One of the stranger website failures is the deploy that succeeds while the public site still shows yesterday.
The build is green. The code is merged. The platform says the deployment finished. But a visitor, a crawler, or a customer in another region still gets stale content from cache or CDN.
That is not a philosophical problem. It is an operations problem.
Why stale pages happen
Modern sites use layers. A browser can cache files. A CDN can cache pages close to visitors. A framework can cache data. A reverse proxy can hold responses. These layers make sites fast, but each one needs a clear invalidation story.
When the story breaks, old content survives.
Sometimes the cache key ignores something important. Sometimes a page is marked cacheable for too long. Sometimes a deployment updates HTML but leaves an old asset reference alive. Sometimes a CDN purge is incomplete.
From the visitor's point of view, none of that matters. They see the wrong page.
A deploy is not visitor proof
This is where teams overclaim. "The deploy succeeded" is platform truth. "Visitors can see the new version" is runtime truth.
You need the second claim when the change matters. A pricing update, legal page, checkout copy, announcement, or broken-link repair should be checked at the public URL after deployment, ideally from a fresh request that bypasses local browser assumptions.
Check more than one path
Cache issues are not always sitewide. The homepage may refresh while a service page stays stale. A blog route may update while an image asset does not. One region may receive a purge before another.
A practical check covers the changed URL, one linked path, and any asset that is part of the claim. If the change affects structured data or metadata, inspect the HTML response, not just the screenshot.
Make cache behavior visible
Response headers can help. Cache status headers, age headers, ETags, and CDN-specific values tell you whether a response came from cache and how old it is. The names vary by platform, but the idea is stable: do not rely only on eyeballing the page.
If a monitor can capture the final URL, status code, selected headers, and a small payload excerpt, it becomes much easier to distinguish stale cache from a failed deployment.
Do not treat cache as an afterthought
Caching is part of production behavior. If a site depends on a CDN, the CDN is not outside the system. It is the system your visitors experience.
Site Clinic's position is simple: if a business claim depends on a page changing, the monitoring proof should show the live public page changed. Anything less is an internal implementation detail.
For a broader view of what deserves monitoring beyond uptime, start with our Site Clinic overview. Fast stale content is still stale.