When content migration breaks SEO: typical causes
Traffic loss during a site move is almost never related to the move itself — what breaks is the mapping of old and new addresses.
If the content migration strategy doesn't describe which URL turns into what, the search engine sees a new site from scratch: old pages drop out of the search results, new ones wait to be recrawled, and positions built up over years are reset to zero in a couple of weeks.
Worst of all, the drop comes with a 2-4 week delay — when it's already hard to link it to the release.
Typical content migration mistakes lie in one plane: redirect chains longer than one hop, redirects to the homepage instead of a relevant page, lost tails of pagination and filters, duplicates caused by the old and new address being available at the same time.
Each such case is either a break in accumulated weight or a ghost page that competes with itself. A separate category is content that was "forgotten" to be moved: it remains accessible at the old address but drops out of the new structure and gradually leaves the index.
Redirects when changing the structure are the most sensitive area.
The transition map must be built from the actual list of URLs with traffic, not from assumptions about which sections are "probably important." If a redirect rule describes a section as a whole, and inside there are pages with unique demand, they lose their address and position.
That's why transitions are designed page by page for everything that brings traffic, and only then is the rest grouped.
Indexing after migration is verified not by the fact that "pages are in the index," but by the fact that the index contains exactly the new addresses and that the old ones have left it.
While both addresses are alive, the search engine chooses the canonical one itself, and the choice doesn't always match expectations. Next, we break down how this is closed at the level of preparation, the transition map, and post-release control.
What a content migration strategy delivers: impact and comparison of approaches
A content migration strategy is not about moving files, but about managing the correspondence between the old and new structure.
A mistake at this level is the most costly: search engines lose accumulated signals, external links lead nowhere, and some pages simply disappear from the search results. Below is what a well-designed strategy delivers and how the approach is chosen for a specific site.
Content audit before migration removes dead weight
An inventory of all URLs with metrics (traffic, inbound links, conversions) divides content into three groups: migrate as is, merge with a duplicate, remove from the index.
On an average corporate site, this filters out 20–40% of pages — migrating them creates no value but does create risk. The remaining set is migrated deliberately, not "just in case."
Preserving URL structure and a redirect map hold rankings
Each old URL is matched to a target one, the rule is described in the redirect map and verified before the switch.
If the URL structure is preserved where possible, and redirects are set only for paths that actually changed, the share of lost traffic stays within a few percent instead of a multi-fold drop. Redirect chains are collapsed to a single hop — otherwise each link loses weight at every step.
Lossless content transfer is verified on a copy
The migration is run on a test environment: titles, metadata, markup, canonical, and sitemap are compared. Automated comparison of old and new URLs catches broken links and lost pages before release, not after.
Such a run typically reveals dozens of discrepancies that in manual mode would only surface in production.
| Option | When it fits | Limitations |
|---|---|---|
| Full one-to-one transfer | Platform change without revising the structure | Carries over outdated sections and duplicates |
| Transfer with cleanup and merging | Dead content has accumulated, duplicates exist | Requires manual decisions for each group |
| Phased migration by sections | Large site, work cannot be stopped | Takes longer, requires supporting two structures |
| Full structure rebuild | The logic of sections and navigation changes | Maximum volume of redirects and checks |
Our engineers run migrations according to a scheme where the redirect map and URL comparison are mandatory artifacts, not a byproduct.
The transfer approach is chosen for the task: sometimes a clean transfer is enough, sometimes a phased scheme with two structures running in parallel is needed.
We use Screaming Frog and similar crawlers for before-and-after comparison — this provides an objective picture instead of assumptions.
Implementation stages: from content audit to handover
A content migration strategy doesn't break during file transfer — it breaks at the seams: URLs change faster than the mapping table is updated, and search engines start seeing duplicates instead of pages.
That's why we structure the site migration stages so that each subsequent step relies on a verifiable artifact from the previous one, not on the team's memory.
- Content audit. We compile a complete list of URLs from the current site and tag each page by status: keep as is, move to a new URL, merge with another, delete. The output is a table with the source URL, target URL, action type, and owner. Without it, any transfer turns into guesswork.
- Redirect schema design. Based on the table, we build redirect rules: one-to-one mappings, group patterns for sections, chains for structural changes. We separately verify that no URL leads nowhere and doesn't form a loop — a chain of two or three hops loses weight and confuses crawlers.
- Staging setup. We run the rules on a production copy and verify response codes for every URL from the audit. Mistakes at this stage cost the least: a config fix takes minutes, whereas dealing with the consequences on a live site takes days.
- Transfer and switchover. We deploy the content, enable redirects, update the sitemap and internal links. Order matters: rules first, then traffic — otherwise some visitors will land on non-existent pages.
- Indexation check. We monitor how search engines crawl the new URLs: the share of indexed pages, response codes, absence of duplicates. We address discrepancies with the plan on a case-by-case basis, rather than "waiting for things to settle on their own."
- Post-switchover monitoring. We keep watching traffic and rankings of key pages until metrics return to their previous level. A dip in the first days is normal; a prolonged one signals that some rules didn't work.
- Documentation handover. We deliver the URL mapping table, the rules file, the indexation report, and instructions for adding new redirects. The client receives not a one-off result, but a working process their team can run on their own going forward.
Each stage ends with a verifiable artifact: a table, a configuration, a report. That is the difference between a managed migration and a transfer "by eye."
How is migration to a new domain different from changing the URL structure?
These are two different classes of tasks, and they must not be confused within a single content migration strategy. Migration to a new domain changes the host: all addresses get a new prefix, while the paths stay the same.
Changing the URL structure changes the paths themselves — sections, nesting, slug — while keeping the same domain. In the first case, you move the entire site as a whole; in the second, you rebuild the navigation and the logic of addresses while keeping the platform.
This leads to different behavior of 301 redirects. When moving a site, the rule is built one-to-one: old address → the same path on the new domain, and the mapping is generated by a script and checked for completeness.
When changing the structure, the correspondence is not obvious: one old URL may split into several new ones, and several old ones may merge into one. Here the redirect map is assembled manually by page groups, otherwise part of the traffic goes to 404.
Preserving link equity depends on where external links point. When moving a domain, equity is transferred via a 301 to the equivalent address — it is important not to lose a single inbound URL and not to serve a redirect through a chain of two or three hops.
When changing the structure, external links point to the old paths, and each such address must serve a 301 to the closest new one in meaning, not to the homepage: a site-wide redirect to the root devalues the link.
Indexation checks also differ. After moving a site, you verify that the search engine sees the new domain, that the old one serves redirects without loops, and you monitor the change of canonical addresses in the markup.
After changing the structure, you check that the old URLs drop out of the index, the new ones get indexed, and that internal links and the sitemap already point to the current paths.
In both scenarios, server logs show which addresses still return 404 and where a redirect leads to the wrong place.
What the scenarios have in common is one thing: a redirect map, updated canonical addresses, and indexation control via logs.
The difference is that when moving a domain you preserve the structure and transfer equity one-to-one, while when changing URLs you reassemble the correspondences anew and risk losing equity on ambiguous matches.
Case study: how content migration preserved traffic and rankings
The client came with a classic situation: a site on an old platform, content accumulated over years, URL structure grown organically.
During the move to a new CMS, the first migration attempt caused a drop — within three weeks about 40% of pages fell out of the index, organic traffic nearly halved, and some addresses returned 404 without redirects.
The cause was not the platform itself, but the absence of a content migration strategy: addresses were changed "according to the logic of the new structure" rather than according to a mapping.
What we did
First, we took a full inventory: exported all URLs from the sitemap and server logs, cross-checked them against the content database, and flagged pages with traffic and inbound links.
For each page we built a "old address → new address" map, and for groups of similar materials — batch migration rules instead of manual work.
Next — permanent 301 redirects at the server level, not in the application: this eliminates chains and extra hops.
Separately, we closed the classes of errors that usually eat rankings: duplicate titles and meta descriptions, broken internal links, orphan pages without inbound links, lost canonical and hreflang.
We monitored using migration metrics: share of preserved pages, reindexing speed, number of crawl errors, traffic distribution by section before and after.
Results in numbers
| Metric | Before | After |
|---|---|---|
| Share of preserved pages | 61% | 98% |
| Pages with 404 | ~1,200 | a handful |
| Reindexing recovery | not completed | 3-4 weeks |
| Return of organic traffic to previous level | — | 5 weeks |
| Duplicate meta data | ~30% of pages | less than 2% |
The key point: traffic didn't just return — in a number of sections it grew, because along the way we removed duplicates and merged scattered pages into proper hubs.
We worked according to a methodology close to what Google Search Central describes for changing site structure: redirect map, preserving addresses where possible, monitoring crawl errors.
What if some content is decided not to be migrated? We don't leave such pages hanging — we return 410 or merge them with the nearest relevant material via 301, otherwise we get soft 404s and diluted link equity.
What if the site is multilingual? Then the mapping is built taking language versions into account, and hreflang is checked separately — otherwise the search engine will merge the wrong pages.
Describe your task — we'll come back with an estimate and a migration plan.
Doubts before migration: compatibility, rollback, access
A content migration strategy breaks not on data transfer, but at the joints: the old stack serves content differently than the new one expects, rights to sources are smeared across contractors, and no one has a rollback plan.
Compatibility during migration is checked before the start — we verify export formats, encodings, URL structure, and how each system serves relationships between materials.
If a source cannot export the section tree or tags, that surfaces on the first run, not on the night of the switch.
What if the new site won't accept part of the content? Then an intermediate layer does the work: content is exported into a neutral format, brought to the target schema, and only then uploaded. Broken links and lost attachments are caught at this stage — before they make it into the index.
And if something goes sideways after the switch? The rollback plan is documented in writing: the point of return, the order of actions, who makes the decision to roll back.
The domain and addressing remain manageable, so returning to the previous version is an operation of minutes, not a blind restore from backup.
Who will have access to what? We describe access and rights as a matrix: who reads, who writes, who can change redirect rules. Excess rights are closed after handover, and service accounts are not left hanging.
What to do if part of the content has to be migrated manually?
Manual migration is planned in advance: we determine the share of such materials, record them in a separate list, and check against it after the switch. That content doesn't get lost between automated runs.
The client receives:
- a redirect map from old addresses to new ones, with checks for chains and loops;
- a migration scheme: sources, intermediate layer, target structure;
- an access policy and a rights matrix by role;
- migration documentation with the point of return and the rollback procedure;
- a reconciliation report: how many materials there were, how many arrived, what went into the manual list;
- a post-switch verification procedure — which addresses, sections, and forms are tested first.
Describe your task — we'll come back with an estimate and a plan: what we check for compatibility, where we set the point of return, and what access will be needed from your side.
