The site changed, but you cannot see the change
You fixed some text, a style, or an image. The deployment finished without an error, but the site still shows the old result.
This usually means that the browser or one delivery stage is returning a stale copy. Do not restart everything immediately. First identify the exact page or file that reaches the user.
A common path is “browser → CDN → server or storage.” A CDN is a network of intermediate servers that keeps copies closer to visitors. A stale version can remain at any of these stages.
Start with three checks
1. Separate your browser cache
Open the site in a private window, another browser, or another device. A private window helps separate local browser data, but it does not bypass the CDN. If another device shows the update, that proves only that this access path received it.
2. Find the exact URL of the stale file
For an old design, inspect the stylesheet; for old button behavior, inspect the JavaScript file; for an old image, open its URL. In browser developer tools, select Network, reload the page, and check the file URL and name. The key question is whether the page requests the new version.
3. Compare the public file with the build output
File size is only a clue. A checksum is stronger: a match is strong evidence that the compared bytes are the same, while a mismatch proves that they differ. Compare the intended files. If the delivery system transforms content automatically, check an embedded release version or a known marker instead.
Where to look for the cause
- If only one browser remains stale, inspect its local cache.
- If the HTML refers to an old filename, inspect the page deployment.
- If the public file differs from the build, inspect the server or storage copy.
- If the server copy is correct but the public one differs, suspect the CDN cache.
These cases are not exhaustive, but they turn a vague symptom into a specific stage to investigate.
Fix only the confirmed cause
Use versioned filenames for stylesheets, scripts, and images, such as app.a31f.css. New content then receives a new URL instead of being confused with an older cached copy.
Publish new files before the page that refers to them. Keep old files available while open or cached pages may still request them.
Purge a CDN cache only after confirming that the server copy is correct. If the provider supports purging one URL, start there. Verify the public file again after the fix.
How to use AI safely
Give AI the public URL, expected version, deployment time, and log excerpts with secrets removed. Ask it to separate facts from assumptions, order three checks by risk, and state what each result would mean.
Without connected tools, AI cannot inspect your system. Do not provide tokens, passwords, or private URLs, and verify every suggestion against the public URL or build file. The Prompt Pack contains a ready-to-use request.
What not to do
- Do not repeat an entire deployment because one file is stale.
- Do not purge the CDN before checking the server copy.
- Do not treat a green status as proof of the public result.
- Do not overwrite a long-cached file when you can change its name.
- Do not send secrets or unredacted logs to AI.
Cloudflare’s cdnjs migration report describes a larger but relevant problem: individual stages could finish while the complete process did not, and the lack of one shared identifier made tracing harder. It does not show that every stale page is a CDN problem. The broader lesson is to verify the final public result, not only one stage’s status.
Sources
Quick checklist
- check the page in a private window or on another device
- identify the URL and filename that remain stale
- check whether the page points to the new file version
- purge only the affected URL instead of clearing every cache blindly
- verify the result through the public URL after the fix
Find why an old version remains after deployment
Help me find why a site or file still looks old after a deployment. Here is what I know: 1. What should have changed: [page, style, image, JavaScript, or another file] 2. Public URL: [URL] 3. What I see now: [description] 4. What I have already checked: [private window, another device, deployment time, and so on] 5. URL and name of the affected file: [if known] 6. Safe response headers or deployment log excerpts: [no tokens or passwords] Do not pretend that you can access my system. Separate facts from assumptions first. Return: - the most likely location of the stale copy; - three checks ordered from simplest to more advanced; - what each check should confirm or rule out; - the safest corrective action; - what should not be purged or restarted without more evidence.