Google’s /goto Update: Why My Use of DataForSEO May Reduce the Impact on ActionSEO

Google changed something in its search results in August that most searchers will probably never notice.

For SEO tools, however, it is considerably more interesting.

On August 26, 2026, Google confirmed the rollout of google.com/goto redirects in search results. Instead of every result exposing its final destination directly in the link, Google can route the click through its own /goto URL first. The change was reported following Google’s confirmation of the rollout .

For someone clicking a search result, very little changes. You click the result and reach the page you expected.

For software attempting to collect search-result data automatically at scale, the technical implications can be much more significant.

It also made me revisit an architectural decision I made while building ActionSEO : using DataForSEO for external SERP data instead of building and maintaining my own Google scraper.

That decision may matter more now than it did when I made it.

What actually changed with Google /goto?

Traditionally, a system collecting search results could retrieve the SERP, inspect the links associated with organic results and identify the destination URLs contained in those links.

With Google’s /goto structure, the link can instead take the form of an intermediate Google URL:

https://www.google.com/goto?...

The user still reaches the intended result, but an automated collection system may now have additional work to do before identifying the final destination.

This matters because Google’s own Search spam policies on machine-generated traffic specifically mention automated queries and scraping search results for rank-checking purposes.

That context is important. Google regularly changes both the appearance and underlying mechanics of its search results, while automated SERP collection systems have to respond to those changes.

Why this matters to SEO tools

Imagine a system that needs to identify which URLs appear for thousands of keywords.

If the destination URL is exposed directly in the search-result markup, collecting it is relatively straightforward.

If an additional redirect or resolution step is required, that small technical change can become much more important when multiplied across:

• thousands of keywords;
• multiple countries and locations;
• desktop and mobile searches;
• different languages;
• scheduled keyword checks;
• competitor research; and
• large volumes of repeated SERP requests.

This is one reason why operating reliable search-result collection infrastructure is very different from writing a small script that checks a Google results page occasionally.

So what happens to ActionSEO?

This is where the architecture becomes important.

ActionSEO does not run its own Google SERP scraper.

For external SERP data used within its SEO workflows, ActionSEO uses DataForSEO rather than directly loading Google result pages, parsing their HTML and attempting to maintain its own extraction system every time the SERP changes.

The DataForSEO Google SERP API provides structured search-result data based on parameters such as keyword, location, language, device type and operating system.

Its structured results include information such as URLs, domains and ranking positions rather than requiring ActionSEO to determine that information by interpreting Google’s link markup itself.

For example, DataForSEO documents both rank_group and rank_absolute. The first represents a result’s position among elements of the same type, while the second represents its position across the SERP.

You can see those fields directly in the DataForSEO Google Organic SERP documentation .

The separation therefore looks more like this:

ActionSEO works with the processed data returned by the API rather than depending directly on the current structure of Google’s organic-result links.

Does that mean ActionSEO is completely unaffected?

No, and that distinction matters.

I would not claim that Google’s /goto change has zero effect on DataForSEO.

DataForSEO still has to obtain and maintain the upstream search-result data. If Google makes collection more technically difficult, the provider may need to adapt its own infrastructure.

What changes is where that technical problem has to be solved.

ActionSEO itself does not have to understand whether Google currently exposes a direct URL, uses /goto, changes a CSS selector or restructures part of its result-page HTML.

DataForSEO’s API becomes the abstraction layer between Google’s constantly changing SERP and the application consuming the data.

That does not remove every dependency.

It moves much of the SERP-collection responsibility to a provider whose infrastructure is specifically designed for that job.

Why I chose an API instead of building another Google scraper

There is always a temptation when developing software to build everything yourself.

Sometimes that is the right decision.

SERP collection was one area where I deliberately chose not to do it.

Maintaining your own collection layer means responding whenever a search engine changes its page structure, link handling, anti-automation measures or result types.

With the DataForSEO model, ActionSEO can request structured data instead.

Conceptually, the difference is between building software that says:

Find the organic-result element, identify its link, extract its URL and work out its position.

and software that says:

Return the structured search results for this keyword, market and device, including the result URLs and ranking information.

Those are very different dependencies.

The API abstraction does not remove dependency — it moves it

Using an API does not magically make Google’s changes disappear.

It changes who has to handle them.

With a self-maintained scraper, the workflow can look something like this:

With a specialist API provider, the architecture becomes:

Of course, that model creates its own dependency: ActionSEO relies on its data provider continuing to collect and structure the information successfully.

That is why using an API should never mean blindly assuming every response is correct.

What I will be watching

Google’s /goto rollout does not currently make me want to change the ActionSEO architecture.

It makes me want to continue monitoring the quality of the data coming through that architecture.

The useful signals are things such as:

• returned destination URLs;
• organic ranking positions;
• keyword, location and device consistency;
• SERP feature identification;
• failed or incomplete responses;
• response times; and
• any future changes to API pricing or limits.

Those indicators matter more to ActionSEO than whether a particular /goto URL appears in one of my own manual Google searches.

This also reinforces why source transparency matters in SEO tools

One of the principles behind ActionSEO is that an SEO tool should be clear about where its information comes from and what that information can actually prove.

That is also why the platform connects directly to Google Search Console and GA4 for website-performance data instead of trying to replace verified first-party measurements with estimated numbers.

If you’re still learning how crawling, indexing and ranking fit together, my guide on how SEO works for beginners explains the full process from Google’s discovery of a page through to ranking.

The same principle applies to SERP information: know which data is being measured, which data is being estimated and which system is actually collecting it.

What the /goto change really reinforces

Google will change again.

SERP layouts will change. Search features will change. AI elements will change. Link structures and access patterns will change.

Building an SEO application around the assumption that today’s Google HTML will remain unchanged is therefore inherently fragile.

For ActionSEO, using DataForSEO creates a layer between those changes and the application itself.

It does not make ActionSEO immune from changes to Google Search.

But it does mean that a change to the mechanics of Google’s result pages does not automatically require me to rebuild SERP-collection infrastructure inside ActionSEO.

And Google’s /goto rollout has made me appreciate that architectural decision considerably more.

The goal is not to build SEO software that assumes Google will not change. It is to build software that expects it will.

Sources and further reading: Google Search Central — Machine-generated traffic · DataForSEO — Google SERP API overview · DataForSEO — Google Organic SERP API documentation · Search Engine Land — Google confirms /goto rollout