Google is quietly hiding search result links behind a new redirect - but only if you're not signed in

What’s actually changed

According to a blog post from scraping-API vendor Autom, Google Search has started rewriting the links on its results pages so they no longer point straight at the destination site. Instead of a readable URL sitting in the page’s HTML, you get a link to google.com/goto?url=..., where that url parameter is a Google-specific, non-decodable blob rather than a simple encoded web address. Click it, and Google’s server redirects your browser to the real page via a Location header, exactly as it always has.

That last part matters: this isn’t a new kind of link-shortening scheme for humans. Google has used redirect wrappers for years - the older google.com/url?q=... format put the destination in plain sight in the query string. The change here is that the destination is no longer readable just by looking at the page’s source code. You (or a piece of software) have to actually make a request to Google’s server and read the response header to find out where a result actually points.

Autom says it first noticed this on a small slice of searches, but by late August it was seeing it consistently across logged-out and private-browsing sessions.

So who is actually at risk

Nobody using Google Search normally in a browser is affected in any meaningful way. Clicking a result still takes you to the page you expect - the redirect happens automatically and invisibly, the same as it always has.

The people this genuinely disrupts are companies and tools that scrape Google’s results pages to build their own indexes or datasets without going through Google’s official APIs - AI crawlers hoovering up search results, SEO rank-trackers, and third-party “search as a service” products like Autom’s own. Previously, those tools could parse a page of Google results and pull out thousands of destination URLs in one pass, no further contact with Google required. With the new format, each result requires a separate round-trip request to Google just to learn where it points - slower, chattier, and far easier for Google to detect and rate-limit.

It’s also worth noting the source here: Autom sells a scraping API and has a direct commercial interest in framing this as a significant “anti-scraping update” - and in reassuring its own customers that it’s already adapted. That doesn’t make the observation false, but it’s not an independent or Google-confirmed account either. Google has not publicly commented on the change.

Why Google might be doing this

The move fits a pattern Autom and others have flagged before: Google steadily raising the cost of automated harvesting of its search results, following earlier steps like scrapping the &num=100 parameter that let scrapers pull 100 results per query, and tightening bot-detection systems. The stated logic is straightforward - make naive scraping slow and detectable enough that it becomes uneconomical, while leaving the experience for ordinary searchers untouched.

What to do about it

If you’re an everyday user, there’s nothing to do - your searches and clicks work exactly as before. If you run software that parses Google’s result pages for links, you’ll need to fetch each /goto URL and read its Location header rather than parsing the HTML directly, or switch to an official API that handles that resolution for you.

The takeaway

This looks like a real, if narrow, tightening of the screws on scrapers rather than any change ordinary searchers will notice. Treat the “anti-scraping update” framing as coming from a company that scrapes for a living - useful signal, but not gospel until Google says so itself.