WordPress caching speeds up your site by storing static versions of dynamic content, but when cache systems malfunction, you'll see outdated content, broken layouts, login loops, or complete site failures. This guide walks through the most common WordPress cache errors you'll encounter in production, showing you exactly how to diagnose each problem and fix it.
Understanding WordPress Cache Layers
Before troubleshooting, understand that WordPress caching happens at multiple levels. Page cache stores full HTML pages. Object cache stores database query results. Browser cache stores assets locally. Opcode cache stores compiled PHP. CDN cache stores content at edge locations.
Most errors stem from cache not clearing when content changes, conflicting cache plugins, or misconfigured rules that cache dynamic content that shouldn't be cached.
Error 1: Content Not Updating After Changes
Symptoms: You publish a post or update a page, but visitors still see the old version. The WordPress admin shows the correct content, but the front end is stuck.
Root Cause: Your cache layer served the old HTML from storage without regenerating it. This happens when the cache clearing hook failed, your cache TTL is too long, or the purge mechanism couldn't reach all cache locations.
Fix:
-
Clear all cache layers manually: - WordPress cache plugin dashboard (WP Rocket, W3 Total Cache, WP Super Cache) - Server-level cache if you're using LiteSpeed, Nginx FastCGI, or Varnish - CDN cache from Cloudflare, Fastly, or your CDN control panel - Browser cache with a hard refresh (Ctrl+F5 or Cmd+Shift+R)
-
Check cache plugin settings and ensure "Clear cache on post update" is enabled.
-
If using object cache (Redis or Memcached), flush it:
# Redis
redis-cli FLUSHALL
# Memcached
echo "flush_all" | nc localhost 11211
- Check file permissions on your cache directory. The web server needs write access:
chown -R www-data:www-data /path/to/wp-content/cache/
chmod -R 755 /path/to/wp-content/cache/
- Verify your cache plugin isn't silently failing. Check PHP error logs and plugin debug logs.
Prevention: Set reasonable cache TTLs. For blogs, 24 hours works well. For e-commerce, keep it under 1 hour for product pages. Configure automatic purge on content updates.
Error 2: Logged-In Users See Cached Pages
Symptoms: Admin bar missing. User-specific content showing wrong data. Shopping carts displaying other users' items. Comments appearing under wrong names.
Root Cause: The cache plugin is serving the same cached page to everyone, including logged-in users who should see personalized content. This is a critical security and functionality issue.
Fix:
-
Check if your cache plugin has "Don't cache pages for logged-in users" enabled. Every major cache plugin has this setting.
-
Verify the cookie exclusion rules. WordPress sets cookies when users log in. Your cache should skip when these cookies exist:
# Apache .htaccess example
SetEnvIf Cookie "wordpress_logged_in" skip-cache=1
# Nginx config example
set $skip_cache 0;
if ($http_cookie ~* "wordpress_logged_in") {
set $skip_cache 1;
}
- If using a CDN, check that
Vary: Cookieheaders are being sent:
curl -I https://yoursite.com | grep -i vary
-
For WP Rocket users, go to Settings → Advanced Rules and ensure "Never cache logged-in user" is active.
-
If you're using server-level cache, add proper bypass rules. For LiteSpeed:
<IfModule LiteSpeed>
CacheLookup on
RewriteRule .* - [E=Cache-Control:vary=cookie]
</IfModule>
Prevention: Never cache pages with user-specific content. Always test your cache configuration by logging in and verifying you see personalized content.
Error 3: White Screen or 500 Error After Enabling Cache
Symptoms: Site becomes completely inaccessible. White screen of death. 500 Internal Server Error. No admin access.
Root Cause: Cache plugin conflicts with server configuration, PHP version incompatibility, memory exhaustion during cache generation, or corrupted .htaccess rules.
Fix:
- Disable the cache plugin via SFTP or SSH. Rename the plugin folder:
cd /path/to/wp-content/plugins/
mv wp-rocket wp-rocket-disabled
- Check if
.htaccesswas modified. Make a backup and restore the default WordPress.htaccess:
# BEGIN WordPress
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress
- Check PHP error logs for the actual error:
tail -f /var/log/php-fpm/error.log
# or
tail -f /home/username/logs/error_log
- Increase PHP memory limit in
wp-config.php:
define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M');
- Clear any existing cache files manually:
rm -rf /path/to/wp-content/cache/*
rm -rf /path/to/wp-content/advanced-cache.php
- Reinstall the cache plugin and enable features one at a time to identify the conflict.
Prevention: Test cache plugins on staging before deploying to production. Check compatibility with your PHP version and server configuration.
Error 4: Mixed Content or Broken Assets
Symptoms: Images or CSS not loading. Console shows mixed content warnings. Layout broken. Site loads but styling is missing.
Root Cause: Cache was generated with HTTP URLs but the site now uses HTTPS, or the cache plugin isn't rewriting URLs correctly.
Fix:
-
Clear all cache completely.
-
Update WordPress site URL settings to use HTTPS. In
wp-config.phpadd:
define('WP_HOME', 'https://yoursite.com');
define('WP_SITEURL', 'https://yoursite.com');
- Run a database search-replace to update all URLs. Use WP-CLI:
wp search-replace 'http://yoursite.com' 'https://yoursite.com' --dry-run
# If the preview looks good, run without --dry-run
wp search-replace 'http://yoursite.com' 'https://yoursite.com'
-
Configure your cache plugin to handle HTTPS correctly. For most plugins, this is automatic after you clear cache.
-
If using a CDN, check that it's configured for HTTPS and has valid SSL.
-
Verify your
wp-content/advanced-cache.phpfile doesn't have hardcoded HTTP URLs.
Prevention: Configure HTTPS before implementing cache. Ensure your CDN supports HTTPS before enabling it.
Error 5: Infinite Login Redirect Loop
Symptoms: After entering correct credentials, you're redirected back to the login page. Cannot access wp-admin. Cookies appear to not be setting.
Root Cause: The cache layer is intercepting the authentication process, caching the redirect response, or blocking cookies.
Fix:
-
Clear browser cookies for your site.
-
Ensure
/wp-admin/and/wp-login.phpare excluded from cache. Check your cache plugin settings and server config:
# Nginx example
location ~* ^/(wp-admin|wp-login\.php) {
set $skip_cache 1;
}
-
Verify your cache plugin has admin pages excluded. This should be default, but check anyway.
-
If using Cloudflare, create a page rule to bypass cache for admin: - URL:
yoursite.com/wp-admin/*- Setting: Cache Level → Bypass -
Check for plugin conflicts. Disable security plugins temporarily to test.
-
Verify your
COOKIE_DOMAINandCOOKIEPATHconstants inwp-config.php. Usually these should not be set unless you have a multisite. -
Test in an incognito window with all cache layers cleared.
Prevention: Never cache admin pages, login pages, or any authentication endpoints. Always test login functionality after cache configuration changes.
Error 6: Dynamic Content Cached (Forms, Carts, Personalization)
Symptoms: Contact forms showing submission success message to all visitors. Shopping cart displaying cached items. Personalized recommendations the same for everyone.
Root Cause: The cache system doesn't recognize which pages contain dynamic content and caches them anyway.
Fix:
-
Identify all pages with dynamic content: - Forms (Contact Form 7, Gravity Forms, WPForms) - E-commerce (cart, checkout, account pages) - Membership areas - Comment sections - Personalized content
-
Exclude these pages from cache. In WP Rocket: - Settings → Advanced Rules → Never Cache URLs - Add
/cart/,/checkout/,/my-account/ -
For pages with both static and dynamic elements, use cache exclusions for specific elements. Many cache plugins support JavaScript-based dynamic content loading.
-
Configure query string exclusions. Pages with
?add-to-cart=or similar should skip cache:
# Nginx
if ($args ~* "add-to-cart|removed_item") {
set $skip_cache 1;
}
-
Use AJAX for dynamic content loading. This lets you cache the page shell while loading personalized data client-side.
-
For WooCommerce, ensure "Cart Fragments" are working. Check that these endpoints aren't cached: -
/?wc-ajax=get_refreshed_fragments-/wp-admin/admin-ajax.php
Prevention: Document all dynamic content on your site. Configure cache exclusions before going live. Test thoroughly with different user states.
Error 7: Mobile Cache Serving Desktop Version
Symptoms: Mobile users see desktop layout. Site not responsive on phones. Pinch-to-zoom required to read content.
Root Cause: Single cache version being served to all devices without detecting user agent.
Fix:
-
Enable separate mobile cache in your cache plugin. Most support this: - WP Rocket: Settings → Cache → Separate cache for mobile - W3 Total Cache: Performance → User Agent Groups
-
Configure proper
Varyheaders:
# Apache
Header append Vary User-Agent
-
Clear cache completely after enabling mobile cache.
-
Test with actual mobile devices or browser DevTools device emulation.
-
If using a CDN, ensure it respects device detection. Cloudflare Polish and other optimization features should be configured correctly.
-
Use responsive design instead of separate mobile templates when possible. Responsive sites cache better because one version serves all devices.
Prevention: Use responsive design. If you must serve different HTML to mobile, configure device detection before implementing cache.
Diagnostic Checklist
When facing any cache issue, work through this checklist:
- [ ] Identify which cache layer is causing the problem (plugin, server, CDN, browser)
- [ ] Clear all cache layers completely
- [ ] Check error logs for PHP errors, warnings, or cache plugin messages
- [ ] Verify file permissions on cache directories
- [ ] Test with cache completely disabled to confirm it's cache-related
- [ ] Check browser DevTools Network tab for cache headers
- [ ] Review recent changes to configuration, plugins, or theme
- [ ] Test in incognito mode to rule out browser cache
- [ ] Verify server resources (disk space, memory, CPU)
- [ ] Check cache plugin debug mode if available
Conclusion
WordPress cache errors are usually fixable once you identify which layer is causing the problem. Work systematically through cache layers—browser, plugin, server, CDN—clearing and testing each. Most issues stem from misconfigured exclusions, conflicting plugins, or cache not clearing properly. The key is understanding your cache architecture and testing thoroughly after every configuration change. Keep cache TTLs reasonable, exclude dynamic content explicitly, and monitor your error logs. When in doubt, disable cache temporarily to confirm it's the source of the problem, then re-enable features one at a time.
