Common Problems and Troubleshooting

This guide is organized by symptom. Find the problem that matches what you are seeing, read the likely cause, then follow the fix. Every fix uses real xSpeed Cache settings and screens.

Tip: Most cache problems are solved by a purge. Click Purge in the xSpeed Cache dashboard, or use Purge All from the xSpeed Cache admin bar menu, then reload the page before digging deeper.

My changes don’t show up

You edited a post, page, or setting, but visitors (or you, while logged out) still see the old version.

Likely cause: the old page is still cached. xSpeed Cache serves the saved HTML copy until that page is purged or its lifetime expires.

Fix:

1. Click Purge in the xSpeed Cache dashboard, or use Purge All from the xSpeed Cache admin bar menu.
2. Reload the page in a logged-out browser or a private window.

xSpeed Cache also purges on its own when you publish or update content, change settings, or switch themes. If a change still does not appear after a purge, check that you are testing while logged out, since logged-in users are never served from the page cache anyway.

CSS or JavaScript changes don’t show up

You changed a stylesheet or script, but the browser keeps loading the old one.

Likely cause: browser cache. Static files are cached by the visitor’s browser for a long time on purpose. The default Static asset TTL is one year, and those files are also marked immutable.

Fix:

• Do a hard reload while testing (this bypasses the browser’s own copy).
• Make sure changed files are served under new names. Fingerprinted asset names change when the file changes, so the browser fetches the new version automatically.
• If you minify or combine, purge the xSpeed Cache so the combined file is rebuilt.

Cache header always shows MISS

You are checking the X-XSpeed-Cache response header and it never shows HIT.

Likely causes and fixes:

• You are logged in. Page cache only applies to logged-out visitors. Logged-in users, admin screens, AJAX, cron, and REST requests are never served from the page cache. Test in a private window.
• The request is not a GET. Only GET requests are eligible for the page cache. A POST (for example, a form submission) will always miss.
• The URL is excluded. Check the Excluded URLs field. If the path is listed, it is skipped on purpose.
• An excluded cookie is present. If the request carries a cookie on the exclusion list (for example, a logged-in or cart cookie), the page is not cached.
• A query parameter is not on the ignored list. A URL with an unrecognized query string is treated as unique and may keep missing. Add the parameter to the ignored query parameters list if it is safe to ignore.

The first visit to any page is always a MISS because nothing is cached yet. The second visit to the same URL should be a HIT. To avoid that first slow hit, turn on the Cache Preloader to warm pages ahead of time.

Cache header shows MISS even on the second visit

The page misses every time, even on repeat loads of the same URL.

Likely cause: a separate cache bucket is being created per request, usually from a varying cookie or query string, or the page is genuinely excluded.

Fix: review the exclusion settings (URLs, cookies, and ignored query parameters). A cookie that changes on every request, or a tracking query parameter that is not ignored, makes each request look unique so it never reuses a cached copy. See the exclusions guide for how to add cookie patterns and ignored query parameters.

Caching is on, but the static-file rewrite isn’t engaged

The Cache panel warns that caching is on but the static-rewrite block is not serving hits, so xSpeed Cache is falling back to the slower PHP drop-in path. The Health panel under the cache diagnostics shows the same.

What to do depends on your server.

Apache

The Health check Static-file rewrite (.htaccess) explains the state:

• Block missing from .htaccess. Toggle Enable Cache off and on to reinstall the block.
• Block installed but the probe failed. Confirm the xSpeed Cache .htaccess block is at the top of the file, and that AllowOverride is enabled for your site so mod_rewrite reads it.

nginx

xSpeed Cache cannot write nginx config for you. The Health check Static-file rewrite (nginx server config) ships the snippet to paste.

1. Copy the unified server-block snippet shown on the Cache panel (or the Health check).
2. Paste it into your site’s server { } block.
3. Reload nginx.

Once nginx is serving hits directly, the check turns green and reports PHP is bypassed.

LiteSpeed

