Google.com/goto: Google's Anti-Scraping Update Makes Every Result Harder to Extract

Google has added an extra request between search results and destination pages, creating a direct conflict with tools that collect result URLs at scale. The change, known as google.com/goto: Google's anti-scraping update, replaces many direct organic links with opaque Google redirect addresses.

The search result still looks familiar to a person. Its title, displayed domain, favicon, and description remain visible. However, the underlying link can now point to google.com/goto?url=... instead of the publisher's page.

That distinction matters because the encoded value does not expose the complete destination URL. A browser can ask Google to resolve it automatically. A scraper must make another request, handle the response, and avoid triggering Google's defenses.

Google describes the rollout as a technical measure against abuse. The change does not block automated collection outright. Instead, it converts a cheap HTML parsing task into a noisier sequence of requests that Google can observe.

This is the central conflict. Search users still need reliable outbound links, while Google wants greater control over automated access to its results. SERP API companies, SEO platforms, researchers, and AI developers now operate inside that tension.

Google.com/goto: Google's Anti-Scraping Update Changes the Link Layer

Google has not changed what an organic result displays, but it has changed how software reaches the result's destination.

A traditional Google result placed the destination page directly inside the anchor element's href attribute. Software could download one search results page, parse its HTML, and extract several complete URLs.

The new structure inserts a Google-controlled redirect. The result's anchor can point to a /goto address containing a value that often begins with CAES. That value represents the destination without publishing it as readable text.

When a person clicks the result, the browser requests the /goto address. Google then returns an HTTP redirect that sends the browser to the actual page. The transition is usually too fast for a searcher to notice.

Google confirmed the rollout on August 26, 2026. A spokesperson said the company regularly deploys technical measures against evolving abuse to protect its services and users. The confirmation described the redirect as one of those measures.

The company did not publish a technical specification for the token. It also did not explain every signal determining which browsers, regions, or sessions receive the rewritten links.

Early observations appeared before the confirmation. Search specialists reported the pattern in June and July, when it still looked like a limited test. By late August, several data providers were seeing much broader deployment.

The rollout confirmation reported nearly complete coverage across several residential IP providers. That estimate came from Derek Perkins of rank-tracking company Nozzle, not from Google.

Autom, a search-data API provider, reported a similar progression. Its team first encountered /goto on a small share of result pages. It later saw the format consistently in logged-out and private browsing sessions.

The provider's technical account says the opaque parameter cannot be converted into the destination through ordinary local decoding. The destination instead arrives through the redirect response.

This format differs from Google's older /url wrapper. That wrapper often included a readable, URL-encoded destination in its query string. Software could extract that value without contacting Google again.

With /goto, the visible search result and the actionable destination become separate pieces of data. Google still renders enough information for a person to assess the result. However, the page source no longer guarantees a reusable outbound URL.

That is the meaningful change. Google has moved destination resolution from static HTML into an interaction with its own server.

Why One Extra Redirect Puts Search Data Providers Under Pressure

The redirect creates a marginal cost for every resolved result, and that cost compounds across high-volume collection systems.

A basic scraper once needed one request to collect several organic destinations from a search results page. Under the new format, it may need the original request plus one resolution request for each unique /goto token.

Consider a service monitoring many queries across locations, devices, and languages. It may collect multiple pages for every query and repeat that collection throughout the day. An extra request per result quickly becomes substantial infrastructure work.

The cost is not limited to bandwidth. Each resolution adds latency, connection management, retry logic, and another opportunity for failure. It also creates a recognizable stream of requests directed at Google's redirect endpoint.

Google can observe how quickly one client resolves links. It can compare those requests with cookies, network identities, browser characteristics, and earlier search activity. Google has not disclosed which signals it uses here.

This makes the update more than a new parsing format. It creates a server-side checkpoint between obtaining the result page and learning every exact destination.

Traditional rank tracking illustrates the pressure. A position tracker must identify which page ranks for a query, not merely which domain appears. Exact paths matter when a site has several pages competing for the same topic.

