Stop Cached Blog Pages from Hiding Your Updates

Separate publication from delivery

An editor clicking Publish does not prove every visitor immediately receives the new article version. Content may pass through a CMS cache, a build artifact, an edge cache, and a browser cache. MDN's Cache-Control documentation describes directives that govern storage and reuse; Content-Type identifies what a response contains. Map your own delivery chain before changing cache settings. The practical question is where the old representation survives. Disabling caching everywhere may mask the issue while sacrificing performance and leaving the publication workflow itself misunderstood.

Capture the observed response

When someone reports stale content, record the exact URL, the visible version, response headers, and whether they were logged in. Compare a normal browser request with a fresh session and a direct HTTP fetch. Inspect the article body as well as headers; a new timestamp on a response does not guarantee the underlying content changed. Check whether query parameters or hostname variants select different cache entries. Keep the investigation tied to the actual public route rather than assuming a preview page and the production page use the same delivery path.

A hypothetical partial update

Suppose a corrected guide appears properly in the CMS preview, while its public article still shows the old instruction and the blog index shows the new title. The inconsistent state suggests different resources are being refreshed separately. Trace the article HTML, index HTML, and any content API response. The fix may require rebuilding or invalidating all affected representations, not just the article record. This example does not imply a particular hosting platform is defective; it illustrates why a publication event needs a clear list of outputs and dependencies.

Define the affected resources

For each publishing action, identify what changes: article HTML, category listings, related-content blocks, feed, sitemap, and metadata previews. Prefer a deliberate update mechanism over broad, unexplained purges. Use long-lived caching for versioned static assets when appropriate and a policy suited to the freshness requirements of public documents. Keep authenticated or personalized responses separate from public content caching. Review the hosting provider's actual behavior before relying on a directive, because application code and managed platform rules can interact. Document which layer is authoritative for each resource type.

Verify the reader-visible result

After the repair, fetch the public article and confirm the exact corrected passage, not merely a successful response. Recheck the listing and sitemap if the publication changed them. Test a returning browser as well as a fresh visitor to understand the practical update experience. Record the intended freshness policy so future teams know what delay, if any, is expected. Search engines may still show an older indexed version until they revisit the page; that is separate from your server continuing to deliver stale content. Resolve delivery first, then assess search reporting with that distinction intact.

Use a recognizable version marker during diagnosis if necessary, then remove temporary debugging content. A precise comparison is more reliable than deciding two responses look broadly similar at a glance.