The Horror Story Nobody Warns You About
A restaurant owner in Kissimmee spent eight months climbing to the top of local search results. Page one for "Cuban food near me." Phone ringing every weekend. Then her developer launched a new website — same business, new design, cleaner URL structure.
Three weeks later, her organic traffic was down 74%.
Her developer had skipped 301 redirects. All that hard-earned Google authority? Gone. Her old URLs now returned 404 errors, and Google had no trail of breadcrumbs leading to the new pages. She had to spend the next six months rebuilding what she'd already built once.
This is a website migration horror story, and it plays out every week for small businesses who don't know what they don't know.
I'm Corey. I've been building on the web for 10+ years. And I can tell you with full certainty: a website migration done right is invisible — your users don't notice anything changed, your rankings hold steady, and your business keeps running. A migration done wrong is a slow-motion catastrophe.
This guide will make sure you do it right.
What Counts as a Website Migration
Before the checklist, let's define scope. According to Google Search Central, a site migration covers any significant change to your site's structure, content, or location — including:
- Domain moves — myoldsite.com → mynewsite.com
- Protocol changes — HTTP → HTTPS
- URL restructuring — /services/cleaning → /cleaning-services (even on the same domain)
- Platform migrations — Wix → WordPress → custom build
- CMS changes — even with the same domain, if your URL patterns change
- Subdomain merges — blog.mybiz.com → mybiz.com/blog
If URLs change — even a little — you need to treat it as a migration and plan accordingly.
The reason this matters: Google indexes specific URLs. When you change a URL without a redirect, Google's link to that page breaks. Any ranking signals, backlinks, or authority that lived on that URL disappears unless you explicitly tell Google where the content moved.
Why Migrations Destroy Rankings (And How Google Sees It)
Here's the mental model that makes everything click: Google doesn't index websites. It indexes pages.
When your site has been live for a year, Google has crawled and cached hundreds of your individual pages. It's seen /services/lawn-care get linked from three local directories. It's noted that /about loads fast and earns a good dwell time. It's associated your home page with your city and your service category.
When you move to a new site, Google has no idea those pages are the same content in a new address unless you use a 301 redirect — a permanent server-side instruction that says "this URL moved here."
Moz's redirect guide has documented that 301 redirects pass approximately 90-99% of link equity from the old URL to the new one. That's almost everything. Miss the redirects and you pass nothing.
Ahrefs' migration research shows that sites losing 40–60% of traffic post-migration almost always share one root cause: redirect coverage below 80%. The businesses that maintain traffic have redirect coverage above 95% — often exactly 100%.
The Pre-Migration Checklist (Do This Before You Touch Anything)
The work you do before launch determines everything.
1. Crawl Your Existing Site
Before you migrate anything, you need a complete inventory of your current site. Use a free tool like Screaming Frog (free up to 500 URLs) to crawl every page. Export it to a spreadsheet.
You want to capture:
- Every URL that exists (not just the pages you remember)
- HTTP status codes (200 = fine, 404 = already broken)
- Page titles and meta descriptions
- Number of internal links to each page
- Any pages that already have backlinks (check in Google Search Console)
This is your migration bible. Every URL on this list needs a plan.
2. Audit Your Backlinks
Log into Google Search Console and download your top linked pages. These are the pages with the most external authority — they deserve extra care. If /blog/our-process has 14 backlinks from local directories, that page's new URL needs a perfect 301.
3. Export Your Rankings Baseline
Screenshot or export your current keyword rankings before the migration. Google Search Console's Performance report shows your top queries and which pages are ranking for them. You'll use this later to verify the migration held.
4. Build Your Redirect Map
Now build a spreadsheet with two columns: Old URL and New URL. Map every single page from your crawl to its destination on the new site.
The rules:
- One-to-one is ideal: old page maps to the closest equivalent new page
- If a page is being removed with no equivalent, redirect to the most relevant parent category
- Don't redirect everything to the homepage — this is a common shortcut that Google treats as a soft 404
- Avoid redirect chains. Old URL → middle URL → new URL loses signal at every hop
A note from the field: I once audited a site that had 12 chained redirects on some pages. Google had simply stopped crawling them.
5. Set Up the New Site Without Making It Live
Build the new site on a staging domain or with password protection. Do not launch until you've done the full pre-launch checks below. Google shouldn't see the new site until everything is ready.
The Launch Day Checklist
This is the moment of maximum risk. You're doing it all at once, in sequence, without a redo button.
1. Implement all 301 redirects before making the site public.
Every redirect from your map needs to be live in your server configuration (.htaccess for Apache, nginx.conf for NGINX, or your CMS redirect manager). Test a sample of 20–30 old URLs and confirm they're redirecting to the right destinations with a 301 — not a 302, not a meta refresh, a 301.
2. Verify HTTPS is set up correctly.
All four versions of your domain should redirect to your canonical version: http://domain.com, http://www.domain.com, https://domain.com, and https://www.domain.com should all end at the same URL. Use SSL Labs to verify your certificate.
3. Confirm your new XML sitemap is submitted.
Generate a sitemap of your new site and submit it in Google Search Console. This tells Google which pages exist and should be indexed. See our XML sitemap guide for a quick walkthrough.
4. Verify your robots.txt doesn't accidentally block crawling.
It's embarrassingly common: a developer adds Disallow: / to robots.txt on the staging site and forgets to change it before launch. Google politely reads it and indexes nothing. Check yourdomain.com/robots.txt the moment the site goes live.
5. Remove any noindex tags from production pages.
Same issue — staging sites often have noindex meta tags on every page. Confirm they're gone.
6. Submit a Change of Address if you moved domains.
Google Search Console has a Change of Address tool in Settings. If you changed your domain name, submit this — it directly signals Google to transfer your rankings. According to Google's own documentation, this speeds up the recrawl process significantly.
The Post-Launch Monitoring Period
You launched. Don't celebrate yet. The next 4–8 weeks are critical.
Week 1: Force a Crawl
In Google Search Console, use the URL Inspection tool to request crawling on your most important pages — homepage, key service pages, location pages. This isn't required, but it gets Google moving faster.
Also: manually test 30–50 redirects from your map. Use your browser's developer tools (Network tab) or a redirect checker to confirm they're returning 301 and landing on the right destination.
Weeks 2–4: Watch for Coverage Errors
Search Console's Coverage report will start showing crawl data for the new site. You're looking for:
- 404 errors — pages Google tried to crawl that don't exist. These are missed redirects. Fix them immediately.
- Redirect loops — circular redirect chains
- Soft 404s — pages that return 200 but show error content
Address errors within 48 hours. Every day a 404 sits unresolved is a day Google is waiting for guidance.
Weeks 4–8: Rankings Will Fluctuate
This is normal. Google is re-evaluating your pages in their new locations. Rankings often dip 10–20% in the first few weeks then recover and sometimes improve. If you see a drop, don't panic — monitor it for 60 days before making changes.
If traffic is still down significantly at 8 weeks, run a redirect audit. Use Screaming Frog to crawl your old site URLs and verify they're all still redirecting correctly. Hosting providers sometimes wipe .htaccess files during server updates.
Platform-Specific Migration Notes
Different platforms create different challenges.
WordPress to Custom Build: WordPress's permalink structure (.com/2024/03/post-name) often changes to cleaner paths. Every post URL will need a redirect. Use a redirect plugin like Redirection to manage this at scale.
Wix or Squarespace to Custom: These platforms often use query-string URLs or generate random slugs. Do a full crawl before leaving the platform — some of those URLs may have indexed traction you don't realize.
HTTP to HTTPS (same domain): Simpler migration, but still needs attention. You need server-level redirects for both www and non-www variants, and your internal links should update to HTTPS. Mixed content warnings (loading HTTP resources on an HTTPS page) can affect both browser security signals and Core Web Vitals.
Domain consolidation (merging two sites into one): This is the hardest migration type. You're essentially migrating two sites simultaneously and teaching Google that their combined authority now lives at one address. Expect 3–6 months for full stabilization.
What to Do When Something Goes Wrong
Even with a perfect plan, migrations break things sometimes. Here's the triage order:
Traffic drops 50%+ in first 48 hours: Check robots.txt and noindex tags immediately. This is almost always the cause for sudden, total traffic loss.
Specific pages not recovering after 2 weeks: Check those redirects manually. Verify the redirect chain is clean and the destination page is indexed.
Whole site dropped but redirects look right: Check for canonical tag misconfiguration. Sometimes migrations introduce canonical tags pointing to the wrong URLs, creating a confusion loop for Googlebot.
Rankings recovered but conversions dropped: This is a UX problem, not an SEO problem. Check if the new page design or copy is less conversion-friendly than the old version. See our guide on website copy that converts.
The old domain is still indexed 6 weeks later: Make sure you submitted the Change of Address in Search Console and that the old site is returning 301s (not 200s with duplicate content).
Common Migration Mistakes (And the People Who Make Them)
The "it'll be fine" developer. Skips the redirect map because "the pages are basically the same." They're not — from Google's perspective, they're new pages with no history.
The deadline-driven launch. The site needs to go live on a specific date for a campaign or event, so the SEO checklist gets rushed. Launch the campaign with the old site and migrate afterward.
The mass homepage redirect. All old URLs → homepage. Quick, easy, catastrophic for SEO. Google treats this as a soft 404.
The forgotten subdomain. Blog was on blog.domain.com, got moved to domain.com/blog, and the subdomain was never redirected. Two years of blog authority evaporated.
The staging site that went live. Developer deploys by copying the staging environment, including the robots.txt that blocks all crawling. Everything is technically live but Google sees nothing.
I've personally seen every one of these. Some I caught in audit. A few I caught too late.
How Long Rankings Take to Recover
Here's what the Ahrefs migration research suggests, and what I've seen in practice:
- Clean migration with full redirects: Rankings hold within 5–10%, recover fully in 4–8 weeks
- Migration with 80–95% redirect coverage: 10–30% traffic drop, full recovery in 3–4 months
- Migration with less than 80% redirect coverage: 40–60% traffic drop, 6–12 months to recover (if ever)
- No redirects at all: Effectively a new website. Start building authority from scratch.
The pattern is clear. Redirect coverage is the single most important variable.
What to Do Next
If you're planning a migration, start here:
- Crawl your current site now — even if the migration is months away. You want that baseline.
- Export your Search Console data — top pages by clicks, top queries, all backlinks.
- Build your redirect map before you build the new site. Not after.
- Plan a 4-week post-launch monitoring window — someone needs to be checking Search Console every 2–3 days.
If you've already migrated and traffic dropped, run the triage checklist above. Missed redirects are usually the culprit and can often be fixed.
If you want help — an audit before your migration, a review of your redirect map, or post-launch monitoring — start a conversation with us. Website migrations are exactly the kind of thing where a second set of experienced eyes pays for itself.
Also worth reading: our core web vitals guide covers the technical health metrics that affect rankings, and our local SEO checklist covers what to verify once your new site is live and stable.
