TL;DR:
- Site migration involves major website changes that can threaten search rankings if mishandled. Proper planning with a detailed checklist and staged testing ensures redirects, internal links, and analytics remain intact, safeguarding SEO and traffic during the process.
Site migration is defined as any significant change to a website’s URL structure, domain, platform, hosting environment, or content architecture that requires careful planning to protect search rankings and user experience. For business owners and digital marketers, the stakes are high. A poorly managed migration can wipe out years of accumulated SEO authority within days. This guide answers the most common site migration FAQs with direct, practical answers grounded in UK best practices, covering everything from your site migration checklist to post-launch monitoring.
What counts as a site migration?
Site migration covers a broader range of changes than most business owners expect. The term is the recognised industry label for any structural website change that search engines must re-learn. Understanding the full scope is the first step in managing the risk.
Common migration types include:
- Domain change: Moving from one domain to another, such as rebranding from an old trading name to a new one.
- Protocol change: Switching from HTTP to HTTPS, which remains one of the most frequent and underestimated migrations.
- Platform change: Moving from one CMS to another, for example from a bespoke PHP build to WordPress.
- URL restructure: Changing how page addresses are formatted, such as removing dates from blog post URLs.
- Content redesign: Reorganising site architecture, merging sections, or splitting categories.
- Internationalisation: Adding subdirectories or subdomains for different languages or regions, such as
/en-gb/or/fr/. - Hosting change: Moving servers, which affects load times and geographic targeting even when nothing else changes.
Each type carries its own risk profile. A protocol change is technically straightforward but breaks every existing inbound link if redirects are not in place. A platform change combined with a URL restructure is the highest-risk combination, because you are changing multiple variables at once. Wherever possible, isolate changes to one variable at a time.
Why does planning make or break a migration?
Rushing site migration preparation is the leading cause of failure. UK experts recommend a minimum of 4–6 weeks of planning for most sites, and longer for complex or high-traffic properties. That timeline is not arbitrary. It reflects the time needed to crawl the existing site thoroughly, map every URL to its new destination, and test redirects before a single change goes live.
A proper pre-migration phase includes these numbered steps:
- Full site crawl: Use a crawl tool to capture every indexed URL, including legacy pages, PDFs, and image assets.
- Redirect mapping: Match every old URL to its closest relevant new URL. This is the most labour-intensive task in the entire process.
- Backlink audit: Identify which pages carry the most inbound links. These pages need priority attention in your redirect map.
- Internal link review: Document your site architecture before migration so you can replicate the internal linking structure on the new site.
- Staging environment setup: Build and test the new site in a non-public environment before launch.
- Analytics verification: Confirm that tracking tags are correctly installed on the staging build.
- Stakeholder sign-off: Get written confirmation from all teams, including development, marketing, and leadership, before setting a launch date.
Compressing this phase leads to errors that are genuinely difficult to diagnose after launch. You cannot easily tell whether a traffic drop is caused by a missing redirect, a broken analytics tag, or normal post-migration volatility if you skipped the baseline checks.
Pro Tip: Run your full site crawl twice: once at the start of the planning phase to build your URL inventory, and once on the staging site before launch to confirm every redirect resolves correctly.
How do you protect SEO and traffic during a migration?
SEO protection during a migration comes down to one-to-one redirect accuracy, staging site discipline, and launch-day monitoring. Each of these deserves specific attention.
Redirect mapping and testing
Missing redirects or redirect chains cause ranking drops of 10–20% initially post-migration. A redirect chain occurs when URL A redirects to URL B, which redirects to URL C. Each additional hop dilutes link equity and adds latency. Flatten every redirect to a single hop from old URL to final destination.
Redirects may be configured at multiple infrastructure layers, including CDN, firewall, and application code. Testing must confirm end-to-end redirect behaviour from the public edge to the origin server, not just within the CMS.
Staging site discipline
Staging environments must be non-indexable using layered protections. Robots.txt alone is not sufficient. Combine password protection or IP restrictions with noindex meta tags and a strict robots.txt disallow rule, then confirm the setup with a crawl test before launch.
Launch-day monitoring
The following checks must happen within hours of going live:
- Confirm the site is publicly accessible and returning 200 status codes on key pages.
- Verify that a sample of redirects resolve correctly in a browser and return 301 status codes.
- Submit the updated XML sitemap to Google Search Console.
- Confirm that analytics tracking is firing on live pages.
Analytics tracking code commonly fails to carry over during cutover, creating data blackouts at critical moments. A team without reliable analytics during launch cannot distinguish a genuine traffic collapse from expected post-migration volatility.
Pro Tip: Set up a simple spreadsheet of 20–30 critical URLs before launch. Check each one manually within the first two hours after go-live. It takes 15 minutes and catches the majority of hard failures before they compound.
| Check | When | Tool |
|---|---|---|
| Redirect accuracy | Pre-launch and launch day | Crawl tool or browser |
| Staging non-indexability | Pre-launch | Crawl tool and robots.txt tester |
| Sitemap submission | Within 1 hour of launch | Google Search Console |
| Analytics tracking | Within 2 hours of launch | Tag verification tool |
| Core Web Vitals baseline | Within 48 hours of launch | Google Search Console |
Common site migration questions answered
These are the questions business owners and marketers ask most often once a migration is underway.
Should I delete low-performing pages during the migration? No. Content pruning and migration should be separated wherever possible. Deleting pages at the same time as restructuring URLs makes it impossible to isolate the cause of any ranking changes. Prune before or after the migration, not during.
What is the best time to launch a migration? Launch on a Tuesday, Wednesday, or Thursday morning, when your development and marketing teams are fully available. Avoid Fridays, bank holidays, and peak trading periods. You need people available to respond quickly if something goes wrong.
Does hosting location affect SEO? Yes. UK businesses benefit from UK or European hosting to reduce latency and support geographic targeting. Moving servers overseas increases page load times and can degrade Core Web Vitals scores, both of which affect search rankings.
How long will rankings take to recover? Expect some volatility for 4–8 weeks after a well-executed migration. A staggered migration approach with phased deployments reduces volatility for most change types. Full rebrands tend to perform better as clean breaks rather than phased rollouts.
What if I notice a sharp traffic drop after launch? Check your redirect map for missing entries, verify analytics is tracking correctly, and confirm your sitemap has been submitted. Do not make additional structural changes until you have identified the root cause.
Key takeaways
A successful site migration requires one-to-one 301 redirects, layered staging site controls, and launch-day monitoring to protect SEO rankings and traffic.
| Point | Details |
|---|---|
| Plan for 4–6 weeks minimum | Rushing pre-migration tasks is the leading cause of post-launch failures. |
| Flatten all redirects to one hop | Redirect chains dilute link equity and slow page load times. |
| Layer staging site protections | Combine noindex tags, robots.txt rules, and access restrictions to prevent accidental indexing. |
| Monitor analytics from hour one | Tracking failures during cutover create data gaps that make diagnosis impossible. |
| Separate content pruning from migration | Deleting pages during a migration makes it impossible to isolate ranking causes. |
What most migration guides get wrong
Site migrations fail far more often because of communication breakdowns than technical errors. I have seen agencies deliver technically perfect redirect maps only to watch the client’s developer deploy the new site without implementing them. The redirect map existed. Nobody confirmed it was actually applied.
The pre-migration phase is where most errors are prevented, and the majority of that work is coordination, not code. Who owns the redirect implementation? Who signs off on the staging crawl? Who monitors analytics on launch day? If those questions do not have named answers before the migration starts, the technical work is largely wasted.
The other thing I see consistently underestimated is internal link equity. Marketers focus on inbound links from external sites, which is correct, but navigation changes and taxonomy restructures quietly damage the internal authority flows that support your most important pages. Document your internal linking structure before you touch anything. It takes an hour and saves weeks of recovery work.
Post-migration monitoring is not a one-day task. Set a calendar reminder for four weeks after launch to review rankings, crawl errors, and Core Web Vitals. That is typically when the full picture of migration impact becomes clear, and when you still have time to act before any damage compounds.
— Marcel
How Wpcto handles WordPress site migrations for agencies
Wpcto manages the full migration process for WordPress sites on behalf of UK design and digital agencies, covering redirect mapping, staging site setup, SEO protection, and post-launch monitoring. Agencies hand over the technical delivery and keep the client relationship intact.
If you manage WordPress sites for clients and want to understand the revenue sitting in your existing base, the WordPress Profit Calculator gives you a clear figure in under 90 seconds. For agencies ready to remove WordPress migrations from their workload entirely, Wpcto’s agency support services cover everything from pre-migration audits to post-launch care plans.
FAQ
What is a site migration in SEO terms?
A site migration is any significant change to a website’s URL structure, domain, platform, or hosting that requires search engines to re-index the site. Without proper redirects and planning, migrations cause ranking drops and traffic loss.
How long does a site migration take to plan?
UK experts recommend a minimum of 4–6 weeks for planning, covering crawling, redirect mapping, and staging tests. Complex or high-traffic sites require longer.
Do 301 redirects fully preserve link equity?
A correctly implemented 301 redirect passes the majority of link equity to the new URL. Redirect chains reduce that transfer, so flattening all redirects to a single hop is best practice.
Should I migrate and redesign my site at the same time?
Separating migrations from redesigns reduces risk. Changing multiple variables simultaneously makes it difficult to identify the cause of any post-launch ranking changes.
How do I check if my staging site is being indexed by Google?
Use a site: search in Google for your staging domain, and run a crawl tool against the staging URL to confirm noindex tags and robots.txt rules are working correctly. Layered controls combining password protection, noindex meta tags, and robots.txt are the only reliable approach.