Google finished rolling out a new google.com/goto redirect layer across search results by August 26, 2026, replacing direct destination links with encoded links that rank-tracking tools can't read without extra work. Semrush, Ahrefs, SISTRIX, AccuRanker, and SerpApi all had to rebuild how they resolve rankings. If your SEO reporting runs through any of those, the plumbing changed underneath you — even though the ranking numbers on your screen look exactly the same as last month.
What Did Google's /goto Redirect Actually Change?#
Between late June and August 26, 2026, Google swapped the plain URLs sitting under organic and paid results for google.com/goto links. Click one and you get a 302 redirect instead of a straight shot to the page — the real destination is packed inside as protocol-buffer ciphertext, not something you decode with a regex.
Nozzle's founder, Derek Perkins, worked out what that costs a rank tracker: 500 to 1,000 requests just to unwrap the links behind one five-page ranking, because Google also blocks the lightweight HEAD requests trackers used to rely on and now forces a full GET for each one.
Tools that had to adapt on short notice:
- Semrush, SISTRIX, AccuRanker — rank-tracking platforms
- Ahrefs, SerpApi, Nozzle — measurement and scraping infrastructure
- Places Scout, Serpdino — ranking report services
SerpApi says it shipped a working fix by September 5, returning direct destination URLs again without customers needing to change anything on their end.
Does This Change Your SEO Reporting?#
If someone else runs your rank tracking — an agency, or a tool you pay for monthly — this mostly isn't your problem to solve. By the dates above, most of the big names had already solved it.
Where it does matter: if anyone on your team built even a light scraper to check rankings — a script hitting Google directly, a spreadsheet macro, an automation workflow with a raw HTTP node — it started returning broken links sometime around late August and needed a rewrite.
My honest guess is a chunk of smaller SEO shops are still running on stale or broken link data right now and don't know it, because the ranking positions didn't move, only the URLs sitting underneath them.
Checking under 20 keywords by hand each week? This changes nothing for you. Running anything automated against Google's result pages? Go check it actually resolves to a real URL today, not a string that starts with google.com/goto.
The Honest Pros and Cons#
Google frames this as a deliberate move to stop scrapers and SERP APIs riding its results for free, not a bug — SerpApi's own writeup takes that framing at face value. Fair enough. It's their index to protect.
The downside lands on everyone who isn't Google. Rank-tracking tools now burn 500 to 1,000 times more requests to do the same job, which shows up somewhere — slower dashboards, tighter limits on lower-tier plans, or a price increase passed down later. Smaller tracking tools without SerpApi's engineering resources may stay broken longer.
My honest unknown here: nobody's published whether this request cost is temporary friction while providers catch up, or a permanent tax on rank tracking going forward. I wouldn't bet on it reversing.
How We're Handling It#
We build client SEO dashboards on API-based ranking data rather than scraping Google's result pages ourselves. That choice happened to insulate every WebEpex reporting setup from this specific break.
We checked our own automation workflows — built in n8n, the same tool we patched for a security advisory earlier this month — the week the rollout finished, and confirmed none of them touch raw SERP HTML directly.
One thing we did rebuild: a client-facing report for a GCC retail client that pulled a "top competing URL" field alongside position data. That field started showing /goto strings instead of real URLs the day the rollout completed. We swapped it to resolve through the ranking API's own destination field instead of trusting the raw link, tested it against three weeks of history, then pushed it live.
At WebEpex, we build SEO and AEO reporting for clients across the GCC, Europe, USA, Canada, and India on API-first infrastructure for exactly this reason. A change like this stays a one-line fix instead of a rebuilt scraper.
It's the same reasoning behind how we read Search Console's own AI-traffic reports: don't build load-bearing reporting on anything you don't control.
What I'd Tell a Client Asking About This#
Don't touch your SEO strategy over this — it doesn't move rankings, it changes what sits underneath them. Do ask whoever runs your rank tracking, in-house or agency, whether they've confirmed their reported URLs are real destinations again, not /goto strings.
If you built anything in-house that scrapes Google directly for ranking checks, budget a day to rebuild it against a proper ranking API instead of patching around Google's redirect format again next time it shifts — and it will likely shift again.
We flagged the same pattern when Google restructured EU search layouts days after this rollout finished: the plumbing under search results keeps moving, and anything built directly against Google's raw output inherits that risk. If a client report ever shows a raw google.com/goto link, that's your signal something upstream broke quietly.
If you want a second pair of eyes on whether your own SEO reporting is exposed to this, send me what's running under the hood and I'll tell you straight — takes two minutes, no pitch attached. [cal.com/webepex/growth-review]
