SEO for Site Migrations: 301 Mapping and Traffic Protection for Domain, Platform, and Structure Changes
1. Three Migration Types and Their Risk Levels
Not all site migrations hurt the same way. First determine which type you’re in, then decide how much effort to invest.
| Migration type | URL changes | Authority transfer period | Risk level | Core actions |
|---|---|---|---|---|
| Domain change (example.com → new.com) | All change | 2 to 6 weeks | High | Change of Address + full 301s |
| Platform change (Shopify → custom build / WordPress → Next.js) | Most change | 2 to 4 weeks | Medium-high | Map each URL + resubmit sitemap |
| Directory structure change (/blog/ → /insight/) | Some change | 1 to 2 weeks | Medium | Bulk 301s via regex |
| Switch to HTTPS or add www | Protocol/subdomain change | Within 1 week | Low | Site-wide 301s to the new protocol |
| Redesign only, URLs unchanged | No change | None | Low | No 301s needed; focus on performance and content |
Counterintuitive point: for migrations that look “small” like switching to HTTPS or adding www, if the 301s are written wrong and both https and http versions coexist, the long-term cost of split authority is far higher than a single content overhaul.HTTPS configuration and HSTS are the technical prerequisites for this type of migration.
2. How to Build the 301 Mapping Table: From T-30 Days to T Day
The mapping table isn’t something you patch together after launch, it’s a key deliverable that should start 30 days before launch.
| Timing | Action | Data source | Acceptance Criteria |
|---|---|---|---|
| T-30 days | Export all URLs from the old site | XML sitemap + Screaming Frog 爬取 | Cover 100% of indexed URLs |
| T-28 days | Layer in GSC click data from the past 12 months | Search Console performance report | Flag all URLs with clicks as priority |
| T-21 days | Layer in backlink data | Ahrefs / Google Search Console 链接 | URLs with backlinks must not be casually 404’d |
| T-14 days | Map each URL 1:1 | Content team + SEO together | 100% of URLs with clicks have a new destination |
| T-7 days | Technical review of the mapping table | Dev + ops | No 301 chains, no 404 destinations |
| T day | Launch 301s + submit change | Server config + GSC Change of Address | Spot-check 50 URLs all 301 to the correct pages |
Example: an industrial B2B site moves from an old domain to a new brand domain. The old site has 2,300 URLs. Instead of mapping them one by one, the team does bulk 301s by directory: everything under /products/ goes to /products/ on the new site, everything under /blog/ goes to /insight/. Four weeks after launch, blog traffic on the new site is only 40% of the old site’s. Why? The old blog post URLs were organized by topic, the new site organizes them by publish year, and the directory-level 301s sent every post to a year archive page, so topical relevance was lost. The right approach is one-to-one mapping: 2,300 URLs takes two people two days.
The mapping rule is topic-to-topic, 1:1: old product page to new product page; old blog post to the most relevant post on the new site; old pages with no matching new content go to a category page, not the homepage. Dumping every old URL on the homepage is the most common mistake.
3. Six things you must do on launch day
| Action | Tools | Why it has to happen that day |
|---|---|---|
| Spot-check 50 of the 301 mappings | Screaming Frog / Redirect Path | If the setup is wrong you can fix it that day; a week’s delay wastes a week of crawl budget |
| Submit a Change of Address | Search Console | Google’s official migration signal; speeds up recrawling |
| Submit the new sitemap | Search Console | So Google finds the new URL structure right away |
| Turn off logged-in crawling of the old site | robots.txt / noindex on the old site | So the old site stops getting crawled |
| Tell your key link partners | Email / LinkedIn | Directories and partners update their links to the new domain |
| Watch the GSC error queue | Search Console | Check once a day for the first 7 days; act immediately if 404s spike |
When you change domains, remember to verify Google Analytics, Search Console and your ad accounts on the new domain too, or your data starts from zero.Site monitoring and alerts metrics need to be set up before the migration so you have a baseline to compare against afterward.
4. How to tell at T+60 days whether it worked
| Metrics | Healthy range | Warning sign | Act immediately |
|---|---|---|---|
| Organic clicks | Back to 90%+ of the old site by T+60 | Still below 50% of the old site at T+60 | Recheck the 301 mappings one by one |
| Index coverage | Indexed pages ≥ 90% | Bulk “Crawled – currently not indexed” | Check content quality and crawl budget |
| 301 chains | 0 items | Redirects with 2+ hops | Collapse them into direct 301s |
| 404 count | Stable at a low level after T+30 | Keeps climbing | Export the GSC 404 report and add 301s |
| Core Web Vitals | No decline after migration | LCP worse by 0.5 seconds or more | Performance regression testing on the new platform |
Example two: a B2B site moves from WordPress to Next.js and organic traffic drops 35% at T+30 days. The team wants to roll back. The GSC coverage report shows indexed pages fell from 1,800 on the old site to 600, because the new sitemap only submitted product pages and left out every blog post. Two weeks after submitting the missing sitemap, the index count is back to 1,700 and traffic has recovered to 92% of the old site. The lesson: when traffic drops after a migration, look at indexing first. Don’t rush to roll back.
5. Common mistakes and red lines
| Common approach | Consequence | The right way |
|---|---|---|
| 301 every old URL to the new homepage | Soft 404 risk; the homepage’s topical focus gets diluted | Map topics 1:1; only fall back to a category page when no matching page exists |
| After migration, keep the old site’s 301s for 3 months, then shut them down | Loss of backlink authority | Keep the old site’s 301s for at least 12 months |
| Forgetting to update canonical after a domain change | Duplicate content across the old and new domains | New pages’ canonical tags point to the new domain itself |
| Forgetting to migrate structured data when switching platforms | All rich results disappear | Migrate Schema along with the templates and verify it again after launch |
| Blocking crawling in robots.txt on migration day | Google stops crawling entirely | Keep robots open; only remove the old site’s login-state blocks |
Schema must be verified again as part of the migration,Structured data (Schema) If templates aren’t carried over to the new platform, rich results disappear within 4 to 8 weeks after migration. Multilingual sites also need to check Hreflang for multilingual sites and whether it migrates along with the URL structure.
6. How to keep a data baseline before and after migration
Without a pre-migration baseline, you can’t tell after migration whether a drop is normal fluctuation or a real incident. Freeze the old site’s key data into a snapshot at T-30 days, then compare against it every week after migration.
| Baseline metric | Freeze point | Comparison frequency | Alert threshold |
|---|---|---|---|
| GSC organic clicks and impressions | 12-week average as of T-30 days | Every Monday | Alert if week-over-week drop exceeds 20% |
| Number of indexed pages | T-30 days | Weekly | Alert if drop from baseline exceeds 15% |
| Rankings for core keywords | Top 100 keywords as of T-30 days | Every two weeks | Alert if a top-10 keyword falls out of the top 20 |
| Total backlinks and anchor text | Ahrefs export as of T-30 days | Monthly | Alert if backlink loss exceeds 10% |
| Core Web Vitals | CrUX average as of T-30 days | Every two weeks | Alert if LCP worsens by more than 0.5 seconds |
This baseline table needs to be built before T-day. Check it once a day during the first week after migration, then once a week from the second week on. Many teams only notice a traffic drop two weeks after migration, go back to investigate, and find no baseline was ever kept, leaving them to judge by gut feel. With a baseline in place, your T+60 acceptance check has something to stand on instead of a vague “looks like it’s recovered.”
One more reminder: don’t do a major redesign, template change, and new features all at the same time during migration. Change only one variable at a time, so when something goes wrong you know whether it’s the 301s or the new template. Split content redesigns, performance optimization, and Schema adjustments into batches done 30 days after migration; troubleshooting will be much easier.
During migration, also keep a close eye on server logs. From T-day to T+14 days, check 404 and 5xx request volumes once a day. If 404s spike for a particular type of URL, your mapping table probably missed a batch; if 5xx spikes, the new site’s server configuration is likely the problem, which has nothing to do with SEO but is just as fatal. Put log alerts and GSC reports on the same dashboard so engineering and SEO share one view instead of each looking at their own.
Don’t shut down the old site’s server right after the migration. Keep the old site’s 301s live for at least twelve months. During that time, log into the old domain’s GSC once a month to check organic traffic. Once traffic has been at zero for two months straight, confirm with your ops team that it’s safe to take the old site offline. Shut it down early and your backlink equity breaks instantly, and the past three months of work may be wasted.
FAQ
Do I have to use Change of Address when switching domains?
How much traffic drop is normal after a migration?
How long should I keep the old site’s 301s?
Why isn’t bulk 301s by directory enough?
Should I submit a new sitemap during the migration?
What should I do if rich results disappear after the migration?
Final thoughts
A site migration is one of the few SEO operations you can’t roll back: misconfigure a 301 and it takes 3 to 6 months to rebuild lost equity. Treat it as an engineering release, not a design handoff.
Three steps to launch: at T-30 days, export every URL from the old site and layer in GSC and backlink data; at T-14 days, finish the 1:1 mapping table and pass technical review; at T+60 days, check the five metrics and fix anything that falls short, one by one.
One line worth remembering: a migration is won or lost in the 30 days before launch. The 301 mapping table is the main deliverable; launch day is just following it.