Checking whether a change you made took effect
Before you decide an edit failed, prove you are actually looking at the new version. Two mistakes eat most of the time lost after a change: concluding it did nothing when it simply has not surfaced yet, and concluding it worked when what you are looking at was assembled earlier and handed back unchanged. Both are solved by testing at a known layer rather than by refreshing and hoping.
Build the change so the question is answerable
Decide, before you edit anything, what string proves the new version is live. A version number in a comment, a distinctive class name, a value you can grep the response for. "Does the page look right" is a judgement call you will argue with yourself about. "Does the response contain v7" is a yes or no. This habit removes more ambiguity than every purge you will ever run.
Every layer that can hand you an old copy
| Layer | Holds a copy for | How to look past it |
|---|---|---|
| Your browser | The freshness window the response declared | A private window, a hard reload with the cache disabled, or fetching the URL from the command line so no browser is involved |
| Plugin or application cache | Its own interval, often independent of everything else | Request the URL with a unique query string appended, which usually misses the stored key |
| Server side page and opcode cache | Seconds to hours, or until the file timestamp changes | Compare two consecutive requests: a first that is slow and a second that is fast means something is being stored |
| Edge proxy or CDN | Per rule, per location | Read the response headers for hit or miss and age; request from a different network or device on mobile data |
| Resolver cache, for name changes only | The TTL that was published before you edited | Query an authoritative nameserver directly and compare it with what your own resolver answers |
Work inward, not outward
- Read the origin response first. If the server itself still emits the old bytes, clearing an outer layer cannot help and only destroys evidence.
- If the origin is correct, move one layer out and repeat. The layer where the marker string disappears is the layer holding the stale copy. That is your answer.
- Only then purge, and purge only that layer. Flushing everything at once tells you nothing about which layer was at fault, so you will be back here next week.
- Re-request and confirm the marker. An unverified purge is not a fix, it is a hope.
Response headers usually name the culprit outright. Age, validators, and the directives that govern reuse are worth knowing properly; the HTTP caching reference covers what each field actually promises.
Name changes run on a clock you set in the past
When you repoint a hostname, the delay you experience was determined by the TTL that was already published, not by the one you just saved. Lowering it now helps the next change, not this one. Disagreement between an authoritative nameserver and your local resolver is expected during that window; it is only a failure if the authoritative answer is wrong. Lower the TTL days ahead of a move instead of diagnosing a wait you created yourself.
One change, then verify
Change one thing, verify it, keep or revert it, then move on. Two edits made together produce one ambiguous result you cannot attribute. Slower per step, much faster overall.
The reverse trap
Here is the expensive version. You edit something, reload, see no difference, assume the edit was wrong, and make a second edit on top of it. The first edit was correct and was being masked. Now you have two changes live, one of them unnecessary and possibly harmful, and the result you eventually see cannot be attributed to either. Worse, a rollback now returns you to a state that never existed. When a change appears to do nothing, the next move is to prove which layer you are reading, not to write more code. If you are still stuck, capture the exact request and its response headers first, then bring both to support. More on isolating a symptom before acting on it in diagnostics.
Still not sure which way to go?
Tell us what you are building. If it needs less than you think, we will say so.