You score a page migrate, rewrite, or kill by asking three questions, in this order: does anyone (a human or a machine) actually reach it, is it good enough to keep exactly as it is, and would fixing it cost less than the traffic it brings in. Answer those three before anyone opens the new CMS, and the tag writes itself. Everything after that is paperwork.
Here's the thing that pushed me to write this down. The default plan on almost every migration is move everything. Not because anyone believes the 40,000-page archive is 40,000 pages of gold, but because deciding is harder than dragging. So the whole attic comes across, the launch slips, the crawl budget gets spread across a warehouse of pages nobody's read since a Bush administration, and three months later someone in a meeting asks why the good pages aren't ranking. They're not ranking because you buried them.
So let's do triage instead. Not the emergency room kind where everyone's shouting, the calm kind where you walk the line of beds first and put a colored tag on every wrist before you decide who gets a doctor.
You are the intake nurse, not the surgeon
Triage is not treatment. The mistake teams make is trying to fix pages while they're still deciding whether the pages should live. That's the surgeon showing up at intake and wanting to operate on everyone. Your job at this stage is faster and colder: put a tag on the wrist and move to the next bed.
The tag comes from three vitals, and you take them in order because the first one can send a page straight to the morgue before you waste a second on the other two.
Vital one: does anything reach it?
Pull server logs, analytics, and your internal link graph. A page with no inbound internal links, no external links, no organic entrances in twelve months, and no crawler hits is not a page. It's a file. Nobody is going to miss it, because they can't find it now, on the site that's already live. (If you can't find it, and Google can't find it, and the AI answer engines never cite it, who exactly are we migrating it for?) That's your first pile of kill tags, and it's usually bigger than anyone wants to admit.
Vital two: is it good enough as-is?
Whatever survives vital one gets read, or at least skimmed against a rubric. Is it accurate, is it complete, does it match the query it ranks for, is it a near-duplicate of a better page three folders over. A page that earns traffic and holds up to reading is a clean migrate. Lift it, redirect it, don't touch a word. A page that earns traffic but reads like it was written for a 2014 keyword-density tool is a rewrite: the URL and the demand are worth keeping, the words are not.
Vital three: does the fix pay for itself?
This is the one people skip, and it's the whole game. A rewrite costs real hours. If a page pulls forty sessions a year and would take a specialist half a day to fix, you are spending a mortgage payment to save a coupon. Downgrade it to kill and redirect it to the nearest better page. Save your rewrite budget for the pages where the math actually clears.
The tags, and what puts a page in each
| Tag | Signals that earn it | What you do at cutover |
|---|---|---|
| Migrate | Real traffic or citations, holds up when read, no better duplicate exists | Move as-is, keep the URL, redirect if the path changes |
| Rewrite | Real demand for the topic, but the content is thin, dated, or off-target | Keep the slot, rebuild the content before or shortly after launch |
| Kill | No reach, or a near-duplicate, or a fix that costs more than the traffic returns | 301 to the closest surviving page, or let it 410 if truly orphaned |
Notice that "kill" almost never means "delete and walk away." A killed page still owns any links pointing at it, so it gets redirected to its nearest living relative. Killing the page is a content decision. Forwarding its mail is a redirect decision. Don't confuse the two, or you'll strand equity you spent years earning.
Why this has to happen before the build
Because template decisions cascade from page decisions, not the other way around. If you build the templates first and triage second, you end up designing a components library for pages you were going to throw out anyway, and every kill you make afterward feels like admitting you wasted the work. Do the triage first and the build gets smaller, cheaper, and honest. You model templates for the pages that survived, not for the whole ghost town.
This is the unglamorous, spreadsheet-heavy front half of a migration, and it's exactly the part a machine should be doing while you sleep. Scoring reach, spotting near-duplicates, flagging orphans, and turning it all into a per-page tag with the evidence attached is the job we built the migrate/rewrite/kill scoring to do, precisely because doing it by hand across 40,000 beds is how migrations slip a quarter.
What I'd actually do
I'd triage the whole inventory before I let anyone name a single content type. I'd be ruthless at vital one and generous with redirects, because an orphaned file costs nothing to kill and a killed link costs you rankings. And I'd treat the rewrite pile as a budget, not a wish list: rank it by traffic-per-fix-hour and draw a line where the money runs out, knowing full well the pages below the line will haunt me in a status meeting eventually.
Move everything and you haven't made a decision, you've just postponed it and paid to ship it. Triage first, and the truck that pulls up on cutover day is carrying a site, not an attic.