How to Migrate a Website Without Losing SEO
Step by step guide for owners, SEOs and webmasters to plan site migrations, map redirects, preserve content and track post launch SEO to avoid ranking loss.

This guide explains how to migrate a website without losing SEO, aimed at owners, SEOs and webmasters preparing a CMS change, redesign or domain move; updated September 27, 2026. It is informational and not a paid implementation service.
Before the migration: planning and backups
Export a full list of existing URLs and key metadata before any change. Use a crawler or existing coverage data to capture URL, HTTP status, title tag, H1, meta robots, canonical and any known backlink targets. The documentation we reviewed lists Screaming Frog and Search Console as sources for extraction and verification.
Prioritise pages by traffic and backlinks. Obtain lists from Search Console, analytics and backlink tools. Mark pages that carry organic value and those that can be deprecated or consolidated. This prioritisation directs the redirection 1:1 mapping and testing effort.
Make complete backups: database, file storage, configuration and DNS zone. Preserve certificates and hosting configurations. Reduce DNS TTL before the cutover when a host or domain change is planned, so propagation is faster at the moment of switch.
Create a pre-migration checklist that includes: backup completion, master URL list, 1:1 redirect plan, DNS TTL lowered, and staging environment ready for full verification. The documentation we reviewed emphasizes testing 301 redirects on staging and keeping a copy of the old sitemap for transition.
URL strategy and mapping of redirects
Prefer to preserve existing URLs when possible. If structure must change, produce a 1:1 mapping file. The documentation we reviewed prescribes using server-side permanent redirects (301 or 308) rather than JavaScript or meta-refresh redirects.
Format the mapping as CSV with columns such as old URL → new URL → status → notes. Include explicit notes for parameterized pages, paginated sequences, tag/filter pages, media files and PDFs. Identify pages that must not be redirected to the homepage; each deprecated page should redirect to the closest topical equivalent.
Avoid redirect chains and loops. Test the mapping in staging: upload the mapping, run a full crawl, and verify that every inbound URL resolves to the final target with a single permanent redirect. The documentation we reviewed points to using crawler features in Screaming Frog to audit redirect chains and confirm correctness.
Technique: what to check in staging and at go-live
On staging, confirm there are no unintended noindex tags, no meta robots blocking critical pages, and that canonical links point to the intended canonical URL. Verify robots.txt does not block resources needed for rendering and indexing.
Validate HTTPS, certificates and HSTS headers where applicable. Ensure mixed-content issues are resolved so pages render fully on mobile and desktop. The documentation we reviewed requires checking HTTP headers and that critical resources are reachable.
Confirm structured data (schema.org) and hreflang implementation if the site is multi-language. Run performance spot checks (LCP/INP/CLS) and basic Lighthouse audits to detect regressions introduced by the redesign. Use automated crawls and spot checks at cutover to detect surprises immediately.
Content and SEO on-page: preserve ranking signals
Keep title tags, H1 and main content where they drive ranking, or document intentional changes to content and search intent. If content is rewritten or merged, record the rationale and the equivalent target URL for redirection mapping.
Recreate internal linking within the new site so anchor text and contextual links continue to support topical clusters. Ensure that redirects preserve the equity of pages that have backlinks and traffic. The documentation we reviewed explicitly warns against deleting high-performing pages without redirection.
Verify rich snippets and social metadata (Open Graph, Twitter cards) to protect click-through behaviour. If review or rich result markup existed, ensure it remains or is migrated to equivalent structured data on the new URLs.
Backlinks, external referencing and follow-up
Identify the highest-value backlinks via backlink tools named in the documentation we reviewed (Ahrefs, Moz). For those targets, confirm the redirect points to a relevant page on the new site so link equity is preserved.
Consider outreach to webmasters of top referring domains to request direct link updates for strategic pages. Prioritise top domains and links that bring meaningful referral traffic or authority. Maintain access to the old sitemap and keep permanent redirects in place for an extended period after cutover.
Search Console, analytics and monitoring post-launch
Immediately after go-live, submit the new sitemaps and monitor Search Console coverage and errors. If a domain change occurred, use the Change of Address tool in Search Console as described in the Google documentation referenced in the documentation we reviewed.
Monitor impressions, clicks, index coverage errors and crawl anomalies daily in the first phase. Use server logs to detect spikes of 5xx errors or unusual crawl behaviour. The documentation we reviewed recommends monitoring Search Console, analytics and server logs.
Keep the old sitemap available during transition and watch for increases in 404s or unexpected non-indexed pages. If critical pages are missing from index or show unexpected status codes, investigate redirects, canonicalisation and robots rules as first steps.
Special cases and common pitfalls
When changing CMS, watch slugs and permalink structure: automated slug generation can alter URLs unintentionally. For HTTPS migrations, enforce HTTPS via redirects and check for mixed content. When changing domain, keep old URLs permanently redirected rather than returning 404s or redirecting broadly to the homepage.
Beware of redirect chains, redirects to the home page, parameter pages left unhandled, and accidentally setting paginated or filter pages to noindex. Performance regressions and mobile rendering issues after a redesign are frequent causes of ranking drops; include performance checks in staging and post-launch monitoring.
Checklist pre-launch (actionable)
Checklist post-launch (daily / weekly)
0–3 days: run a full crawl, inspect top landing pages, scan for 5xx errors, confirm indexation of core pages. 4–14 days: monitor impressions and clicks trends, fix any missing redirects, review canonical and robots settings. 15–90 days: track recovery of referral traffic, continue outreach to update external links, and fine-tune on-page elements based on rankings and behaviour data.
Recommended tools and documentation
How long before effects appear in search?
This guide avoids arbitrary time estimates. Monitor Search Console and server logs to see how indexing and impressions evolve post-launch; consult the monitoring checklist above for expected observation windows.
Can the old site be deleted after a while?
The conservative approach is to keep permanent redirects in place as long as possible. Removing the old site while redirects remain active on the server can still preserve signals, but ensure redirects are validated first.
What to do if traffic drops?
Diagnose common causes: missing redirects, pages accidentally set to noindex, redirect chains, canonical errors, or server errors. Use crawls and Search Console to locate the issue and prioritise fixes for high-value pages.
When to ask for expert help?
Ask for specialist support when redirects are complex at scale, when critical server configuration or DNS changes are required, or when legal/contractual constraints on hosting and DNS exist. This guide is informational and not a substitute for technical or legal work.
How this guide was established
This guide was assembled from documentation and checklists consulted on September 27, 2026, including Google Search Central, Screaming Frog tutorials, Ahrefs and Moz migration guides, and a public migration checklist PDF noted in the documentation we reviewed. The content aggregates those recommendations into a practical, checklistable reference and points readers to the original docs for implementation details.
What we do not know



Sources
- [1]Google — Site Moves and Migrations / Change of Address / Redirects — developers.google.com
- [2]Google — Redirects and Google Search (301/308) — developers.google.com
- [3]Screaming Frog — How to use the SEO Spider in a site migration (tutorial) — www.screamingfrog.co.uk
- [4]Screaming Frog — Audit redirects guide — www.screamingfrog.co.uk
- [5]Ahrefs — A Website Migration Takes More Than A Checklist To Be Successful — ahrefs.com
- [6]Moz — The Website Migration Guide: SEO Strategy, Process, & Checklist — dc8hdnsmzapvm.cloudfront.net
- [7]Upward Engine — Site Migration Checklist (PDF) — upwardengine.com
- [8]TPR Media — SEO Migration Pre-Launch Checklist — tpr.media
- [9]Community threads and practical reports — www.reddit.com
Related guides
Priya Nair
Priya covers hosting, performance, security and backups. She reads changelogs and pricing pages so readers don't have to, and flags what changed since the last update.
Updated on September 27, 2026