Google /goto Links Broke SERP APIs Again on October 30, 2026: What Happened

TL;DR

• What happened: On the evening of October 29 (New York time), Google stopped letting scrapers resolve all of its google.com/goto result links right away. Serper now resolves only the first three organic URLs per search and returns results 4 to 10 as raw /goto links that it says become resolvable about 30 seconds later. SerpApi reopened and prioritized its unresolved-link issue the same day.
• Why it matters: A /goto link hides the real destination. If your app filters by domain, cites sources, or scrapes the result pages, a wrapped link breaks all three.
• How we got here: Google required JavaScript for Search in January 2025, killed &num=100 in September 2025, started testing /goto in July 2026, confirmed it on August 26, 2026, and tightened it on October 30.
• What to do: Check your search results for google.com/goto and google.com/url links before anything downstream touches them. If you'd rather not deal with any of this, the Context.dev web search API returns real destination URLs. In our own test on October 30, 20 searches came back with 199 results and zero Google redirect links, and pricing goes as low as $0.38 per 1,000 searches.

What happened on October 30, 2026

Google made its /goto redirects harder to resolve in bulk, and two of the best-known SERP APIs started returning wrapped links in production within hours of each other.

Serper opened an incident at 01:30 UTC on October 30 (9:30 p.m. on October 29 in New York). Its updates describe the new behavior it is working around:

• Serper's API resolves the first three organic result URLs.
• Results 4 to 10 come back as google.com/goto links.
• Serper says those remaining links become resolvable roughly 30 seconds after the search.
• It shipped a new /resolve endpoint so customers can turn the wrapped links into destinations later.
• Resolving the first three adds latency, and you can skip it with resolveLinks: false.

Serper marked the incident resolved at 09:43 UTC, but "resolved" here means "we shipped new handling." It does not mean ten clean destination URLs per search came back. The three-link cutoff is Serper's choice, and the 30-second delay is what Serper observed. Google has not published either number.

SerpApi tells a similar story from a different angle. Its public issue #4315, opened on September 18 for unresolved links in organic_results[].link, had gone quiet. On October 14, staff could not reproduce the problem across roughly 400 searches and 3,000+ links. On October 28, they saw it once in 100 searches. On October 30, one customer's affected search reproduced consistently with "significant production impact," another reproduction followed on different queries, and the issue moved to open and prioritized with a fix in progress.

So the short version: a problem the industry thought it had solved in early September came back, at least for some providers, at least for some queries, on October 30.

Serper incident timeline

Event	UTC	New York (EDT)
Incident created	October 30, 01:30	October 29, 9:30 p.m.
Intermediate update	October 30, 03:08	October 29, 11:08 p.m.
Marked resolved	October 30, 09:43	October 30, 5:43 a.m.

What is a google.com/goto link?

A google.com/goto link is a redirect that Google puts in place of the real destination URL on a search result. Instead of linking straight to https://example.com/page, the result's href looks like this:

https://www.google.com/goto?url=CAES...

When a person clicks it, Google sends a redirect and the browser lands on the site. Nothing looks different. For a program reading the results page, though, the destination is gone. The grey breadcrumb under each title still shows a shortened domain and path, but that is display text, often cut off with "...", and you can't follow it.

This is different from the older google.com/url?q= wrapper. That one carried the destination in plain sight as a query parameter, so you could read it without making a request. Autom.dev draws the same distinction: /url?q= is readable, /goto is opaque.

Can you decode a /goto token?

No. ScrapingBee's tests from September 7 found that the CAES... value is Base64URL-decodable into a protobuf envelope, but the destination inside is protected. Parsing the token doesn't reveal the URL. The only reliable way to get the destination is to ask Google for it.

In those September tests, a GET with redirects turned off returned a 302 with the destination in the Location header, while HEAD did not. Tokens could be reused, worked across connections, and still resolved days later. Resolving 50 links took a median of about 3.27 seconds one at a time, or 1.23 seconds with five workers.

