If you're reading this, you're probably close to going through a website migration.
Advice number one: don't panic. I know this is one of the biggest nightmares of any SEO or digital marketer. But there are multiple ways to mitigate the performance impact.
Fortunately (or unfortunately), I've gone through several website migrations, including domains with millions of pages, where the organic channel represented the biggest share of traffic and revenue across the whole website.
My personal history includes migrations of websites like Indie Campers, Worten and Carro. These 3 went really well, but I've also experienced migrations that went out of control, for several reasons I'll go through later.
So, I know every best practice, but also everything you must avoid, so you don't wake up the morning after with your Google Analytics crying for help.
And no matter if it's a simple theme change, a migration to a new CMS or a move to a vibe-coded solution, this SEO migration guide is helpful in every scenario.
Key Takeaways
Best practices: Keep the root domain and every URL identical whenever you can, and map all your URLs before development starts.
Why most website migrations go wrong: They're rushed by deadline pressure or only audited after launch, when some issues are already too late to fix.
Mistakes to avoid: Not mapping all your URLs before the migration, making drastic changes to the URL hierarchy, not redirecting deprecated URLs, breaking canonical tags and the heading structure of pages that were performing well.
Mandatory technical SEO audits: Run 15 checks on staging, starting with heading structure, content parity, meta tags, self-referencing canonicals and meta robots. The other 10 are covered in detail in this guide.
Why staging is so important: It's the private copy of the new website where you can find and fix problems before your visitors, Google and AI search engines like ChatGPT ever see them.
Avoid changing URLs: This is the most important tip in this guide article. Each page builds up its history over the years and that history is tied to its exact address. Even with 301 redirects in place, crawlers still have to find and process every new URL, and that can lead to ranking drops.
If you need support during migration: The team behind the Indie Campers, Carro and Worten migrations can audit your staging build before it goes live. See how Reach can help you migrate and grow organic visibility.
No Time To Read? Here's a Quick SEO Migration Checklist
If you're wondering how to do an SEO migration without reading the whole guide, this is the short version.
Each item is explained in the steps below.
Why Migrations Can Be Organic’s Worse Enemy
A website migration touches everything search engines use to understand your website at once: URLs, page templates, internal links, rendering, metadata and the server configuration behind it. Any of those can break without anyone noticing it on the page.
Google Search works in three stages: it crawls pages it discovers through links and sitemaps, indexes them by picking one canonical version among similar pages, and serves the most relevant ones in results. A migration resets all three at once, and Google doesn't guarantee any page will make it through each stage again.
Every ranking signal is attached to an exact URL. Backlinks point to it, Google has years of ranking history stored against it, and AI engines have it saved as a citation.
A 301 redirect passes most of that along. But Google still has to recrawl the old URL, follow the redirect and process the new one. Multiply that by thousands of URLs and rankings can take weeks to settle.
AI search adds another layer of complexity.
Engines like ChatGPT, Perplexity and Claude rely heavily on search engines to get real-time information while building an answer, a process known as retrieval-augmented generation (RAG). If the URLs that were driving many of your citations start returning 404s or disappear from search results, LLMs stop finding them, and your AI search visibility can drop with them.
Then there are the silent failures. A Disallow: / copied from staging, a noindex left in a template or canonical tags still pointing to the staging domain are invisible to anyone browsing the new website, since they only exist in the code. The website looks perfect while it disappears from search results.
And migrations rarely come alone. They usually arrive together with a redesign, a new navigation strategy and content changes, so when traffic drops, nobody knows which change caused it.
That's why migrations have such a bad reputation among SEOs, and why the recovery usually takes longer than the fall. A solid SEO migration strategy catches almost all of these issues before launch.
How To Plan a Website Migration SEO-Friendly: Step-by-Step
These are the website migration SEO steps I follow on every project, from the first meeting to the weeks after launch.
1. Get to know every person involved during the website migration
Especially in larger companies, every team will try to look after its own interests.
The design team will suggest changing page layouts, only thinking about making the page look pretty, without following any SEO best practices. The CRO team might consider changing the categories in the menu, without knowing the negative organic impact of removing those important internal links. Or an online sales member might ask to remove landing pages that don't make sense to have anymore, without configuring redirects to preserve all the organic strength of those pages.
And the problem is not them. They don't need to be SEO experts. It's also your responsibility to educate them.
So, it's very important in this phase to work on your own "PR" inside the company, by making clear to everybody the current impact of organic on website traffic and revenue, so everyone understands the risk of making decisions without you being involved.
Everyone needs to understand in this phase that you need to be part of the discussions, especially when larger changes to the website are being considered.
A practical way to do it is to share a short set of migration guidelines with every team before design starts. Ours cover URLs, page structure, meta information, canonicals, the XML sitemap, rendering, crawler access and tracking, each with a short explanation of why it matters for Google and AI search.
The rule was easy to follow by anyone in the company: any change to a URL or a template had to be validated with us first.
2. Map all the pages performing well on organic search
Ideally, no URLs should be changed during migrations. The root domain and URLs must stay identical, character for character.
It's possible to work on onsite navigation improvements or website redesigns without touching the hierarchy of your URLs. That should be your number one priority.
Watch for the URL changes that happen without anyone deciding to make them: a CMS that lowercases slugs, a blog moving from /blog/ to /resources/, a date folder added to article paths, or a trailing slash added or dropped sitewide.
However, when you migrate to platforms like Shopify, there are some folders that need to be respected. For example, product pages will by default be inside /products/ and category pages inside /collections/. In these cases, 301 redirects must be configured.
From the beginning, you need to prepare a spreadsheet that lists all the URLs on the current website and their current status in the migration. This will guarantee that no page is forgotten.
In cases where URL changes cannot be avoided, add a column to your spreadsheet identifying the corresponding new URL for each page, so you list all the 301 redirects needed.
On larger websites, it's very important to pick 5 to 10 URLs of every page type (e.g. category pages, use case pages, product pages, etc.), so you can run dedicated analyses on each of them. Technical issues usually affect multiple pages at once, not just a single page.
This is also the moment to record your benchmark. Export organic traffic, conversions, revenue, keyword rankings, indexed pages and AI search citations for the months before the migration. Without that baseline, your SEO migration plan has nothing to be measured against.
3. Make all the validations on a staging environment before the go-live
In the next section, I'll share some of the most important audits to run when working on a website migration.
However, make sure all of these analyses are conducted in a testing environment, and not only after the new website goes live. The staging environment allows you to find issues before the live website gets affected, so once the migration happens, the chances of something going wrong are lower.
And please make sure all staging environment pages have a noindex tag, to avoid staging URLs getting indexed and competing with your live pages in search results.
Password protection is even safer, since it also keeps the unfinished build away from anyone who finds the URL. On a recent migration, the staging build was open with index, follow, so that was the first issue we flagged.
At launch, do the opposite: remove the noindex and any Disallow: / from the production build. A staging directive that reaches production can remove a website from search results within days.
Staging is also where you crawl the current website and the new build side by side, comparing URLs, titles, meta descriptions, canonicals, heading structure, schema and status codes. Anything that comes back different gets fixed before launch.
4. SEO website migration audits you must run (15 mandatory analyses during staging)
These are the SEO website migration audits I run on every project.
Most of them come from issues I found in real migrations, so I'll share examples along the way.
Heading structure
Check that every page keeps one descriptive H1 and the same H2 and H3 hierarchy it has today. Redesigns often turn headings into styled text or turn design labels into headings.
AI engines pull answers at the section level, so an H2 that becomes a styled div stops being a retrievable block of content. And headings used only for styling add noise to every page they appear on.
On one staging build I audited, the footer column labels were marked up as H2s. Since the footer loads everywhere, every page ended with the same eight generic H2s: Platform, Solutions, Use Cases, Customers, Resources, Guides, Legal and Company.
The fix was a one-line change in the footer component, from <h2> to <p> with the same class, so nothing changed visually.
Content parity
Compare the copy of every ranking page on the current website with its staging version.
Body copy, FAQs, comparison tables and CTAs should all be there, and blog authors and publish dates shouldn't be reset to the migration date.
Copy trimmed to fit a new layout usually removes the specific sentences that were earning rankings and AI citations. A quick way to catch it is comparing word count per URL between the baseline crawl and the staging crawl, then reviewing any page that drops significantly.
Pillar pages like the homepage or pricing can be rewritten, as usually these only rank for branded terms. Everything else should stay word for word during the migration.
Meta tags
Meta titles and meta descriptions need to be migrated page by page, never replaced by a template default or the page name.
Crawl both versions and match titles and descriptions one to one. CMS imports are where this usually breaks, with blank descriptions or titles generated automatically from the H1.
Self-referencing canonicals on every page
Every indexable page needs exactly one canonical tag pointing to itself, with an absolute URL on the production domain. Set it at template level, so new pages inherit it.
The usual rebuild failure is a template that hardcodes the canonical to the homepage, or leaves the staging domain in place. Both can quietly deindex the website while everything looks correct in the browser. Relative canonicals can resolve against the wrong base and cause the same problem.
On one international website, the canonical tags on location pages pointed to old URLs that redirected to the current ones. For example, /en-gb/new-slug/city had its canonical set to /en-gb/old-slug/city. It affected every location page in every market except EN-US, and it also broke the hreflang setup (more on that below).
Meta robots
Check every template for noindex, nosnippet or noimageindex directives, both in the <meta name="robots"> tag. A noindex should only exist where you want it, like thank-you pages or internal search results.
Check every template, not just the homepage. A directive set in a single template or page setting can hide an entire section of the website. I'll share what happened on one launch day in step 5.
Domain consolidation
Search engines should only find one version of each URL. Pick www or non-www, HTTPS, and one trailing slash format, then 301 every other variant to it, sitewide. A canonical tag alone is not enough.
This is easy to miss when you move away from a CMS, because this behavior often lives in the hosting configuration and not in the code. When moving from Webflow to a custom-coded website on Vercel, for example, the www to non-www redirect that Webflow handled had to be rebuilt in Vercel's domain settings before launch.
Automatic XML sitemap
The XML sitemap should be generated automatically and updated whenever content is published or changed. It should only contain indexable URLs that return a 200 status code, with no redirects, noindex pages, 404s or parameter URLs.
Reference it in robots.txt and submit it in Google Search Console and Bing Webmaster Tools.
A clean sitemap is also your diagnostic tool at launch. If the URL count changes, or URLs appear that shouldn't be there, something in the build is generating pages you didn't plan for.
Server-side rendering
Content has to be in the raw HTML that the server returns. The test takes ten seconds: open view-source: on a page and search for a sentence of body copy. If it's not in the source, most crawlers can't read it.
Googlebot executes JavaScript, but on a delay and against a budget, so JavaScript-dependent content gets indexed slower and less reliably. Most AI crawlers, including GPTBot, ClaudeBot and PerplexityBot, don't execute JavaScript at all. They fetch the raw HTML once and work from whatever came back.
Watch for scroll-triggered content injected by JavaScript, modules that start at zero opacity, accordion or tab content fetched on click, and infinite scroll without paginated URLs behind it.
CSS animations on text that is already in the HTML are fine. You can keep the motion, as long as the words exist in the source before the animation runs.
Google and AI crawler access
In this stage, there are two important analyses to complete.
The first one is related to robots.txt. Make sure no important folders or URLs are being disallowed, and that Google, ChatGPT and other bots have access to your website.
Start from the robots.txt that is live today and replicate it, unless there's a reason to change it. A default robots.txt shipped by a new CMS or framework often blocks pages you need crawled. And staging usually runs with Disallow: /, which is right for staging and the most damaging file you can ship to production.
If the new build creates parameter URLs (pagination, filters, currency selectors, tracking IDs), add Disallow rules for them. On one ecommerce website, tracking parameters, currency selectors and ad click IDs were creating thousands of duplicate URLs, so we blocked them in robots.txt.
The second verification is at the hosting and CDN level.
Bot protection on Cloudflare or other CDNs, firewalls and rate limits can block GPTBot, ClaudeBot or PerplexityBot even when robots.txt allows them. Check your CDN's bot settings and your server logs to confirm AI crawlers get 200 responses, instead of 403s or challenge pages.
Schema markup
Every schema type you have today needs to come across to the new templates, whether that's Organization, Product, FAQPage, BreadcrumbList or Article. Validate it, check that it matches the visible content (FAQPage should mirror the FAQs on the page), and confirm that every URL inside it uses the production domain.
If the new build generates schema automatically, compare its output against the current markup before sign-off. Auto-generated schema is often thinner than what's live.
The opposite can happen too. One staging build I audited added a full Organization entity to every page, with ContactPoint, Offer, Service and Audience blocks that had nothing to do with the page itself.
We kept the Organization entity on the homepage only. Every other page references it with an @id, which gives the whole website one company record to resolve against
Hreflangs
If your website has language or region versions, hreflang needs to be bidirectional and self-referencing, include an x-default, and point to the equivalent page in each language instead of the locale homepage. Use full language-country codes when regional variants exist.
Every hreflang target also has to be self-canonical. On the same international website, the hreflang setup looked correct at first glance, but every alternate URL pointed to a page whose canonical referenced a different URL.
On top of that, the website used a generic hreflang="en" next to en-gb and en-ie, which made it unclear which English version was the default. We replaced it with en-us, also used as the x-default.
Redirects
For every URL that changes or disappears, there must be a 301 redirect to the most relevant live page. The homepage is the last resort.
The redirects that already exist on the current website must be migrated too. Over the years, teams add redirects in WordPress plugins, Webflow's redirect settings, Shopify's URL redirects or server configuration files, and none of them come across automatically when you move to a new CMS or a custom-coded website.
Export the full list from the old setup and rebuild every redirect on the new one. Otherwise, old URLs that still carry backlinks and traffic start returning 404s on launch day.
Check that all redirects are 301s (no 302s, 307s or JavaScript redirects), resolve in a single hop and land on a page that returns 200. If the website went through previous migrations, update the old redirects so they point straight to the new final URLs, without chains.
Internal links
Every internal link on the new website should point straight to a live page on its final URL. That includes the navigation menu, the footer, breadcrumbs, buttons and CTAs, and the links inside the body of each page.
Crawl the staging build and list every internal link that returns a 404, goes through a redirect or still points to an old URL. Links in the body copy are the ones most often missed, since they're written into the content and don't update when URLs change or when content is imported into a new CMS.
Then check that the menu and footer still link to the same key pages as before. That's where CRO and design changes tend to cut links.
Core Web Vitals
Test your key pages on mobile against Google's thresholds: LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less. On staging you only have lab data, since field data from real users only arrives after launch, so treat lab results as early warnings.
The most common issues are heavy hero images, unused JavaScript and third-party scripts. On one travel website, real-user LCP on location pages was around 2.4 seconds, but lab tests on mobile showed around 14 seconds.
The hero images were too large for slow connections, and over 700 KiB of JavaScript loaded on each page was never executed. Reducing unused JavaScript and serving compressed, responsive images were the two priorities.
Tracking scripts (eg. Google Analytics, Google Search Console)
Your tracking stack has to be live from the first minute of the new website. Analytics data cannot be recovered afterwards, and without it you can't compare performance before and after the migration.
Start by listing every tool running on the current website: Google Analytics, Google Tag Manager, Google Search Console, ad pixels, your CRM forms and the cookie consent banner. A new website starts with none of them, so each one has to be added again and tested on staging.
Then test the actions that matter to the business. Submit a form, book a demo or complete a purchase on staging, and confirm each one shows up as a conversion in Google Analytics. Conversion tracking breaks easily during migrations, and it often goes unnoticed until someone sees the drop in a monthly report.
Also confirm that Google Search Console still recognizes the new website as yours. Depending on how it was verified, the verification can disappear with the old website, along with access to the reports you'll need in the weeks after launch.
5. Final validation in production
Once the website goes live, the work isn't finished yet.
You must run a final check on most of the technical aspects I covered above, but now on the live website.
Some issues only show up in production. On one migration, after weeks of staging audits, the launch-day crawl found 17 commercial pages carrying noindex, follow, covering entire product sections of the website. Two of them were already ranking before the website migration.
We traced where the directive came from, so it wouldn't come back on pages created later, removed it from all 17 pages, and ran a live URL inspection in Search Console on the two ranking pages to request indexing. Everything was fixed within three days.
The first week after the migration is crucial. Open your Google Analytics and Google Search Console every day to identify unusual fluctuations in the following metrics:
Metric | Why does it matter? | Where to analyse it? |
Organic Traffic | The first sign that rankings or indexing changed. Compare it with the same weekdays before launch. | Google Analytics |
Organic Conversions | Traffic can hold while conversions drop when forms, CTAs or tracking break in the new website. | Google Analytics |
Organic Revenue | Shows whether the pages that bring in money kept their positions. | Google Analytics |
Key Events | Confirms your events are still firing on every template. A drop to zero usually points to tracking, not organic performance. | Google Analytics |
Google Impressions | Reacts before clicks do. A drop shows pages losing visibility or leaving the search index. | Google Search Console |
Google Clicks | Clicks usually drop significantly when meta titles and descriptions change during a migration, even when rankings hold. | Google Search Console |
Google Average Position | Some movement in the first days is expected. A steady decline on key pages is a warning. | Google Search Console |
Google Number of Ranked Keywords | A good signal that pages changed during the migration. A drop usually points to broken subheadings, important keywords removed from meta titles, or pages that disappeared and no longer rank for their search terms. | Google Search Console |
Number of Indexed Pages | A drop points to noindex, canonical or rendering issues. Unexpected growth points to duplicates or parameter URLs. | Google Search Console |
Number of 404 Pages | Each new 404 is a URL missing from the redirect map. | Google Search Console |
Total Crawl Requests | A short spike is normal while Google rediscovers the website. A sustained rise means crawl budget is going to redirects and duplicates. | Google Search Console |
AI Search Citations | AI search trackers show which pages are losing citations. A significant drop on a URL usually points to it being deindexed from search engines, crawlability issues, or content AI crawlers can no longer read. | Reach AI |
After the first week, move to weekly checks for at least the following two months. Search Console data arrives with a delay of a couple of days, and AI citations take even longer to reflect the changes.
Success Stories with Website Migrations
More than just best practices, let me now show you real case studies of brands I've helped with migrations in the past, from ecommerce to SaaS companies.
And in contrast to other case studies I usually share - where I present increases in inbound traffic, organic rankings or revenue - in these SEO migration stories my main performance goal is to make sure everything stays stable, with no huge fluctuations.
Before getting into the details of each case, there's a small (but highly important) detail shared by all these success stories that keeps migrations from becoming a dramatic story: only go live once everything is actually ready to migrate.
CEOs and decision makers tend to pressure their teams to move fast (and that's totally reasonable). But what doesn't make sense is deciding to migrate within a few weeks, without the necessary precautions and tests. This is usually what defines whether a migration goes wrong or not.
Carro: Migration from Webflow to a Custom-Code Solution
Carro has been one of the most fun projects we've worked on at Reach, especially because of how collaborative our relationship with them is.
We have a dedicated case study with them from the first months of work, where we helped them become one of the most cited brands by LLMs in the ecommerce inventory management space (it's worth a look).
By the end of July 2026, Carro's team told us they were planning to refresh the look and feel of the website. And they were counting on us to help them mitigate the impact.
My initial honest thought was something like "Oof, why does everyone want to run website migrations when the projects are going great?". But in the end, it turned out to be an SEO migration success story.
The goal was to migrate from Webflow to a custom code solution. This type of decision is growing in popularity, especially with the rise of vibe coding solutions that enable non-technical people to make changes to websites with prompts.
So this migration had to be done carefully, as we were not dealing with a theme refresh or a migration from one CMS to another. We were talking about migrating from a CMS that has a lot of predefined technical SEO features that make everything much easier, to a solution built from scratch within a few weeks.
We worked together with their team through a period full of audits and late-night fixes. And every hour of effort was worth it.
The migration happened on September 18th, and it was really smooth, as you can see in the screenshot below.
The absolute numbers are hidden, but you can see from the evolution of clicks over time how stable the numbers were.
No drops in Google's organic performance. And the AI visibility numbers didn't drop either.
Several technical SEO issues were also identified and resolved before go-live, including:
Staging build open to indexing: The preview website on Vercel carried an index, follow directive, which risked preview URLs getting indexed and competing with the live website in search results. We blocked it from indexing until launch, and made sure that block didn't reach the production build at cutover.
robots.txt blocking the entire website: The staging robots.txt had Disallow: /, which is correct for a preview environment and would have told every crawler to stay away from the whole website if it reached production. The production file was rebuilt with the disallow removed, rules for paginated URLs and blog tag pages, and a reference to the XML sitemap.
www to non-www redirect missing: Webflow handled this redirect in its hosting configuration, not in the codebase, so it wouldn't come across with the migration. It was rebuilt in Vercel's domain settings as a single-hop 301, so the website wouldn't be duplicated across two hostnames at launch.
Tracking stack missing from the new build: None of the tools running on the live website existed on staging, from Google Tag Manager and Google Analytics to the ad pixels, HubSpot forms and cookie consent banner. Everything was rebuilt and tested before cutover, so there was a clean before and after comparison from day one.
Organization schema on every page: The new templates added a full company description to every page, with details unrelated to the page itself. We kept it on the homepage only and pointed every other page to it with an @id reference.
Footer labels marked up as H2s: Every page ended with the same eight generic H2s from the footer. A one-line change in the footer component fixed it, with no visual difference.
A few other problems were solved, but the first four would have been dramatic if not fixed before go-live.
One more appeared on launch day itself. The production crawl found 17 commercial pages carrying a noindex, two of them already ranking. We removed it and requested indexing for the two ranking pages in Search Console, and everything was fixed within three days.
Indie Campers: Migrating From Country-Level to Same Root Domain
Reach supported one of the largest RV rental companies in the world in migrating from country-level domains to .com. The goal was to consolidate every language under the .com.
The content of the pages was supposed to stay the same, with a very similar navigation hierarchy. But in this case, thousands of URLs had to change from .pt, .es, etc., so we had to make sure all the necessary 301 redirects were properly set up.
It was decided to do a gradual migration, avoiding moving all the domains to the .com at the same time. And for websites of this size, where domains are being changed, it's actually a smart decision.
We were able to flag some important issues that were fixed before they harmed the website, including:
Sitemap not updated with the new URLs: After the new URL structure went live, the XML sitemap kept listing the pre-migration URLs, like /rent-an-rv/usa instead of /discover/en-us/rent-an-rv/usa. Every entry had become a redirect source, and Google's daily crawl requests climbed from around 25-30K to peaks of 100-140K over 90 days. We regenerated the sitemap with the final URLs only and resubmitted it in Google Search Console and Bing Webmaster Tools.
Pages returning 307 temporary redirects: Locale-wide URL patterns, like /discover/en-gb/rent-an-rv/scotland to /discover/en-gb/campervan-hire/scotland, were redirecting with a 307. A temporary redirect tells Google to keep revisiting the old URL instead of consolidating the ranking signals into the new one. All of them were replaced with 301s.
Page rendering issues: The new React location pages served a loading shell in the raw HTML (an orange background with a spinner), and the content only appeared after JavaScript ran. Google Search Console's live test showed the full page, since Google renders JavaScript in a second stage. AI crawlers don't, so for ChatGPT, Claude or Perplexity the location pages were blank. A prerendering layer started serving the full HTML to every bot, not only Googlebot, while server-side rendering was implemented.
Hreflang pointing to non-canonical: The hreflang tags on every location page pointed to alternate URLs whose canonical tags referenced old, redirecting URLs. We made the canonicals self-referencing across all markets, so every hreflang target became its own canonical version, and replaced the generic hreflang="en" with en-us.
The migration shipped without the organic drop everyone expected, and organic grew during the migration window. The full story is in the Indie Campers case study.
Worten: Migrating The Largest Ecommerce in Portugal to a New Website Infrastructure
This was probably one of the most intense ones.
I'm talking about the largest ecommerce in Portugal, during a period when I was leading the SEO team (before I joined Reach).
Back in 2023, Worten went through a website migration to an updated version of its website infrastructure. Organic was the number one traffic acquisition channel and the one driving the highest revenue, and the goal was to avoid a dramatic impact on rankings.
I faced many challenges, but especially these ones:
We were talking about dozens of people involved in this project, from tech teams to online sales, CRO, content, acquisition and many more. I had to be almost a PR person there, building good relationships with everyone to make sure no big decisions that could affect our website hierarchy, page structures, technical configurations, etc. were made without my guidance.
Commercial teams, with a lot of internal influence, were putting pressure to change a lot of the website's hierarchy in core categories like home appliances. One of their requests was to merge small domestic appliances and large appliances under the same URL hierarchy, without understanding the dramatic impact those URL changes would have on rankings and revenue, by forcing Google to recrawl and follow thousands of redirects. We were able to find a solution through the navigation menu that improved the visitor experience, without changing URLs that were already ranking first on Google.
Worten is the Portuguese Amazon, with millions of pages indexed on Google and dozens of categories on the website. I had to map the website's hierarchy, order it by revenue impact and run dedicated audits for the pages driving the highest results.
The migration happened in February 2023. No categories that kept their URL structure were negatively affected, and the overall performance of the website improved, not only in organic traffic but also in overall conversion rate.
The following year, in 2024, SEO at Worten generated 250M+ organic sessions and €100M+ in attributed revenue.
Best Practices for SEO Site Migrations
So, after all the insights I've been sharing, let's now summarize some of the best practices for website migrations.
Keep the root domain and URLs identical: Change the navigation, templates and look and feel as much as you need, and leave the URLs as they are. When a URL has to change, it gets a single-hop 301 to its closest equivalent.
Get a seat in every decision that touches URLs, page content or navigation: Share migration guidelines with every team before design starts.
Build the URL inventory and the benchmark before the build starts: You need both to know what to protect and to prove nothing was lost.
Crawl the current website and staging side by side: Compare URLs, titles, meta descriptions, canonicals, headings, schema and status codes, and fix every difference before launch.
Test the raw HTML on every template: Check view-source: and a browser with JavaScript disabled. A page that looks perfect in Chrome can be empty for an AI crawler.
Migrate in phases when domains change: Moving one market or one domain at a time makes issues easier to spot and limits the impact if something breaks.
Launch when the team is available: Avoid going live right before a weekend, a holiday or your peak season. Developers need to be on call during the first days.
Keep redirects live for the long term: Google recommends keeping redirects for at least one year. Removing them earlier sends old backlinks and bookmarks to 404 pages.
Have a rollback plan: Keep the old website and its hosting ready to be restored for the first weeks. If something critical breaks and can't be fixed quickly, going back to the previous version costs far less than leaving a broken website live while rankings drop.
Monitor Google and AI search together: AI engines update their citations more slowly than Google processes redirects, so a stable Search Console report doesn't guarantee your AI visibility is safe.
Mistakes to Avoid in SEO Website Migrations
I believe it's also important to highlight some of the most common mistakes I've witnessed during SEO migrations, based on previous experiences.
1. Rushing migrations because of C-level pressure
Not everyone is going to be as technical as you, or even understand the business impact of a bad migration.
It's possible to work on a website migration quickly without harming what already works. What shouldn't happen is putting it at risk just because we're excited to have a better look and feel on the website.
When the deadline can't move, cut scope instead of tests. Launch with the pages and templates that passed the audits, and leave the extra redesign changes for after the website stabilizes.
2. Doing an SEO website audit only after the migration
There are two phases of a proper SEO migration.
The first one happens in the staging environment, before go-live, where you must flag all the issues that could hurt your organic performance. And the second one happens once the migration is live, where you should run final tests to identify issues that only occur in the production environment.
Without a proper SEO audit before the new version of the website goes live, some of the issues you detect in production might be too late to fix.
3. Shipping staging settings to production
The Disallow: / and noindex tags that protect staging are correct right up until launch day. If they reach production, they tell every crawler to stay away from the entire website, and Google starts dropping pages from its index within days.
Clicking through the new website won't reveal it, since these settings only exist in the code and the website looks perfect to visitors. Add both to your launch-day checklist, and check the live robots.txt and page source in the first minutes after go-live.
4. Letting the redesign cut content
Design teams often trim copy to fit new layouts, turn H2s into styled text or remove FAQ modules that look cluttered. Each of those changes removes something that was earning rankings or AI citations.
Keep the copy, headings and FAQs of every ranking page during the migration. If the content needs to change, do it afterwards, so you can measure the impact of each change.
5. Using temporary redirects or redirect chains
302 and 307 redirects tell Google the move is temporary, so it keeps crawling the old URL and doesn't consolidate the signals into the new one. Chains add a hop to every crawl and lose part of the signal along the way.
Every redirect in a migration should be a 301, resolve in a single hop and land on the most relevant equivalent page. Mass redirects to the homepage tend to be treated by Google as soft 404s.
6. Trusting Google's live test as proof that every crawler can read your pages
Google Search Console's URL Inspection live test shows the page after Google renders the JavaScript. On one website I audited, it showed full content, FAQs and internal links, while the raw HTML only had a loading spinner.
AI crawlers never get to that rendering stage. Test the raw HTML with view-source: or an SSR checker, and compare the responses for different user agents (Googlebot, GPTBot, ClaudeBot) to make sure a prerendering setup isn't serving content to Google only.
7. Leaving tracking for launch day
Tag placement tends to be treated as a launch-day task, and then it gets missed under pressure. Every session lost before someone notices is gone for good, along with the before-and-after comparison you need to evaluate the migration.
Have GA4, Google Tag Manager and every conversion event running on staging, and test them before cutover.
SEO Website Migration FAQs
Does Reach help companies during SEO website migration?
Yes, Reach helps companies during SEO website migration, from the first URL inventory to the weeks of monitoring after launch. The team runs dozens of technical audits on staging, crawls the old and new websites side by side, and checks the live website again on launch day. Reach also tracks AI search citations alongside Google, so drops on either side are caught early. See how Reach can help you migrate and grow organic visibility.
Can I migrate without having an organic performance impact?
Yes, you can migrate without having an organic performance impact when the URLs stay the same, the content and metadata are preserved, and every technical setting is validated on staging before launch. In the migrations covered in this guide, Google clicks stayed stable through launch and AI visibility didn't drop. Small fluctuations during the first week are normal while Google recrawls the website. When URLs change, expect a longer adjustment period, since Google has to crawl and process every redirect. Keeping 301 redirects live for at least one year, as Google recommends, protects the signals of the old URLs.
What are the risks of a website migration?
The risks of a website migration are losing rankings when URLs change without 301 redirects, and getting removed from search results when a staging noindex or Disallow: / reaches production. Duplicate URLs from www, HTTP or parameter variants can also split ranking signals between two versions of the same page. AI crawlers like GPTBot, ClaudeBot and PerplexityBot don't run JavaScript, so pages that depend on it can become invisible in AI search. Broken tracking is another risk, since lost analytics data can't be recovered and hides the real impact of the migration. On one migration covered in this guide, an outdated sitemap pushed Google's daily crawl requests from around 25-30K to peaks of 100-140K.
Which teams should be involved in a website migration?
The teams that should be involved in a website migration are all the teams that can change URLs, page templates, content or tracking, such as development, design, CRO, content, commercial teams, paid acquisition and analytics. In larger companies, product and leadership need to be in the loop too, since they usually set the deadline. SEO should be part of every decision that touches URLs, page structure, navigation or technical configuration. SEO should also own the final sign-off before launch, once all staging audits are complete. On large ecommerce migrations, this can mean aligning dozens of people across departments.
What are the main precautions to have in an enterprise SEO site migration?
The main precautions to have in an enterprise SEO site migration are mapping every URL, ordering page types by revenue, and auditing 5 to 10 sample URLs per page type on staging before launch. On websites with millions of indexed pages, this keeps the workload manageable while protecting the categories that drive the most revenue. Internal alignment has to start early, since dozens of stakeholders will ask for changes to URLs, menus and page templates. When domains or URL structures change at scale, migrate in phases, one market or domain at a time. Crawl stats need daily checks during the first week, since wasted crawl budget compounds quickly across thousands of URLs.
Why should no URLs be changed during website migrations?
No URLs should be changed during website migrations because backlinks, Google's ranking history and AI citations are all attached to the exact URL. A 301 redirect passes most of those signals, but Google still has to recrawl and process every redirect before rankings settle. AI search engines rely on search results to find sources in real time, so URLs that drop out of Google can also lose AI citations. When URLs do have to change, Google recommends keeping the redirects live for at least one year. Keeping URLs identical removes that risk, so the migration only changes how the website looks and works.
Is it safe to migrate from a CMS like Webflow or Framer to a vibe coding website?
Yes, it is safe to migrate from a CMS like Webflow or Framer to a vibe coding website, as long as you rebuild the technical SEO settings the CMS handled for you. Webflow and Framer manage domain redirects, sitemap generation, canonicals and server-rendered HTML by default, while a custom or vibe-coded website only has them if someone builds them. Many vibe coding tools generate client-side React apps, which serve near-empty HTML to AI crawlers that don't run JavaScript. Before launch, confirm that the framework renders HTML on the server, the www and HTTPS redirects are set at the hosting level, and the sitemap, robots.txt, canonicals and schema are generated automatically. One of the success stories in this guide moved from Webflow to a custom-coded website on Vercel with no drops in Google or AI visibility.
