Content audit before migration: where pages get lost
Site migration almost never breaks at the transfer stage — it breaks earlier, when content is moved "as is" without verifying exactly what is being migrated.
A content audit before migration is an inventory of all URLs, sections, and the links between them before the old site is shut down. Without it, typical failures surface only after launch, when search engines recrawl the new site and register the losses.
The first and most costly failure is broken links and lost URLs.
Some pages get new URLs during the transfer without redirect rules, while others simply don't make it into the export: they remain in the old catalog, in a separate database, or in a section that "seems to be needed by no one." Each such page drops out of the index, and the traffic it brought isn't redistributed — it simply disappears. The older the site, the more accumulated URLs there are, and the more noticeable the drop.
The second failure is a broken section structure.
If the catalog, blog, and reference materials are migrated separately, the nesting and URL logic change, and along with them the internal linking collapses: internal links point to non-existent URLs, breadcrumbs show the wrong path, and related materials stop finding each other.
Search engines read such a structure as new and rebuild it from scratch — that takes weeks, and throughout that time rankings are unstable.
The third failure is duplicates. The same page remains accessible at several URLs: old and new, with parameters and without, with a trailing slash and without. Duplicates dilute weight between copies, and none of them ranks the way the original ranked.
Separately, orphan pages surface — they are in the export, but no link points to them, so they aren't crawled at all.
A content audit closes all three failures before the transfer: it reconciles the full list of URLs, fixes redirect rules, and checks the section structure and internal linking on a copy. Let's break down how this works in our process.
What a Preliminary Content Audit Delivers
A preliminary content audit is an inventory of all pages before migration begins: which URLs are alive, which duplicate each other, which are outdated and should be closed, and which must retain their address.
Based on our experience, on a typical corporate website 15-25% of pages turn out to be junk: test sections, duplicates with parameters, drafts that made it into the index.
If they are migrated "as is," they will drag along broken links and diluted weight — and rankings will drop after launch, when fixes are most expensive.
The main effect is preserving rankings.
When the map of addresses and redirects is built in advance, rather than reconstructed from logs after traffic drops, 90-95% of pages with organic traffic migrate without losing visibility: each old link gets one precise destination address, with no chains or intermediate hops.
The share of errors after migration drops severalfold — from the typical 10-15% broken links and "soft" errors down to single digits, because verification follows a list rather than waiting for complaints.
Migration speed increases because the team does not edit content during the process. Decisions are made in advance: what to migrate verbatim, what to rewrite, what to close.
Manual fixes after launch take a day or two instead of a week — fixes concern only exceptions, not the entire array. The redirect map becomes a working document: it is handed to the developer as a specification, rather than assembled on the fly.
Quality control stops being a matter of taste. Every page has a criterion: retains traffic, merges with another, goes to the archive.
This eliminates arguments about "whether this page is needed" and makes migration acceptance verifiable — by a checklist, not by gut feeling.
Content migration approaches: comparing options
Content migration is not "copy the database and deploy it." In practice, the choice of approach determines how many manual edits you will have to make after launch and how quickly search engines will reindex the new address.
Below are four working options that teams actually choose between on projects, with the honest limitations of each.
| Option | When it fits | Limitations |
|---|---|---|
| Full migration | Structure and URLs are preserved, content is up to date, volume is up to several thousand pages | It drags along outdated and duplicate materials, broken links, and junk metadata — you will have to clean up after launch |
| Selective migration | Some pages generate no traffic and are not needed by the business | It requires a priority map and a decision for each group; risk of losing a page that was driving visits |
| Phased migration | Large site, work cannot be stopped, there are dependent sections | A long period when the old and new environments run in parallel; redirects and synchronization are needed at every stage |
| Structure rebuild | The logic of sections, navigation, and taxonomy is changing | The most labor-intensive: URLs, internal links, and templates are rewritten, and the volume of edits grows |
How the choice is made in practice
Full migration is chosen when the site is small and the structure is satisfactory — then the task comes down to correctly setting up redirects and checking that no page returns an error.
Selective migration is advantageous when there is traffic analytics: we migrate what works, and archive the rest while preserving the addresses.
Phased migration is a compromise for large projects: we split it into sections, migrate one at a time, and close each stage with a check of indexing and links.
A structure rebuild is justified if the old navigation gets in the way of the user and search — but it is planned as a separate stage, not combined with the migration.
The limitation is common to all approaches: without content inventory and a redirect map, any option causes a traffic drop. That is why the choice is locked in before the start, not along the way.
How a content audit works: stages of the process
A content audit is not "looking over pages with your eyes" but a sequence of operations where each step produces an artifact for the next.
We start with an inventory: we pull a complete list of URLs from the sitemap, server logs, and internal links in order to catch pages that are not in the navigation but that are linked to or receive search traffic.
- Page inventory. We collect all URLs into a single table: title, page type, number of incoming internal links, impressions and clicks over recent months, date of last change. Discrepancies between the sitemap and the logs immediately reveal forgotten sections and duplicates.
- Value assessment. We assign each page a class: core (brings traffic and conversions), supporting, outdated, duplicate. The decision for each one is to keep, rewrite, merge, or unpublish.
- URL scheme. We design the target structure: which sections keep their previous URLs, which change, and where we introduce a unified template. We record a mapping table "old URL → new URL" — this is the basis for redirects.
- Redirect setup. Using the table, we set up permanent redirects from old URLs to new ones, including chains and variants with and without a trailing slash. We handle pages we are unpublishing separately: we point them to the closest section by meaning, not to the homepage.
- Post-migration check. We go through all URLs from the table and make sure each one returns a correct response rather than an error. We verify the sitemap, internal links, and canonical URLs against the new structure.
- Handover and monitoring. We hand over the mapping table, the URL scheme, and the list of redirects so the team can repeat the check. For the first weeks after launch, we monitor for errors and lost clicks.
This order closes the main risk of migration — the loss of accumulated traffic due to broken URLs. Describe your task — we will come back with an estimate and a work plan.
What the client receives as a result of the audit
The audit ends not with a presentation, but with a set of working artifacts that the team uses to carry out the migration without improvisation.
Each document covers its own class of decisions: what we migrate, where we direct traffic, what we discard, and how we verify the result.
- Page inventory — a table for each address: current URL, content type, traffic and rankings, target address after migration, status (migrate / merge / delete). It shows the scope of work and ensures nothing is lost during migration.
- Redirect map — a "source → target" rule for each old address, including chains and query parameters. It addresses the main migration risk: the loss of accumulated traffic and link equity.
- Exception rules — what we do not touch and why: service sections, pages under active campaigns, addresses with external integrations. It resolves contentious decisions before the start, not during the process.
- Duplicate report — groups of pages with identical or near-identical content, with a recommendation: merge, keep one as canonical, or exclude from indexing. It eliminates internal competition for the same queries.
- Verification protocol — an acceptance checklist after migration: address reconciliation, response codes, redirect correctness, availability of key pages. It allows the result to be accepted objectively, not "by eye."
Additionally, we provide a structural diagram of the new site and a list of addresses that need to be re-crawled after launch.
These artifacts remain with you as a working document — they can be used to conduct the next migration or hand the project over to another team without losing context.
Case study: migrating an online store without losing sections
An online store on an old platform had accumulated a catalog that no one had reviewed for years: some sections duplicated each other in meaning, some product pages linked to items no longer for sale, and the category tree had grown so deep that filters in the listing stopped working.
A "as is" migration would have moved this entire structure to the new platform along with the clutter — and the rise in errors in search, filters, and product pages would have been baked in before launch.
What the preliminary review showed
We began the content audit before migration not with the transfer, but with an inventory: we exported all catalog URLs, cross-checked them against actual product availability and the visitor navigation map.
It turned out that a noticeable share of sections brought neither traffic nor orders, yet dragged along chains of internal links.
We identified three classes of problems: semantic category duplicates, product pages without current items, and broken links between sections and filters.
How we migrated
We did not copy the structure but rebuilt it according to rules: one canonical URL per category, duplicates — into a permanent redirect, empty product pages — into an archive while preserving the URL.
We reduced the catalog tree in depth, and tied filters to product attributes rather than to manual value lists. Separately, we ran the navigation map: we checked that not a single working URL returns an error or leads to a dead end.
Result
After launch, the share of errors in the catalog dropped from 12% to 1.5% — mainly due to the disappearance of broken links and duplicates. The number of sections was reduced by roughly a third without losing traffic: the transitions were redistributed to canonical URLs.
Search and filters began responding faster, and the content team stopped spending time on edits in the overgrown tree.
How does a content audit differ from a technical site audit?
A technical audit answers the question "does the site work": page availability, correctness of server responses, delivery speed, broken links, duplicates, indexing, behavior under load. It says nothing about whether it makes sense to migrate every page to a new platform.
A content audit answers a different question — "what exactly are we migrating and in what form": which materials retain value, which duplicate each other, which are outdated and only bloat the structure.
The difference in approaches is visible in a concrete example. A technical audit will show that all pages return a success response code and open quickly — formally, everything can be migrated.
A content audit, meanwhile, will reveal that forty materials describe the same service in different words, some texts reference discontinued products, and half the sections are not connected by internal linking.
Migrating in this form simply replicates the chaos on the new site, and later it will have to be sorted out in production.
Migration tasks require both perspectives at once. A content audit provides a content map: what to merge, what to rewrite, what to remove from the index, how to structure the site and navigation.
A technical audit provides a map of addresses and connections: which URLs change, where redirects are needed, which pages must not be lost due to accumulated traffic. Without the first map, you migrate the unnecessary; without the second, you lose what brought visitors.
The practical order is this: first, an inventory of content and a decision for each page — keep, merge, rewrite, remove — then cross-checking against technical data on traffic and link weight, and only after that, designing the new structure.
This way, the decision to delete is based not on taste but on data, and the redirect map is built from a real list of addresses rather than reconstructed after the fact from logs.
The bottom line: a technical audit is about functionality, a content audit is about meaning and structure. For migration, they do not replace but complement each other: one prevents losing what works, the other prevents migrating what is dead.
Common technical concerns before migration
The first concern is what to do with outdated pages. They are not "migrated just in case": each such page carries weight in the index, blurs the topic of the section, and creates duplicates.
During the audit, we mark them into three groups: keep and update, merge with a current one, close with a redirect to the closest in meaning.
If a page is simply deleted, external links and accumulated traffic will go nowhere — that is why closing always goes through a redirect rule, not through deleting the file.
Nested addresses are the second risk point. A structure like "section/subsection/page" maintains hierarchy and navigation logic, and during migration it is easy to "flatten" it into a flat list.
We fix the address map before work begins: each old link gets exactly one new address, without chains of multiple redirects — a long chain slows down response and loses part of the signal.
Separately, we check addresses with parameters and trailing slashes so as not to end up with two versions of the same page.
Is manual content migration necessary?
Fully manual migration is justified only on small sites with heterogeneous markup. At scale, we migrate content with a script based on a pre-captured map, and manually fix what the script cannot parse: embedded forms, tables, non-standard blocks. This way the migration proceeds predictably and without loss of text.
What will happen to rankings after migration?
Short-term fluctuations are possible — the search engine needs time to re-crawl the new addresses. The risk is mitigated by the redirect map and by the fact that the section structure is preserved. We verify indexing after migration and address any remaining discrepancies.
How do you know that the content audit has been carried out fully?
The sign is not a report, but a map: every page has a decision (keep, update, merge, close) and a destination address. If there is no decision for some pages, the audit is not finished — it is precisely in these "gray" areas that traffic is lost.
Let's discuss your migration task
To come back with an estimate and a parsing plan, we need to understand your current structure and migration goals. Describe the task — which sections are moving, what changes in the architecture, whether there are hard deadlines for shutting down the old site.
The more specific the input, the more accurate the estimate: parsing content, internal linking, and redirects are calculated differently depending on the volume and number of templates.
Then we work in this order:
- Inventory. We compile a complete list of pages, files, and media from the current site — including what didn't make it into the section map and lives by direct links.
- Value tagging. We assign a status to each page: keep as is, rewrite, merge with another, or remove from the index. We record the decision in writing so that no disputes arise during the migration stage.
- Duplicate and "orphan" check. We find pages with duplicate content and those with no internal links — these are the ones that most often lose rankings after migration.
- Redirect map. We build a "old address → new address" table with a 301 status for each page, including nested and parameterized links.
- Migration and verification. We upload the content, check headings, meta descriptions, and markup, run a crawler, and make sure there are no broken links.
- Post-launch support. We monitor indexing and traffic for the first weeks, cleaning up what surfaces on the live site.
We send the estimate and parsing plan after a short conversation — with stages, timelines, and what will be required from your side.
