A website migration done poorly can destroy years of SEO work in days. This step-by-step guide covers the pre-migration checklist, redirect strategy, common mistakes, and how to validate that rankings are preserved after launch.
Corey Fry
A website migration done poorly can destroy years of SEO work in days. Rankings that took 18 months to build can vanish within a week of a botched launch, and recovering them takes months more.
Done correctly, a migration preserves your existing rankings and — if you are moving to a faster, better-structured platform — typically improves them within 60–120 days.
This guide covers the complete migration process: pre-migration preparation, redirect strategy, common mistakes, post-migration validation, and what to expect on the timeline.
Use Screaming Frog, Sitebulb, or a similar crawler to crawl your entire site and export a complete URL list. This is your source of truth for everything that needs to be migrated or redirected.
The crawl should capture:
Save this export. You will refer to it constantly throughout the project.
Export from Google Search Console:
This data tells you which pages matter most for SEO and where Google's current understanding of your site stands.
Before migration, capture keyword rankings for your most important terms. Use a tool like Ahrefs, SEMrush, or even a manual Google search in an incognito window. Document:
This becomes your post-migration comparison baseline.
Create a redirect map: a spreadsheet with the old URL in one column and the new URL in the other. Every URL from your crawl export that is changing needs a row in this map.
If URLs are not changing (same domain, same slug structure), you still need to verify each one is live and accessible on the new platform.
The easiest migration from an SEO perspective is one where URLs do not change. If you are moving from WordPress to Next.js but keeping the same domain and the same slugs (/services/accounting, /about, /blog/post-title), Google's indexed URLs remain valid.
Sometimes a migration involves restructuring URLs — for example, moving from /page/about-us to /about, or changing blog post structures. In these cases:
Rule: Every old URL that changes must 301 redirect to the new equivalent URL.
A 301 redirect tells Google: "This page has permanently moved to this new location." Google transfers the ranking signals (the "link equity") from the old URL to the new one. Without a 301 redirect, that page effectively starts from zero in Google's index.
Never use 302 redirects for permanent changes. A 302 is a temporary redirect — Google does not transfer ranking signals through temporary redirects.
A redirect chain is when URL A redirects to URL B which redirects to URL C. Chains dilute the link equity transfer and slow page load. If your old site already has redirect chains, clean them up in the new site so every old URL redirects directly to its final destination.
Maintain your redirect map in a shared spreadsheet and keep it updated throughout development. Before launch, validate every row — test that each old URL redirects to exactly the right new URL with a 301 status code.
Every page that has a meta title and description on the old site should have the same (or improved) meta title and description on the new site. Do not launch with blank meta tags — Google uses them for search snippets.
Carry the meta data from your crawl export into your CMS or code.
Preserve your H1 headings from the old site on the new site. If you are improving content, the H1 should still contain the primary keyword — do not remove keyword signals while redesigning.
Your internal link structure contributes to how Google understands the relationship between your pages. A significant change to internal linking (removing links from the homepage to service pages, for example) can affect the ranking of those service pages.
Review the internal link report from your crawl export and ensure the new site maintains links between important pages.
If your old site had LocalBusiness, FAQ, or other schema markup, recreate it on the new site. Schema markup is a positive SEO signal — migrating without it means starting over on those rich result eligibility signals.
For schema details: the WebHouz Next.js sites ship with JSON-LD schema built into page components.
Run through this list before flipping DNS:
For the performance audit process: How to audit your website speed
Do not develop the new site on the live domain. Use a staging URL (staging.yourdomain.com or a temporary URL on the new host) with a noindex tag to prevent Google from indexing the staging version.
Only remove the noindex tag and flip DNS after the new site is fully tested and validated.
When you flip DNS, the new site goes live. Within the first hour:
Immediately after launch, submit the new XML sitemap to Google Search Console. This prompts Google to start crawling the new site.
Also use the URL Inspection tool in Search Console to request indexing on your 5 most important pages.
Days 1–7: Google's crawlers will begin discovering and re-indexing your new URLs. You may see temporary ranking fluctuations — some pages may drop briefly as Google processes the migration. This is normal.
Weeks 2–4: Most redirects will have been followed and link equity transferred. Rankings typically stabilise at or above pre-migration levels for pages with clean redirects.
Weeks 4–12: The full benefit of any performance improvements becomes visible in field data (CrUX) and may contribute to ranking improvements. Google's Core Web Vitals assessment updates on a 28-day rolling window.
Month 3–4: If you have migrated to a significantly faster platform, ranking improvements from the performance upgrade typically become visible during this period.
If you see rankings drop more than 30% across multiple pages within the first 30 days:
The most common and most damaging mistake. Even one or two important pages without redirects can cause significant ranking loss.
The staging site had a noindex tag. If it was not removed before launch, Google will deindex the entire site. Check this is removed — it is easy to miss.
Changing platform, design, content, and URL structure simultaneously makes it impossible to diagnose what caused any ranking changes. Where possible, separate the migration from content updates — migrate first, then improve content.
A migration that improves desktop speed without addressing mobile performance misses the majority of SEO impact. Google indexes and ranks based on mobile.
If Search Console is not configured before launch, you miss the baseline data and the early indexing reports. Set it up at least two weeks before migration.
For a clean migration with proper redirects and no technical issues, most rankings stabilise within 2–4 weeks. Full recovery or improvement typically takes 6–12 weeks as Google fully processes the redirect chain and recrawls all pages.
No. Changing both simultaneously doubles the variables and makes diagnosis difficult. If you need to change both, change the platform first (same domain), verify rankings are stable, then change the domain with a separate migration.
Not if done correctly. The redirect structure, canonical tags, and content must all be preserved. The performance improvements from moving to Next.js typically help rankings over the 60–120 days post-launch.
Prioritise by traffic. Your crawl export plus Search Console performance data will tell you which pages have meaningful traffic and rankings. Redirect those carefully. Lower-traffic pages without meaningful rankings can be consolidated or allowed to 404 if the content is genuinely no longer relevant.
Website migration service — if you want professional help managing the SEO aspects of a platform migration. When should you redesign your website? — if you are still deciding whether a migration is warranted. Next.js development — if you are considering moving to a modern framework.
Let's talk about your project and how we can help you build a website that actually performs.