Site migration: the link check-list

A migration breaks links in four distinct places, and most teams check one of them, usually the redirects, then declare it done. The other three surface weeks later, one complaint at a time.

This check-list covers the links inside and into your site. The separate question of the backlinks other sites gave you deserves its own pass: keeping your backlinks through a redesign. The two run on the same day, with the same people, and are all the easier to confuse for it.

The check-list, in order

None of these steps is difficult on its own. What makes migrations go wrong is that they are done in the wrong order, or all on the same afternoon.

A month later the subject is closed. What breaks after that belongs to ordinary maintenance, not to the migration, and confusing the two sends you looking in the wrong place.

Before: three lists worth having

The URLs that receive traffic. From your analytics, over twelve months, not one. Seasonal pages are the ones nobody remembers in July, and they are the ones that generate complaints in November.

The URLs that receive links, internal and external. These are the addresses that must keep answering, whatever else changes. They are in Search Console, in your own link tracking, and in your server logs, where visits arriving from outside are recorded.

The absolute URLs written inside your content. This is the list nobody makes, and it is where migrations actually break. Every https://olddomain.com/... typed into an article body survives the export perfectly and keeps pointing at the old place. Search your content export for your own domain name and count the hits: the number is usually a surprise, and the older the site, the bigger the surprise.

On the day: the four places links break

1. The redirect map. One hop, page to equivalent page. The decision for each retired URL follows the same tree as any page removal, and that tree never produces "redirect to the homepage".

2. Internal links inside content. Relative links usually survive. Absolute ones do not, unless you rewrite them. Do it as a search-and-replace on the export, before import, not afterwards page by page.

3. Navigation, footer, and templates. Menus are often built from hard-coded paths in a theme. They are on every page, so a mistake here is the most visible one you can make, and the quickest to fix if you test it on the day.

4. The technical furniture. Sitemap regenerated, robots.txt reviewed, canonical tags pointing at the new URLs, hreflang updated if you run several languages. Each of these silently contradicts the others when only some are updated, and the contradiction produces no visible error.

After: what to verify, in order

• Open the old URLs. Not the new sitemap, the exact old addresses. Each should answer 200 after exactly one redirect. Two hops work as well, and will be cut one day by someone tidying up.
• Crawl the whole new site. This is the pass that finds the absolute links you missed, and it is the reason to do it now rather than in six months. The free methods are enough for a site of a few hundred pages.
• Check the outbound links too. A migration is the one moment someone actually reads every page: take the opportunity, they show up nowhere else.
• Watch Search Console for a month. Crawl errors arrive gradually, not on launch day, and a rise in the third week is normal.

The case of a domain name change

It is the heaviest migration there is, and it deserves three extra rules.

The redirect is kept indefinitely. Not two years: indefinitely. An abandoned domain takes the entire link history with it, and it is often bought by someone else afterwards, which turns your old references into links to a site you no longer control.

The old domain is renewed alongside the new one. The expiry date is the real end date of your migration, and it is the one nobody writes down anywhere.

Email counts too. Addresses at the old domain keep receiving mail for years, including renewal notices and alerts from your own suppliers. A successful migration that loses the mailbox is a failed migration two years later.

Who does what, and why it matters

A check-list without an owner turns into a wish list. Three roles are enough, even in a team of two.

Someone owns the lists: traffic, links, absolute URLs. That is spreadsheet work rather than technical work, and it can start a month ahead without depending on anybody.

Someone owns the redirects: writing them, putting them live, testing them. It is the only role that has to be present on switch-over day.

Someone owns the verification afterwards: the checks at D plus 1, D plus 3 and D plus 30. It is the role people forget to assign, and it is the one that decides whether the migration went well or whether you find out in February.

What will break anyway

There is no such thing as a perfect migration, and planning for leaks beats promising watertightness.

URLs with parameters, old search pages, attachments and images almost always slip through. Links sent in emails three years ago will keep arriving, and nobody can list them. And redirect chains inherited from a previous migration often reveal themselves at this point, because they add one more hop and cross the limit beyond which nothing follows any more.

The right answer is not to try to foresee everything: it is to watch the server logs for the first two weeks. They list what people actually requested, including what you never imagined, and they are the only report that does not depend on a list drawn up in advance. Triaging those 404s follows its own rules: not all of them deserve a fix.

The two mistakes that cost the most

Redirecting everything to the homepage because the mapping was left to the last afternoon. It converts a manageable list of decisions into a permanent loss, and it repairs badly, because afterwards nobody knows which old URL corresponded to what.

One case comes up more often than the rest and is handled in exactly the same way: moving from HTTP to HTTPS. Every one of your addresses changes, so it is a migration, with this same check-list. What HTTPS really changes, and what it does not is worth reading before working through it.

Removing the redirect rules a year later during a clean-up, by someone who was not there. Those rules are the only thing still attaching years of links to your site. Keep them, and leave a comment in the file saying why they exist and which migration they belong to.