Website Migration SEO: A Checklist for Before, During and After Launch

Website migration SEO is work on URLs and content, not on the look of the site. Visibility drops when the mapping of old URLs to new ones breaks, or when page content changes unexpectedly alongside the move — the crawler then hits a 404, a redirect loop, or a page that no longer answers the same query. A new layout, new colours and a new content management system do not on their own push a site out of search results. What follows is an operational checklist in three blocks — before, on launch day, and after — plus the rollback plan you need ready before anything moves.

Website migration SEO starts with URLs, not with the design

Two things lose visibility: broken URL mapping and uncontrolled content change. Everything else — a different template, different photos, a different colour scheme — is secondary to a search engine, as long as the URL still answers with the same status code and the same answer to the same query.

Broken mapping has several faces, and all of them are visible in the Page Indexing report in Google Search Console: 404 errors, redirect errors, 5xx server errors, required 401 authentication, a robots.txt block, a noindex tag, and duplicates or alternate versions. That is a ready-made list of things to check after every deployment — Google sorts it for you.

Five kinds of migration and the risk each one carries

Not every migration is equally risky — what decides is how much you change at once. The worst scenarios are the ones where a domain change, a URL structure change and a content rewrite all ship in a single deployment, because after a drop nobody can tell which of them caused it.

A platform change deserves its own decision before the migration starts, because it determines what URLs look like on the new site — the comparison of whether WordPress or a custom website fits better is the place to settle that. For a shop the equivalent decision is a hosted or a custom online store, because a subscription platform usually imposes the URL pattern you will be redirecting into. When hosting changes, watch what happens after the move to the Core Web Vitals thresholds for LCP, INP and CLS, because a new environment can move response times in either direction.

The “before” block: four things you cannot recreate after launch

Before deployment you collect data that stops existing the moment the old site is switched off. This is the part of a migration that cannot be made up later.

1. A complete list of the old site’s URLs. Crawl the site with a tool such as Screaming Frog, add the URLs from the sitemap and from your Search Console reports, and save the result as a file, not as a browser tab.
2. A 1:1 old URL to new URL map. One row, one source URL, one target URL. No exceptions and no empty cells.
3. A decision for URLs with no counterpart. Each one gets either a redirect to the closest match by topic, or a 410 status stating that the content has been withdrawn. A silent 404 is a decision not taken.
4. A baseline export from Search Console. The Performance report gives you clicks, impressions, CTR and average position, and the data reaches 16 months back. An export taken before the migration is the only reliable reference point you will have afterwards.

The staging environment gets locked down at this same stage. The safest block is requiring authentication at server level — a noindex tag and a robots.txt entry can be lost when the environment is copied or deployed to production, and then the staging version reaches search results alongside the live one.

If an outside team is running the migration, the same scope is worth writing down at the start — describe both sites to us and you get that scope back in a form you can put in front of a supplier.

The “launch day” block: an order that matters

On launch day you carry out four actions in a fixed order, confirming each by observation rather than by the supplier’s word.

First you switch the 301 redirects on according to the map and check a dozen or so random URLs from the spreadsheet: each should reach the right target in a single hop, with no loops and no chain of further jumps. Then you remove the indexing block from the new site — this is where a noindex tag left over from testing, or a robots.txt rule blocking a whole directory, most often turns up.

Third comes the sitemap: a new sitemap.xml with current URLs, submitted in Search Console. Fourth, and most often skipped, is confirming that the old version is not answering in parallel — after a hosting change it can keep running for a while on the old IP address or a technical hostname, serving a full copy of the content.

A domain change adds a fifth element: the Change of Address tool in Google Search Console. You report the move from the old domain property to the new one, with redirects already working and access to both properties in place. It tells Google the move is intentional rather than a failure of the old site.

The “after” block: what to check in the first day, week and month

After launch, monitoring follows a schedule instead of meaning you check rankings every hour. Three horizons answer three different questions.

The first 24 hours — is the new site reachable for the crawler. Take your dozen or so most important URLs and run them through the URL Inspection tool. That tool settles the status of a specific URL; the site: operator gives an approximation and is not proof. Rule out, in order, a robots.txt block, a noindex tag, 5xx server errors, 404 errors, redirect errors and required 401 authentication.

The first week — is the index keeping up. You read the Page Indexing report: how many URLs carry the “Indexed” status, how many “Not indexed”, and for what reasons. A rising count of redirect errors or duplicates means the map has holes — reading those reports is covered in more depth in an SEO audit and what blocks visibility.

After a month — has visibility come back, not just availability. You compare the Performance report against your pre-migration export at query and URL level, not at total level. URLs that dropped out fall into three groups: those with no redirect (add them to the map), those whose content genuinely changed (decide whether to revert), and those you redirected elsewhere on purpose. Companies serving a local area also check that the URLs listed in their business profile and directories still work — the part of local SEO that tends to be left pointing at old addresses after a migration.

The rollback plan: what has to be ready before anything goes live

A rollback plan is the set of assets and decisions prepared before deployment that lets you return to the state from before the migration. After launch it is too late — a missing database copy cannot be produced retroactively.

Before deployment you need:

• a frozen copy of the old site — files and database as of the moment of freezing, stored off the production server,
• the old hosting and domain paid for through a period agreed in advance after the migration, not merely until the next renewal date,
• a lowered TTL on your DNS records, set a few days before the change, so a return does not have to wait for old caches to expire,
• a reverse redirect map — the same spreadsheet read right to left, ready to deploy,
• the old site’s configuration saved: robots.txt, sitemap, redirect rules, Search Console settings,
• a trigger and a decision-maker — what specifically sets a rollback in motion (mass 5xx errors, say, or a spike in URLs with redirect errors) and who makes that call.

Some changes are one-way: rewritten content and new URLs that have already entered the index come back more slowly than server configuration does. A rollback plan therefore covers mainly the first days after launch, and its purpose is to rescue the availability of the site.

How to tell normal variation from a fault and from a penalty

A ranking drop with no message in the Manual Actions section of Search Console is not a penalty. That section is the only place where Google reports a manual action — if it flags no problems, there is no penalty and nothing to appeal.

Repeated content is not a penalty either: duplicate content does not appear on Google’s spam policies list. What it can do is lead to URL consolidation or worse ranking — which is exactly what you see after a migration when the old and the new version answer in parallel.

That leaves the question of time. Google states that some changes take effect within hours and others only over months, and recommends waiting a few weeks before judging the outcome (Google SEO starter guide, updated 10 December 2025). An honest assessment of a migration therefore means checking, in this order: are the URLs reachable, are they in the index, do they appear for the same queries. When a site still does not show up in results, Google maintains a help page listing the reasons to work through before anyone starts talking about a penalty.