Value-score your URLs before a migration, not after

Every migration project eventually produces a number like "the redirect map covers 96% of URLs". It goes on the board, it gets signed off, and it cannot detect the thing that will actually cost you traffic.

The reason is structural. Redirect maps are usually generated by pattern-matching old URLs against new ones. Pattern matching works where URL structure is regular. Your most valuable pages are frequently the least regular, because they are the oldest — which is exactly why they have accumulated links, rankings and authority.

So a pattern-generated map reliably covers the long tail and misses the head. Counted by URL, that looks like 96%. Counted by value, it can be under half.

What a value score is

One number per URL, combining:

• Organic clicks over the last 12–16 months (Search Console, page level)
• Conversions and revenue (GA4, plus your own reporting where it is better)
• Referring domains pointing at that specific URL
• Query value — is this URL the landing page for commercially important queries?
• Internal importance — is it linked from the main navigation, or is it an orphan?

Weight them however suits your business; the precise weighting matters much less than having a single sortable number. Then sort descending and cut into deciles.

Decile 1 is what you are protecting. Decile 10 is what pattern rules already handle.

Building the inventory (about three days)

1. Crawl the old site completely. Rendering on, no sampling.
2. Export Search Console pages for the full available history. Use the API or bulk export if the property is large — the interface truncates.
3. Export GA4 landing pages with sessions, conversions and revenue.
4. Export backlinks by target URL from whichever tool you have.
5. Add your own conversion or revenue value per page if you have better data than GA4.
6. Join all of it on URL into one file. Normalise trailing slashes, protocols, and case first, or the join will silently lose rows.
7. Score, sort, decile.

The output is one spreadsheet or one table. It is the single most useful artefact in a migration, and it is reusable for the next one.

What to do with it

Test the proposed redirect map against the scored list programmatically. Not by sampling — sampling is how you get 96%.

For every scored URL, check four things:

• Is there a destination at all?
• Is it a single hop?
• Is it a 301, where permanent is intended?
• Does the destination return 200 and serve equivalent content?

Then report coverage weighted by value, per decile. That table is the one to put on the project board. Aggregate coverage and top-decile coverage are different numbers, and only one of them predicts what happens on launch week.

The rest of the pre-launch surface

Redirects are the biggest risk but not the only one. On staging, before launch:

• Metadata: titles, descriptions, canonicals carried across on the templates serving deciles 1–3. Field-by-field crawl diff, not a spot check.
• Structured data: still valid, still describing the page.
• Internal links: do they point at new URLs, or at old URLs that will now redirect? A site full of internal redirects works but wastes crawl and slows everything.
• Sitemaps: only canonical, indexable URLs. Segmented by page type so coverage problems are diagnosable later.
• robots.txt on both environments: staging closed (disallow and HTTP auth), production open. Getting these the wrong way round is a surprisingly common launch-day incident.
• Analytics continuity: events, conversions, dataLayer and cross-domain tested with real actions on staging. If tracking breaks at launch, you lose the ability to measure the migration itself.

Launch day is a checklist, not a vigil

Write the pass/fail criteria in advance, with owners. Then work it:

1. Status codes across the scored URL set.
2. Redirect behaviour — single hop, correct target, correct code.
3. Canonicals on the new templates.
4. robots.txt on production; staging closed.
5. Sitemap submitted and accurate.
6. Analytics firing; conversions recording.
7. Critical pages indexable.
8. Server response times under real traffic.

And define rollback triggers before launch week. The question at 2am should be "did criterion 4 fail?", not "does anyone feel nervous?".

Then monitor for 30 days

• Day 1: critical QA on the scored URL set.
• Day 3: indexing and error monitoring.
• Day 7: traffic comparison against baseline.
• Day 14: page-level comparison, cohort by cohort.
• Day 30: full report on what value was retained and what was not.

A short dip while new URLs are recrawled and reprocessed is normal. A sustained loss of 30% or more is not normal — it is a preventable mistake, and the prevention is almost entirely in the work above.

If you have two weeks, not eight

Reduced scope, same order:

1. Score the URLs. Even a rough score beats a URL count.
2. Get deciles 1–3 mapped correctly, single hop, 301.
3. Validate analytics with real actions.
4. Close staging, open production.
5. Write the launch checklist.

Skip the full metadata and content mapping and say out loud that you are skipping it. A known gap you have decided to accept is a different situation from a gap nobody noticed.