Cache headers are the closest thing WordPress site owners have to a truth table. They do not tell the whole story alone, but they give evidence. WPColt uses headers to decide whether a public page is likely a HIT, MISS, BYPASS, STALE, or impossible to verify.
Header quick reference
| Header | What it can reveal | Common WPColt question |
|---|---|---|
| CF-Cache-Status | Cloudflare edge cache result such as HIT, MISS, BYPASS, DYNAMIC, EXPIRED, STALE, or REVALIDATED. | Is Cloudflare caching HTML or only passing it through? |
| Age | How long a response has lived in a shared cache. | Does Age increase on repeated logged-out requests? |
| X-Cache | Host, proxy, CDN, or server cache status. Meaning varies by provider. | Does the origin or proxy show HIT after a warm request? |
| X-Varnish | Varnish request identifiers or cache-path clues. | Did the request pass through Varnish, and can HIT be verified? |
| Cache-Control | Storage rules such as public, private, no-store, no-cache, max-age, and s-maxage. | Is the response even eligible for shared cache? |
| Set-Cookie | Cookies added by WordPress, plugins, ecommerce, analytics, consent, or security tools. | Is a cookie forcing public pages to bypass cache? |
| Via | Proxy involvement. | Which intermediate layers touched the response? |
| Server-Timing | Backend timing hints when exposed by host or plugin. | Is the delay in PHP, origin, edge, or another layer? |
CF-Cache-Status values
HIT
Cloudflare served the response from cache. This is usually desirable for public posts and pages. It should not happen for private account, checkout, cart, or logged-in pages.
MISS
Cloudflare did not have a cached copy for that request. A first MISS after purge can be normal. Repeated MISS results may mean HTML cache is disabled, the URL is not eligible, or a rule prevents storage.
BYPASS or DYNAMIC
The request was skipped or treated as dynamic. Cookies, Cache-Control rules, page rules, logged-in behavior, query strings, or plan limitations may be involved.
STALE or REVALIDATED
A stale response may be served while the cache revalidates or while the origin has trouble. This can protect uptime but may confuse editors if stale content persists after updates.
How to test headers correctly
- Use a public URL that should be cacheable.
- Test while logged out.
- Request the same URL twice.
- Compare cache headers, cookies, and response times.
- Update the content, purge cache, and confirm stale HTML disappears.
Common header conflicts
- Public page sends Set-Cookie: server cache or CDN may bypass storage.
- Cache-Control says private: shared cache should not store the page.
- Cloudflare HIT but origin MISS: edge may hide a broken origin cache.
- No Age header: cache may still exist, but it cannot be proven from that signal alone.
- Repeated MISS after purge: cache may never warm because a rule blocks storage.
Use the Glossary for definitions and the Documentation for the full testing workflow.