A tool that stores the Google redirect instead of the publisher URL can produce misleading records. It might report missing results, merge distinct pages, or make landing-page changes look like ranking changes.

Search APIs face a related problem. Their customers expect clean, structured destination URLs. Those customers should not need to understand Google's current link wrapper or rewrite their integrations whenever the format changes.

Autom says it modified its pipeline to resolve /goto links while preserving its existing response fields. This approach moves the compatibility burden from API customers to the data provider.

That fix still depends on Google's redirect service remaining available to the collector. It also assumes the current response behavior will remain stable. Google has made no commitment to either condition.

AI search and research products face another form of pressure. Some systems use commercial search APIs, while others gather result pages through their own infrastructure. Both approaches depend on predictable access to source URLs.

The redirect does not prevent a model from reading a destination after someone supplies it. It affects the upstream discovery process that finds, ranks, and retrieves sources before analysis begins.

Knowledge workers may encounter the effect indirectly. A research assistant can miss sources when its search connector mishandles redirect URLs. It can also store Google wrappers where users expect stable publisher links.

That makes provenance harder to inspect. A trustworthy research record should preserve the page that supported a claim, not a temporary routing address owned by the search engine.

Teams building internal research systems should therefore keep source identity separate from discovery metadata. A searchable AI knowledge base remains useful only when its citations resolve to durable documents.

The immediate pressure lands on search-data intermediaries. The downstream risk reaches any product that treats their output as dependable source infrastructure.

The Real Contest Is Open Results Versus Controlled Resolution

Google still publishes a readable results page, but it increasingly controls the actions required to turn that page into reusable data.

This is not simply Google versus one scraping company. The primary contest is between two technical models for accessing public-facing search results.

The first model treats a results page as a document. A client downloads it, reads the links embedded in the HTML, and decides what to do next. Much of the early web operated through this simple pattern.

The second model treats results as an interactive service. What the user sees remains accessible, but important values become available only through additional requests governed by the platform.

The /goto rollout moves Google Search toward the second model. It does so without removing organic results or forcing ordinary users into a new workflow.

That subtlety is important. Calling the update a scraping ban overstates its effect. The links remain resolvable, and independent testing shows that developers can still recover their destinations.

ScrapingBee tested /goto across browsers, automated sessions, and network configurations. Its redirect experiments found the token could be structurally decoded, but not converted locally into the original URL.

The company reported that an HTTP GET request with automatic redirects disabled returned a 302 response and a Location header. That header contained the destination address.

Its tests also found that HEAD requests behaved differently. They returned 200 responses without the required location header, forcing collectors to use GET for reliable resolution.

That finding conflicts with Autom's initial recommendation to read the location using HEAD. The difference may reflect changing behavior, testing conditions, or multiple rollout variants.

Developers should not treat either method as a permanent contract. A defensive implementation can test response behavior, support more than one wrapper, and record failures without corrupting stored URLs.

ScrapingBee measured 50 resolutions at a median of about 3.27 seconds when processed sequentially. Five workers reduced the median to about 1.23 seconds in its environment.

Those figures come from one vendor's tests, not a universal benchmark. Network location, connection reuse, Google responses, and throttling can produce different results.

Still, the experiment clarifies the tradeoff. The update adds friction, but moderate concurrency can absorb some of it. That makes the measure more likely to reshape costs than eliminate scraping.

The server interaction also gives Google options that static links did not provide. It can adjust responses, change token formats, apply rate controls, or distinguish among client types.

Google already controls the search results page itself. However, direct outbound URLs limited the company's involvement after a client received the HTML. /goto extends that involvement to destination resolution.

The change follows other efforts that have complicated large-scale collection. Google has tightened automated-traffic defenses and changed result-page parameters that collectors previously used for larger result sets.

Each individual adjustment can be engineered around. Together, they make unofficial access less predictable and increase the value of maintained collection infrastructure.

