Contents
Site migration often looks like a story about a domain, a CMS, and a new design. For search, it is almost always a jolt. URLs change, the structure changes, and the site’s internal logic changes. Along with that, the signals that crawlers used to understand what belongs where, and what to trust, shift too.
If you go into a migration without a plan, the outcome is usually predictable: traffic drops, some pages fall out of the index, and rankings start to fluctuate.
The good news is, when a migration is managed like a project, organic traffic can usually be preserved. The difference is usually one thing: preparation and control instead of improvisation. When you know in advance what is changing, how the new version will be connected to the old one, and which metrics you will use to evaluate the launch.
Bogdan Eletenko, an SEO specialist at Why SEO Serious, prepared this piece so the migration follows a clear scenario, and does not turn into a search for causes after the fact. In the article, he breaks the process into steps: what to check ahead of time, what to keep under control during the switch, and which signals help you quickly see that something went wrong.
Why search engines may reduce a site’s visibility after a migration
A search engine “sees” a site through a set of stable signals. This is what helps the system connect pages into a single resource and understand how much it can trust it. This picture includes the URL structure, internal and external linking, behavior signals, and technical consistency.
When a migration changes page addresses, the platform, or the logic of the site structure, some of these signals reset or start to contradict each other. At this moment, algorithms almost stop recognizing the site and act cautiously until they understand what they are looking at.
Below are the main reasons why visibility drops after a migration:
| What breaks | How it looks to a search engine | What happens as a result |
|---|---|---|
| The link between old and new content | There is no clear bridge between old and new URLs | Accumulated authority is not transferred, rankings drop |
| Technical correctness | 404s, redirect chains, indexing errors | Trust in site quality drops, visibility declines |
| Behavioral signals | Users leave more often, move deeper less often, and spend longer looking for what they need | Algorithms register a decline, rankings get worse |
| Internal linking | Internal links point to old addresses, orphan pages appear | Crawlers cover the site less effectively, authority is distributed unevenly |
| External links | Referring sites land on 404s because redirects were not set up | You lose both traffic and link equity |
The main task is to help search engines get familiar with the site again and convince them that the quality stayed the same. It is the same resource, just in an updated setup.
When a migration is justified
Not every reason for a migration is a good one. If the site works well and brings in traffic and leads, targeted improvements are often enough. A migration makes sense in these cases:
- A domain change due to a rebrand or a site merger.
The site address will change anyway. The key is to do it in a controlled way so search engines connect the old site to the new one, and you do not lose the accumulated history.
- Moving to a different CMS that better fits business needs.
If the current platform limits growth (content workflows, speed, integrations, templates), you end up fixing issues instead of growing. A migration removes that ceiling.
- The need to change an outdated URL structure.
When URLs are messy, with no clear hierarchy and no readable slugs, they can create duplicates or break the logic of sections. This makes indexing harder and confuses how search engines interpret the site structure. In this case, it is easier to rebuild URLs into one consistent scheme once than to keep fixing the symptoms with small changes.
- A major redesign that affects navigation and usability.
If templates and section logic change, the SEO risk is close to a full migration. That means you need a migration approach here too, with checks and a plan.
Three stages of a controlled SEO migration
1. Planning
At this stage, you lay the foundation for a safe transfer. It matters to understand early which pages are assets and which ones are more like ballast.
- Audit. Collect a list of all pages. Add traffic, rankings, and link equity for each one. Then you can see which URLs are truly critical for the business.
- Redirect mapping. Write down in advance where each old address will go. This helps preserve link equity and keeps accumulated signals from being lost.
- Internal linking plan. If the URL structure changes, you need a map of what to update in menus, page copy, recommendation blocks, and widgets. Otherwise, after release, many internal links will still point to the previous version of the site.
- Timing. It is better to launch in a low season. Also, avoid launching right before a weekend. In the first days, small issues often surface, and it is important to fix them fast.
2. Preparation
Before launching the new site, it is worth checking that everything works as intended. And that search engines will not see the staging version too early.
- Staging environment. Set up a staging site to test functionality without indexing.
- Site crawl. Run the site through Screaming Frog or a similar crawler. This helps you find broken links faster, issues with meta tags, canonicals, robots.txt, and gaps in internal linking.
- Analytics tags. Move your analytics setup into the new site’s code (for example, Google Analytics 4, Tag Manager, or the tools you use). Without it, after launch, you can lose visibility into what is really happening.
3. Launch
After you switch on the updated version, the most important phase begins: monitoring and quick fixes based on what you see in production.
- Submit the new sitemap.xml in Google Search Console (and, if relevant, Bing Webmaster Tools).
- Monitor technical health and indexing. Track indexing in Search Console, the availability of robots.txt and sitemap.xml, canonical URLs, meta tags, 4xx and 5xx HTTP statuses, page speed, and how interactive elements work on different devices. Also, track ranking dynamics separately.
- Set up and maintain redirects. Redirects should go straight to the target pages, without chains. They must return the correct status code, usually 301 for a permanent redirect. Redirects are not kept for a couple of weeks. They stay as long as needed to transfer accumulated authority and to reinforce for search engines that the site has moved to new addresses.
- Check external links. For example, use Ahrefs. If possible, ask referring site owners to update their URLs, so the signal reaches the right pages faster. If updating links is not possible, make sure the old URLs do not lead to 404s and correctly redirect to the current pages. A prepared redirect map will cover this.
🤝 Stay in touch
For more context and practical notes from the team, follow us on LinkedIn.
Features of different migration types
A migration is not one-size-fits-all. The risks are similar, but problems show up in different places, depending on what exactly you are changing.
Domain change
It is better to enable the migration tools in Google Search Console and Bing Webmaster Tools after the technical move is done. That means when the new domain is live, pages open correctly, and the old and new sites run in parallel for a while and stay stable. This makes it easier for search engines to connect old addresses to new ones and keep the migration logic intact.
After that, everything comes down to redirects. They should point directly, without chains, and stay in place long enough. You also should not switch off the old domain too early. During this period, it works as a bridge between the previous version and the current one.
One more important point is timing. Google’s documentation often mentions a guideline of at least a year, but in practice, it is better to keep redirects longer. Gary Illyes, a Search Quality Analyst at Google, has also emphasized this in a tweet.
Search engines may need more time to fully accept the move and solidify the new URLs.
Switching to a new CMS
First, it is best to check the basics. These are page templates, meta tags, schema markup, and canonical tags.
Then look at how the site serves content technically. It is worth monitoring server-side rendering (SSR) settings, how forms work, how responsive the templates are, and how all existing integrations behave on the new platform.
There is one more point that is often underestimated. When you change a CMS, it is better to test in different browsers and on different devices. This is where differences in layout, scripts, and functionality usually show up.
Redesign and changing URLs
Even if the domain stays the same, the SEO risks remain.
Try not to change URLs without a real need. If changes are necessary, update internal links and the sitemap, so both search engines and users do not keep running into old addresses.
Next, make sure you do not lose what holds the page structure together. Check semantic HTML and headings (H1–H6), meta tags, and structured data. Also, review page speed and responsiveness. These metrics are the ones that most often drop after a redesign.
Expert tips that most often save a migration
After a migration, minor fluctuations are ok. A noticeable drop is almost always caused by something specific. Here are five areas where we most often see issues, and how to catch them before launch.
Checking the new domain
Even a “new” brand domain may not be newly registered, and it may have a past. Before you buy it, check Archive.org and see what used to be there. Look at the topic and the quality.
Domains with a bad history, such as spam links or traces of banned or illegal content, are better avoided altogether. The ideal option is a relevant expired domain with a clear history, stable rankings, and a healthy link profile. A brand-new domain with no history is usually safer, but it has to build authority from scratch.
SSR for JavaScript frameworks
If the site is built on a JavaScript framework, check how pages are rendered for crawlers. If key content is loaded only on the client side, search engines may see an incomplete page or process it more slowly. That affects indexing and rankings.
Server-side rendering (SSR) reduces this risk. It helps deliver the main content in the initial HTML and makes it easier for bots to understand the page.
A simple way to check is to compare what you see in the browser with what is available in the raw HTML and in “view source.” If headings, main text blocks, and internal links are missing there, rendering needs attention.
Duplicate headings and semantic HTML
During a redesign or a CMS change, semantic markup often breaks. Instead of a clear hierarchy H1 → H2 → H3, everything turns into a mess of dozens of H1s and H4s.
Our own case. After a move to React, we found 15+ H1 headings on the homepage, including footer menu items.
Search stops understanding which content is the main one on the page, and relevance gets diluted. That is why it is important to verify the heading structure, keeping one H1 and a logical nesting.
Pagination
One of the most common and fatal mistakes when moving to SPA sites is broken pagination. If the URL does not change when users go to the next catalog page, there are no parameters like ?page=2, and content loads dynamically, the crawler will not be able to index products beyond the first page.
As a solution, you can either set up static URLs for pagination pages with canonical tags or use infinite scroll with SSR.
Transferring schema markup
During migration, schema markup can easily be missed or not reconfigured. This is especially common for products (Product), articles (Article), the organization (Organization), and breadcrumbs (BreadcrumbList).
When it is missing, the site loses rich snippets in search and loses structured signals for crawlers and AI assistants. After the move, validate the markup with the Schema.org validator and Google’s rich result testing tools.
How to assess whether the migration was successful
In the first weeks after the move, keep a close eye on the basics. Regularly check four things:
- Organic traffic in GA4 (or your analytics setup).
- Index coverage: how many pages are in the index, and how quickly search engines pick up the new URLs.
- Rankings for key queries, especially for the pages that used to drive most of the traffic.
- Technical signals: 404 errors, load speed, and other site health indicators.
👉 What a good scenario looks like: traffic either barely drops, or shows a short decline and then quickly returns to the previous level.
Ideally, once things stabilize, you may even see growth, especially if the migration also removed old technical limitations.
Conclusion
If a migration feels stressful, that is ok. It almost always brings some turbulence, even when everything is done carefully. But it does not turn into a disaster when you prepare the transfer in advance, check the critical points, and then, for a couple of weeks after launch, closely monitor indexing, errors, and traffic. In that case, SEO usually returns to its usual levels.
We help protect traffic and rankings during a migration
Our team has experience migrating complex projects across different industries, from media to e-commerce and online marketplaces.
