Every migration horror story sounds the same: new site goes live, everyone celebrates, and three weeks later organic traffic is down 40% and nobody can say why. The good news is that it’s almost never bad luck. Rankings drop after a migration for a short list of predictable reasons — and every one of them can be prevented with a process that starts weeks before launch day. Here it is, step by step.
To migrate a website without losing SEO, you need to do four things right: record what currently ranks (before anything moves), map every old URL to a new one with a 301 redirect, carry over on-page SEO (titles, meta descriptions, headings, content) unchanged, and monitor Search Console for 30–90 days after launch. A small dip for 1–4 weeks while Google re-crawls the site is normal. A lasting drop almost always means missing redirects, lost content, or a “noindex” setting left on from staging.
Why Rankings Drop After a Migration
Google doesn’t rank “your website” — it ranks individual URLs, each with its own history, backlinks and content. A migration breaks that connection unless you rebuild it deliberately. The usual culprits:
- Old URLs return 404. Every backlink and every Google result pointing to them now leads nowhere, and the ranking history attached to them is lost.
- Content changed or disappeared. A redesign that cuts a 1,500-word service page down to three lines and a hero image removes the very text that page was ranking for.
- On-page SEO wasn’t carried over. Page titles reset to “Home – My Site”, meta descriptions go blank, H1s change.
- The site is blocked from Google. A staging “noindex” tag or a
Disallow: /line in robots.txt survives launch. - Internal links still point to old URLs. Every click goes through a redirect, or worse, a chain of them.
- Site got slower. A heavier theme or new plugins push Core Web Vitals into the red.
None of these are technical edge cases — they’re the default outcome when a migration is treated as “copy the content and switch the domain”.
Phase 1: Before the Move (2–4 Weeks Before Launch)
This is where 80% of a successful migration happens. Rushing this phase is the single most common reason rankings drop.
Step 1: Crawl the old site and list every URL
Use a crawler like Screaming Frog (free up to 500 URLs) to export every page, blog post, category, image and PDF. Then add URLs the crawler can’t find on its own: pages from your XML sitemap, top pages from Google Search Console, and pages that have backlinks (the free Ahrefs Webmaster Tools or Search Console’s Links report will show them). Orphan pages that nobody links to internally often still rank.
Step 2: Benchmark your current performance
Export the last 12 months from Search Console: clicks, impressions and average position per page and per query. Note your total indexed pages, your top 20 landing pages, and Core Web Vitals scores. Without a “before” snapshot, you can’t tell whether a post-launch dip is normal or a problem.
Step 3: Build the redirect map
Create a spreadsheet with two columns: old URL → new URL. Every old page should point to its closest equivalent on the new site — a service page to the same service page, a blog post to the same post. Rules that matter:
- Use 301 (permanent) redirects, not 302s or JavaScript redirects.
- One hop only. Old URL goes directly to the final new URL — no chains through intermediate addresses.
- Never mass-redirect to the homepage. Google treats that like a 404. If a page genuinely has no equivalent, redirect to the closest parent category, or let it return 410 if it had no traffic or links.
- Keep URLs unchanged wherever you can. The safest redirect is the one you don’t need.

Step 4: Keep content and on-page SEO at parity
For every page that brings traffic, the new version should keep the same (or better) page title, meta description, H1, body text, internal links, image alt text and structured data. Redesigns are the moment teams “simplify” copy — that’s fine for pages with no traffic, risky for pages that rank. If you want to rewrite important content, do it a month or two after the migration, so you can see the impact of each change separately.
Step 5: Build on a protected staging site
Build the new site on a staging copy that’s password-protected or set to noindex, so Google never indexes a half-finished duplicate of your site. Then crawl the staging site the same way you crawled the old one, and check: are all key pages there, are titles and H1s correct, do canonical tags point to the live domain (not the staging address), and is the site at least as fast as the old one?
Phase 2: Launch Day
Pick a low-traffic window — for most small businesses, early morning on a weekday when someone is around to fix things, not Friday evening.
Step 6: Switch the domain and implement the redirects
Point the domain to the new site and load the redirect map in the same hour. On WordPress, the Redirection plugin or the redirect manager in Rank Math or Yoast Premium handles this; for large maps, server-level rules (.htaccess or Nginx) are faster. Then test a sample of old URLs — at minimum your top 50 pages — and confirm each returns a single 301 to the right page.
Step 7: Remove every staging block
In WordPress, go to Settings → Reading and make sure “Discourage search engines from indexing this site” is unchecked. Check robots.txt doesn’t contain Disallow: /, remove any password protection, and view the source of a few pages to confirm there’s no noindex meta tag left.

