WordPress Cache Not Working: 10 Fixes That Actually Work

You installed WP Rocket. Or WP Super Cache. You cleared the cache, refreshed the page, and... nothing changed. Your site still feels slow. Speed tests show the same TTFB as before.

Problem: Your cache plugin isn't actually caching anything. Or it's caching, but the wrong things. Or there are two cache plugins fighting each other. Or your hosting provider is running their own cache and blocking yours.

The first step isn't "update the settings." It's "verify caching is actually working." Then we fix what's broken.

How to Verify Caching Is Actually Working

Before you troubleshoot, confirm caching is even enabled.

Method 1: Check the HTML Footer (Easiest)

For WP Rocket only:

  1. Go to an incognito/private window (to avoid browser cache)
  2. Visit your homepage
  3. Right-click > View Page Source
  4. Scroll to the very bottom of the HTML
  5. Look for a line like this:
<!-- This website is like a Rocket, isn't it? Performance optimized by WP Rocket. Learn more: https://wp-rocket.me - Debug: cached@1730272532 -->

If you see this comment: ✅ WP Rocket is caching this page. Timestamp (1730272532) shows when cache was created.

If you DON'T see this comment: ❌ WP Rocket is NOT caching this page. Continue to Fixes #1-10 to find out why.

Method 2: Check Cache Directory via FTP (Advanced)

For any cache plugin:

  1. Connect via FTP (FileZilla, WinSCP, etc.)
  2. Navigate to: /wp-content/cache/
  3. Look for subdirectories and files
  4. Visit your site in an incognito window
  5. Check if new files were created in the cache folder

If files exist and timestamps update: ✅ Caching is working.

If no cache folder exists or it's empty: ❌ Cache files aren't being created. Continue to Fixes #1-10.

Method 3: Check Browser DevTools (Most Detailed)

  1. Open your site in incognito window
  2. Press F12 > Network tab
  3. Refresh the page
  4. Click the first HTML document request
  5. Look at Response Headers for one of these:

WP Rocket headers:

X-Rocket-Powered-By: WP Rocket/3.15
Cache-Control: max-age=0, public

WP Super Cache headers:

X-WP-Super-Cache: Cached

W3 Total Cache headers:

X-Powered-By: W3 Total Cache

If you see these headers: ✅ Cache headers are being sent (good sign).

If you DON'T see cache headers: ❌ Either caching is disabled or not running.

The 10 Fixes (In Priority Order)

Fix #1: Disable Other Cache Plugins (Most Common)

The problem: Running two cache plugins simultaneously is like running two security guards at the same door. They fight each other, create conflicts, and often disable themselves.

The fix:

  1. Go to Plugins > Installed Plugins
  2. Search for any other cache plugins: WP Rocket, WP Super Cache, W3 Total Cache, WP Fastest Cache, Comet Cache, Cachify, LiteSpeed Cache, etc.
  3. Deactivate and delete all but ONE cache plugin
  4. Keep only the ONE you want to use
  5. Clear cache
  6. Test the footer comment or DevTools headers again

Red flag: Did you install a new cache plugin and forget you had one installed already? This is the #1 reason cache "stops working."

Expected result: After removing the second plugin, cache headers appear and site speeds up immediately.

Fix #2: Verify You're NOT Logged In

The problem: Most cache plugins have "User Cache" disabled by default. Logged-in users aren't cached because WordPress shows different content (admin bar, personalized messages, etc.). So if you test while logged in, you'll see stale cache data.

The fix:

  1. Open an incognito/private window (a completely separate browser session, not just a new tab)
  2. Visit your site
  3. Check the HTML footer or DevTools for cache headers

Why incognito? Incognito windows automatically clear cookies, so you're not logged in.

Alternative: If you want logged-in users cached too (e.g., on a private membership site), go to your cache plugin settings and enable "Cache for logged-in users" or "User Cache."

Expected result: Cache headers appear when tested from incognito window.

Fix #3: Check WP_CACHE Constant (For WP Rocket & W3 Total Cache)

The problem: WordPress has a native constant called WP_CACHE. If it's set to false, some cache plugins won't work.

The fix:

  1. Connect via FTP or File Manager
  2. Open /wp-config.php (in WordPress root directory)
  3. Search for: define( 'WP_CACHE', false ); or define( 'WP_CACHE', true );
  4. If it says false, change it to: define( 'WP_CACHE', true );
  5. Save the file
  6. Clear cache and test again

If WP_CACHE doesn't exist in wp-config.php: That's fine. Most hosting providers don't define it, and most cache plugins handle this automatically.

Red flag: Some hosting providers deliberately set WP_CACHE to false because they want you to use their server-level cache instead. In that case, ignore this step — use Fix #9 (server-level cache).

