# Gemini UTM parameters: 171 of 1,047 sites dropped the tag during a redirect

> Lantad asked all 1,419 hostnames in this repository's two committed corpus seed files for a home page carrying utm_source=gemini on 24 October 2026, as LantadBot with redirects followed and no JavaScript executed. 1,047 answered HTTP 200. Of the 749 that reached the page through at least one redirect, 171 arrived with both parameters gone, and every one of the 298 that made no redirect kept them.

- Canonical page: https://lantad.co/blog/gemini-utm-parameters-171-of-1047-dropped-in-a-redirect
- This file: https://lantad.co/blog/gemini-utm-parameters-171-of-1047-dropped-in-a-redirect.md
- Last substantive update: 2026-10-24

## Key facts

- **Published:** 2026-10-24
- **Category:** Findings
- **Author:** Lantad
- **Length:** 3443 words
- **Takeaway 1:** Gemini UTM parameters only reach your analytics if your own redirects carry them: Lantad requested a tagged home page from 1,419 corpus hostnames on 24 October 2026, and of the 1,047 that answered HTTP 200, 171 landed on a URL with both parameters stripped.
- **Takeaway 2:** The redirect is the whole mechanism. All 171 losses happened on a site that redirected, and not one of the 298 sites that answered without a redirect lost the tag, measured on 24 October 2026.
- **Takeaway 3:** 119 of the 171 losses were already visible in the first response: the Location header named a bare host with no query string at all, on a first hop that was 301 in 136 cases, 302 in 32 and 308 in 3.
- **Takeaway 4:** The platform decided the outcome more than the sector did. All 30 Squarespace hosts in the corpus that redirected lost the tag on 24 October 2026, while all 18 Wix hosts redirected and all 18 kept it.
- **Takeaway 5:** A stripped parameter is narrower than it looks: the referring header is a separate signal that a redirect does not touch, so a site can lose the campaign tag and still see that the visit came from Gemini.

## Summary

Google has started tagging the links it sends out of Gemini, and whether that tag ever reaches your analytics is decided by your own server before any page loads. Search Engine Journal reported the tagging on 1 October 2026, in a piece by Roger Montti, after a user in an r/SEO thread noticed it; the article states that Google's implementation is undocumented, and John Mueller replied in the same thread that he could see it too and asked for reproducible examples. That is the whole of the public record. Google has published no documentation for it, so the exact parameter value is not a figure this site can confirm from a primary source, and nothing below depends on it.

What a scanner can confirm is the receiving end, which is the part nobody checks. A tagged link is just a URL with a query string, and a query string survives a redirect only if whoever wrote the redirect chose to carry it. So Lantad asked all 1,419 hostnames in this repository's two committed corpus seed files for their home page with a tracking query attached, followed the redirects, and recorded what the final URL looked like. 1,047 answered HTTP 200. 171 of them answered at an address with the query gone. This post is about which redirect ate it, on which hop, and why the [AI crawler](https://lantad.co/glossary/ai-crawler) side of the house turns out to be the wrong place to look for the cause.

## What are Gemini UTM parameters, and what is actually confirmed about them?

A UTM parameter is a name and value bolted onto the end of a URL so that analytics software can tell where a visit came from. It changes nothing about the page. It is a label attached to the request, and it has to arrive intact at the address the browser finally loads, because that is the only address any script on the page can read.

The reported development is that Gemini now attaches such a label to the links it shows. The record for it is thin and worth stating plainly rather than dressing up. Search Engine Journal published the report on 1 October 2026 at searchenginejournal.com/google-gemini-adds-utm-parameters-for-referral-attribution/591754/, that host is not on this site's registered outbound list so the address is written out rather than linked, and the article says the implementation is undocumented. Its only figure is a pass-through rate offered by a commenter in the same Reddit thread, which the article does not verify, so it is not repeated here as a number. This blog has taken that position on an announcement before, when [the only number in a Google AI Mode post was a multiple with no base](https://lantad.co/blog/ai-mode-citations-five-changes-and-one-number).

