This sample report shows the kind of plain-English output WPColt Cache Inspector is designed to produce. The exact interface may change before release, but the editorial goal is stable: explain the cache stack in a way a WordPress site owner can act on.
Example site summary
- WordPress page-cache plugin detected: WP Rocket.
- Object cache detected: Redis drop-in present and connected.
- CDN detected: Cloudflare headers present.
- Server cache clue: Nginx cache header present.
- Homepage second request: HIT.
- Single post second request: MISS.
- Warning: Set-Cookie appears on public post response.
What is working
The homepage appears to be served from cache after the first request. Redis is connected, which may help repeated database operations and admin activity. Cloudflare is present and returning cache-related headers, so the CDN layer can be inspected.
What is broken
The sample post does not become a cache HIT on the second logged-out request. The response includes a cookie, which may cause a server cache or CDN to bypass storage. Because the homepage behaves differently from the post, the issue is likely related to post-level output, plugin conditions, or a rule that affects single posts.
What to fix first
- Identify which plugin or script sets the cookie on public posts.
- Confirm whether the cookie is necessary for logged-out visitors.
- Exclude only the sensitive behavior, not the whole post template, if possible.
- Purge plugin, server, and CDN caches after the change.
How to verify the fix
Run the same logged-out two-request test again. A healthy result would show the post moving from first-request MISS to second-request HIT or an increasing Age header, while private pages such as cart, account, checkout, and login remain BYPASS.