brnrd.me

Everything Digital

How to plan an SEO-safe website migration (step-by-step)

Most migration-related traffic drops are not caused by the migration itself. They are caused by preparation failures that could have been caught weeks before go-live. The number one reason migrations fail is not technical: it’s organisational. SEO is not part of the conversation during planning, and by the time someone asks about redirects, it’s too late to do it properly.

Key Takeaways

  • SEO involvement must begin before any development work starts – not two days before launch

  • Benchmarking current performance is the baseline against which everything is measured post-migration

  • The redirect map is the most important single deliverable – every high-value URL needs a direct 301, never a homepage redirect

  • Never launch on a Friday or during a peak traffic period

  • Post-launch monitoring should run for at least 30 days

  • AI search visibility must be benchmarked before migration and tracked after – it is not covered by traditional monitoring

Before the stages: define what is actually changing

The SEO risk of a migration scales with how many things change simultaneously. A hosting swap with identical URLs is low risk. A simultaneous domain change, CMS switch, and URL restructure is one of the highest-risk events in organic search. Before planning begins, document: domain, URL structure, CMS, planned content changes, international structure, and HTTPS status. Each variable adds risk; combinations multiply it.

Stage 1: Build the plan before you touch anything

Before anyone touches code or design files, establish scope, assign roles, and build the roadmap that guides the rest of the project.

Define migration type and scope

  • Will the domain name change?

  • Will the URL structure change?

  • Is the CMS changing?

  • Are content changes planned alongside the migration?

  • Who handles implementation – internal team or external partner?

  • What is the target go-live date, and is it realistic?

Benchmark current performance

You cannot measure migration success without knowing where you started. Export and save:

  • Organic traffic from Google Analytics and Search Console

  • Keyword rankings for priority terms

  • Backlink profile – total referring domains and highest-linked pages

  • Page-level performance – traffic, conversions, revenue by URL

  • Core Web Vitals scores

  • Current indexed page count

Identify priority pages

Pull the pages with highest organic traffic, conversions, referring domains, and keyword rankings. These pages get extra scrutiny at every subsequent stage. Redirect mapping, content review, pre-launch testing, and post-launch monitoring.

Secure access

  • Google Analytics and Google Search Console

  • Google Tag Manager

  • Staging and development environment

  • CMS for both old and new sites

Build a migration roadmap

Create a timeline with milestones for each stage, named owners, and review cycles. Migrations consistently take longer than estimated – pad the timeline accordingly and build in contingency before the go-live date.

Stage 2: Audit everything and map your redirects

This is where the majority of SEO migration work happens. Audit the current site, audit the new site in staging, build the redirect map, and validate everything before a single URL goes live.

Crawl and document the current site

Run a full crawl using Screaming Frog, Sitebulb, or Ahrefs. Export everything: URLs, status codes, title tags, meta descriptions, H1s, canonical tags, structured data, internal links, and images. This crawl is the master reference document – every URL must be accounted for.

Audit the new site in staging

  • URL structure – clean, descriptive, and logically organised?

  • Content parity – has any high-performing content been removed, merged, or altered?

  • Title tags and meta descriptions – unique and optimised per page, not template-generated duplicates

  • Internal links – pointing to new URLs directly, not old URLs through redirects

  • Image optimisation – alt tags, file names, and file sizes

  • Structured data – Article, FAQ, Product, and Organisation schema correctly implemented and validated

  • Mobile experience – tested across multiple devices; Googlebot uses mobile-first indexing

  • XML sitemap – valid, reflects new URL structure, contains only correct URLs

  • Robots.txt – staging blocks all crawlers; production version ready to open at launch

  • Custom 404 page – functioning and helping users navigate to useful content

  • Core Web Vitals – benchmarked on staging; flag any regressions before launch

  • Tracking – GA4 and Tag Manager correctly implemented on every page type

Create the redirect map

The redirect map matches every old URL to its new equivalent. It is the most consequential document in the migration.

  • Every page with organic traffic or external backlinks redirects to its closest topical equivalent – never the homepage

  • If no direct equivalent exists, redirect to the most relevant parent category page

  • Use 301 redirects, not 302s – 302 signals temporary and may not pass ranking signals

  • Avoid chains – if A redirects to B and B now redirects to C, update A to point directly to C

  • Review high-priority URLs manually; pattern-matching alone is insufficient for key pages

Review new domain history (if applicable)

If the migration involves a new domain, check its history via the Wayback Machine and backlink tools. A domain with prior spam or penalties can negatively affect the new site from day one.

Verify all SEO elements

  • Title tags and meta descriptions match the plan across all page types

  • Canonical tags in place and pointing to correct new URLs

  • Noindex tags removed from all pages that should be indexed – this is critical

  • Hreflang tags correct with return tags validated for all international variants

  • Structured data validates without errors in Google’s Rich Results Test

  • All internal links using new URL structure directly

