A website migration protects SEO when every indexed URL maps to a 301 redirect, the new site is crawlable on launch day, and rankings are monitored for 90 days after the switch. Traffic loss comes from missed redirects and blocked crawling, not from the platform change itself.
Most migrations lose 20 to 40 percent of organic traffic in the first month. The ones that hold rankings share one habit: they treat the URL inventory as the plan, not an afterthought. This guide walks the strategy that keeps sessions steady through a move. For the full picture, start with our website migration service page.
Build the URL inventory first
Before touching design or platform, pull every URL that earns traffic or links.
Sources to combine:
- Google Search Console: export the last 16 months of pages by clicks and impressions
- Analytics: export landing pages with sessions over the last 12 months
- A crawl tool: crawl the live site to capture every internal URL
- Backlink data: export pages that hold external links
De-duplicate into one sheet. A 400-page site often carries 900 to 1,200 unique indexed URLs once you add tags, filters, and paginated archives. Every row becomes a redirect decision: keep the same path, map to a new path, or retire and redirect to the closest match.
Rank the list by clicks. The top 50 URLs usually drive 70 to 80 percent of organic sessions. Those get manual review. The long tail gets pattern-based rules.
Set a scope and a rollback plan
Before the work starts, write down what is moving and what is not. A migration that changes the platform, the URLs, the design, and the content at once carries four times the risk of one that changes a single variable. Decide the scope early and hold it.
Four common migration types, ranked by risk:
- Platform move, same URLs. Lowest risk. Rankings usually hold if redirects are clean.
- URL change, same platform and content. Moderate risk. Redirects carry the full load.
- Redesign with new templates. Higher risk. Content and structure both shift.
- Full replatform plus redesign plus new URLs. Highest risk. Several signals change at once.
Whatever the scope, define a rollback before launch. A rollback plan names the exact condition that triggers a reversal, for example a 404 rate above 5 percent or checkout failing on the live domain, and the steps to restore the old site. Keep the old environment reachable for at least 48 hours so the reversal stays a real option, not a theory. Assign one person to make the call so nobody hesitates while traffic bleeds.
Plan redirects at the URL level
A redirect map pairs each old URL with one new URL and a status code.
Rules that hold rankings:
- Use 301 (permanent), never 302, for content that moves for good
- Map to the closest topical match, not the homepage
- Avoid redirect chains: old URL to new URL in one hop, never two or three
- Preserve query strings only where they change page content
Homepage redirects are the most common mistake. Sending 200 retired product URLs to the homepage tells Google those pages had no specific value, and the link equity flattens out. Map each to its category or a replacement product.
Test the map before launch on staging. A 1,000-row map with 30 broken targets means 30 pages return 404 on day one, and recovery takes weeks.
Stage and validate before the switch
The new site should be fully built and testable on a staging URL that search engines cannot index.
Staging checklist:
- Block crawling with HTTP auth or an IP allowlist, not only robots.txt
- Confirm every template renders title tags, meta descriptions, and H1s
- Validate structured data on product, article, and breadcrumb templates
- Check internal links resolve to new paths, not old ones
- Run a full crawl of staging and compare the URL count to the inventory
The comparison catches gaps. If the inventory holds 1,100 URLs and staging crawls to 740, some content did not migrate. Find the missing 360 before launch, not after.
Launch in a controlled window
Pick a low-traffic window and run the cutover as a sequence, not a single toggle.
Launch order:
- Remove the staging crawl block and confirm the site is publicly reachable
- Apply the redirect map at the server or CDN level
- Submit the new XML sitemap in Search Console
- Crawl the live site immediately to confirm redirects fire and return 301
- Spot-check the top 50 URLs by hand
Keep the old platform reachable for 48 hours if the architecture allows it, so a rollback stays possible. Confirm the sitemap lists only 200-status URLs; a sitemap full of redirects or 404s slows re-indexing.
Monitor for 90 days
Rankings settle over weeks, not days. Watch the signals that predict recovery.
Track weekly:
- Search Console coverage: indexed page count should climb back toward the pre-move number
- Crawl stats: Googlebot requests should rise as it re-processes the new URLs
- Top 50 rankings: compare positions to the pre-move baseline
- 404 report: any spike means a redirect rule missed a pattern
Most sites see a dip in weeks one and two, then a climb back to baseline by weeks six to ten. If traffic is still down 15 percent at week eight, re-audit the redirect map against the 404 report. The fix is almost always a missed URL pattern.
For a time estimate on the full process, see how long SEO takes. For a launch-day list, use the website migration checklist.
Assign owners before launch day
A migration fails on the seams between people as often as on the technical work. Name an owner for each piece before the cutover.
| Task | Owner decides |
|---|---|
| Redirect map | Who signs off that every URL has a target |
| Crawl block on staging | Who confirms it is removed at launch, not before |
| DNS change | Who has registrar access and makes the switch |
| Sitemap submission | Who verifies the property and submits |
| 404 monitoring | Who watches the report daily for the first two weeks |
The two failures that recur are a staging crawl block left on after launch, so Google cannot index the new site, and a DNS change nobody was cleared to make on the day. Assign both to a named person, not the team in general, and launch day runs on a checklist instead of a scramble.
A rollback plan that actually works
Hope is not a launch strategy. Decide in advance what triggers a rollback and how you execute it.
- Keep the old platform reachable for at least 48 hours where the architecture allows.
- Define the trigger: a checkout that fails, a 404 rate that spikes, or top pages dropping out of the index.
- Know the mechanism: pointing DNS back, or re-enabling the old server, and who does it.
- Time-box the decision so you are not debating during an outage.
A rollback is cheap insurance that costs only the overlap window. The migrations that go badly are usually the ones where the old site was torn down at launch, so a fault at hour two had no path back except a rushed forward fix under pressure.
Communicating the move to stakeholders
Set expectations so a normal reindexing dip does not read as a failure to the people watching the numbers.
- Tell stakeholders a 10 to 20 percent traffic dip in the first two weeks is expected and temporary.
- Share the recovery window: baseline by weeks six to ten for most sites.
- Report weekly against the pre-move baseline, not day to day, so noise does not drive panic.
- Flag the one metric that signals a real problem: a 404 spike that does not fall.
A migration that recovers on schedule can still look like a crisis to someone who was not told the dip was coming. A short brief before launch turns week-two anxiety into a wait everyone already agreed to.
Hold URLs stable when you can
The lowest-risk migrations change one thing at a time, and the single most protective choice is keeping URLs the same when the platform allows it.
- If the new platform can keep the old URL structure, do it, and you skip the largest source of ranking risk entirely.
- If URLs must change, change only URLs in this move and hold design and content steady, so a ranking drop has one obvious cause.
- If you also want a redesign, ship it as a second phase weeks after the platform move settles.
Bundling a platform change, a redesign, and a content rewrite into one launch makes any traffic drop nearly impossible to diagnose, because three variables changed at once. Separating them costs a little more calendar time and buys a clean read on what each change did.
Frequently asked questions
Will I lose rankings when I migrate?
A short dip is normal in the first two weeks. Permanent loss happens when redirects are missing or the new site blocks crawling. With a complete redirect map and a crawlable launch, most sites recover to baseline within six to ten weeks.
Should I redirect old pages to the homepage?
No. Map each old URL to its closest topical match. Homepage redirects discard the specific ranking signals a page earned and treat it as if it had no unique value.
How many URLs do I actually need to redirect?
Every URL that earns clicks, impressions, or holds a backlink. Pull the list from Search Console, analytics, a crawl, and backlink data, then de-duplicate. A mid-size site usually finds 900 to 1,200 unique URLs.
Can I migrate design and platform at the same time?
You can, but it raises risk. Changing URLs, templates, and content in one move makes it harder to isolate what caused a ranking drop. If the timeline allows, hold URLs stable through a platform move, then redesign.
How long should I keep the old site running?
At least 48 hours, longer if the architecture allows. Keeping the old environment reachable gives you a real rollback if checkout breaks or the 404 rate spikes on launch day. Once the new site holds steady and the first live transactions complete, you can retire the old one.
What is the single biggest cause of migration traffic loss?
Missed redirects. Every indexed URL that returns a 404 instead of a 301 drops from the index and takes its rankings with it. A complete redirect map, tested on staging and re-checked against the 404 report after launch, prevents the majority of lost traffic.
Get help with your migration
If you want a migration planned and executed without the traffic loss, our website migration service team builds the URL inventory, redirect map, and launch plan for you.