Find Which Cache Is Serving an Old WordPress Page

An editor sees a new post in wp-admin while visitors see old HTML. The stale object could live in the browser, service worker, CDN, reverse proxy, page cache, object cache, generated CSS, or a fragment inside WordPress.

Start with evidence and the smallest reversible change; work on staging when possible, preserve the logs and rollback material if production is already down, and keep the objective specific: use response headers, cache keys, logged-in comparisons, and origin tests to purge the right layer instead of clearing everything repeatedly.

What the symptom narrows down

• The purge event targets one URL while archives, mobile variants, or query-string keys remain fresh in cache.
• A CDN and plugin use different cache keys or invalidation rules.
• Generated assets keep the same URL after their contents change.

The branches are ordered to protect the strongest evidence around this possibility: the purge event targets one URL while archives, mobile variants, or query-string keys remain fresh in cache. The observed scope and logs—not a familiar-looking error screen—decide which one applies.

Performance work needs a measured bottleneck and a comparable before/after trace; a faster test after warming a cache or changing network conditions is not proof that the code improved; in this guide, the practical goal is to use response headers, cache keys, logged-in comparisons, and origin tests to purge the right layer instead of clearing everything repeatedly.

Evidence to collect before the fix

1. Compare private-window, logged-in, and curl -I responses; record Age, Cache-Control, ETag, Last-Modified, and vendor cache headers.
2. Request the origin through an authorized path and compare body hashes.
3. Identify whether HTML, an object query, or a versioned asset is stale.
4. Map every caching layer before purging any of them.

The sequence moves from observation toward intervention. Preserve the result of the final check—map every caching layer before purging any of them—because it provides a useful comparison after the repair.

Apply fixes in the safest order

1. Correct the invalidation event and cache-key variation, then purge the smallest affected scope.
2. Use content-hashed or versioned asset URLs for long-lived static files.
3. Keep personalized/admin responses private and out of shared caches.

Before applying “Correct the invalidation event and cache-key variation, then purge the smallest affected scope,” name its rollback point and the evidence that will count as success. Afterward, repeat the original request and specifically check whether you can update a controlled page and observe origin plus each cache layer transition; a changed symptom at that point is new evidence, not permission to make several more changes at once.

curl -sS -o /dev/null -D - https://example.com/changed-page/
curl -sS -o /dev/null -D - -H 'Cache-Control: no-cache' \
  https://example.com/changed-page/
wp cache flush

Prove recovery

• Update a controlled page and observe origin plus each cache layer transition.
• Confirm unrelated cached pages remain hits.
• Test anonymous and authenticated behavior with and without query strings.

One successful refresh is not closure. Keep the incident open until you can also confirm unrelated cached pages remain hits, adjacent paths have not regressed, temporary diagnostics are gone, and another operator can explain what changed.

Prepare a useful escalation if the boundary is outside your control

Record URL/template, device and network profile, cache state, geographic test point, trace or waterfall, field-data window, and deployed version; report medians or percentiles across repeated observations rather than the best run; include the result of this first observation: compare private-window, logged-in, and curl -I responses; record Age, Cache-Control, ETag, Last-Modified, and vendor cache headers.

State what was tested, including the result of “Compare private-window, logged-in, and `curl -I` responses; record Age, Cache-Control, ETag, Last-Modified, and vendor cache headers,” and what changed between attempts; evidence tied to that observation is safer and more actionable than granting broad access or sending an unnecessary full database export.

Shortcuts that create a second incident

• Do not use no-store on all public content; it discards useful browser and intermediary caching.
• Do not treat browser hard refresh as a CDN purge.

Primary references

• MDN HTTP caching — official reference consulted for this guide.
• WordPress performance — official reference consulted for this guide.

Editorial note: The scenario above illustrates how to approach “Correct the invalidation event and cache-key variation, then purge the smallest affected scope”; it is a documented example, not a claim about a reader’s server, so verify the cited documentation, take the appropriate backup, and follow the real environment’s access and change-control rules.