Expected result: After setting to true, cache headers appear.

Fix #4: Check for Missing wp-rocket-config Directory (WP Rocket Only)

The problem: WP Rocket stores its configuration in a special directory called wp-rocket-config. If this directory doesn't exist or doesn't have write permissions, WP Rocket can't save cache.

The fix:

  1. Connect via FTP
  2. Navigate to /wp-content/
  3. Look for a folder called wp-rocket-config
  4. If it doesn't exist, create it manually
  5. Set permissions to 755 (read/write for server)
  6. Go back to WordPress dashboard
  7. Deactivate and reactivate WP Rocket (forces it to recreate its config)
  8. Test caching again

Alternative (easier): In WordPress, go to WP Rocket > Settings > Advanced. Click "Reset WP Rocket." This forces it to detect and set up the directory correctly.

Expected result: After directory is created, WP Rocket settings become available and caching starts.

Fix #5: Clear All Cache Layers (Not Just Plugin Cache)

The problem: Your site has multiple cache layers: plugin cache, CDN cache, browser cache, and possibly server-level cache (Varnish, Nginx). Clearing only the plugin cache doesn't clear the others.

The fix (Proper Order):

  1. Clear plugin cache first: Go to your cache plugin settings > Clear Cache button
  2. Clear CDN cache second: If using Cloudflare, go to Cloudflare dashboard > Caching > Purge Everything
  3. Clear browser cache last: Hard refresh in your browser (Ctrl+Shift+R on Windows, Cmd+Shift+R on Mac)

Why this order matters: If you clear CDN first, it refills from plugin cache (which still has old version). If you clear browser first, you're not clearing the actual issue.

For WP Rocket + Cloudflare: WP Rocket has a built-in integration. Go to WP Rocket > Settings > Advanced > Cloudflare API Token. This lets WP Rocket automatically purge Cloudflare when you clear cache.

Expected result: New content shows up immediately after clearing in the proper order.

Fix #6: Exclude Dynamic Pages (Cart, Checkout, My Account)

The problem: Some pages should NEVER be cached because they show personalized content. Caching these pages shows stale data to users.

Common pages to exclude:

  • WooCommerce Cart (/cart/)
  • WooCommerce Checkout (/checkout/)
  • WooCommerce My Account (/my-account/)
  • Any custom login page
  • Admin pages (usually auto-excluded)

The fix (WP Rocket):

  1. Go to WP Rocket > Settings > Advanced Rules > Never Cache URLs
  2. Add each dynamic page URL, one per line:
/cart
/checkout
/my-account
  1. Save
  2. Clear cache
  3. Test those pages — they should now show fresh content every time

The fix (WP Super Cache):

  1. Go to WP Super Cache > Advanced > Never cache the following pages:
  2. Add the same URLs
  3. Save

Expected result: Cart and checkout always show current data, while other pages remain cached.

Fix #7: Disable Plugins That Block Caching

The problem: Some plugins or themes intentionally set a WordPress constant called DONOTCACHEPAGE to prevent caching. This can be legitimate (e.g., for dynamic content) or a mistake (plugin author forgot to remove it).

The fix:

  1. Disable plugins one by one (in incognito window, test caching after each)
  2. When cache headers reappear, you found the culprit
  3. Either update the plugin, disable it, or contact the author

Common culprits:

  • Analytics plugins trying to track every user
  • E-commerce plugins with overly aggressive personalization
  • Membership plugins preventing cache
  • Custom development plugins with debugging code

To verify DONOTCACHEPAGE is being set: Add this code to your theme's functions.php temporarily:

if ( defined( 'DONOTCACHEPAGE' ) ) {
  error_log( 'DONOTCACHEPAGE is set' );
}

Then check /wp-content/debug.log to see if the message appears.

Expected result: After disabling the problematic plugin, cache headers return.

Fix #8: Check for Query Strings (Posts Not Being Cached)

The problem: URLs with query strings (like example.com/?v=1 or example.com/?utm_source=google) are often not cached by default because they're considered "dynamic" (different for each visitor).

The fix (WP Rocket):

  1. Go to WP Rocket > Settings > Advanced Rules > Cache Query Strings
  2. Enable "Cache Query Strings"
  3. Add the query string parameters you want cached (e.g., v, utm_source)
  4. Save

The fix (WP Super Cache):

  1. Go to WP Super Cache > Advanced
  2. Enable "Cache query strings" option
  3. Save

Be careful: Caching query strings means each variation is cached separately. example.com/?v=1, example.com/?v=2, example.com/?v=3 are three different cached files. Only cache query strings you actually use.

Expected result: Pages with query strings now show cache headers.

Fix #9: Check Server-Level Caching (Hosting Provider)

