Moving a website to another server, CMS, or domain does not create an SEO problem by itself. Problems begin when, after the changes, the search engine can no longer correctly match the old pages with the new ones.
A URL that has received organic traffic, backlinks, and consistently ranked for relevant queries for years may turn into a 404 after an unsuccessful migration. Or it may redirect to a page on a completely different topic. Or it may remain accessible but lose its content, internal links, or correct canonical. Technically, the new website may work perfectly — the problem will appear in search.
That is why site migration SEO is not so much about moving the website itself as it is about the controlled transfer of accumulated signals from the old structure to the new one. The relationship between URLs, content, search intent, internal links, backlinks, canonical, and other signals Google already uses to understand the pages must be preserved.
If this relationship is planned before launch, the migration can be managed. If SEO becomes involved only after the new version has gone into production, the team often moves from a planned migration to searching for what was lost.
Website migration is a significant technical change that affects the domain, URLs, platform, infrastructure, or the way search engines discover and index pages.
The level of SEO risk depends not on the word “migration,” but on what exactly is changing.
For example, moving a website to new hosting without changing URLs primarily creates infrastructure risks: downtime, DNS issues, server responses, CDN, or crawler access. When moving to a new domain, the search engine already needs to match the old and new versions of a large number of pages. A CMS change may simultaneously affect URLs, metadata, canonical, internal linking, sitemap, schema, and rendering.
Website migration usually includes:
changing the domain;
changing the URL structure;
moving from HTTP to HTTPS;
changing the CMS or ecommerce platform;
changing hosting;
merging several websites;
significantly restructuring the architecture.
For example, the old address /catalog/product.php?id=123 may become /products/product-name/ after moving to another platform. For a person, it is still the same product. For the search engine, it is already a different URL, and the connection between them needs to be shown correctly.
A redesign primarily changes the interface, UX, visual appearance, or page templates. It can happen without any change to URLs.
Migration deals with the technical or URL structure of the website and may not be noticeable to the user at all. For example, the website moves to another CMS but looks almost unchanged.
The scenario becomes more complex when both processes happen at the same time. Along with the new design, the team changes the domain, URL structure, CMS, navigation, content, and information architecture. If organic visibility drops after launch, many potential causes need to be checked at once.
That is why major changes should be separated where the project allows it. This not only reduces risk but also makes further diagnostics much clearer.
A search engine does not know the internal logic of your project. To the team, it is obvious that the old service page and its new version are the same entity. Google needs enough signals to reach the same conclusion.
The connection may break if old URLs start returning 404s, redirects lead to the wrong destinations, important content is not transferred, or the new page no longer matches the search intent of the old one.
There are also less noticeable technical problems: canonical pointing to the old domain, noindex from the test environment, a sitemap with incorrect URLs, pages blocked through robots.txt, broken hreflang, missing schema, or internal links that continue pointing to old addresses.
Another risk is backlinks. An old URL may no longer be important for internal navigation but still have backlinks from strong resources. If it is forgotten during migration, part of the accumulated value simply will not have a logical continuation.
That is why SEO migration should be planned as a system of connected changes, not as a separate task to “set up 301 redirects.”
Starting a migration without an SEO baseline is risky. If something changes after launch, the team will have nothing to compare with the new metrics.
Before migration, you need to record not only total organic traffic but also the structure of the old website.
The first step is a complete crawl. Save URLs, status codes, canonical, title, H1, meta robots, hreflang, internal links, and structured data. This file will become a reference snapshot against which the new website can be compared.
In Search Console, record clicks, impressions, key landing pages, queries, indexing data, and existing issues. In Analytics, organic landing pages, conversions, revenue, and ecommerce data are particularly important.
For strategic commercial pages, it is useful to save rankings separately. Another layer of data is backlinks, especially for URLs that have strong external links.
This baseline is not needed for a nice “before/after” report. After launch, it allows you to quickly distinguish a real SEO loss from natural fluctuations, seasonality, or, for example, broken tracking.
One common mistake is building a redirect map from the pages currently visible in the menu.
This makes it easy to lose old landing pages, products, categories, articles, pages from previous campaigns, or URLs that disappeared from navigation a long time ago but still receive traffic or have backlinks.
That is why the URL inventory is collected from several sources: crawl, sitemap, Search Console, Analytics, backlink data, CMS, or database. For large and complex websites, server logs can also be added.
Different sources almost always produce different sets of addresses. A crawl may not include an orphan page, the sitemap may not include a page deleted long ago, and Analytics may not show a URL with no current traffic that still has strong external links pointing to it.
The goal of this stage is not to preserve absolutely every address. First, you need to see the entire old website, and only then decide what should move into the new structure.
After the inventory, the future of each old URL is defined.
The basic logic looks like this:
Old URL → New URL → Action
For example:
/old-service/ → /services/new-service/ → permanent redirect
If the page is permanently removed and there is no relevant replacement:
/old-page/ → no new equivalent → 404 or 410
URL mapping is one of the central stages of SEO migration. This is where it is decided whether the old page will have a logical continuation in the new structure.
The destination should be chosen not according to the principle “where can we send this URL?” but according to the closest possible content and search intent.
If the old page was dedicated to an SEO audit, the agency homepage does not become a full replacement just because both belong to the same domain. A much stronger solution would be a new SEO audit page or the closest relevant service.
That is why the model “1,000 old pages → homepage” is not a proper migration strategy.
Server-side permanent redirects, including 301 or 308, are used for permanently moving URLs.
There is no point in building the whole process around the old claim that “only 301 passes SEO value.” For migration, what matters more is that the redirect is permanent, direct, technically correct, and leads to a relevant new URL.
Redirect chains should also be checked separately.
Instead of:
A → B → C → D
it is better to use:
A → D
Long chains create unnecessary requests, slow down the transition, and complicate diagnostics. They are especially common on domains that have already gone through several major changes.
Another critical mistake is a redirect loop, for example:
A → B → A
In this case, the page effectively becomes inaccessible both to the user and to the crawler.
At the same time, a redirect is not always needed. If the old page has been permanently removed, has no relevant replacement, and should not exist on the new website, a 404 or 410 may be the correct result.
Not every 404 is an SEO mistake. The mistake is losing a valuable URL that actually has a logical continuation.
Even a perfect redirect will not save a page if its content changes after migration.
Suppose the old /seo-audit/ page consistently ranked for queries related to SEO audits. In the new structure, it was redirected to a page with an abstract description of “comprehensive digital growth,” where the audit is mentioned only briefly.
The technical redirect works. The topical continuity does not.
That is why content mapping should be done together with URL mapping. For important pages, check the main topic, search intent, key content, metadata, and structured elements.
This does not mean that old content must be frozen forever during website migration. It can be improved, merged, or restructured. But such changes become a separate factor and need to be taken into account when evaluating the result.
Redirects tell search engines where old URLs have moved. But the new website itself must also consistently use the new structure.
On new pages, canonical should point to the current canonical URLs.
After launch, check whether canonicals still point to the old domain or staging, whether HTTPS pages point to HTTP, and whether a large number of new URLs are canonicalized to one random address.
These errors can easily spread across hundreds of pages if the problem is built into the CMS template.
Internal links after migration should point directly to the new URLs.
The structure:
internal link → old URL → redirect → new URL
works technically, but leaves an unnecessary intermediate step in the site structure.
After migration, it is better to have:
internal link → new URL
This allows the website to transition to the new URL system faster, while the crawler does not waste additional requests on old pages.
The new sitemap should reflect the current structure of the website: canonical, indexable URLs with a 200 status.
Redirects, 404s, noindex, and old outdated addresses should not remain in the main sitemap.
For large migrations, the old sitemap can sometimes be used temporarily as an additional way to monitor old URLs. But this does not change the main requirement: the current sitemap should correctly describe the new website.
Indexability problems are particularly unpleasant because the user may not notice them at all.
The website opens. Forms work. Pages look correct. But production inherited staging rules that restrict crawling or indexing.
Before launch, check robots.txt: important directories should not be blocked, CSS and JS required for rendering should remain accessible, and the sitemap reference should point to the current file.
noindex requires a separate check.
For a test environment, this directive may be appropriate. For production, it is a critical mistake if indexable pages are accidentally left blocked.
That is why checking indexability should be part of the launch checklist, not something done several days after launch.
Multilingual websites have another layer of dependencies — hreflang.
After changing the domain or URL, check all language versions, reciprocal references, canonical, new paths, and x-default, if used.
A hreflang problem does not always look like an obvious technical error. Pages remain accessible and may be indexed, but the search engine receives incorrect signals about regional or language relationships.
After a CMS migration, structured data should also be checked again. Organization, Product, Breadcrumb, Article, LocalBusiness, Video, and other schema types often disappear not because of a specific decision, but simply because the new template no longer generates them.
Moving to another domain is one of the scenarios where simply connecting the two homepages is not enough.
If the old website had:
oldsite.ua/services/seo/
and the new one has:
newsite.ua/seo/
a direct match needs to be created between these pages.
The same applies to categories, products, articles, and other URLs that have a continuation on the new domain.
After launch and redirect verification, Change of Address in Search Console is used for the relevant type of domain migration. The old and new properties continue to be monitored in parallel.
Change of Address is not a universal tool for every migration. It is not needed for HTTP → HTTPS migration or ordinary path changes within the same domain.
During a domain migration, all actual domain variants should also be taken into account, including www and non-www, so that no versions remain unaccounted for in the migration plan.
HTTP → HTTPS is also a URL change, even though only the protocol changes in the address.
Check the SSL certificate, HTTPS redirects, canonical, internal links, sitemap, and hreflang. Another risk area is mixed content, where the page itself already works over HTTPS, but some images, JS, CSS, or other resources continue loading over HTTP.
Change of Address is not used for this type of migration.
If the domain and page addresses remain unchanged, URL signals do not need to be transferred. However, other risks arise.
The website may become unavailable during DNS switching, the new server may respond slowly or process certain statuses incorrectly. A CDN or WAF may accidentally restrict crawler access, and some resources may simply not be transferred.
Therefore, during hosting migration, the main task is to ensure stability:
minimize downtime;
configure DNS correctly;
check server responses;
preserve HTTPS;
check CDN and WAF;
make sure Googlebot is not blocked;
test load handling.
This is a simpler scenario from a URL migration perspective, but it can still affect crawling and website availability.
WordPress, Shopify, Magento, WooCommerce, or a custom CMS do not determine the SEO result by themselves.
The consequences arise because the platform change may also change the rules for generating URLs, metadata, pagination, filters, canonical, hreflang, structured data, sitemap, internal linking, or rendering.
For example, the old CMS may have created one indexable category page, while the new one creates dozens of URLs with filter parameters. Or Product schema may disappear after moving to another template, even though the product pages themselves look almost unchanged.
That is why, before a CMS migration, you should compare not the platform brands but the specific SEO behavior of the old and new systems.
An ecommerce website has significantly more page types and technical relationships than a typical corporate website.
In addition to categories and product URLs, you need to control discontinued products, variants, filters, faceted navigation, pagination, inventory, reviews, and product schema. It is equally important to test checkout and ecommerce tracking.
Special attention should be paid to filters. The new platform may quietly create thousands of indexable combinations or, conversely, block pages that previously captured organic demand.
That is why ecommerce migration should not be reduced to a redirects table. It is also work with catalog structure, indexation, crawling, product data, and analytics.
Most technical errors are cheaper to find before launch.
The new website should be tested on staging, but the environment itself should not enter the index. Authentication or password protection is more reliable for protecting it than relying only on crawler directives.
Before launch, crawl the new version and compare it with the old website.
Pay particular attention to:
number and types of URLs;
indexability;
status codes;
redirects;
title and H1;
canonical;
noindex;
internal links;
hreflang.
This is often the stage where it becomes clear that some important pages did not make it into the new structure, canonical logic changed, or the CMS generates URLs that the SEO team did not expect.
On launch day, URL mapping or redirect structure should not be decided for the first time. These decisions should be prepared and tested earlier.
Before switching, the team checks the backup, final URL mapping, redirect rules, correct analytics settings, Search Console, sitemap, robots.txt, DNS, and SSL.
After launch, it is important to perform a production crawl as quickly as possible. It will show the real version of the website, not what was planned on staging.
Check redirects, robots.txt, indexability, canonical, sitemap, analytics, key forms, checkout, and main commercial URLs.
Priority pages are better defined in advance. If the website is large, there is no point manually opening thousands of URLs in the first hours while the most important categories or landing pages remain unchecked.
After launch, the monitoring stage begins.
In Search Console, you need to monitor not only total clicks and impressions but also what is happening with the pages.
It is useful to monitor:
indexing;
page errors;
sitemap processing;
URL Inspection for critical URLs;
clicks and impressions;
queries;
main organic landing pages.
During domain migration, it is especially important not to forget the old property. It helps show how the activity of old URLs changes and whether visibility is transferring to the new domain.
Overall numbers may also hide a problem. If one group of pages sharply loses impressions while another grows, the overall domain chart may look relatively stable. That is why strategic clusters are better analyzed separately.
New 404s after launch can help find gaps in mapping.
They may include old URLs the team did not account for, broken internal links, incorrect redirects, or external links to pages with no new equivalent.
But priority is determined not by the number of 404s, but by the value of the specific addresses.
A 404 on a technical URL that never had traffic and should not exist, and a 404 on an old landing page with backlinks and stable organic clicks, are completely different tasks.
That is why a 404 audit after migration is better combined with Search Console, Analytics, and backlink data.
For large websites, server logs can provide an additional level of control.
They show whether Googlebot continues to regularly access old URLs, whether it passes through redirects, which parts of the new website it is already actively crawling, and where it receives server errors.
On a large ecommerce website, this helps you understand more quickly how the transition between structures is actually happening, especially if the number of URLs reaches tens or hundreds of thousands.
For a small corporate website, log analysis may be unnecessary. The same problems can often be found with simpler tools.
Yes, fluctuations are possible after a major migration, especially if the domain or a significant share of URLs changes.
But it is important not to create artificial benchmarks. There is no universal rule that “a 10–20% drop is normal” or that visibility must fully return within a specific number of weeks.
The result depends on the scale of the website, migration type, number of changed URLs, quality of mapping and redirects, crawl frequency, and how much the content changed together with the technical part.
That is why the process should be monitored: whether Google finds the new pages, whether redirects work, whether the required URLs are indexed, how impressions and clicks shift, and what happens to priority landing pages.
Small fluctuations and a systematic problem have different signs.
Detailed diagnostics are needed if several of the following signals appear after launch:
a sharp drop in organic traffic;
important URLs disappearing from the index;
problems indexing new pages;
a large number of redirect errors;
an increase in 404s on valuable URLs;
incorrect Google-selected canonical;
declining impressions for the old version without a corresponding transition to the new one;
conversions disappearing after migration.
The last point is particularly important. A decline in conversions does not yet prove that the migration damaged SEO. First, make sure the measurement system itself continues to work.
After domain migration, the old version continues to perform an important function.
Users may visit old URLs from bookmarks, external resources, and Googlebot. The redirects that direct these requests to the new addresses work through the old domain.
If the domain is shut down too early, this bridge between the old and new structures stops working as well.
This rule should not be replaced by an arbitrary timeframe such as “keep the domain for 30 days.” The duration depends on the specific migration and how long the old addresses remain part of the real web.
Permanent redirects remain necessary regardless of whether the external link was updated.
At the same time, for the most valuable backlinks, it makes sense to contact the owners of the resources and ask them to replace the old address with the new one. This primarily applies to strong media websites, partner sites, niche directories, and other sources that matter to the project.
There is no need to turn this into a campaign to manually update every old link. Prioritize resources where the direct link genuinely has value.
The most difficult scenario to control looks approximately like this:
new domain + new CMS + new URL structure + new design + new content + new architecture.
Sometimes business reasons genuinely require combining these changes. But each of them adds a separate layer of risk.
If visibility drops after launch, you need to understand whether the problem lies in redirects, new content, internal linking, indexation, CMS, or a completely rebuilt structure.
The fewer independent parameters change at the same time, the easier it is to control the result, diagnose the problem, and perform a rollback if necessary.
SEO may have been migrated correctly, but reporting may show a disaster if events or integrations stop working after launch.
That is why, after migration, GA4, GTM, Google Ads conversions, ecommerce events, forms, call tracking, CRM integrations, referral exclusions, and cross-domain tracking, if used, should be checked separately.
Measurement changes especially often together with the CMS, checkout, or form logic.
If an order used to send an ecommerce event and stops doing so after launch, Analytics will show revenue disappearing even with stable traffic and real sales.
Without this control, the team may spend several days looking for an SEO problem that does not actually exist.
To avoid keeping all dependencies in your head, the process should be divided into three stages.
crawl the old website;
record the Search Console and Analytics baseline;
save important rankings;
collect backlinks;
build a complete URL inventory;
prepare URL mapping;
define the redirect plan;
create content mapping;
prepare technical SEO requirements for the new website.
crawl staging;
test redirects;
check canonical and indexability;
check robots.txt and sitemap;
test hreflang;
check structured data;
check analytics;
test the mobile version and performance.
run a production crawl;
perform a redirect audit;
check Search Console;
monitor the sitemap;
analyze 404s and server errors;
monitor indexing;
compare rankings and organic traffic;
monitor conversions.
This is not simply a list of technical tasks. The stages should be completed in this exact sequence because each next stage relies on data from the previous one.
Most problems after website migration do not arise from one exotic technical error. More often, several simpler issues accumulate.
The team does not collect a complete list of old URLs and then configures redirects only for pages in the menu. Old pages are redirected in bulk to the homepage. Some important content is not transferred. Redirect chains appear. Canonicals remain on the old domain, redirects appear in the sitemap, and internal links continue pointing to previous URLs.
After changing the CMS, hreflang or structured data may disappear. After staging, noindex sometimes reaches production. And if Analytics and conversions are not checked at the same time, unreliable reporting is added to the real SEO problem.
Another category of risk is shutting down the old domain too early and changing too many elements at once without a real need.
A good migration checklist is needed precisely to prevent these small decisions from turning into one large problem together.
A migration cannot be considered complete simply because the new website opens, SSL works, and the old pages redirect somewhere.
SEO migration should preserve the logical continuation of what was already created on the old website: page relevance, relationships between URLs, internal linking, canonical signals, backlinks, and a structure that remains understandable to the search engine.
That is why a proper process looks like this:
inventory → URL mapping → redirects → technical checks → launch → monitoring.
And the safest time for an SEO specialist to join the migration is not after traffic drops, but before the structure of the new website is finally approved.
Website migration is a significant technical change to the domain, URLs, CMS, infrastructure, or another part of the website that may affect crawling and indexing. From an SEO perspective, it is important not only to move the website itself, but also to correctly connect the old pages with the new ones.
The risk can be significantly reduced through proper preparation: collect all old URLs, record a baseline, create URL mapping, configure relevant permanent redirects, and check the new website before and after launch. However, it would be incorrect to guarantee the complete absence of any fluctuations after a major migration.
You need to match old URLs with new ones, configure permanent redirects, update canonical, internal links, and sitemap, check both properties in Search Console, and monitor indexing after launch. Change of Address is also used for the relevant type of domain move.
No. A permanent redirect is needed when there is a relevant new address for the old page. If the content has been permanently removed and there is no appropriate equivalent, a 404 or 410 may be a better solution than an artificial redirect.
Mass redirecting to the homepage does not create a correct match between old and new content. For each valuable URL, it is better to find the closest new equivalent in terms of content and intent.
Yes. The current primary sitemap should contain new canonical indexable URLs with a 200 status. Old pages, redirects, 404s, and noindex should not remain there as part of the current structure.
The tool is used for relevant scenarios of moving between domains or subdomains after the new website is already live and redirects have been configured. It is not needed for HTTP → HTTPS migration or ordinary URL changes within the same domain.
There is no single timeframe. The speed depends on website size, number of URLs, migration type, crawl frequency, redirects, and the scale of other changes. It is better to monitor the actual transition in indexing, impressions, and clicks rather than wait for an arbitrary day when the “migration should be complete.”
Some fluctuations are possible, especially during a large-scale URL or domain change. However, there is no universal “normal percentage drop.” A sharp disappearance of important pages, indexing problems, or prolonged visibility loss requires diagnostics.
You need to compare the old and new crawl, check redirects, canonical, indexability, sitemap, 404s, Search Console, organic landing pages, rankings, and conversions. For a large website, server log analysis can also be useful.
There is no universal short timeframe. The old domain should remain accessible long enough for redirects to continue working for search engines, users, backlinks, and old bookmarks. It should not be shut down immediately after the new version is launched.
