Google has confirmed that it is rolling out google.com/goto passthrough redirects on search results, replacing the direct link to a destination page with a Google-owned hop that has to be followed before the real URL is known. [1] For anyone whose reporting depends on parsing search results, the damage is narrower than the first read suggests. Google still prints the display URL under every result title, because that line is how a searcher decides whether a link is safe to click, so domain-level rank tracking, share of voice and competitor identification all survive without resolving anything. What degrades, and what almost nobody is covering, is exact URL-level attribution.
CAESgAEB and continues past the right edge of the image. [1] [5] Base64url decoding succeeds immediately. The first five bytes are 08 01 12 80 01, which is protocol-buffer wire format. Read as protobuf, the token declares a first field holding the number 1, then a second field declaring a payload of 128 bytes. Across the 63 payload bytes the crop let me recover, there is not one run of four or more readable characters. No http, no .com, and no fragment of the destination domain, which in this sample was a Search Engine Roundtable article.
So the barrier is not the encoding, and stripping base64 leaves a binary blob that either is encrypted or is an identifier pointing at a lookup only Google can perform. Either way there is no destination to parse, and the redirect has to be followed. This also resolves an ambiguity in the June sighting, which described the parameter as carrying a "base64-like encoding of URL or Google ID." [2] In this sample it is the second thing. My decode cannot say whether the token is signed, whether it expires, or whether Google binds it to the issuing session. Those three stay plausible and unverified.
## What survives the change, and what degrades?
Domain-level attribution survives, because Google still renders a display URL under every result title, whether or not the destination link resolves. [1] URL-level precision degrades, because that display line is breadcrumbed and truncated. Rank tracking by domain holds up, and naming the exact ranking page does not.
*Result and token prefix from the screenshot Search Engine Roundtable published 2026-08-26; token decoded first-hand 2026-08-27.*
The screenshot Search Engine Roundtable published shows both halves at once, the goto link in the status bar and the display line under the title. [1] That display line renders as a breadcrumb with the path truncated behind an ellipsis, so the visible text identifies the site and gestures at the page. Google has strong reason to keep printing it, since it is the trust affordance a searcher uses to judge a link before clicking. Competitor set discovery and most of what an enterprise visibility dashboard reports survive on that line alone. For a catalog with tens of thousands of near-identical product pages, "which of these URLs ranks for this term" stops being an exact answer. Four things degrade together: page-level rank tracking, keyword-to-URL mapping, cannibalization analysis, and any merchant or citation attribution that joins on the destination URL. Every one of those lines its own data up against Google's results on the exact URL, the join key, meaning the single field two datasets are matched on. That field is what goes away.
## Is the circulating chart really evidence of a 100% rollout?
The chart is titled goto_error_rate by hour, and reading it as a rollout percentage confuses two measurements. Nozzle's chart, published by Search Engine Roundtable, is captioned as the percentage of goto-only result pages Nozzle fetched across roughly four months of the test. [1] Rollout reach and share of affected fetches are two different quantities resting on two different denominators.
My read of that screenshot puts the series near zero through May, in the low tens through June and July, and up around the twenties to forties across the second half of August, with two brief single-hour excursions to 100. Estimated from a published image, since no underlying data accompanied it.
Both figures can be true at once, and keeping them apart matters for anyone quoting either. "Nearly a 100% rollout across several residential ip providers" describes reach across the IP ranges a vendor fetches through, whereas the share of fetched result pages that come back goto-only describes how often the behavior is actually served. [1] A feature can be live everywhere and still be served on a minority of requests. Anyone building a plan on the claim that it sits at 100% has, on my read, taken the first number for the second.
Nozzle counts a goto result page as an *error*, and in July Perkins described the mitigation plainly: "We just throw away those SERPs and fetch new ones." [2] Discard-and-refetch is cheap while the behavior is rare, and it inverts once the behavior is common, because there is no clean version of the page left to fetch.
## Does resolving every link really cost 100 times more?
The intuitive read of "hundreds of links per result page" is a hundredfold cost increase, and on bandwidth that is close to backwards. Fetching a rendered result page moves a substantial amount of data and is billed by the gigabyte. Vendors do it through a residential proxy, an address borrowed from an ordinary home connection so the request does not look like a bot's.
Following a redirect returns a status line and a few headers, typically well under a kilobyte, with nothing rendered. A hundredfold jump in request count can therefore land as a rounding error on the bill, which makes raw resolution the cheap half of the problem. My cost model, not a vendor's. Detectability is the constraint that actually binds, and Google just moved the endpoint inside its own perimeter. Because Google now owns that endpoint, it can cap how often a caller resolves links, expire the token, tie it to one session, and fingerprint the requester, meaning build a behavioral profile that identifies a bot with no name attached. The signature is loud on its own. A searcher runs one query and clicks zero to two results, while a resolver runs one query and requests 150 destinations in seconds, and that ratio is a classifier before anyone writes one.
Pace resolution down to a human-plausible click ratio and the unit of cost stops being requests. Resolving 100 links at a believable rate needs something like 50 sessions, and a session means a result-page fetch, which is the expensive item. You would be re-fetching result pages to earn the budget to resolve links, which is the discard-and-refetch loop Nozzle already runs, now a permanent tax instead of an occasional retry. At that point sampling is the only economics that closes, and selective deep resolution becomes a premium tier covering top results only, tracked domains only, on a sampled cadence.
## Where does this leave the SerpApi lawsuit?
Google amended its complaint against SerpApi on August 10, 2026, and the new theory turns on having authority to deploy an access control. [3] A federal judge dismissed the core of Google's original anti-circumvention claim in July, on the ground that the barrier Google was defending guarded uncopyrighted search-result data. [4] The amended complaint answers that by routing through licensed content.
Google alleges its Reddit agreement "directs Google not to enable third parties to extract and independently commercialize the licensed content, making clear Google has the authorization to prevent such behavior through access control mechanisms such as SearchGuard," and that Reddit "specifically asked Google to employ technical measures" once it suspected scrapers were reselling licensed content. [3] Reddit is also suing SerpApi directly in the Southern District of New York. [3]
The amended complaint names SearchGuard 33 times and never mentions goto, redirects or passthrough URLs at all, which I verified by searching the filed document. [3] [5] Google has not connected the two. What sits on the record is a sequence, starting with a dismissal in July, then a refiled complaint on August 10 arguing that Google holds partner authority to run access controls, and a confirmed rollout of a server-side redirect by August 26, with one vendor reporting near-full reach. In my opinion the sequence is worth watching, because restructuring the facts so the conduct reads as issuing authenticated requests against an endpoint instead of reading a public page is useful in court whether or not it stops anyone. That reading is mine, and readers checking after publication should look at the live docket instead of treating any of it as settled. [4]
## What should you do before your rank data changes shape?
Record today's date as the rollout marker, and draft the measurement-change explanation now, before a stakeholder asks. The likeliest source of pain is the day a vendor swaps exact-URL attribution for inferred attribution and your time series steps sideways. Page-level rank distributions shift, tracked URL counts move, and the shape on the chart is indistinguishable from a real visibility event.
Econometrics already has a name for that shape, a structural break, and the fix is knowing the break date instead of inventing a cause for it. I have run this diagnosis the hard way, on a reporting cliff that turned out to be a vendor reclassifying one field on a known date, with no traffic loss underneath it. Recovering that date after the fact cost far more than recording it would have. This week, in rough order of payoff.
1. Record the rollout date, and note that Google confirmed it publicly on August 26, 2026. [1]
2. Watch vendor exports and API pulls for null, truncated or breadcrumb-shaped URL fields, which is how this surfaces before any vendor announces it.
3. Ask each vendor in writing whether URL-level position is measured or inferred, and from what date, because inference from a crawled index of your own site is the likely substitute and it is probabilistic.
4. Pin page-level truth for your own properties to Search Console, which reports URLs directly and is unaffected by how anyone parses a result page.
5. Annotate your dashboards on the switchover date, so the step change carries its own explanation the first time somebody scrolls back to it.
The tools will adapt, and the adaptation is where your risk lives. A vendor that quietly moves from parsing an exact URL to inferring one has not told you your numbers changed meaning. Neither will the chart.
## Sources
1. Search Engine Roundtable: Confirmed: Google Search Rolling Out google.com/goto Tracking Parameters (Barry Schwartz, Aug. 26, 2026) — https://www.seroundtable.com/google-search-goto-tracking-41957.html
2. Search Engine Roundtable: Google Testing google.com/goto As Tracking URLs In Search Results (Barry Schwartz, Jul. 8, 2026) — https://www.seroundtable.com/google-com-goto-as-tracking-urls-41647.html
3. US District Court, N.D. Cal.: Amended Complaint, Google LLC v. SerpApi, LLC, No. 4:25-cv-10826-YGR, ECF No. 45 (filed Aug. 10, 2026) — https://storage.courtlistener.com/recap/gov.uscourts.cand.461513/gov.uscourts.cand.461513.45.0.pdf
4. CourtListener: Docket, Google LLC v. SerpApi, LLC, 4:25-cv-10826 (N.D. Cal.) — https://www.courtlistener.com/docket/72059948/google-llc-v-serpapi-llc/
5. First-hand analysis: base64url and protocol-buffer decode of one google.com/goto token, read from the screenshot published by Search Engine Roundtable (Brandon Lazovic, Aug. 27, 2026)