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 create or configure caching rules in Cloudflare manually. When you enable Cloudflare caching, Super Page Cache automatically creates a Cloudflare Cache Rule that caches eligible pages and respects the cache headers the plugin sends. Adding a separate rule with a fixed Edge Cache TTL — for example, a manual Page Rule — overrides the plugin's headers and can cause stale or unexpectedly short cache lifetimes.

📝 Note: Current versions of Super Page Cache use a Cloudflare Cache Rule and no longer create a Cloudflare Page Rule. Page Rules are legacy. If you do not see a Page Rule for your domain, that is expected — there is nothing to add.

📝 Note: For basic Cloudflare integration setup instructions, see How to setup 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.

This is especially common on publishing and news sites that get social traffic from Facebook. Links opened in the Facebook in-app browser often include the fbclid parameter, and campaign links add utm_* parameters. Without normalization, these tracking parameters can fragment the cache and lower your Cloudflare hit rate.

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 Cache Rule

Super Page Cache automatically creates a Cloudflare Cache Rule when you enable Cloudflare caching — you do not need to create one manually. To confirm it is in place:

1. In the Cloudflare dashboard, go to Caching → Cache Rules for your domain.
2. Confirm that a Cache Rule created by Super Page Cache is present and enabled.
3. The rule is configured to cache eligible pages and to respect the cache headers the plugin sends, so you do not need to set a fixed Edge Cache TTL.

⚠️ Important: Do not add a fixed Edge Cache TTL through a separate Cloudflare 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. If you still have an old Cache Everything Page Rule under Rules → Page Rules from a previous setup, remove it — current versions of the plugin use a Cache Rule instead, and a leftover Page Rule can conflict with it.

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 Cloudflare analytics show many URL variants that differ only by tracking parameters (especially fbclid and utm_* on social/news traffic), use the plugin's Ignore Marketing Parameters feature instead of bypassing all query-string URLs.

1. In WordPress Admin → Super Page Cache → Settings → General, find Ignore Marketing Parameters (Pro).
2. Enable the setting, then review the parameter list and keep/add tracking keys such as fbclid, utm_source, utm_medium, utm_campaign, and similar campaign parameters that do not change visible page content.
3. Click Save Settings, then purge cache so Cloudflare rebuilds entries using normalized cache keys.

For detailed Ignore Marketing Parameters setup steps, see Bypass Cache for Specific Query Parameters.

📝 Note: Do not globally bypass all URLs with query strings when those parameters are only used for tracking. Only ignore parameters that do not change visible page content. Never ignore parameters used for pagination, search results, filtering, or any other content-changing behavior.

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.

If Super Page Cache Did Not Create a Cloudflare Cache Rule

When Cloudflare caching is enabled, Super Page Cache automatically creates and manages a Cache Rule in your Cloudflare zone (labeled [DO NOT EDIT] WP Super Page Cache Plugin rules for...). That rule, together with the s-maxage headers described above, is what tells Cloudflare to cache your pages. If your cache hit rate is low because no rule was created, work through the checks below.

📝 Note: Super Page Cache uses Cloudflare Cache Rules, not the older Page Rules. Look under Caching → Cache Rules in the Cloudflare dashboard — not Rules → Page Rules. The plugin also removes any legacy Page Rules it previously created, so an empty Page Rules list is expected.

Confirm Cloudflare caching is enabled

Super Page Cache only creates and manages the Cloudflare Cache Rule while caching is turned on.

1. Go to WordPress Admin → Super Page Cache → Settings → Cloudflare.
2. Confirm Enable Cloudflare CDN & Caching is ON.
3. Make sure the correct zone is selected for your domain, then click Save Settings.

Confirm the API token can edit Cache Rules

A Cloudflare API token can connect successfully but still fail to create or edit rules if it lacks the right permissions. Super Page Cache needs two permissions that Cloudflare's WordPress token template does not add for you:

• Zone → Cache Rules → Edit
• Zone → Transform Rules → Edit

If you created your token from the WordPress template without adding these manually, the connection works but rule creation fails — and regenerating the token from the same template will not help unless you add both permissions. Edit the token in Cloudflare (or create a new one), add both permissions, and re-save it in the plugin. For full token setup steps, see Super Page Cache Cloudflare Permissions.

Retry automatic rule creation

After confirming the setting and token permissions, force the plugin to recreate the rule:

1. Go to Super Page Cache → Settings → Cloudflare.
2. Turn Enable Cloudflare CDN & Caching OFF and click Save Settings.
3. Turn it back ON and click Save Settings again.
4. In the Cloudflare dashboard, open Caching → Cache Rules and confirm the plugin's rule is now present.

Check the plugin logs for Cloudflare API errors

If the rule still is not created, the Cloudflare API is likely rejecting the request.

1. Go to Super Page Cache → Advanced → Logs Settings and enable Log Mode.
2. Reproduce the issue by toggling Enable Cloudflare CDN & Caching off and on again.
3. Review the log for Cloudflare API errors. Messages mentioning permissions or authorization confirm the token is missing the Cache Rules or Transform Rules edit permissions listed above.

After the rule appears, confirm caching is working by checking the response headers in an incognito window, as described in Step 4: Inspect Response Headers in an Incognito Window above.

📝 Note: The cached page/object count shown on the Super Page Cache dashboard refers to pages stored in the plugin's own disk cache. It is not the same as your Cloudflare cache hit ratio, and it is unrelated to persistent object cache tools such as Docket Cache.

Recommended settings for news and social-media traffic

If your site gets high traffic from Facebook, Google Discover, newsletters, or campaign-tagged links, start with this Super Page Cache Pro baseline:

• Cloudflare tab → Enable Cloudflare CDN & Caching: ON.
• General tab → Enable Disk Page Cache: ON.
• Advanced tab → Cloudflare Cache Behavior → Automatically Purge Cloudflare's Cache When Something Changes: keep this enabled and use Purge cache for related pages only.
• Advanced tab → Cache → Disable Cache Purging Using Queue: OFF (recommended). This keeps purge queueing enabled. Turn it on only if you are troubleshooting WP-Cron/queue execution issues.
• General tab → Ignore Marketing Parameters (Pro): ON, and make sure the parameter list includes fbclid, utm_source, utm_medium, utm_campaign, and any other tracking keys that do not change page content.
• Advanced tab → Cache → Strip Response Cookies: keep OFF unless you have confirmed the cookies are safe to remove.
• Advanced tab → Preloader → Enable Preloader: ON.
• Advanced tab → Preloader → Automatically Preload Pages You Have Purged From Cache: ON.
• Advanced tab → Preloader → Preloader Operation: include recently updated content so fresh news/article pages are warmed quickly after purge.

Handling Facebook fbclid and campaign parameters

Facebook and campaign platforms append tracking parameters to article URLs. Cloudflare treats each unique query-string version as a different cache key, so one article can be cached many times (/story/, /story/?fbclid=..., /story/?utm_source=...), reducing hit rate.

Use Ignore Marketing Parameters (Pro) to normalize these tracking variants into the same cache entry. Do not use global "don't cache pages with query args" behavior for this case, because that can force unnecessary cache bypasses on traffic that could otherwise be served from cache.

Ads, analytics, consent, and paywall caveats

Google AdSense and Google Analytics scripts run in the visitor's browser, so ignoring server-side tracking parameters for cache keys does not stop those client-side scripts from loading.

⚠️ Important: On publishing sites, review cookie-based exclusions carefully. Keep or add exclusions for cookie patterns used by consent/CMP tools, paywalls, memberships, geo-targeting, or other personalization logic so cached pages are not shared with the wrong visitor state.

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.