On LiteSpeed this is not a problem at all. xSpeed Cache intentionally serves cache hits through its drop-in rather than the .htaccess static rewrite, because LiteSpeed’s .htaccess engine can’t add the X-XSpeed-Cache: HIT header or log a static hit for counting. The Health check Cache serving (LiteSpeed) shows this as the healthy, expected state. Hits are still tagged and counted.

Site looks broken after minify or combine

After turning on minification or combining CSS/JS, your layout breaks, a script stops working, or styles go missing.

Likely cause: a file did not survive being minified or combined with others.

Fix:

1. Turn the minify and combine options off one at a time and reload your site after each, so you know which setting caused it. Enable one option at a time.
2. Purge the cache after each change so combined files are rebuilt.
3. To debug without changing settings, enable WP_DEBUG. xSpeed Cache automatically skips HTML minification when debug mode is on. Developers can also use the xspeed_skip_minify filter.

xSpeed Cache uses safe-minify, which skips files that already look minified and falls back to the original if something looks off. Combining changes load order, so if the problem only appears with combine on, leave combine off for the file type that breaks and keep plain minify on.

Browser cache headers don’t apply on nginx

You turned on Enable browser cache headers, but the Cache-Control and Expires headers never appear on nginx.

Likely cause: on nginx, xSpeed Cache only stores your settings. It cannot edit nginx config, so the directives do nothing until you add them yourself.

Fix:

1. Copy the unified server-block snippet from the Cache panel. The browser-cache directives are included in it.
2. Paste the snippet into your nginx vhost.
3. Reload nginx, then reload one of your pages to confirm the headers are live.

xSpeed Cache keeps showing a notice until it detects the headers are active. This same pattern applies to GZIP on nginx, IIS, and any server xSpeed Cache cannot configure itself: the toggle saves your choice, but you paste a snippet by hand.

No .htaccess rules were written

You enabled GZIP or browser cache on Apache, but no rules appeared in .htaccess.

Likely cause: automatic writing only happens on Apache and LiteSpeed, and the .htaccess file in your site root must exist and be writable. GZIP also needs mod_deflate available.

Fix: confirm your server is Apache or LiteSpeed, make sure .htaccess exists in the site root and is writable, then toggle the setting off and on. If the file cannot be written, fix its permissions or paste the shown snippet by hand.

Object cache won’t connect

The Object Cache panel’s Test connection fails, or enabling the object cache did not finish.

Likely cause: wrong host, port, or password, or the cache server is unreachable.

Fix:

• Run Test connection. The message names the backend and what went wrong, for example that the server did not respond or that authentication failed.
• Check the Redis Host / Redis Port (default 127.0.0.1 and 6379) or Memcached Host / Memcached Port (default 127.0.0.1 and 11211).
• Add the Redis Password if your server requires auth.
• xSpeed Cache will not enable the object cache while the test fails, so fix the connection first, then enable again.

Note: Keep the Connection Timeout (seconds) low, around 1 to 2 seconds, so an unreachable cache server can never stall your pages.

If wp-config.php is not writable, xSpeed Cache still installs its drop-in but cannot write the constants. Paste the snippet shown on the panel into wp-config.php by hand. If a different object-cache.php drop-in is already present, xSpeed Cache backs it up before replacing it.

Cache is configured but pages aren’t being served from it

The drop-in is set up, but cached pages are not being served before WordPress loads.

Likely cause: the WP_CACHE constant is not set. The Health check WP_CACHE constant reports this. xSpeed Cache cannot serve pages through the drop-in until WordPress sees WP_CACHE.

Fix: add this line near the top of wp-config.php, above the line that says “That’s all, stop editing”:

define( 'WP_CACHE', true );

xSpeed Cache normally writes this for you when you enable cache. You only need to add it by hand when wp-config.php is not writable.

The advanced-cache.php drop-in is missing or owned by another plugin

The Health check advanced-cache.php drop-in shows a failure.

Likely cause: the drop-in was removed, or another caching plugin installed its own advanced-cache.php.

