Website Migration SEO: Protect Your Rankings Before, During, and After Every Move

The pre-migration SEO audit is the foundation of every decision made in the migration process. Without it, you are redirecting URLs you have not mapped, restructuring architecture you have not benchmarked, and launching onto a platform whose SEO output you have not validated. The audit is not a formality — it is the document that defines your risk exposure.

A thorough pre-migration audit covers five core areas. First, a full crawl of the existing site to capture every URL currently returning a 200 status. This becomes your redirect mapping source document.

Any URL not in this list that later receives inbound links or search impressions will need to be handled separately. Second, a ranking baseline. Export every keyword for which the current site ranks, mapped to its ranking URL.

This is your recovery benchmark. Post-launch, if a keyword that previously ranked drops, you can immediately identify which URL carried that ranking and verify its redirect status. Third, a backlink profile export.

Every page with inbound links should be prioritised in your redirect map. Link equity passes through 301 redirects, but it does not pass through redirect chains or 404 errors. Pages with strong backlink profiles that resolve to 404 post-migration represent a direct loss of domain authority.

Fourth, an internal link architecture map. Platform migrations often regenerate internal link structures automatically, and the new structure may differ significantly from what was in place. Understanding the existing link hierarchy allows you to validate that the new CMS or template system is replicating it accurately.

Fifth, a structured data inventory. List every page type that currently carries schema markup — product pages, article pages, FAQ blocks, breadcrumbs — and confirm the migration plan includes equivalent structured data implementation on the new platform. In practice, the pre-migration audit is the document your development team, SEO lead, and project manager all work from.

Without a shared source of truth at this stage, decisions made in isolation create compounding issues post-launch.

Redirect mapping is the most operationally intensive part of a website migration SEO process, and it is where the most errors occur. The goal is straightforward: every URL on the existing site that carries any search value — ranking position, inbound links, indexed status, or organic traffic — should resolve to the most relevant equivalent URL on the new site via a single 301 redirect. The challenge is scale and precision.

Large sites may have thousands of URLs to map. E-commerce platforms with faceted navigation can generate tens of thousands of parameterised URLs. Content sites with years of published articles may have significant URL structure changes tied to a new taxonomy.

Each scenario requires a different mapping methodology. For structured migrations where old and new URLs follow a predictable pattern — such as a path change from /blog/post-title to /resources/post-title — bulk redirect rules can handle the majority of cases efficiently. The rule is written once and applied to an entire URL pattern.

For sites where URL structures are being significantly reorganised, a page-by-page mapping document is required. Each old URL is matched to its closest semantic equivalent on the new site. Where no equivalent exists — for content that is being deprecated or consolidated — the redirect should point to the closest relevant parent page or category, not the homepage.

Redirecting everything to the homepage is one of the most common and damaging mistakes in migration SEO. Chain management is a separate discipline within redirect mapping. When a site has been migrated before, existing redirects may already be in place.

A new migration layered on top of old redirects creates chains: a URL redirects to an intermediate URL which redirects again to the final destination. Chains dilute the link equity signal and slow crawl. Before launch, every redirect chain should be flattened so that each old URL points directly to its final destination in a single hop.

Post-launch, redirect validation should be run within 24 hours of deployment using a crawl tool that follows redirect logic. Every 301 should be confirmed, every 404 should be investigated, and any redirect chain introduced by the deployment should be corrected immediately.

The staging environment is where most migration SEO errors are introduced — and where they must be caught before they reach production. A staging site that has been configured incorrectly for indexation, canonicalisation, or structured data will generate errors that persist post-launch if not identified and corrected in advance. The first and most fundamental check is that the staging environment is correctly blocked from indexation.

This is typically handled via a robots.txt disallow directive or a noindex meta tag applied at the server or CMS level. Staging sites that are accessible to crawlers and not blocked can generate duplicate content issues, particularly if they are later indexed before the production launch is complete. Beyond the indexation block, there are several SEO elements that must be validated on staging before any launch decision is made.

The robots.txt file for the production environment should be drafted, reviewed, and confirmed — not left to be configured on the day of launch. The XML sitemap structure should be validated, ensuring it includes only canonical, indexable URLs and is formatted correctly for submission to Search Console. Page-level canonicals need to be verified across all template types.

Platform migrations frequently introduce canonical logic at the template level, which means a single misconfiguration affects every page built on that template. Check that self-referencing canonicals are correct, that paginated series use the appropriate signals, and that any legacy canonical patterns from the old site have been deliberately replicated or updated. Title tags and meta descriptions generated by the new CMS should be audited across a representative sample of each page type.

Templated titles that were functional on the old platform may be constructed differently on the new one, producing truncated, duplicated, or missing title tags at scale. Finally, page speed and Core Web Vitals should be benchmarked on staging. A new platform or theme may have significantly different performance characteristics from the existing site.

Performance regressions post-launch affect both rankings and user experience, and they are far easier to address before deployment than after.

