After a migration, a surprising number of ‘problems’ are not problems at all — they are caches showing you stale, old content. Caching exists to speed up sites by serving stored copies, but during and after a migration those stored copies can be out of date, making you (or visitors) see the old site, old styling, or old behaviour even though the migration succeeded. Knowing the layers of caching and how to clear each one resolves a whole category of post-migration confusion. This guide walks through them all.

You will learn why caching causes post-migration confusion, the several layers of cache that can each hold stale content, how to clear browser cache, how to clear site and server caches (like caching plugins and server-level caches), the CDN layer, and how to tell a genuine problem from a cache artifact. By the end you will be able to clear every relevant cache and stop mistaking stale caches for migration failures.

Why caching causes post-migration confusion

Caching is the practice of storing copies of your site (or parts of it) so they can be served quickly without regenerating everything each time — which is great for speed but causes confusion after a migration, because those stored copies can be of the old site or old state. When you migrate, the underlying site changes, but caches may keep serving their older stored version until they are cleared or expire.

This produces a whole class of misleading post-migration experiences: you see the old site or old styling even though the new one is live, a change you made does not appear, or the site behaves as it did before the migration. It is natural to interpret these as the migration having failed or not fully worked — but very often the migration is fine, and you are simply looking at a cached old copy that has not refreshed yet.

So caching is a major source of false alarms after a migration, making a successful move look broken. The key realisation is that before concluding something is wrong, you should rule out caching by clearing the relevant caches and looking again — because a large share of ‘the migration didn’t work’ turns out to be ‘a cache was showing me the old version.’ Understanding this saves enormous time otherwise spent debugging problems that do not actually exist.

The layers of cache

There is not one cache but several layers, each of which can independently hold stale content after a migration, which is why clearing just one may not resolve the confusion. Knowing the layers tells you everything that might need clearing:

• Browser cache: your own browser stores copies of pages and assets, so you personally may see an old version even when the live site is updated.
• Site/plugin cache: a caching plugin (common on WordPress) stores generated pages; it can serve old cached pages after a migration until cleared.
• Server cache: server-level caching (like LiteSpeed, Varnish, or object caches) stores content at the host level, independent of any plugin.
• CDN cache: if you use a CDN (content delivery network), it caches your content at edge locations worldwide, which can serve stale copies until purged or expired.
• DNS cache: separately, DNS caching (covered in propagation) affects which server you even reach — a related but distinct ‘stale’ effect.

These layers stack, so stale content can be served by any of them independently: your browser might show old content even after the server cache is cleared, or a CDN might serve an old copy even after the site cache is cleared. This is why post-migration cache-clearing often means clearing several layers, not just one — and why a change can appear for some people (whose caches refreshed) but not others (whose have not). Knowing all the layers exist is what lets you clear them systematically rather than being baffled that clearing one did not fix it.

Clearing browser cache

The first and most personal layer to clear is your own browser cache, because it is the most likely reason you specifically are seeing an old version after a migration. Your browser stores copies of pages, images, and assets to load sites faster on repeat visits, and after a migration it may serve you those stored old copies instead of fetching the fresh ones.

You clear it either by using your browser’s ‘clear cache’ or ‘clear browsing data’ function (choosing to clear cached files/images), or, more conveniently for a quick check, by opening the site in a private/incognito window (which does not use your normal cache) or doing a hard refresh (which forces the browser to re-fetch the page, bypassing its cache). The private-window trick is especially handy, as it instantly shows you the site without your browser cache interfering.

So before assuming a post-migration problem is real, clear your browser cache or view the site in a private window — this alone resolves a large share of ‘I still see the old site’ confusion, because it is so often just your own browser showing you a stored copy. This is the quickest, most personal cache to rule out, and doing so first often reveals that the site is actually fine and only your browser was behind. It costs seconds and prevents needless debugging.

Clearing site and server caches

