Google Confirms It Is Routing Search Result Links Through a goto Redirect

Google has confirmed it is rolling out a redirect on the links in its search results. Instead of pointing straight at the destination page, a result link now routes through google.com/goto?url=, with the target address encoded inside it.

A Google spokesperson told Search Engine Land: “We have a long history of deploying technical measures against evolving forms of abuse, and we regularly take steps to protect our services and users.”

Google did not name scraping in that statement. The mechanism points that way, and it arrives a month after the company lost its main legal argument against a scraping company in court.

What is the google.com/goto redirect?

A search result link used to contain the destination URL in full, so hovering over it showed the address you were about to visit. The link now carries a Google URL with the destination encoded as a parameter, and a server-side redirect sends the browser on to the page.

Not every searcher gets it. Ray Grieselhuber of the search analytics company DemandSphere wrote on 27 August that signed-in users “may or may not get the goto link replacement”, and pointed to incognito mode as the way to reproduce the behaviour reliably; a separate observation on X the day before described the same split, goto links on logged-out searches but not logged-in ones. Google has said nothing about who the rollout covers, so this is practitioner observation rather than documented behaviour, and it explains why two people checking the same query can disagree about whether the change has landed. It does not soften the effect on measurement tools, because a scraper reads a logged-out results page.

Barry Schwartz reported the confirmation on 26 August 2026 for Search Engine Roundtable and Search Engine Land. Derek Perkins of the rank tracking company Nozzle told him Google had been pushing the change live and that he was seeing it at “nearly a 100% rollout across several residential ip providers”.

The behaviour itself is not new, only newly confirmed and newly widespread. Alex Greenland reported rewritten result links on 23 June 2026, reading the pattern as goto?url= followed by what looked to him like a custom base64-like encoding of either the destination URL or a Google ID. What sits in the parameter is a long run of digits and mixed-case letters with underscores, which is the character set base64url encoding uses. Brodie Clark of SERPAlerts flagged it on 2 July and recorded that the wrapper answers with a 302, a temporary redirect, which tells a crawler the wrapper is not meant to replace the destination address anywhere it stores one. Schwartz wrote it up as a test on 8 July 2026 and noted then that he could not reproduce it himself, which is roughly the difference between that report and this one.

Why is Google adding a redirect to its result links?

Perkins described it as an anti-bot measure that removes client-side links in favour of server-side redirects. The consequence for anyone reading a results page programmatically is the substance of the change:

The goto links can’t be decoded, so providers will have to follow the redirect links. While that works in small scale tests, Google seems likely to make that tough, since each SERP will have hundreds of links to decode.

A scraper that could once read every destination straight out of a page’s HTML now needs an extra request per link to find out where that link goes. Perkins has since put a number on it: resolving every link across a five-page ranking takes 500 to 1,000 requests.

The cheap way round it is closed. A HEAD request asks a server for a URL’s headers without its body, which would hand back the redirect target at a fraction of the cost of a page fetch, and Perkins said Google does not let HEAD requests through. A GET that stops at the redirect still works and still avoids downloading the destination page, so the limit that decides what breaks is Google’s rate limiting rather than bandwidth or storage.

There is a recent precedent for what that does downstream. In September 2025 Google stopped supporting the num=100 parameter, which had let a tool collect 100 results in one request; afterwards the same job took ten. An analysis of 319 properties by Tyler Gargula of LOCOMOTIVE Agency found 77.6% of them lost query count in Search Console and 87.7% lost impressions. The mechanism differs, num=100 changed how much a tool could fetch per request while goto changes what a tool can read from what it already fetched, but the shape of the consequence is the same: collection gets more expensive, and the depth of your tracked data is what absorbs the cost.

The timing sits next to a legal setback. In July 2026 a US federal court dismissed Google’s DMCA claims against SerpApi, holding that bypassing anti-scraping controls to reach uncopyrighted search results is not circumvention under that law. That removed a legal route against scraping; this is a technical one. Google has not connected the two, so the sequence is context rather than established cause.

What the goto redirect means for your rank tracking

The parties who carry the cost here are the tool providers, not site owners. What reaches you is the data those tools produce.

• Rank tracking held up. The providers absorbed this within about a week. If your positions looked sparse or stale in the days after 26 August, that window is the likelier explanation than a ranking change.
• Check a sudden movement against Search Console. A tracked position that swings with no matching change in impressions or average position is more likely a collection artefact than a real one.
• Nothing to implement. The redirect sits on Google’s side of the click. No change to your site follows from it.

Update, 5 September 2026: The collection problem was solved faster than expected. SerpApi said on 5 September that it had deployed a fix and that its Google Search API was returning destination addresses again rather than the Google wrapper, and SE Ranking and Semrush both said their position tracking was never affected. This article originally expected tracked data to thin out while providers adapted, which is what the 500 to 1,000 request figure above implied; it did not happen at that scale. No provider has described how it recovers the destination address, and Google still has not documented the goto parameter or said whether it is permanent.

Two things are not yet established. Google has said nothing about Search Console specifically. Its reports are built from Google’s own logs rather than by reading a results page, so the redirect does not sit between Search Console and its data, but that reasoning on its own would have been wrong last time. The num=100 removal moved Search Console impressions too, because the tools appending the parameter had been generating impressions of their own along the way. Whether the goto redirect shifts scraper behaviour enough to show up in anyone’s impression data is unknown, and worth watching rather than predicting. And no one has yet published measurements of what the extra hop does to referrer data. The redirect stays on a Google domain, so the referrer a site receives should still resolve to Google as it does today, but that is reasoning from how referrers behave rather than an observation anyone has reported.

Sources

• Google Tests google.com/goto Tracking URLs In Search Results, Search Engine Roundtable
• Confirmed: Google Search Rolling Out google.com/goto Tracking Parameters, Search Engine Roundtable
• Google confirms deploying goto URL redirects to search results links, Search Engine Land
• 77% of sites lost keyword visibility after Google removed num=100, Search Engine Land
• Google goto links strip destinations, costing rank trackers 500 to 1,000 requests per query, PPC Land
• SerpApi restores direct URLs after Google goto redirect rollout, PPC Land
• An update from DemandSphere on Google’s goto redirects