Website Migration SEO Checklist: Relaunch Without Losing Rankings

A relaunch is the moment when websites most often lose visibility they spent years building. That is rarely Google's fault. It comes from URLs that disappear without a redirect, content that gets cut during the rebuild and blocks from the test environment that go live with the new site. A good website migration SEO checklist therefore makes sure of two things: knowing exactly what you have before the move, and checking that it is still there afterwards.

With this checklist you can map every URL you have, plan the redirects before launch day and check after the move that your rankings and traffic have held.

What costs rankings in a relaunch

Before the steps, it helps to look at the usual causes. Almost every loss falls into one of these groups:

• Changed URLs without redirects. Google and every backlink point to addresses that no longer exist.
• Lost content. Pages are merged, shortened or dropped even though they brought in visitors.
• Changed internal linking. A new navigation pushes important pages deeper or orphans them completely.
• Technical blocks. noindex, a blocking robots.txt or password protection from staging end up on the live site.
• Too many changes at once. A new domain, new URL structure, new design and new copy on the same day make it almost impossible to find the cause of a drop.

Phase 1: Inventory before the relaunch

You can only protect what you know. Before any planning, collect a complete list of existing URLs and what they are worth.

1. Crawl the old site completely. A crawl returns every reachable URL with status code, title, canonical and internal links. Save it, you will need it for comparison later.
2. Export important pages from Search Console. The Performance report shows which pages bring clicks and impressions. These pages take priority in the redirect plan.
3. Record link targets. Pages with external backlinks must get a matching new address no matter what.
4. Add landing pages from your analytics. This surfaces pages that matter through other channels.
5. Measure rankings as a baseline. Track your most important keywords before the relaunch. Without a baseline you cannot tell later whether anything changed.

For URL mapping, Google recommends collecting important addresses from sitemaps, server logs and Search Console. That is described in the guide to site moves with URL changes.

Phase 2: The redirect plan

The redirect plan is the most important document of the relaunch. It maps every old URL to a new one that serves the same purpose.

• Map one to one. An old product page points to the new product page, an old guide to the new guide. If there is no direct equivalent, use the closest page by topic.
• Do not redirect everything to the homepage. Google often treats such redirects like a soft 404. The signals of the old page are lost anyway.
• Use server-side redirects. Google recommends permanent HTTP redirects such as a 301 redirect or a 308. JavaScript or meta refresh redirects are only a fallback.
• Avoid chains. If redirects from earlier rebuilds already exist, point them straight to the new destination instead of through several hops.
• Do not forget files. Images and PDFs with rankings or backlinks need a redirect too.
• Keep them long enough. Google advises keeping redirects for as long as possible, generally at least one year.

Phase 3: Check the staging environment

Most mistakes can be found before they go live. Crawl the staging environment and compare it with the old site.

• Content of important pages. Are the copy, headings and titles of the pages with the most clicks still complete?
• Canonicals. Every canonical tag must point to the future live address, not to the staging domain.
• Internal links. The new site should link directly to the new URLs, not to old addresses that only get redirected. The glossary entry on internal linking explains why.
• Language versions. On multilingual sites, the hreflang annotations must be updated to the new URLs.
• Blocks only on staging. Staging should be protected by a password or noindex. Write down exactly which blocks you need to remove before launch.
• Rendering. If the new site loads content with JavaScript, check that titles, copy and links appear in the rendered HTML.

Test redirects systematically

A redirect plan is only as good as its test. Do not just check a few examples in the browser, check the complete list of old URLs from your crawl and the Search Console export. Four things should be true for every URL:

1. The old address responds with a 301 or 308.
2. There is exactly one redirect, not a chain of several hops.
3. The destination responds with 200 and is not set to noindex itself.
4. The destination matches the old page in content.

The first three points can be checked automatically, the fourth cannot. So at least review the pages with the most clicks and backlinks one by one. A redirect to an unrelated page is technically correct and still a loss for search.

Special cases: domain change, HTTPS and a new shop system

