A website migration can wipe out months of organic growth in a weekend. Most losses come from missed redirects, broken canonicals, orphaned pages, and tracking gaps, not from anything mysterious.
Good website migration SEO starts long before launch day. If you’re changing domain, platform, design, or URL structure, treat the move like an operations project with a baseline, a fixed scope, and clear checks at every stage.
Start with the pages, signals, and conversions you can’t afford to lose.
Start with scope, owners and a baseline
The first job is to define what is changing. A migration might mean a new domain, a new CMS, a redesign, a move to HTTPS, a shift in URL structure, or all of them at once. Each extra change adds risk, so keep the scope as tight as possible.
Name one person to own the migration. Then give clear responsibilities to SEO, development, content, design, analytics, and paid media. If nobody owns the handover points, small misses stack up fast.
Next, crawl the current site and save everything. Export URLs, status codes, page titles, H1s, canonical tags, meta robots, internal links, XML sitemaps, image files, PDFs, and structured data where possible. Also keep copies of robots.txt, redirect rules, analytics settings, and Google Search Console access.
Your baseline should cover traffic and business outcomes, not only rankings. Pull at least 28 days of data, and use 90 days or year-on-year figures if seasonality matters.
Use this benchmark table before anyone touches templates or URLs:
| KPI | Why it matters | Where to pull it |
|---|---|---|
| Organic sessions by landing page | Shows which pages already attract search traffic | GA4 or your analytics platform |
| Organic conversions or revenue | Protects leads and sales, not only visits | GA4, CRM, eCommerce reports |
| Search Console clicks and impressions | Shows visibility by page and query | Google Search Console |
| Indexed pages | Flags noindex mistakes or crawl blocks after launch | Search Console Pages report |
| Top linked pages and referring domains | Protects backlink equity | Link tool plus Search Console |
| Crawlable 200 URLs | Forms the basis of your redirect map | Site crawl export |
Keep this baseline in a shared document. When traffic moves after launch, you need numbers everyone trusts. For another pre-launch sense check, Semrush has a useful website migration checklist.
Audit the pages that carry rankings, links and sales
Not every page deserves the same level of protection. Your homepage matters, but so do service pages, category pages, high-ranking guides, location pages, product pages, PDF assets, and any URL with strong backlinks.
Start by tagging pages into three groups. First, pages that drive organic traffic. Second, pages that convert. Third, pages that attract links or brand trust. Some URLs will sit in all three groups, and those pages need the most careful handling.
Preserve search intent on those high-value pages. If a service page ranks because it clearly answers a local query, don’t turn it into thin brand copy during the redesign. If a category page ranks because it has strong filters, copy, and internal links, keep that structure intact on the new site.
This is also the point to record what each page needs to keep. That includes title tags, meta descriptions, H1s, body copy, image alt text, schema, breadcrumbs, internal anchors, canonicals, and indexation rules. If the site has hreflang, pagination, or faceted navigation, document those too.
If a page brings links, leads, or rankings, treat it as an asset, not old clutter.
Be careful with content pruning. Teams often delete older pages during a redesign because they look dated. That can work, but only when the page has no meaningful traffic, links, or conversion value. If two pages cover the same intent, merge them into the stronger destination and redirect the weaker URL properly.
In 2026, this matters even more on JavaScript-heavy builds. Google can render a lot, but key content still needs to load clearly and quickly. If headings, links, and product text only appear after delayed scripts, crawling and indexing can suffer. Check rendered HTML, not only what the design looks like in the browser.
Map URLs and redirects before anyone touches launch
The redirect map is the heart of a safe migration. Every important old URL needs a clear destination on the new site. Without that map, rankings, backlinks, and indexed pages start to leak almost at once.
Aim for one-to-one 301 redirects wherever possible. Each old page should point to the closest new equivalent, not a category page that feels “near enough” and not the homepage by default. Google can follow redirects, but relevance still matters. Users notice weak matches as well.
A few redirect rules make most migrations safer:
- Map every live, indexable old URL to one best new URL.
- Use 301 redirects for permanent moves, and keep 302s for short-term tests only.
- Redirect files with value too, including PDFs and image URLs that attract links.
- Avoid redirect chains, loops, mixed protocol hops, and internal links that still hit old URLs.
- Use 410 only when a page has no replacement and no business value worth preserving.
Here is the kind of thinking you want. If /services/seo-audit becomes /seo/technical-audit, that can work if the new page covers the same intent and carries the same core value. If an old blog post merges into a broader guide, redirect it to the exact section or the consolidated page, not to a blog index.
Keep the old domain and hosting live long enough to serve redirects. If the domain changes, don’t switch it off once the new site is online. Leave those 301s running for the long term.
Also update links you control. Change navigation, footer links, XML sitemaps, email signatures, paid landing pages, social profiles, and Google Business Profile links to the final URLs. Marcel Digital has a solid SEO website migration checklist if you want another way to pressure-test your redirect plan.
Build a staging site that matches production
A staging site should behave like the real site, not like a rough preview. If templates, canonicals, or navigation work one way on staging and another way in production, your checks lose value.
Protect staging with a password and add noindex rules. Do both. Robots.txt alone doesn’t stop indexing if a URL is discovered elsewhere. A staging environment that slips into Google’s index can create duplicate pages, wrong canonicals, and a mess in Search Console.
Run a full crawl on staging before launch. Check status codes, canonical tags, meta robots, XML sitemaps, internal links, structured data, breadcrumb markup, and mobile rendering. Confirm that canonicals point to the final new URLs, not back to the old site and not to staging URLs.
Your XML sitemap should list only indexable 200 URLs. Keep noindex pages, redirected pages, parameter URLs, and canonicals-out pages out of it. Google uses the sitemap as a hint, so sloppy sitemap entries waste crawl attention and make debugging harder.
Internal linking matters more than many teams expect. Update menus, breadcrumbs, related content blocks, XML feeds, and contextual links so they point straight to the new URLs. Internal links that bounce through redirects waste crawl budget and hide template mistakes.
Check analytics before launch as well. GA4, conversion events, consent mode, CRM handoffs, call tracking, checkout tracking, and form tracking all need testing on staging or in a safe pre-production setup. A migration that keeps rankings but breaks lead tracking still leaves you blind.
For domain moves, set up the new property in Google Search Console early. If you need a practical reminder to crawl the live site first and keep exports handy during QA, this Tech SEO migration discussion makes the same point.
Handle launch day like a controlled release
Launch day should feel boring. That is a good sign. The aim is not drama or a grand reveal, it is a clean handover with as few moving parts as possible.
Pick a quieter trading period if you can. Freeze non-essential content edits, plugin installs, and design changes a few days before launch. If DNS records will change, lower the TTL in advance so updates propagate faster.
Once the site is live, check the basics straight away. Load the homepage, a service page, a product or category page, a blog page, and a contact page. Confirm they return 200 status codes, load over HTTPS, and show the expected canonical tags. Then test a sample of high-value redirects from your mapping sheet.
After that, review robots.txt, XML sitemaps, and indexation rules. Remove launch blocks from production, but keep staging blocked. Submit the new sitemap in Google Search Console. If the migration includes a domain change, use Search Console’s Change of Address tool as well.
Track analytics from the first visit. Open real-time or equivalent reports and confirm sessions, page views, conversions, and revenue events appear as expected. Also test forms, checkout, phone links, chat tools, and CRM integrations.
Keep old certificates, CDN rules, and redirect infrastructure active. Many post-launch issues come from expired settings outside the CMS. A perfect set of redirects won’t help if the old domain stops resolving.
Launch day is for controlled checks and fixes, not last-minute rewrites.
What to monitor after launch
Some fluctuation is normal after a migration. Google has to re-crawl, process redirects, and re-evaluate signals. Small movement in the first days doesn’t always mean something is wrong. Sharp drops on key pages, however, need attention fast. Reviewing performance data alongside practical SEO recommendations can help teams prioritise fixes based on the issues that have the greatest impact on visibility and traffic.
Look at page groups before you look at site-wide averages. If all service pages fall, check templates, canonicals, internal links, or noindex rules. If blog traffic drops but commercial pages hold steady, review content migrations, category changes, and missing redirects.
This post-launch table helps keep the team focused:
| Signal | First 72 hours | First 30 days |
|---|---|---|
| Indexation | Inspect priority URLs in Search Console and confirm sitemap processing | Watch indexed page trends and investigate sharp drops |
| Errors | Review 404s, 5xx errors, and failed redirects daily | Fix recurring patterns and re-test affected templates |
| Organic landing pages | Compare top pages against the baseline | Compare 7-day and 28-day trends, including year-on-year where useful |
| Conversions and revenue | Check forms, calls, leads, and transactions | Compare conversion rate by landing page and device |
| Canonicals and internal links | Re-crawl priority sections to catch mismatches | Re-crawl the full site after fixes land |
| Backlinked URLs | Watch valuable old URLs for 404s or weak redirect targets | Update controlled external links and reclaim missed ones |
Google Search Console is your first stop after launch. Watch the Pages report, sitemap status, performance trends, and URL Inspection results. If you have access to server logs, review bot activity too. Logs show whether Googlebot is spending time on the right URLs or getting stuck in old paths and error pages.
Monitor conversions as closely as rankings. A migration can hold traffic steady whilst quietly damaging lead flow with broken forms, cookie banner issues, or missing checkout events. Protecting rankings matters, but protecting revenue matters more.
Keep the first two weeks tight. Check daily, fix fast, and annotate every change in analytics. After that, move to weekly review until traffic, indexed pages, and conversions settle near baseline.
A concise website migration checklist
Use this list as a sign-off sheet before, during, and after launch:
- Define the migration type, scope, owners, freeze dates, and success measures.
- Crawl the live site and export URLs, metadata, canonicals, indexation rules, internal links, images, and files.
- Benchmark organic traffic, clicks, indexed pages, backlinks, and conversion data.
- Mark priority pages by traffic, links, revenue, and brand value.
- Map every old URL to the best new destination before development signs off.
- Keep high-value content intent, titles, headings, schema, and internal links intact where possible.
- Build staging to match production and block it with password protection plus noindex.
- Check canonicals, robots.txt, XML sitemaps, hreflang, structured data, and HTTPS on staging.
- Add GA4, CRM tracking, form tracking, and Google Search Console access before launch.
- Launch in a controlled window and test priority redirects, page templates, forms, and checkout paths.
- Submit the XML sitemap and use Change of Address if the domain changes.
- Monitor Search Console, analytics, crawl errors, backlinks, and conversions daily, then fix the highest-impact issues first.
Keep this checklist in the project ticket, not buried in email. The best migrations are the ones where everyone works from the same sheet.
Final thoughts
Website migrations usually lose traffic in the gaps between teams, not because Google dislikes change. A solid baseline, a careful URL map, protected high-value pages, and disciplined post-launch checks keep those gaps small.
The safest move is a controlled one. If you can account for every important URL, link, indexed page, and conversion before launch, you’ve already done most of the work that protects SEO performance afterwards. Many agencies, including BBMM, emphasise structured migration planning because consistent processes often reduce the risk of avoidable SEO issues during complex website changes.
Frequently Asked Question:
1. What is the biggest SEO risk during a website migration?
The biggest risk is losing important SEO signals through missing redirects, broken internal links, incorrect canonicals, or blocked pages. Careful planning and testing help preserve rankings, traffic, and conversions.
2. Why should every old URL have a matching redirect?
A one-to-one 301 redirect sends users and search engines to the most relevant new page. It helps retain ranking signals, protects backlinks, reduces errors, and creates a smoother browsing experience after migration.
3. What should be tested before launching a migrated website?
Test redirects, canonical tags, XML sitemaps, robots.txt, analytics, forms, internal links, and page status codes. Finding and fixing issues before launch reduces the chance of traffic and tracking problems.
4. How long should a website be monitored after migration?
Monitor the site closely for at least two to four weeks. Review indexing, crawl errors, organic traffic, redirects, and conversions regularly so any unexpected issues can be identified and resolved before they affect performance.
5. Is it safe to remove old pages during a website migration?
Removing pages is only safe if they have no useful traffic, backlinks, or business value. Valuable content should be merged carefully and redirected to the closest relevant page to preserve SEO performance and user experience.