This shift also exposes an uncomfortable symmetry. Google builds its index by crawling other websites, while restricting automated systems that collect Google's presentation of that index.

The activities are not identical. Googlebot follows publisher controls, builds a search product, and operates under documented crawling systems. SERP scrapers collect Google's generated ranking pages, often outside a supported API relationship.

Even so, publishers and developers notice the imbalance. Google expects the open web to remain technically accessible while making its own aggregation layer progressively harder to reuse.

A heavily discussed community thread reflected that dispute. It attracted 472 points and 369 comments at the snapshot supplied with this story.

Some participants viewed the update as reasonable service protection. Others described it as another enclosure around information derived from public websites. Several focused on the practical engineering challenge instead of the policy argument.

The strongest interpretation sits between those positions. Google has not closed its search results, but it has made high-volume reuse more dependent on Google-controlled interactions.

The Update Is Friction, Not a Complete Scraping Block

The largest uncertainty is whether `/goto` remains a manageable redirect format or becomes one layer in a stricter enforcement system.

The current mechanism has visible limits. A scraper can request each redirect and read its destination. Some copies of the underlying URL may also remain elsewhere in the rendered page.

Google needs destination information to display domains, favicons, breadcrumbs, and attribution. Depending on the result format, collectors may reconstruct part of the identity without resolving every link.

That does not always produce the exact landing page. A displayed domain cannot distinguish a product page from a support article on the same site. Breadcrumb text may also omit parameters or path components.

The rollout is not uniform either. ScrapingBee reported /goto in Chrome, Edge, Playwright, and its own collection environment. Brave and LibreWolf returned direct links during the same testing effort.

Safari returned another Google wrapper rather than the same /goto format. Changing proxy location did not reliably remove the redirect.

These results suggest client variation, but they do not reveal Google's selection rules. Browser type may correlate with the outcome without directly causing it.

The tokens also appeared portable in ScrapingBee's tests. Tokens collected through one connection could be resolved later through another client without the original cookies or proxy.

They remained usable for more than 24 hours in those experiments. Their maximum lifetime remains unknown, and Google could change portability or expiration rules without notice.

That uncertainty should shape engineering decisions. A production collector should not store opaque tokens as if they were permanent identifiers. It should resolve and validate destinations close to collection time.

It should also preserve the original wrapper for diagnosis. Keeping both values helps teams distinguish a ranking change from a resolver failure or a new Google response variant.

Retries need careful limits. Aggressive resolution can amplify the request pattern the change appears designed to expose. Unbounded retries can also create higher costs during partial outages.

Collection systems should deduplicate identical tokens before resolving them. ScrapingBee found repeated tokens within some result pages, making unnecessary duplicate requests avoidable.

Providers also need monitoring at several boundaries. They should track the share of results using each wrapper, resolution success rates, response codes, and latency distributions.

A sudden rise in Google URLs inside customer output is a parsing incident, not evidence that publishers disappeared from search. Separating those conditions prevents false ranking alarms.

Analytics teams have a different question. They want to know whether the redirect changes referral attribution when a human reaches a publisher's site.

A server-side redirect can still lead to the expected destination while preserving usable referral signals. Actual attribution depends on browser behavior, headers, analytics configuration, and Google's implementation.

There is no verified basis for claiming that the rollout broadly destroys organic attribution. Site operators should inspect their own landing requests and analytics classifications before drawing that conclusion.

Google's general redirect guidance explains how its crawler interprets common redirect types. It does not document /goto as a public integration surface for third-party collectors.

That difference matters. Google Search Central documentation tells publishers how to redirect their own pages. It does not promise stable behavior for Google's outbound search wrappers.

Users face a smaller but real tradeoff. Hovering over a result may reveal a Google address instead of the complete destination. The displayed domain still provides context, but the browser's status preview becomes less informative.

That can weaken a familiar security check. A cautious user may want to inspect the exact destination before opening it, especially when several pages share similar titles.

