You update a post, hit Publish, and check the live page—but the old version is still there. You clear your browser cache. Still stale. You wait five minutes. Still wrong.
The culprit is usually your CDN’s edge cache, and the purge signal your WordPress site sent either never arrived, arrived too late, or targeted the wrong URL variant.
Here’s how CDN cache invalidation actually works, where the automation breaks, and what to verify when pages stay stuck.
How WordPress tells a CDN to purge
When you publish or update a post, most WordPress caching plugins send a purge request to your CDN. The request typically targets:
- The post or page URL itself
- The homepage
- Any archive pages (category, tag, author) that list the post
- RSS feeds
Popular plugins like WP Rocket, W3 Total Cache, and LiteSpeed Cache include CDN purge integrations for Cloudflare, StackPath, KeyCDN, and others. Each uses the CDN’s API to issue a cache invalidation command.
The CDN then propagates that purge across its edge nodes. Depending on the provider and purge method, this can take anywhere from a few seconds to several minutes.
Where purge requests fail
The most common failure points:
API credentials expired or misconfigured. If your plugin is using an outdated API token, the purge request returns a 401 or 403 error—but WordPress doesn’t surface that to you. Check your CDN integration settings and regenerate tokens if you’ve rotated passwords or switched accounts.
URL mismatch between WordPress and the CDN. If your WordPress site uses http:// internally but your CDN caches https:// URLs, or if you’ve changed your permalink structure without flushing the CDN, purge requests may target URLs that don’t match what’s actually cached. Cloudflare’s API, for example, treats example.com/post/ and example.com/post (with and without trailing slash) as distinct cache keys unless you’ve set a page rule to normalize them.
Partial purge vs. full purge. Many plugins default to purging only the updated post and homepage to avoid rate limits. If your post appears on a paginated archive (e.g., page 2 of a category), that archive page may remain cached with the old excerpt or publish date. Some CDNs charge per purge request or throttle bulk invalidations, so plugins err on the side of conservative purging.
CDN caching HTML despite cache-control headers. If your CDN is set to ignore origin cache headers and enforce its own TTL, purge requests may succeed but the CDN repopulates the cache immediately from a stale upstream layer (like Varnish or Redis object cache on your host). Check your CDN’s cache rules to ensure it respects Cache-Control: no-cache or must-revalidate directives for dynamic pages.
What to check first
When a page won’t update:
Confirm the CDN is the bottleneck. Bypass the CDN by hitting your origin server directly (use your host’s IP or a hosts-file override). If the page is current at origin but stale through the CDN, the purge failed.
Check the plugin’s purge log. WP Rocket and LiteSpeed Cache log purge events in their debug modes. Enable logging, update the post again, and review whether the plugin attempted a purge and what response it received. Missing API errors here are a smoking gun.
Verify which URLs were purged. Most CDN dashboards (Cloudflare’s under Caching → Configuration → Purge Cache history, checked November 2026) show recent purge requests. Compare the purged URLs to the actual cached URLs. If you see /blog/post-name/ purged but your CDN cached /blog/post-name, trailing-slash normalization is broken.
Test with a manual full purge. Log into your CDN dashboard and purge everything. If the page updates immediately, the issue is with selective purging logic—either the plugin isn’t targeting the right URLs, or your CDN’s partial purge propagation is slow.
A non-obvious fix
If you’re using Cloudflare with a page rule that caches everything, double-check the Cache Level setting. Cloudflare’s Ignore Query String level treats example.com/post?v=123 and example.com/post as the same cache object, which can cause purge misses if your theme or plugin appends query strings for versioning. Switch to Standard or add an explicit purge for query-string variants.
For hosts running Varnish or Nginx FastCGI cache in front of WordPress, coordinate purges at both layers. Your CDN plugin may purge the CDN edge but leave Varnish’s copy intact; the CDN refetches stale HTML from Varnish, and you’re back where you started. Tools like Varnish HTTP Purge (checked via the WordPress plugin directory, November 2026) can integrate with your CDN plugin to purge both simultaneously.
Cache invalidation remains one of the hardest problems in distributed systems. When it breaks, start at the origin, trace the purge path, and confirm every hop actually cleared.
Hit reply if you’ve found a CDN purge edge case we didn’t cover—we’ll feature operator solutions in a future issue.