Domain change. Verify both the old and the new domain in Search Console and submit a Change of Address for the old property. Keep the old domain registered and redirecting permanently. Also update the links you control yourself, such as profiles, directories and partner sites.

Moving to HTTPS. Only the protocol changes here. Redirect every HTTP address to its HTTPS version and update canonicals, sitemaps and internal links. A Change of Address in Search Console is not needed.

Switching shop or CMS platforms. URL patterns often change systematically, for example from addresses with file extensions to readable paths. Rule-based redirects are then better than thousands of individual entries. Pay special attention to filter and parameter URLs that the new system generates differently, and to whether structured data for products and reviews survives.

Phase 4: Launch day

On the day of the switch, a fixed order matters.

1. Activate the redirects and test a sample from the plan, especially the pages with the most clicks.
2. Remove staging blocks: noindex, password protection and blocking rules in robots.txt.
3. Submit the new XML sitemap in Search Console. Google recommends also submitting a sitemap with the old URLs so the redirects are discovered faster.
4. If you change domains, submit a Change of Address in Search Console for the old property. It is not needed for new URLs on the same domain or for a move to HTTPS.
5. Crawl the new site completely right after launch.

Phase 5: The first weeks afterwards

Google points out that rankings fluctuate temporarily during a move. For medium-sized sites it can take a few weeks or more before the new URLs replace the old ones in the results. During this time, check regularly:

• the Page indexing report and crawl stats in Google Search Console,
• new 404 errors and server errors, including in your server logs,
• whether the old sitemap gradually shows fewer indexed URLs and the new one more,
• rankings for the keywords you measured as a baseline before the relaunch.

A few losses in the first days are normal. If important pages have not reappeared after several weeks, check their redirect first and then their content. Our guide to Crawled - currently not indexed explains what to do with pages Google crawls but does not index.

Common mistakes

• Staging stays on noindex and nobody notices until traffic drops.
• Canonicals keep pointing to the staging domain after launch.
• Old redirects get overwritten, and backlinks from earlier rebuilds lead nowhere.
• Many URLs are redirected wholesale to the homepage or a category.
• Internal links still point to old URLs and create redirect chains on your own site.
• All copy is rewritten along with the relaunch, so nobody can tell which change caused which effect.

How a crawl comparison protects the relaunch

The most valuable test before launch is a direct comparison between the old site and staging. It shows which URLs disappear, which titles change, where canonicals point to other targets and which status codes are new.

In Crawl Foundry Site Audit you crawl both environments and compare them in migration or staging mode. Mapping rules for hosts, path prefixes, query parameters, trailing slashes and exact URL pairs make sure old and new addresses are compared with each other despite a changed structure. The documentation on crawl comparison explains the modes in detail. After launch, you repeat the comparison between two crawls of the live site and see which findings are new, fixed or regressed. Position Tracking lets you keep an eye on rankings for your most important keywords at the same time.

Our article on technical SEO issues in Site Audit shows how to put crawl findings into a useful order.

The checklist

Before the relaunch

• Old site crawled completely and saved
• Important pages from Search Console, backlinks and analytics recorded
• Rankings for the most important keywords measured as a baseline
• Redirect plan created for all important URLs, one to one
• Staging crawled and compared with the old site
• Content, titles, canonicals, hreflang and internal links checked on staging

On launch day

• Redirects active and spot-checked
• noindex, password protection and robots.txt blocks removed
• New and old sitemaps submitted in Search Console
• Change of Address submitted if the domain changes
• New site crawled completely

In the weeks after

• Page indexing and crawl stats monitored
• New 404 and server errors fixed
• Rankings compared with the baseline
• Crawl comparison between launch and current state reviewed

Keeping your rankings through the move

A relaunch without ranking losses is mostly careful preparation: a complete inventory, a redirect plan for every important URL, a crawled and compared staging environment and a fixed order on launch day. After that, monitoring in the first weeks decides whether small mistakes stay small.

On the first day after launch, check that your most important URLs respond and that their redirects work.