Why Are My Website Changes Not Showing After Deployment?

How do you rule out a deployment problem first?

Confirm the production branch, commit, successful deployment, hostname, and exact path. A successful preview build does not establish that the production domain points to it. Compare a visible sentence, asset reference, or other harmless version marker in the deployed HTML with the intended source.

If both a fresh browser and the production response show the old HTML, investigate the deployment and routing before rewriting CSS. If the HTML is new but its stylesheet reference still points at an old file, inspect the generated output or template. If only one browser looks old, investigate its local state.

The preview and production guide explains environment separation. This article focuses on response freshness after you have identified the intended release.

What should you inspect in the Network panel?

Open DevTools, reload, and select the document plus the specific stylesheet, script, or image that looks stale. Record its URL, response content, status, and cache-related headers. Look for whether the browser reports a memory cache, disk cache, or service-worker response.

Temporarily enabling Disable cache while DevTools is open helps test browser-cache behavior. It does not necessarily bypass every CDN, application cache, or service worker. A private window is another comparison, but it changes other state too; treat it as evidence rather than a universal fix.

A 304 Not Modified response means a conditional request validated a stored response for reuse. It is not inherently an error. Examine what content was reused and whether its validation rules match your publication approach.

What do common cache directives mean?

• no-cache: a response may be stored, but reuse requires validation. The name does not mean “never store.”
• no-store: tells caches not to store the response. It is not a retroactive eraser for every copy that already exists.
• max-age: sets how long a stored response can be considered fresh under that policy.
• immutable: indicates the representation will not change while fresh; it suits genuinely versioned assets better than a filename you overwrite repeatedly.

Shared caches and browsers can have different controls. Inspect your actual host’s behavior and headers; do not paste a long-lived policy across all routes because it speeds up one test. Account pages and private data need a different review from public images and stylesheets.

How can you prevent stale static assets on the next release?

Use content-versioned filenames such as site.a1b2c3.css when your build supports them, and update the HTML to reference the new file. A file’s URL then changes when its content changes. Keep older versioned assets available long enough for previously cached pages to finish using them. Retain the needed files in the deployed output or an intentionally retained asset store; do not depend on residual CDN copies remaining available.

A manual query version such as site.css?v=2 can be useful on a small site if every reference is updated and the serving cache treats that URL as intended. Its reliability depends on the host and cache configuration. It is easier to forget a query update than to use a build that generates content hashes.

Give frequently changing HTML a freshness policy appropriate to your release process. Do not mark mutable HTML or a reused script filename immutable casually. The goal is fast repeat visits and predictable updates, not eliminating all caching.

Could a service worker be serving the old page?

A service worker can intercept requests and serve responses from storage managed by the application. Sites built with offline or PWA tooling may have one even if the owner did not intentionally add it. Inspect the Application panel’s service worker and cache storage information when the browser evidence points there.

Service worker updates have a lifecycle. A newly installed worker may wait while an older one controls open pages. Closing tabs, testing in a fresh session, or using the tool’s controlled development options can help reproduce the update path. DevTools unregister and clear-storage controls affect the current browser profile for that site; they do not repair other visitors’ sessions. Clearing site storage can remove locally stored work. Treat production worker-update changes as a separate code change.

Review the worker’s cache names, activation cleanup, navigation strategy, and compatibility with older pages. If nobody owns that code, ask for a bounded review before changing the update behavior.

When should you purge a CDN cache?

When you have evidence that a CDN is serving an outdated response, consult the platform’s supported purge and caching documentation. Prefer the narrowest relevant purge when available. A broad purge can temporarily increase origin traffic and does not fix an incorrect deployment, stale service worker, or outdated source file.

Cloudflare Pages has its own documented asset-serving behavior; separate that from any additional rules applied to a custom domain. Do not assume a generic cache tutorial describes your Pages configuration.

1. Record the intended deployment and one failing response.
2. Identify the responsible layer and make the smallest suitable correction.
3. Test both a returning session and a fresh session.
4. Check that the new HTML and assets agree.
5. Repeat essential navigation and form checks on production.
6. Document the asset-versioning or cache-policy change for the next update.

Use browser evidence collection when you cannot tell which response is stale. Keep a recoverable source and configuration record before changing deployment or cache settings.