Google's /goto Redirect: What It Changes, and What It Does Not

Google now points the links on its search results pages at google.com/goto?url=[payload] and redirects the click on its own servers, instead of pointing them straight at the destination site. Google confirmed the rollout on 2026-08-26 with a short statement about abuse, and said almost nothing else. This piece is for anyone who buys rank-tracking data, reads a rank report they did not collect themselves, or has to answer "did something break?" for a nervous stakeholder.

It separates what Google confirmed, what one named practitioner observed, and what the industry has inferred on top of both. It does not settle the referrer and analytics question, because the only published answer is an undated vendor test, and saying so is more useful than guessing.

The short version

• The change sits in the measurement layer, not the ranking layer. There is nothing to fix on your site, and the useful response is a question for whoever sells you rank data, not an SEO task.
• Google now points result links at google.com/goto?url=[payload] and redirects the click server-side. The destination URL is still printed as text under the result title, so a searcher can still see where a link goes before clicking it.
• The cost lands on whoever collects results-page data at scale. The payload cannot be decoded, so a provider has to follow every redirect. That is a bill, not a bug.
• Google's statement names abuse and nothing more specific. The anti-scraping reading belongs to the industry, not to Google, and those two are worth keeping apart.
• Whether /goto changes the referrer your site receives is the question everyone asks, and the only published answer is one vendor's undated test. This piece says what that is worth, and gives you a procedure for checking your own property.

What is google.com/goto, and what does the URL look like?

A redirect that Google places between its results page and your site. Where a result link used to carry the destination URL in its href, it now carries a Google URL of the form https://www.google.com/goto?url=[payload]. The browser requests that URL, Google's server answers with a redirect, and the visitor lands on the destination. Both Search Engine Land and Search Engine Roundtable reported the format when Google confirmed the change, and Derek Perkins of the rank-tracking company Nozzle described the mechanism as a server-side redirect replacing client-side links.

Two details matter more than the shape itself.

The payload is opaque: the value after url= is not a readable encoded address. It is a blob. Perkins put the consequence bluntly: "The goto links can't be decoded, so providers will have to follow the redirect links." Ahrefs' own SERP data for an unrelated query on 2026-09-07 returned result rows whose URLs took the form https://www.google.com/goto?url=CAES…, which is consistent with an opaque payload rather than an encoded destination anyone can read off the page.

The destination is still visible: Search Engine Land reports that the destination URL is still displayed as text under the result title, even though the browser now shows a Google URL on the way through. A searcher can still tell where a link goes. What they cannot do any more is copy the real URL straight out of the link.

One caveat about that Ahrefs observation, because it is the sort of thing that gets repeated as a finding. In that single dataset the wrapping was not uniform across every row. We cannot separate "Google wraps some link types and not others" from "this vendor normalises some URLs and not others", and we have not confirmed either against a live results page, so neither reading belongs in an article. What does belong is the lesson: treat any tool's URL data as a rendering of the results page rather than the results page itself. That caution is, in a sense, the whole subject here.

When did this start, and how far has it rolled out?

Testing was first observed in July 2026, and Google confirmed the rollout on 2026-08-26. Google has published no completion date, and there is no official documentation describing the change at all.

Date	What happened	Source	Confirmed by Google?
2025-12-19	Google announces a lawsuit against the scraping company SerpApi for "circumventing security measures protecting others' copyrighted content that appears in Google search results"	Google's own blog, written by Halimah DeLaine Prado, General Counsel	Yes, Google's own announcement
July 2026	The redirect is observed in testing on live results pages	Search Engine Roundtable	No
2026-08-26	Google confirms the rollout with a one-sentence statement about abuse	Search Engine Land and Search Engine Roundtable, reporting the same statement	Yes, statement only
2026-08-27	A rank-tracking vendor publishes countermeasures and a list of what breaks without them	DemandSphere, a company that sells rank tracking	No
Late August 2026	"nearly a 100% rollout across several residential ip providers"	Derek Perkins of Nozzle, via X, quoted by Search Engine Roundtable	No
2026-09-07	Goto-wrapped result URLs present in Ahrefs SERP data for an unrelated query	Ahrefs SERP data, dated observation	No

