The most expensive page on a site I looked at pulled in twelve visits a month. Nobody put it on any save list, because who fights for twelve visits? It also happened to hold most of the backlinks pointing anywhere near that whole section, and when it quietly 404'd at cutover, the rankings sitting above it sagged right along with it. That page taught me the thing I keep repeating: a content inventory sorted by traffic and word count is a list of the pages you'll remember to save, which is a completely different list from the pages that will hurt you when they go.
A pre-migration inventory only predicts what breaks if it ties four things to every URL: the page's current traffic and rankings, its inbound and internal links, every asset and template it leans on, and where it's supposed to land after the move. Titles and word counts tell you nothing about risk. The inventory that earns its keep is a dependency graph, not a page list, and it answers "if this URL changes or dies, what else goes down with it?" before production answers it for you. Most migrations break in dull, predictable ways: redirect chains that quietly leak link equity, orphaned PDFs someone uploaded by FTP in 2019 and forgot, hardcoded internal links still pointing at the old paths, and the high-value pages nobody flagged because the pageviews were tiny but the backlinks or the conversions were not. A good inventory drags all four into the light before cutover.
Start with a complete crawl, not a CMS export
Your CMS export lists what the CMS knows about. It does not list the marketing landing pages on a subdomain, the campaign PDFs uploaded to /assets/, the legacy blog on a different template, or the pages generated by a plugin. Cutover breakage lives precisely in those gaps.
Build the inventory from the union of three sources:
- A full site crawl that follows internal links, sitemaps, and rendered JavaScript so you catch client-side routes and lazy-loaded content.
- Server logs (30–90 days) to find URLs that receive real traffic, including ones no link points to anymore.
- Search Console and your analytics platform for the URLs Google actually indexes and sends clicks to.
The difference between these sets is your risk list. A URL that gets organic clicks but appears in no crawl is an orphan that will silently 404 at cutover.
Score every URL on signals that predict loss
Once you have the master list, attach the columns that let you rank risk. A URL is dangerous when it combines high value with high fragility. Capture these per row:
| Signal | Why it predicts breakage |
|---|---|
| Organic clicks / impressions | Quantifies what you lose if the URL 404s or loses ranking |
| Referring domains to the URL | Backlinks don't follow soft redirects reliably; deep-linked pages need exact 301s |
| Internal links in / out | High in-degree pages, if moved, break navigation and dilute crawl paths |
| Canonical and indexation status | Reveals existing duplication you shouldn't carry forward |
| Template / component dependencies | Pages sharing a template break together when that template isn't rebuilt |
| Asset references (PDF, video, JS) | Assets often live outside the CMS and get left behind |
| Last meaningful update | Separates evergreen assets from dead weight |
This is roughly the analysis Replatform Radar runs automatically, scoring duplicate content, orphaned files, and redirect risk so each page lands in a migrate, rewrite, or kill bucket. The point of any tool here is to make the risk visible before you commit URLs.
Map dependencies, because pages don't break alone
The single biggest predictor of a broken cutover is a page whose dependencies weren't migrated. Three dependency types matter:
- Structural, the template or component the page renders with. If your new platform rebuilds "article" but not "case study," every case study breaks at once.
- Referential: internal links, embedded assets, and hardcoded absolute URLs in body content. Search your content for old-domain and old-path strings; these are the links redirects can't fix because they're baked into HTML.
- Functional, forms, personalization tokens, tracking scripts, and gated-content logic that a static crawl won't reveal but that users notice immediately.
Group URLs by shared template and shared asset so you can test in clusters. When one page in a cluster works, the rest usually do, and when one fails, you know the blast radius.
Turn the inventory into a redirect and disposition plan
Every URL needs an explicit decision. Don't let "we'll redirect everything to the homepage" happen: that destroys link equity and confuses answer engines that cite specific pages.
- Migrate 1:1, high value, still relevant. Needs an exact 301 to a live equivalent.
- Consolidate, duplicate or thin pages. Redirect to the strongest surviving version and update internal links to point directly at the target, not through a chain.
- Rewrite: good URL and demand, weak content. Keep the path, replace the body.
- Kill: no traffic, no links, no purpose. Return 410 (gone) rather than redirecting noise into your new site.
Validate redirects before launch: no chains longer than one hop, no loops, and every 301 resolving to a 200. Redirect chains are the most common post-migration ranking loss, and they're entirely preventable with a pre-cutover check against the inventory.
Test the prediction against a staging crawl
An inventory that predicts breakage should be falsifiable. Crawl the staging environment and diff it against your migrate list:
- Every "migrate" URL should have a live destination returning 200.
- Every planned 301 should resolve correctly and preserve the canonical.
- No URL that had organic clicks should be missing from staging without an explicit kill decision.
- Assets referenced in migrated content should all resolve on the new host.
The gap between what you predicted and what staging shows is your remaining risk, and you found it before real users and Googlebot did.
The one-sentence test for a good inventory
If you can point to any URL in the site and instantly answer "what happens to this at cutover, what depends on it, and how much traffic is at stake," your inventory predicts breakage. If you can't, it's just a list.
So here's what I actually think, no hedging: build the thing as a graph of value and dependency, rule on the fate of every URL by name, and diff the whole plan against a staging crawl before a single visitor lands on the new site. If you only have time for one of those, do the dependency mapping, because that's where the surprises hide and traffic sorting will lull you into missing them. Do all three and cutover stops being the day you learn what mattered one 404 at a time. It turns into a controlled, slightly boring event, which is the best kind. And that twelve-visit page? On a proper inventory it never sneaks past you, because you'd already know it carried the backlinks, and you'd have written its exact 301 before anyone flipped the switch. For platform-specific redirect and template mapping notes, see the guides under /migrate.