LiteSpeed Cache Keeps Saying MISS? How to Find Out Why

You installed LiteSpeed Cache, turned it on, and the site still feels like it's rebuilding every page on every visit. Before you start buying optimisation plugins, you can check in about thirty seconds whether pages are actually being served from cache — and if they aren't, narrow down why.

Step 1: Read the response header

A LiteSpeed server tells you, on every request, whether it served the page from cache. Open a terminal and run:

curl -sI https://example.com/ | grep -i -E 'server|x-litespeed|cache-control|set-cookie'

Run it twice. The first request after a purge is always a miss — that's normal, it's the request that builds the cache entry. The second one is the one that matters.

What you're looking for in the second response:

server: LiteSpeed
x-litespeed-cache: hit

No terminal? In Chrome or Firefox, press F12, open the Network tab, reload the page, click the first entry (the document request), and look at Response Headers.

How to read what you get:

• x-litespeed-cache: hit — the page came from cache. Your caching is working; if the site is still slow, the problem is front-end weight (images, scripts, fonts), not caching.
• x-litespeed-cache: miss — the request reached PHP and WordPress. Keep reading.
• x-litespeed-cache-control: no-cache — something explicitly told the server not to cache this page. That's a strong clue; see steps 4–6.
• No x-litespeed-* header at all — either the plugin isn't producing cache rules, or you're not on a LiteSpeed server. See steps 2 and 3.
• If you use QUIC.cloud CDN you may also see a x-qc-cache header. That's the CDN edge, a separate layer from the server cache.

Header names and values differ slightly between LiteSpeed versions, and some are lowercase. Match on x-litespeed, not on exact spelling.

Step 2: Confirm you're actually on LiteSpeed

The server: header should say LiteSpeed. If it says Apache or nginx, the LiteSpeed Cache plugin's page cache cannot work at all — the page cache is a server feature, and the plugin is just the control panel for it. The plugin's other features (image optimisation, CSS/JS handling, object cache) still work, but the big win doesn't.

In WordPress you can also go to LiteSpeed Cache → Dashboard; recent versions show the detected server there, and the Cache settings page will warn you if the server does not support the cache.

If the header is missing entirely, check whether a proxy or CDN sits in front of your site and strips headers. Test by requesting the server directly, or temporarily put the CDN into a development/bypass mode and re-run the curl.

Step 3: Confirm the cache switch is on

Go to LiteSpeed Cache → Cache → [1] Cache and check Enable Cache is ON. This sounds obvious, but a plugin update, an imported settings file, or a staging-to-live copy can flip it back.

While you're there, note the Default Public Cache TTL. If someone set it to a very small number, pages expire almost immediately and nearly every request looks like a miss.

Step 4: Are you testing while logged in?

By default, logged-in users are not served public cache. If you're checking your own site in a tab where you're logged into wp-admin, you will see misses forever.

Test in a private/incognito window, or use curl, which sends no cookies at all. This single mistake accounts for a large share of "my cache isn't working" reports.

There is a Cache Logged-in Users option on the same page. Leave it as the plugin default unless you understand the implications for a membership or shop site — caching personalised pages for the wrong visitor is worse than no cache.

Step 5: Look at Set-Cookie

In your curl output, check for a set-cookie line on a plain page view by an anonymous visitor. If you see something like:

set-cookie: PHPSESSID=...; path=/

then a plugin or theme is starting a PHP session on every request. Pages that set a session cookie are typically excluded from public cache, by design — the server can't tell whether the content is personalised.

To find the culprit, deactivate plugins one at a time on a staging copy and re-run the curl after each. Common sources are older contact form, booking, chat and currency-switcher plugins. Some can be configured to only start sessions on the pages that need them.

Also check LiteSpeed Cache → Cache → [5] Excludes. If a cookie name there matches a cookie every visitor receives — for example an analytics or consent cookie set server-side — nothing will ever cache. Remove entries you can't justify.

Step 6: Check URL-level exclusions and query strings

Still in [5] Excludes, read Do Not Cache URIs, Do Not Cache Query Strings and Do Not Cache User Agents. A wildcard someone added months ago (/shop*, say) can quietly cover half the site.

Query strings matter too. A link with ?utm_source=facebook is a different URL to the server, so it gets its own cache entry and the first click on each new campaign tag is a miss. The plugin has a Drop Query String setting where you can list parameters to ignore; the tab it lives on has moved between plugin versions, so use the settings search or check each Cache tab rather than following a screenshot from an old post.

E-commerce carts, checkout and account pages are excluded on purpose. Don't "fix" those.

Step 7: Check the rewrite rules in .htaccess

The plugin writes a cache block into .htaccess. Another plugin, a security tool, or a manual edit can remove it.

1. In cPanel, open File Manager.
2. Click Settings (top right) and tick Show Hidden Files (dotfiles).
3. Open public_html/.htaccess and click Edit.
4. Look for a block that begins with a line containing LSCACHE, usually wrapped in ## LITESPEED WP CACHE PLUGIN markers.

If it's missing, make a copy of the file first, then go to LiteSpeed Cache → Toolbox → Purge → Purge All, toggle Enable Cache off and on again, and re-check the file. If two plugins keep fighting over .htaccess, pick one page-cache plugin and remove the other — running two page caches is a reliable way to get neither.

Step 8: Check how often the cache is being purged

A cache that is emptied constantly behaves like no cache. Under LiteSpeed Cache → Cache → [7] Purge, review the auto-purge rules. Every post publish or update triggers purges according to these rules; if a plugin writes to posts programmatically (stock updates, feed imports, view counters), it may be wiping the cache many times an hour.

To test this, run your two curls, wait ten minutes, run them again. If you drop back to miss, something is purging.

Step 9: Re-test and record the result

After each change, purge once, then request the page twice and save the headers. Keep a short note of what you changed and what the second request returned. Without that, you'll be guessing again in a month.

If you want a before-and-after number rather than a header, measure Time to First Byte yourself:

curl -s -o /dev/null -w 'TTFB: %{time_starttransfer}s\n' https://example.com/

Run it several times from the same connection, on a miss and on a hit, and compare your own figures. That's more useful than any benchmark someone else publishes.

When the cache is fine and the site still isn't

If you're getting clean hits and pages still feel heavy, caching has done its job and the remaining weight is in what the browser downloads: oversized images, render-blocking scripts, too many fonts. That's a different piece of work.

One thing caching can't fix either is distance. A cache hit still has to travel to your visitor. Gocelerus runs cPanel hosting on servers in Singapore with LiteSpeed web server and NVMe storage, which is a reasonable starting point for audiences in Indonesia and Cambodia — plans are listed at https://gocelerus.com/pricing, and moving an existing site over is free.