A click on an organic Google result no longer leads straight to your page. Since 26 August 2026, when Google confirmed the rollout, every link in the results passes through google.com/goto?url= with an encoded token, and only then does Google’s server send the browser on to the real address. Nothing changes for the user, and nothing changes for rankings. What changes is what the tools that read results from HTML can see, and that is the only area where something needs checking. This article separates what Google confirmed from what the industry has filled in, and says exactly what to check in your analytics and in WordPress.
What Google confirmed, and what is guesswork
There is one confirmation and it is short. In its reply to Search Engine Land on 26 August 2026, Google wrote:
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 all. There is no documentation, no description of the token format, no referrer policy, no start date. The rest comes from observation, and it is worth knowing whose.
| what we know | source | status |
|---|---|---|
the link takes the form google.com/goto?url= with an encoded token | SEO observations since June 2026 | confirmed many times over |
| the server answers with a 302 redirect to the target address | tool observations | confirmed |
| the token cannot be decoded locally | Nozzle, SerpAPI | confirmed by attempts |
| rollout close to 100 percent on residential addresses | Derek Perkins, Nozzle | one company’s measurement |
| Search Console unchanged | Search Engine Land | a report, not a document |
| referrer policy | nobody | unknown |
The first reports date from 23 June (Alex Greenland) and 2 July (Brodie Clark), so two months passed between the first observation and the confirmation. Google called it an anti-abuse measure, and the context is plain: the company had earlier sued SerpAPI over scraping and lost the key DMCA claims. Since the court did not block the reading of results, the engineering did.
The mechanism, in three steps
Until 26 August, the link in an organic result was a plain <a href="https://yoursite.com/post/">. A tool that fetched the results HTML had the list of addresses and positions right away.
Now the href points at https://www.google.com/goto?url= followed by a string that looks like base64 but is not, in any publicly known form. The browser sends a request to that address, Google’s server answers with a 302 and a Location header pointing at the real page, and the browser follows. The user sees one click and one page. In the status bar before clicking, however, they see a Google address rather than yours, and that is the only difference visible to them.
This is not a new idea. Google Ads has routed ad clicks through its own intermediate address for years, and in organic results a similar /url?q= redirect appeared for logged-in users as early as around 2009, only with the target address written in plain text. The novelty is not the redirect, it is that the target address stopped being readable without making a request.
The referrer: why the apocalypse did not arrive in August, because it arrived in 2011
Most of the alarmist pieces are about the referrer and attribution. Two facts cool that down.
First, Google has not published a referrer policy for goto. Any article that states with certainty what you will see in Google Analytics is describing its own observations, not a rule.
Second, and more important: the data you would supposedly lose now, you lost long ago. In 2011 Google stopped passing the query in the referrer for logged-in users (the famous “not provided”), and over the following years extended that to all traffic. Since then the browser gets only the origin from Google, that is https://www.google.com/, with no path and no parameters. GA4, Matomo, Umami and Plausible have for years classified such a visit as google / organic purely on the basis of the domain. A redirect through google.com/goto does not change the domain.
Our own data adds nothing here, and we say so plainly: in Umami on wppoland.com we do not collect the referrer at all, the source field for us means the place on the page that fired the event, not where the user came from. We manage search traffic from Search Console, and according to Search Engine Land’s report, Search Console does not see goto redirects, because it counts clicks from its own logs, not from HTML.
What to check if you use GA4 or another referrer-based tool: compare the share of google / organic in the week of 8 to 17 August with the week of 22 to 31 August. If the share dropped while Search Console clicks in the same window held steady, some visits changed classification, and that is when it is worth digging further. If both charts move together, there is nothing to fix. For us, Search Console clicks in those two windows are 223 and 226, so nothing moved on Google’s side.
Rank tracking tools: this is where the real cost sits
A rank tracker that until now made one request per query and read a hundred addresses from the HTML today gets a hundred tokens. To find out who sits in position seven, it has to make a request to google.com/goto for the seventh token and read the Location header. For the whole first page plus the extra blocks, Nozzle prices this at 500 to 1000 requests per query.
There are three consequences, and each will show up in your reports in a different form.
The first is cost, which the tools will pass on either in pricing or in read frequency. A daily measurement may become a measurement every three days without any announcement, and the position chart will start to look like a staircase.
The second is gaps. Google rate-limits requests on residential addresses, so a tool that has to make a thousand requests instead of one will hit a block mid-read more often. In the report you will see results for positions 1 to 4 and no data beyond, or a “not found” for a page that has clicks in Search Console from the same day.
The third is volatility that is not ranking volatility. If a tool samples rather than measures, two consecutive reads of the same phrase can differ because the sample differed, not the SERP. The August waves of “unconfirmed volatility” that Barry Schwartz described on 1 to 3, 5 to 6 and 12 to 13 August fall exactly within the goto testing period. We are not claiming that is the only cause. We are claiming that a tool that changed its reading method during that period is not a reliable witness to ranking volatility.
A practical rule: since 26 August, Search Console is the only source that has not changed its method. If the rank tracker and Search Console disagree, Search Console is right and the tracker has a gap. Before reporting a ranking drop to a client, compare impressions and average position for the same page in Search Console for the same day.
What this changes in WordPress: nothing, with two exceptions
No theme file, no plugin and no server setting has any influence on how Google builds the link in its results. There is nothing to rebuild, no headers to add, nothing to “optimise for goto”. If someone is selling you such a service, they are selling air.
The two exceptions concern plugins that base their logic on the referrer.
The first is old plugins that display “the phrase the visitor came from” and highlight it in the content. They work on the q parameter from the referrer, which Google has not sent since 2011. They were dead before goto and they are dead after it. If you still have one active, remove it, because it burdens every request and delivers nothing.
The second is A/B and personalisation plugins that check whether the referrer contains google. in order to show a different variant of the page. They still receive the origin google.com, so the condition works, but after 26 August it is worth verifying live: open a result from Google in a private window and check in the server logs or in developer tools what Referer arrived. Five minutes, and the answer is hard evidence, not something from an article.
There is one more thing nobody writes about: caching and your own redirects. If your server has a rule that treats requests with an unusual referrer as suspicious (some hotlink protection setups and some rules in application firewalls), check that google.com with goto in the referrer path has not landed on a block list. It is rare, but the effect would be a 403 for users arriving from search, and Search Console would show such an error weeks late.
What we do not know and how to act anyway
We do not know the token format, nor whether Google intends to document it one day. We do not know whether the redirect will cover all countries and result types, or only the main organic links. We do not know the purpose beyond a general “against abuse”, although the chain of events around SerpAPI suggests an answer. And we do not know how browsers will behave in future versions, because the referrer policy for 302 redirects depends on them, not on Google.
The operational decision does not depend on any of these gaps. Rankings are the same as before 26 August. Search Console shows the same as before. The user lands where they landed before. The only thing that changed is the reliability of tools that read results from the outside, and that is where the burden of proof has to move: from the tracker to Search Console.
Three actions that close the topic:
- Compare in GA4 or your own tool the share of organic traffic from Google in the windows before and after 26 August. If it dropped and Search Console clicks did not, you have a classification problem to investigate. If it did not drop, the topic is closed.
- Check the dates and gaps in your rank tracker from 20 August onwards. Every client report from this period should carry a column with the Search Console position next to the tool’s position.
- Remove the plugins that rely on the phrase from the referrer, and verify live the ones that check the referrer domain.
Google took the map of the results away from the tools, not the traffic away from you. That is the difference between a change you have to react to and a change you have to know about. This one is the second kind.