The 30 days after a migration launch are the highest-risk period in the entire process. Search engine crawlers need time to discover the new URL structure, process the redirects, and re-evaluate rankings based on the updated signals. During this window, traffic fluctuations are normal — but unchecked anomalies can indicate deeper technical issues that compound over time if not addressed promptly.

Post-launch monitoring should be structured around four data sources: Search Console, your crawl tool, your analytics platform, and your redirect log. In Search Console, the Index Coverage report should be checked daily for the first two weeks. Any increase in 'Not Found' URLs (404 errors) requires immediate investigation against the redirect map.

The Coverage report will also surface any new crawl anomalies introduced by the migration — unexpected noindex tags, server errors, or canonicalisation conflicts. The Performance report in Search Console shows impressions and clicks at the URL level. Because there is typically a reporting lag of a few days, this data is most useful for identifying sustained drops rather than day-one fluctuations.

Map the top-ranking URLs from your pre-migration baseline against their post-migration performance to identify which pages have lost visibility and whether the redirect for each has been implemented correctly. Your crawl tool should be run against the live site within 48 hours of launch and then weekly for the following month. Compare the post-launch crawl against the pre-migration crawl to verify that the page count, internal link depth, and crawl coverage match expectations.

A significant drop in crawlable URLs is a signal that either the sitemap is misconfigured or the new site architecture is placing content at greater crawl depth than intended. Analytics data — sessions, organic channel performance, and page-level traffic — provides the commercial view of migration impact. Monitor organic sessions daily at both the aggregate and page level.

Sharp, sustained drops on specific page types often point to a systematic issue such as a template-level canonical error or a missing redirect rule pattern.

Platform migrations — moving from one CMS to another — carry a distinct set of SEO risks that go beyond URL structure changes. When the underlying system that generates your pages changes, the SEO output of every template, every content field, and every technical configuration changes with it. These are systemic risks that affect the entire site, not just individual pages.

The most common platform migration scenario is a move from a legacy or custom CMS to a modern platform. In these cases, several SEO elements need to be explicitly re-engineered rather than assumed to transfer automatically. URL structure is the most visible change, but it is not the most dangerous.

The more subtle risks lie in how the new platform handles technical SEO at the template level. Pagination logic, canonical generation, meta tag construction, image alt text handling, and breadcrumb structured data are all typically generated programmatically by the CMS. If the new platform handles any of these differently — and it almost always does — the output across hundreds or thousands of pages changes simultaneously.

For e-commerce migrations, product and category pages carry the highest SEO value and the most complex technical requirements. Faceted navigation, filter URLs, product variant pages, and out-of-stock product handling all need explicit SEO logic in the new platform. These are frequently deprioritised in the development scope because they are treated as edge cases — but they represent a significant portion of the organic traffic for most e-commerce sites.

For content-heavy sites, the migration of the editorial taxonomy — categories, tags, author pages, archive pages — requires careful thought. New platforms often generate these pages with different URL patterns and different pagination logic. If the old platform generated /category/seo-strategy/page/2 and the new one generates /category/seo-strategy/?page=2, every paginated archive URL has changed and needs a redirect.

Content field mapping is another area where SEO value is routinely lost in platform migrations. If the old CMS stored the SEO title and meta description in custom fields and the new platform uses a different field structure or SEO plugin, the import process may not carry these fields across correctly. Post-migration, pages may be serving auto-generated titles rather than the optimised titles that contributed to their rankings.

A domain migration — moving your site from one domain to another — is the highest-risk migration type from an SEO perspective. Domain authority, which search engines build over time based on the accumulated backlink profile, content quality signals, and historical trust indicators of a domain, does not automatically transfer. It passes through 301 redirects, but the signal transfer is not instantaneous and is not always complete.

The starting point for any domain migration is the backlink profile audit. Every domain that links to your current site is passing authority to that domain. When you migrate, those links still point to the old domain.

Your redirects pass the signal forward, but the most effective resolution is to update the links themselves where possible — particularly for high-authority referring domains. Reach out to site owners where you have a relationship and request that the link destination be updated to the new domain. Search Console configuration for a domain migration requires specific steps.

The Change of Address tool in Search Console is designed specifically for domain migrations and should be used once the redirects are confirmed to be working correctly. This tool signals to Google that the migration is intentional and accelerates the re-evaluation process. Both the old domain and the new domain must be verified in Search Console before the tool can be used.

Branding changes that accompany a domain migration introduce an additional layer of complexity. If the domain change is accompanied by a site name change, a visual rebrand, and a content reorganisation simultaneously, the number of concurrent changes to evaluate makes it significantly harder to diagnose any ranking issues that emerge post-launch. Where possible, separating the domain migration from other major changes — completing the domain move first, then making structural or content changes — reduces the diagnostic complexity if problems arise.

The timeline for authority recovery after a domain migration is longer than for other migration types. In practice, sites that execute domain migrations with clean redirect coverage and correct Search Console configuration tend to see gradual recovery over a period of several months, with some fluctuation in the earlier weeks as crawlers work through the new domain's content.