Google is prefetching your ads. Why it matters
Google is prefetching your ads. Why it matters
How Chrome’s Private Prefetch Proxy removes the user’s IP from a fifth of your paid clicks — and what that does to the tools you rely on to catch fraud.
Summary
A growing share of the traffic hitting your Google Ads landing pages never comes from a human. It comes from Google.
When someone searches on Google, Chrome frequently preloads the landing page of the ad they’re most likely to click — before they click it — and routes that request through a Google-operated proxy that hides the user’s real IP address. In the logs, the visit shows up as coming from Google’s own network — in our case, typically autonomous system AS15169 — carrying the ad’s click ID.
This is legitimate Google infrastructure, not fraud. But it has a consequence advertisers rarely hear about: on the account we analyzed, roughly 20% of billed clicks passed through this prefetch mechanism, and for around 60% of those prefetched clicks we never saw the user’s real IP address at all. The click was served from Chrome’s local cache, so the actual navigation never touched our server.
That is a real transparency and verification problem — and it undermines the in-browser anti-fraud tools most advertisers depend on.
The bottom line: prefetch now affects a significant share of Google Ads traffic, and most standard anti-fraud tools have limited visibility into it — because they ultimately block invalid clicks by excluding the visitor’s IP in Google Ads, and a prefetched click arrives from Google’s own IP, with the user’s IP hidden. At Fáktica Analytics we approach the problem differently: we work hands-on with each client’s own data and server logs, rather than handing everyone the same off-the-shelf script. And we don’t lean on IP blocking — for us, IP addresses are just one tool among many.
What is prefetching?
Prefetching (or preloading) is a browser performance feature. Its whole purpose is speed. When you run a Google search, Chrome tries to predict which result or ad you’re most likely to open and downloads that page in advance, so that if you do click, the page appears almost instantly.
There’s a privacy catch built into that. If Chrome fetched the page directly from your device, the destination server would see your IP address before you had decided to visit — leaking the fact that you’re about to go there. To prevent that leak, Chrome routes the preload through the Private Prefetch Proxy, a Google-operated CONNECT proxy. The destination server never sees your IP. It only sees Google’s.
So in a server log, a prefetched ad click looks like this:
- The request comes from a Google IP address (in our case, typically AS15169), not the user's.
- It usually carries the real browser's user-agent (a genuine, up-to-date Chrome).
- It requests the full landing-page URL, including the gclid/gbraid click ID and UTMs.
- The actual human click, if it happens, is often served straight from Chrome's local cache — with no second request to your server.
In other words: the ad click and the preload share the same identifier, but the visit you can actually see and inspect may never arrive.
What Google says
Google frames this purely as a performance-and-privacy feature, and on its own terms that framing is accurate. Google’s Chrome developer documentation describes the Private Prefetch Proxy as a way to speed up outbound navigations from Google Search — it began rolling out with Chrome 103 on Android and is documented as improving those navigations by around 30% at the median. Google is also explicit that the proxy is designed so the destination server cannot see the user’s IP address until the user actually navigates.
Google has also made a second, more specific statement. In a Chrome for Developers post dated February 12, 2025, it described how Google Search prefetches search-result pages and said it deliberately avoids ads — Search lists the result URLs explicitly so that it does not, in Google’s words, “prefetch other URLs like ads.” On paper, then, Google Search’s documented prefetch mechanism is designed to prefetch search results while excluding ad URLs.
That is not what our logs show. The prefetch traffic we see lands on paid landing pages — every request carries an ad click ID — and it arrives with the exact private-prefetch-proxy signature (Google’s own network, an anonymized IP) that Google documents for organic results.
You can verify this yourself without ever touching a server log. Run a Google search on desktop Chrome and open Chrome DevTools. In the Application → Speculative loads panel, Chrome lists every URL the page has instructed it to prefetch or prerender via the Speculation Rules API. Ad landing-page URLs show up in that list on a regular basis — as in the screenshots below, where the page is asking the browser to load an ad destination (note the gclid, gad_source and gbraid parameters in the URL) before the user has clicked on anything.
See it live. Top: Chrome’s own DevTools (Application → Speculative loads) on a Google results page — the autoeurope.es ad URL, gclid and all, is already prefetched and “ready for the next navigation.” Bottom: the sponsored result that URL belongs to, in the same “car rental chicago” search.
Whatever the stated intent in February 2025, ads are being prefetched — at scale, and increasingly so.
The practical message advertisers usually get is some version of “that traffic in your logs is just Google infrastructure — it isn’t clicks you’re being charged for, so ignore it.”
And taken narrowly, that’s true: a preload is not, by itself, a billable click. What that framing leaves out is the downstream effect. The same mechanism that protects the user’s privacy also removes the single most useful signal advertisers have for validating their own traffic — the visitor’s real IP — from a meaningful slice of the clicks they are billed for. Google’s documentation even notes the side effect directly: because Chrome issues no observable DNS lookup for a prefetched page, network-level content filtering may not work as intended on those navigations. The privacy win for the user is a visibility loss for the advertiser.
Sources: Google’s own documentation — Private prefetch proxy in Chrome, the Private Prefetch Proxy explainer, and the February 12, 2025 post How Google Search uses speculation rules.
What we see in our logs
We analyzed five months of server logs (April–August 2026) for one advertiser account, restricted to paid Google traffic — every request tagged source / medium = google / cpc and carrying a gclid click ID. Within that paid traffic, a large and growing share arrives not from a user, but from Google itself (AS15169):
The AS15169 slice has an unmistakable fingerprint: 99.97% of it was Chrome, split between desktop and Android, running natural, up-to-date versions — not a fixed bot user-agent. This is the exact signature of ad-landing-page preloading, not generic crawling.
Set against the clicks Google billed over the same period, the headline is this: about 1 in 5 billed clicks (≈20%) had passed through prefetch. The rest hadn’t — largely because iOS/Safari doesn’t use Chrome’s prefetch proxy, and not every impression gets preloaded. Prefetch is a transport layer that touches a random minority of your paid clicks, not all of them.
Note: this makes the absence of prefetch meaningless as a fraud signal. Most legitimate clicks have no prefetch. We don’t treat “no prefetch” as suspicious, and neither should anyone else.
When did this start?
This is not how it always was. Looking further back, prefetch traffic from Google to the same landing pages was a rounding error until late 2025 — a few hundred requests per quarter — and then it stepped up sharply:
The prefetch surge is not traffic growth. Ad clicks stay flat while Google’s prefetch requests climb from 180 to 10,275 per quarter. Source: Fáktica Analytics.
The obvious question is whether this just tracks more advertising — more impressions, more clicks, so more of everything, prefetch included. It doesn’t. Over the exact same period, on the same Google Search campaigns, ad volume was flat: impressions stayed in a band of roughly 85,000–137,000 per quarter, and clicks in a band of roughly 3,600–5,200. They end 2026 Q2 almost exactly where they began in 2024 Q1. Prefetch, meanwhile, went from an average of 227 requests per quarter across 2024 Q1–2025 Q2 to 10,165 per quarter across 2026 Q1–Q2 — about a 45× increase, against effectively flat clicks.
Google Ads figures: Campaign type = Search; Network = Google Search (only). Chart ends at 2026 Q2, the last full quarter; for reference, prefetch in July 2026 alone (partial 2026 Q3) was already 4,573.
The pattern falls into three phases. Through 2024 and the first half of 2025, prefetch was a baseline rounding error — a few hundred requests per quarter. In 2025 Q3–Q4 it surged, climbing from under 300 to more than 6,000 in two quarters. Across 2026 it settled into a new normal above 10,000 per quarter — all while your actual audience stayed the same size.
Whatever the exact cause — wider rollout, more Android/Chrome coverage, broader eligibility — this became a mainstream feature of paid-search traffic essentially within the last year, with no change in your spend or reach behind it.
This timing is worth sitting with. When Google published its “organic only, no ads” description of prefetch on February 12, 2025, it was essentially accurate: through mid-2025, ad-landing-page prefetch was a rounding error. It stopped being accurate within the same year. By Q4 2025 the very traffic that post says Google avoids had multiplied into thousands of requests per quarter — and it has kept climbing since.
If you last audited your ad traffic before mid-2025 and concluded prefetch was negligible, that conclusion is now out of date.
Why it matters: transparency, verification, and fraud control
Here’s the crux. Of the billed clicks that passed through prefetch, about 60% left no trace of the user at all. Google billed the click, Chrome served the page from its preloaded cache, and our server never recorded a request from the user’s real IP. We can see that a click was charged; we cannot independently see who made it, from where, or on what network.
To be clear about what this is and isn’t:
- It is not evidence of fraud. In our analysis, this cache-served, IP-less traffic was overwhelmingly high-intent brand search from desktop — exactly the profile of legitimate clicks that prefetch works best on and then makes invisible. A datacenter bot cannot manufacture a prefetch: it's triggered by Chrome on Google's own results page and exits from Google's IP. Prefetch is not a channel fraud can exploit to sneak past you.
- It is a loss of verifiability. For roughly a fifth of your paid clicks — and around 60% of that fifth — you are being asked to take the billing on trust, because the one signal you'd use to check it (the user's IP and network) has been removed at the source.
For most of history, ad-traffic validation has rested on an assumption: the traffic that lands on my page carries the visitor’s real IP, so I can classify it — residential vs. datacenter, human vs. bot, expected geo vs. anomaly. Prefetch breaks that assumption for a growing slice of paid traffic. You’re not looking at fraud you can’t see; you’re looking at legitimacy you can no longer confirm — and, in the general environment around it, plenty of genuine datacenter-scraper noise that has to be separated out before any conclusion is safe.
The result is not “trust Google less.” It’s “browser-side visibility is no longer enough.” The only way to close the gap is to reconcile at the log level, by click identifier, against what Google actually billed.
What this does to ClickCease, Lunio and similar anti-click fraud tools
Most commercial anti-fraud products — ClickCease, Lunio, and the rest of that category — work in broadly similar ways: they sit in the click path — a JavaScript tag on your landing page, or a tracking redirect through the vendor’s own servers — capture the visitor’s real IP and device signals, score them, and — if the visit looks fraudulent — add that IP to your Google Ads IP exclusion list so it can’t cost you again.
Prefetch degrades that model in two specific, structural ways:
- Origin blindness. When a click is served from Chrome's prefetch cache (much of that ~60% above), the tool's detection point — a tag on your landing page, or a click-time redirect through the vendor's servers — may never see a fresh request carrying the user's IP. The preload arrived from Google's IP; the real navigation was served locally. The tool simply never sees the visitor it's supposed to evaluate.
- IP exclusion can't act. A prefetched request comes from a Google IP, not the user's. IP exclusion lists operate on the user's IP. So a click delivered this way is, by construction, immune to IP-based blocking — there's no user IP to block.
Two caveats. First, prefetch is not itself a fraud vector — a bot can’t summon one. Second, the effect is bounded, for now: only ~20% of billed clicks pass through prefetch, so ~80% of your paid traffic is still fully visible to these tools. But “for now” is doing real work in that sentence. That boundary is Google’s to move — just as prefetch surged in Q4 2025, nothing prevents another jump that widens the blind spot overnight.
But the conclusion is hard to avoid: in-browser detection has a permanent, structural blind spot that it cannot close on its own. The clicks it can’t see are, definitionally, the clicks where its core signal (the user’s IP) was removed before the tag ever ran. Catching what happens inside the browser can’t cover traffic that was resolved before the browser hit your page. That coverage only comes from server-log reconciliation against Google’s billing data.
Where Fáktica Analytics comes in
This is exactly the gap Fáktica Analytics exists to close.
We don’t rely on a browser tag that only sees the clicks Google lets it see. We work from your raw server logs, reconcile them click-by-click against what Google actually billed, and forensically separate legitimate traffic — including the prefetched, cache-served clicks that in-browser tools go blind on — from genuine invalid activity. That’s how you turn “clicks I’m asked to trust” back into “clicks I can verify.”
We help advertisers with the full lifecycle:
If ~20% of your paid clicks are arriving with their origin erased, you’re making budget decisions — and fraud decisions — on partial information. We can show you what’s actually in your logs.