Website Migration SEO: Pre and Post-Launch Checklist

Website Migration SEO: Pre and Post-Launch Checklist

A website migration is one of the riskiest moments in a site's life. A redesign, a new CMS, a domain change, or a move to a new hosting platform can each change URLs, templates, internal links and metadata at the same time. When that happens without a plan, a site that took years to build can lose most of its organic traffic in weeks.

Most migration losses are preventable. They come from a small number of predictable causes: missing redirects, changed or dropped URLs, canonical and noindex tags that were carried over by mistake, blocked resources, broken internal links, and content that changed more than the team realised. None of these are exotic. They are simply easy to miss when the focus is on the new design.

This checklist covers the work before launch, the checks on launch day, and the monitoring needed for the first three months.

Define what kind of migration this is

Migrations differ in risk. Name the type first, because the checklist depends on it.

• Redesign on the same URLs. Visual and template changes only. Risk is mostly in metadata, internal links and performance.
• URL structure change. Paths change, for example from /blog/post-name/ to /resources/post-name/. Requires a full redirect map.
• CMS or platform change. Templates, rendering and sometimes URL patterns change. Test rendering carefully. The JavaScript rendering post covers that risk.
• Domain change. The domain itself changes. Requires redirects, Search Console changes and link-related work.
• Protocol or subdomain change. For example, moving to HTTPS or changing www handling. Needs consistent redirects and canonicals.

Document the type, the scope, and the date. Everything that follows should match the scope, not a generic template.

Step 1: Crawl and record the current site

Before anything changes, capture the baseline. You cannot check a migration against a site you have not recorded.

Run a full crawl of the live site and export:

• Every indexable URL, with status code, canonical, title, meta description, H1, and word count
• Internal links and their anchor text
• Redirects already in place, including chains
• Pages with traffic or links, pulled from analytics and Search Console

Save the crawl with a date. This file becomes the reference for every check after launch.

Also export the Search Console performance data for at least 12 months, and the list of pages that receive organic clicks. These are the pages that cannot be lost.

Step 2: Build the URL inventory and decide each fate

Create a spreadsheet with one row per URL. For each, decide what happens on the new site:

• Keep the same URL, with no change.
• Redirect to a new URL, with a 301 response.
• Merge into another page, where two old pages become one. Redirect both to the chosen page.
• Remove deliberately, where the content is no longer needed and has no traffic or links. Return a 410 or redirect to the most relevant remaining page, depending on the case.

Do not redirect everything to the homepage. Redirecting unrelated pages to the homepage wastes the signal from those pages and creates a poor experience. Redirect each URL to the closest equivalent page.

The content pruning post covers deciding which pages deserve to survive. The migration inventory is where those decisions are applied.

Step 3: Map redirects one to one

The redirect map is the core of a migration. Every old URL that is changing needs a single redirect to its new equivalent.

Check that:

• Each old URL redirects in one step to the final destination. Chains, where one redirect points to another, slow crawling and can lose signal.
• Status codes are 301 for permanent moves. Temporary 302 redirects are not appropriate for a migration.
• Redirects preserve path meaning. A blog post should redirect to the new blog post, not to a category page, unless the new site has no equivalent.
• Trailing slashes, case differences and parameters are handled consistently. An old URL with a trailing slash and one without should resolve to the same destination.
• HTTP versions redirect to HTTPS and non-www to the chosen www version, or the reverse, in a single step.

Test the full map before launch. A spreadsheet of rules is not proof. Run every old URL through a request and confirm the status code and final address.

Step 4: Check canonicals, noindex and robots directives

The new site often carries directives from a staging environment, and these can cause severe problems.

Before launch, confirm:

• No staging noindex tags remain on production pages. A noindex left in place removes pages from search.
• Canonical tags point to the new URLs, not to old addresses, staging domains or the homepage.
• robots.txt does not block the content, templates or resources that the new site needs for crawling and rendering.
• The sitemap lists only new, canonical, indexable URLs, and does not include redirected or noindexed pages.

These are the most common self-inflicted losses. Check them on a sample of templates and on a full crawl.

Step 5: Preserve on-page content and metadata

A migration often changes titles, descriptions, headings and body copy without anyone deciding to. Compare the old and new versions of each important page.

Look for:

• Title tags and meta descriptions that have been shortened, removed or rewritten without reason. The title tags post covers how these should be written for search.
• H1 headings that have changed meaning or disappeared
• Body content that has been cut, moved behind tabs or accordions, or replaced with less detail
• Image alt text that has been dropped in the new template
• Structured data that no longer validates or has been removed

Keep the content of high-traffic pages intact unless a change is deliberate and reviewed.

Step 6: Keep internal links working

Internal links are part of the site's architecture. A migration can break them in several ways: links to old URLs that now redirect, navigation that changes depth, and orphaned pages that lose their connections.

Check that:

• Internal links point to new URLs directly, not through redirects, where possible
• Important pages remain within a few clicks of the homepage
• Anchor text is still descriptive, not replaced with generic labels
• No important page has become orphaned, with no internal links at all

The website structure post and the internal linking post cover how to rebuild the link architecture for topical authority.

Step 7: Test performance and rendering on the new templates

A new template can change page speed, layout stability and the way content is rendered. Test the new templates before launch, not after.

Measure:

• Core Web Vitals on representative templates: homepage, service pages, article pages, product or listing pages
• Whether the main content is present in the initial HTML, if the new site relies on client-side rendering
• Whether new scripts or third-party tags block critical resources

The Core Web Vitals post and the JavaScript rendering post go into the detail for these checks.

Step 8: Launch with a plan for the first day

On launch day, run a short set of checks in the first hours, not the first week.

• Recrawl the live site and compare against the baseline crawl
• Test a sample of old URLs from the redirect map, including the most important pages, blog posts and any URLs with external links
• Confirm that the sitemap is updated and submitted in Search Console
• Check that Search Console and analytics are tracking the new property, or the new domain if it changed
• Confirm that the live site is not blocked by a leftover staging setting

Keep the team on call for the first 48 hours. Early errors are easier to fix before they spread.

Step 9: Monitor for the first three months

Migration effects unfold over weeks, not hours. Monitor on a schedule, and compare against the baseline.

In Search Console, watch:

• Indexing reports for a rise in excluded or not-indexed pages
• 404 and soft 404 reports for old URLs that were missed in the redirect map
• Crawl stats, looking for unusual drops or spikes
• Performance by page, comparing high-value pages with their pre-migration figures

Set a routine. Weekly checks in the first month, then fortnightly, and monthly after that. Keep a log of what was fixed and when.

The indexing and sitemaps post covers how to speed up discovery of the new URLs, which is useful when a large number of pages have moved.

What a migration checklist cannot do

It cannot prevent all traffic movement. Some fluctuation is normal, especially after a large structural change. A checklist reduces avoidable losses, but it does not guarantee that rankings will return to their previous level.

It cannot compensate for a weak new site. If the redesign removes content that earned traffic, or the new pages are less useful, the losses are a product decision, not a technical error.

Common migration mistakes to avoid

Launching with staging noindex tags. This removes the whole site from search and is among the most damaging errors.

Redirecting everything to the homepage. It throws away the relevance of individual pages.

Using 302 redirects for permanent moves. Temporary redirects do not transfer the same signal.

Forgetting the old sitemap. An outdated sitemap sends crawlers to URLs that no longer exist.

Changing content without a record. Undocumented edits make it impossible to diagnose a traffic drop later.

Testing only the homepage. Most migration losses appear on deep pages, which need checking as well.