The mistakes to avoid in a website migration

People often say a website migration always loses traffic. That is wrong: the loss almost always comes from a mistake, and it is often the same ones. Here are the most frequent, from the decision to monitoring after launch.

For an overview of website migration (definition, steps, cost), see our reference article.

Do you really need this migration? Changing CMS just because you prefer another one is not a benefit worth the risk. Set the expected gain and how you will measure it before deciding: see the good reasons to migrate a website.

Migrations are often underestimated, and the SEO specialist is only brought in shortly before going live, or even after, when the damage is visible. Involve them from the mock-up stage: site structure, templates and URLs are decided early, and the redirect plan takes time.

A migration is a risky project. If good practice is not familiar to you, call on a specialised consultant or agency, checking their experience of migrations: agencies fail them too for lack of method. To build your skills, our video course on website migration on YouTube goes through the steps one by one.

A migration done by hand needs at least a crawler (Screaming Frog or another), a spreadsheet and access to Search Console and Google Analytics. To secure the redirect plan, add the link exports from your tools (Majestic, Ahrefs, Babbar, SEObserver, Search Console) and the server logs: they reveal URLs the crawl does not find. Swan replaces the crawler and the spreadsheet for matching the pages, the longest part to do by hand.

A URL that is no longer in any menu can still receive links and traffic. Inventory every URL that matters: those from the crawl, but also those from Search Console, link tools, server logs, campaigns and old sitemaps. A URL missing from the inventory will get no redirect.

Redirecting every old URL to the home page amounts, for Google, to deleting them: it treats these redirects as 404 errors. Each old page must lead to the new page closest in content, in a single hop. Redirect chains (an old migration, then HTTPS, then the new one) slow down crawling and dilute authority. See the redirect plan.

When changing domain, the link between the old one and the new one only holds as long as you keep owning the old domain and its redirects stay in place. Letting the old domain expire wipes out at once the benefit of the links it received. See should you renew the old domain name and how long to keep a redirect.

A staging site is closed to search engines (robots.txt, noindex, password): these settings must not reach production. Conversely, the staging site must never be indexed, or you get duplicate content. At launch, check the robots.txt, the noindex tags, the canonical tags (which must point to the new addresses, never to the staging site or the old site) and the XML sitemap.

A change of host carries almost no risk for rankings, unless the new server is undersized or far from the target audience: slow pages or errors while Google crawls the whole site degrade indexing. Compare the offer with your real needs before committing.

A migration that copies the site as it is also copies its flaws: dead links, duplicate content, slow pages, old crawling problems. Use the prior audit to fix them, rather than finding them again on the new site. See the content audit.

A migration is complex because of the number of points to check and the rigour each step requires. Test the redirects on the staging site, check them again on production on launch day, then monitor indexing, errors and traffic over the following weeks. Our migration checklist lists the checks, and the article on SEO problems after a redesign helps diagnose a drop.

Most of these mistakes are prevented during the preparation phase of the migration: backup, inventory, baseline measurements and redirect plan. The search side is detailed in our SEO migration guide.