Website migration SEO is the work of moving a site to a new domain, URL structure, platform or design without losing the search visibility it has earned. The essentials are a complete URL inventory, a one-to-one redirect map using permanent 301 or 308 redirects, a tested staging site, and close monitoring for several months after launch.
Migrations are where websites most often lose organic traffic, and most of those losses are avoidable. They happen because old URLs were never mapped, redirects pointed everything to the home page, the staging site’s noindex tag went live, or important content was dropped from the new design. This guide sets out a practical plan in five phases, with checklists for each, based on Google’s own site move guidance. It is written for marketing leads and project managers running a redesign, replatform or domain change, and for developers who want a shared plan.
Key takeaways
- Map every URL. Every old URL that has traffic, links or rankings needs a redirect to its closest new equivalent, not to the home page.
- Use permanent redirects. Google recommends server-side permanent redirects (301 or 308) for site moves.
- Keep redirects for at least a year. Google’s site move guidance says to keep them in place for at least one year, and longer is safer.
- Expect some fluctuation. Google notes that rankings can fluctuate while a move is processed. A plan reduces the dip; it does not remove all risk.
- Change one big thing at a time where you can. Combining a domain change, a new structure and a new platform makes problems harder to diagnose.
What counts as a website migration?
Any change that alters URLs, content or the way pages are served at scale is a migration in SEO terms. The risk depends on what changes.
| Type | What changes | URL changes? | Typical risk |
|---|---|---|---|
| Redesign only | Templates, layout, design | No | Low to medium (content or internal links may be lost) |
| Platform change | CMS, for example a custom site to WordPress or WordPress to Shopify | Often | Medium to high |
| URL restructure | Folders, slugs, hierarchy | Yes | High |
| HTTP to HTTPS | Protocol | Yes (protocol only) | Low if redirects are correct |
| Domain change | Entire hostname, for example a rebrand | Yes, every URL | High |
| Merging sites | Two or more sites combined | Yes | High |
Even a “redesign only” project can hurt visibility if it removes text from key pages, changes headings, drops internal links or slows the site. Treat every redesign as a migration for planning purposes.
What does Google recommend for site moves?
Google’s guide to site moves with URL changes sets out the core steps:
- Prepare the new site and test it thoroughly before launch.
- Create a mapping of every old URL to its new URL.
- Set up server-side permanent redirects (301 or 308) from old to new URLs.
- Update internal links, canonical tags and sitemaps to use the new URLs.
- For a domain change, use the Change of Address tool in Search Console.
- Monitor traffic and indexing on both old and new sites.
- Keep the redirects in place for at least one year.
Google also notes that a medium-sized site can take a few weeks for most pages to move in its index, and larger sites take longer, with temporary ranking fluctuation during that period being normal.
The Bargaon five-phase migration plan
Inventory, map, test, launch, monitor
Phases 1 and 2 should start before design is finalised, so content and URL decisions shape the build.
Phase 1: Inventory and benchmark
Build a complete list of every URL that matters. Combine these sources, because no single one is complete:
- A crawl of the current site.
- The current XML sitemap.
- Search Console Performance report (pages with clicks or impressions in the last 12 to 16 months).
- Analytics landing pages for the last 12 months.
- Backlink data: pages that other sites link to, from Search Console’s Links report or a backlink tool.
- Paid campaign landing pages, email links and printed QR codes.
Export each source into one sheet and remove duplicates. Mark every URL with its source, so you can see which pages appear only in backlink data or only in analytics; those are the ones most often missed.
Then record a benchmark: organic clicks and impressions by page, top queries, conversions from organic, number of indexed pages and Core Web Vitals status. Without a benchmark, you cannot tell whether the migration helped or hurt.
Phase 2: Map and plan redirects
For every URL in the inventory, decide one of four outcomes:
| Decision | When | Action |
|---|---|---|
| Keep | Page continues with the same URL | No redirect; check content and links are preserved |
| Move | Page continues at a new URL | 301 or 308 redirect to the new URL |
| Merge | Two or more pages combined | Redirect each old URL to the merged page |
| Retire | No equivalent and no value | Redirect to the closest relevant page if one exists; otherwise return 404 or 410 |
Avoid redirecting large numbers of retired URLs to the home page. Google may treat irrelevant redirects as soft 404s, and visitors arriving from an old link expect related content, not the front door. Avoid redirect chains, too. If page A already redirects to B, and B is moving to C, update A to point straight to C.
Phase 3: Build and test on staging
Protect the staging site from indexing with password protection or IP restriction rather than relying on a robots.txt rule alone. Then test:
- Every redirect in the map returns a single 301 or 308 to the right destination.
- Key pages keep their essential content, headings, title tags and meta descriptions, or improve on them.
- Canonical tags point to the new URLs.
- Internal links point directly to final URLs, not through redirects.
- Structured data is present and valid.
- The XML sitemap lists only new, canonical, indexable URLs.
- Analytics, tag manager, conversion tracking and forms work.
- Core Web Vitals and mobile usability are at least as good as before.
Phase 4: Launch-day checks
Plan launch for a quieter traffic period and a day when the team is available. Take a full backup first. Then:
- Remove staging restrictions and any noindex tags or robots.txt blocks.
- Deploy redirects and test a sample of the top 100 URLs immediately.
- Submit the new XML sitemap in Search Console. For a domain change, verify the new property and use the Change of Address tool.
- Use URL Inspection on the most important pages to confirm Google can fetch them.
- Submit a test lead through every form and confirm it reaches the CRM.
- Check analytics is recording real-time visits.
Phase 5: Monitor
Monitor daily for the first two weeks, weekly for the next two months, and monthly after that. Watch:
- Search Console Page indexing report for spikes in “Not found (404)”, “Page with redirect” or “Excluded by noindex”.
- Crawl stats for errors.
- Organic clicks and impressions compared with the benchmark, by page group.
- Server logs or 404 reports for old URLs that were missed in the map.
- Conversions from organic.
What should a redirect map contain?
The redirect map is the single most important document in a migration. Keep it as one shared sheet, owned by one person, with these columns:
| Column | Purpose | Example |
|---|---|---|
| Old URL | The full current URL | /services/seo-services/ |
| Organic clicks (12 months) | Shows which URLs matter most | 1,240 |
| Referring domains | Shows which URLs carry external links | 18 |
| Decision | Keep, move, merge or retire | Move |
| New URL | The single best destination | /growth/seo-aeo-geo/ |
| Redirect type | 301 or 308 for permanent moves | 301 |
| Tested on staging | Confirms the rule works before launch | Yes |
| Tested after launch | Confirms the rule works in production | Yes |
| Notes | Content changes, merges, owner comments | Merged with /seo-audit/ |
Sort the sheet by clicks and referring domains, so the highest-value URLs are checked first. The figures in the example column are illustrative.
Who should own which parts of a migration?
Migrations go wrong when everyone assumes someone else is checking SEO. Assign named owners before work starts:
- Project lead: owns the timeline, the launch decision and communication with leadership.
- SEO lead: owns the inventory, benchmark, redirect map, staging checks and post-launch monitoring.
- Developer: implements redirects, canonical tags, sitemaps and robots rules, and fixes issues found in testing.
- Content owner: confirms every key page’s content has been carried over or improved, and approves merges.
- Analytics owner: confirms tracking, conversions and CRM integration work on staging and after launch.
Hold a short sign-off meeting before launch. Each owner confirms their checklist is complete. If any item in the “fix before launch” list is still open, delay the launch. A few days’ delay is far cheaper than months of lost visibility.
What should you expect after launch?
Even a well-run migration can see a short dip while Google recrawls and reprocesses the site. The chart below is illustrative, showing the general shape teams often plan for, not data from any specific site.
Planned vs unplanned migration, weeks after launch
If traffic has not begun to recover within a few weeks, look for missing redirects, accidental noindex tags, blocked resources, lost content or a large drop in internal links to key pages.
What are the most common migration mistakes?
- Launching with noindex still in place. A staging setting copied to production can remove a site from search within days.
- Redirecting everything to the home page. Relevance is lost, and Google may treat the redirects as soft 404s.
- Temporary (302) redirects left permanently. Use permanent redirects for permanent moves.
- Removing content to fit a new design. Shorter, prettier pages that drop the text that ranked will lose the queries it answered.
- Forgetting images, PDFs and media. These can carry links and image search traffic too.
- Removing redirects too soon. Old links and bookmarks keep arriving for years. Keep redirects for at least a year, and ideally indefinitely for important URLs.
- No benchmark. Without “before” data, nobody can prove what changed.
What about WordPress migrations specifically?
- If permalinks change, use a redirect plugin or server rules, and import the full redirect map rather than relying on WordPress’s automatic guess for old slugs.
- Check the “Discourage search engines from indexing this site” setting is off after launch.
- Confirm the SEO plugin’s sitemap, canonical and schema settings carried over.
- Re-check custom post types and their rewrite rules, since a theme change can remove them and turn pages into 404s.
- Clear every cache layer (plugin, server and CDN) after launch so visitors and crawlers see the new site.
How do migrations affect AI search visibility?
Google’s AI features use the same index as Search, so pages that are correctly redirected, crawlable and indexed remain eligible, as Google’s AI features documentation explains. Other AI assistants rely on their own crawlers and on third-party sources, so redirects and a consistent brand name across the web matter there too. After a domain change, update your profiles on directories, social platforms and partner sites, as described in our entity SEO guide. Search Console’s generative AI report lets you check whether AI Overviews and AI Mode impressions continue after the move.
Troubleshooting questions after launch
Should I tell Google before I migrate?
There is no need to notify Google in advance. Prepare the redirects, update sitemaps and internal links, and use the Change of Address tool after launch if the domain changes. Google discovers the move by recrawling the old URLs and following the redirects.
What if traffic drops sharply after launch?
Check the basics first: noindex tags, robots.txt rules, missing redirects for top URLs, and whether key content was removed. Use URL Inspection on the pages that lost the most traffic and compare old and new versions side by side. Most sharp drops trace back to one of these causes.
Do I need to update links on other websites?
Redirects handle most of it, but for your most valuable links, such as partner listings and major publications, asking the site owner to update the URL is worthwhile. It removes a redirect hop and protects the link if redirects are ever lost.
If none of these explain the drop, compare the old and new versions of the affected pages for changes in titles, headings, body copy and internal links. Content that was removed or rewritten during the redesign is the next most common cause, and restoring the parts that answered important queries often brings visibility back.
What a migration plan cannot guarantee
A good plan reduces risk; it cannot remove it. Changes to content, structure and design all affect how search engines evaluate pages, and competitors keep moving. Some migrations improve visibility because the new site is faster, clearer and better linked; others take months to recover even when executed carefully. Honest planning sets expectations with leadership before launch, not after. For the foundations to get right on the new site, see our guides on site architecture and internal linking, Core Web Vitals and the SEO audit checklist.
Frequently asked questions
How long does SEO recovery take after a migration?
Google says most pages of a medium-sized site can move in its index within a few weeks, with larger sites taking longer. Many well-planned migrations return to benchmark within one to three months, but there is no fixed timeline.
Should I use 301 or 308 redirects?
Both are permanent redirects that Google treats as a strong signal that the new URL should be canonical. 301 is the most widely used and supported; 308 preserves the request method. Either is fine for a site move.
Can I remove old redirects after a year?
Google recommends keeping them for at least one year. Because old links, bookmarks and citations continue to send visitors, keeping redirects for important URLs indefinitely is the safer choice.
Should I change domain and redesign at the same time?
Where possible, separate them. Changing several big things at once makes it hard to diagnose problems. If they must happen together, plan and test even more carefully.
Do I need the Change of Address tool?
Use it when moving from one domain to another. It is not needed for URL changes within the same domain or for an HTTP to HTTPS move.
What is the single most important migration task?
The redirect map. Every valuable old URL mapped to its best new equivalent, tested before and after launch, prevents most migration losses.
Sources and further reading
- Google Search Central: Site moves with URL changes.
- Google Search Central: Redirects and Google Search.
- Search Console Help: Change of Address tool.
- Google Search Central: AI features and your website.
Planning a redesign, replatform or domain change? Bargaon’s website development service builds the redirect map and staging tests into the project plan, and our technical SEO service runs launch checks and post-launch monitoring.