What Changed in Google Search Results
The old wrapper was google.com/url?q= with the destination in plain sight. The replacement is google.com/goto?url= followed by a value beginning with CAES, an internal reference rather than an encoded address. Offline decoding does not work, and rebuilding a URL from the visible site name corrupts your data.
Rewritten links surfaced on 23 June 2026, and Brodie Clark recorded on 2 July that the wrapper answers with a 302. Search Engine Roundtable reported near-total coverage across residential IP providers in late August, and Google confirmed the change on 26 August as a measure against abuse, without naming scraping.
One detail matters more than the rest, and most coverage skips it. Not every client gets goto links. They appear reliably in incognito and inconsistently while signed in, and a measurement across roughly a thousand keywords found browser sessions returning clean hrefs for queries that came back wrapped through an API. Google decides per client, not per region, so wrapped links tell you how you have been classified.
How Much the Resolve Actually Costs
Derek Perkins of Nozzle put the cost at 500 to 1,000 requests for a five-page ranking. That is a ceiling, not an invoice. Most workloads need the first page or two, and the cite line still carries the domain, so domain-level tracking survives with no resolve. DataForSEO reported resolving 99.99 percent of organic results a day later, with AI Overviews accounting for most of the rest.
Also Read: How to Build a SERP Scraper That Scales
How to Resolve a goto URL
Do not follow the redirect and do not render anything. Request the goto URL with redirects disabled and read the Location header.
The status code is a trap. Google has been seen returning 402 and other non-3xx codes that still carry a valid Location, so gating on a 3xx range silently drops results. Treat the header's presence as the success condition. A 200 with no Location is usually a verification interstitial, and it will poison your dataset if you parse it.
Perkins reported that HEAD requests are refused and every write-up since has repeated it. Test that rather than assuming it, because one SERP API vendor publishes working HEAD examples using a Referer of the search page.
import requests
session = requests.Session()
session.proxies = {
"http": "http://user:pass@proxy-host:port",
"https": "http://user:pass@proxy-host:port",
}
session.headers.update({
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36",
"Referer": "https://www.google.com/search",
})
def resolve_goto(goto_url):
r = session.head(goto_url, allow_redirects=False, timeout=10)
location = r.headers.get("Location")
if location:
return location
r = session.get(goto_url, allow_redirects=False, timeout=10)
return r.headers.get("Location")Cheaper Reads Worth Trying First
Google still needs the real URL to render the page, so it stays in the markup. The destinations sit in a trailing data script feeding an internal store the SERP JavaScript reads. Parsing that payload skips the resolve for organic results. An Accept-Language that does not match the result language leaks a second copy, on the translate control Google then adds. Both are brittle, so keep the Location read as your fallback.
Also Read: How to Use Random User Agents for Web Scraping
Proxy Setup for the Resolve Hops
Resolve inside the session that fetched the results page. Same IP, same cookies, same User-Agent. A burst of requests to google.com from an address that never searched anything is the clearest bot signal you can send, so sticky sessions on residential proxies keep the sequence coherent. Leave datacenter proxies for the destination sites.
Rate limiting is the binding constraint, not bandwidth. Each resolve returns a few hundred bytes, so per-GB pricing barely registers it while per-request billing charges every hop. Pace resolves with jitter, cache every mapping since destinations repeat, and skip positions you were never going to report.
FAQ Section
What is a google.com/goto URL?
It is a passthrough link Google places on search results. The click lands on google.com/goto with an encoded parameter, and Google redirects to the real page. Searchers still see the destination domain under the result title.
Can I decode the url parameter offline?
No. The value is an internal reference, not a base64-encoded URL, so the only reliable way to learn the destination is to request it or parse it out of the page payload.
Does this affect rankings or organic traffic?
No. The redirect sits after ranking has already happened. Real visitors pass through the hop in a fraction of a second and land on your page as before.
Will my rank tracker break?
Most have already adapted. Expect fewer daily refreshes, higher prices, or shallower position coverage while providers absorb the cost.
Are datacenter proxies still usable for Google?
Rarely. Google was tough on datacenter ranges before this, and the resolve hops add more chances to get flagged. Residential IPs with sticky sessions are the safer default.
Final Thoughts
The goto wrapper turns one request per results page into dozens, but the encoded parameter is the only genuinely hard part. Read the Location header regardless of status code, try HEAD before paying for GET, parse the page payload when it is available, and keep every hop inside the session that fetched the SERP. Rate limits break this workload long before bandwidth does, which makes session quality worth more than raw request volume.
