WPColt Cache Inspector is being built for one job: make WordPress cache behavior understandable. It is not another speed plugin and it does not try to rewrite your stack. The first version is a read-only diagnostic tool that checks public request behavior, active cache layers, common conflicts, and the evidence exposed in HTTP headers.
Use this documentation as the working manual for the product and the diagnostic method behind it. Even before the downloadable plugin is released, the process below reflects the way WPColt thinks about WordPress performance: prove what is happening first, then change the smallest useful setting.
Quick start workflow
- Confirm the test URLs. Use the homepage and one normal published post. Avoid search results, preview links, cart pages, account pages, and admin URLs for the first pass.
- Run as logged out. Admin sessions usually bypass cache. A public page-cache test should look like a real visitor request.
- Request each URL twice. The first request may warm the cache. The second request is where a healthy HIT often appears.
- Read the evidence together. One header is not enough. Compare Age, Cache-Control, Set-Cookie, X-Cache, X-Varnish, CF-Cache-Status, and host-specific markers.
- Fix conflicts before tuning. Duplicate page-cache plugins, unsafe CDN HTML cache, or cookies on every public page should be resolved before chasing minor speed settings.
What WPColt checks
| Area | What the report looks for | Why it matters |
|---|---|---|
| WordPress plugins | Known page-cache, optimization, security, ecommerce, membership, and object-cache helpers. | Two plugins can both try to own HTML cache, purge events, or asset optimization. |
| Server cache | Varnish, Nginx FastCGI cache, LiteSpeed, and host-managed cache clues. | Server cache may be the real page-cache layer even when the WordPress plugin looks active. |
| CDN/proxy | Cloudflare and other proxy headers, edge cache status, Age behavior, and bypass markers. | A CDN can speed public HTML or accidentally cache the wrong thing. |
| Object cache | Redis or Memcached connection clues and object-cache drop-in status. | An installed object cache is not useful if WordPress is not actually connected to it. |
| Safety exclusions | WooCommerce cart, checkout, account, login, and personalized URL patterns. | Private pages must bypass public page cache even when public posts should HIT. |
Result meanings
HIT
A cache layer served the response from storage. HIT is usually good for public pages and usually dangerous for private account or cart pages.
MISS
The cache layer did not have a stored response for that request. A first MISS can be normal after a purge. Repeated MISS responses on public pages deserve investigation.
BYPASS
The request was intentionally skipped. Common reasons include cookies, logged-in state, query strings, no-store headers, POST requests, or excluded URL rules.
Unknown
The layer cannot be verified from available evidence. Some hosts hide headers. Unknown is not automatically broken; it means the next step is manual confirmation.
Fix-order philosophy
WPColt reports should not dump a pile of warnings. They should answer four questions in order: what is working, what is broken, what to fix first, and how to verify the fix. That sequence keeps site owners from changing five settings at once and then losing the cause.
Recommended next reads
Open the Status Codes & Headers Library for header definitions, the WordPress Glossary for cache vocabulary, and the Sample Report to see how raw evidence becomes a practical recommendation.