Why every request reports a cache miss, and how to find the cause

A cache that reports a miss on every request is not caching anything. The site works, nothing looks broken, and every visitor pays full price. This is the most common caching fault on a WordPress network and it is almost always one of five causes.

Confirm it first

Request the same page twice and look at the response headers. A working cache reports a miss on the first request and a hit on the second. If the second is still a miss, the cache is not filling.

curl -sI https://example.com/some-post/ | grep -i cache
curl -sI https://example.com/some-post/ | grep -i cache

Compare the time to first byte as well. Two identical timings on two identical requests is the same signal from a different angle.

The five causes, in the order worth checking

1. A cookie attached to the first response. The moment your server hands a visitor a cookie, that page stops being identical for everyone and the cache refuses to share it. Consent tooling is the usual offender, followed by anything that fingerprints a reader before they have clicked anything at all. Expect to find your cause here more often than anywhere else.
2. You are logged in. Administrators are deliberately excluded, so your own browser is the worst possible test client. Use a private window or a plain command line request.
3. An over broad exclusion rule. Somebody excluded a path months ago to fix one page and the rule covers far more than intended. Read the exclusion list and check what each entry actually matches.
4. A query string. Tracking parameters and campaign tags can make every arrival look like a distinct page. Decide deliberately which parameters should be ignored for caching purposes.
5. The page really is uncacheable. Carts, checkouts, account pages and search results should miss. If the misses are confined to those, nothing is wrong.

Why it hits a whole network at once

You built these sites from one recipe, so they inherit one weakness. Whatever tool is issuing that cookie was installed everywhere, which means caching quietly stopped working everywhere on the same afternoon. What you notice is a portfolio that got slower over a month with no single site to point at.

The upside is symmetry. Name the cookie, then either drop it from the cache key or stop the tool issuing it to readers who have not logged in, and the whole portfolio recovers in one move.

The cold page problem, which is different

A cache can be working perfectly and still miss constantly if entries expire faster than pages are requested. On a site with thousands of posts and modest traffic, most pages are simply never asked for twice inside the cache lifetime.

Two responses, and the first is usually the right one:

• Accept it. If the uncached response is reasonable, the long tail being cold is normal and not worth engineering around.
• Warm the cache. Crawl your own sitemap on a schedule so popular pages stay warm. Do this gently: a warmer that hammers the site is a self inflicted traffic spike and shows up in your resource faults.

If the uncached response is not reasonable, warming is hiding a problem rather than solving it. Fix the slow page.

After every change

Purge, then re-run the two request check. A configuration change plus a stale cache produces confusing results, and half the time spent on caching problems is spent measuring the old behaviour.

The header and configuration reference is at docs.litespeedtech.com. For a rollout that avoids most of these problems in the first place see Speed and Caching, and for the underlying resource picture, Platform and Limits.