Lantad has not measured Gemini's behaviour and this post does not claim to. What it measures is the thing a site owner controls, and the measurement is deliberately indifferent to the exact tag: the request carried utm_source=gemini and utm_medium=referral, chosen to match the reported name, but any two query parameters would have travelled identically, because nothing in a redirect inspects what a query string means. The finding generalises to every tagged link a site receives, from [an engine that cites it](https://lantad.co/how-to-get-cited/google-ai-overviews) or from anywhere else. That is why it is worth a measurement rather than a guess, and why the result is not really about Gemini at all.

## What Lantad asked 1,419 hostnames, and what answered

The population is the one this blog uses for every corpus run: the 1,419 hostnames in the two committed seed files under worker/seeds, covering ten site-builder strata and eight industry strata. Nothing was sampled and nothing was chosen for this question, which matters, because a population picked after seeing the result is not a population.

Every host was asked for robots.txt first, as LantadBot, the token this scanner publishes on [its own crawler page](https://lantad.co/bot). 1,150 files parsed into at least one user-agent group. 176 answered a 4xx status, which [RFC 9309](https://www.rfc-editor.org/rfc/rfc9309) treats as unrestricted access, and 93 answered a 5xx or otherwise unusable status, which this scanner treats as a disallow rather than guessing, the posture described on [the methodology page](https://lantad.co/methodology). Each parsed file was then evaluated for the tagged home-page path using the same longest match rule the scanner ships, the one you can exercise by hand in [the robots.txt tester](https://lantad.co/tools/robots-txt-tester). 152 hosts refused LantadBot that path and were not requested.

The remainder were asked for the home page once, with the query attached, redirects followed to a limit of ten, and no JavaScript executed. 1,047 answered HTTP 200 and 220 answered something else, 183 of them a 403 to a named scanner, which is its own finding and not this one: [a user agent is a claim rather than an identity](https://lantad.co/blog/a-user-agent-is-a-claim-not-an-identity), and plenty of servers decline the claim. Those 1,047 landings are the denominator for everything that follows. Two caveats belong here rather than at the end. The request was not a browser, and a site that varies its behaviour by user agent could redirect a person differently, which is the failure mode behind [Vary: User-Agent being declared and ignored](https://lantad.co/blog/vary-user-agent-32-of-1072-home-pages-declared-it). And one request to one home page is not a crawl of a site.

## How many sites dropped the tracking parameter?

Of the 1,047 landings, 874 ended at a URL still carrying both parameters, 171 ended at a URL carrying neither, and 2 arrived altered rather than intact. Split by whether the site redirected at all, the number stops being a rate and becomes a mechanism.

298 of the 1,047 answered the tagged request directly, with no redirect. All 298 kept both parameters, which is not surprising and is worth recording anyway: it establishes that nothing in the request itself loses the tag. 749 reached the page through at least one redirect. 576 of those kept both parameters, 171 lost both, and 2 landed somewhere stranger. So the loss rate among redirecting sites is 171 of 749, and among non-redirecting sites it is zero of 298. There is no third cause to look for.

The two odd ones are worth naming because averaging them away would hide the interesting part. On faz.net the first hop carried the query correctly and a later hop left utm_medium as referral%2F, a value that analytics will read as a campaign nobody created. On geisinger.org the request was handed to a bot-management validator on a different host, which had folded the original tagged URL, encoded, into its own query string. Neither is a dropped parameter and neither is a clean one, so they sit in their own row rather than being counted as either. That kind of interstitial is also why [878 of 1,322 home pages answered a crawler with a redirect](https://lantad.co/blog/do-ai-crawlers-follow-redirects-878-of-1322) in an earlier run: the redirect is where sites put their machinery.

## Which hop loses the query string, and why nothing stops it

Looking at the first response each of the 171 sites gave splits them cleanly. 119 had already lost the query in the first Location header: the server answered the tagged request with a redirect to a bare host and a slash, so the tag was gone before the second request was made. The other 52 carried the query correctly through the first hop and lost it later, and 33 of those 52 ended on a path beginning with a language or region segment, which is the same machinery behind [27 of 719 home pages changing language on a header alone](https://lantad.co/blog/hreflang-and-ai-crawlers-27-of-719-changed-on-a-header). By status code the first hops were 136 responses of 301, 32 of 302 and 3 of 308.

The reason nothing stops this is that no specification asks anyone to. [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110) defines the Location field as a single URI reference and gives the server the choice of what goes in it. The standard does go out of its way to rescue one component: section 10.2.2 states that where a Location value in a 3xx response has no fragment component, a user agent MUST process the redirection as if the value inherits the fragment of the original reference. The query gets no such sentence anywhere in the document. So the one part of a URL the standard protects across a redirect is the fragment, which a server never receives, and the part analytics depends on is left entirely to whoever wrote the rule.

Nor does the search guidance fill the gap. [Google's redirect documentation](https://developers.google.com/search/docs/crawling-indexing/301-redirects), carrying Last updated 2026-04-14 UTC, sorts redirect types into permanent and temporary and says nothing at all about query strings. The practical difference shows up in configuration rather than in prose: the nginx example on [MDN's redirections guide](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Redirections) returns $scheme://www.example.com$request_uri, and $request_uri includes the query string, while the Apache example beside it describes path preservation only. Two ways of writing the same apex to www rule, one of which keeps the tag, and no document telling an administrator that the choice matters.

## Squarespace lost it 30 times out of 30, and Wix none out of 18

The corpus is stratified, so the losses can be attributed. They do not spread evenly, and the strongest signal is not an industry at all. The site-builder stratum that mixes Squarespace and Wix hosts lost the tag on 30 of its 49 redirecting landings, far worse than any industry. Fingerprinting those hosts by their own response headers separates the two products completely. 35 answered as Squarespace, of which 30 redirected and all 30 dropped the query, while the remaining 5 served the apex directly and so had nothing to rewrite. 18 answered as Wix, all 18 redirected, and all 18 carried the query through. One host could not be identified and kept the tag.

That is as clean a split as this corpus produces, and it is a platform default rather than a choice any of those site owners made. Nobody running a Squarespace site wrote that redirect. Two other builder strata behave like Wix: the Webflow hosts redirected 31 times and lost the tag zero times, and the Shopify storefronts redirected 6 times and lost it zero times, which is consistent with what [the Shopify stack guide](https://lantad.co/fix/shopify) and [the Framer guide](https://lantad.co/fix/framer) describe about how little of the serving path those platforms hand over.

The industry strata vary more mildly and in a way that reads as infrastructure age rather than sector. Government hosts lost the tag on 28 of 80 redirecting landings, finance on 20 of 80, education on 17 of 72, travel on 16 of 61, healthcare on 15 of 78, news on 10 of 78, software on 9 of 65 and ecommerce on 6 of 52. The large institutional estates with locale front doors are the ones that lose it, which fits the second-hop pattern above. None of this says anything about whether those sites are readable by an answer engine, which is a separate question that [the crawlability study](https://lantad.co/research/crawlability-study) reports on, and a good tag on an unreadable page buys nothing.

## What a stripped tag actually costs, and what it does not

The inconvenient part of this finding is that the loss is narrower than the number makes it sound, and saying so is more useful than letting it stand. A server-side redirect happens before any document renders, so no script ever runs at the tagged address and client-side analytics never sees the parameter. That much is a real, total loss for campaign attribution. But the first server in the chain did receive the tagged request and can see it in its own access log, and the referring header is a separate mechanism that a redirect does not strip. Mueller's own reply in that Reddit thread made this point, asking whether Gemini already passed a referrer.

So the honest statement is specific: a site in the 171 loses the campaign label in its analytics product while usually keeping a referrer that still identifies the source. That is a degraded signal rather than an absent one, and the degradation is uneven in a way that matters for anyone reporting on it. A referrer tells you a visit came from somewhere. A tag can tell you which surface and which variant, and it survives a redirect to a third-party link wrapper where a referrer often does not, which is the same fragility behind the published split in [how Meta took the crawl volume while ChatGPT kept the referrals](https://lantad.co/blog/meta-took-the-crawl-volume-chatgpt-kept-the-referrals). Treating the two as interchangeable is how an attribution report quietly becomes wrong.

It also sets a limit on what any measurement of this kind can claim, including this one. Lantad counted URLs, not visits. Nothing here measures how much Gemini traffic any site receives, whether the tag is applied consistently, or what an analytics product then does with it, and this run cannot distinguish a site that would behave differently for a real browser. Being named by an engine at all is a different measurement again, reported through [AI visibility](https://lantad.co/glossary/ai-visibility) work such as [the finding that 15 of 31 brand mentions carried no rank](https://lantad.co/blog/ai-rank-tracking-15-of-31-mentions-carried-no-rank). What this run establishes is one link in that chain, and that the link is broken on 171 of 1,047 sites for a reason none of them chose.

## How to check your own site in one request

This needs no tool and no account. Request your own home page with any two query parameters attached, follow the redirects, and look at the address you end up on. If the parameters are still there, nothing on this page is your problem. If they are gone, read the Location header of the first response: a value ending in a bare slash is the 119 case and the fix is in whichever rule wrote it, while a value that still carries the query means a later hop is responsible and you need to look at the locale or trailing-slash rule that follows.

The fix is a one-line configuration change in every case this run found, and it is the same change: make the redirect carry the request's query rather than composing a fresh URL. On nginx that is the $request_uri form in the MDN example above. On a hosted builder it is not available to you at all, which is the honest answer for the 30 Squarespace hosts: the redirect belongs to the platform, the only remedies are serving on the host the platform does not rewrite, as the 5 that kept the tag do, or reporting it. Naming that limit is more useful than implying a setting exists.

Worth keeping the result in proportion. A tag is a reporting convenience, and this site's subject is the layer underneath it, which is whether an engine can read the page in the first place. A page that no crawler can fetch has nothing to attribute, and that is the failure [the crawler directory](https://lantad.co/tools/ai-crawlers) and [what GPTBot sees](https://lantad.co/tools/what-gptbot-sees) exist to surface, alongside the vocabulary in [generative engine optimization](https://lantad.co/glossary/geo) and [answer engine optimization](https://lantad.co/glossary/aeo). Fix the redirect because it is cheap and it is yours. Then go and check whether the page behind it is readable, because that is the measurement that decides whether there is any traffic to label.

## Questions and answers

**What are Gemini UTM parameters?**

They are tracking parameters reported to be appended to the links Gemini shows, so that analytics software can attribute the visit. Search Engine Journal reported the tagging on 1 October 2026 and states that Google's implementation is undocumented, so the exact value is not confirmed from a primary source. The measurement in this post does not depend on it: any two query parameters travel through a redirect identically.

**Why would my site lose a UTM parameter?**

Because a redirect on your own site composed a new URL instead of carrying the one that was requested. Of 1,047 corpus home pages that answered HTTP 200 on 24 October 2026, 171 landed with both parameters gone, and every one of those sites had redirected at least once. None of the 298 that answered without a redirect lost anything.

**Does any standard require a redirect to keep the query string?**

No. RFC 9110 section 10.2.2 defines Location as a single URI reference chosen by the server, and it requires a user agent to inherit only the fragment component when the Location omits it. The query component is given no equivalent rule anywhere in the document, and Google's redirect documentation, Last updated 2026-04-14 UTC, does not mention query strings at all.

**If the tag is stripped, is the visit untracked?**

Not entirely. The redirect happens before any page renders, so client-side analytics never sees the parameter, but the first server received the tagged request and can see it in its access log, and the referring header is a separate signal that a redirect does not strip. The campaign label is lost while a coarser source signal usually survives.

---

Lantad measures whether AI crawlers can actually read a page: it fetches as a non-rendering
crawler, renders as a browser, and reports the gap. Free scan, one URL, no signup.

Method and weights: https://lantad.co/methodology | All pages as markdown: https://lantad.co/md | Crawler policy: https://lantad.co/bot