Full Answer

Safari's Link Tracking Protection works at the browser level, after the HTTP request has already left the device. When a visitor clicks a Google ad, the browser sends a request to your server with the full URL — gclid, fbclid and all. Only after the page starts rendering does Safari strip those parameters from the address bar and from JavaScript access. A client-side tag that tries to read gclid from the URL finds it gone. A server-side setup reads it from the incoming request before that ever happens.

The storage step matters just as much. Once captured, the gclid goes into a first-party cookie set via an HTTP Set-Cookie header from your own domain. Safari ITP does not apply its 7-day cap to server-set first-party cookies the way it does to JavaScript-set ones. The click ID survives longer attribution windows, so when the visitor returns days later and completes a purchase, the server retrieves the stored gclid and forwards it to Google Ads with the conversion event.

iOS 26 extends this stripping to all standard Safari browsing — not just Private Browsing and Mail links as before. That makes server-side gclid capture a requirement rather than an optimisation for any WooCommerce store running Google Ads. For the full impact breakdown, see [iOS 26 is quietly deleting your gclid and fbclid before the page loads](https://seresa.io/blog/data-loss/ios-26-is-quietly-deleting-your-gclid-and-fbclid-before-the-page-loads).