Read Perkins' figure with its scope attached. He described near-total coverage across several residential IP providers, which is what one practitioner could see from the vantage points he was testing from. It is not a published global completion figure, and nobody has produced one.

Why is Google doing this, and what did it actually say?

Here is Google's statement in full, quoted identically by both publications that broke the story: "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."

That is the entire official position. It names abuse. It does not name scrapers, SERP APIs, AI companies, or rank trackers, and no spokesperson was named in either report. Everything past that sentence is inference. With a story like this one, the useful move is to keep the layers apart rather than blend them into a single confident paragraph.

Our analysis suggests the cleanest way to hold it is a ledger.

Claim	Status	Who said it	What would change the verdict
The rollout is real and deliberate	Confirmed by Google	An unnamed Google spokesperson, quoted identically by Search Engine Land and Search Engine Roundtable on 2026-08-26	A reversal or a retraction
Links take the form google.com/goto?url=[payload] and the hop is server-side	Observed and attributed	Both publications; Perkins described the server-side mechanism	Google documenting the format, or the format changing
The destination URL is still printed as text under the result title	Observed and attributed	Search Engine Land	A change to how results are rendered
The payload cannot be decoded, so a provider must follow each redirect	Observed and attributed	Derek Perkins of Nozzle, via X	Anyone publishing a working decode, or Google documenting the encoding
The purpose is to stop scraping by SERP APIs and AI companies	Inferred by the industry	Barry Schwartz, most explicitly in Search Engine Roundtable, and Perkins. Google's statement says "abuse" and names nobody	Google naming a target, or a court filing that does
Search Console data is not affected	Observed and attributed, as a publication's read rather than a Google statement	Search Engine Land	A Google statement in either direction
Rankings, indexing and crawling are unchanged	Not established as a Google statement, and unreported as a problem	None of the reporting describes any ranking, indexing or traffic effect	A reproducible report tying a ranking or indexing change to the redirect
The referrer a destination site receives, or GA4 channel attribution for Google organic, has changed	Not established	Google has published nothing, and neither publication addresses referrers, analytics or GA4 at all. One vendor, Attributer, reports the referrer arriving intact, but its test is undated and validated with its own product	Google documenting its referrer policy for the hop, or a dated, reproducible measurement
The rollout is complete	Not established	Perkins reported near-total coverage across several residential IP providers, which is his scope and not a global figure	Google publishing a completion note

The inference in row five is reasonable, and it is worth saying why rather than only labelling it. On 2025-12-19, Google's General Counsel, Halimah DeLaine Prado, announced a lawsuit against SerpApi for "circumventing security measures protecting others' copyrighted content that appears in Google search results", describing tactics that included "cloaking themselves, bombarding websites with massive networks of bots and giving their crawlers fake and constantly changing names". Eight months later Google deployed a technical measure that makes result links expensive to collect, and cited "evolving forms of abuse" when asked about it. Both events are documented and dated, and reading them as part of one enforcement arc is a fair inference. It is still an inference, and it is not the same thing as Google naming a target.

Does /goto change your rankings or indexing?

No, and nobody has reported otherwise. Crawling, indexing and serving results are three separate stages in Google's own account of how Search works, and not one of them touches the href attribute Google writes into a rendered results page. The redirect changes how a click is handed off after ranking has already happened.

The question keeps coming up anyway, and the reason is worth naming: a visible change inside Google's own markup looks like a change to Google's ranking systems. It is not one. Neither publication that broke the story describes any ranking, indexing, crawl or traffic effect, and no such figure exists to quote. If your rankings moved in late August, this is not the explanation.

