How to Handle Google's /goto Redirect in Your SERP Pipeline

The verdict in 30 seconds

Google confirmed on Aug 26, 2026 that search result links now route through google.com/goto?url=[encrypted token] before hitting the destination. Barry Schwartz reported it for Search Engine Roundtable and Search Engine Land, and a Google spokesperson confirmed the rollout as part of "a long history of deploying technical measures against evolving forms of abuse."

If your team extracts destination URLs from Google's search results (rank tracking, SERP scraping, AI data collection), one assumption just broke: the real URL is no longer visible in the link. It's encrypted into a token that a browser follows like a normal redirect.

The good news: this is fixable, and the fix is smaller than most people expect. The token can't be decrypted, but it can be resolved with one extra HTTP request, and it's deterministic, so you can cache it. This article walks through a 30-minute repair: detect the change, resolve it safely, and confirm your reports still show the right pages. If you don't scrape SERPs or track rankings against scraped URLs, skip ahead to "What the change does not affect" and carry on. Nothing changes on your site.

What exactly changed

For years, a Google search result carried the real destination in the link itself:

<a href="https://yoursite.com/landing-page?utm_...">...

Now the same result can carry a passthrough link:

<a href="https://www.google.com/goto?url=TtFp1Lc2026...*">...

Follow it, and Google returns an HTTP redirect that lands you on the destination. Two things matter about how it works:

• The token is encrypted and tamper-proof. Independent reverse engineering (published Aug 2026) shows a 1-byte marker, a 4-byte key identifier, and encrypted data in the Tink encryption format. Change one character and Google returns HTTP 400. You cannot forge a token or decode the URL without Google's keys.
• The token is deterministic. The same destination URL always produces the same token. That one detail makes the whole fix cheap: resolve once, cache by token.

Derek Perkins of Nozzle observed the change near a "100% rollout" across several residential IP providers, which is why it's more than an experiment this time.

What changed in the link itself: the destination moved into an encrypted token.

What survives the change

The ved parameter surviving is worth noting: position and click-type data that rank trackers used to read off result links is still there. Only the destination URL is hidden.

What the change does not affect

• Rankings and traffic. Google's ranking system has nothing to do with the links it renders.
• Google Search Console data. Positions, impressions, and clicks in GSC are from Google's internal data and are unaffected.
• Crawlers fetching your site. Googlebot, GPTBot, and every other bot that crawls your pages never touches google.com/goto. That only appears in links Google renders back to you.
• Bing and other engines. This is a Google-only change.

The only people who feel this are the ones whose pipelines read links out of Google SERPs. If that's you, you'll feel it; if it's not, this change is noise.

Check whether you're affected

Run these four checks. The first two take five minutes; the last two are a vendor conversation.

If every check is clean, nothing to do: bookmark this page and move on.

If you found a hit, the next four steps bring your pipeline back to accurate. Each step says what to do, what good output looks like, and how to recover if it doesn't happen.

The four steps that bring a tokenized SERP pipeline back to accurate.

Step 1: Detect tokens where they show up

Action. In your SERP extraction script, grab all result links and flag any that start with https://www.google.com/goto?url= (also match the bare /goto?url=, which appears on some surfaces, and the url= followed by a base64-looking payload). Log the flag rate per query. That number is your rollout indicator. Derek Perkins's observation aside, rollout is not uniform across IP ranges, so track it per provider, not just globally.

Expected output. A per-query goto_rate figure. 0% means your data source still returns direct links; 100% means you're fully tokenized.

Quality check. Fire the same query twice from two different IPs. If one is tokenized and the other is not, you have an IP-range split and both sides need handling.

Recovery. If your sample shows zero hits but you suspect tokenization, check whether your extraction is reading the JavaScript-rendered DOM rather than the raw HTML. Tokens can appear in the rendered markup even when the raw response keeps the old shape.

Step 2: Resolve the token with one redirect

Action. When a result carries a token, follow the link server-side with redirects disabled and read the Location header:

curl -sI "https://www.google.com/goto?url=TtFp1Lc..." | grep -i location

The response is an HTTP 3xx to the real destination. Keep that. Two rules make this cheap and safe:

• Cache by token, not by URL. Because tokenization is deterministic, one lookup per token is enough. Store token -> resolved_url and reuse it forever.
• Never crawl `google.com/goto` as a page. Google added Disallow: /goto? to its robots.txt in late July 2026. The URL is explicitly not meant to be fetched by crawlers; a working fetcher briefly follows the tokenized link and reads only the redirect chain. A broken one indexes or saves the goto URL itself, which pollutes your data. By late July, close to 3,750 such URLs were already indexed on google.com, Google's own site.

