This sample report is the clearest way to understand WPColt Cache Inspector. The plugin is not trying to become another caching plugin. It is designed to answer the question most WordPress owners cannot answer confidently: which cache layer served this page, which layer failed, and what should I fix first?
Example site profile
| Site type | WordPress publisher with documentation, blog posts, lead forms, Cloudflare, a page-cache plugin, Redis object cache, and host-level Nginx cache. |
|---|---|
| Business risk | Public content should be fast and fresh. Private areas, previews, forms, and admin routes must never be served from shared cache. |
| Test method | Homepage and one public post requested twice as a logged-out visitor, then compared by status, timing, response headers, and cache evidence. |
| Report style | Plain-English priorities with raw evidence available for developers and hosts. |
Diagnostic snapshot
| Layer | Evidence | Status | What it means |
|---|---|---|---|
| Cloudflare edge | CF-Cache-Status: HIT, Age increases from 119 to 1842 | Working | The homepage is served from Cloudflare cache on repeat visits. |
| WordPress page cache plugin | Plugin detected, cache marker present on homepage, absent on post | Partial | The plugin is installed, but behavior differs by template or request. |
| Server cache | X-Cache: MISS on both post requests | Broken | The public post is not warming server cache. |
| Redis object cache | object-cache.php drop-in present, Redis connection responds | Working | Object cache is connected, but it does not replace HTML page cache. |
| Cookie behavior | Set-Cookie appears for a logged-out public post | Conflict | A public cookie may force bypass at the plugin, server, or CDN layer. |
| Private routes | /wp-admin/, login, cart-style paths bypass shared cache | Safe | Private pages are not being treated as public cache candidates. |
Raw evidence excerpt
| Request | Key headers | Interpretation |
|---|---|---|
| Homepage, first request | CF-Cache-Status: MISS Cache-Control: public, max-age=0, s-maxage=14400 |
Cloudflare fetched from origin and may store the response. |
| Homepage, second request | CF-Cache-Status: HIT Age: 1842 |
The edge cache is serving stored HTML. |
| Public post, first request | X-Cache: MISS Set-Cookie: visitor_segment=… |
The post response looks personalized to cache layers. |
| Public post, second request | X-Cache: MISS CF-Cache-Status: BYPASS |
The post is not warming cache. The cookie is the first suspect. |
What is working
The site is not globally broken. Cloudflare is serving the homepage from cache after the first request, and Redis appears connected. That means the infrastructure has useful pieces in place. WPColt would not recommend replacing everything. The report separates working layers from failing layers so the owner does not waste time undoing the parts that are already helping.
What is broken
The public post never becomes a cache HIT on repeat logged-out requests. That is the expensive failure. A blog, documentation page, or marketing article should usually be safe to cache for anonymous visitors. When that page misses every time, WordPress, PHP, and the database do unnecessary work, and the CDN cannot do its job consistently.
The likely conflict is the anonymous cookie. Some plugins set cookies for consent, A/B testing, analytics, geolocation, security, personalization, or popup behavior. Those cookies can be legitimate, but when they appear on every public response they often make cache layers treat ordinary visitors as personalized sessions.
Fix order
- Confirm the cookie source. Disable suspects on staging or inspect plugin output until the anonymous Set-Cookie header disappears.
- Decide whether the cookie is needed before interaction. If it is only needed after a form submit, login, cart event, or consent choice, stop sending it on first public page view.
- Retest one URL. Clear plugin, server, CDN, and browser cache. Request the same post twice as a logged-out visitor.
- Look for a second-request HIT. A healthy result may show X-Cache: HIT, CF-Cache-Status: HIT, or Age increasing.
- Only then tune TTLs. Increasing cache duration before removing the bypass cause does not solve the underlying problem.
What not to fix first
Do not install a second page-cache plugin. Do not raise every TTL. Do not enable HTML cache at the CDN without private-page exclusions. Do not assume Redis will solve full-page HTML misses. These changes can make the site harder to reason about and can create unsafe caching if cart, account, preview, or logged-in pages are accidentally stored.
Verification target
| URL type | Expected behavior | Success signal |
|---|---|---|
| Homepage | Cacheable for logged-out visitors | Second request HIT or Age increases |
| Public post | Cacheable after cookie issue is fixed | MISS then HIT pattern |
| Login/admin | Never shared-cache public HTML | BYPASS, no public HIT |
| Cart/account | Private or excluded | BYPASS with appropriate private headers |
How WPColt turns this into a useful report
The value is not the raw header list. Site owners can already open browser dev tools, run curl, or ask a host for logs. The value is priority. WPColt groups the signals into a practical decision: what works, what is broken, what to fix first, what to avoid, and how to verify the fix without guessing.
Why the report tests twice
A first request often warms cache. A second request proves whether the layer stored and reused the response. Without repeat testing, a report can confuse a normal first MISS with a broken cache.
Why logged-out testing matters
Public page cache is for anonymous visitors. Testing as an admin usually produces BYPASS because admin cookies are present. WPColt uses logged-out requests so the result matches real public traffic.
Why private pages are part of the report
A cache system is only healthy if it caches what should be public and bypasses what should be private. The goal is speed without leaking account, cart, preview, or admin-specific HTML.
Conversion takeaway
This is the problem WPColt is built to solve. A site can have Cloudflare, Redis, a page-cache plugin, server cache, image optimization, and a good hosting plan while still failing the most basic public-post cache test. WPColt gives the site owner a readable answer and gives a developer or host enough evidence to fix the right layer first.