Winner: Best SEO Agency – Prestige Awards London & South East
SEO Guide · Migration Playbook

How to Migrate a Website Without Losing SEO

A practical, evidence-backed playbook. A successful SEO website migration protects search visibility by combining careful measurement, conservative change management, and systematic testing.

The playbook used by technical SEO teams is simple in concept and exacting in execution:

  • Back up everything and audit/benchmark the current site.
  • Create a full URL inventory and mapping.
  • Preserve content, metadata and structured data.
  • Implement comprehensive 301 redirects.
  • Update internal links to point to final URLs.
  • Validate technical signals (sitemaps, robots.txt, HTTPS, speed, mobile, hreflang).
  • Fully test on staging while blocking indexing.
  • Monitor closely after launch with a clear rollback plan.

Expect short-term movement in rankings. With a disciplined approach, most issues are avoidable, and the rest are recoverable within weeks to months.

This guide gives a step-by-step SEO migration plan, the technical checklist you must run through, the common mistakes that break SEO, and clear guidance on when to bring in migration specialists.

Before anything else: back up and set your rollback triggers

Why this matters: migrations introduce risk from the first change you make. A backup taken only "before final cutover" doesn't protect you from mistakes made earlier in the process, so this is step one, not a pre-launch afterthought.

What to back up:

  • Full site files and assets.
  • Database dump(s).
  • Current XML sitemap(s).
  • Server configuration and existing redirect rules.
  • Any third-party integrations and their configuration.

Rollback planning

  • Define clear rollback triggers up front (e.g. critical traffic drop, site-wide 5xx errors, indexation blocked).
  • Test the rollback procedure on a staging clone so you can execute it quickly if needed.

Audit, benchmark and plan

Why this matters: you cannot protect what you haven't measured. Benchmarks tell you where to focus effort and how to quantify impact after launch.

