SEO migration checklist: how to manage organic-search risk during a website rebuild.

A new website can improve brand, user experience, content management and conversion. It can also change almost every signal that search engines and customers use to find and understand the organisation.

URLs may move. Navigation and internal links change. Valuable pages are merged or shortened. Metadata, structured data, headings and copy are rewritten. JavaScript rendering, hosting, analytics and consent configuration may change at the same time.

SEO migration is the workstream that identifies that existing value, carries what should be preserved into the new experience, manages deliberate change and monitors the result.

It does not remove uncertainty. Google’s current site-move guidance says significant changes can produce temporary ranking fluctuations while pages are recrawled and reindexed. A careful migration can minimise avoidable problems; no agency can guarantee unchanged rankings, traffic or revenue.

The most important timing lesson is simple:

What counts as an SEO migration?

The work is relevant whenever a website change may alter discovery, indexing, relevance or measurement. Common triggers include:

• A new CMS or eCommerce platform
• Redesign and information-architecture change
• Domain, subdomain, protocol or URL-path change
• Content consolidation, removal or rewriting
• Multisite, brand or regional consolidation
• JavaScript framework or rendering change
• Hosting or CDN change, even when visible URLs stay the same
• Analytics, tag-management or consent change

The plan should match the change. Moving hosting without URL changes follows a different technical path from changing thousands of product URLs. Google publishes separate guidance for hosting changes without visible URL changes, which reinforces why “website migration” is not one universal checklist.

Why migrations affect search performance.

Search engines have accumulated knowledge about the existing website. They have discovered URLs, crawled content, interpreted internal links and received signals from external links and user demand.

A rebuild can disrupt that understanding in several ways:

• A valuable URL returns an error or redirects to an irrelevant page.
• The new page does not satisfy the query intent of the old page.
• Internal links no longer point to priority content.
• Staging `noindex` or crawl blocks remain active after launch.
• Canonical tags point to old, staging or inconsistent URLs.
• Important content is hidden behind unsupported interaction or rendering.
• Analytics does not capture the same events or conversions.
• The website returns errors or cannot support increased crawling.

Some change is deliberate. A new architecture may remove weak duplication or create clearer pages. The objective is not to freeze the old website. It is to know which changes are being made, why they are worth the risk and how the result will be evaluated.

The migration plan should also identify dependencies outside the website team’s direct control. Domain access, hosting configuration, third-party search, translation, feeds, campaign destinations and external development vendors can all affect timing or verification. Record the responsible person, required access and decision deadline for each dependency. A technically correct checklist still fails when the only person who can change DNS, approve a redirect or restore a service is unavailable at cutover.

Phase 1: establish the baseline before architecture locks.

Assign an SEO migration owner.

The SEO workstream must have a named owner, decision rights and access to design, content and technical discussions. If SEO reviews the website only after content and URLs are approved, the project has already made consequential decisions.

Create a change log covering architecture, templates, domains, rendering, content, metadata, data feeds, analytics and release timing. Identify who approves URL mapping and who can stop launch for a critical issue.

Build the complete URL inventory.

Use several sources because none is complete alone:

• Current XML sitemaps
• A full crawl of accessible URLs
• CMS and eCommerce exports
• Analytics landing pages
• Search Console pages and queries
• Server logs where available
• Backlink data
• Paid campaign, email and social destinations
• Images, videos, PDFs and other indexed files

Google recommends using sitemaps, analytics or logs, CMS data and linked pages to build a list for complex moves. The inventory should include status code, canonical, indexability, title, headings, content type, internal links, organic performance, conversions and backlinks where relevant.

Record search and commercial benchmarks.

Capture enough history to understand seasonality and normal variation. Segment by template, directory, brand, location, product or content cluster rather than relying only on sitewide totals.

Useful baseline measures include:

• Organic clicks, impressions, queries and landing pages
• Indexed and excluded URL groups
• Rankings for commercially important query themes
• Organic sessions and engaged visits
• Enquiries, transactions and revenue attributed or assisted by organic landing pages
• Crawl errors, response codes and performance
• Backlinks and referring domains to important URLs

Record the date, property filters and attribution assumptions. You will need comparable reporting after launch.

Decide what should be preserved, improved, consolidated or removed.

Do not copy every page automatically. Review the purpose, search intent, business value and content quality.

For each page, choose a disposition:

• Preserve with the same URL and equivalent or improved content
• Move to a new equivalent URL
• Consolidate into a genuinely relevant destination
• Rewrite because the intent remains valuable but guidance is stale
• Remove because it has no useful equivalent or continuing purpose

A migration is a good time to improve the content estate, but high-value removal needs evidence and approval.

Phase 2: design the new website with migration in view.

Finalise information architecture with search evidence.

New navigation should serve users, brand and operational goals. Search evidence adds another view: which topics, locations, products and questions already connect customers to the organisation?

Map priority intents to new destinations. Avoid forcing several distinct needs into one generic page merely to reduce page count. Conversely, avoid creating many near-duplicate pages without a clear user purpose.

Create a one-to-one URL mapping where possible.

Every old URL needs a deliberate outcome. The preferred mapping is usually old page to the most equivalent new page.

Google recommends server-side permanent redirects such as 301 or 308 when a URL has moved. It also warns against redirecting many unrelated URLs to the new home page, which can confuse users and be treated as a soft 404.

Maintain the mapping as a controlled project artefact with old URL, new URL, disposition, owner, rationale and test status. Include parameters or legacy patterns where they generate accessible URLs.

Avoid redirect chains. Point old URLs to the final destination, not through an intermediate page. Update internal links to the new URLs so users and crawlers do not rely on redirects for normal navigation.

