Themeisle Docs

Appearance

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 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 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:

    HeaderExpected valueWhat it means
    cf-cache-statusHITCloudflare served this from its edge cache
    X-Wp-Cf-Super-Cache-Active1Super Page Cache is active for this request
    X-Wp-Spc-Disk-CacheHITThe origin server served a disk-cached copy
    Cache-Controlcontains 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 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.

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.