Those findings are from before October 30. The GET and Location approach is still how you resolve a link, but you can no longer assume every link will resolve the moment you get it.

Why /goto links break SERP scrapers and AI agents

Every wrapped link adds work between "I have search results" and "I can use search results." That extra step shows up in four places.

Latency. Each /goto link needs its own HTTP round trip to Google before you know where it points. Ten results can mean ten extra requests. If some of them now need to wait around 30 seconds, an agent that expected a sub-second search call is suddenly waiting half a minute.

Domain filtering. If you only want results from docs.python.org, or you want to exclude Pinterest, you need the destination host. A /goto link's host is google.com, so include and exclude lists quietly stop working.

Citations. AI answers that cite sources need real URLs. An agent that cites google.com/goto?url=CAES... gives the reader a link that may not resolve tomorrow and tells them nothing about the source.

Downstream scraping. Most search pipelines scrape the result pages next. Passing a /goto link to a scraper means the scraper follows Google's redirect, which is another request to Google from your infrastructure, and one that can fail for the same reasons the original resolution did.

There is also a quieter problem. A 200 OK from a SERP endpoint doesn't mean the results are right. SEOmonitor reports that about 8% of the results Google returns to its collection system each day are degraded and need checks and retries, and that incorrect results reached its platform between October 9 and 13, affecting roughly 10% of tracked keywords. RESONEO's BotGuard tests found the same query from the same IP can return different results depending on browser automation signals and session state. Neither proves Google is deliberately poisoning results, but both say the same thing: check the content, not just the status code.

A history of Google's anti-scraping changes, from JavaScript to /goto

The October 30 change is the latest step in a run of changes that have made Google results more expensive to collect programmatically. Here is the full timeline.

Date	What changed	Source
Years before 2025	Result links wrapped in google.com/url?q=, with the destination readable in the URL	Autom.dev
January 17, 2025	Google starts requiring JavaScript to use Search	TechCrunch
Around September 10, 2025	Google disables the &num=100 parameter, capping pages at 10 results	Search Engine Land
July 2026	Early tests of google.com/goto result links spotted	Search Engine Roundtable
August 26, 2026	A Google spokesperson confirms the /goto rollout as protection against abuse	Search Engine Land
August 27, 2026	DemandSphere ships countermeasures for organic results and starts on SERP features	DemandSphere
August 30, 2026	SerpApi posts that result links are affected and remediation is underway	SerpApi
September 5 to 6, 2026	SerpApi announces direct destination URLs are restored	SerpApi
September 7, 2026	ScrapingBee publishes token and redirect tests	ScrapingBee
September 7 to 13, 2026	SerpApi fixes relative /goto links that had no domain	SerpApi changelog
September 18, 2026	SerpApi opens issue #4315 for intermittent unresolved links	GitHub
October 9 to 13, 2026	SEOmonitor reports incorrect results reaching its platform	SEOmonitor
October 28 to 30, 2026	SerpApi sees renewed failures and escalates the issue	GitHub
October 30, 2026	Serper reports immediate-resolution limits and ships new handling	Serper

January 2025: JavaScript becomes mandatory

On January 17, 2025, Google began requiring JavaScript for Search. Plain HTTP clients that fetched the results page and parsed the HTML stopped getting results. Tools either moved to headless browsers or found other routes in, and the cost per search went up.

September 2025: the end of &num=100

For years, adding &num=100 to a Google search URL returned the top 100 results on one page. Around September 10, 2025, Google switched it off. Getting the top 100 now meant ten requests instead of one. Rank trackers that stopped after the first page or two to save money started reporting pages at position 45 as "not ranking," and Search Console impression counts shifted for many sites. Search Engine Land's analysis found 77% of sites lost keyword visibility after the change.

July to August 2026: /goto arrives