Cost check before you ship this: a first pass over a SERP with a couple hundred results means a couple hundred extra requests against google.com, which is exactly the kind of load Google's bot detection watches. The deterministic cache deflates that to one request per unique token, so do not skip it.

Expected output. A stable mapping table between token and destination. Spot-check 10 random tokens against a browser: every one should land on a sensible page.

Quality check. Confirm the token length is stable across different URLs and that identical destination URLs always produce identical tokens. If they stop matching, key rotation happened (see Step 5).

Recovery. If a token 400s, it was forged, truncated, or belongs to an expired session; re-pull the SERP and retry. Two failures in a row usually means your stored HTML is stale, not that the token is bad.

Step 3: Store the destination, not the passthrough

Action. The rest of your pipeline (keyword-to-page mapping, index checks, schema audits) has to see the destination URL. So after Step 2, keep three fields per result: resolved_url, token, and accessed_at. Drop the goto link from the URL column of any report; a google.com URL in your keyword report is a data-quality error twelve different ways.

If you can't add a resolver this week, the safe intermediate step is to omit the destination entirely rather than save the token: rank and position data stays meaningful; only the URL column goes blank. Tools that report "no URL" loudly are much easier to interpret than tools that report a token string as an actual URL.

Expected output. A report where 100% of rows show http(s) destination URLs from your own domains, zero google.com rows.

Quality check. Compare URL-level data against Search Console for 10 keywords. Rows should match. If Search Console gives you positions for a URL your report says "missing," your resolver or parser has a gap.

Recovery. If a small % of URLs still fail to resolve, log those tokens separately. Most failures trace back to the two culprits in Step 2: stale HTML, or a bot-detection wall on the follow-up request.

Step 4: Check what your vendor is doing

Action. If you rely on a rank-tracking tool or a SERP API (including ones built on scraped Google data), the rollout has been underway for weeks. Ask these five questions, and hold any report change against them:

Expected output. Either a confirmed fix or a clear-cut reason to move. Within 30 days you should be able to merge your report URLs with site-change records without noise.

Recovery path. No vendor improvement within a week: swap that data point to the Google Search Console API for positions, which comes straight from Google's own data and never sees a token. The cost is less link-level detail, which is fine if your decisions need accuracy more than they need third-party features.

Step 5: Watch the next moves

The mechanism doesn't sit still. Three things to monitor monthly:

1. Key rotation. The reverse-engineering sample found four key IDs in circulation with one dominant ("ee47aa4d", roughly 62% of tokens). If a fifth key appears and dominant-share patterns shift, expect cache invalidation: re-resolve tokens on a rotation.
2. Spread to other surfaces. Paid links and other result types were observed carrying /goto too. If your tooling touches ads or images, extend the Step 1 grep.
3. Hardening. This sits inside a longer sequence: mandatory JavaScript rendering (early 2025), SearchGuard rollout, the shutdown of &num=100 (Sept 2025), and a DMCA Section 1201 lawsuit against SerpApi (Dec 2025). Each is independently documented; the reverse-engineering write-up compiles most of them together. Expect the final URL to keep getting harder, not easier.

Verify the finished result

• [ ] Step 1 detector runs in CI or on your schedule and logs goto_rate per query
• [ ] All sampled tokens resolve to real destinations, spot-checked in a browser
• [ ] Zero google.com/goto URLs in your reports (grep your latest export)
• [ ] 10 keyword URLs match Search Console row for row
• [ ] Vendor confirmed resolution strategy, or the positions data is already on the GSC API
• [ ] Dedicated key-rotation check on your monthly cadence

FAQ

Does this affect my rankings or my traffic? No. The click path changes; the ranking system, the results, and what a searcher sees do not. Your organic performance is only at risk if a tool you run starts reporting wrong data.

Can the goto token be decoded? Not from the outside. It's a Tink-formatted encrypted payload, and mutating one character returns HTTP 400, so no forgery either. The usable path is to follow the redirect and read the Location header, the same thing your browser does.

Is it OK to follow `/goto` links with a scraper? Practically, following a tokenized link via redirect is what a browser click does, but Google has now disallowed /goto? in its own robots.txt and its terms limit automated access to search results. If you scrape SERPs, you're already on the wrong side of those terms; this rollout doesn't change that, it just makes it harder. Choose your compliance position before you build a resolver.

Do I need to change anything on my own website? No. The change is entirely in Google's rendered links. What you should check is every tool that reads SERPs on your behalf; that's in Step 4.

Author: Olivia Stone, SERP Intelligence Researcher Across 25k+ Queries at Auspia. Olivia writes about SERP analysis, ranking patterns, and how changes to search results affect ranking data.