SEO Migration Strategy: Planning a Site Move That Doesn't Kill Your Rankings

Migration strategy isn’t a checklist. It’s the thinking that happens before the checklist — the decisions that determine whether your migration is a controlled operation or a controlled demolition.

Most migration guides jump straight to “build a redirect map.” That’s step 15. Steps 1-14 are where you decide whether you should migrate at all, what type of migration you’re doing, and how to structure the project so SEO isn’t an afterthought.

First Question: Do You Actually Need to Migrate?

Not every website change requires a full SEO migration. Some changes are cosmetically different but technically identical — and treating them as migrations adds unnecessary risk.

You need a migration strategy if:

• URLs are changing (new CMS, new URL structure, new domain)
• You’re consolidating multiple sites into one
• You’re splitting one site into multiple domains
• You’re moving from HTTP to HTTPS (or changing subdomains)
• You’re significantly restructuring your information architecture

You probably don’t need a migration strategy if:

• You’re redesigning the visual layout but keeping the same CMS and URLs
• You’re updating content on existing pages
• You’re adding new pages without changing existing ones

If URLs stay the same, Google barely notices. The moment URLs change, you’re asking Google to reassociate all your ranking signals with new addresses. That’s where things get risky.

Types of SEO Migration

Different migration types carry different levels of risk. Know which one you’re doing:

Platform Migration (Medium Risk)

Moving from one CMS to another — WordPress to Headless, Shopify to custom, legacy system to modern stack. URLs often change because different platforms have different URL conventions.

Key risk: Default URL structures differ between platforms. WordPress uses /category/post-name/, Shopify uses /collections/ and /products/, Astro generates whatever you configure. If you don’t control the new URL structure from the start, you’ll end up with unnecessary redirects.

Strategy: Define your URL structure before choosing development settings. Force the new platform to match your old URLs wherever possible.

Domain Migration (High Risk)

Moving from one domain to another — rebrand, acquisition, or consolidation. This is the highest-risk migration because you’re asking Google to transfer all authority from one domain to a completely new one.

Key risk: Domain authority doesn’t transfer instantly or completely. Even with perfect redirects, expect a temporary ranking dip as Google recrawls and reassociates signals.

Strategy: Use Google’s Change of Address tool in Search Console. Keep the old domain active with redirects for at least 12 months. Monitor the authority transfer in Ahrefs/Moz — it should stabilise within 3-6 months.

Structural Migration (Medium-High Risk)

Restructuring your site’s information architecture — changing categories, merging sections, creating new navigation hierarchies. URLs change because the site structure changes.

Key risk: Internal linking patterns shift dramatically. Pages that had strong internal link equity may lose it if the new structure doesn’t maintain similar link flows.

Strategy: Map the internal link graph before and after. Ensure high-value pages receive at least as many internal links in the new structure as they had in the old one.

Protocol Migration (Low Risk)

HTTP to HTTPS, or www to non-www. Technically a migration, but the lowest risk if done correctly.

Strategy: Server-level redirect rules. All versions (http://www, http://non-www, https://www, https://non-www) should 301 to a single canonical version.

Building the Migration Strategy Document

Before any development begins, you need a strategy document that covers:

1. Scope Definition

What’s changing and what isn’t. Be specific:

• Are URLs changing? Which ones?
• Is content changing? What’s being added, removed, or merged?
• Is the domain changing?
• Is the hosting environment changing?
• Are third-party integrations (analytics, chat, forms) changing?

Every change introduces risk. The strategy should acknowledge each risk and plan for it.

2. Success Criteria

Define what “success” looks like before the migration, not after. Typical criteria:

• Organic traffic within 5% of pre-migration levels within 30 days
• No more than 10% ranking position fluctuation for priority keywords
• Zero high-priority pages returning 404 errors
• Core Web Vitals meeting or exceeding pre-migration scores
• Full index coverage restored within 60 days

Without defined success criteria, you can’t measure whether the migration worked.

3. Risk Register

Document every risk and its mitigation:

Risk	Likelihood	Impact	Mitigation
Redirects not deployed correctly	Medium	Critical	Test on staging, automated verification post-launch
Content parity lost in redesign	High	High	SEO review of all content changes before dev freeze
Robots.txt blocks crawling	Low	Critical	Pre-launch robots.txt audit, post-launch verification
Core Web Vitals regression	Medium	Medium	Performance benchmarking during development
Analytics tracking breaks	Medium	High	Pre-launch tracking audit, real-time monitoring

4. Timeline and Responsibilities

SEO migration tasks need to be built into the project timeline — not bolted on at the end. Critical milestones:

• URL structure finalised — before development begins
• Redirect map complete — before content freeze
• Staging SEO audit complete — before launch approval
• Launch day SEO team available — during deployment

Assign specific people to each task. “The SEO agency” isn’t a person. “Sarah reviews redirect map by March 15” is.

5. Rollback Plan

What happens if the migration goes badly wrong? You need a rollback plan:

• Can you revert to the old site quickly?
• How long would rollback take?
• What’s the trigger for deciding to rollback? (e.g., 50% traffic drop within 24 hours)
• Who has authority to make the rollback decision?

Most migrations don’t need rollback. But having the plan removes panic from the decision-making process if things go wrong.

Common Strategic Mistakes

Treating SEO as a Post-Launch Concern

The most common and most damaging mistake. By the time SEO is considered “after launch,” URLs are locked, content is finalised, and the redirect map is a rushed afterthought.

Fix: SEO requirements should be in the project brief from day one. URL structure, redirect mapping, and content parity are development requirements, not marketing nice-to-haves.

Redirecting Everything to the Homepage

When the redirect map gets complicated, lazy implementations redirect all unmatched old URLs to the homepage. Google treats mass homepage redirects as soft 404s. You lose the ranking signals from every redirected page.

Fix: Map each old URL to its most relevant new equivalent. If there’s genuinely no equivalent, redirect to the most relevant category or parent page — not the homepage.

Ignoring the Backlink Profile

You can have perfect redirects for user-facing pages and still lose link equity if you don’t account for backlinks pointing to non-obvious URLs — old PDF files, image URLs, deep-linked resources.

Fix: Export your full backlink profile and ensure every URL receiving external links is accounted for in the redirect map.

Launching Without Monitoring Capacity

Launching on a Friday afternoon before a holiday is not a meme — it happens. And when it does, migration errors go undetected for days while Google crawls the broken site.

Fix: Launch when your team has full capacity to monitor for 48-72 hours post-deployment.

Not Testing at Scale

Spot-checking 20 redirects out of 2,000 is not testing. Automated crawling of the full redirect map is testing.

Fix: Use tools like Screaming Frog in list mode to verify every redirect fires correctly before launch. Then verify again after launch.

When to Bring in a Specialist

If your site has fewer than 50 pages and minimal organic traffic, you can probably manage a migration with this guide and careful execution.

If any of these apply, consider bringing in a migration specialist:

• More than 500 pages
• Significant organic traffic (>5,000 monthly sessions)
• Complex URL structures (parameters, faceted navigation)
• Multi-language or multi-market site
• Domain change
• Legacy redirect chains that need cleanup

The cost of a specialist is a fraction of the cost of a botched migration. Rebuilding lost organic traffic can take 6-12 months.

Planning a migration and want to make sure your rankings survive? See our SEO migration services — we handle the strategy and execution so your dev team can focus on building.