Most website migrations lose traffic for a boring reason. The team followed a checklist, ticked every box, and never defined what "done" meant for each box.
Redirects were "set up," but nobody tested the full list of old URLs. The new templates were "checked," but nobody compared their titles, canonicals and schema with the old site, field by field. Everything looked fine in the browser, and two weeks later organic traffic started sliding.
An SEO migration plan fixes that. It turns each task into a test with a pass or fail result, adds a go/no-go gate before launch, and gives you a way to tell a normal post-migration dip from a real regression. A migration is not complete when the new site goes live. It is complete when you have verified that search engines can crawl, index and understand the new site without losing the signals the old one earned.
If you only need the task list, use the website migration SEO checklist, available as PDF, Word and Excel. This guide explains how to plan and run the work behind it.
How to Do an SEO Migration: The Short Answer
- Identify the migration type and where its risk sits.
- Capture a baseline crawl, URL list and performance export.
- Build a redirect map, reviewing high-value URLs by hand.
- Flatten redirects left over from earlier migrations.
- Protect staging without risking production.
- Compare the staging crawl with the baseline, field by field.
- Test crawler access on the new host, CDN and firewall.
- Run a go/no-go review against agreed launch criteria.
- Launch, then crawl the old URL list and production immediately.
- Diagnose any traffic drop at the page level, not the site level.
- Monitor with scheduled crawls until the migration has fully settled.
Step 1: Identify the Migration Type and Its Risk
"Migration" covers very different projects, and your plan should spend effort where the risk actually sits. Combining a domain change with a URL restructure in one release multiplies risk, because when traffic drops you cannot tell which change caused it. Split them into separate releases when you can.
| Migration type | Risk | What usually breaks | Plan priority |
|---|---|---|---|
| Domain change | High | Backlink equity, slow signal transfer | Complete redirect map, Change of Address tool, backlink outreach |
| URL restructure | High | Long tail URLs missing from the map, redirect chains | Full URL inventory, chain flattening |
| CMS or platform switch | High | Metadata and schema lost on new templates, forced URL formats | Template field comparison, JavaScript rendering checks |
| Site consolidation | High | Duplicate content, irrelevant destinations | Content mapping by intent, canonical review |
| HTTP to HTTPS | Medium | Mixed content, internal links still pointing to HTTP | Sitewide 301, internal link and canonical updates |
| Hosting or CDN move | Medium | Firewall rules blocking Googlebot or AI crawlers, new 5xx errors | Bot access tests, server response monitoring |
| Redesign only | Lower | Removed content, weaker internal linking, changed headings | Content and internal link comparison |
Write three things at the top of your plan: the migration type, the changes you intend to make, and the things that must not change. That last list is what every later test checks against.
Step 2: Capture a Baseline You Can Compare Against
You cannot prove a migration worked without a "before" snapshot. Capture it two to four weeks before launch and leave it untouched.
- A full crawl of the current site. Status codes, titles, meta descriptions, H1s, canonicals, robots directives, hreflang, structured data, internal link counts and word count for every URL. Save it as a named audit so you can compare against it later.
- The complete old URL list. Combine crawled URLs with XML sitemap URLs, Search Console pages, GA4 landing pages and URLs from your backlink tool. A crawl alone misses orphan pages, old campaign URLs and PDFs that still earn links.
- Performance data. Export Search Console clicks, impressions and queries per page, plus GA4 organic sessions and key events per landing page. Split branded and non-branded traffic.
- Indexing data. Record the indexed page count from the Search Console page indexing report.
- Existing redirect rules. Export them now. You will need them in Step 4.
Pass criteria: one saved baseline crawl, one deduplicated old URL list and one performance export, all dated and stored where the whole team can find them.
Step 3: Build the Redirect Map by Page Value
Map every old URL to its closest equivalent new URL, one to one wherever possible. Then sort the map by value, so people review the URLs that matter most instead of skimming thousands of rows.
| URL group | How to map it |
|---|---|
| High-value URLs (top traffic, revenue or backlinks) | Review each destination by hand and confirm the new page covers the same search intent |
| Pattern URLs (products, posts, categories) | Map with rules, then spot-check a sample from every pattern |
| URLs with no equivalent | Redirect to the closest relevant parent. Return 404 or 410 only when nothing relevant exists |
| Images, PDFs and other files | Include any file that earns links or image search traffic |
| Parameter URLs | Decide which tracking parameters must pass through to the destination |
Do not send unmatched URLs to the homepage. Google tends to treat irrelevant redirects as soft 404s, so the old page's signals do not carry over. Our guide to finding and fixing redirect problems covers destination choices in more detail.
Pass criteria: every URL on the old URL list has a destination or a deliberate 404/410 decision, and a person has reviewed every high-value URL.
Step 4: Flatten Redirects From Earlier Migrations
Most migration guides skip this. If your site has been migrated before, its old redirects already point to URLs that are about to change. Apply the new map on top of them and you create chains.
# Before the new migration (from a 2021 move)
/services/seo-audit 301 /seo-audit/
# New migration rule
/seo-audit/ 301 /services/technical-seo-audit/
# Result: a two-hop chain
/services/seo-audit > /seo-audit/ > /services/technical-seo-audit/
# Fix: point the legacy rule straight at the final URL
/services/seo-audit 301 /services/technical-seo-audit/Before launch, update every existing rule so it points straight to the final destination. Then confirm that no destination in your new map is itself a URL that redirects.
Pass criteria: every legacy and new redirect resolves in a single hop to a URL that returns 200. See the redirect chain issue for how to spot them in a crawl.
Step 5: Protect Staging Without Risking Production
Staging has to stay out of search, but the method you choose decides how risky launch day is.
| Method | Launch risk | Why |
|---|---|---|
| Password protection or IP allowlist | Safest | Nothing in the HTML or robots.txt changes at launch, so nothing staging-specific can leak into production |
Robots.txt Disallow: / | Risky | Easy to deploy to production by accident, which blocks crawling of the whole new site |
Sitewide noindex | Risky | Often hardcoded in templates and shipped with them, keeping the new site out of search for weeks |
If your crawler needs access to staging, give it credentials instead of opening the site to everyone.
Step 6: Compare the Staging Crawl With the Baseline
This is where most plans say "test the site" and stop. A real test compares the staging crawl with the baseline, field by field, and flags every change that is not on your list of intended changes.
| Field | Expected | Red flag |
|---|---|---|
| Indexable URL count | Within the range your URL map predicts | Large unexplained drop or increase |
| Status codes | 200 for every mapped destination | New 4xx, 5xx or redirected destinations |
| Canonicals | Self-referencing on the production domain | Canonicals pointing to staging or old URLs |
| Robots directives | Same indexability as the old equivalent page | Noindex on pages that used to be indexable |
| Titles and meta descriptions | Carried over or deliberately improved | Template defaults or blank fields |
| H1 and main content | Same topic and comparable depth | Removed sections, lower word count on key pages |
| Internal links | Key pages keep their inbound link count | Pages losing links or becoming orphans |
| Structured data | Same schema types per template | Schema missing from a whole template |
| Hreflang | Return tags valid with the new URLs | Alternates pointing to redirected URLs |
| Rendered content | Content and links present in rendered HTML | Content only visible after user interaction |
In SiteAuditLint's audit comparison, you choose the baseline audit and the staging audit, and every issue appears as new, fixed, increased, decreased or unchanged, with the URLs that changed. Template problems stand out, because they show up as one issue affecting hundreds of URLs instead of hundreds of separate problems. If the new site relies on JavaScript, crawl it with JavaScript rendering turned on so you compare what Google actually sees.
Test the redirect map separately
A crawl of the new site never visits old URLs, because nothing links to them anymore. Test redirects by crawling the old URL list directly, in list mode. Every row should return one 301 to its mapped destination, and that destination should return 200. For a row-by-row method with result codes, see redirect map validation.
Step 7: Test Crawler Access on the New Infrastructure
A new host, CDN or firewall can block crawlers even when robots.txt is perfect. Bot protection, rate limits and challenge pages often return 403 or 429 to Googlebot, Bingbot and AI crawlers, and nobody notices because the site loads fine in a browser.
- Key URLs return 200 with full content when fetched as Googlebot and Bingbot
- Firewall rules allow verified search bots by verification, not by user agent string alone
- AI crawler rules from the old robots.txt are carried over, including separate rules for training and search bots
- The llms.txt file, if you use one, exists on the new site with updated URLs
- Server response time is no worse than the baseline
Related reading: how to diagnose search engine crawling problems on Cloudflare and how to fix 403 errors blocking AI crawlers.
Step 8: Run a Go/No-Go Review
Agree on launch criteria before launch week, not during it. Blocking items stop the launch. Everything else is logged with an owner and a fix date.
| Decision | Issue |
|---|---|
| No-go | Any high-value URL without a tested redirect |
| No-go | Sitewide noindex or robots.txt disallow in the production build |
| No-go | Canonicals pointing to staging or the old domain |
| No-go | Redirect chains or loops on mapped URLs |
| No-go | Analytics or conversion tracking missing on key templates |
| No-go | Search bots blocked by the firewall or CDN |
| Fix after launch | Minor title differences on low-traffic pattern URLs |
| Fix after launch | Internal links that redirect once, scheduled for update |
| Fix after launch | Meta descriptions or alt text carried over in poor shape from the old site |
Agree on a rollback plan at the same time: who can revert the release, how long it takes, and which signal triggers it.
Step 9: Launch Day
Launch in a low-traffic window, with the developer and the SEO lead both available for the hours that follow.
- Deploy the redirects together with the new site, not afterwards.
- Remove staging protection, then confirm robots.txt and meta robots on production.
- Crawl the old URL list and confirm single-hop 301s to 200 pages.
- Crawl production and compare it with the final staging audit. Any difference points to an environment setting.
- Submit the new XML sitemap in Search Console. For a domain change, verify both properties and use the Change of Address tool.
- Keep the old sitemap available for a short period so Google discovers the redirects sooner, then remove it.
- Confirm GA4, Google Tag Manager and conversion events record on the new site. A tracking and analytics audit checks this across every template.
Step 10: Tell a Normal Dip From a Real Regression
Some fluctuation after a migration is expected while Google recrawls the site and processes redirects. Your plan needs to answer one question: is this drop temporary, or did something break?
| Signal | Verdict | What it usually means |
|---|---|---|
| Impressions dip across many pages for a few days, then recover gradually | Normal | Google is reprocessing the move |
| Old URLs move to "Page with redirect" while new URLs are indexed | Normal | Redirects are being followed as intended |
| Rankings wobble on single queries, landing pages hold overall | Normal | Short-term reordering |
| Traffic falls sharply on one template or folder only | Investigate | A template change removed content, links or tags |
| Bulk "Excluded by noindex" or "Alternate page with proper canonical tag" | Investigate | Staging settings or wrong canonicals in production |
| Indexed new URLs stay well below the old count after several weeks | Investigate | Discovery, quality or crawl access problem |
| Crawl stats show a spike in 4xx, 5xx or host errors | Investigate | Missing redirects or infrastructure blocking bots |
Diagnose at the page level, not the site level. Join the baseline performance export to the redirect map, then compare clicks for each old URL with clicks on its new destination. The pages with the biggest gap are where you start.
Be careful with rank tracker data in the first weeks. Third-party tracking has been distorted by altered results served to scrapers, so confirm any drop in Search Console before acting on it. Read more in Google Is Poisoning Search Results: How It Distorts Rank Tracking.
For a structured way to find the cause, follow the SEO incident investigation workflow.
Step 11: Monitor Until the Migration Has Settled
| When | What to check |
|---|---|
| Days 1 to 7 | Daily: Search Console indexing and crawl stats, 404s on old URLs, tracking, server errors |
| Weeks 2 to 4 | Weekly crawl compared with the launch-day audit, page-level clicks against the baseline |
| Months 2 to 3 | Indexed URL count, recovery of high-value pages, outreach to top referring domains |
| Month 3 onward | Monthly scheduled crawls for regressions. Keep redirects for at least a year, ideally permanently |
Ask the sites behind your most valuable backlinks to update their links to the new URLs. Redirects pass signals, but direct links remove your dependence on redirect rules that someone could delete during the next rebuild.
Scheduled audits make the long tail hands-off. Each crawl is compared with the one before it, so a template change that drops canonicals in week six appears as a new issue instead of a slow traffic decline you notice a month later:
- Fixed: migration issues that existed at launch and now pass
- Still open: issues that survived a fix, often on a second template
- New: issues that did not exist before, the clearest sign of a regression
Common SEO Migration Problems and Their Causes
| Problem | Typical cause | How to confirm |
|---|---|---|
| New site not indexed | Staging noindex or disallow shipped to production | Crawl production and filter by indexability |
| Traffic loss in one section | Template dropped content, links or schema | Compare baseline and production audits for that folder |
| Old URLs returning 404 | Long tail or file URLs missing from the map | Crawl the old URL list |
| Slow recovery after a domain move | Chains, homepage redirects or no Change of Address | Check redirect hops and destinations |
| Traffic looks lower than it is | Analytics missing on some templates | Run a tracking audit across all URLs |
| Crawl errors after a host change | Firewall or rate limits blocking bots | Search Console crawl stats and server logs |
SEO Migration Plan FAQ
How long does it take to recover after a website migration?
Small sites with clean one-to-one redirects often stabilize within a few weeks. Large sites, domain changes and migrations that combine several changes can take a few months. If recovery stalls after that, look for a technical cause rather than waiting longer.
How long should I keep 301 redirects after a migration?
At least a year, and permanently if you can. Old URLs keep receiving visits from backlinks, bookmarks and emails long after Google has processed the move.
What is the difference between an SEO migration plan and a checklist?
A checklist lists the tasks. A plan sets the order, the owners, what counts as a pass for each task, and the criteria for launching or rolling back. Track the tasks with the website migration SEO checklist and run them with this plan.
Should I redesign and change URLs at the same time?
Avoid it if you can. Each change makes the other harder to diagnose. If they have to ship together, the baseline comparison in Step 6 matters even more.
Can I test a migration before launch?
Yes. Crawl the password-protected staging site with credentials, compare it with the baseline crawl, and test the old URL list against staging redirects. See pre-deployment SEO testing for the full method, and post-deployment SEO testing for the checks after release.