You publish a correction to a post, hit update, and reload the page. It looks fine. Two hours later, a reader emails you about the mistake you just fixed—because they’re still seeing the old version.
CDN edge caches don’t purge instantly. Even when your WordPress hosting provider or CDN plugin claims “automatic purge on publish,” the signal has to propagate across dozens or hundreds of edge nodes. Some refresh in seconds. Others take minutes. A few stragglers can hold stale content for five, ten, even fifteen minutes.
If you run a content site, newsletter archive, or any business where correctness matters more than speed, you need to understand how purge delays work—and when to bypass the CDN entirely.
How CDN purge propagation actually works
When you update a WordPress post, your caching plugin or hosting control panel sends a purge request to the CDN. That request tells the CDN to invalidate the cached copy of a specific URL.
But CDNs don’t store one copy of your page. They store dozens, distributed across edge nodes in different cities and regions. The purge request has to reach every node that cached that URL. Some CDNs use a hub-and-spoke model, where a central controller tells edge nodes to purge. Others rely on eventual consistency, where nodes check in periodically and sync purge lists.
The result: purge latency varies by CDN provider, geographic distribution, and how the edge node last synced. Cloudflare’s global purge typically completes in under 30 seconds. StackPath and BunnyCDN clock in around 30–60 seconds. Older or budget CDNs can take two to five minutes. Regional edge nodes in low-traffic zones sometimes lag another five minutes beyond that.
If your reader hits an edge node in Tokyo thirty seconds after you purge in New York, they might still see the cached version. The purge request is in flight, but hasn’t landed yet.
When purge delays break your workflow
For most blog posts, a one-minute delay doesn’t matter. Readers won’t notice. But three scenarios make purge lag painful:
- Breaking news or time-sensitive corrections. If you publish live updates, product launches, or breaking analysis, stale caches mean early readers see outdated information. You can’t control which edge node they hit.
- Email newsletter links that drive immediate traffic. You send a newsletter linking to a new post. Subscribers in different regions click within seconds of each other. Some see the post. Others hit a 404 or an older draft, because the edge node nearest them hasn’t purged yet.
- Affiliate links, pricing, or legal copy. If you update an affiliate disclosure, a product price, or terms of service, you need every reader to see the current version immediately. A five-minute cache lag exposes you to inconsistency or compliance risk.
Purge delays also compound when you use multiple caching layers. If your host runs Varnish or Nginx caching in front of the origin, and you layer a CDN on top, you have two purge queues. A plugin might purge the CDN instantly but leave the host cache intact for another sixty seconds. The CDN pulls the stale copy from the host, re-caches it, and now you’re waiting for both layers to expire.
What to do when instant purge matters
If you need guaranteed fresh content, you have three levers:
Bypass the CDN for critical URLs. Most CDNs let you set cache rules per path. If you have a /live subdirectory or a specific post slug that needs zero cache lag, exclude it from edge caching entirely. The page will load slightly slower, but every reader sees the current version.
Use query string cache busting. Append a unique query parameter to the URL when you update the post—something like ?v=1721203487. The CDN treats it as a new URL and skips the cache. This works for newsletter links, social shares, or any scenario where you control the inbound link. It doesn’t help organic search traffic, because Google ignores query strings in most cases.
Monitor purge lag and escalate if necessary. If you’re on a managed WordPress host like BigScoots, WP Engine, or Kinsta, check whether they expose purge status in the dashboard. Some hosts show per-node purge completion. If you see consistent lag on specific regions, open a support ticket. Misconfigured edge nodes or stale DNS can cause outlier delays that support can fix.
For most solo operators, the simplest fix is setting shorter cache TTLs on high-stakes pages. If your default CDN cache is set to 24 hours, dial it back to 5 or 10 minutes for posts you update frequently. You lose some performance benefit, but you cut the worst-case purge window from hours to minutes.
The non-obvious detail: browser cache adds another layer
Even if your CDN purge completes in ten seconds, readers might still see stale content for minutes or hours—because their browser cached the page. CDN purges don’t touch client-side caches.
If your WordPress caching plugin or CDN sets Cache-Control: max-age=86400 (24 hours) in HTTP headers, the reader’s browser won’t even ask the CDN for a fresh copy until that timer expires. You can purge the CDN a hundred times; it won’t matter.
Check your caching plugin’s browser cache setting. For posts you update often, set browser cache TTL to 5 or 10 minutes, not hours. That way, readers who reload the page within a few minutes will fetch the updated version from the CDN, even if their initial pageview hit a stale edge node.
One more thing: if you’re testing purge behavior yourself, open an incognito window or clear your browser cache before each reload. Otherwise you’re testing your local cache, not the CDN.
Got a caching or hosting question? Reply to this email—we cover reader questions every Sunday.