The Zero-Keywords-Lost Migration Checklist

The rule the whole checklist serves

Decide your rollback threshold before launch day, in writing, with a name attached to the decision. Everything else on this list is preparation for a moment when somebody has to choose between waiting and reverting, and that is the worst possible time to be inventing criteria.

Migrations rarely fail on launch night. They fail because a decision that should have been made in week one got made under pressure in hour six.

Build the crawl inventory first

Before anything gets designed, produce a complete list of every URL that currently exists and what each one is worth. This is the document the entire migration runs on, and building it takes longer than anyone estimates.

For every URL, capture: its status code, its canonical, its indexed state, its organic entrances and revenue or conversions over the last twelve months, its ranking keywords, and its inbound links. Then sort by value, because the list will be too long to treat every row equally.

Why your sitemap is not your inventory

A sitemap is what someone intended to publish. Your inventory is what actually exists and what actually earns, and the gap between them is where migrations lose money.

The sitemap will miss the pages that earn quietly:

• Orphaned pages that still rank and still convert, linked from nowhere internally.
• Old campaign and PDF URLs with real inbound links pointing at them.
• Parameter and pagination variants that quietly hold rankings.
• Pages behind redirects from an earlier migration, where a second hop is about to become a third.
• Subdomains, help centers, and legacy blogs nobody on the current team remembers owning.

Map 301s per URL

Every URL in the inventory gets an explicit destination, decided by a person, recorded in a spreadsheet. Old URL, new URL, reason, and who signed off.

Redirect to the closest equivalent page, never to the homepage as a shortcut. A redirect to an unrelated page is treated as a soft 404, so it passes on nothing and costs you the ranking anyway.

Never pattern-only for money pages

Pattern rules are fine for the long tail. They are not acceptable for the pages that earn, because a regex cannot tell you that one URL in forty had a different slug convention, and you will find out from a traffic drop rather than from a test.

The working split: hand-map every page in the top tier of your value sort, plus anything with meaningful inbound links, and pattern-map the rest with spot checks. Then test the whole map against the staging site before launch and confirm every redirect returns a single 301 to a live 200. Chains and loops are the most common preventable failure in any migration.

Freeze everything else during the window

A migration is one variable. Ship it as one variable, or you will never know what caused what.

• No content rewrites on pages that already rank. Move them as they are, improve them next month.
• No information-architecture changes beyond what the migration requires. A new URL structure and a new nav at once doubles the diagnosis.
• No internal-link overhaul. Internal links carry rankings, so changing them at cutover hides the effect of the cutover.
• No redesign of the templates that hold your ranking pages, if it can wait a cycle.
• No tracking changes. Migrating analytics in the same window means your measurement breaks exactly when you need it most.

Track rank and traffic through cutover, page by page

Site-level averages will tell you everything is fine while a category quietly collapses. Track at the page level, and start before launch so you have something to compare against.

• A ranking baseline captured in the week before cutover, daily for the money pages.
• Organic entrances and conversions per URL, so a drop can be traced to a page rather than a channel.
• Index coverage and crawl stats in both search consoles, watched daily through the first two weeks.
• Server logs if you can get them, because they show what bots are actually fetching rather than what you hope they are.
• Core Web Vitals on the templates that changed, since a fast old page replaced by a slow new one is a real ranking risk.

The first 72 hours

A short, ordered watchlist. Run it in this sequence.

• Hour one: confirm the new site returns 200s, robots.txt is not blocking, and no noindex tag survived from staging. This is the single most common launch-day error.
• Hour one: run the full redirect map against production and confirm every row lands on a live page in one hop.
• Hour two: submit the new sitemap in both search consoles and confirm it is being read.
• Day one: verify analytics and conversion tracking are firing on the new templates, and that the numbers are plausible rather than merely present.
• Day one and two: watch index coverage for spikes in excluded or crawled-not-indexed URLs.
• Day two and three: check rankings for your money pages daily, and check that internal links resolve without hops.

The rollback decision rule

Write it down before launch, and make it a number rather than a feeling. A workable version: if the money pages lose more than an agreed share of their ranking positions and it holds beyond 48 hours with no identified fixable cause, revert.

Two things make the rule usable. First, one named person decides, not a committee assembled at midnight. Second, the revert path is tested in advance, so reverting is a known 30-minute operation and not a discovery exercise. A rollback plan nobody has rehearsed is a wish.

Most of the time you will not use it. The value is that you stop debating whether things are bad enough, and start reading the number you agreed on.

When to start changing things again

Wait for the signal, not the calendar. The migration is done when index coverage has stabilized, rankings have held for two to three weeks, and your traffic and conversion numbers are back in their normal range.

Then unfreeze in order, one change at a time, so each one is still measurable: content improvements on the pages you deliberately moved unchanged, then internal linking, then the IA and design work you postponed. Anything you shipped during the freeze window because it seemed harmless is the first thing to check if numbers are still odd.

The checklist, in order

The whole thing, compressed enough to work from.

• Crawl and inventory every URL with its value attached. Do not trust the sitemap.
• Sort by value, and identify the money pages explicitly.
• Hand-map 301s for every money page and every page with inbound links. Pattern-map the tail with spot checks.
• Test the full map against staging. One hop, live destination, no loops.
• Freeze content, IA, internal links, and tracking for the window.
• Capture a page-level ranking, traffic, and conversion baseline in the final week.
• Agree the rollback threshold, the decider, and the tested revert path, in writing.
• Launch, then run the 72-hour watchlist in sequence.
• Hold the freeze until coverage and rankings stabilize.
• Unfreeze one change at a time.

What it looks like on a real migration

One example from our own work. A law firm needed a full migration after a previous redesign cost rankings that took two years to recover, so the requirement was to lose nothing. Every legacy URL was crawled, mapped, and redirected before launch, and rankings were tracked daily through cutover so any drop would surface in hours rather than quarters.

Zero keywords were lost, and 100% of legacy URLs were mapped and redirected. Neither number came from anything clever. They came from doing the inventory first and deciding the rules before launch day, which is the entire argument of this checklist.