Google can argue that its visible domain labels and abuse protections remain effective. Critics can reasonably answer that a platform-controlled label is not identical to inspecting the actual link.

Neither concern proves that the rollout harms most users. It shows that anti-automation measures can alter transparency even when the click experience appears unchanged.

The evidence currently supports a narrow conclusion. /goto raises collection costs, breaks simplistic parsers, and expands Google's control over destination resolution.

It does not support the stronger claim that Google has made search scraping impossible. Providers have already demonstrated working resolution paths, although those paths carry new operational risks.

What Google's Anti-Scraping Update Forces Teams to Watch Next

Three signals will determine whether this becomes a routine parser update or a lasting change in search-data economics.

The first signal is link-format coverage. Providers should measure how often direct URLs, /url wrappers, and /goto tokens appear across browsers, regions, and session states.

A stable mixture would strengthen the view that Google is running a segmented control system. A rapid move toward universal /goto links would strengthen the anti-scraping interpretation.

A reversal toward direct links would weaken the broader conclusion. It would suggest that compatibility problems, user concerns, or experimental results outweighed the extra control.

The second signal is resolver behavior. Teams should track whether a simple GET request continues returning a usable 302 Location header without a browser session.

If that route remains available, experienced providers can treat the update as added infrastructure cost. Basic scrapers will break, but maintained systems can continue operating.

New authentication requirements, short token lifetimes, strict rate limits, or client-bound tokens would materially increase the barrier. They would indicate that Google is tightening the checkpoint rather than merely rewriting links.

Changes to HEAD and GET behavior also deserve attention. The conflicting early reports show why providers need direct tests instead of relying on a single implementation recipe.

The third signal is data quality inside SEO and AI products. Customers should watch for missing landing pages, duplicated Google URLs, unexplained ranking volatility, or citations that stop at redirect wrappers.

These symptoms would show that some providers have not fully adapted. Stable output would suggest that vendors absorbed the change without shifting much burden to customers.

Search-data buyers should ask vendors concrete questions. Does the service return the final destination? Does it preserve canonical parameters? How does it label unresolved results?

They should also ask whether reported positions changed because of the link format. A ranking tool must separate collection errors from actual movements in Google's ordering.

AI product teams need similar checks around citations. Every retrieved claim should connect to the final publisher URL, with collection failures visible to operators.

Google's next public statement also matters, although the company may offer little additional detail. A formal explanation of user protection or abuse categories would narrow the debate about intent.

The present statement confirms that /goto is a protective measure. It does not say whether AI crawlers, SEO tools, click measurement, or another abuse class motivated the design.

Legal conflicts could provide more context. Google has challenged some companies that collect and resell search results, showing that technical controls exist alongside legal pressure.

However, /goto affects a wider range of clients than any single defendant. Researchers, accessibility tools, browser extensions, and internal monitoring systems can encounter the same wrappers.

The next few months will reveal whether Google distinguishes among those uses. Uniform restrictions would favor centralized data providers that can maintain large resolution systems.

Selective access could produce a different market. Supported partners and approved interfaces would gain importance, while unofficial collection would become less reliable.

For developers, the immediate response is straightforward. Treat search-result links as variable data, validate destinations, retain diagnostic context, and monitor resolver failures separately from ranking changes.

For buyers, the task is verification. Ask whether your SEO, monitoring, or research provider has adapted before trusting an unexpected shift in its reports.

For knowledge workers, inspect citations when an automated research system returns a Google wrapper. A usable answer should lead to the underlying source, not stop at the search engine's routing layer.

Google.com/goto: Google's anti-scraping update is therefore neither a total blockade nor a cosmetic redirect. It is an architectural toll booth placed at a valuable point in the search-data pipeline.

Watch whether that toll remains one inexpensive request. If it gains stricter identity checks, shorter-lived tokens, or tighter limits, today's parser repair will become a larger access dispute.