RC RANDOM CHAOS

You depended on access you never owned.

Google Search now routes organic result links through google.com/goto, hiding destination URLs behind an undecodable blob to slow SERP scraping.

· 3 min read
You depended on access you never owned.

Google Search now points its organic result links at google.com/goto?url=... instead of putting the destination URL in the page HTML. Click a result and Google redirects you to the real page. The url parameter carries a custom, Google-specific encoding rather than a plain base64 of the target, and in practice it reads as an opaque reference to Google’s own index record for that page. You cannot decode it offline.

As of late August 2026, Autom reports this showing up consistently for logged-out and private-mode sessions. It may still be an experiment, but it has moved past a small slice of SERPs: in those conditions the result URLs are effectively all goto.

What changed from google.com/url

Google has wrapped result links in redirects before. The old format was google.com/url?q=[URL-encoded destination], with the target sitting readable in the query string, parseable straight out of the HTML. The goto format breaks that in three ways. The href is /goto, not the destination. The url= blob does not decode without asking Google. And the real URL only appears in the Location header that /goto returns. To get it, you request /goto and read Location. You do not follow the redirect through to the page.

One nuance is worth keeping. Google still has to render the destination somewhere to draw the result row, so it can show the domain, favicon and attribution. Copies of the URL therefore remain on the page. Reading those is a separate problem from reading Location, and a separate story.

Why Google is doing it

The change is aimed at automated SERP harvesting, the AI crawlers and SEO scrapers that bulk-extract result URLs to build their own indexes. With plaintext links, a scraper parses thousands of URLs out of one HTML response and never talks to Google again. With goto, every result it wants to resolve becomes another request back to Google. That is slower and noisier, and it hands Google a clean signal: the same client resolving hundreds of /goto links in sequence looks nothing like a person clicking one.

It lines up with the earlier moves. Google removed &num=100 and tightened BotGuard/SearchGuard, and goto is the next increment. Each step raises the price of naive scraping without closing it outright.

If you run a pipeline on Google results

Resolve goto the way the behaviour allows: request the /goto URL and read the Location header, then stop. Following the redirect through to the destination doubles your requests and your footprint for no extra data, since the URL you wanted is already in the header. That keeps you to one extra request per link.

Autom says it has updated its Google Search pipeline to do exactly this, read Location, no follow, and return the final destination in the same structured fields its API already exposes, so callers of those endpoints should keep getting usable URLs without changing their integration.

The plaintext result URL was never a stable interface. Anyone whose index was built on free, offline-decodable access to Google’s result links was depending on access they never owned, and Google is now withdrawing it one encoding change at a time. The format can shift again, and Autom expects to adjust if it does. If you resolve goto yourself, plan for the same.

Share

Keep Reading

Latest on the Wire

Full wire →

New signal daily · RSS

Stay in the loop

New writing delivered when it's ready. No schedule, no spam.