Search Engine Roundtable spotted /goto links in testing in July. On August 26, Google confirmed the rollout and described it as a technical measure against abuse. Growtika checked 493 links across eight searches, including organic results, videos, AI Overview sources, People Also Ask, and ads, and every one hid its destination.

September 2026: providers declare victory

SERP providers moved fast. DemandSphere had organic countermeasures out by August 27. SerpApi posted a notice on August 30 and announced the fix around September 5. The standard approach was simple: request each /goto link without following redirects and read the Location header. For organic results, the problem looked solved.

October 2026: it comes back

It didn't stay solved. SerpApi's issue #4315 picked up sporadic reports through September and October. SEOmonitor and RESONEO published broader evidence that automated collection was getting degraded or inconsistent results. Then on October 30, Google started limiting how many /goto links can be resolved right after a search, and Serper and SerpApi both reported production impact the same day.

The pattern across all of these changes is the same. Each one keeps search working for people while making it slower or more expensive for machines.

What we don't know yet

A lot of the October 30 coverage blurs what's confirmed and what's guessed. Here is where things stand.

Claim	Status
Google rolled out /goto redirects on search results	Confirmed by Google and observed by many providers
/goto adds a request before you have the destination	Confirmed by published tests
Only three links per search can be resolved immediately	Serper's handling choice, not a published Google limit
The remaining links resolve after about 30 seconds	Serper's observation, not a published Google limit
Every SERP provider is affected the same way	Not established
Google has published the new thresholds or detection logic	No such document found
A successful API response means accurate results	Not true. See SEOmonitor and RESONEO above

If you depend on a SERP provider, check its status page and issue tracker yourself rather than relying on a summary, including this one. These pages change quickly.

How to check whether your search API is returning /goto links

Run a quick audit before this breaks something in production.

1. Count wrapped links. For a sample of searches, count how many result URLs have a google.com host with a /goto or /url path.
2. Check by position. Given Serper's three-link handling, compare positions 1 to 3 with 4 to 10. A spike from position 4 on is a strong signal.
3. Measure time to usable URLs. Track p50 and p95 latency from the search call to the moment every URL you need is a real destination, not just the search call itself.
4. Count extra requests. Log how many resolution requests and retries each search triggers.
5. Test the downstream path. Make sure domain filters, citation rendering, and page scraping all handle an unresolved link without crashing or silently dropping it.
6. Spot-check the content. A clean URL list can still be wrong. Compare a handful of results against a manual search.

Here is a small Python check against the Context.dev search endpoint. Swap in your own provider's call to run the same test on it.

import os
from urllib.parse import urlparse
 
import requests
 
api_key = os.environ["CONTEXT_DEV_API_KEY"]
 
response = requests.post(
    "https://api.context.dev/v1/web/search",
    headers={
        "Authorization": f"Bearer {api_key}",
        "Content-Type": "application/json",
    },
    json={"query": "google goto redirect links", "numResults": 10},
    timeout=90,
)
response.raise_for_status()
 
GOOGLE_REDIRECT_PATHS = ("/goto", "/url")
 
def is_google_redirect(url: str) -> bool:
    parsed = urlparse(url)
    host = parsed.hostname or ""
    is_google_host = host == "google.com" or host.endswith(".google.com")
    return is_google_host and parsed.path.startswith(GOOGLE_REDIRECT_PATHS)
 
results = response.json()["results"]
unresolved = [r["url"] for r in results if is_google_redirect(r["url"])]
 
for result in results:
    print(result["title"], result["url"])
print(f"{len(results)} results, {len(unresolved)} Google redirect links")

If you are resolving links yourself, keep the request a GET with redirects turned off and read the Location header. Treat a missing Location or a non-3xx response as unresolved rather than passing the /goto URL along, and plan for retries now that immediate resolution isn't guaranteed.

Need a reliable web search API? Use Context.dev

