Website Shows Old Content After Deployment: Find the Cache Layer

The release is complete and the CMS shows the new headline, but some visitors still see the old offer. Another person sees the right text with a broken layout. Before deploying again, identify which response is old and which system is serving it.

A website can have several independent caches. The browser may reuse a response, a CDN may retain a public copy, and the application may generate HTML from cached data. A service worker can introduce another layer. Clearing one of these does not automatically clear the others.

Give the old and new versions a name

Choose a harmless marker that distinguishes the versions: a changed sentence, a release identifier, or an asset filename. Record the exact URL, the observed marker, and the time. Without this, “still broken” may describe different problems from different reviewers.

Compare the document and its assets separately. New HTML referencing a missing stylesheet is different from old HTML referencing an old but valid stylesheet. The first suggests an incomplete or mismatched release; the second suggests an older response is still being delivered.

Start with the browser

Open the page in a fresh browser profile or private window, then compare it with the affected session. Inspect the Network panel with the browser cache disabled for the test. This can help isolate browser reuse, but it does not bypass every upstream cache or necessarily remove service-worker behavior.

If the problem occurs only in the original browser, inspect storage and service-worker registration for that site. Do not tell every customer to clear all browsing data as the permanent fix. A release process that depends on customers doing that has an unresolved delivery problem.

Read the response evidence

Compare response headers and content for the same URL. Cache-Control describes caching policy, while headers such as Age can provide clues about shared-cache reuse. Provider-specific cache-status headers may add useful context.

One common misunderstanding is that no-cache means a response cannot be stored. It generally requires validation before reuse; no-store is the directive that prevents storage. MDN's caching guide explains these semantics. Do not change directives blindly: the correct policy depends on the resource and whether its content is public or personalized.

Save the relevant headers with the old and new markers. Differences in hostname, path, query string, language, or cookies may explain why two requests receive different versions. Keep the request conditions comparable.

Inspect the CDN and application in order

If you manage the CDN, check its cache rules and deployment purge history for the affected path. Use a targeted purge when appropriate and verify the resulting public response. Random query parameters are not proof that the normal URL has been repaired; they may simply select a different cache entry.

If an authorized origin check also returns old content, move inward. Confirm the active release, CMS publication state, and relevant application cache. A CDN purge cannot correct HTML that the application is still generating incorrectly.

For personalized pages, investigate why a shared cache is involved before increasing its lifetime or broadening its key. A stale marketing headline is inconvenient; serving one user's content to another requires a different response.

Make the release self-consistent

A practical prevention plan pairs versioned asset filenames with a deliberate HTML caching policy. Keep assets required by still-served HTML available during the transition. Include cache invalidation in the release procedure and verify it using the normal public URL.

Finish by retesting the original failing session and a fresh session. Record whether the issue was browser reuse, CDN reuse, application output, or a release mismatch. That label helps the next incident start at the right layer.

If the content is unfamiliar rather than merely old, use the existing unexpected website change checklist. For ordinary stale content, keep the investigation focused on delivery evidence before assuming someone changed the site without permission.