Run a final pre-launch crawl

Crawl staging one final time immediately before launch. Compare against the original crawl and the recommendations document. Any discrepancy is a risk that must be resolved before go-live.

Coordinate launch timing

Launch on a Tuesday or Wednesday when the full team is available to monitor and respond. Never launch on a Friday, during peak traffic periods, or before a bank holiday.

Stage 3: Launch day

Launch day requires fast, sequential verification. The new site goes live and every critical element must be confirmed in order.

  • Noindex tags removed from all indexable pages

  • Robots.txt allows crawling of all important areas of the site

  • Canonical tags pointing to correct live URLs, not staging URLs

  • Priority redirects re-tested on the live site – server configuration can cause staging redirects to behave differently in production

  • Updated XML sitemap submitted to Google Search Console

  • New Search Console property set up and Change of Address tool used if domain has changed

  • GA4 real-time data confirmed as flowing correctly

  • Conversion paths tested – forms, checkout flows, and key events

  • URL Inspection tool used to request indexing of highest-priority pages

  • Full crawl of the live site run immediately to catch any deployment issues

The most common launch-day failure is a robots.txt error. The staging disallow-all carrying into production. Check it within the first 30 minutes of go-live.

Stage 4: Monitor, measure, fix

The first four to eight weeks after go-live are where issues surface and recovery is managed. This stage is as important as pre-launch preparation.

Indexation

  • Track indexed page count via Search Console coverage report – compare against target

  • Investigate if numbers are not climbing within the first week

  • Watch for unexpected noindex or excluded pages in coverage data

Keywords and traffic

  • Monitor priority keywords daily for the first two to three weeks, then weekly

  • Compare organic traffic against pre-migration benchmarks by page type and site section

  • Investigate any section underperforming disproportionately relative to the rest of the site

  • Rankings not recovering within two to three weeks need active investigation – not a wait-and-see approach

Technical

  • Continue monitoring Search Console for new crawl errors, 404s, and server errors

  • Spot-check high-value redirects weekly to confirm they are resolving correctly

  • Review Core Web Vitals field data under real traffic – staging performance does not always predict production

  • Run a full re-crawl at four to six weeks and compare against staging crawl

Post-migration review

At four weeks, compile a formal performance review: what recovered as expected, what is still below baseline, and the remediation plan for outstanding issues. This document closes out the migration engagement and sets the baseline for ongoing monitoring.

Migrations and AI search visibility

A migration guide that covers only traditional search is now incomplete. AI Overviews, ChatGPT, and Perplexity synthesise and cite content – and that visibility can be disrupted during a migration in ways that do not appear in Search Console. SUSO Digital includes AI search benchmarking as a standard phase in their migration process, tracking citation visibility before and after launch alongside traditional organic metrics.

AI citation visibility is at risk when previously cited content is removed or restructured, when schema markup is lost on the new site, or when topical authority signals are diluted through poor redirect mapping.

AI search checklist

  • Benchmark current AI citations before migration – run key queries through ChatGPT, Perplexity, and Google AI Overviews and record which pages are cited

  • Preserve structured data – especially Article, FAQ, Product, and Organisation schema – and validate on the new site

  • Maintain content depth and topical clustering for pages AI models have been citing

  • Confirm authoritative content retains its URL or redirects cleanly to its new location

  • Re-run the same AI queries after migration and compare citations against the pre-migration benchmark

If citations drop post-launch, work backwards: check for broken schema, removed content, lost internal links, or redirect chains affecting previously cited pages.

The only rule that matters

A successful migration is not measured by a clean launch on day one. It is measured by traffic levels 90 days later. Every hour invested in pre-migration preparation reduces the risk of spending those 90 days in recovery.

Common questions

How far in advance should SEO be involved?

At platform or CMS selection stage – before development begins. Minimum eight weeks before go-live for a straightforward migration; twelve to sixteen weeks for a complex multi-region or multi-domain project.

How long does traffic recovery take?

A Search Engine Journal study of 892 domain migrations found the average recovery time was 523 days – but that average includes poorly executed migrations that never fully recovered. Well-planned migrations often see traffic stabilise within two to eight weeks.

How many hours of SEO work does a migration require?

Typically 60 to 100+ hours across planning, audit, pre-launch testing, launch day, and monitoring. Smaller sites fall at the lower end; large or complex migrations push well beyond 100 hours.

Can I make content changes at the same time as a migration?

You can, but be cautious. Every simultaneous change makes it harder to diagnose the cause if traffic drops. Keep the migration focused on the structural move. Content changes are better handled as a separate phase once the migration has stabilised.