google.com/goto: Google's anti-scraping updateFeaturesPricingDocumentationBlogLoginSign upHomeBloggoogle.com/goto: Google's anti-scraping updatePublishedAugust 27, 2026CategoryGoogleAuthorsAutom TeamShareX.comReady to scrape?Start scraping with Autom today and discover the power of our API.Start for freeGoogleAugust 27, 2026|by Autom Teamgoogle.com/goto: Google's anti-scraping updateWhat's happening
Google Search is rewriting organic result links to google.com/goto?url=... instead of exposing the destination URL directly in the HTML.
When you click a result, Google redirects you to the real page. The url parameter uses a custom, Google-specific encoding. It is not a plain base64 of the target URL. In practice, it looks like an opaque reference to Google's index record for that page.
As of late August 2026, this is showing up consistently across searches when you are logged out or browsing in private mode. It may still be an experiment, but it is no longer limited to a small slice of SERPs.
Not the same as google.com/url
Google has used redirect wrappers before. The older format is google.com/url?q=[URL-encoded destination], where the target link is readable in the query string.
The new goto format is different:

The result href is /goto, not the destination
You cannot decode the url= blob offline
The real URL is in the Location header on /goto. Request that URL. Do not follow the redirect.

Google still needs the destination to draw the SERP (domain, favicon, attribution), so copies of the URL remain on the page. That is a separate story from reading Location. The walkthrough is here: google.com/goto: read Location with HEAD.
That shift matters for anyone building a search index from SERP data at scale.
Why Google is doing this
This fits Google's broader push against automated SERP harvesting, especially from AI crawlers and SEO scrapers that bulk-extract result URLs to build their own indexes.
With plaintext links, a scraper could parse thousands of URLs from HTML without touching Google again. With goto, each result needs a request back to Google just to learn the destination. You read Location; you do not follow through to the page. That is slower, noisier, and gives Google a clear signal when the same client resolves hundreds of links in sequence.
Combined with earlier moves like removing &num=100 and tightening BotGuard/SearchGuard, Google is steadily raising the cost of naive SERP scraping.
What we saw at Autom
We first spotted goto links on a small percentage of SERPs. At that level, it was hard to ship a reliable fix without breaking responses for everyone else.
As of late August 2026, the pattern is much more consistent for logged-out and private sessions. Result URLs on Google Search are effectively all goto in those conditions.
We have been monitoring the rollout and testing against it.
Update at Autom.dev
We have updated our Google Search pipeline to resolve google.com/goto links (read Location, no follow) and return the final destination URL in API responses, in the same structured fields customers already use.
If you call Autom's Google Search endpoints, you should keep getting usable destination URLs without changing your integration. We will keep watching Google's rollout and adjust if the redirect format shifts again.
Related reading

google.com/goto: read Location with HEAD
Google killed num=100
Google sues SerpAPI: What SearchGuard reveals
Scraping SERP with Google, Bing, and Brave

Need live SERP data while Google keeps moving the goalposts? Try 1,000 free requests on Autom pricing, or get an API key at app.autom.dev/register.Read alsoGoogleNeed To Know About Google Search APIAutom Team|Jan 15, 2026GoogleHow To Scrape Google News using PythonAutom Team|Feb 3, 2026GoogleSerpApi vs Google Search API vs Autom.devAutom Team|Mar 6, 2026GoogleGoogle sues SerpAPI: What SearchGuard reveals about bot detectionAutom Team|Jan 20, 2026SERP APIDiscover why Autom is the preferred API provider for developers.Deploy your SERP scraperView pricingFastest SERP API8Secure paymentsDiscordResourcesPricingDocumentationBlogLibraryToolboxService StatusAll resourcesCompareOxylabsScrapingbeeBright DataScraperAPISerpAPISee allAccountLoginRegisterContact usCompanyWebAPI GroupPrivacy PolicyTerms of ServiceAffiliateBug BountyStartup ProgramPreferences🇺🇸EnglishAutom has been servicing since0 years 0 months 0 days 0 hours 0 min 0 secs🇺🇸English

Google is implementing a significant change in how it presents organic search result links, shifting from directly exposing destination URLs in the HTML to using a custom format known as google.com/goto?url=... This new method utilizes a Google-specific encoding that functions as an opaque reference to Google's index record for the page, rather than exposing the target URL directly. This development contrasts with the older redirect wrapper format, google.com/url?q=[URL-encoded destination], where the destination link was explicitly present in the query string. In the new goto format, the result href points only to /goto, and the actual destination URL must be retrieved by making a request to the Location header of the /goto request, explicitly instructing not to follow the redirect.

This structural change has critical implications for entities that build search indexes from Search Engine Results Page data at scale. The shift alters the mechanism for accessing destination URLs, necessitating different approaches for data extraction. The motivation behind this update is Google's broader strategy to combat automated SERP harvesting, particularly from AI crawlers and SEO scrapers that indiscriminately extract result URLs to build proprietary indexes. Plaintext links allowed scrapers to parse thousands of URLs directly from the HTML without further interaction with Google. The goto mechanism forces automated systems to make a subsequent request back to Google to ascertain the destination, which introduces latency and provides Google with a clearer signal regarding sequential link resolution. This makes naive SERP scraping more costly and less efficient.

Autom Team observed that while goto links initially appeared inconsistently across search results, they have become highly consistent for logged-out and private browsing sessions as of late August 2026. To address this change, the Autom Team updated its Google Search pipeline to effectively resolve these goto links by reading the Location header without following the redirect and returning the final destination URL within the standard API responses. This ensures that users calling Autom's Google Search endpoints receive usable destination URLs without requiring changes to their existing integration. This evolution underscores a trend where search engines are actively making it more complex for external systems to harvest link data while simultaneously optimizing the operational costs associated with such scraping activities.