Migrating a site without losing rankings — a 2026 playbook

We get migration requests roughly every month. The conversation usually starts with some version of "we're replatforming from WordPress to Shopify" or "moving from a custom Ruby app to a Next.js storefront." The follow-up question is always "how do we not lose our SEO?" — and the honest answer is "you can, but only if you treat the migration as a real engineering project with a specific checklist."

Done well, a migration can actually improve organic traffic — faster site, better schema, cleaner URL structure. Done badly, a migration erases years of accumulated organic equity in a single weekend, and the recovery takes 6-12 months of remediation. This article is the operational playbook we follow when handling replatforming. It's the supporting piece for the website + SEO pillar, where the broader stack-choice and architecture context lives.

The six things that go wrong, in order of frequency

We've watched dozens of migrations over the years. The failure modes cluster:

1. Missing or broken redirects. Old URL /blog/post-name doesn't redirect to new URL /insights/post-name. Google sees a 404 on a previously-ranked URL. After 30 days of 404s, the page is deindexed. The new page (different URL) starts from zero authority.

2. Content rewrites during the migration. Team decides to "improve" copy on top-traffic pages while the replatform is happening. Now we have two changes confounded — the platform change AND the content change. If rankings drop, you can't tell which caused it. If rankings hold, you might still be missing out on what's bleeding.

3. Schema regression. Old site had Article + Organization + BreadcrumbList schema; new site shipped without it. Google's rich-result coverage drops, AI search citations drop, both happen invisibly because nothing about the site "broke."

4. Page-speed regression. Counterintuitive but common — the team migrates to a modern stack expecting speed gains, but ships before optimization. LCP goes from 2.1s to 3.4s. Google's Core Web Vitals score drops, rankings follow.

5. Sitemap not resubmitted. New URLs aren't in Google Search Console's sitemap. Google discovers them slowly through link-following. Indexing lag stretches to weeks instead of days.

6. Trailing-slash or case-sensitivity changes. Old site served /About and /about as the same page. New site treats them as different URLs. Now you have duplicate-content signals where you didn't before.

Each of these is preventable with a checklist. The list below is what we work through.

The pre-migration audit (Phase 1, week -3 to -1)

You don't start a migration without a complete inventory of what's currently there. Tools we use: Screaming Frog (or Sitebulb), Search Console, Ahrefs / Semrush for backlink data.

Crawl the existing site fully. Export every URL, status code, response time, meta title, meta description, H1, canonical, schema type, and inbound internal link count. This is the baseline. The crawl typically takes 1-4 hours depending on site size.

Pull last 90 days of Search Console data. Top 50 queries by clicks. Top 50 queries by impressions. Top 50 pages by clicks. The pages and queries on those lists are your priority targets — these are the URLs that must survive the migration with rankings intact.

Pull backlink profile. Export referring domains and the specific URLs they link to. The deep-link targets are your real priority — if you lose redirects to backlinked URLs, you lose the link equity.

Map content to the new structure. Every URL on the existing site needs a destination URL on the new site. Build a spreadsheet: old URL, new URL, status (1:1 / consolidated / removed), redirect type (301 / 410 / canonical). This is the master migration document.

Identify orphans and dead pages. Pages with no inbound internal links and no organic traffic — candidates for removal. Migrations are a good time to clean up; just be deliberate about which pages get removed.

The redirect map (Phase 2, weeks -2 to launch)

The redirect map is the document that prevents most migration disasters. Two rules:

Every old URL maps to something. Either a 1:1 destination on the new site (the most common case) or an explicit 410 ("gone") response. Never silent 404s on previously-indexed URLs.

Every redirect is a 301, not a 302. 301 is permanent — passes full link equity. 302 is temporary — passes partial. We've seen 302 redirects cause 30-50% organic traffic loss. The distinction matters.

The redirect map is generated from the master spreadsheet and exported as a rules file for the new platform. For Next.js sites, this becomes redirects in next.config.ts or a custom middleware. For Shopify, it's the URL Redirects section of the admin. For WordPress, a plugin like Redirection.

A typical migration has 200-1500 redirects. Don't skip the long tail — the redirects for low-traffic pages are cheap to add and prevent the slow erosion of link equity.

The launch sequence (Phase 3, weeks -1 to launch)

The week before launch is checklist execution, not creative work. The list:

Soft-launch on a test domain or staging URL. New platform runs at staging.mediapromotions.net with noindex headers globally. Internal QA can test it without Google indexing the staging URLs.

Verify redirects on staging by hitting every URL on the old-site crawl. Automated check, not manual sampling. We use a script that hits each old URL and verifies the response is 301 to the expected new URL. Any URL returning 404 or wrong destination gets flagged for fix before launch.

Confirm schema is present on the new platform. Open key pages, view source, validate the JSON-LD in Google's Rich Results Test. Organization, LocalBusiness, Service, FAQPage, Article — whichever applied on the old site should apply on the new one.

Measure new-site Core Web Vitals on staging. PageSpeed Insights, multiple representative URLs. If LCP is above 2.5s on mobile, optimize before launch. Migration is the moment to fix performance, not after.

Confirm canonical tags are set correctly. Every page on the new site should have an explicit canonical pointing to itself. Confused or missing canonicals cause Google to make choices it shouldn't make.

Submit the new sitemap to Search Console. Add the new site's sitemap.xml to the new property in Search Console (you'll need to verify the new property first if the URL structure has changed).

Set up IndexNow ping for fast Bing/Yandex/Seznam discovery. Faster than waiting for organic crawl.

