How to Handle a Client’s ‘GoTo Redirect’ Issue: A Freelancer’s Quick Fix Guide (Sept 2026)

Google has started routing some search result clicks through a Google-owned address, google.com/goto, before sending the visitor to the real page. Nothing about the destination changes. The visitor still lands on the client's site, on the same page, in the same time. What changes is what shows up on hover or in the page's source code: a Google address with an encoded hash instead of the clean destination URL.

Three things make this look alarming without an SEO background. The hover preview no longer shows their own URL. The destination sits behind a hash instead of readable text. And there is a brief extra step before the page loads. None of that is malware or a broken canonical tag, it just looks exactly like those problems from the outside.

The redirect itself is nothing new, the 302 status code it uses for "moved temporarily" has existed since HTTP/1.0 was first specified in 1996.

Skip the urge to change anything on the website itself. Pull baseline traffic from Google Search Console and Google Analytics from before the change spread widely, then compare organic sessions against the weeks after. If those numbers hold steady, the client's visibility is fine, only the raw link format changed. It is also worth a quick message to whichever rank tracking tool the client uses, since some tools are still adjusting to the new format, which can show up as a misleading dip in reported rankings even when actual visibility has not moved.

Do not add a redirect, touch the robots.txt file, or edit a canonical tag in response to this. The wrapper lives entirely on Google's servers, before the click ever reaches the client's site, so there is nothing on their end to fix. Site-side changes made for a problem that does not actually exist tend to create the very issues clients were originally worried about.