Most website migrations are planned as a move: same pages, new home, nicer paint. That's the most expensive way to waste the one moment you get to decide what your website should actually contain. A site that has been around for a few years is carrying pages nobody reads, pages that contradict each other, and a handful of pages quietly doing most of the work. A good website migration checklist starts by telling those apart.
Start with a list of every page
You can't decide what to bring if you don't know what you have, and almost nobody does. Menus show a fraction of a site. Years of old service pages, event announcements, landing pages from a campaign three agencies ago and near-copies of the same post are usually still live, reachable from somewhere, and still being found by search engines and AI assistants.
So the first step is an inventory: every address on the site, crawled rather than remembered. When we migrate a site, that crawl is how the project starts, and we keep the list, because it becomes the checklist at the end.
Give every page one of four decisions
Go through the list and give each page exactly one of these:
Keep. The page is accurate, useful and still earns visits or links. It moves across, ideally at the same address.
Merge. Two or three pages cover the same thing. Combine them into one stronger page and point the others at it.
Rewrite. The topic matters but the page is thin or out of date. It moves, but it's improved on the way.
Retire. Nobody needs it: expired offers, old events, empty tag pages, things you no longer do. It doesn't come with you.
Be honest with the last category. Thin and outdated pages aren't harmless filler; they dilute what the site is about, both for people and for the AI tools that now summarise businesses from their websites. We've written about how those assistants decide what to say about your business. A smaller site that is accurate everywhere beats a large one that is accurate in places.
A migration is the only time cutting pages costs nothing extra. Everything you carry across, you'll be maintaining for years.
Protect what's already earning
Here is where migrations go wrong. Some of the pages you're tempted to retire or rename are the ones search engines trust most, and other sites link to them. Change their address without a plan and those links land on an error page, and whatever ranking the page built up starts to drain away.
Before you decide, check which pages actually bring people in. Your search console data shows which pages get impressions and clicks; your analytics show where visitors land. Any page with real traffic or inbound links is in the keep or rewrite pile until there's a very good reason otherwise.
Then, for anything whose address changes, whether merged, renamed or retired, set up a permanent redirect from the old address to the closest relevant new page. Not to the home page: a visitor who wanted your old pricing page should land on pricing, not on a welcome banner. For retired pages with no sensible equivalent, point them at the nearest useful section rather than leaving a dead end.
On our own builds the redirects live in the site's own content, so they can be added or changed without a developer, and a whole spreadsheet column of old addresses can be pasted in at once. That matters more than it sounds: redirects are usually forgotten the week after launch, and the ones that get missed are the ones that cost you.
Check the old addresses after launch
The list from step one earns its keep here. After the new site goes live, every old address on it should be requested and checked: does it load, or does it redirect to the right page? On our migrations that check runs against the full list, and any old address that lands on an error page blocks handover until it's fixed.
Then keep watching for a few weeks. Search console will show crawl errors and pages that dropped out. Some movement in the first weeks is normal; a page that was getting steady traffic and is now getting none needs a look.
While you're there: make it readable to AI
A migration is also the cheapest moment to fix how your site reads to AI assistants, because you're touching every template anyway. Check that the new site doesn't accidentally block the crawlers you want, and decide whether an llms.txt file is worth adding. Neither is a rescue for weak content, but both are much easier to get right at the start than to retrofit.
What's unsettled
We'd be overstating it to promise that a careful migration never dips. Search engines take time to re-crawl, and some fluctuation is normal even when every redirect is right. What a plan does is make the dip small and temporary rather than permanent. And how much AI assistants rely on a site's structure, as opposed to its content, is still changing month to month.
Where to start
Before you talk to anyone about a new design, get the full list of pages on your current site and mark each one keep, merge, rewrite or retire. It takes an afternoon and it will change the conversation. And if you want to see how your current site reads to AI assistants before you move it, run the twenty-second scan.
