Website migration checklist: how not to lose traffic

The short answer

A migration loses traffic in four places: uncovered 301 redirects, titles, descriptions and body text lost during the transfer, a noindex or Disallow: / accidentally left on production, and broken hreflang markup on a multilingual site. Everything else is secondary.

So the whole checklist collapses into one document: the mapping “old URL → new URL” covering every address that produced impressions or clicks in the last 12 months. The map is built before development starts. If it appears on switch day, the migration has already failed; you will simply find out three weeks later.

Traffic drops from four things, not from the move

The move itself is neutral for Google: Search Central describes a site move as a routine procedure and states that with page-level 301s the signals transfer to the new addresses. The same holds for a server change, which I covered in the article on whether hosting affects rankings. The drop happens where the move loses something on the way.

That last row is specific to Estonian projects. After a move, a site in three languages often ends up with hreflang pointing at the previous Estonian and Russian addresses, and Google stops linking the versions together. I covered the typical mistakes in that markup separately in the article on hreflang setup.

The URL mapping decides the outcome

The map is a two-column table with one rule: every old address has exactly one new address carrying the same meaning. Not “a similar section”, but the page the visitor actually followed the link for. Completeness is measured against 12 months of impressions in Search Console, not against the row count of the old sitemap.xml.

The map is assembled from four sources, and none of them covers everything: a crawl sees only what is linked, Search Console only what was shown in search, logs only the last month.

1. A crawl of the old site (Screaming Frog, Sitebulb) gives the addresses reachable through internal links.
2. A 12-month Performance export by page gives the addresses that actually bring traffic, including ones nothing on the site links to any more. Those are orphan pages, and a crawl will not show them.
3. A month of server logs shows which addresses Googlebot still requests and which ones receive people from external links.
4. The old sitemap.xml gives what was meant to be indexable.

Then each address gets one of three decisions: a 301 to its equivalent; a 404 or 410 if no equivalent exists and none is coming; or the page keeps its current address untouched. The third option is the most underrated one: if the URL structure is already sane, there is no reason to change it while moving to a new CMS. The difference between 301, 404 and 410 is covered in the article on what deleted pages should return.

What to capture from the old site before the switch

Before the release you take a snapshot of the old site: not a file backup, but 4 datasets you will use 30 days later to find what went missing. All 4 are captured on the same day, including the 12-month Search Console export, so the dates line up.

• A crawl export with columns for URL, title, description, H1, word count and response code. The file goes into the project repository, not into an email thread.
• A 12-month Performance export, separately by page and by the query-to-page pairing. Search Console keeps 16 months of data, but it will not restore the link between old and new URLs after the move.
• A list of external links at the level of specific URLs, not domains: those are the addresses you cannot afford to lose under any circumstances.
• A ranking snapshot for the core keyword set, so that a month later the discussion is about numbers rather than impressions.

On staging exactly four things get checked: whether it is closed to indexing (basic auth is safer than robots.txt), whether titles and body text match the map, whether new addresses return 200 without intermediate redirects, and whether the new sitemap.xml is generated. How it should work together with robots.txt is covered in the article on sitemap.xml and robots.txt.

Switch day: the order of operations

1. Remove basic auth from staging and open the new site.
2. Remove noindex and check production robots.txt by hand, opening /robots.txt in a browser. This is the single most failed step: Disallow: / travels from staging to production with depressing regularity.
3. Turn on the 301 redirects from the map. Page by page, not with a blanket rule sending everything old to the homepage.
4. Submit the new sitemap.xml in Search Console and leave the old one reachable: it helps the crawler find the redirects faster.
5. For a domain change, file the request through the Change of Address tool.
6. Check the tracking: GA4 and Tag Manager fall off during a template change more often than redirects do.
7. Run the old URLs from the map through a crawler and confirm each one returns 301 in a single hop.

Step seven is the acceptance test: 100 % of the addresses in the map answer with a 301 in one hop, zero chains of two or more redirects. Until a crawler confirms that, the release is not closed, even if the site looks fine.

What to watch in the first two weeks

Check the “Page indexing” report in Search Console daily. Three categories matter: “Not found (404)”, “Page with redirect” and “Duplicate, Google chose different canonical than user”. The first shows holes in the map, the second shows redirect chains, the third shows that new addresses compete with each other, meaning the site now has duplicate content.

Speed gets its own check: a new theme usually drags in fonts, sliders and scripts that were not there before. Core Web Vitals field data in Search Console is calculated over a rolling 28-day window, so the first assessment has to come from lab measurements in PageSpeed Insights compared against the pre-release state.

How long the dip lasts and when to worry

From what I see on migrations of small service sites, things stabilise in two to three weeks. On catalogues with several thousand pages it runs into months: Google does not recrawl addresses simultaneously, and part of the old URLs sit in the index until the crawler gets to them. That is not a fault, that is crawl budget.

The warning sign is not the drop itself but its shape.

• A gradual decline that recovers within 2 to 3 weeks is a normal transition.
• A collapse across the whole site within the first three days means noindex or a blocked robots.txt.
• A drop confined to one section means a missing chunk of the redirect map.
• A flat plateau noticeably below the old level six weeks in means lost content: text was trimmed during the template transfer, and traffic will not return until the text does.

What breaks most often on Estonian projects

Three things repeat from project to project. First: the developer migrates the Estonian version and leaves Russian and English “for later”, so the site spends a month with broken language links. Second: Estonian addresses handle täpitähed differently, the old URL carried õ percent-encoded while the new one transliterates it to o, and addresses stop matching where nobody expected a mismatch. Third: on the old site the Russian version lived on a subdomain and on the new one it lives in a folder, so no redirect map is built for that subdomain at all, because the crawl ran on the main domain.

All three are caught by one habit: crawl the old site in Screaming Frog separately for each language section, and build a separate mapping for the Estonian, Russian and English version.