Type your own best-selling product into Google sometime and see what comes back first. Odds are decent it's a PDF you'd forgotten you ever made: a spec sheet from three years ago, no logo you'd recognise, linked from nowhere on your actual site, quietly pulling in the exact buyers you're paying an agency to chase. Nobody owns it. Nobody knew it was there. And on migration day, nobody exports it, because it never lived in the CMS to begin with. That's an orphaned asset, and it has a twin: the three near-identical pages the old system spawned from tag archives, print views, and session parameters that all rank a little and consolidate to nothing. Both look perfectly fine in the demo. Then six weeks after launch someone opens the organic report, it's down, and no one can say why. This article is about those two quiet killers: what each one is, why migrations manufacture them, and how to catch them while you still can.
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.
So here's what I actually think: run both audits four to six weeks before go-live, not because it's tidy but because that window is the only time the fix is cheap. You still have room to link orphans back in, write canonicals into the new templates, and prove your redirects on staging before real traffic ever touches them. Do it after launch and the same reconciliation stops being prevention and becomes recovery, which is the gentle word for reconstructing what you lost one 404 at a time. Recovery always costs more traffic, every time. If you only take one thing from me, take this: the forgotten PDF at the top of your own search results is not an edge case, it's the warning. Find it before your cutover does.