A website migration without losing SEO starts with defining what is actually moving. A hosting change with identical URLs has a very different risk profile from replacing a domain, CMS, URL structure, design and content at the same time.
No team can guarantee zero ranking movement after a substantial migration. Search engines must crawl and process the changes, while users and third-party systems may still request old addresses. The purpose of an SEO migration is to preserve accumulated signals, remove preventable technical errors and keep any disruption temporary rather than allowing it to become a long-term decline.
A plan for website migration without losing SEO
An SEO migration plan is necessary whenever a release can change how search engines discover, render, interpret or consolidate pages. Common scenarios include:
- Hosting migration: the domain and URLs stay the same, but DNS, server infrastructure or CDN changes.
- Domain migration: every public address moves to a different domain or subdomain.
- CMS or framework migration: templates, rendering, metadata and backend behaviour change, even if URLs do not.
- URL migration: folders, slugs, parameters or taxonomy are restructured.
- Redesign: layouts and components change while the existing information architecture is retained.
- Site replacement: an old website is replaced by a newly developed version.
- Combined migration: domain, CMS, URLs, design and content all change in one release.
Risk rises when several variables change together because diagnosing a loss becomes harder. Google Search Central recommends changing one major thing at a time where practical. A business might move hosting first, confirm stability, and only then release the redesigned CMS. Commercial constraints sometimes require one launch, but that decision calls for broader testing and a stronger rollback plan.
Build a recoverable baseline before development ends
Do not treat the XML sitemap as a complete inventory. It may omit orphaned pages, legacy URLs, parameter variants and URLs that still earn visits or backlinks. For a sizeable site, combine crawler data, XML sitemaps, CMS exports, Google Search Console landing pages, analytics, backlink data and server logs.
For each discovered URL, record what can be preserved or compared:
- HTTP status, indexability, robots directives and inclusion in the sitemap;
- title, meta description, H1, significant H2 headings and principal content;
- canonical, hreflang annotations and structured data;
- internal links pointing to and from the page;
- organic clicks, impressions, landing-page sessions and conversions where available;
- known external backlinks, especially links to deeper pages;
- media files, downloadable assets and functional dependencies.
This baseline is both a specification and an incident-response tool. Without it, a team may notice that traffic fell but be unable to tell whether valuable pages disappeared, metadata changed, links broke or rendering failed.
Create a complete old-to-new URL map
The central deliverable of URL migration SEO is a mapping in which every important old address has an intentional outcome. The following abbreviated example shows the fields a working document should contain:
| Old URL | New URL | Old status | New status | Redirect | Canonical | Traffic | Backlinks | Verified |
|---|---|---|---|---|---|---|---|---|
| /guides/seo | newdomain.com/resources/seo | 200 | 200 | 301 | New URL | High | Yes | Pending |
| /expired-campaign | No replacement | 200 | 410 | None | Not applicable | None | No | Pending |
Use direct permanent redirects
Each old page should redirect to the most relevant new equivalent, not merely to the homepage. For example: example.com/old-page → 301 → newdomain.com/new-page. Avoid chains such as old URL → intermediate URL → final URL, and make internal links point straight to the final destination.
For a permanent move, use a server-side 301 or 308 redirect. Both communicate permanence; 308 also preserves the request method. Temporary 302 or 307 redirects belong to genuinely temporary situations and should not be the default for a permanent site move. Canonical tags are not a substitute for redirects because users and crawlers can still request the old URL.
Handle pages without equivalents honestly
If a broader new page genuinely replaces several old pages, consolidation may be appropriate. If no relevant replacement exists, return a real 404 or 410. Redirecting hundreds of unrelated pages to the homepage creates a poor user journey and obscures what was actually removed.
Preserve the value of pages that already perform
Unless content optimisation is an explicit, separately tested part of the project, retain the existing search intent, principal copy, title, H1, useful subheadings, internal links, media, alt text, structured data and important conversion functions. A strong landing page should not lose most of its useful content solely because a cleaner design has less room for it.
CMS migration SEO also requires output parity, not just visual similarity. A WordPress to Next.js migration, for example, should confirm that essential content and metadata are present in rendered HTML, pages return accurate server status codes, navigation remains crawlable and JavaScript failures do not leave an empty template. Product filters, pagination, localisation and client-side routing need explicit test cases.
Align canonical, crawling and discovery signals
Canonicals and XML sitemaps
Every new indexable page should normally have a self-referencing canonical using its final production URL. Check for canonicals accidentally pointing to staging, the old domain, HTTP addresses or redirected URLs.
The post-launch XML sitemap should contain only canonical URLs that return 200, use the new domain and structure, and include correct hreflang references where applicable. Remove redirected and missing URLs, then submit the new sitemap in Google Search Console. The old sitemap can remain temporarily accessible during a domain move to help discovery, but it must not become the new site's canonical inventory.
Robots, hreflang and structured data
One of the most damaging release errors is carrying staging restrictions into production. Before launch, inspect robots.txt, meta robots directives, X-Robots-Tag headers and actual Googlebot accessibility. Removing a robots.txt block does not remove a noindex header, so test each layer independently.
Multilingual sites must update every hreflang URL and preserve reciprocal language references, including structures such as /en/ and /ua/. Validate structured data such as Organization, BreadcrumbList, Article, Product and Service, removing old-domain or staging URLs. FAQ markup should only be used when matching FAQ content is visibly present and complies with current search-engine requirements.
Sequence the launch by migration type
Hosting migration with unchanged URLs
Back up files and databases, build the site on the new server, and test it before changing DNS. Check runtime and database versions, dependencies, environment variables, file permissions, SSL, cron jobs, transactional email, redirects, cache rules and CDN behaviour. Keep the old environment available for rollback until the new one is stable.
After DNS changes, verify that all regions and protocols reach the intended server and watch logs for elevated errors or timeouts. Because the public URLs did not change, this scenario does not require page-by-page migration redirects or Search Console's Change of Address tool.
Domain, CMS and full-site moves
Verify ownership of both old and new Search Console properties before a domain launch. Deploy the mapped redirects on the old host, update canonicals and internal links, and submit the new sitemap. For a qualifying domain or subdomain move, use Search Console's Change of Address after redirects are operational. It is not a universal migration button and is not used for an unchanged-domain hosting move, a path-only restructure or a routine HTTP-to-HTTPS change.
Keep permanent redirects active for as long as practical; Google advises retaining them for at least a year. For the most valuable backlinks, ask publishers to update their links directly when feasible, while keeping the redirect for old references you cannot control.
Run the SEO migration checklist before release
- Crawl the staging site and compare its indexable URL set with the approved map.
- Test representative templates, high-traffic pages and backlink destinations manually.
- Confirm one-hop redirects, final 200 responses and intentional 404 or 410 outcomes.
- Check titles, headings, canonicals, hreflang, structured data and rendered content.
- Scan navigation, breadcrumbs, footer, product cards, related content and CTAs for old internal URLs.
- Test mobile rendering, forms, checkout, search, authentication and analytics events.
- Prepare backups, rollback ownership, launch responsibilities and an issue-priority process.
A migration budget should distinguish one-time technical protection from ongoing acquisition work. If the wider planning question is how much does website promotion cost, account separately for development remediation, SEO validation, content changes and post-launch growth.
Monitor by page group, not only site-wide averages
Immediately after launch, crawl both old and new URL sets and retest redirects from outside the development environment. Monitor Search Console indexing reports, sitemap processing, crawl activity, organic landing pages, analytics conversions and server errors. Inspect important URLs with Search Console rather than requesting indexing for every page indiscriminately.
Compare sections and templates separately: products, categories, articles, locations and language versions can behave differently. A site-wide average may conceal a failed template. Investigate persistent losses for blocked crawling, wrong canonicals, redirect gaps, missing content, rendering defects, soft 404s, broken internal links or server instability.
Short-term movement does not automatically mean failure, but it should never be used to dismiss a clear technical problem. A controlled migration provides enough baseline data, ownership and monitoring to distinguish normal reprocessing from defects that require immediate correction.