Does it change your referrer data or your analytics?

Nothing establishes that it does, and nothing establishes that it does not. That is the honest answer, and the thinness of the record deserves spelling out.

Across the sources we reviewed, Google has published no documentation on this change at all, let alone on what referrer the hop passes through. Its documentation on how Search works does not describe how result links are constructed or what referrer they carry. Neither Search Engine Land nor Search Engine Roundtable mentions referrers, analytics or GA4 anywhere in its report. There is no Google statement, and no dated, reproducible measurement in either direction.

One vendor has published an answer. Attributer, which sells attribution software, reports that it tested Google result clicks across ten device and browser combinations and saw the referrer arrive intact every time, leaving the visit classified as organic search. Take it for exactly what it is: the post carries no test dates, shows no raw headers, and validates the result with the author's own product, which makes it one company's experience report rather than a measurement anyone can reproduce from what is published. It is the closest thing to an answer on the record, and it is not enough to move the row out of the not-established column.

The mechanism does not settle the question either, and it is worth being precise about why. The referrer a destination receives starts from the referrer policy of the page that began the navigation, and a policy of origin, for example, sends only the origin, so a destination sees https://www.google.com/ and never the query. A redirect in the middle is not neutral, though: the redirect response can carry its own Referrer-Policy header, and that policy governs the request which actually reaches your site. Google has published neither the policy on its results page nor the headers on the /goto hop, so the mechanism narrows the possibilities without answering them.

Three things are worth holding onto while the record stays thin.

• Referrer loss is not new: traffic from inside a platform's own app often arrives with no referrer at all, which is one reason a referral number can be understated. Our guide to where website traffic actually comes from covers how that distorts the picture, and it is the right frame for reading any wobble you see now.
• Search Console is first-party: it counts clicks on the results page rather than inferring a source from a header, which is why Search Console reports data straight from Google instead of estimating it. That makes it the control in any test you run.
• GA4 and Search Console were never counting the same thing: the gap between them predates this change by years. If you are not already clear on how GA4 and Search Console split the organic picture, a referrer investigation will hand you a confusing answer.

How do you check your own analytics for a referrer change?

Run it as a before-and-after against a fixed date, weekly rather than aggregated, with Search Console as the control. Five steps.

1. Set the window: four weeks before 2026-08-26 and four weeks after, kept as separate weeks. An aggregated eight-week total hides exactly the shift you are looking for.
2. Pull session source and medium in GA4: filter to your top landing pages and record two series per week, sessions attributed to google / organic and sessions attributed to (direct) / (none).
3. Watch the ratio, not the totals: a referrer problem shows up as organic sessions moving into Direct while the sum stays roughly flat. A real traffic change moves the sum.
4. Cross-check against Search Console clicks: same pages, same weeks. If Search Console clicks hold steady while GA4 organic sessions fall and Direct rises, you are looking at a measurement change. If both fall together, you are looking at a traffic change, and the redirect is not the suspect.
5. Read your raw logs if you have them: server or CDN logs carry the actual Referer header for those landing pages. That is the only place you see the real value rather than a tool's interpretation of it.

When not to trust the result: seasonality, a consent-mode change, a tagging change, a bot-filtering change or a GA4 release can each move that ratio on their own. One week's wobble proves nothing, and one site's data cannot tell you whether anything changed globally. If you do find a clean, repeatable shift dated to the rollout, publish it with the dates and the method attached. That is the report the industry is currently missing.

What changes for rank trackers and SERP APIs?

The economics, mainly. If the payload cannot be decoded, a data provider cannot read the destination off the results page any more; it has to issue a request and follow the redirect for every link it wants to resolve. A results page carries a lot of links, and a tracker runs a lot of results pages. That is a real increase in requests, latency and cost, and it is the same structural fragility that shapes how AI visibility tools actually reach each engine. The access route belongs to the platform, and the platform can change it without notice.