Step 8: Update internal links
Run a search-and-replace across the database so internal links point directly to new URLs rather than relying on redirects. Check menus, footers, buttons and links inside blog posts — these are the ones most often missed.
Step 9: Tell Google about the new site
Submit the new XML sitemap in Search Console and use URL Inspection to request indexing of your most important pages. If the domain changed, verify both domains in Search Console and use the Change of Address tool. Keep the old property — it’s where you’ll watch old URLs drop out of the index.
Step 10: Re-check tracking, forms and conversions
Confirm Google Analytics and Tag Manager fire on every page template, submit a test through every form, and run one test purchase if it’s a store. A migration that keeps rankings but silently breaks the contact form is still a failed migration.
Phase 3: After Launch (The First 90 Days)
Step 11: Watch Search Console daily for the first two weeks
Check the Pages (indexing) report for spikes in “Not found (404)”, “Redirect error” or “Excluded by noindex tag”. Any 404 that used to have traffic or backlinks gets a redirect the same day.
Step 12: Compare against your benchmark weekly
Compare clicks and positions for your top 20 landing pages against the “before” export. Look at individual pages, not just the total — a stable total can hide one important page that dropped to page three.
Step 13: Keep redirects and the old setup in place
Keep redirects live for at least a year — and in practice, permanently; they cost nothing and old backlinks never stop sending visitors. Keep the old domain registered and the old site’s backup for at least 30 days.
What a normal post-migration dip looks like
| Timeframe | What’s normal | What’s a warning sign |
|---|---|---|
| Week 1–2 | Rankings fluctuate, some pages briefly drop as Google re-crawls | Sudden drop of 50%+ in clicks, spike in 404s or noindex errors |
| Week 3–6 | Traffic returns close to the benchmark | Key pages still missing from the index |
| Month 2–3 | Traffic at or above the old level, often helped by a faster site | Steady decline instead of recovery |
Small sites usually settle within a few weeks; sites with thousands of URLs can take a few months, simply because Google needs longer to re-crawl everything. If you’re past week six and key pages haven’t recovered, the cause is almost always one of the issues in the “Why rankings drop” list above — go back through it page by page.

Platform-Specific URL Traps
Moving away from a hosted website builder adds one extra challenge: these platforms force their own URL patterns, so URLs almost always change and the redirect map matters even more.
| Platform you’re leaving | Typical URL pattern | What to watch for |
|---|---|---|
| Wix | Blog posts under /post/…, many pages with auto-generated slugs | No full-site export; blog posts and images often need manual transfer. Redirect every /post/ URL individually |
| Shopify | /products/…, /collections/…, /pages/…, /blogs/news/… | Product variants and collection-filtered URLs multiply quickly. Map products one-to-one when moving to WooCommerce |
| Squarespace | Blog posts under /blog/…, page slugs set manually | Image URLs live on Squarespace’s CDN and break after you cancel — re-upload images to the new site |
| Old custom / PHP site | .php or ?id= parameters | Parameter URLs need server-level redirect rules, not just a plugin list |
For stores, also plan for customer accounts (passwords usually can’t be transferred, so customers need a reset email) and order history, which keeps support and returns working after the switch.
Website Migration SEO Checklist
Copy this list and tick items off as you go.
Before launch
- Full crawl of the old site exported
- URLs from sitemap, Search Console and backlink reports added
- 12-month Search Console benchmark exported (pages + queries)
- Redirect map complete: every old URL → one new URL, 301, no chains
- Titles, meta descriptions, H1s and body content carried over for ranking pages
- Structured data and image alt text carried over
- Staging site crawled and checked; canonicals point to the live domain
- New site speed tested against the old one
Launch day
- Domain switched and redirects live in the same window
- Top 50 old URLs tested: single 301 to the right page
- “Discourage search engines” unchecked, robots.txt and noindex checked
- Internal links updated to new URLs
- New XML sitemap submitted in Search Console
- Change of Address submitted (domain changes only)
- Analytics, forms and checkout tested
After launch
- Search Console indexing report checked daily for 2 weeks
- New 404s with traffic or backlinks redirected the same day
- Top 20 landing pages compared with benchmark weekly
- Redirects kept permanently; old backup kept 30+ days
Frequently Asked Questions
Will I lose SEO if I change my website platform?
Not if every old URL is redirected and the content stays the same. Platform changes cause drops when URLs change without redirects or content is cut — the platform itself isn’t the problem.
How long does it take Google to recognize a migrated site?
Small sites usually stabilize within 2–6 weeks. Larger sites can take a few months, because Google re-crawls URLs gradually.
Should I use 301 or 302 redirects for a migration?
301 (or 308) — both signal a permanent move. A 302 tells Google the move is temporary, which can delay the transfer of ranking signals to the new URL.
Can I change my URLs and design at the same time?
You can, but it makes problems harder to diagnose. If you need both, keep the content of ranking pages stable and leave major content rewrites for a month or two after launch.
How long should I keep redirects?
At least a year, and ideally permanently. Old backlinks and bookmarks keep sending visitors long after Google has updated its index.
The Bottom Line
A website migration doesn’t have to cost you rankings. The sites that lose traffic almost always skipped one of three things: a complete URL inventory, a one-to-one 301 redirect map, or post-launch monitoring. Get those right, keep your ranking content intact, and the most likely outcome is a short wobble followed by traffic at or above where you started — especially if the new site is faster.
If you’d rather not run this checklist yourself, it’s exactly what our website migration service covers. You can also see what a migration typically costs in Website Migration Services: What’s Included and What It Costs in 2026, or get in touch for a fixed quote after a free review of your site.


