The reported Google AI Overview tracking parameter has a different origin than initially suggested. Search Engine Roundtable has updated its October 2 article to say that a Chrome browser extension added st_source=ai_overview to the links. The observation therefore does not establish a Google test of native AI-search click attribution.
That correction changes the editorial angle. A parameter that looks descriptive can be useful evidence of a browser’s behaviour, but its name alone does not tell publishers who created it or how reliably it identifies a traffic source. For SEO and analytics teams, this is a practical reminder to validate the collection mechanism before building a reporting category around it.
What changed in the original report
The initial Search Engine Roundtable report described examples shared by Tom Pool, including links in an AI Overview’s source list and an AI Mode example. Barry Schwartz could not reproduce the behaviour across several browsers. The updated article attributes the modified URLs to a Chrome extension, based on Pool’s subsequent clarification.
The extension is not identified in the correction. Nor does the article establish its data handling practices. Speculation about why the extension changed the URLs should not be repeated as a verified finding. The supported conclusion is narrower and sufficient: these examples do not demonstrate that Google supplied the tag.
A URL tag is not automatically an attribution system
Google’s Analytics documentation on campaign URLs describes recognised UTM parameters such as utm_source, utm_medium and utm_campaign. The reported st_source key is a separate parameter. Its appearance should not be interpreted as a documented instruction for GA4 to create an AI Overview acquisition channel.
A website could investigate such a value in its collected URLs or logs, where available, but the resulting segment would need a carefully defined label. Until the tag’s provenance and coverage are established, counting it as all AI Overview traffic would overstate what the evidence supports. Untagged visits would also remain outside that segment, making absence of the parameter an unreliable test of origin.
A useful validation exercise is to repeat the same search in a clean browser profile with extensions disabled, then compare the link before navigation with the destination URL after redirects. Record the query, browser conditions and observation time. This is an investigative recommendation, not evidence that every site must change its tracking setup because of this incident.
Measure visibility and visits as separate questions
Google already documents dedicated generative-AI visibility reporting in Search Console. Its June announcement, updated with global availability on August 31, describes impression reporting for AI features, with page, country, device and date views. Those reports address visibility; a destination URL parameter would address a different part of the measurement chain.
For a publisher, the useful workflow is to keep those questions distinct: where content appears, which visits can be attributed with defensible evidence, and what visitors subsequently do. A screenshot of a tagged link cannot resolve all three. Reports should explain the scope of each dataset rather than suggesting that a single marker closes the entire AI-search measurement gap.
This correction also stands apart from the separate observations of UTM tags on Gemini links. Similar-looking attribution stories still require independent verification. The immediate action is to correct any claim that these examples prove a Google rollout and preserve the measurement lesson: source labels are only as credible as the process that produces them.