Beyond your browser, the caches on the site and server itself must be cleared so that everyone — not just you — gets the fresh content. On WordPress, a caching plugin is the common culprit: after a migration, it may still be serving pages it cached from the old state, so you clear its cache through the plugin’s settings (usually a ‘clear cache’ or ‘purge all’ button). This forces it to regenerate pages from the current, migrated site.

Server-level caching is a separate layer that a plugin’s clear does not touch: many hosts run server caches (like LiteSpeed cache, Varnish, or object caching), which store content at the server level and have their own clearing mechanism, often in the host’s control panel or a dedicated plugin. After a migration, clearing the server cache ensures the host is serving the new content, not a server-stored old copy.

So clear both the site’s caching plugin and any server-level cache, since they are independent layers that can each hold stale content — and clearing one does not clear the other. On a migration, it is good practice to clear all the caching your site and host use, so that the fresh migrated content is what gets served to everyone. Knowing your setup (which caching plugin, what server caching the host provides) tells you what to clear; when in doubt, the host’s support can identify the server caches that need purging.

The CDN cache layer

If your site uses a CDN (content delivery network) — which caches copies of your content at edge servers around the world to speed delivery — that is another distinct cache layer that can serve stale post-migration content until it is purged. A CDN can keep serving old cached copies of your pages, images, or assets from its edge locations even after you have cleared your browser, plugin, and server caches, which is a common source of lingering post-migration staleness.

You clear it by purging the CDN’s cache through its dashboard (a ‘purge cache’ or ‘purge everything’ option), which tells the CDN to discard its stored copies and fetch fresh ones from your (now migrated) site. If your CDN is provided or integrated by your host, the purge may be available in your host’s panel or caching plugin; if it is a separate CDN service, you purge it in that service’s own dashboard.

A special note: some host-level CDNs (like a host’s built-in edge cache) are not cleared by the usual Elementor or caching-plugin purges and may self-expire on their own schedule rather than offering an instant purge — so if content stays stale after clearing everything else, a host CDN with its own TTL may be the reason, and it will refresh on its own shortly. So account for the CDN layer when clearing caches after a migration: purge it explicitly where you can, and be aware that a host’s edge cache may need a little time to expire. The CDN is often the last layer standing between a cleared site and the stale copies some visitors still see.

Telling a real problem from a cache artifact

The most valuable skill in all this is distinguishing a genuine migration problem from a mere cache artifact, so you fix real issues and wait out (or clear) false ones. The tell-tale signs of a cache artifact are: the stale content clears when you view in a private window or after clearing a cache; different people see different states (some old, some new); or the ‘problem’ is simply old content/styling showing rather than an actual error.

By contrast, signs of a genuine problem are: the issue persists across all caches cleared and in a fresh private window; it appears consistently for everyone regardless of caching; and it is a real error (a database-connection message, a broken function, missing content) rather than merely a stale version. A real problem does not go away when you clear caches; a cache artifact does.

So the diagnostic routine after a migration is: before treating anything as a real problem, clear the relevant caches (browser first, then site/server, then CDN) and check again in a private window — if the issue disappears, it was a cache artifact; if it persists, it is a genuine problem to fix. This simple habit prevents the enormous time-waste of debugging phantom issues that were only stale caches, while ensuring real problems (which survive cache-clearing) get the attention they need. Clear caches first, diagnose second: that order is what separates the real from the cached, and it resolves a whole category of post-migration confusion at a stroke.

FAQs

How do I clear cache after a website migration?

Clear each layer in order: your browser cache first (or view in a private/incognito window), then your site’s caching plugin (‘purge all’), then any server-level cache (LiteSpeed, Varnish, object cache — via the host panel or a plugin), then your CDN cache (purge in its dashboard). Each is independent, so clearing one doesn’t clear the others. After clearing, check the site in a private window to see the true current state.

Why do I still see the old site after migrating?

