Here is the whole decision, before the metaphors kick in: you tag a page migrate when it earns something (traffic, links, answers, revenue) and a machine can still read and reach it; you tag it rewrite when it clearly matters to real people but the page itself is broken, thin, or stale; and you tag it kill when nobody visits it, nothing links to it, and something else already does its job better. That is it. Everything below is just how you get to those three words without lying to yourself.
Picture the night before a house move. Three piles by the front door. Keep, fix, toss. The keep pile goes on the van as-is. The fix pile is the chair with the wobbly leg you swear you'll glue this time. The toss pile is the George Foreman grill you used twice in 2016.
Migration is that, except you're doing it for four thousand pages, and every one of them insists it's the George Foreman grill of somebody's dreams.
Why score before you touch a template
Because moving cost scales with volume, and most sites are hoarders. I have never once opened an inventory and thought "wow, exactly the right number of pages." There's always a decade of press releases, three versions of the same PDF, a landing page for an event in 2019, and a tag archive nobody knew the CMS was generating.
If you migrate all of it, you pay to rebuild templates, re-QA, and redirect junk. If you kill it blindly, you strip a link somebody important is still following. So you score first. You decide what's on the van before you argue about what the van looks like.
The three questions each page has to answer
Every page gets three interrogations, and it needs to pass all three to earn a clean "migrate."
First, does it earn anything? Pull organic clicks and impressions from Search Console, referring domains from a backlink tool, internal links pointing at it, and, increasingly, whether it shows up in AI answers for anything you care about. A page with zero clicks, zero external links, and one internal link (from a sitemap it generated itself) is not pulling its weight.
Second, can a machine actually read and reach it? Status code, canonical tag, robots directive, whether it's an orphan with no path in from the navigation. A page returning 200 that no crawler can find is a locked room with the lights on.
Third, does something else already do the job? Near-duplicate body copy, two URLs targeting the same query, a printable version competing with itself. When two pages fight, Google usually picks one and buries the other, and you've been paying rent on both.
The scoring grid
| Value (traffic, links, answers) | Machine health (crawl, index, canonical) | A better version exists? | Verdict |
|---|---|---|---|
| High | Healthy | No | Migrate as-is |
| High | Broken or thin | No | Rewrite before you move it |
| Low but has real links | Any | No | Consolidate, then redirect |
| Low | Any | Yes | Kill and redirect to the winner |
| Zero | Orphaned | Doesn't matter | Kill (410 or redirect a parent) |
Notice "kill" almost never means "delete and walk away." A killed page with even one decent backlink still deserves a 301 to its nearest living relative, because that link equity is real and free. You're not throwing the George Foreman grill in the bin. You're leaving a note that says the good stuff moved to the kitchen.
The trap: recency bias and sentimental value
The wobbly-chair pile is where migrations go to die. Everybody has a page they're sure is one rewrite away from greatness. Sometimes they're right. Mostly they're gluing the chair for the fourth time.
Be honest about the fix pile's size. Rewriting is real work with a real cost, and if the rewrite pile is bigger than your writers can clear before cutover, it isn't a rewrite pile. It's a second migration you haven't budgeted for. When in doubt, a page that hasn't been updated in five years and earns nothing is not "about to turn a corner." It's furniture.
And watch the sentimental owner. Somebody in the building loves that 2019 event page because they built it. That's a fine reason to keep the memory. It is not a reason to redirect crawl budget toward it forever.
Do this while the old site is still standing
The one thing you cannot recover after cutover is the evidence. Once the old URLs are gone, you can't re-pull their Search Console history or re-check who linked to them. Score while the patient is still breathing. Crawling a whole site and cross-referencing traffic, links, duplication, and crawl health by hand is grim work, which is exactly the sorting a tool like Replatform Radar does before you move: every page and asset lands in a migrate, rewrite, or kill bucket with the reason attached, so the argument happens over data instead of feelings.
You don't need software to start, though. A crawl export, a Search Console pull, and a backlink dump in the same spreadsheet will get you eighty percent of the way. The three questions do the rest.
So what would I actually do
I default to kill. Genuinely. I make every page argue for a seat on the van, and I let the quiet ones lose. Sites don't get slow and unfindable because someone deleted too much; they get that way because nobody ever deleted anything. A leaner site after migration crawls faster, ranks cleaner, and gives you less to redirect and less to break.
Keep the pile by the door small and the van will be lighter than you feared. And if someone fights to save the George Foreman grill, let them carry it up the stairs themselves.