Skip to main content
Important: If your WordPress host uses a CDN for caching (Cloudflare, Fastly, etc.), the plugin will only capture cache misses — not cache hits. This is a platform limitation, not a plugin limitation.

​
The Issue

Many managed WordPress hosts (WP Engine, Kinsta, Flywheel, etc.) place a CDN in front of your WordPress site for performance. When a visitor requests a page:
  1. Cache Miss → Request passes through to WordPress → Plugin captures the request → Logged successfully
  2. Cache Hit → CDN serves cached content directly → Request never reaches WordPress → Not logged by plugin
This means you’ll only see a portion of your actual traffic — specifically, the traffic that wasn’t served from cache.

​
Example

In this example, the site is hosted on WordPress Engine with WPE application cache layer enabled. In this example, we are fetching the page for the first time, so it is a cache miss. 
curl -I "https://my-wp-site.com/some-page"


HTTP/2 200 OK
...
x-cache: MISS
# Cache missed, request reaches WordPress and is logged by the plugin
...
On the second request, the page is live in the cache, so it is served from the cache layer and never reaches WordPress. 
curl -I "https://my-wp-site.com/some-page"


HTTP/2 200 OK
...
x-cache: HIT: 1
# Cache hit, request never reaches WordPress and is not logged by the plugin
...

​
Why This Happens

The plugin operates at the WordPress application layer. It can only log requests that actually reach your WordPress server. When a CDN serves cached content, the request terminates at the CDN’s edge servers and never makes it to your WordPress installation. The complete solution is to use CDN-native log drains, which Agent Analytics already fully supports. CDN logs capture everything — cache hits, cache misses, bot traffic, DDoS attempts, the complete picture.

​
The Platform Problem

Unfortunately, most managed WordPress hosts like WP Engine and Kinsta do not provide customers access to configure their CDN log drains. Profound has contacted these providers to request access for customers, they declined at this time. We are pursuing partnership opportunities with these providers to enable this functionality.

​
Impact on Analytics

  • Initial page visits (cache miss)
  • Dynamic/personalized pages that bypass cache
  • POST requests and form submissions
  • Admin-generated traffic to public pages
  • Pages with query parameters (often uncached)
  • Requests during cache purge/rebuild periods
  • Subsequent visits to the same page (cache hits)
  • Popular pages with high cache hit rates (90%+ typical)
  • Static assets served from CDN (CSS, JS, images)
  • Bot traffic filtered or served at CDN edge
  • Attacks/DDoS blocked at CDN layer
  • Well-optimized sites: 85-95% cache hit rate
  • Average sites: 60-80% cache hit rate
  • Dynamic/personalized sites: 20-40% cache hit rate

​
Workarounds

If you need complete traffic visibility, consider:
  1. Switch to a host that provides CDN control - Many hosts (AWS, Google Cloud, etc.) allow you to configure your own CDN
  2. Request enterprise CDN access - Some managed hosts provide log access to enterprise customers
  3. Accept partial data - For bot detection and abuse monitoring, cache misses are often sufficient since bots typically don’t benefit from cache
  4. Use Agent Analytics directly with a supported CDN - If you have the ability to configure your own Cloudflare, Fastly, or other supported CDN, use our native integrations instead
This limitation is not unique to Agent Analytics. Any WordPress plugin attempting to log HTTP requests faces the same constraint — they can only see what reaches WordPress. The industry standard solution is CDN-native log collection, which we fully support for customers with CDN access.