Skip to content
Contact DA
Published

Website Migration SEO Checklist

A website migration is not only a design or development project. It is also a change to the URLs, content, internal links, metadata, and technical signals that search engines already understand.

When those signals are moved carefully, a new platform can launch with limited disruption. When they are treated as a final SEO task, important pages can disappear, redirects can point to the wrong place, and search engines must work out the new structure with incomplete information.

Old and new website structures connected through carefully mapped redirects and migration checks

What counts as a website migration?

A migration can include more than moving to a new domain. Search risk is introduced whenever important URLs or the way content is delivered changes.

Common migrations include:

  • Moving to a new CMS or framework
  • Redesigning the site and changing templates
  • Changing domains, subdomains, or protocol
  • Reorganizing categories and URL paths
  • Combining several websites
  • Moving from client-side rendering to server-rendered or static pages
  • Removing, consolidating, or rewriting large amounts of content

The larger the change, the more important it is to separate migration work into clear stages. Changing the domain, platform, content, navigation, and visual design at the same time makes problems harder to isolate.

Start with a complete URL inventory

Before building the redirect map, collect the URLs that currently matter.

Use several sources because no single source is complete:

  • Crawl the current website
  • Export indexed and submitted pages from Google Search Console
  • Review XML sitemaps
  • Export landing pages from analytics
  • Include URLs with backlinks or referral traffic
  • Include campaign, product, category, document, and image URLs where relevant
  • Review server logs for URLs that crawlers and users still request

Record each URL’s status code, canonical target, indexability, title, primary heading, traffic, backlinks, and intended destination. This inventory becomes the reference for redirect mapping, testing, and post-launch monitoring.

It also reveals existing problems. The old website may already contain redirect chains, duplicate pages, orphaned content, or conflicting canonical signals. Decide which issues should be cleaned up during migration and which should be preserved temporarily to reduce launch risk.

Create an explicit URL map

Every important old URL should have a deliberate outcome:

  • Keep the same URL
  • Redirect to a close equivalent
  • Consolidate into a stronger relevant page
  • Return a real 404 Not Found or 410 Gone when no replacement exists

Do not redirect every removed URL to the homepage. A redirect should lead users and search engines to a page that satisfies approximately the same intent. Irrelevant redirects create a poor experience and may be treated like soft 404s.

Keep the mapping in a structured document that development, content, and SEO work can share. Include the old URL, new URL, reason, implementation status, and test result. This makes missing routes and accidental decisions visible before launch.

Preserve the signals that still matter

A migration often includes improvements, but useful existing signals should not disappear by accident.

For important pages, compare the old and new versions:

  • Main content and purpose
  • Page title and meta description
  • Primary heading and heading structure
  • Internal links
  • Canonical URL
  • Robots directives
  • Structured data
  • Language alternates
  • Images, alt text, and downloadable files

The new page does not need to be identical, but it should still clearly serve the reason the old page ranked or received traffic. A technically correct redirect cannot compensate for replacing a useful page with thin or unrelated content.

Control staging carefully

The staging site should be available to the people testing it but unavailable to the public and search engines.

Use authentication or network-level access control where practical. A noindex directive is useful as an additional safeguard, but it must be removed before launch. Blocking the staging site only with robots.txt can prevent crawlers from seeing the noindex directive and does not protect private content from people who know the URL.

Create a launch check specifically for temporary controls:

  • Remove staging authentication from the production environment
  • Remove noindex from pages intended for search
  • Confirm production robots.txt allows the correct areas
  • Replace staging domains in canonicals, links, schema, and sitemaps
  • Remove test analytics, API endpoints, and credentials

Temporary migration settings have a habit of becoming permanent production problems when they are not tracked explicitly.

Implement redirects without chains

Use server-side permanent redirects for URLs that have permanently moved. Point each old URL directly to its final destination instead of routing through earlier versions.

For example:

old URL -> final new URL

Avoid:

