Domain migration: where positions and traffic are lost
Domain migration rarely hits positions at the moment of switchover — the drawdown comes in two to four weeks, when the search crawler re-crawls the new address and finds discrepancies.
The first and most common point of failure is redirect chains: from the old address to an intermediate one, from the intermediate to the new one, with separate rules for addresses with and without a slash, for www and non-www.
The crawler follows the chain for a limited number of steps; after that, the link is marked as broken, and the accumulated page weight is not transferred.
The second cause of traffic loss is diverged canonical addresses.
If page markup still specifies the old domain, while the sitemap already serves the new one, the signals contradict each other, and some sections continue to live in the index at the previous address or drop out of it entirely.
Separately, we check language and regional bindings: during site migration they break most quietly and become noticeable by a drop in impressions in specific regions.
The third point is external links. Direct links to deep pages do not move with the domain, and if the redirect covers only the home page and categories, the link profile loses its most valuable mentions: they are placed on articles, cards, and landing pages for queries.
We start with an inventory of all served addresses and an old-to-new mapping before switchover, not after: this way redirect errors are caught on the test contour. Below we analyze how this is closed at each stage.
What is preserved during migration: positions, traffic, indexing
During migration only the domain changes: address structure, page content and markup remain the same.
We build an old address → new address mapping line by line — we do not use an "everything to the home page" redirect because it zeroes the accumulated weight of internal pages.
- Preservation of positions. Each address gets a permanent 1:1 redirect, including pagination, filters and sorting parameters. Benchmark — all mapped addresses; unmapped ones return 404 and are handled manually.
- Indexing of the new address. Update the sitemap and robots.txt, submit the domain for re-crawl, monitor the coverage report: pages should move from "excluded" to "indexed" rather than hang in the queue.
- Address structure. Protocol, www prefix, trailing slash and case are brought to a uniform form: old and new versions should not respond simultaneously, otherwise the search engine merges mirrors and leaves the wrong address in results.
- Traffic recovery. Through Yandex Webmaster we monitor the address change and impression dynamics: usually 80–90% of traffic returns in 2–4 weeks; the remainder is queries where migration coincided with a content change.
- Eliminated class of failures. Remove duplicates, redirect loops and canonical address discrepancies — errors that cause a site to get stuck on the old domain for months.
We check the result by numbers: share of indexed pages of the new domain, number of preserved positions in the top 10 and time for traffic to return to the previous level.
Migration methods: redirects, mirror, parallel launch
The migration scheme is selected by two parameters: how many addresses live simultaneously and how quickly search traffic needs to return.
An end-to-end redirect from the old address to the new one is the most predictable option: each page gets a permanent response, signals and history transfer to the new address, and the user sees no interruption.
The condition is one, but strict — the redirect map is assembled before switchover, from logs and the index, otherwise some addresses return an error and drop out of results for months.
A site mirror and parallel launch solve another task: let both addresses work simultaneously and compare behavior before the final switchover. Here it is critical to separate canonical addresses and indexing rules, otherwise two contours will compete and dilute positions.
| Option | When suitable | Limitations |
|---|---|---|
| End-to-end 1:1 redirect | Full domain change, single contour, minimal downtime | Need a complete redirect map; an error in a rule is immediately visible in logs |
| Site mirror | Need to test the new address under load without shutting down the old one | Requires manual setup of canonical addresses and crawl map |
| Parallel launch | Gradual rollout of the new address, behavior comparison | Double maintenance of contours, risk of content divergence |
| Phased migration by sections | Large catalog, migration in parts with control | Extended timeline, both contours live for a long time |
The linking artifact for any scheme is the same — a redirect map and canonicalization rules.
We assemble it from logs, the index and structure, migrate section by section and take metrics after each stage: share of addresses with a correct response, transition dynamics and index coverage.
Stages of domain migration: from audit to decommissioning the old site
We build the work order so each subsequent operation relies on the verified result of the previous one, and rollback remains possible at any step while the old domain responds.
While preparation is underway, both addresses exist in parallel — this is the insurance against position drawdown.
-
Structure audit and address inventory. Export the sitemap, server logs and traffic report, collect all addresses: pages, pagination, filters, parametric and service URLs. Separately mark addresses with external links — their loss zeroes accumulated link weight.
-
Address mapping scheme. Assign a target to each old address: one-to-one migration, merge or deletion with the correct response code. Version the scheme so the developer, content manager and client work from one table.
-
Setup on the test contour. Raise the new domain in a closed environment and run redirect rules, canonical links, sitemap and internal links. The test contour cuts off external crawls and intermediate storage — we see failures before publication.
-
Pre-switchover check. Automatically crawl the entire scheme: verify response codes, catch multi-hop redirect chains and cyclic rules, check availability of the mobile and main versions.
-
DNS switchover. First lower record TTL, then change addresses — propagation takes minutes, and the old site continues serving content until the new one is ready.
-
Post-launch monitoring. For several weeks compare positions, traffic and response codes on a sample of addresses, adjust the scheme based on actual data.
-
Decommissioning the old site. Do last: keep the old domain while redirects work and statistics are stable.
The result of the sequence is migration without traffic failure: the search engine gets a predictable redirect map, and the team gets a rollback point at each stage.
Redirect maps, schemes and regulations after migration
Migration is considered complete not when the old address started responding with a redirect, but when the client's team has the full set of artifacts.
Without them, the next site edit or contractor change turns into reconstructing migration logic from memory — and some addresses again go nowhere.
- Redirect map — table "old address → new address → response code" with all exceptions: parameters, different case, extra slash, nested paths. It allows migration to be reproduced on the test contour and checked automatically, not by eye.
- Link handling rules — what we do with internal links, canonical addresses, sitemap and external mentions, and what we intentionally leave unchanged and why.
- Crawl scheme — order of checking sections and address groups: what we review manually, what we serve to the search crawler, where priority is on pages that bring transitions.
- Indexing regulation — timeline for removing the old address from the index and the moment when redirects can be removed without losing accumulated weight.
- Migration documentation — check logs, response code reports, crawl coverage, list of changed templates and server settings.
- Acceptance checklist — set of checks by which a new administrator understands the migration state in an hour and sees what remains to be done.
Such a set removes dependence on specific contractors: migration stops being knowledge in someone's head and becomes part of project documentation.
Case: migrating a catalog to a new address without a drawdown
An online store catalog with 19,400 addresses — product cards, categories, filter pages — was migrating to a new domain due to a change of legal entity and brand.
The old address could not be kept, and losing accumulated search traffic meant zeroing the channel that brought more than half of orders. The task was strict: change the domain without dropping search visibility.
How it was migrated
The address map was captured by crawler before migration and matched one-to-one — without "folding" the catalog into the home page, which usually causes the collapse.
Each old address got a permanent redirect, canonical was rewritten, the sitemap and all internal links were updated. Migration went in waves by sections: first categories, then products, and at each wave we checked where exactly the drawdown appeared. Dynamics were taken in Google Search Console and the webmaster panel daily.
Metrics before and after
| Metric | Before migration | Lowest point | After 10 weeks |
|---|---|---|---|
| Addresses with correct redirect | — | 99.4% | 99.4% |
| Visible queries | 24,300 | 17,900 | 26,800 |
| Search transitions, % of baseline | 100% | 61% | 106% |
| Pages in index | 19,400 | 6,200 | 18,900 |
The drop came on the third day — search reindexed the new address and temporarily removed trust. Traffic return to baseline took eight to nine weeks, and by the twelfth week visible queries exceeded the starting values.
The remaining 0.6% of addresses — duplicates and filter parameters: they were intentionally closed from indexing so as not to dilute weight.
How does migration to a subdomain differ from changing the main address?
Migration to a subdomain and changing the main address solve different tasks, and the migration logic differs. A subdomain is a separate host: the main domain stays in place and retains accumulated trust signals, while the new address starts almost from zero.
When changing the main address, the entire site is migrated — along with history and link profile — and the previous domain is removed from the index and gradually loses visibility.
External links are handled differently. When migrating to a subdomain, links to the main address continue to work and do not need rewriting — but they also pass weight to the main domain, not the subdomain.
When changing the main address, each external link must go through a permanent redirect: one uncovered page or redirect chain — and part of the link weight is lost irretrievably.
Site structure is rebuilt differently too. On a subdomain, it is enough to mirror paths and replace the host in canonical addresses and the sitemap — sections and internal navigation remain untouched.
When changing the main address, it is safer to keep page addresses one-to-one: a simultaneous change of domain and paths mixes two variables, and later it is unclear what exactly caused the position drop.
Recovery timelines differ fundamentally. A subdomain does not drop the positions of the main site, but is promoted independently: first transitions appear after weeks, stable positions after months.
When changing the main address, a short-term traffic drawdown is possible, and return to previous positions takes from two to six weeks with a clean redirect map to several months in competitive topics.
Redirects, sitemap and canonical addresses after migration
We build redirects in one step: old address — new address, without intermediate links. A chain of two or three hops dilutes transmitted weight and spends crawler requests on intermediate nodes, and some transitions do not reach the final page.
Therefore before switchover we collect inbound links, server rules and internal linking and collapse chains to direct ones.
We fix canonical addresses by templates: one entity — one address. Duplicates after migration — with and without a slash, in different case, with sorting parameters — are closed by a redirect or canonical link.
Otherwise crawling by search engines will split signals across copies, and some positions will go to pages not in navigation.
We rebuild the sitemap immediately after switchover and keep only addresses with a correct response in it. We compare crawl in Google Search Console and repeat the check in a week and in a month — until indexing statistics return to the previous level.
What to do if a redirect chain has already accumulated?
We disassemble it from the last link to the first: determine the final address and rewrite rules so each old address leads directly to it. Remove intermediate nodes and check crawl again via the server log.
Why are duplicates not closed with a disallow in the robots file?
Disallow prevents the crawler from seeing the canonical link and merging signals — copies remain in the index as standalone pages. More reliable is a permanent redirect, and for pages that should exist — a canonical address.
Let's discuss the task: migration scheme, timelines, responsibility area
At the input we need access to manage domain records, the registrar account, the site admin, and an export of current redirect rules. Separately we look at the traffic map and entry points from web analytics systems — it shows which addresses must not be lost during migration.
The more complete this data, the more accurate the migration timelines, without a "just in case" buffer.
We assemble the work plan before start: stages, action order, checkpoints and the moment after which the old address can be disabled.
The responsibility area is divided explicitly — we are responsible for the technical part of migration and preserving positions, you confirm content decisions and provide access.
- migration scheme: which addresses redirect where and in what order;
- stage-by-stage work plan with checkpoints after each;
- migration timelines and the window when traffic goes to the new address;
- responsibility area of the parties: what we do, what you confirm;
- redirect map and rules for nested pages;
- list of control addresses monitored after migration;
- accesses and roles: who can change what in domain records and on the server;
- action order if positions drop after migration.
Describe the task and current site placement — we will return with an estimate, migration scheme and migration timelines. At the output you will have a work plan and clear boundaries of responsibility of the parties.