DemandSphere, a company that sells rank tracking and therefore has a commercial interest in the answer, published the most concrete account of what goes wrong without countermeasures. In their description, destination URLs all resolve to google.com, domain matching fails so a client's own pages stop being recognised as theirs, share of voice and competitor attribution get calculated against the wrong domains, and historical series break on the rollout date. They also state that once their countermeasures are in place, "Ranking data for organic is unaffected".

Take both halves of that. The failure modes are specific and plausible. The reassurance is a vendor's own statement about its own product, which is not an audit. No rank tracker should be called broken on the strength of a competitor's blog post, and none is called that here.

The metric with the most exposure is the one with no first-party substitute. Your own positions can be sanity-checked against Search Console; your competitors' positions cannot, which is why share of voice depends on a rank tracker for its denominator. If domain attribution quietly resolved to google.com for part of a period, a share-of-voice trend line would shift without either competitor changing anything at all.

What should you ask the vendor you buy rank data from?

This is where the change actually costs you something, and it costs an email rather than a project. Our recommendation is to send these six questions to any provider whose numbers reach a board deck or a client report, and to keep the answers on file.

• Collection method: has the way you collect results-page data changed since 2026-08-26, and if so, what changed?
• Historical continuity: did any series break, get backfilled, get restated or get interpolated around that date? If so, which metrics and which dates?
• Domain attribution: are competitor and client URLs still resolving to publisher domains rather than to google.com, in every report type, including SERP features and sitelinks?
• Resolution method: are you following each redirect to its destination, or inferring the destination from the URL text displayed under the result?
• Exposure: if Google hardens this further, what breaks first, and what is the fallback?
• Notification: will you tell your customers in writing when your collection method changes, and does the contract say so?

The last question is the one people skip and the one that pays. A rank number is not a measurement of your site. It is a vendor's reconstruction of a page Google rendered somewhere else, for somebody else's browser. Buying that without the collection method in the contract is buying an output with no stated method.

What should you do, and what should you not panic about?

Do: Nothing to your website. Run the referrer check above on your own property for the rollout window. Send the vendor questions and file the answers. Keep Search Console as the first-party record of how Google handled your pages. Add a note to your reporting documentation that a collection-method change happened in late August 2026, so whoever reads the trend line in six months knows a discontinuity is possible.

Do not: Change your URLs, your redirects, your internal links or your markup because of this. Nothing on your site participates in the mechanism. Do not trace a ranking drop back to the redirect, and do not accept a rank report from anyone who cannot say how it was collected. Do not repeat "Google confirmed it is targeting scrapers", because Google confirmed a rollout and offered a sentence about abuse, and that is all it did.

The temptation with a story like this is to manufacture an action item. There is not one, and inventing one is how this kind of article does damage.

What is still unknown?

Four things, and they are not equally answerable.

• Whether the rollout is complete: answerable by observation, and the industry will settle it soon enough. Google has published nothing.
• Whether referrer and analytics behaviour changed: answerable by measurement, by anyone with server logs and a dated window. Answered so far only by one undated vendor test, which is not the same as answered.
• Whether Google will harden this further: not answerable. Speculating about it is not analysis.
• Whether pipelines that depend on Google-derived data are affected downstream: partly answerable, and worth asking about any product whose numbers ultimately come from a Google results page. Nothing establishes an effect on any named AI answer engine, and this article does not claim one.

When a whole category of question keeps landing in the "not established" column, the response is to stop asking the internet and start asking your vendor.

The habit worth building out of this is smaller than the news itself: ask every number about Google where it came from. First-party or reconstructed. Measured or modelled. Collected how, and when did that method last change. Most SEO reporting mixes those freely, and a change like /goto only hurts the teams that never separated them.

This week, take the single rank number that carries the most weight in your reporting, find out how it is collected, and write the answer down next to it. Our SEO analytics and reporting work starts in the same place, because a metric nobody can trace is a metric nobody should act on.