Source: HTTP caching, by MDN Web Docs
On 2026-09-13 a site deploy reported done. The index page changed, and the example sub-pages kept serving old links from the CDN cache. Our publish script now fetches the served page with a cache-buster and looks for the exact headline.
We shipped a site update and the deploy was verified. The index page showed the change.
The example sub-pages kept serving old links from the CDN cache. A cached page is still served with status 200, so a check that only looks at the status stays green.
The publish script fetches the served page with a cache-buster on the URL (?v=<timestamp>) and greps for the exact <h1> of the page title.
| Check | Why |
|---|---|
| Fetch the served page with a cache-buster query string | The request asks for a URL the CDN has not cached yet. |
| Look for the exact headline you just shipped | A status code alone stays 200 on a cached old page. |
| Check the sub-pages too | In our case the index was new and the sub-pages were stale. |
Sources: the 2026-09-13 stale sub-pages and the cache-buster rule are from our incident log; the publish check (cache-buster, exact h1, 6 retries) is from our site lane's publish script notes. HTTP caching background is from MDN Web Docs.