Themeisle Docs

Appearance

Troubleshooting "Cloudflare integration has an issue" ​

If you see "Cloudflare integration has an issue" or "Disk Page Caching has an issue" after clicking Test Cache, the warning can be confusing. In many cases, the plugin's test request did not get the expected result, but visitor-facing caching is still working.

What the Test Cache warning means ​

The Test Cache warning means the plugin's internal check did not receive the expected cache response during that test run. It does not always mean caching is broken for your visitors.

📝 Note: Test Cache warnings can be generic. You may only see a high-level warning (for Cloudflare or Disk Page Caching) without a detailed per-failure error in the popup.

Are detailed Test Cache logs available? ​

At this time, there is no separate interface that shows detailed, per-test diagnostics for every Test Cache failure.

To investigate further, use practical checks:

  • Inspect live response headers in your browser (steps below).
  • If needed, enable Log Mode under Super Page Cache > Advanced > Logs Settings and review the plugin log for related cache activity.
  • Check your hosting/server logs and firewall/security logs for blocked loopback or REST API requests.

How to Verify if your Cache is Actually Working ​

Before troubleshooting, check if the cache is live by inspecting your site headers:

  1. Open your site in an Incognito/Private browser window.

  2. Open the Network tab in your browser's Developer Tools (F12 or Right-click > Inspect).

  3. Purge the cache once from Super Page Cache, then load your homepage twice.

  4. Click on your main domain request in the Network list.

    Look for these successful indicators in the Response Headers:

    • cf-cache-status: HIT : Cloudflare is serving a cached response.
    • X-Wp-Cf-Super-Cache-Active: 1 : Super Page Cache is active for Cloudflare integration.
    • X-Wp-Spc-Disk-Cache: HIT : Super Page Cache local disk cache is working.

Note: On the first load after a purge, cf-cache-status may show MISS or EXPIRED. Reload once more and check again.

If both Cloudflare and Disk Page Caching show an issue ​

Use this quick decision path after checking headers:

  • If you see cf-cache-status: HIT, X-Wp-Cf-Super-Cache-Active: 1, and X-Wp-Spc-Disk-Cache: HIT, caching is working and the dashboard warning is likely a false positive.
  • If you see X-Wp-Cf-Super-Cache-Active: 1 and X-Wp-Spc-Disk-Cache: HIT but cf-cache-status: BYPASS, Super Page Cache is active but Cloudflare is intentionally not storing that response at the edge. Continue with the BYPASS checks below.
  • If one or more headers are missing, continue with the troubleshooting checks below.

If Cloudflare shows BYPASS but Super Page Cache is active ​

This combination usually means Cloudflare can reach your origin and Super Page Cache is working, but Cloudflare is refusing to cache the HTML response because of response headers.

In most cases, this is not a Cloudflare API connection failure.

Check for cookies and restrictive cache headers ​

Use an Incognito/Private window and check the homepage request in Developer Tools > Network:

  • Check Set-Cookie in the response headers. If cookies are present, Cloudflare may bypass edge caching for that page.
  • Check Cache-Control in the response headers. Values like no-cache, no-store, or private can force a BYPASS.

Fix BYPASS safely ​

  1. Remove or reconfigure plugins/services that add unnecessary response cookies on public cacheable pages.
  2. If needed, enable Super Page Cache > Settings > Advanced > Cache > Strip Response Cookies.
  3. Keep personalized pages excluded from cache (for example cart, checkout, login, account, membership, or other user-specific pages).
  4. In Cloudflare, confirm Development Mode is disabled.
  5. Purge cache in Super Page Cache and Cloudflare, then reload the page twice in Incognito.

⚠️ Warning: Enable Strip Response Cookies only for pages that are safe to cache for all visitors. Do not force-cache pages that contain personalized or logged-in user content.

Verify the result ​

After applying the changes:

  1. Open the same page in an Incognito/Private window.
  2. Load once, then reload.
  3. Confirm these headers are present:
    • cf-cache-status: HIT
    • X-Wp-Cf-Super-Cache-Active: 1
    • X-Wp-Spc-Disk-Cache: HIT

Note: Cloudflare cache ratio in the dashboard includes all zone traffic. A low ratio does not always mean your cacheable HTML pages are failing to cache.

Why the Dashboard Shows an "Issue" (Common Causes) ​

If your headers show a HIT  but the dashboard shows an error, it is usually due to one of the following:

  • Server-Side Security/Firewalls: Many web hosts use security modules (like ModSecurity or BitNinja) that block "loopback" requests. The plugin tries to "talk to itself" to verify the cache, and the firewall flags this as suspicious behavior.
  • DNS Resolution: Sometimes your server resolves your domain name to its local internal IP address rather than the Cloudflare IP. Because it skips the Cloudflare network during the test, it cannot see the Cloudflare headers.
  • REST API Blocks: If you have plugins that restrict access to the WordPress REST API or certain query parameters, the test script may be unable to complete its check.

