Website changes not showing? Find the stale HTML or CSS

1. Pick one change you can recognize

Suppose you change a workshop start time from 10:00 to 11:00, but the public page still says 10:00. Use that exact text as the version marker. For a style change, use a specific rule or asset filename you can recognize. You need a difference in the delivered file, not just a “publish succeeded” message.

Copy the final public address from the browser after redirects. Check the language, hostname and path; a preview URL, editor session or another translation can show a different version. If possible, compare the same public page while signed out. For pages that need an account, keep the account and response variant consistent.

• Expected marker: 11:00. Observed marker: 10:00. Exact final URL: record it.
• Is the marker present in the generated or selected release? If it is absent there, investigate saving, building or selecting the publication first.
• If only a Google result or a social preview is old, compare it with the live page. Those services can retain separate copies; refreshing your browser does not update their saved result.

2. Inspect the document, then its assets

In desktop Chrome, open DevTools → Network before reloading. Select the document request (Doc), check its final address, and search Response for the marker. Read the response itself before relying on Elements, where JavaScript may already have changed the page. If an application loads its text later, inspect the matching Fetch/XHR response as well.

Now enable Disable cache while DevTools stays open and reload. This tests the browser HTTP cache. It does not purge a CDN or the application’s service-worker storage. Record whether the response marker changed. Disable the option again before the final ordinary-visitor check.

• Old document response → investigate that HTML URL and the release serving it.
• New HTML but old appearance → inspect the exact CSS, JavaScript or image request named by that HTML. A cached asset at an unchanged URL can outlive the document.
• New document and new asset responses but old screen → check script-rendered content, CSS overrides or application state. Clearing HTTP caches may not address this.
• A document missing from the request log after Back does not prove a cache failure. Navigate to the exact URL or reload while recording.

3. Compare with a request outside the browser

For a public page, replace the example address below with the final URL you recorded. Run it in a terminal; on Windows use curl.exe if curl is a PowerShell alias. This GET prints headers and the body. With redirects, inspect the last response block.

Run the first command, then the second for comparison. These requests do not use your browser’s saved response or execute its service worker. They still go through the public hostname’s delivery path, including any CDN. The second asks caches to validate before reuse; it does not guarantee a direct origin connection or purge anything.

Compare the marker and status in both results with the browser. curl does not render JavaScript or share your signed-in session. Cookie, language or other response variants can explain a difference, so a disagreement alone does not prove which cache is responsible.

• curl -sS -L --max-redirs 5 --max-time 20 -i "https://example.com/page/"
• curl -sS -L --max-redirs 5 --max-time 20 -i -H "Cache-Control: no-cache" "https://example.com/page/"

4. Read the headers without guessing

• Cache-Control: max-age=3600 allows a response to remain fresh for an hour. An old editorial version can still be fresh according to HTTP rules.
• Cache-Control: no-cache allows storage but requires validation before reuse. no-store prevents storage of that response; changing to it does not erase copies already held elsewhere.
• ETag is a version validator. For a conditional request, 304 means reuse the stored body; it is not a new HTML download or automatically an error. If content changed but the validator did not, investigate the validator and selected release.
• Age estimates seconds since generation or successful validation at the origin. It is not the time since your edit. Its absence does not prove the origin was contacted.
• Provider-specific cache headers can be clues. Check that provider’s meaning before treating HIT, MISS or a missing header as a diagnosis.

5. A controlled example: fresh HTML, old stylesheet

On 21 October 2026, Coru ran an isolated HTTP/1.1 experiment in Chromium 155.0.8059.12 with curl 8.5.0. After changing HTML and CSS on the local server, an ordinary return navigation showed the new release-2 text but kept the old red style: the server received no new stylesheet request. Disabling the browser HTTP cache fetched the changed CSS and made it blue. Separately, unchanged no-cache HTML with an ETag produced a network 304; after the body and ETag changed, it produced 200 with the new text. These are controlled technical results, not measurements from readers.

Reproduce the idea on a local test site: give the HTML no-cache and an ETag that changes with its body; give a stylesheet max-age=3600. Visit once, then change both the HTML marker and the CSS rule without changing the stylesheet URL. Navigate again normally and compare document and CSS responses. Finally disable the browser cache and reload. Do not infer a CDN or service-worker result from this local HTTP-cache test.

6. Repair the layer you identified

• Publication: make sure the intended build is selected for the correct host and path. Retest the marker in its delivered response.
• Browser cache of a changing asset: publish a new versioned filename, such as style.v2.css, and update the HTML reference together. Verify that the new file exists and keep old files available for pages still referring to them.
• Shared cache/CDN: after verifying the intended origin release, invalidate the affected URL or release using the provider’s controls. Test that exact public URL again. Adding a random query parameter is only a clue: cache-key rules vary.
• Service worker: in Chrome, inspect Application → Service Workers. Bypass for network is a separate diagnostic switch. If bypass changes the result, investigate the worker’s cache/update strategy, then test with bypass off. A fix must reach returning visitors with the worker enabled.
• Public HTML cache policy: consider validation on reuse with correct validators when timely updates matter. Choose asset freshness separately; a blanket no-store policy is not required for every public file. Personalized pages need their own privacy-aware policy.

7. Keep a short acceptance record

Record: exact final URL; expected and received marker; document or asset; normal browser result; Disable cache result; curl result; response headers; repair; ordinary reload after restoring diagnostic settings. Keep request headers and account data private.

Success means the intended text and assets arrive through the real public URL during an ordinary visit, including a returning browser when relevant. A local cache-cleared screenshot or HTTP 200 by itself is not that check.

Sources & further reading

• MDN: HTTP caching
• Chrome DevTools: Network features reference
• Chrome DevTools: Debug Progressive Web Apps
• IETF RFC 9111: HTTP Caching