Diagnostics

Diagnostics

Four tools, in the order you should reach for them.

1. Read the response headers

curl -sSI https://example.com/some-page/ | grep -i x-gt-cache

Value	Meaning
HIT	Served from cache, still fresh
STALE	Served from cache past fresh; a rebuild is queued
MISS	Nothing cached yet; WordPress rendered it
EXPIRED	Past the stale window
REVALIDATE	A preload request deliberately skipped the stale copy
BYPASS	Not eligible — see the reason header
DYNAMIC	Eligible, but the rendered response failed validation
(no header)	A bypass with Debug mode off

X-GT-Cache-Reason only appears when Debug mode is on, so production does not advertise its bypass rules. Turn it on temporarily when investigating.

Behind a CDN you may be reading an edge copy rather than your origin. Add a cache-busting query parameter to force a real origin render — and remember an unknown parameter deliberately bypasses, which is exactly what you want here.

2. Explain This Page

wp gt-performance cache explain --page-url=https://example.com/pricing/

Also available in the admin. It reports, for one URL: eligibility and the deciding rule, the computed cache key and its inputs, the stored entry's age and freshness windows, which optimizations applied, and what the edge policy would do.

This answers "why is this page not caching" directly instead of by elimination.

3. Purge receipts

Every purge writes a receipt: what was requested, what was actually evicted at the origin, and what Cloudflare reported. Purges are easy to believe and hard to verify — a receipt is the difference between "I clicked purge" and "the object is gone".

wp gt-performance cache verify --page-url=<url>

fetches the URL afterwards and confirms the cache behaved as configured.

4. doctor

wp gt-performance doctor

Environment-level: PHP, WordPress, directory writability, drop-in ownership, WP_CACHE, Redis, Cloudflare, xCloud, cron.

The plugin log

wp-content/cache/gt-performance/logs/gt-performance.log, one JSON object per line:

{"time":"…","level":"debug","message":"Response not cached","context":{"reason":"status:404"}}

Response not cached entries at debug level are normal — 404s, redirects and cookie-setting responses are supposed to be excluded. Look for error and warning.

The directory is denied to the web and carries an index.html.

Cron health

The preload queue depends on WP-Cron. doctor reports whether request spawning is enabled and whether events are overdue. On a site with DISABLE_WP_CRON, drive it from a real cron:

*/5 * * * * cd /path/to/wp && wp gt-performance queue run --quiet

Related

WP-CLI · Troubleshooting · Page Cache