Your WordPress view counter shows more visits than Google Analytics. Server logs record hits that never show up in your reports. This does not always point to broken tracking or bot traffic.
Since WordPress 6.8, browsers can prerender a subpage before the visitor actually navigates to it.
It is designed to make browsing feel instant. At the same time, it can skew analytics, view counts, and server-side logic.
Why does WordPress load pages before a click?
The goal is simple: reduce waiting time.
If the browser predicts that you are about to click a specific link, it can start fetching it in the background. When you finally click, the page is already prepared.
WordPress relies on the Speculation Rules API to handle this.
By default, WordPress does not aggressively prefetch every single link on the page. It behaves more cautiously, reacting only when user behaviour suggests an intent to visit that link.
For page speed, this is great news. The issue starts when the rest of your tech stack treats this speculative fetch as an actual visit.
The user hasn't arrived, but WordPress already built the page
When the browser prerenders a page, the server receives a standard HTTP request.
WordPress bootstraps, renders the template, runs plugins, and executes server-side code.
If you use a view counter plugin that logs every page generation to the database, it can count this speculative request as a real visit.
The user might click the link a moment later. Or they might change their mind and leave.
In the latter scenario, WordPress fully served a page that nobody ever looked at.
Why does Google Analytics show different numbers?
This is where the discrepancy becomes obvious.
During a typical speculative fetch, the browser downloads the document structure, but does not run its JavaScript yet.
Google Analytics runs in the browser and depends entirely on JavaScript. Your server-side counter can log a page view while Google Analytics has not registered a single event.
If the user never opens that page, one tool keeps an extra view that the other never saw.
That is why discrepancies between WordPress counters, server logs, and Google Analytics are not always caused by bots or broken tracking scripts.
Does this mean Google Analytics is wrong?
Not at all.
Both systems are simply measuring different things.
A server-side counter tracks how many times WordPress generated a given page. Google Analytics tracks actual user interaction inside the browser.
A few years ago, this distinction rarely caused major gaps. With speculative prerendering, generating a page no longer guarantees that anyone saw it.
This matters if you rely on WordPress metrics for content reporting, ad billing, or marketing decisions.
The issue goes beyond analytics
The bigger risk lies with URLs that trigger state changes when loaded.
A well-architected website should never run destructive or stateful actions on a simple GET request. In practice, older builds and custom setups often break this rule.
Think of custom add-to-cart URLs, logout links, action confirmations, affiliate redirects, or server-side conversion trackers.
If the browser prerenders that URL, the action might execute before the visitor ever decides to click.
Whenever you update WordPress, check beyond the visual layout—review any custom logic tied to standard link clicks.
What about WooCommerce?
A standard WooCommerce setup is mostly protected by how WordPress chooses URLs for speculation.
By default, WordPress skips URLs that include query parameters. Standard WooCommerce actions relying on parameters are not automatically queued for speculative fetches.
Custom stores need a closer look.
If your store relies on custom endpoints, legacy integrations, or server actions tied to regular URLs, test how they behave.
This is especially critical for large stores where WordPress and WooCommerce sync with ERP systems, warehouses, loyalty programs, or affiliate software.
Should you disable this feature?
In most cases, no.
The feature itself is useful. It improves perceived loading speed, and on a clean codebase, it will not trigger unwanted actions.
Rather than switching it off entirely, check if it actually disrupts your specific setup.
If the only issue is an inflated counter in a plugin, adjust your counting logic. If certain endpoints should never be prerendered, exclude them. Only turn the API off completely if it creates more headaches than benefits.
How to check if WordPress is prerendering pages
There is a catch: by default, WordPress generates speculation rules only for logged-out visitors.
If an administrator checks the site while logged in, the rules will not show up in the source code.
Always run tests as a regular visitor, for instance in a private browsing window.
A developer can then inspect which URLs are being fetched ahead of time and whether those requests write data to your database.
If your stats drifted after a core update or your view numbers look inflated, this is one of the first areas to investigate before rebuilding your entire analytics setup.
What should you check on your site?
First, check whether you use any view counters running directly inside WordPress. If they drive business decisions, make sure they separate speculative requests from real visits.
Second, audit custom code. Pay special attention to links that modify user state, update the database, or trigger third-party calls upon loading.
For online shops, review custom WooCommerce modifications and bespoke integrations.
A standard website might need no adjustments at all. But the more customized your architecture is, the more important it becomes to verify how it behaves after a WordPress update.
A faster website shouldn't mean unreliable data
Speculative prerendering is a classic background optimization—invisible to visitors, but impactful behind the scenes.
It speeds up the browsing experience, but it alters how server-side code and analytics work.
If your WordPress numbers do not match Google Analytics, it does not mean your setup is broken. The two tools may simply be recording different events.
At DOCK, we handle technical support and development for websites and online shops running on WordPress and WooCommerce. When we audit or onboard a project, we check beyond core updates and speed—we inspect custom logic, integrations, and tracking accuracy.
If your data diverged after an update or your site is behaving unexpectedly, we can track down the source of the issue and put the right fixes in place.
