WPColt

Documentation

This documentation explains how WPColt Cache Inspector should be used once the plugin download is available. The first release is planned as a read-only diagnostic tool. It is built for WordPress site owners, developers, agencies, and support teams who need a plain-English answer to a common performance question: is the cache working, or is something silently bypassing it?

What Cache Inspector checks

Cache Inspector looks at the layers that commonly sit between a visitor and a WordPress page. That includes active WordPress caching plugins, server cache signals, CDN headers, object cache status, cache-related cookies, and the difference between the first and second logged-out requests. The goal is not to tune every setting automatically. The goal is to collect enough evidence to show what is working, what is broken, and what to verify next.

  • Active page-cache plugins and possible overlaps.
  • Server cache signals such as Varnish, Nginx FastCGI cache, LiteSpeed, or host-managed cache.
  • CDN and proxy headers including Cloudflare cache status, Age, X-Cache, X-Varnish, and related markers.
  • Object cache detection for Redis or Memcached where WordPress exposes enough information safely.
  • Cookie and header patterns that commonly prevent pages from being cached.
  • WooCommerce cart, account, checkout, and session-sensitive pages that must not be cached as public HTML.

How to run a clean scan

A useful cache test must look like a real visitor. If you test while logged in, WordPress and many caching systems deliberately bypass cache. Cache Inspector therefore checks the homepage and a representative post as a logged-out visitor, then requests each URL twice. The first request may reasonably be a MISS. The second request should often become a HIT if public page caching is configured correctly.

  1. Install and activate the plugin when it becomes available.
  2. Open the Cache Inspector screen in the WordPress admin area.
  3. Choose the homepage and one published post for the first scan.
  4. Run the read-only test and wait for the report to finish.
  5. Review the status of each layer before changing cache settings.

Understanding the result

A HIT normally means a caching layer served the page from cache. A MISS means the layer did not have a stored copy at that moment. BYPASS means the request was intentionally not cached, often because of cookies, query strings, logged-in state, checkout pages, or explicit rules. Unknown does not automatically mean broken; it means the server did not expose enough evidence in headers for the plugin to verify that layer.

What to fix first

Start with conflicts before chasing tiny speed gains. Two page-cache plugins can fight over output buffering, preload behavior, purge events, and headers. A CDN that caches HTML while WordPress is still sending private cookies can create stale or unsafe pages. An object cache that is installed but not connected can give a false sense of performance coverage. Fix the structural issue first, clear all layers, then test again.

How to verify a fix

After each change, purge the relevant cache layer and run the same test again. Look for a healthier second request, stable cache headers, and no private cookies on pages meant to be public. Avoid changing ten settings at once; cache stacks become readable when you move one lever at a time.