If you'd rather not build and babysit link resolution, retries, and validation for a search provider, use the Context.dev web search API. Results come back with real destination URLs, so you can filter, cite, and scrape without a second step.

We tested this on October 30, 2026, the day of the change. We ran 20 different queries (shopping, how-to, news, developer docs, finance, travel) with 10 results each, five at a time from a single machine. All 20 searches succeeded and returned 199 results between them. None of the 199 URLs was a google.com/goto or google.com/url link. Median response time was 1.44 seconds and the slowest search took 6.9 seconds. That's a small self-run test, not a benchmark, so run the script above with your own queries.

What else you get in the same call:

• Full page content. Turn on markdownOptions to get each result scraped to Markdown in one request, so your agent doesn't need a separate scrape step.
• Highlights. highlightsOptions returns the passages from each result that match your query.
• Real domain filters. includeDomains and excludeDomains work on destination hosts, and Google-style operators like site: and intitle: work in the query.
• Freshness and locale. Limit results to the last day, week, month, or year, and set country and languages.
• MCP. The same search is available as the web-search tool on our hosted MCP server for Claude, Cursor, and other agents.

A search with 10 results costs 1 credit, and Markdown adds 1 credit per result page. At volume, that works out to as low as $0.38 per 1,000 searches. You can start for free, and pricing has the full breakdown.

If you're comparing options, our roundup of web search APIs and MCP tools for AI agents covers the wider field, and our web search MCP comparison covers Cursor and Claude setups.

FAQs

What is google.com/goto?

It's a redirect URL Google puts on search result links in place of the real destination. Clicking it takes you to the site as usual, but the destination is encoded in an opaque CAES... token, so a program reading the results page can't see where the link goes without asking Google.

When did Google start using /goto links?

Search Engine Roundtable spotted them in testing in July 2026, and Google confirmed the rollout to Search Engine Land on August 26, 2026. On October 30, 2026, Google added limits on how quickly scrapers can resolve them.

What changed on October 30, 2026?

Google began limiting how many /goto links can be resolved immediately after a search. Serper responded by resolving only the top three organic results and returning the rest as /goto links that it says resolve after about 30 seconds. SerpApi reported renewed production failures and prioritized a fix the same day.

Can I decode a /goto URL without making a request?

No. The token decodes to a protobuf envelope, but the destination inside is protected. You have to send a GET to the /goto link with redirects turned off and read the Location header from the 302 response.

Why is Google adding /goto redirects?

Google says the redirects are a technical measure to protect against abuse of its search results. Combined with the JavaScript requirement in January 2025 and the removal of &num=100 in September 2025, they make automated collection of Google results slower and more expensive.

Do /goto links affect SEO or rankings?

Google hasn't said they affect rankings, and nothing in the published evidence suggests they do. They matter for tools that collect Google results, such as rank trackers, SERP APIs, and AI agents, because those tools need the destination URL.

Does Serper still work after the /goto change?

Serper marked its October 30 incident resolved with new handling. The first three organic results are resolved, results 4 to 10 come back as /goto links, and a new /resolve endpoint turns them into destinations later. Check Serper's status page for the latest.

Is there a SerpApi alternative that returns real URLs?

Yes. Context.dev's web search API returns real destination URLs. In our October 30 test, 20 searches returned 199 results with no Google redirect links. Pricing goes as low as $0.38 per 1,000 searches, and you can get each result's page as Markdown in the same call.

Conclusion

Google's /goto redirects started as a quiet change in July, looked solved by early September, and came back on October 30 with limits on how fast links can be resolved. Serper now resolves only the top three results right away, and SerpApi is working on a fix for renewed failures. Given the run from JavaScript in 2025 to num=100 to /goto, it's safe to expect more changes like this.

Whatever provider you use, check your results for google.com/goto links, measure how long it takes to get usable URLs, and make sure the rest of your pipeline handles a link that won't resolve. If you'd rather hand that off, try the Context.dev web search API for free and run the check above against your own queries.