Blog

Weed the Shelves: Migrate, Rewrite, or Kill Every Page

· 6 min read · By the Replatform Radar team

Answer first: before you move a page to a new platform, you owe it one honest verdict, and there are only three. Migrate it as it stands, rewrite it, or kill it. Every one of those decisions can be made in a spreadsheet, weeks before anyone opens a template. The trick is to stop treating a migration as a moving job (grab everything, sort it out at the new place) and start treating it as a weeding job.

Here is what prompted the question. You ask the old CMS for a list of every URL, and it hands back six thousand of them. You scroll. Somewhere around row 800 you find a press release from a product that no longer exists. Around row 2,000, three near-identical pages about the same service, written by three different people who never met. And at the bottom, a graveyard of PDFs nobody has opened since a laptop had a CD drive.

The temptation, right there, is to migrate the whole lot. It feels safe. It is not.

Librarians already solved this

Public libraries do not keep every book forever. They can't, because shelves are finite and a shelf full of a 1997 tax guide is a shelf you can't use for something people actually want. So librarians weed. There is a formal method for it, the CREW method (Continuous Review, Evaluation, and Weeding), published by the Texas State Library, and it comes with a wonderful acronym for what earns a book the bin: MUSTIE. Misleading, Ugly, Superseded, Trivial, Irrelevant, and available Elsewhere.

Read that list again with your sitemap open. A page that is factually out of date is Misleading. A page whose layout broke two redesigns ago is Ugly. A page a newer, better one has replaced is Superseded. That thin 90-word FAQ is Trivial. The product-that-no-longer-exists page is Irrelevant. And the fourth copy of your returns policy is available Elsewhere on your own site.

A librarian would not pack those into the moving van. Neither should you.

The three verdicts, and how to earn each one

You do not need a sandbox to assign these. You need traffic data, a backlink export, an internal-link count, and a plain-language read of whether the thing is still true. Line those up against each URL and the verdict mostly writes itself.

VerdictWhen a page earns itWhat you do at cutover
MigrateStill accurate, pulls organic traffic or real referrals, holds inbound links, has pages linking to it internally.Move as-is, same URL if you can, 301 if the URL must change.
RewriteTopic still matters and ranks, but the content is stale, thin, or duplicated by two of its neighbours.Consolidate the duplicates into one page, refresh, then migrate the winner.
KillNo traffic, no links, superseded, or off-strategy. Nobody is coming. Nobody is pointing.301 to the closest living relative, or return a clean 410 if there is genuinely no relative.

Notice what the middle row does. Rewrite is where most of your effort should go and where teams spend the least, because "migrate" feels done and "kill" feels brave, while "rewrite" is just work. That is exactly backwards. Rewrite is where you fold four mediocre pages into one page that finally deserves to rank.

Killing a page does not mean losing its history

The fear that stops people killing anything is a fear of throwing away link equity. Good news, and it is genuinely settled: a 301 redirect passes essentially all of a page's ranking signals to the target. Google's own engineers have said, repeatedly since 2016, that 30x redirects do not cost you PageRank. So killing a dead page by pointing it at a living, relevant one is not a loss. It is a cleanup that keeps the value and drops the dead weight.

The one thing you must not do is let a killed page quietly 404, or worse, redirect everything to the homepage. Google treats a redirect to an irrelevant page (usually the homepage) as a soft 404, which means it behaves as if the page simply died. You did the paperwork and got none of the benefit. That is the redirect equivalent of forwarding someone's mail to a random address and calling it delivered.

Why paper beats the sandbox

Every hour you spend rebuilding a page in the new platform is an hour you have decided that page is worth moving, whether or not you ever made that decision on purpose. Scoring first flips the order. You decide worth, then you spend effort, and only on the survivors. A 6,000-page site is very often a 1,800-page site wearing a trench coat, and the 4,200 you weed out never cost you a single template hour.

This is the part a crawl can do for you before a human reads a word: pull the traffic, the links, the internal-link counts, the duplicate clusters, and the orphans into one scored sheet so the obvious kills and obvious migrates sort themselves, leaving humans to argue only about the genuine maybes. That scoring pass is exactly what a pre-migration inventory is for.

What I would actually do

I would set the default to kill, not migrate. Make every page argue for its seat on the van. A page earns "migrate" by showing traffic, links, or a clear job; if it can't, it gets consolidated or redirected. Yes, that means you will kill pages someone is emotionally attached to, and yes, someone in the meeting will say "but what if we need it." You won't. And if you truly do, it lives in the 301 and the old backup, not on the shelf.

Weed ruthlessly on paper, and the new library opens with shelves full of books people actually check out. Migrate everything, and you have just paid movers to relocate a 1997 tax guide.

Questions and discussion

When you last audited a site before a move, where did the "migrate everything, we'll sort it later" instinct come from: your own caution, a stakeholder who couldn't let a page go, or a deadline that left no time to weed? I'm curious which one actually drove it, because I suspect I'm blaming the wrong culprit.
Steven Solano, who wrote this — and reads every reply

Loading discussion…

Want this analysis for your exact site before you migrate?

Request a scan →