A new website can look better, load faster and convert more effectively, then lose valuable organic traffic within days if search engines cannot understand what moved where. This site migration SEO checklist is for the period before, during and after a site rebuild, replatforming, domain change or major URL restructure.
The central rule is simple: a migration is not a design launch. It is a controlled transfer of search signals from one version of a site to another. URLs, internal links, redirects, canonical tags, metadata, structured data and indexability all need deliberate treatment. Leave these decisions until the final week and the risk rises sharply.
Start with a clear site migration SEO checklist scope
Before anyone builds a redirect file, define what is actually changing. A move from one CMS to another while keeping the same URL structure is materially different from combining several sites, changing a domain, moving to a JavaScript-heavy frontend or rewriting every content page.
Write down the answers to a few practical questions: Are domains changing? Will URLs change? Are any pages being removed or merged? Is the site moving between subdomains and subfolders? Will the new frontend render content differently for crawlers? Are international pages, downloadable files or logged-in areas involved?
This matters because the technical work should match the risk. A small brochure site may need a careful URL inventory and redirect plan. A large content platform may need crawl data, server log analysis, rules for pagination and faceted navigation, and a phased release. Treating both projects alike is either wasteful or dangerous.
Build a reliable inventory of the existing site
You cannot preserve pages you have not identified. Start by crawling the live website and collecting every indexable URL, along with status codes, titles, meta descriptions, headings, canonical tags, word counts and internal link data.
That crawl is only one source. Add URLs from XML sitemaps, analytics landing-page reports, search performance data, paid campaign destinations and, where available, server logs. Crawlers find what is linked internally; search engines and users may still visit orphaned pages, old campaign pages or documents that matter commercially.
For each URL, make a decision. It should either remain live at the same address, move permanently to the closest equivalent new page, be consolidated into a stronger replacement, or be intentionally retired. “We will decide later” is not a migration status.
High-value pages deserve extra scrutiny. Prioritise pages with organic visits, impressions, backlinks, leads or a clear role in the buyer journey. A low-traffic page with strong external links can be more valuable than its analytics profile suggests.
Create a URL mapping sheet
A mapping sheet is the operational heart of a website migration checklist. It should include the old URL, destination URL, redirect type, page purpose, owner and implementation status. It becomes the shared reference for marketing, content and engineering teams.
Do not redirect removed pages to the homepage by default. Search engines usually treat that as a poor substitute when the old and new content are unrelated. Redirect a discontinued service page to the most relevant surviving service page, for example. If no meaningful replacement exists, a genuine 404 or 410 response can be the cleaner choice.
Use permanent 301 redirects for permanent moves. Avoid chains such as old page to interim page to final page. They slow crawling, lose clarity and often survive long after launch because nobody notices them.
Build the new site with crawlability in mind
A technically polished interface can still be difficult to crawl. During development, confirm that primary content, links and metadata are available in the initial response or are rendered reliably for search engines. This is particularly relevant when moving to React or Next.js — see our separate guide to Next.js website migration without lost rankings for framework-specific detail.
Client-side rendering is not automatically wrong, but it introduces more variables. If critical product, service or editorial content appears only after scripts run, test what a crawler actually receives. For many marketing and content pages, server-side rendering or static generation is a simpler, more dependable default.
Maintain one clear canonical URL for each indexable page. Canonical tags should point to the preferred live address, not to staging URLs, old domains or pages that redirect. Ensure pagination, filtered URLs and duplicate query parameters have an intentional policy rather than accidental indexation.
Technical SEO is also tied to performance. Large JavaScript bundles, unoptimised images, shifting layouts and slow server responses can hurt user experience and make crawling less efficient. Improving Core Web Vitals is worthwhile — our notes on how to improve your Core Web Vitals score properly cover the main levers — but do not sacrifice page content or navigation merely to improve a lab score. A fast page that omits the information users need is not an improvement.
Test the migration before the public launch
A staging environment needs protection from indexation, but that protection must be removed correctly at launch. A password wall is usually safer than relying solely on a robots.txt file, because robots.txt does not prevent a URL appearing in search results if it is discovered elsewhere.
Before release, crawl the staging site as if it were live. Check that important pages return 200 status codes, redirects return one clean 301 hop, and error pages are genuine 404 responses. Validate internal links, canonical tags, hreflang annotations where relevant, XML sitemaps, robots directives and structured data.
This pre-launch stage is where a general website launch checklist and a migration-specific one diverge: a migration adds the redirect map, the legacy URL inventory and a rankings baseline on top of the usual release checks. If you want the wider list too, the technical SEO checklist we run on every launch covers the non-migration essentials. For a migration specifically, work through a short but disciplined pre-launch list:
- The redirect map is implemented and tested against the complete list of legacy URLs.
- Staging noindex tags, password controls and blocked crawl rules have a documented removal plan.
- Production canonical tags use the correct HTTPS domain and preferred host format.
- XML sitemaps contain only canonical, indexable URLs that return 200 status codes.
- Analytics, consent controls and search verification are present without blocking essential page content.
- Key templates are tested on mobile devices, not only in a desktop browser.
Also test real journeys. Submit a contact form, open a downloaded document, follow navigation from a popular landing page and check any search or filter behaviour. Migration defects often sit at the boundary between technical SEO and ordinary product quality.
Launch with change control, not hope
Avoid deploying unrelated redesign tweaks, copy rewrites and infrastructure changes at the same time if they can be separated. A migration already creates enough variables. When rankings or conversion behaviour change, you need to be able to identify why.
At launch, switch the site deliberately: enable production indexation, activate redirects, publish the XML sitemap and verify that the preferred domain resolves consistently. HTTPS, www and non-www variants should all lead to one canonical version through a single redirect.
Then crawl the live site immediately. Compare its URL count, response codes, titles, canonical tags and internal links with your pre-launch benchmark. Sample redirects manually, especially top organic landing pages and URLs with external links.
Do not remove the old redirect rules after a few weeks. Users, bookmarks, old articles and search results can continue to request historic URLs for a long time. Permanent redirects are part of the site’s infrastructure, not a short-lived launch task.
Monitor what search engines do after release
Search engines need time to recrawl and process a changed site. Some fluctuation is normal, particularly after a major consolidation. The question is whether the signals point to healthy replacement or a preventable error.
Monitor crawl errors, indexed page counts, sitemap processing, top landing pages, impressions and clicks. Watch for unexpected noindex directives, canonical exclusions, spikes in 404s, redirect loops and pages that have dropped from the index despite being intended for search.
Compare like with like. If a dozen thin pages were intentionally merged into one useful page, raw indexed URL counts should fall. That is not necessarily a problem. Equally, a rise in page speed scores does not offset a missing redirect for a high-intent service page.
Keep a launch log of deployments and observed issues. It makes troubleshooting far faster than relying on memory when a marketing lead notices a traffic change two weeks later.
Treat migration SEO as an engineering responsibility
The best migrations involve marketing and engineering early, with a single owner for the mapping, testing and launch checklist. SEO requirements should sit alongside accessibility, security, analytics and performance acceptance criteria, not arrive as a final request after the build is signed off.
If the migration involves a valuable domain, complex routing or a new React or Next.js architecture, an independent technical review before launch is usually cheaper in effort than repairing lost visibility afterwards. Our software engineering services include exactly this kind of pre-launch review: a senior engineer who can explain the risks plainly, test the implementation and leave you with documentation you can use on the next change too.
A careful launch does not promise unchanged rankings — search results are never fully under your control. It does ensure that the new site gives search engines clear, consistent evidence of what has moved, what has improved and where each valuable page now belongs. If you are planning a migration and want a second pair of technical eyes on the plan, book a free consultation and we can review the architecture, redirect approach and pre-launch checks before the switch is made.
