A pre-migration content inventory predicts what breaks at cutover only when it records how each page is loaded — its traffic, its inbound links, its redirect history, its asset dependencies — and not merely that the page exists. A flat list of URLs tells you nothing about risk. A list of URLs joined to status codes, canonical tags, internal link counts, search impressions, and referenced files tells you, with unnerving accuracy, which pages are going to fall off the truck somewhere around mile three hundred.
Picture the night before a long road trip. You've packed the car. You assume everything works, because everything worked last Tuesday when you drove to the shop. Then, forty minutes past the last exit with a gas station, a light comes on that you have never seen before and cannot name. That light is your migration going live at 2am while the whole department watches Search Console like it's a heart monitor.
The inventory is the pre-trip inspection. Done properly, it is boring, and boring is the entire point.
Most inventories describe the car and never look under the hood
The default export from any crawler gives you a wall of URLs. That's the parking lot. It tells you how many vehicles you own and nothing about which ones will start. I've watched teams treat a 40,000-row spreadsheet as an accomplishment, ship it to the migration vendor, and then act surprised when the pages that mattered came back with the check engine light on.
The difference between a parking lot and an inspection is the columns you join in. Each one answers a specific question about whether a page survives the drive.
| Column | What it actually predicts |
|---|---|
| HTTP status + redirect chain | Pages already on their second or third redirect. Migrate them naively and you build a chain that loops or dead-ends. |
| Canonical tag | Pages quietly pointing elsewhere. Move the wrong one as the "real" page and you resurrect a duplicate you'd buried. |
| Internal inbound links | How load-bearing the page is. A page 400 other pages point to is a structural beam, not a leaf. |
| Search impressions (last 90 days) | Whether anyone would notice it vanishing. This is your triage line. |
| External backlinks | Equity you cannot regenerate. Lose the URL, lose the link, and no rewrite gets it back. |
| Referenced assets | The PDFs, images, and downloads a page depends on. These are the parts that don't come in the box. |
| Template / content type | Whether the target platform even has a mapping for it. No mapping means a manual rebuild. |
| Last modified date | Staleness. A page nobody has touched in four years is a candidate to kill, not carry. |
Notice what these have in common. Not one of them is visible from the URL. You can only get them by crawling the live site and joining that crawl to analytics and to your backlink source before you move a single thing.
The two columns that do the most predicting
If I could keep only two, I'd keep inbound links and impressions, and I'd multiply them together in my head.
A page with high impressions and high inbound links is the beam holding up the roof. It gets a redirect written by a human, verified twice, before anything else moves. A page with high impressions and zero inbound links is often an orphan that ranks anyway — traffic arriving with no internal path to it, which means your new information architecture might strand it entirely without anyone noticing until the quarter closes. A page with lots of internal links and no impressions is usually a navigation artifact, safe to consolidate. And a page with neither? That's the box in the attic you've carried between three apartments and never once opened.
Kill it. (You won't. But you should.)
Where the breakage actually hides
The genuinely dangerous rows are the ones that look fine in isolation and are lethal in combination. A page returning a clean 200, with decent traffic, that references a PDF living on a subdomain the migration scope quietly excluded. The page moves. The link stays. The file doesn't. Now you've got a 200 page with a 404 heart, and nobody catches it because the crawler said the page was healthy.
This is why the inventory has to model dependencies, not just pages. Assets, redirect targets, canonical targets, hreflang partners — every arrow that points from one thing to another is a place the road can wash out. Scoring those relationships before you move is the whole job, and it's the part a raw URL export cannot do. It's also, not coincidentally, exactly what our pre-migration crawl is built to surface: the joins, not just the list.
How to build it so it's actually predictive
Crawl the live site fully, including assets and non-HTML files. Join that crawl to at least ninety days of Search Console impressions and to a backlink source. Trace every redirect to its final destination and flag anything more than one hop deep. Cluster near-duplicate content so you decide the canonical now, not during a panic on launch night. Then, and only then, sort the whole thing by traffic times inbound links and read from the top. The top of that list is your manual, hand-verified redirect work. The bottom is your permission slip to delete.
Do that and cutover stops being a séance. You already know which pages will complain, because you asked them beforehand.
So what would I do?
I'd refuse to accept a URL list as an inventory. Full stop. If the only column is the address, someone has handed you a parking lot and called it an inspection, and you will find out which cars don't start at the worst possible moment — past the last gas station, in the dark, with the whole team watching the monitor. Spend the boring week joining the columns. Boring is the sound of nothing breaking.