How to read LiteSpeed response headers

LiteSpeed response headers show whether a page was served from cache, ran PHP, or was skipped on purpose. You read them by requesting headers only, then looking for the x-litespeed-cache and server lines. On shared hosting we run LiteSpeed with cPanel, so these headers are the quickest way to see what the origin actually did.

Run a header check with curl

Open a terminal and request headers for a public URL you care about. The command below filters the lines that matter for LiteSpeed and cache.

curl -sI https://example.com/ | grep -i -E ‘server|x-litespeed|cache’

Replace the example hostname with your own domain. Use a page you expect to be public and cacheable, such as the homepage, when you first test.

If you are logged into WordPress in the browser, open an private window or stick with curl. Logged-in sessions are supposed to miss cache, so a browser test while signed in often looks broken when it is not.

What the common values mean

server: LiteSpeed means the response came from a LiteSpeed server. Pair that with a DNS lookup of your hostname if you need to confirm you hit your account and not another layer in front.

x-litespeed-cache: hit means the page was served from LiteSpeed cache and PHP did not run for that request. That is the result you want on public pages that should be cached.

x-litespeed-cache: miss means LiteSpeed ran the request through PHP and may store the result for later. A miss on the first visit after a purge is normal. A permanent miss on a public homepage usually points to a plugin, cookie, or cache rule.

no-cache means a cookie, cache rule, or page type told LiteSpeed not to store the response. Cart, checkout, and account pages often show this on purpose.

• Hit on / and miss on /cart is expected behavior.
• Hit on /cart or checkout is a problem worth fixing.
• Miss on / every time, while logged out, usually means a misconfiguration or a conflicting plugin.

CDN layers, LSCache, and extra plugins

A CDN in front of the site can hide or replace origin cache headers. If the headers look wrong, check the origin hostname directly or use a CDN bypass method your CDN documents.

LSCache is the LiteSpeed page cache. AccelerateWP is a separate optimization layer and does not replace LSCache. They can work together, but a second full page-cache plugin beside LSCache often causes purge conflicts. Keep one page cache.

A cache hit only means PHP did not run. A large HTML document is still large, and images and scripts still affect load time. Use the headers to confirm cache behavior, then tune assets separately if the page feels heavy.

When the browser still shows old HTML

Phones that keep yesterday’s HTML after a purge are often holding an app cache or stale DNS, not a stuck LSCache copy. Pull fresh headers with curl before you disable plugins. Those headers are the tie-breaker between origin cache and something on the device or network.

If a public page never shows a hit while you are logged out, say so in the ticket and include the curl output. That gives support a clear starting point without guesswork.