Almost always caching serving a stale copy — most often your own browser cache. Caches store copies of your site for speed, and after a migration they may keep serving the old version until cleared or expired. Before assuming the migration failed, clear your browser cache (or use a private window), then the site, server, and CDN caches. A large share of ‘still see the old site’ is just a cache showing a stored copy.

What are the layers of cache to clear?

Browser cache (your own copies — why you personally see old content), site/plugin cache (a caching plugin’s stored pages), server cache (host-level caching like LiteSpeed or Varnish), and CDN cache (edge copies worldwide). Plus DNS cache separately affects which server you reach. They stack independently, so stale content can come from any layer, and clearing one may not fix another — often you clear several.

How do I clear my browser cache to check a migration?

Use your browser’s ‘clear cache’/’clear browsing data’ function (clearing cached files and images), or more quickly, open the site in a private/incognito window (which ignores your normal cache) or do a hard refresh (which re-fetches the page, bypassing cache). The private-window trick is handiest for a quick check — it instantly shows the site without your browser cache interfering, ruling out the most personal cause of seeing old content.

Does a CDN cache old content after migration?

Yes — a CDN caches copies of your content at edge servers worldwide and can keep serving old copies even after you’ve cleared browser, plugin, and server caches. Purge it via its dashboard (‘purge everything’). Note some host-level edge CDNs aren’t cleared by the usual plugin purges and self-expire on their own schedule, so if content stays stale after clearing everything else, a host CDN with its own TTL may be the cause — it’ll refresh shortly.

How do I tell a real migration problem from a cache issue?

Clear the relevant caches (browser, site/server, CDN) and check in a private window: if the issue disappears, it was a cache artifact; if it persists across cleared caches and a fresh window, and appears for everyone, it’s a genuine problem to fix. Cache artifacts are stale content/styling that clears; real problems are actual errors (a connection message, broken function, missing content) that survive cache-clearing. Clear caches first, diagnose second.

The bottom line

A large share of post-migration ‘problems’ are not problems at all but caches serving stale copies of your old site, and understanding this saves enormous wasted debugging. Caching stores copies of your site for speed, and after a migration those stored copies can be of the old state, making a successful move look broken — you see the old site or old styling, a change does not appear, or the site behaves as it did before. The complication is that there is not one cache but several independent layers, each of which can hold stale content on its own: your browser cache (why you personally see old content), the site’s caching plugin, server-level caches (like LiteSpeed or Varnish), and a CDN caching copies at edge locations worldwide. Because they stack, clearing one may not resolve the confusion, and a change can appear for some people but not others depending on whose caches have refreshed.

So the practical routine is to clear the layers in order — browser first (or simply view in a private window, the quickest way to rule out the most personal cause), then the site’s caching plugin, then any server-level cache, then the CDN — remembering that some host-level edge CDNs are not cleared by the usual purges and self-expire on their own schedule, so lingering staleness after clearing everything else may just need a little time. Above all, adopt the diagnostic habit that this whole category demands: before treating anything as a real problem, clear the relevant caches and check again in a private window — if the issue vanishes, it was a cache artifact; if it persists across cleared caches and for everyone, and it is a genuine error rather than merely old content, then it is a real problem to fix. Clear caches first, diagnose second, and you stop mistaking stale caches for migration failures — resolving a whole class of post-migration confusion at a stroke while ensuring the genuine issues, which survive cache-clearing, get the attention they actually need.

When you are ready, you can start with Hostinger and use code PROTIPS for the reader discount. After a migration, clear caches before assuming anything’s broken — stale caches make a successful move look failed. Clear the layers in order: browser (or use a private window), site/plugin cache (‘purge all’), server cache (LiteSpeed/Varnish, via host panel), then CDN (purge in its dashboard; host edge CDNs may self-expire). Then diagnose: if the issue clears, it was a cache artifact; if it persists for everyone across cleared caches, it’s a real problem to fix.