See it on a real storeBots, pages and people sent by AI on an example store. No sign-up.You install a WordPress plugin to track AI bots, wait a week, and see a handful of visits. Then you open your server log and find hundreds. Nothing is broken. Your cache is doing its job.
This post explains why page caching hides bots from WordPress plugins, how to check whether it affects your site, and what to do about it.
How page caching skips WordPress
Without caching, every request starts PHP, loads WordPress and its plugins, queries the database and builds the page. That's slow, so almost every serious WordPress site caches.
A page cache saves the finished HTML the first time a page is built. The next request for that page gets the saved copy straight from disk, from the web server or from a CDN, without running WordPress at all.
That's the point of caching, and it's also the problem. A plugin is code inside WordPress. If WordPress doesn't run, the plugin doesn't either, and the visit is never seen.
Why bots are hit harder than people
Bots mostly ask for public pages: articles, products, categories. Those are exactly the pages caches store. Logged-in users, carts and checkout usually bypass the cache, but bots never log in.
So the visits a plugin does see tend to be the odd ones: a page requested for the first time after the cache cleared, a URL with a query string the cache ignores, an error page. That makes the plugin's numbers both too low and skewed.
Which setups are affected
| Setup | Does a plugin see bots? |
|---|---|
| No caching | Yes, all of them |
| Plugin-level cache that still loads WordPress early | Mostly |
| WP Rocket, WP Super Cache, W3 Total Cache (disk cache served by the web server) | Only cache misses |
| LiteSpeed Cache on a LiteSpeed server | Only cache misses |
| Host-level cache (many managed WordPress hosts) | Only cache misses |
| CDN caching full pages (Cloudflare APO, others) | Only requests the CDN passes through |
How to check your own site
Two quick tests.
1. Look at the response headers
curl -sI -A "GPTBot" https://example.com/some-article/ | grep -iE "cache|age|x-litespeed|cf-cache-status"Headers such as cf-cache-status: HIT, x-litespeed-cache: hit, a non-zero age, or a cache comment at the bottom of the HTML mean the page came from cache. That request never reached a plugin.
2. Compare the plugin with the server log
If your host gives you access logs, count one bot in both places for the same day. A large gap is the cache.
grep -c "GPTBot" access.logYour options
Exclude bots from the cache (not recommended)
Some cache plugins can skip caching for certain user agents. Plugins would then see bots, but every bot visit would load full WordPress. On a busy site that adds real load for no benefit to visitors.
Read the server logs
Complete for requests that reach the server, but a CDN cache in front can still hide visits, and many managed hosts don't give you raw logs, or keep them only a few days.
Measure at the CDN or edge
If your site is behind Cloudflare, every request passes through it, cached or not. Recording there sees everything without touching WordPress or the cache. This is the most complete option.
Use a plugin, knowing its limits
On sites without full-page caching, a plugin works fine. On cached sites it's still useful for seeing which bots appear and what errors they hit, as long as you read the counts as a sample.
On managed WordPress hosting
Managed WordPress hosts usually add their own cache layer in front of your site, and many don't give you full raw logs, or keep them only briefly. Before you rely on any numbers, find out three things from your host's documentation or support:
- Is there a full-page cache in front of WordPress, and can bots be served from it? Almost always yes.
- Can you download raw access logs, and how many days are kept?
- Can you put your own CDN, such as Cloudflare, in front of the site?
If the answers are yes, no and yes, measuring at your own CDN is the way to see everything. If you can't change DNS or add a CDN, the host's logs are your most complete source, even if you have to download them often.
What a partial count gets wrong
A plugin behind a cache doesn't just undercount. It sees a biased slice of traffic, which can lead to wrong conclusions:
- Errors look worse than they are. Error pages often aren't cached, so they reach the plugin while successful visits don't.
- New posts look over-read. A new page is a cache miss the first time each bot asks for it, so recent content is overrepresented.
- Trends follow your cache, not bots. Clear the cache and bot visits seem to jump; extend cache lifetimes and they seem to drop.
If the plugin is your only source, read it for which bots appear and what errors they hit, not for how many visits there were.
How SenseGap handles WordPress
SenseGap offers both routes. The WordPress plugin installs like any other and works well on sites without full-page caching. It warns you when it detects a page cache, so you know its counts are partial. For sites on Cloudflare, the Cloudflare install records every request at the edge, cached pages included, with nothing changed in WordPress and no extra wait for visitors.
Freelancers managing several WordPress sites can connect them all to one account. See SenseGap for agencies and freelancers, or why tag-based analytics misses bots for the wider picture.