Fix: toggle Enable Cache off and on to reinstall the xSpeed Cache drop-in. If another caching plugin is active, deactivate it first (see the conflict section below), since only one page-cache plugin should own the drop-in.

Page cache isn’t caching anything (permalinks)

No pages cache at all, and the Health check Permalinks shows a warning.

Likely cause: your permalinks are set to “Plain”. Page caching needs URL paths to key cached files on.

Fix: go to Settings → Permalinks in WordPress and choose anything other than “Plain”, then save.

Cache directory isn’t writable

The Health check Cache directory writable fails and reports it cannot write to the cache folder.

Likely cause: file permissions on the cache directory (by default wp-content/cache/xspeed).

Fix: adjust the directory’s file permissions so the web server can write to it, then re-check Health. xSpeed Cache cannot save cached pages until this folder is writable.

A plugin conflicts with caching

xSpeed Cache detects other caching and optimization plugins and either refuses to enable an overlapping feature or warns you. Running two page caches at once causes double-caching and unpredictable behavior, so xSpeed Cache blocks the overlap.

When a feature is refused, you see a message like: “[Plugin] is active and handles the same feature. Deactivate it before enabling this in xSpeed Cache.” When a feature is warned, you can still proceed, but xSpeed Cache advises you to test carefully. The Health check Caching plugin conflicts lists any active conflicting plugin.

xSpeed Cache recognizes these plugins. The middle column shows which xSpeed Cache features they block or warn against.

Plugin	xSpeed Cache features affected
WP Rocket	Refuses page cache, HTML/CSS/JS minify, preloader, CDN rewrite, image lazy load
LiteSpeed Cache	Refuses page cache, HTML/CSS/JS minify, preloader, image lazy load; warns on CDN rewrite
W3 Total Cache	Refuses page cache, HTML/CSS/JS minify, preloader; warns on CDN rewrite
WP Super Cache	Refuses page cache, preloader
WP Fastest Cache	Refuses page cache, HTML/CSS/JS minify, preloader, image lazy load
Cache Enabler	Refuses page cache, preloader
Comet Cache	Refuses page cache
Hummingbird	Refuses page cache, HTML/CSS/JS minify, image lazy load; warns on preloader and CDN rewrite
SG Optimizer	Refuses page cache, HTML/CSS/JS minify, preloader; warns on image lazy load
Breeze	Refuses page cache, HTML/CSS/JS minify, preloader; warns on CDN rewrite
Autoptimize	Refuses HTML/CSS/JS minify
FlyingPress	Refuses page cache, HTML/CSS/JS minify, preloader, CDN rewrite, image lazy load
NitroPack	Refuses page cache, HTML/CSS/JS minify, preloader, CDN rewrite, image lazy load
WP-Optimize	Warns on page cache and HTML/CSS/JS minify
Jetpack Boost	Warns on CSS/JS minify and image lazy load
Asset CleanUp	Warns on CSS/JS minify
EWWW Image Optimizer	Refuses image optimization
ShortPixel	Refuses image optimization
Smush	Refuses image optimization; warns on image lazy load

Fix for a refused feature: deactivate the conflicting plugin, then enable the xSpeed Cache feature. As a rule, run only one page-cache plugin at a time.

Fix for a warned feature: you may keep both active, but turn on the overlapping xSpeed Cache feature, then test the affected pages carefully. If you see double minification or layout issues, turn off the overlapping feature in one of the two plugins.

Note: LiteSpeed Cache is a special case at the server level. When xSpeed Cache runs on a LiteSpeed server, it detects LiteSpeed’s server-level caching module and steps back to avoid double-caching. The plugin-level conflict above still applies if the LiteSpeed Cache plugin is active.

Related

• How to Enable Page Cache
• Purging the Cache
• Excluding Pages, URLs, and Cookies from Cache
• Browser Cache Settings
• GZIP Compression
• Setting Up Object Cache (Redis and Memcached)
• Cache Health Dashboard
• Frequently Asked Questions