A pre-migration content inventory predicts what breaks at cutover only if it links four things per URL: the page's current traffic and rankings, its inbound and internal links, every asset and template it depends on, and its planned destination URL. A spreadsheet that lists titles and word counts tells you nothing about risk. The inventory that actually predicts breakage is a dependency graph, not a page list — it answers "if this URL changes or dies, what else fails?" before you find out in production.
Most migrations break in predictable, boring ways: redirect chains that drop link equity, orphaned PDFs that were never in the CMS, hardcoded internal links pointing at old paths, and high-value pages nobody flagged because they had low pageviews but high conversion or backlinks. A good inventory surfaces all four 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.
Build it as a graph of value and dependency, decide the fate of every URL explicitly, and verify against staging. Do that and cutover becomes a controlled event instead of a discovery process. For platform-specific redirect and template mapping notes, see the guides under /migrate.