Stale CMS data appears in Collection List after publish – unresolved cache invalidation

Direct answers

There is no documented or contractually guaranteed maximum stale-data window for a Collection List after a Webflow publish completes. Webflow regenerates static pages and then internally invalidates its CDN cache, but how quickly every edge node re-fetches the new HTML varies by geography, edge node, and plan tier. In practice the window is often seconds to a couple of minutes, but any specific number quoted in community posts is anecdotal, not an SLA.

Webflow does not expose a user-triggered, per-page or per-Collection-List CDN purge API. Cache invalidation is managed entirely on Webflow's side as part of the publish pipeline, so manual selective purging of Collection List endpoints is not a supported feature.

There is no supported mechanism to defer CMS updates until after global CDN propagation finishes. A publish is atomic from Webflow's perspective; you cannot schedule item changes to activate only after the CDN has fully refreshed.

Likely explanation vs confirmed facts

Likely explanation: A Collection List is rendered into static HTML at publish time. After publish, a visitor's request may still hit an edge node holding the pre-publish page until that node's copy is invalidated and re-fetched. Node behavior differs by location, so two visitors can briefly see different versions of the same list.

Confirmed facts: Webflow publishing is site-wide and atomic; no blue-green deployment for CMS data exists; CDN cache invalidation occurs after publish completes and is not user-controllable; the stale window is undocumented and empirically variable.

Verification steps you can run

To measure your site's actual stale window:

1. Publish a trivial CMS item change (e.g., update a single rich text field).
2. From multiple geographic locations (different machines, cloud shells, or a global ping service), fetch the Collection List page with a cache-busting query string disabled:

curl -s -D - -o /dev/null https://yoursite.com/your-collection-page | grep -iE 'age|cache-control|x-cache'

The Age and cache-status headers indicate whether a node served a cached copy and how old it was. Record the time each request returns the new content. Repeat immediately after publish and at intervals until the updated item appears everywhere you test. The spread of those timestamps is your observable window.

When to ask for further diagnosis

If you can confirm whether your site uses custom CDN cache-control headers beyond Webflow's defaults, that detail affects whether the observed window is normal propagation or a deployment issue. Have you measured the stale duration on your live site, and if so, what timestamps did you record? Sharing that information lets me tailor the recommendation.