Troubleshooting Low Cloudflare Cache Hit Rates with Super Page Cache

If your Cloudflare analytics show a low cache hit rate, this guide explains how Super Page Cache controls Cloudflare edge caching, what causes hit rates to drop, and how to diagnose and fix the most common issues.

How Super Page Cache Manages Cloudflare Edge Caching

Super Page Cache controls how long Cloudflare stores your pages at its edge locations by setting a Cache-Control: s-maxage=<seconds> header on every cacheable response. The s-maxage value tells Cloudflare (and other shared caches) exactly how long to serve the cached copy before requesting a fresh one from your origin server.

Because the plugin dynamically sets this TTL header, you do not need to configure a manual Edge TTL in Cloudflare Page Rules. The correct Cloudflare Page Rule setting for this to work is Cache Level: Cache Everything combined with Edge Cache TTL: Respect Origin TTL. Using a fixed Edge TTL value in Cloudflare Page Rules will override the plugin's headers and can cause stale or unexpectedly short cache lifetimes.

📝 Note: For basic Cloudflare integration setup instructions, see How to setup WP Cloudflare Super Page Cache.

Common Causes of Low Cache Hit Rates

A cache hit rate below ~80% usually has one or more of the following causes:

Crawler and Bot Traffic

Automated traffic from search engine crawlers, uptime monitors, and vulnerability scanners frequently sends unique query strings or User-Agent headers. Most of these requests bypass the cache and are counted as misses in Cloudflare analytics, which pulls your overall hit rate down even if real visitors are being served cached pages.

Plugin Exclusion Rules

Super Page Cache automatically excludes certain requests from caching to avoid serving incorrect content. Common exclusions include:

• Logged-in WordPress users
• WooCommerce cart and checkout pages (/cart/, /checkout/, /my-account/)
• Pages that set session cookies or personalization cookies

Every excluded request is a cache miss. If a large portion of your traffic hits excluded pages, your overall hit rate will be lower.

Query Parameters

URLs like example.com/page/?ref=newsletter or example.com/?utm_source=google are treated as unique URLs by Cloudflare. If your site receives a lot of traffic with varied query strings, each unique combination is a separate cache entry that must be warmed individually.

Low or Variable Traffic

Cache entries expire after their TTL. On low-traffic sites, pages may expire before being requested again, resulting in a high proportion of compulsory misses. The hit rate improves naturally as traffic volume increases.

Cloudflare Development Mode

When Development Mode is enabled in your Cloudflare zone, all edge caching is suspended for three hours, and all requests will show as DYNAMIC or BYPASS in cache status headers. Disable this mode unless you are actively making changes that need to bypass the cache.

Step-by-Step Diagnosis and Fixes

Step 1: Check Your Cloudflare Analytics

1. Log in to your Cloudflare dashboard.
2. Select your domain and go to Analytics & Logs → Traffic.
3. Review the Cache Performance section and note your cache hit ratio over a meaningful time window (at least 24 hours).

📝 Note: A hit rate of 85% or higher is a healthy target for most WordPress sites. Rates below 60% usually point to a configuration issue rather than normal traffic variation.

Step 2: Verify the Cloudflare Page Rule

1. In the Cloudflare dashboard, go to Rules → Page Rules for your domain.
2. Find the rule that covers your domain (e.g., example.com/*).
3. Confirm the rule is set to:
   • Cache Level: Cache Everything
   • Edge Cache TTL: Respect Origin TTL
4. If Edge Cache TTL is set to a fixed value (e.g., "4 hours"), change it to Respect Origin TTL and save.

⚠️ Important: Do not add a fixed Edge Cache TTL on top of the plugin's page rule. Doing so overrides the dynamic s-maxage headers that Super Page Cache sets and can cause the cache to either expire too quickly or serve stale content.

Step 3: Review Plugin Exclusion Rules

1. Go to WordPress Admin → Super Page Cache → Settings.
2. Open the Cache tab and review the URLs never to cache and Cookies never to cache fields.
3. Check whether any pages that should be cached are inadvertently listed there.
4. If you use WooCommerce, open the WooCommerce tab and confirm that only cart, checkout, and account pages are excluded — not your product catalog or blog pages.

Step 4: Inspect Response Headers in an Incognito Window

Use your browser's developer tools to check whether a specific page is actually being served from the Cloudflare cache:

1. Open your site in an Incognito / Private browser window (this prevents logged-in cookies from triggering the bypass for logged-in users).

2. Press F12 to open Developer Tools and go to the Network tab.

3. Reload the page and click the first request for your domain.

4. Inspect the Response Headers and look for:

   Header	Expected value	What it means
   cf-cache-status	HIT	Cloudflare served this from its edge cache
   X-Wp-Cf-Super-Cache-Active	1	Super Page Cache is active for this request
   X-Wp-Spc-Disk-Cache	HIT	The origin server served a disk-cached copy
   Cache-Control	contains s-maxage=<seconds>	Plugin is setting the TTL correctly

   If cf-cache-status shows MISS, the first request after a cache expiry is expected. Reload once more — if it then shows HIT, the cache is working correctly.

   If cf-cache-status shows BYPASS or DYNAMIC consistently, review the exclusion rules and Cloudflare settings described above.

Step 5: Handle Query Parameters

If your Cloudflare analytics show many unique URLs differing only in query strings (such as UTM parameters), you can instruct Cloudflare to ignore those parameters when looking up cache entries:

1. In the Cloudflare dashboard, go to Rules → Cache Rules (or Page Rules).
2. Add a rule that strips or ignores known tracking parameters (e.g., utm_source, utm_medium, fbclid, gclid) before the cache lookup.

Alternatively, Super Page Cache's Advanced settings include an option to normalize URLs by stripping query parameters before caching. Review those options in WordPress Admin → Super Page Cache → Settings → Advanced.

📝 Note: Only strip query parameters that your site does not use for content variation. Never strip parameters that change the actual content of a page (for example, pagination or search query parameters).

Step 6: Disable Cloudflare Development Mode

1. In the Cloudflare dashboard, go to Caching → Configuration for your domain.
2. Confirm that Development Mode is set to Off.
3. If it was on, wait up to 5 minutes for the setting to propagate, then re-check your cache headers.

Verifying the Fix

After making any of the changes above:

1. Purge the Cloudflare cache: in your Cloudflare dashboard go to Caching → Configuration → Purge Cache → Purge Everything.
2. You can also purge from within the plugin by clicking the Purge Cache button in WordPress Admin → Super Page Cache.
3. Wait for real or test traffic to warm the cache (at least a few minutes).
4. Check cf-cache-status: HIT in an incognito window as described in Step 4.
5. Monitor Cloudflare Analytics → Cache Performance over the following 24 hours to confirm the hit rate has improved.

💡 Tip: A single cold visit (first load after purge) will always show cf-cache-status: MISS — that is expected. The second and subsequent visits to the same URL should show HIT. Always test by loading a page twice and checking the second request.