The problem: Your hosting provider might be running server-level caching (Varnish, Nginx FastCGI Cache, LiteSpeed Cache) that overrides or conflicts with your plugin cache.

The fix:

  1. Contact your hosting provider
  2. Ask: "Do you have server-level caching enabled (Varnish, Nginx, LiteSpeed)?"
  3. If yes: "Is it enabled by default, or should I manage caching via a plugin?"

Common scenarios:

Scenario 1: Host says "We manage caching at the server level. Don't use a plugin." → Deactivate your cache plugin. Your host is handling it.

Scenario 2: Host says "Use LiteSpeed Cache plugin if you want plugin-level caching." → Install LiteSpeed Cache (free). It integrates with their server.

Scenario 3: Host says "You can use any cache plugin." → Keep your current plugin. Their server cache and your plugin will work together.

Red flag: If your host runs Varnish or Nginx but won't let you manage it, you're limited to whatever their defaults are. This is a common complaint about cheap shared hosting.

Expected result: After confirming with your host, caching is either actively working (via plugin or server) or you understand why it's not.

Fix #10: Upgrade to Better Hosting

The problem: Some cheap shared hosting providers actively block or disable caching plugins. They don't want you speeding up sites on their oversold servers.

The fix:

Red flags your host blocks caching:

  • Cache plugin installed but shows "disabled" or "not configured"
  • Cache files aren't being created even after Fixes #1-9
  • Host support says "caching isn't supported on this plan"
  • Host removes wp-rocket-config directory or resets file permissions

If this is happening: Your host doesn't want you optimizing. Switch to a host that supports performance:

Budget option ($15-30/mo): SiteGround, Kinsta (entry), WP Engine (entry)

Value option ($30-50/mo): Hostinger WordPress, Cloudways, Bluehost (managed WordPress)

Premium option ($50+/mo): Kinsta, WP Engine, Pagely

Expected result: After moving to a host that supports caching plugins, they work immediately without configuration.

Diagnostic Flowchart

  1. Is cache enabled in the plugin? → Check plugin Settings > Is "Enable Caching" toggled on?
  2. Are you logged in? → Test in incognito window. Logged-in users aren't cached by default.
  3. Do cache headers appear in DevTools? → If no, apply Fixes #1-4 (conflicting plugins, WP_CACHE, wp-rocket-config)
  4. Are you caching dynamic pages? → If cart/checkout are cached, apply Fix #6 (exclude them)
  5. Is a plugin blocking cache? → If cache disappears after enabling a plugin, apply Fix #7 (DONOTCACHEPAGE)
  6. Do pages with query strings not cache? → Apply Fix #8 (cache query strings)
  7. Does nothing work? → Verify with your host (Fix #9), or upgrade hosting (Fix #10)

FAQ

Q: I cleared cache but old content still shows. Why?

A: You cleared the plugin cache but not other layers. Clear in this order: (1) plugin cache, (2) CDN cache (Cloudflare, etc.), (3) browser cache (hard refresh). Each layer can serve stale content from the one below it.

Q: Cache works on homepage but not other pages. Why?

A: Some pages might be excluded from caching (dynamic pages, query strings) or a plugin is blocking them. Check WP Rocket > Advanced Rules to see what's excluded. Or a plugin might be setting DONOTCACHEPAGE on those specific pages only.

Q: Should I enable "User Cache" (caching for logged-in users)?

A: Only if you run a membership site or need logged-in users to see cached content. For public sites, leave it disabled (default). Logged-in users get personalized content anyway (admin bar, messages, etc.).

Q: Why is my hosting provider's cache better/worse than my plugin?

A: Server-level cache (LiteSpeed, Varnish) is often faster because it sits lower in the stack. But plugin-level cache (WP Rocket) gives you more control. Best case: both work together. Ask your host how they interact.

Q: If I have two cache plugins, do they double the speed?

A: No. They create conflicts and often cancel each other out. Use exactly ONE cache plugin. If your host has server-level cache, use that (don't add a plugin). If your host doesn't have cache, use a plugin.

The Real Talk

Cache not working usually isn't a mystery. It's one of three things:

  1. Two plugins fighting: Delete the extra one (Fix #1)
  2. Testing while logged in: Use incognito window (Fix #2)
  3. Host blocking it: Contact support or switch hosts (Fixes #9-10)

Before changing 50 settings, verify caching is actually enabled. Check the HTML footer or DevTools headers. If you don't see cache headers, caching isn't working, and you need to find out why.

Once caching works, your site speed improves 50-70% automatically. That's not hyperbole — it's the difference between generating a page from scratch (PHP + database) and serving a static file.

Get caching working. Everything else is fine-tuning.