Action steps

  • Crawl the entire site and export every indexable URL. Use a crawler such as Screaming Frog to capture URLs, status codes, titles, meta descriptions, H1s, canonical tags and structured data.
  • Capture a traffic and rankings baseline:
    • Export organic traffic per page from GA4 for the past 3-12 months. (Universal Analytics was sunset in mid-2023 and no longer collects data; it's only useful now as an archive of older historical figures, not as an active source.)
    • Export rankings for your target keywords from your rank tracker.
  • Identify high-value pages: sort by organic sessions, conversions and inbound links.
  • Backlink audit: use Ahrefs, SEMrush or similar to export referring domains and the pages receiving links. Flag high-authority backlinks that must be preserved.
  • Domain authority snapshot: note domain-level metrics and which pages carry most of that value.
  • Create a migration plan and timeline, and assign owners for redirects, content, QA, devops and monitoring.

Deliverables to produce before any change:

  • Full URL inventory spreadsheet (old URLs with metadata and performance metrics).
  • Prioritised list of high-risk / high-value pages.
  • Redirect mapping template (blank) ready to populate.

Inventory and URL mapping (old → new)

Why this matters: URL changes are one of the largest causes of migration-related ranking loss. A precise mapping prevents accidental orphaning and broken backlinks.

How to properly do it

  • Export every live URL into a spreadsheet with columns for: old URL, status (200/301/404), page title, meta description, traffic, conversions, backlinks and proposed new URL.
  • For each old URL, assign a single best-match new destination. If the exact page won't exist anymore, map to the closest topical match, never mass-redirect everything to the homepage.
  • Prioritise mapping for pages with traffic, conversions or high-value backlinks.
  • Add QA columns: expected redirect status (301), testing owner, and test result.
  • Note where canonical relationships will change and reflect that in the mapping.

Best practices

  • Preserve meaningful URL structure when possible; when you must change URLs, make sure the mapping is exhaustive.
  • Avoid redirect chains by pointing old URLs directly to their final destination.
  • For sites with thousands of URLs, break the work into batches and verify each batch with a crawler.

Preserve content parity, or improve deliberately

Why this matters: a migration can also be a legitimate opportunity to improve content and structure. The risk we most often find isn't in improving, it's in doing it unplanned and untested, at the same time as everything else.

Practical rules

  • As a baseline, keep the wording, structure and depth of migrated pages close to the original at launch. This makes it easy to isolate the impact of the migration itself from the impact of the content.
  • If you do want to improve content or restructure pages, that's a reasonable choice, but treat it as a deliberate, planned change. Test the new version on high-value pages first, or roll improvements out in a second phase once the migration has stabilised, so you can tell which change caused which result.
  • Where content genuinely must change (e.g. consolidating several old pages into one, or a real content upgrade), document it explicitly in the URL mapping so any ranking movement can be attributed correctly during monitoring.
  • Avoid bundling multiple unrelated changes into the same cutover: a domain move, a CMS change and a full content rewrite happening simultaneously make it very hard to diagnose what caused a ranking drop if one occurs.

301 redirects: planning, implementation and testing

Why this matters: 301 redirects are the standard mechanism for preserving link equity and preventing 404s. Improper redirects create chains, loops and lost authority, and can cost you traffic.

Implementation checklist

  • Implement a 301 for every old URL that will change or be removed.
  • Avoid these common pitfalls:
    • Redirecting all old URLs to the homepage (this wastes link equity).
    • Creating redirect chains (A → B → C): map and implement redirects directly to the final URL.
    • Leaving redirect loops or misconfigured server rules.
  • Where a page is permanently gone and no topical replacement exists, prefer a closely relevant alternative over the homepage. If there truly is no relevant alternative, return a 404 (Not Found) or a 410 (Gone). In practice, Google treats the two very similarly for ranking purposes: a 410 can signal removal a little more explicitly and may be processed slightly faster, but it isn't a meaningful lever on its own. Use whichever your CMS/server handles more reliably.

Testing the redirects

  • Test redirects at scale with Screaming Frog or a similar crawler: crawl the old URL set and confirm each returns a single 301 to the intended new URL, which itself returns 200.
  • Verify HTTP status codes, Content-Type, and that no redirects re-introduce canonical conflicts.
  • Check redirects on staging before launch, then re-test immediately after launch.

Preserve metadata, canonical tags and structured data

Why this matters: title tags, meta descriptions, H1s, canonicals and schema are on-page signals search engines use to understand relevance and to serve click-through in results. Losing or changing them unnecessarily erodes rankings.

Practical rules

  • Transfer title tags, meta descriptions, H1s and canonical tags to the new pages verbatim, unless you have a tested, SEO-positive improvement.
  • Migrate structured data (schema.org) exactly, or improve it deliberately, and validate it in the new environment.
  • If you plan to change metadata, do it selectively and after you've benchmarked performance post-launch. Avoid sweeping changes at the moment of cutover.

Testing

  • Crawl the staging site and compare metadata exports to the baseline crawl. Flag any unexpected changes.
  • Use a structured data testing tool to confirm schema parses correctly.

Internal links: update to point to new URLs

Why this matters: internal linking is a primary crawling path and distributes link equity across the site. Relying on redirects internally reduces crawl efficiency and risks unnecessary chains.

Action steps

  • Update internal links so they point directly to the new canonical URLs, not through a redirect.
  • After launch, crawl the site to detect any internal links still pointing to old URLs and fix them.
  • Pay particular attention to navigation, footer links, in-content links and XML sitemap links.

Technical checklist: staging, HTTPS, robots.txt, sitemaps, speed, mobile and rendering

Why this matters: technical regressions (blocked crawling, loss of HTTPS, poor mobile or speed performance, broken JavaScript rendering) can drop rankings almost immediately.

Before launch (on staging)

  • Block the staging environment from indexing:
    • Use a robots.txt disallow and/or a <meta name="robots" content="noindex"> tag on staging.
    • Keep staging inaccessible to search engines and password-protected where appropriate.
  • Verify HTTPS is enabled and certificates are valid on production.
  • Prepare a production robots.txt that allows crawling of the new site.
  • Generate XML sitemap(s) for the new site reflecting the final, canonical URLs.
  • If the site serves multiple languages or regions, verify hreflang tags are implemented correctly and reference the right URLs.
  • If the new site relies on client-side JavaScript rendering (a new CMS or framework often does), confirm that Googlebot can actually render and index the content, test with a rendering/inspection tool rather than assuming it works.
  • Run Core Web Vitals and page speed tests (lab and field) to confirm the new site meets or improves on current performance.
  • Verify mobile responsiveness and viewport settings.

At launch

  • Remove staging blocks and make the site live.
  • Upload the production robots.txt and sitemap.
  • Confirm the site serves HTTPS and redirects HTTP to HTTPS.

Testing & monitoring

  • Use a crawler to validate indexable pages and to find blocked, non-indexable or unexpected status codes.
  • Run Lighthouse / Core Web Vitals audits across key templates and compare against the baseline.

Google tools and analytics: configuration and monitoring

Why this matters: Search Console and analytics are how you detect errors, observe indexation and measure impact.

Essential steps

  • Verify or re-verify the production site in Google Search Console and set up the users who need access.
  • Add the new sitemap(s) to Search Console immediately after launch and submit priority pages for indexing.
  • Confirm GA4 is installed and recording correctly. Keep historical analytics access for comparison.
  • If relevant, update your Google Business Profile URLs.
  • Use Search Console to monitor for crawl errors, coverage issues, indexing anomalies and manual actions.

Monitoring cadence

  • Check Search Console and analytics daily for the first week, then at least weekly for the first three months.
  • Track rankings and organic sessions weekly for high-priority pages; expand to full-site checks as things stabilise.

Staging and pre-launch QA

Why this matters: testing on a correctly blocked staging environment prevents premature indexing and stops untested redirects or dead pages from reaching search results.

Pre-launch QA checklist

  • Confirm staging is not indexable and is password-protected where necessary.
  • Execute the full redirect test suite and confirm no chains or loops.
  • Crawl staging and compare it to the pre-migration crawl for parity on URLs, titles, meta descriptions, canonical tags, structured data and page content.
  • Validate internal links, navigation and breadcrumbs point to the intended final URLs.
  • Complete performance, mobile and rendering testing.

Prioritise high-value pages

Why this matters: resources are finite. Protecting the pages that drive revenue, traffic and backlinks reduces immediate business risk.

How to prioritise

  • Use the pre-migration audit to identify top-tier pages by sessions, conversions and referring domains.
  • Validate redirects, metadata and content for those pages first, and re-check them first at launch.
  • Set up daily monitoring for these specific URLs during the first week post-launch.

Consider a phased rollout on larger or higher-risk sites

Why this matters: a single "big bang" cutover concentrates all migration risk into one moment. On large sites, complex platforms, or anything commercially critical, migrating in phases (by section, template or subdomain) lets you validate real-world behaviour on a smaller slice before committing the whole site.

How to do it

  • Group URLs into logical batches (e.g. by content type or site section).
  • Migrate, monitor and stabilise one batch before starting the next.
  • Keep the redirect mapping and rollback plan batch-aware, so a problem in one phase doesn't force a rollback of already-stable sections.

This is a judgement call: for smaller sites, a well-tested single cutover is usually simpler and just as safe.

Launch day

  • Remove staging blocks and deploy the production site.
  • Upload robots.txt and submit the sitemap.
  • Re-run crawls to validate redirects, status codes and metadata against the plan.
  • Monitor Search Console and analytics closely from the first hour.

Post-launch monitoring and recovery expectations

Why this matters: early detection enables fast fixes. Expect short-term fluctuation, recovery speed depends on execution quality.

Immediate post-launch checks (day 0-7)

  • Submit the sitemap to Search Console and request indexing for priority pages.
  • Crawl the live site and compare status codes to the expected mapping.
  • Check coverage and indexation reports in Search Console for errors.
  • Monitor GA4 for large traffic drops or tracking breaks.
  • Where feasible, review server log files to see how Googlebot is actually crawling the new site, which URLs it's requesting, which status codes it's getting, and whether it's still hitting old paths. This is more reliable than inference from Search Console alone, especially on larger sites.

Ongoing monitoring (weeks 1-12)

  • Track organic traffic and rankings weekly for at least the first three months.
  • Monitor Search Console for spikes in 404s, blocked resources or indexing errors.
  • Re-audit backlinks: identify high-value referring pages still pointing to old URLs, and reach out to webmasters to get them updated.
  • Anticipate temporary ranking dips. Industry guidance suggests allowing at least 4-6 weeks for Google to process changes, and longer for full stability; complex migrations may take months.

When to take corrective action

  • If high-priority pages show prolonged traffic loss beyond a few weeks, review redirect implementation, indexation, canonical tags and content parity.
  • Fix critical server errors, remove accidental noindex rules, correct robots.txt mistakes and restore missing sitemaps quickly.

Common mistakes and how to avoid them

Mistake: No redirects, or a mass redirect to the homepage

Avoidance: Map and implement 301s for every changed URL; never redirect all old pages to the homepage.

Mistake: Breaking metadata, content or titles sitewide at launch

Avoidance: Migrate metadata and content unchanged, and improve selectively after baseline comparisons.

Mistake: Staging indexed or left unblocked

Avoidance: Use robots.txt/noindex and password protection for staging.

Mistake: Redirect chains and internal links left pointing to old URLs

Avoidance: Point internal links to final URLs and test for chains before launch.

Mistake: Forgetting Search Console, sitemap, hreflang or HTTPS

Avoidance: Prepare these assets pre-launch and verify them immediately after going live.

Mistake: Inadequate backups or no rollback plan

Avoidance: Take full backups and agree rollback triggers and procedures with stakeholders before work starts, not during an incident.

Mistake: Treating a big, complex migration as a single all-or-nothing cutover

Avoidance: Consider a phased rollout for large or high-risk sites.

Tools and methods (recommended)

  • Site crawling: Screaming Frog to export full URL lists, status codes, metadata, and to test redirects at scale.
  • Backlink audits: Ahrefs, SEMrush or similar to identify referring domains and top-linked pages.
  • Analytics and indexing: Google Search Console and GA4 for monitoring indexing, coverage and traffic.
  • Performance testing: Lighthouse, PageSpeed Insights and field CWV tools for Core Web Vitals.
  • Rank tracking: your existing rank tracker to monitor keyword movement.
  • Server logs: a log analyser to see actual crawler behaviour post-launch.
  • Communication and tracking: shared spreadsheets for the redirect mapping, a ticketing system for QA, and a single source of truth for owners and deadlines.

Domain changes: a separate, higher-risk scenario

Why this matters: changing domains moves the entire brand and historical trust signal at once, on top of everything else a migration already involves. It's not simply another step in the standard flow; instead, treat it as its own project with its own timeline.

If you must change domains

  • Extend timelines and resource allocation beyond what a same-domain migration would need.
  • Implement 1:1 301 redirects from the old domain to the new domain for every URL.
  • Keep both domains verified in Google Search Console, and use the Change of Address tool as part of the process.
  • Preserve backlinks where possible by asking webmasters to update links to the new domain, target the most valuable referring domains first.
  • Monitor Search Console and traffic closely, and expect a longer recovery timeline than a same-domain migration.

When to avoid a domain change

  • If the only goal is cosmetic or URL cleanliness, weigh the SEO and business risk carefully. Where possible, keep the same domain.

When to hire migration or SEO specialists

Consider external help if:

  • The site is large (thousands of pages) or has complex URL structures and many redirects.
  • You're changing domains, changing CMS/platform, or moving an ecommerce catalogue.
  • High-value pages and revenue depend heavily on organic traffic.
  • In-house technical bandwidth for exhaustive testing and monitoring is limited.

What specialists typically do

  • Create and validate full URL mappings and server-level redirects.
  • Run detailed crawl comparisons and root-cause investigation for issues.
  • Handle advanced Search Console configuration, canonical strategy and backlink remediation outreach.
  • Provide post-launch monitoring and rapid remediation.

Hiring is a risk-management decision: the cost of expert help is often lower than the business impact of lost traffic and revenue.

At MJ Web Studio we offer a full SEO Migration Service.

Final migration checklist (summary)

A condensed, printable version of everything above.

Before you start

Take full backups and agree rollback triggers with stakeholders.

Crawl and export all URLs; benchmark traffic, rankings and backlinks.

Create the full URL mapping spreadsheet and prioritise high-value pages.

Build and test on staging

Preserve content parity, metadata, canonicals and structured data.

Implement and test 301 redirects.

Update internal links to point to final URLs.

Block staging from indexing; test performance, mobile and rendering.

Prepare robots.txt, hreflang and XML sitemaps.

Verify GA4 and Search Console setup.

Decide whether a phased rollout makes sense for your site.

Launch day

Remove staging blocks and deploy production.

Upload robots.txt and submit the sitemap.

Re-run crawls to validate redirects, status codes and metadata.

Monitor Search Console and analytics closely.

Post-launch (first 3 months)

Check GSC and analytics daily for the first week, then weekly.

Review server logs for real crawler behaviour.

Fix crawl, indexation and redirect issues immediately.

Reach out to webmasters for backlink updates on high-value links.

Be patient, expect stabilisation over weeks to months.

In conclusion

Site migrations don't need to be traumatic events. The difference between a safe migration and a damaging one is planning and discipline: back up first, audit and benchmark, map and protect every URL, preserve content and metadata, implement clean 301 redirects, update internal links, block and test on staging, and monitor intensively after launch.

When complexity or risk increases, such as large sites, domain moves, or major CMS changes, bring in migration or SEO specialists to manage the work.

With the right checklist, the right order of operations, and disciplined execution, you can migrate with minimal SEO loss and confidence that any temporary disruption will resolve.

Frequently Asked Questions

How much does professional SEO migration cost?

SEO migration costs £3,000-£15,000 depending on site size, complexity, and migration type. Small sites (under 500 pages) typically cost £3k-£5k. E-commerce sites cost £5k-£10k. Enterprise migrations cost £10k-£15k+. Consider this: the average failed migration loses 30-50% traffic permanently. Recovering that traffic costs £20k-£50k plus 6-12 months of lost revenue. Prevention is dramatically cheaper than recovery.

How long does a properly planned SEO migration take?

Proper SEO migration takes 6-12 weeks depending on site complexity. Planning and mapping take 2-4 weeks. Implementation and testing take 2-4 weeks. Launch and monitoring take 2-4 weeks. This timeline protects your rankings. Rushed migrations (2-4 weeks total) cause mistakes that destroy traffic. The extra time invested upfront prevents 6-12 months of recovery work later.

Can I handle SEO migration myself or do I need an expert?

Simple migrations (HTTPS upgrades, minor redesigns) can be handled internally with careful planning. Complex migrations (platform changes, domain moves, major restructuring) require professional expertise. One redirect mistake, one technical error, one overlooked element can cause permanent ranking loss. Professionals have done hundreds of migrations and know every failure point. The investment in expertise prevents catastrophic mistakes.

Will my rankings drop during migration?

Properly executed migrations maintain rankings with 0-5% fluctuation. Rankings may fluctuate temporarily (1-4 weeks) as Google re-crawls and re-evaluates the site, but should stabilize at or above pre-migration levels. Poorly executed migrations lose 20-60% of traffic permanently. The difference is comprehensive planning, perfect execution, and continuous monitoring that catches issues before they compound.

What happens if something goes wrong during migration?

Professional migrations include rollback plans and immediate response protocols. If issues appear post-launch, we identify problems within hours, implement fixes immediately, and monitor continuously until resolved. Most issues caught quickly (first 48 hours) can be corrected with minimal impact. Issues that linger for weeks cause permanent damage. This is why continuous monitoring and expert oversight are non-negotiable during migration.

How do you handle migrations for large e-commerce sites?

E-commerce migrations are highest-risk because of product page volume, category structures, and revenue dependence. We map every product URL, preserve category hierarchies, implement faceted navigation SEO, maintain product schema, test checkout processes, and verify all technical elements. Staged rollout (testing with small product subset first) minimizes risk. Continuous monitoring catches issues before they affect revenue.

Do you provide ongoing support after migration?

Yes, post-migration support is included for 30-90 days depending on migration complexity. We monitor rankings, traffic, indexation, and technical health continuously. If issues emerge (ranking drops, crawl errors, indexation problems), we investigate immediately and implement corrections. Most migrations stabilize within 4-8 weeks, but we continue monitoring until performance confirms complete success.

What's the biggest mistake businesses make during migrations?

Rushing the process. Most failed migrations happen because businesses set arbitrary deadlines (site launch dates, seasonal events) that force rushed execution. Proper migration takes time—comprehensive planning, thorough testing, and careful monitoring can't be compressed without consequences. The second biggest mistake is treating SEO migration as checklist rather than strategic process requiring expertise. Both mistakes cause permanent traffic loss.

Planning a Website Change and Want to Protect Your Rankings?

Real Results, Real Clients
No Long-Term Contracts
Transparent Reporting