old URL -> previous redesign URL -> HTTP version -> final new URL

Redirect chains slow requests, consume crawl resources, and create more places for a migration to fail. Existing external links may still point to very old URLs, so include historical redirects in the review and update them to the final destination where possible.

Google’s guidance for site moves with URL changes recommends keeping redirects for as long as possible, generally at least one year. In practice, useful redirects can remain longer when old links and bookmarks still exist.

Update internal signals to the final URLs

Redirects are a safety net, not the preferred route through the new site.

Update internal links, navigation, canonical tags, hreflang references, structured data, and XML sitemaps so they point directly to the final production URLs. This helps users and crawlers follow the new structure without unnecessary redirects or conflicting signals.

The sitemap should contain canonical, indexable, successful URLs only. Do not include redirected, blocked, duplicate, or missing pages. This connects directly to the wider work around crawlability and indexation.

Test before launch

Crawl the staging site and compare it with the current production inventory. Test more than the homepage and a few templates.

Check:

  • Every mapped redirect
  • Important pages and user journeys
  • Status codes and response headers
  • Canonicals and robots directives
  • Internal links and orphaned pages
  • XML sitemaps
  • Structured data
  • Mobile layout and accessibility
  • Forms, search, checkout, login, and integrations
  • Page speed and rendered content
  • Error pages and missing URLs

Automate repeatable checks where possible. A simple script or crawler export comparison can find hundreds of missing redirects or incorrect canonicals more reliably than manual browsing.

Keep the launch controlled

Avoid launching immediately before a weekend, holiday, or period when the right people cannot respond. Make sure backups, rollback steps, DNS access, redirect configuration, analytics, and monitoring are ready before the switch.

At launch:

  1. Deploy the production site and redirect rules.
  2. Confirm temporary staging controls are gone from production.
  3. Test a representative group of important old and new URLs.
  4. Crawl the live site.
  5. Submit the new sitemap.
  6. Use Search Console’s Change of Address tool when moving domains and the tool is applicable.
  7. Check logs, analytics, forms, integrations, and error monitoring.

A rollback plan should define what must fail before the old system is restored. Without that decision in advance, teams can spend critical launch hours debating whether a problem is serious enough.

Monitor after launch

Migration work continues after the new site is public.

Watch:

  • Indexation and crawl reports
  • Organic landing pages and search traffic
  • 404, 500, and redirect responses
  • Server logs and crawler activity
  • Sitemap processing
  • Canonical selection
  • Rankings for important queries
  • Conversion and form completion
  • Performance and Core Web Vitals

Compare results with the benchmarks collected before migration. Some fluctuation is normal while search engines recrawl and process the changes, but technical errors should be investigated quickly rather than dismissed as temporary.

Common migration mistakes

The same avoidable problems appear repeatedly:

  • Redirect mapping starts too late
  • All old URLs redirect to the homepage
  • Internal links still point through redirects
  • Production launches with noindex
  • Canonicals or schema still reference staging
  • Valuable content is removed without an equivalent
  • JavaScript rendering hides important content
  • The sitemap contains redirects and errors
  • Tracking or conversion flows stop working
  • Nobody monitors the site after launch

A migration does not need to preserve every weakness of the old website. It does need to preserve the value people and search engines already rely on while the underlying platform changes.

Migration checklist

Before approving the launch, confirm that:

  • The existing URL inventory is complete enough to protect important pages
  • Every important old URL has a tested outcome
  • Redirects point directly to relevant final URLs
  • Content and metadata changes are intentional
  • Internal links, canonicals, language alternates, schema, and sitemaps use production URLs
  • Temporary staging controls are removed from production
  • Important user journeys and integrations work
  • Analytics and monitoring are active
  • Backups and rollback steps are ready
  • Post-launch ownership and checks are agreed

Good migration work is mostly preparation, explicit decisions, and careful verification. The visible launch may happen in one day, but preserving search visibility depends on the work completed before and after it.

More articles