The launch day (Phase 4, launch ± 24 hours)

The actual cutover is a DNS change. The hours around it matter.

Time the launch to a low-traffic window. Tuesday morning, ideally. Not Friday afternoon. Not the start of a holiday weekend. You want maximum monitoring time after launch in case something needs immediate fix.

Lower DNS TTL 48 hours before cutover. Drop your DNS TTL from the default (often 24 hours) to 300 seconds (5 minutes). This lets the propagation happen quickly and rollback (if needed) happens quickly too.

At cutover: flip DNS. Watch. First 30 minutes: real-user traffic on the new platform. Open Vercel / Cloudflare / your CDN logs. Watch 5xx rate. Watch response times. Watch organic traffic in Plausible or whatever real-time analytics you have. If anything's broken, rollback DNS now.

At cutover + 60 min: spot-check critical user flows. Lead form submission, e-commerce checkout if applicable, account signup. Anything that touches a third-party integration (Stripe, Supabase, your CRM) needs human verification, not automated alerting.

At cutover + 120 min: pull a fresh Search Console crawl stats. Are Google's bots reaching the new site at expected rates? If crawl rate dropped to zero, there's a robots.txt issue or an HTTP-500 wall blocking the crawlers.

Cutover + 24 hours: full check. Run a fresh full-site crawl with Screaming Frog. Verify every URL on the old crawl now resolves correctly (200 on new URLs, 301 on old URLs). Pull Search Console for any new crawl errors. Look at top 50 pages from Phase 1 baseline; spot-check they're indexing correctly.

The post-launch monitoring window (Phase 5, weeks 1-4)

Launch is not the finish line. The next 30 days is when problems surface.

Daily for the first week:

• 5xx error rate
• Crawl stats in Search Console
• Real-user metrics for Core Web Vitals
• Spike in 404s (Search Console → Pages → Not indexed)
• Indexing coverage (sudden drops mean trouble)

Weekly for the first month:

• Top-page rankings for high-value queries (compare to pre-migration baseline)
• Organic session traffic vs same period prior month + same period prior year
• Backlink-equity transfer (referring domains pointing at old URLs now showing equity flow to new URLs)
• Any "soft 404" warnings in Search Console

The pattern we expect to see: a 5-15% traffic dip in week 1, recovery to ~95% of baseline by week 3, full recovery + small uplift from improved platform by week 6-8. If traffic doesn't recover by week 4, something is structurally wrong and worth investigating.

The mistakes we see in nearly every botched migration

Beyond the six big ones at the top, more granular failure patterns:

Forgetting subdomain or alternate-host redirects. If your old site was at www.example.com and example.com both, both need redirect handling. We've seen migrations where example.com started serving the new site but www.example.com continued serving the old site for weeks.

Hreflang misconfiguration on international sites. Multi-language sites need hreflang tags. The migration is a common moment for them to break — wrong country code, mismatched alternate URLs, missing reciprocal references.

Mobile-specific redirects on the old site. Older WordPress sites sometimes had separate mobile URLs (m.example.com). Those need redirects too, even if your new site is responsive (which it should be).

Lost image redirects. Images that were ranking in image search need their URLs to redirect, not just the parent pages. Most teams forget image redirects. We've seen this cost meaningful traffic for visual-search-heavy categories (recipe sites, e-commerce, design).

404s on robots.txt or sitemap.xml themselves. Yes, we've seen migrations where the basics returned 404 for the first 48 hours. Devastating. Verify these specifically.

SSL cert mismatches during DNS propagation. New cert isn't fully propagated globally when DNS flips. Some users see invalid-cert warnings for hours. Use Let's Encrypt or Cloudflare's automatic SSL to avoid this.

Skipped manual approval of the redirect map. A junior engineer generates the map, ships it, and a high-traffic page redirects to the wrong destination. We require human approval of redirect maps over 200 URLs.

The migration that doesn't lose rankings

The migration that goes well looks boring. The traffic dip in week 1 is minimal (under 10%). Recovery is fast. By week 4, traffic is back to baseline. By week 8, it's slightly above baseline because the new platform is faster and the schema is cleaner.

The migration that goes badly looks dramatic. Traffic drops 30-60% in week 1. Search Console fills with crawl errors. Week 4 traffic is still 40% below baseline. The team is in panic mode trying to figure out which of the 12 things they changed caused which problem.

The difference is checklist discipline, not technical skill. The skills required are well-documented and not novel. The will to do every step in the right order — especially the boring ones, like verifying every old URL redirects correctly — is what separates the two outcomes.

What we charge for a migration

Migration project pricing in our 2026 retainer engagement:

• Light migration (under 50 URLs, single platform-to-platform, no e-commerce): $4,500-$8,500 one-time + included in any active retainer
• Standard migration (100-500 URLs, marketing site, schema rebuild, page-speed optimization): $8,500-$18,000 one-time
• Complex migration (500+ URLs, e-commerce or membership, custom integrations, international/multi-language): $18,000-$45,000+ one-time

This is for the migration work itself — pre-audit, redirect mapping, schema implementation, launch supervision, post-launch monitoring. The new website build is separate (covered in the web/SEO pillar pricing section).

A safe migration on a serious site is worth every dollar. A bad migration on a serious site costs 10-30× more than a careful one — in lost traffic, recovery work, and rankings that never come back.

This article is part of the website + SEO complete guide cluster. For the broader stack-decision and architecture context, see the pillar. For a migration audit on your specific replatform plan, open the intake.