Protect content equivalence and on-page signals.

A redirect carries a user and a search engine to a destination; it does not make an unrelated page equivalent.

For important pages, compare:

• Primary purpose and query intent
• Essential copy, products or service information
• Titles, headings and descriptions
• Images, files and media
• Structured data and eligibility requirements
• Internal links in and out
• Calls to action and conversion path

The new page can be better and differently designed. It should still satisfy the reason the old page earned visibility unless a deliberate business decision changes that purpose.

Control staging safely.

Prevent premature indexing through appropriate authentication or access controls. If `noindex` or robots rules are used, maintain an explicit launch list for their removal. Google identifies forgotten `noindex` and crawl blocks as common migration mistakes.

Use production-like data and URLs where safe so redirects, canonical tags, internal links, structured data and sitemaps can be tested. Ensure staging references cannot leak into the release.

Build measurement before launch.

Implement analytics, tag management, consent behaviour, advertising tags and CRM or eCommerce events on the new templates. Validate key journeys and compare event definitions with the baseline.

Changing measurement at the same time can create an apparent traffic or conversion change that is really a tracking change. Document every difference.

Phase 3: complete pre-launch validation.

Run a full crawl of the production-ready build and compare it with requirements.

Technical search checks.

• Priority pages return the intended status code.
• Indexable pages have self-referencing canonicals using production URLs.
• Robots directives and robots.txt match the launch plan.
• XML sitemaps contain canonical, indexable production URLs only.
• Internal links point directly to final URLs.
• Metadata and headings are present and appropriate.
• Structured data is valid and matches visible content.
• Mobile and rendered content contain the material information.
• Pagination, filters and international annotations behave as designed.

Redirect checks.

Test the entire mapping at scale, not only ten examples. Confirm destination, status, chains, loops and irrelevant mappings. Separately test the highest-value pages, backlinks, campaign URLs and files.

User and commercial checks.

Test organic landing pages through to forms, calls, account actions and transactions. Confirm confirmation pages, notifications, CRM capture, product availability and payment where relevant.

Launch plan and rollback criteria.

Set a cutover sequence, owners, communication channel and decision points. Define which failures can be fixed forward and which require rollback or traffic control. Preserve a recoverable copy of configuration, mapping and production data under appropriate controls.

Time the release for a period when the right people and vendors are available to monitor and respond. Lower traffic can reduce customer impact, but staff readiness matters more than an arbitrary late-night launch.

Phase 4: launch and verify immediately.

After cutover:

• Check the home page, priority templates and transactions from outside the deployment environment.
• Confirm robots.txt and remove temporary `noindex` directives as planned.
• Test old-to-new redirects and direct new URLs.
• Validate canonical tags, structured data and the new XML sitemap.
• Confirm analytics and conversion events in real time.
• Verify Search Console ownership for the relevant properties.
• Submit the new sitemap.
• For an eligible domain move, use Search Console’s Change of Address tool after redirects and verification are ready.
• Watch application, server and CDN errors.

Do not declare the migration complete after the first crawl succeeds.

Monitor the migration until the evidence stabilises.

Google explains that website moves occur per URL and that discovery and processing time depends on website size and server capacity. Monitor both old and new properties where relevant.

Daily or high-frequency checks at first.

• Availability, 5xx responses and failed transactions
• Robots, index directives and canonical errors
• Priority redirect failures
• Search Console indexing and crawl errors
• Analytics collection and major conversion changes
• Server logs for crawler access and unexpected errors

Weekly trend review.

• Old URLs falling and new URLs rising in indexed coverage
• Organic clicks and impressions by page group and query theme
• Brand and non-brand demand
• Landing-page engagement and conversion
• Backlink destinations and high-volume external links
• New 404s, redirect chains and soft-404 patterns

Distinguish expected movement from a defect. Ranking fluctuation alone is not a diagnosis. A sudden loss across one directory may point to redirects, content or internal links. Sitewide disappearance may indicate indexability, availability or domain configuration.

Keep a record of fixes and annotation dates so later changes can be interpreted.

Google recommends keeping redirects for as long as possible, generally at least one year, and notes that indefinite redirects may continue to help users. Update internal and important external links to their final destinations rather than relying on redirects permanently.

A public example: Primary Dental.

Our public Primary Dental case study describes a website programme for more than 60 locations that included multiple integrations, SEO migration, transition and security considerations.

The example illustrates why migration must sit alongside website architecture and delivery. It does not prove that a specific method prevents all ranking change, and no private performance result should be added without current evidence and permission.

Common migration mistakes.

• Involving SEO after the sitemap and copy are approved
• Mapping only current sitemap URLs and missing live legacy pages
• Redirecting many old pages to the home page
• Keeping redirect chains from previous migrations
• Removing useful content because the visual design prefers shorter pages
• Launching with staging `noindex`, blocked resources or staging canonicals
• Measuring sitewide traffic without page-group or query context
• Changing analytics definitions without documenting them
• Turning off redirects too early
• Treating the launch date as the end of the workstream

Treat organic visibility as an asset to be migrated deliberately.

A rebuild should not preserve every weakness of the old website. It should preserve valuable discovery paths and evidence while making deliberate improvements.

Benchmark before decisions lock. Inventory the full URL estate. Map every old page. Protect content equivalence. Build redirects, canonicals, internal links, staging controls and analytics into delivery. Test the complete mapping. Monitor old and new signals until the evidence stabilises.

If a website rebuild or replatform is being planned, book a meeting with us before the sitemap and content structure are finalised. We can help define the appropriate SEO migration workstream alongside website Discovery and implementation.