Michele Eccher
On this page
A safe SEO migration preserves the meaning and discoverability of valuable pages while the website changes underneath them. Before launch, record the baseline, inventory old URLs, map each one to a relevant new state and test the new site. At launch, release direct permanent redirects and consistent canonical, internal-link and sitemap signals. Afterwards, monitor crawling, indexing, visibility and conversion until the new system is stable—and keep the redirects in place for at least a year.
A migration is any website change that can alter how search systems find, fetch, understand or select pages. Moving to a new domain is the obvious example, but a CMS rebuild, URL restructure, international rollout, HTTP-to-HTTPS move, redesign or switch from server-rendered HTML to a JavaScript application can create the same search risk. Even when URLs stay unchanged, removing navigation, changing rendered content or rewriting templates can change what Google receives.
The objective is not to freeze the old site. It is to make every change intentional and observable. A successful launch can still produce temporary fluctuations while search engines recrawl and reassess the new URLs. A controlled process lets the team tell that expected transition apart from a broken redirect, missing content or blocked template.
Baseline, inventory, URL map and test plan
Redirects, signals, crawl checks and release decision
Monitor, diagnose, correct and keep redirects live
Decide what is changing—and what should remain stable
Begin with a written change boundary. List the systems, templates, URLs, content, navigation and markets affected by the release. Then identify the elements that do not need to change. Retaining strong page intent, copy, headings and internal relationships while the platform changes reduces the number of variables the team must diagnose afterwards.
Domain or subdomain move
Every URL changes host. Verify ownership of old and new Search Console properties, preserve paths where sensible and plan for certificate, DNS and server capacity as well as redirects.
Platform or CMS migration
The visible URL may stay the same while rendering, metadata, structured data, pagination and status-code behaviour change. Compare output, not feature names in the new CMS.
Architecture or URL restructure
Categories, folders and page relationships change. Test whether the new hierarchy still matches audience intent and whether important destinations remain reachable through crawlable links.
Redesign or front-end rebuild
Templates, components and navigation change, sometimes without an explicit SEO workstream. Check content parity, mobile behaviour, initial HTML, rendered output and all routes that depend on client-side code.
If the team is still deciding between a visual redesign, a structural rebuild or a limited repair, use the website redesign versus rebuild guide before freezing the migration scope. Once the route is chosen, a technical SEO audit provides the baseline for checking templates, rendering and indexation.
Build a baseline that can answer what changed
A pre-launch baseline is not a presentation of historic traffic. It is the evidence needed to investigate the release. Record data at URL and template level so that a falling total can be traced to a section, market, query group or technical state. Take the baseline close enough to launch to reflect the current site, but retain longer periods for seasonality and trend context.
| Baseline | What to capture | Why it matters after launch |
|---|---|---|
| Organic performance | Clicks, impressions, queries, landing pages, countries and devices | Shows where demand or visibility changed instead of hiding it in one total. |
| Commercial behaviour | Leads, revenue, form events, assisted journeys and high-value pages | Separates a search transition from a broken conversion or measurement path. |
| Index and crawl state | Indexed samples, sitemap coverage, crawl statistics and server responses | Provides a reference for how quickly old and new URL sets are processed. |
| Site inventory | All discoverable URLs, canonicals, status codes, metadata and internal links | Reveals lost pages, changed directives and unexpected URL generation. |
| External references | Important linked URLs, campaign destinations, bookmarks and integrations | Prioritises durable redirects and updates outside the website itself. |
Combine exports rather than trusting one crawler. Analytics can reveal pages that receive visits but are no longer internally linked. Search Console can surface landing pages absent from the current sitemap. Server logs may show old routes still requested by search engines or customers. Backlink data, paid campaigns, email templates and offline documents add URLs that a site crawl cannot discover.
Before the production release, crawl the old site one final time and preserve the result. Save representative HTML, screenshots and structured-data output for the most important templates. The purpose is not archival completeness. It is to have a known working example when the new page behaves differently.
Give every valuable old URL one intentional new state
The redirect map is a decision register, not a search-and-replace formula. For each old URL, define whether the closest equivalent remains available at a new address, has been consolidated into a broader page or has genuinely been removed. Preserve the original intent. A product page should not land on the home page simply because both belong to the same company.
Redirect directly to the closest new version. Confirm that the destination contains the expected content and returns 200 without another hop.
Redirect only when the new destination genuinely answers the old need. Record why several pages now belong together and which demand the combined page must retain.
Return 404 or 410 and remove internal links. A clear absence is better than a misleading redirect to an unrelated page that may be interpreted as a soft 404.
Still validate its status, canonical, indexability, content and links. A familiar address can serve a fundamentally different or incomplete page after a rebuild.
Implement permanent redirects on the server where possible. Google recommends 301 or 308 for permanent moves and advises against long chains. A request should travel from the old URL to the final relevant destination in one step, including legacy redirects that existed before the project. Test encoded characters, uppercase variants, trailing slashes, parameters and protocol or host variants rather than assuming one rule covers every request.
Google's redirect guidance states that permanent server-side redirects are the best way to change the URL shown in search results. It also notes that Google can follow multiple hops, but direct redirects reduce latency, failure points and operational confusion.
Test the new system as search engines and users will receive it
Keep staging unavailable to public indexing, but do not let the protection hide launch defects. Access controls, temporary noindex tags and blocked robots rules must have a named owner and a launch-removal check. A single inherited directive can make an otherwise perfect migration invisible.
Crawl representative templates
Test priority examples and edge cases across services, products, categories, articles, pagination, filters, local pages and language versions. Compare them with the old production output.
Validate search signals
Check status codes, self-canonicals, robots directives, titles, headings, structured data, hreflang and XML sitemap eligibility. Signals should agree on the preferred new URL.
Test rendering and navigation
Compare initial HTML with the rendered DOM. Confirm that important content and crawlable links survive JavaScript, responsive states, consent tools and failed API requests.
Verify conversion and measurement
Submit forms, complete purchases and inspect analytics across devices. A migration can preserve rankings while losing revenue because a form, event or checkout path stopped working.
Run the complete redirect map against a production-like environment. Check destination relevance as well as status code. Then crawl the destinations to confirm they are indexable, self-canonical and internally linked. A technically valid 301 is not a successful migration when it leads to a noindex page, another redirect or a thin replacement.
Release in a sequence the team can observe and reverse
Choose a period when engineering, SEO, analytics and business owners can watch the release. Avoid a handover at the end of the day or immediately before a peak trading period. Record the exact deployment time so that logs, monitoring and performance data can be aligned with the change.
Make the new production site available
Confirm DNS, TLS, host variants, server capacity and public access. Remove staging protections only from the intended production environment.
Activate and test permanent redirects
Test priority URLs, patterns and known legacy rules from outside the deployment environment. Look for loops, chains, 5xx responses and irrelevant destinations.
Crawl the new site immediately
Check robots controls, canonical URLs, indexability, internal links, rendered content and status codes. Compare the result with the approved staging crawl.
Publish and submit the new sitemap
Include only canonical 200-status new URLs. Update sitemap references in robots.txt and submit the file in the relevant Search Console properties.
Verify journeys and measurement
Test high-value forms, transactions, consent, analytics and advertising tags on production. Confirm that reports identify the new landing URLs correctly.
Log findings and make the release decision
Classify defects by impact and scope. Fix safe issues quickly, but use the agreed gate when a widespread blocker makes rollback safer than live repair.
Use the right signals for the type of move
Verify all relevant old and new properties before the migration. For a domain or subdomain move, that includes ownership of both sides and any protocol or host variants needed for diagnosis. Keep access to the old property after launch: it shows lingering requests, indexed URLs and errors that the new property cannot explain by itself.
Use the Change of Address tool only for a move between domains or subdomains and only after permanent redirects are working. Google's Change of Address documentation excludes HTTP-to-HTTPS, www-to-non-www and path-only changes. Those transitions are handled through redirects, canonicals, sitemaps and recrawling rather than the tool.
Each new page should declare itself as canonical unless a deliberate consolidation says otherwise. Update internal links, hreflang and sitemap URLs to point directly to the new canonical versions. The purpose is to present one coherent destination, not to ask Google to reconcile old links, redirected canonicals and mixed language alternates.
Google's current site move guidance recommends testing the new site, preparing URL mappings, starting the move and then monitoring traffic. It also advises keeping redirects for at least a year and warns that larger sites can take longer to process because the move is handled URL by URL.
Monitor the transition as a set of hypotheses, not one traffic line
Establish an intensive first-day and first-week cadence, then reduce the frequency as the system stabilises. Do not wait for a monthly report. A broken template discovered in hours may be repaired before it affects a large part of the site; the same issue found weeks later can require a much longer recovery.
| Signal | Expected transition | Investigate immediately |
|---|---|---|
| Old URLs | Requests continue but resolve directly to relevant new pages. | 200 responses, loops, chains, 5xx errors or irrelevant destinations. |
| New URLs | Crawling and indexation rise progressively across priority templates. | Blocked crawling, noindex, wrong canonicals, soft 404s or empty rendering. |
| Search performance | Some volatility while queries and URLs transfer. | Loss isolated to a template, language, directory or high-value query set. |
| Commercial performance | Normal variation with valid measurement and working journeys. | Form, checkout, tracking or consent failure despite stable search demand. |
| Server behaviour | Temporary increase in crawling of old and new hosts. | Latency, capacity errors or bot protection blocking legitimate crawling. |
Segment results by migration cohort. Compare changed URLs with unchanged controls where possible, and separate brand from non-brand, mobile from desktop, country from country and template from template. If one section falls while the rest transfers correctly, inspect its specific redirects, content parity, internal links and technical output before blaming the whole migration or a search update.
Maintain a live issue log with evidence, scope, owner, decision and verification status. Re-crawl repaired patterns and inspect representative URLs in Search Console. Keep the old domain, certificates, redirect infrastructure and monitoring active. A migration is not complete merely because the new home page is indexed.
Most migration losses come from a small number of avoidable decisions
Redirecting everything to the home page
This abandons the original intent and can be interpreted as soft-404 behaviour. Match the closest equivalent or return an honest 404 or 410 when none exists.
Launching with staging controls
Password protection, noindex tags or blocking rules survive into production. Make their removal an explicit release check, not an assumption.
Creating redirect chains
New rules point to old intermediate locations. Resolve historical chains so every known legacy URL reaches the final destination directly.
Preserving URLs but losing content
The page still returns 200, yet important copy, links, media or structured data has disappeared. Compare rendered output and intent, not address alone.
Mixing old and new signals
Canonicals, hreflang, internal links and sitemaps point to different URL versions. Update all controllable signals to the final canonical destination.
Removing redirects after the first report
Old URLs may still have links, bookmarks and search history. Keep redirects for at least a year and ideally as long as the previous addresses continue to receive use.
The migration is stable when valuable old URLs resolve correctly, the new canonical set is discoverable and indexed, important query and commercial patterns have transferred, no systemic blocker remains and the monitoring cadence can return to normal operations. Document the final redirect map and accepted exceptions so future releases do not undo the work.
Good migration practice is disciplined change management. It preserves what users and search systems already understand, gives engineering a testable target and makes losses diagnosable before they become normalised. The checklist matters because the release is temporary; the URL decisions can remain in use for years.
SEO migration FAQs
What is an SEO migration?
An SEO migration is a controlled change to URLs, domain, protocol, platform, architecture, templates or rendered content that can affect how search engines discover, interpret and index a website. The SEO work protects valuable signals by defining the intended destination for every important URL, testing the new system and monitoring the transition after launch.
How long does an SEO migration take?
Preparation may take a few weeks for a small site and several months for a complex international or ecommerce platform. After launch, search engines process the move URL by URL, so visibility can fluctuate for weeks or longer. The practical timeline depends on the number of URLs, scale of the change, crawl demand, server reliability and how accurately redirects and internal signals are implemented.
Do 301 redirects cause a loss of ranking signals?
Google states that permanent redirects such as 301 and 308 do not cause a loss of PageRank. That does not make every redirect safe: the destination still needs to be relevant, accessible and supported by consistent canonicals, internal links and sitemap entries. Redirecting unrelated pages to a generic destination can be treated as a soft 404.
How long should migration redirects remain in place?
Google recommends keeping redirects for at least one year. Retaining them longer is usually better when people, links, bookmarks or old documents can still send requests to the previous URLs. Treat the redirect map as durable infrastructure, not a temporary launch-day file that can be removed after traffic appears stable.
When should the Change of Address tool be used?
Use Search Console's Change of Address tool for a site move from one domain or subdomain to another after the permanent redirects are live. Do not use it for an HTTP-to-HTTPS migration, a move between www and non-www, or a path-only change within the same domain. Those moves are communicated through redirects, canonicals, sitemaps and normal recrawling.
Should the old XML sitemap stay available after launch?
Keeping an old-URL sitemap available temporarily can help the migration team observe whether Google is still requesting and processing previous addresses, while the new sitemap should contain only canonical new URLs. Both files must be interpreted as monitoring aids rather than substitutes for direct permanent redirects.
What should happen to pages that have no replacement?
A removed page with no close equivalent should normally return 404 or 410. Do not send every deleted URL to the home page or an unrelated category merely to avoid an error status. Where a genuinely equivalent consolidated page exists, redirect to it and preserve the user's original intent.
Can the domain, CMS and design all change in one migration?
They can, but combining many changes makes faults harder to isolate and increases the number of assumptions that must work at once. Google recommends changing one major dimension at a time where possible. If commercial constraints require a combined release, establish a strong baseline, minimise unnecessary URL and content changes, test representative templates and define a rollback decision before launch.
