Olivier de Segonzac recently posted on LinkedIn that Google has stepped up its fight against scrapers again, this time by adding a delay to /goto redirect URLs in the SERP. He reported waits of up to 83 seconds. We ran our own test to see how this works in practice.
Setup
- Browser: Google Chrome, Incognito mode
- Queries: a handful of commercial keywords
- Depth: top 50 results for the US and top 50 for Ukraine
- Automation: Cursor
We collected the result URLs and measured how long it took each one to resolve to the final destination URL.
TL;DR: the gate is real, but we never got close to 83 seconds. And the delay doesn't depend on ranking position.
What we found
In Incognito, Google replaces result URLs with /goto links. When you request one, Google responds in one of two ways:
- an immediate 302 redirect to the site, or
- an HTML page with a meta refresh of N seconds.
N is how long you have to wait before the next step, which is the same /goto URL again with a fresh token.
This is not the familiar interstitial with a "Verifying your request" title. We didn't see that title once in our US run. It's a quieter gate built on a meta refresh delay. Results were consistent across both locations, so geography doesn't appear to matter.
| Scenario | First gated result | Max meta wait |
|---|---|---|
| Top 15 + cookie | from ~#5 | ~20 s |
| Top 50 + cookie | from #5 | 19 s |
| Top 50, no cookie | from #9 | 26 s |
| Single URL request, no cookie | immediately | 34 s |
Across our runs, the ceiling delay was 19–34 seconds.
| Metric | Ukraine (ua) | US (en) |
|---|---|---|
| First gate (+cookie) | #5 | #5 |
| Gated URLs (+cookie) | 26/50 | 25/50 |
| Max meta wait (+cookie) | 21 s | 19 s |
| Gated URLs (no cookie) | 47/50 | 41/50 |
| Max meta wait (no cookie) | 29 s | 26 s |
Position doesn't drive the delay
We tested the obvious hypothesis that #1 resolves fast and results further down get throttled. It didn't hold up.
We ran the list in reverse, from #25 down to #1:
- #25, requested first → instant 302
- #1, requested last → 19-second wait
Controls:
- Alternating #1 and #47 → all 302s
- Requesting the same #1 URL 15 times → all 302s
The delay is tied to request order within the session, not to SERP ranking.
How often the counter resets
With cookies, the pattern repeats roughly every 7–9 hits:
free → free → free → free → 3 s → 5 s → 10 s → 19 s → free again…
So the reset is based on hit count.
Without cookies it's harsher. Instant redirects almost never come back, although the wait time periodically drops (for example, from 26 s to 7 s) and then climbs again.
If you try to skip the timer, Google returns a 400:
| Moment | Status | Result |
|---|---|---|
| Right after the gate (t≈0), N=4 s | 400 | Error 400 (Bad Request) |
| After N seconds | 302 | Redirect to the site |
Key takeaways
- The /goto gate exists. Instead of a 302, you often get an HTML 200 with an N-second meta refresh.
- The first few links are free. The delay kicks in after that.
- Cookies soften it but don't remove it. Without cookies, almost everything is gated.
- The ceiling is about 19–34 seconds over 15–50 hits.
- It works as a per-session hit counter (roughly every 7–9 hits). It isn't based on ranking, and it isn't necessarily "one SERP = one counter."
- You can't skip the timer. Requesting the new /goto before the countdown ends gets you a 400. Once the timer runs out, you get a normal 302 to the site.
Why this matters
Google is deliberately slowing down bulk /goto resolution with meta refresh delays. A single user clicking a result won't notice, but any tool that resolves SERP URLs at scale will. That makes the data harder and more expensive to collect for rank trackers, SERP APIs and other SEO tools, and in the end, SEO specialists will probably pay for it through higher subscription prices.
Leave a comment