How to Resolve the Warning ​

  1. Confirm key cache settings: In Super Page Cache, make sure Enable Disk Page Cache and Enable Cloudflare CDN & Caching are enabled.
  2. Check firewall and loopback restrictions: Ask your host to whitelist your server IP and review ModSecurity/BitNinja/WAF rules that may block loopback requests.
  3. Verify DNS and Cloudflare routing: Confirm your domain resolves through Cloudflare correctly during cache tests.
  4. Check REST API and security restrictions: Temporarily disable or relax security rules/plugins that block REST API calls or test query parameters.
  5. Check for plugin conflicts: Temporarily disable other cache, optimization, or security plugins and run Test Cache again.

Preloader returns 403 when Cloudflare Bot Fight Mode is enabled ​

When the Super Page Cache preloader is running, it sends automated requests to your site to warm the cache. Cloudflare's Bot Fight Mode can classify these origin-server requests as suspicious bot traffic and block them with a 403 Forbidden response.

Why this happens ​

Bot Fight Mode analyzes request patterns and may flag the preloader's automated crawl because it originates from the same server as your WordPress installation rather than from a real browser. This is a Cloudflare security classification, not a plugin error.

How to resolve 403 preloader blocks ​

Choose one of the following options depending on your Cloudflare plan:

  1. Disable Bot Fight Mode — In the Cloudflare dashboard, go to Security > Bots and turn off Bot Fight Mode. This is the most direct fix but removes bot protection site-wide.

  2. Switch to Super Bot Fight Mode (Business and Enterprise plans) — Super Bot Fight Mode allows more granular control. Set Definitely automated traffic to Allow or create skip rules for your origin server's IP address.

  3. Create a WAF skip rule for your origin IP (Pro plan and above) — In the Cloudflare dashboard, go to Security > WAF > Custom Rules and create a rule that skips Bot Fight Mode checks for requests originating from your server's IP address. This lets preload requests through without disabling bot protection globally.

⚠️ Important: The ability to bypass or create exceptions for Bot Fight Mode depends on your Cloudflare plan. On the free plan, Bot Fight Mode cannot be bypassed with a rule — you must disable it entirely or accept that preload requests may be blocked. Upgrading to a paid plan provides more targeted control.

Preloader is requesting HTTP URLs instead of HTTPS ​

If you notice the Super Page Cache preloader fetching http:// URLs instead of https://, the plugin is not generating these URLs incorrectly. The preloader reads URLs directly from your WordPress configuration and sitemap data. If those sources contain http:// entries, the preloader will use them.

What to check ​

  1. WordPress site URL settings — Go to Settings > General in your WordPress admin and confirm both WordPress Address (URL) and Site Address (URL) are set to https://. If either still shows http://, update it and save.

  2. SEO or sitemap plugin settings — Open your SEO plugin (such as Yoast SEO, Rank Math, or All in One SEO) and check the canonical URL and sitemap base URL settings. Ensure the site URL used for sitemap generation is https://.

  3. Regenerate your sitemap — After confirming the URL settings above, regenerate your sitemap so it no longer contains http:// entries. In most SEO plugins this option is under the sitemap settings panel.

  4. Clear all caches — After updating URLs and regenerating the sitemap, purge the Super Page Cache and the Cloudflare cache so the preloader picks up the updated HTTPS URLs on its next run.

  5. Check for legacy HTTP entries in the database — If your site was previously served over HTTP, old http:// URLs may still exist in post content, options, or metadata. Use a search-and-replace tool (such as the Better Search Replace plugin) to update remaining http://yourdomain.com entries to https://yourdomain.com across the database.

📝 Note: SSL/HTTPS must be active on your server and Cloudflare must be configured to use Full or Full (Strict) SSL mode for HTTPS preload requests to succeed end-to-end.

How to verify the fix ​

After applying any of the changes above, confirm the issue is resolved:

  1. Run the preloader again — In Super Page Cache, trigger a manual cache preload.
  2. Check for 403 responses — Monitor your Cloudflare Security > Events log (or the plugin's Log Mode output under Super Page Cache > Advanced > Logs Settings) and confirm preloader requests are no longer blocked.
  3. Confirm preload URLs use HTTPS — Review the plugin log or your server access log during preloading and verify all requested URLs begin with https://.
  4. Inspect response headers — Load your homepage in an Incognito window after preloading and confirm cf-cache-status: HIT and X-Wp-Spc-Disk-Cache: HIT are present, indicating cached responses are being served.