Orphaned assets and duplicate content are the two failure modes that survive almost every migration launch checklist. Redirects get mapped and templates get QA'd, but nobody owns the PDF that ranks for a high-intent query yet links from nowhere, or the three near-identical pages the old CMS spawned from tag archives, print views, and session parameters. Both problems are invisible in a demo and expensive in the organic traffic report six weeks later. This article explains what each one is, why migrations create them, and how to catch them before go-live.
Why migrations manufacture both problems
A replatform is a mass content move, and mass moves expose whatever the old system was quietly generating. Legacy CMSes produce duplicate URLs through pagination, faceted navigation, tracking parameters, HTTP/HTTPS and www/non-www variants, and CMS-specific artifacts like ?print=1 or /node/1234 aliases. On the old domain, canonical tags and years of accumulated redirects held that mess together. A migration strips those bindings and re-exposes the raw URL sprawl on a new URL structure — often multiplying it.
Orphaned assets are the mirror image. Every site accumulates files — PDFs, images, spec sheets, whitepapers, old campaign landing pages — that earn links and rankings but are no longer surfaced in navigation or internal links. During migration, teams inventory pages from the CMS database. Assets that live outside the content tree, or pages that were only ever reachable via an external backlink, simply don't appear in the export. They get dropped, 404, and take their link equity with them.
Duplicate content: the slow dilution
Duplicate content rarely triggers a manual penalty. The damage is subtler: Google has to choose which version to index, splits crawl budget across copies, and dilutes internal link signals across URLs that should have consolidated into one. After a migration, this gets worse because you've reset the canonical and redirect history the old site relied on.
The common sources
- Parameter variants — sort, filter, and session parameters creating thousands of thin near-duplicates.
- Protocol and host duplicates — HTTP vs HTTPS, www vs non-www served as separate indexable pages.
- Trailing-slash and case inconsistencies —
/about,/about/, and/Aboutall resolving 200. - Templated boilerplate — location or product pages that differ only by a name, flagged as thin duplicates.
- Migration doubling — content published on both the staging domain and production, or old and new URLs both live during a phased cutover.
How to fix it before launch
- Crawl the full old site (not just the sitemap) and cluster pages by content similarity, not URL.
- For each cluster, pick one canonical target and 301 the rest to it — don't rely on
rel=canonicalalone for URLs you can retire. - Reserve
rel=canonicalfor parameterized variants you must keep live, and make sure the new CMS emits it consistently. - Confirm one host and one protocol resolve; everything else 301s.
- Block staging from indexing with authentication, not just
robots.txt— a disallowed staging URL can still get indexed if it's linked.
Orphaned assets: the equity leak
An orphaned asset is any URL that earns traffic, rankings, or backlinks but has no internal path to it. The classic case is a PDF that ranks on page one for a commercial query and pulls links from industry sites — but isn't linked from a single page you control. When the migration inventory is built from the CMS, that file is invisible, so it isn't migrated, isn't redirected, and returns a 404 the day you cut over.
The only reliable way to find orphans is to reconcile multiple data sources, because no single source sees them all:
| Source | Finds | Misses |
|---|---|---|
| CMS export | Managed pages and media | Files outside the content tree, backlink-only URLs |
| Server logs | Anything Google/users actually request | Low-traffic-but-linked pages |
| Google Search Console | URLs earning impressions/clicks | Assets with links but no ranking yet |
| Backlink tools | Externally linked URLs | Internal-only orphans |
| XML sitemap | What the site claims exists | Everything the old CMS forgot to list |
Union those lists, subtract the crawlable set, and what remains is your orphan candidate list. Each one needs a decision: link it back into the new site, redirect it to the best equivalent, or deliberately kill it and let it 410. The mistake is making no decision — that's how a 404 becomes permanent.
Turn the audit into a migrate / rewrite / kill plan
Both problems resolve into the same three verbs. Duplicate clusters and orphaned assets should each land in one bucket:
- Migrate — the canonical version, or the orphan with real link equity, moves and gets a preserved (or redirected) URL.
- Rewrite — thin templated duplicates get consolidated or expanded into one page worth ranking.
- Kill — genuine dead weight is 410'd or redirected, so it stops draining crawl budget on the new platform.
This is exactly the reconciliation work a pre-migration content audit exists to do: crawl the old estate, cross-reference logs, Search Console, and backlink data, and score every page and asset so nothing high-value falls through the export gap. It's the core of what Replatform Radar produces before a cutover.
The one-line takeaway
Redirect maps protect the pages you know about. Orphan and duplicate audits protect the ones you forgot — and those are usually the ones still ranking.
Run both audits at least four to six weeks before go-live, while there's still time to add internal links, write canonicals into the new templates, and confirm redirects on staging. After launch, the same reconciliation becomes a recovery project instead of a prevention one — and recovery always costs more traffic than prevention.