Tutorial · migration-hosting · Published 2026-08-16 · 4 min read
Cache and CDN after a migration
After a migration, flush WordPress, browser, DNS and CDN caches and verify the new origin is live instead of a stale copy.
A site migration ends at the DNS cutover, but the users may still be shown the old site for longer than the DNS change, because caches hold their own copies. The content delivery network, the hosting-level page cache, the CMS cache, the browser and even DNS resolvers each keep a version of the site, and none of them are invalidated just because the files or DNS changed. Clearing them in order is part of a correct migration, not an optional finish.
What survives a move
Different caches answer to different triggers:
| Cache | What it holds | Survives DNS change? |
|---|---|---|
| CMS cache (WordPress page cache, Redis) | Rendered pages | Yes, until flushed |
| CDN edge cache | Copied responses | Yes, until TTL or purge |
| Host page cache | Static full-page copies | Yes, until cleared |
| Browser cache | CSS, images, pages | Yes, per URL |
| DNS resolver cache | Old origin IP | Yes, until TTL |
The last one is the migration-specific case: if an old copy was fetched from the previous origin, the caches still hold it. The older browser content article covers browser-side staleness, and the general CDN static assets guide explains edge caching.
Flush each layer in order
Do this after the DNS cutover has begun, from the systems you control down to the ones you only affect:
- CMS and host cache: flush the WordPress object and page cache (via the panel, a caching plugin, or the relevant tool) and clear the hosting-level full-page cache so the new origin renders fresh pages.
- CDN edge cache: purge the site at the CDN provider. On Cloudflare this is the purge operation covered in the purge cache article; the aim is the same on any edge, remove the copied responses for the site's URLs.
- Origin responses: confirm new response headers (cache control) point browsers at the new host and set an appropriate expiry, so stale copies do not linger.
- Browser: a private window bypasses your own browser cache and confirms the public response, rather than debugging a stale local copy.
- DNS: all that flush does is start fresh fetches from the current resolver or IP state; it does not force other resolvers. It is expected that some users see the old IP until the TTL passes.
The exact first click after cutover often shows the old site for the person who is testing, because their own browser or resolver still holds a copy. A private window against a freshly purged edge is the trustworthy test.
Verify the new origin
The final check is that the bytes come from the new host:
curl -sI https://example.com/Compare the server or response header that identifies the host, and confirm a page or asset you changed as part of the migration is present. If the response still shows the old host after the DNS TTL and a CDN purge, either a resolver was slow or a cache was missed; walk the layers again rather than waiting.
Prevent the second round
- Lower the relevant cache control TTLs before cutover so edge and browser versions naturally expire faster during the move.
- Record the full list of caching layers in your migration notes, so the flush step is not dropped on a repeat move. The migration checklist is the place to keep it.
- Confirm that getting a fast edge does not hide a broken origin: after purging, watch the origin for errors for a day, since a healthy edge can mask an origin fault (see the site down after DNS update article for that trap).
When stale content persists
A visitor seeing the old site after a migration is almost never a reason to revert. Flush the layers in the order above, confirm the origin via curl, and let the TTL and browser timeouts clear the stragglers. If a specific page keeps showing old data, it is usually a single missing purge or a CMS cache that was not flushed, and the fix is that one layer.