WordPress may purge its page cache after a menu update while Cloudflare continues to serve old HTML. Adding a broad bypass rule can swing the problem the other way, sending nearly every request to an overloaded origin.
The two cache layers need compatible eligibility, keys, and invalidation—not repeated global purges.
What it means
A WordPress–Cloudflare cache conflict occurs when the origin and edge disagree about whether a response is cacheable, what forms its cache key, how long it remains fresh, or which signal invalidates it. WordPress can generate current HTML while Cloudflare reuses an older representation; the edge can also cache a response the application intended to keep private.
- Origin page cache and Cloudflare edge cache are separate stores.
- A browser refresh does not remove a shared edge entry.
- Cookies, query strings, Vary, and no-cache headers must be interpreted consistently.
A realistic WordPress example
After a navigation update, the origin returns the new menu but the public URL still shows the old one with an increasing Age header. A temporary edge bypass makes the page current, confirming that WordPress itself is no longer stale.
The operator corrects the Cloudflare eligibility and purge integration for that URL class, verifies the new edge response, and removes the temporary bypass without disabling caching for the rest of the site.
Why it matters and when to use it
Conflicting policy causes stale content, accidental private caching, ineffective purges, or excessive origin traffic. The fault is easy to misplace because every layer can return a valid 200 response with different content and headers.
Investigate when a direct-origin comparison or cache-status header proves that the public edge does not follow the intended WordPress state.
A straightforward route for beginners
- Capture the same URL at the public edge and the origin, including status, Cache-Control, Vary, Set-Cookie, Age, and Cloudflare cache status.
- Confirm DNS, proxy mode, zone, and origin hostname.
- Bypass one test URL temporarily at the edge and compare it with the normal path.
- Align cache eligibility, cookie bypass, query handling, TTLs, and WordPress no-cache signals.
- Purge the affected URL or tag, then test anonymous, logged-in, preview, account, cart, API, redirect, and error responses.
The advanced route
Review every owner of edge behavior: cache rules, legacy page rules, Workers, automatic platform optimization, and any WordPress integration. Overlapping rules may apply in an order that the WordPress administrator cannot see.
- Inspect complete cache-key factors rather than URL path alone.
- Use targeted purges and retain the returned identifier where available.
- Test from more than one region because edge state is distributed.
- Document the origin rule, edge rule, TTL, purge path, owner, and emergency bypass.
Risks, common mistakes, backup, and rollback
Purging everything before capturing headers removes useful evidence and may briefly overload the origin. A permanent bypass hides the conflict rather than fixing it, while a broad cache-everything rule can expose authenticated or transactional pages.
- Do not assume a clean administrator view matches anonymous visitors.
- Do not change WordPress and Cloudflare rules simultaneously without a control request.
- Do not leave temporary bypass rules undocumented.
If private content is cached or the origin becomes unstable, enable the narrow emergency bypass or restore the previous edge rule while the exact policy mismatch is corrected.
How AIOWS helps:
AIOWS Cache Manager
AIOWS Cache Manager can keep supported WordPress-side cache settings and purge behavior visible in one place. That makes it easier to compare the application's intent with the response Cloudflare actually serves.
Use a direct-origin request and the public URL as a pair. Compare their cache headers, cookies, content, and timestamps, then test one unaffected page. After correcting the WordPress-side rule, verify that Cloudflare receives the intended signal and that a targeted purge produces a new edge response.
AIOWS cannot change Cloudflare cache rules, Workers, zone settings, or distributed edge state. If the public response still disagrees, inspect Cloudflare's effective rule and cache key. Keep an emergency bypass and the previous configuration available until anonymous and private paths pass in several regions.
Related AIOWS articles
- Clear WordPress Cache: Page, Object, Browser and CDN
- WordPress Cache-Control Headers Explained
- When Should You Purge WordPress Cache?
Conclusion and recommended route
Compare the same URL at the origin and edge, align cache keys and bypass policy, then purge only the stale scope. Use a narrow temporary bypass while correcting policy, not as a permanent substitute for it.
