Before you build a single template, you score every page with two exports and a spreadsheet: pull twelve months of entrances and conversions, pull a full crawl with inbound links and canonical status, and give each URL one of three verdicts. Migrate the pages that earn traffic, links, or revenue and still read true. Rewrite the ones with demand or authority but tired, duplicated, or inaccurate content. Kill the pages nobody visits, nothing links to, and no one will miss. You do this on paper, not in a sandbox, because arguing about a page while a developer waits on the clock is the most expensive way to make a cheap decision.
Here is the scene that makes me preach this. A team sits in a cramped kickoff, the new platform gleaming in a demo tab, and someone says "we'll just bring everything over and clean it up later." Everyone nods. Later never comes. Six weeks on, three people are manually rebuilding a 2014 press release that got eleven visits last year, and the page that actually ranks is still sitting in a backlog nobody prioritized. They moved the junk and lost the jewels.
So let's garden instead.
You're not moving a website. You're moving a greenhouse.
Think of your content library as a greenhouse you're relocating. You don't load every pot onto the truck. You walk the rows with a clipboard. The thriving plant that flowers every year and that the neighbors keep asking about? That gets repotted carefully and placed in the best light. Migrate it, redirects and all, and don't touch its words.
Then there's the overgrown thing that's clearly alive but a tangled mess. People still come looking for it, but it hasn't been pruned since the last redesign. That's your rewrite. The root system is good (it ranks, it earns links), but the growth on top needs cutting back before it goes in the new soil.
And then, in the back, the brown stick in the cracked pot. No visits. No links. No demand. You've been watering it out of guilt for years. Compost it. (Gracefully, with a redirect to its nearest living relative, so nobody who stumbles onto the old address hits a wall.)
The four readings that decide a plant's fate
You don't need intuition for this. You need four numbers, and you can get all of them before you ever log into the new CMS.
The first is demand: does anyone arrive here, from search or anywhere else? Twelve months of entrances, not pageviews, because you want to know if a page is a front door or a dusty back room. The second is authority: how many external sites link to this URL? One good inbound link can outweigh a thousand of your own visits, because that's equity you cannot manufacture in the new build. The third is business value: conversions, assisted conversions, leads, revenue, or for the honest among us, the page the sales team physically begs you not to delete. The fourth is truth: is the content still accurate, or is it quoting prices, people, and products that left the building in 2019?
Score those four, and the verdict mostly writes itself.
| Verdict | What the readings say | What you actually do |
|---|---|---|
| Migrate | Real demand or inbound links, content still true | Move as-is, map the redirect one-to-one, change nothing that machines use to find it |
| Rewrite | Demand or authority present, but content is stale, thin, or duplicated | Keep the URL and the topic, replace the words, consolidate the duplicates into it |
| Kill | No demand, no links, no business value, or flatly obsolete | Redirect to the nearest living page, or let it 410 if nothing fits |
A word on that last column. Killing a page is not deleting a URL into the void. A 301 to a relevant page hands its signals forward; Google has said for years that 3xx redirects pass ranking signals without loss, so a thoughtful redirect is a graft, not a funeral. A page that simply 404s after cutover is the one that bites you.
Why the spreadsheet beats the sandbox
Here's the uncomfortable math. On most sites I've looked at, a small minority of pages carry the overwhelming majority of the traffic and the links. (The exact split varies, but the shape is always lopsided.) That means most of your library is already in the kill-or-rewrite pile before anyone opens a design tool. If you discover that fact in a sandbox, you've paid a developer's hourly rate to learn something a free analytics export would have told you in an afternoon.
Scoring on paper also makes the fight happen at the right time. Every migration has the meeting where someone defends a page for emotional reasons. You want that meeting to happen over a spreadsheet, where a page with eleven annual visits has to justify itself in public, not three weeks into the build when killing it feels like wasted work. A crawl that pins duplicate clusters, orphaned assets, and zero-traffic URLs to a single screen is exactly the kind of evidence that ends those arguments quickly. (A pre-migration crawl is the whole job our migrate planning workflow exists to do, but the method matters more than the tool.)
One caution so you don't over-prune. Don't kill a page purely because it has zero organic traffic. Some pages exist for humans you already have: the shipping policy, the careers page, the thing support links in every ticket. Low search demand is not the same as low value. Read all four numbers, not just the loud one.
What I'd actually do
I'd score the whole site before the platform contract is even signed, and I'd treat "migrate everything" as the single most expensive sentence in the project. My bias is to kill more than feels comfortable, because a smaller site is a faster migration, a cleaner redirect map, and a library a human can actually keep accurate afterward. If I'm wrong about a page, a redirect quietly fixes it. If I'm wrong by hauling the whole overgrown greenhouse across town, I find out at launch, in public, with the new site slower and messier than the old one.
So walk the rows first. The brown stick in the cracked pot has had a good run. It does not get a seat on the truck just because you've been watering it this long.