You publish a correction, the editor preview is right, but visitors still see the old version. Purging every cache can hide which layer failed and create a large burst of uncached traffic.
Follow the content from WordPress storage to the public response and clear only the layer that owns the stale copy.
Confirm the update exists in WordPress
View the saved page in the editor and check revision history. Then use WordPress preview while logged in. If the editor itself shows old content, the issue may be an unsaved revision, translation, reusable block or page-builder template—not full-page cache.
Check that you edited the same language and canonical URL visitors use. A service page can inherit text from a global template while its editor contains only a shortcode or placeholder.
Compare logged-in and private responses
Open the public URL in a fresh private session and inspect its page source. Search for a distinctive changed phrase.
If the logged-in page is current but private HTML is old, page or CDN caching is likely. If HTML is current but the visible browser page is old, generated CSS, JavaScript, client storage or a service worker may be responsible.
Add no-cache developer settings only for diagnosis; ordinary visitors still need to be tested through the real delivery path.
Identify the stale layer from headers
Record response headers for the canonical URL. Look for CDN age and hit status, hosting cache markers and cache-control directives.
Purge the specific page in the WordPress cache first, then request it again. If the CDN continues serving an old response with a high age, purge that exact public URL.
Do not purge an entire CDN zone for one text change unless the provider cannot target the asset and the business impact justifies it.
Check alternate URL keys
The cache may hold separate entries for:
- trailing slash and no slash;
wwwand apex host;- HTTP and HTTPS;
- language prefixes;
- mobile variants;
- query parameters.
Correct redirects so visitors converge on one canonical form. Purge both source and destination only when the source itself can serve cached HTML rather than a simple redirect.
Do not configure all query strings as equivalent without checking search, preview, currency and campaign behaviour.
Inspect generated page-builder assets
If text is correct but spacing, colours or background images are old, regenerate the builder’s CSS through its supported tool. The HTML cache and CSS cache are different objects.
A generated stylesheet may have a new filename while cached HTML still references the old one, or the CDN may hold the old file under a stable URL.
Avoid manually deleting builder directories. This can leave pages unstyled during regeneration and may remove files owned by another process.
Distinguish object cache from full-page cache
Persistent object cache stores database query results and computed values. WordPress normally invalidates relevant objects when a post updates, but custom code may use its own cache key without proper expiry.
If a dynamic widget remains stale after full-page caches are bypassed, inspect its plugin or transient behaviour. Flushing the entire object cache can affect other applications and create a database spike.
Delete a specific transient or cache group only when ownership is understood and a rollback is available.
Test automatic invalidation
After restoring the current page, make a harmless change in staging and publish it. Confirm which cache entries clear automatically and how long public propagation takes.
Test related archives if the edit changes a title, featured image or product data. The individual page, category listing and homepage card may have separate cache entries.
Document the normal update path for editors so they do not repeatedly purge all caches.
When stale content needs repair
Request an assessment when only one language or device variant stays stale, cache headers conflict or updates require repeated manual flushing. Share the public URLs, expected phrase and timestamps; do not send credentials in the first enquiry.
A durable repair aligns invalidation across WordPress, builder assets and CDN while keeping cache effective for visitors.