Google now wraps many organic results in google.com/goto?url=CAES... redirects, so a rank tracker that matches your domain against each result's URL stops finding you past the first few positions. The fix: detect goto links, send a plain GET to each one without following redirects, read the real URL from the Location header, and do it immediately after fetching the SERP.

Our own rank checker started under-reporting at around 01:30 UTC on 30 October 2026. Nothing crashed. No errors were logged. Domains we knew ranked on page one simply stopped showing up, and that kind of silent failure is the worst kind for anything that feeds a report.

Instead of linking straight to the destination page, some organic results now point to https://www.google.com/goto?url= followed by an opaque encoded token. The real URL is not in the link at all. In our live test, positions 1–5 still had real URLs, and positions 6–10 were all goto redirects.

This is not a glitch. Google began testing the passthrough format in mid-2026 and confirmed the rollout to Search Engine Roundtable, describing it as part of "a long history of deploying technical measures against evolving forms of abuse." The day it reached the queries we track is simply the day our numbers fell off.

The token looks like an encoded blob (it starts with CAES), not a readable query parameter. Nothing in the link tells you which domain it points to.

Why does this silently break rank tracking?

Most rank checkers do one thing per result: pull the hostname out of the link and compare it with the target domain. When the link is a goto redirect, every hostname is www.google.com, so the match fails and the tracker reports "not ranking." It doesn't raise an error, because from the code's point of view nothing failed.

That's why it's dangerous. A tracker that crashes gets fixed the same day. A tracker that quietly says a client dropped from position 6 to "not in top 10" gets turned into a client report, a strategy discussion, maybe a panicked content rewrite, all based on a parsing bug.

Anything downstream of SERP links has the same problem: competitor monitoring, backlink prospecting, SERP-feature analysis, and any LLM pipeline that grounds answers on scraped search results. If your system reads link and assumes it's the destination, it's affected.

Request the goto URL with a plain HTTP GET and turn redirect-following off. Google answers with a 302 and puts the real destination in the Location header. In our tests this worked with curl, without JavaScript or special headers, using both the default user agent and a browser user agent.

One of our test tokens returned location: https://www.instagram.com/ironmind.ai/, exactly the result the SERP was showing at that position. Use GET, not HEAD: rank-tracking vendors report that Google refuses HEAD requests on these links, so a GET that stops at the first hop is the workable approach.

The resolver we added to our rank checker, simplified:

import requests

GOTO_MARKER = "google.com/goto"
REDIRECT_CODES = {301, 302, 303, 307, 308}

def resolve_goto_links(results, timeout=5):
    """Call this immediately after fetching the SERP.
    Goto tokens are probably short-lived, so don't queue this for later."""
    for result in results:
        link = result.get("link", "")
        if GOTO_MARKER not in link:
            continue  # already a real URL, leave it alone
        try:
            resp = requests.get(link, allow_redirects=False, timeout=timeout)
            location = resp.headers.get("Location")
            if resp.status_code in REDIRECT_CODES and location:
                result["link"] = location
            else:
                result["goto_unresolved"] = True
        except requests.RequestException:
            result["goto_unresolved"] = True  # keep the original link
    return results

Three details matter here. It only touches links containing the goto marker, so results that are already clean cost nothing. It uses allow_redirects=False, so the only request goes to Google and the destination site is never contacted. And on any failure it keeps the original link and flags it, so a timeout doesn't crash the run or silently drop the result.

Why stop at the first redirect instead of following it?

The Location header on Google's 302 holds the URL Google is actually ranking, and that's what a rank tracker needs. Following the whole redirect chain adds a request to every destination site, slows each lookup, and can return a different URL after the site's own redirects. That URL is not the one Google indexed.

We chose single-hop resolution over full redirect-following for that reason. If a client's listing is http://example.com/pricing and the site redirects to https://www.example.com/pricing/, the second URL is a fact about their server, not about their ranking. Mixing the two makes historical rank data harder to compare.

We also decided not to try decoding the CAES... token locally. It's an undocumented internal format, rank-tracking vendors say it can't be decoded, and a parser built on a reverse-engineered Google encoding is just the next silent break waiting to happen. The 302 is the one interface Google has to keep working, because real browsers depend on it.

Resolve them immediately after fetching the SERP, in the same job. We didn't measure how long a goto token stays valid, but there are signs it's tracked and probably short-lived, so a link resolved hours later may fail or point somewhere unexpected. Never store raw goto links and resolve them in a later batch.

The evidence is circumstantial. Each redirect response also sets a __Secure-ENID cookie, which suggests Google is tracking the hop like a real click, not just serving a static redirect. Tokens built for click attribution are usually single-use or time-boxed. We haven't confirmed either, so we built for the pessimistic case.

The practical rule: fetch the SERP, resolve, then persist. The value you store is the resolved URL plus a flag for anything that didn't resolve. Unresolved results should show up in your reporting as "unknown," never as "not ranking."

Does this fix hold up at scale?

We don't know yet, and anyone who says they do should show their numbers. We verified the technique on a handful of requests. At volume you're sending Google one extra request per goto link, and we'd expect a single IP to start hitting captchas or HTTP 429s fairly quickly. Rotating or residential proxies are the sensible plan.

The multiplication is real. In our test, five of ten page-one results needed resolving, so each query cost roughly six requests instead of one. If you track deeper pages or parse every link on the page (sitelinks, People Also Ask, local packs), it grows fast. One rank-tracking vendor estimates 500 to 1,000 requests to fully resolve a five-page ranking.

So budget for it. Resolve only what you actually match against, which for most trackers means organic results only. Treat rate-limit responses as "unresolved, retry within the same job," not as hard failures, and decide in advance what level of unresolved results makes a run untrustworthy.

Did the fix actually work?

Yes, at the scale we tested. After patching our rank checker with the resolver above, domains that appeared only at positions 6 and 8 were correctly found and reported at the right positions. Before the patch, the same queries reported those domains as not ranking at all, with no error and no warning.

The bigger lesson was the monitoring gap, not the parsing. Our checker had no way to notice that every result past position 5 now shared one hostname. We've since added a sanity check: if a large share of results on a page resolve to google.com, the run is flagged instead of reported. That check would have caught this within minutes.

This is the same pattern we wrote about in why you shouldn't trust API docs and should trust shipping code instead. When you depend on a third party's output format, the format is the contract, and nobody tells you when it changes. Your system has to notice on its own. If your rank data feeds into keyword strategy, as it does in how we built a genetic algorithm for SEO keyword research, one bad parse spreads into every decision downstream.

What is the complete fix at a glance?

Detect any result link containing google.com/goto. Send a plain GET with redirects disabled. Replace the link with the Location header from the 302. Do it right after the SERP fetch, keep the original and flag it on failure, and alert when results collapse onto Google's own hostname.

The goto rollout is a format change, not a ranking change. Positions haven't moved, but any tracker that hasn't adapted is now reporting a fiction past the first few results. The resolution step is about a dozen lines of code. The part that actually protects you is monitoring that notices when a dependency changes shape under you, because the next change won't come with an announcement either.