“The cache will not clear” is not one failure mode. A WordPress response can be cached by the browser, CDN, reverse proxy, page cache, object cache, PHP opcode cache or an application fragment. Purging everything at once removes the evidence that tells you which layer is stale.
Identify the stale layer before purging
Record the exact URL, host, user state and response headers. Compare a normal request with a safe cache-bypass request and, where architecture allows, with the origin response.
Headers and cache keys are evidence
Check age, cache status, vary rules and whether www, language, query-string or device variants use different keys.
Correct the source before invalidating it
If the database or deployed file is still old, purging simply repopulates the cache with the wrong content. Confirm the authoritative value first.
Distinguish page/CDN cache from object cache
Stale menus, options or query results with fresh HTML can indicate object cache; use the Redis/object-cache checks. Checkout/session symptoms have different cache constraints; compare the WooCommerce cart and cache diagnostic.
Restart PHP only with evidence
An opcode or mixed-node deployment issue can justify recycling specific workers, but restarting every service should not be the default response to stale content.
Verify the next update, not only the current one
After the fix, publish or change one controlled value and confirm the canonical public URL invalidates predictably across the same cache layers. Private or visitor-specific pages must remain correctly uncached.
WP REPAIR INCIDENT STANDARD
Safe intervention sequence
Pressing several purge buttons at once removes the evidence of which layer is stale and may not touch a mis-keyed or separate host cache.
- Record the stale URL, user state, host and response cache headers.
- Add a safe cache-bypass query or header and compare body and age.
- Test origin directly where architecture and security allow.
- Check purge scope across www/non-www, language, device and query variants.
What must be verified
- The canonical public URL serves the new content from every edge tested.
- Subsequent updates invalidate the same layer predictably.
- Private pages and visitor-specific content remain uncached.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
If I purge every cache plugin and CDN button at once, will that reliably fix stale content?+
Not necessarily, and it can make diagnosis harder. Pressing multiple purge controls at once removes the evidence of which specific layer was actually stale, and may still miss a mis-keyed cache entry or a separate host-level cache entirely.
Can old content persist even after the source page has been correctly updated?+
Yes. A reverse proxy, CDN, or object cache can continue serving a previously cached version of the page even though the origin content is already correct, which is why comparing the origin response directly against the public URL is part of the diagnostic sequence.
Is disabling caching site-wide a reasonable permanent fix for this kind of problem?+
No. The guide is explicit that disabling all caching should not be treated as the repair — the goal is to fix the invalidation logic for the specific layer at fault while preserving overall cache performance.
Could restarting PHP fix stale content if purging cache plugins doesn't help?+
In some cases, yes. An opcode cache mismatch or a deployment where one server node is still running an old file version can look identical to a caching problem, and restarting only the necessary PHP workers is appropriate once that specific evidence points there.