Before you start: audit and benchmark
You cannot verify a migration against a state you never recorded. So before anything moves, the old site gets crawled in full: every URL, its status code, title, meta description, canonical tag and any redirect already in place. Not the pages you remember - the pages that exist. Old blog tags, parameter URLs, PDFs, image files that earn links. The URLs you forgot about are the ones that leak equity.
Alongside the crawl, benchmark what the site currently earns. Search Console shows which queries and pages bring traffic, analytics shows what each page is worth, and a backlink export shows which URLs other sites actually point at. Record current rankings for the terms that matter commercially, note the indexed page count, and take a Core Web Vitals reading. This is the baseline every post-launch check gets measured against.
This is also the first place Claude Code genuinely changes the work. We point it at the live site and it scripts the crawl, then writes the inventory into the repository as structured data. That matters because the inventory stops being a spreadsheet someone half-maintains - it becomes the file that later generates the redirect map and drives the post-launch tests.
The URL map: the artefact that saves migrations
The URL map is the single artefact that saves migrations: one row per old URL, mapped to its exact new destination. Most of the map should be one to one. Where the structure improves - and it usually should - the mapping stays deliberate: the old services page moves to its direct successor, not to a vaguely related parent.
Every URL gets one of four decisions. Keep it (same URL on the new site, the ideal case), move it (301 to its new location), merge it (301 into the page that absorbs its content), or retire it (a deliberate 410, only for pages with no successor, no traffic and no links). What no URL gets is silence. An unmapped URL becomes a 404 at launch, and a 404 hands back everything the page earned.
The classic failure is mapping everything you can’t place to the homepage. Google treats bulk redirects-to-homepage as soft 404s, so the equity is lost anyway - it just fails quietly instead of loudly.
Redirects: 301s, one to one, no chains
Redirects are 301, permanent. A 302 says the move is temporary and the old URL is coming back, which is exactly the wrong signal on the way out.
Point every old URL straight at its final destination. Chains - old URL to interim URL to new URL - add latency on every hop, and crawlers give up on long ones. That includes legacy redirects: if the old site already sent /about-us to /about, the new map sends /about-us straight to the final page rather than through the retired one.
Be suspicious of wildcard rules. A blanket /blog/* to /insights collapses hundreds of distinct pages into one destination, which is the homepage failure again at section scale. Wildcards are fine for genuinely mechanical patterns; everything else gets mapped by hand - which is to say, by the inventory.
In our builds the redirect map is generated from the inventory file and written into the site’s configuration as code. Then Claude Code writes a test that requests every old URL and asserts both the status code and the destination. Several hundred redirects get verified in minutes, on the staging site, before launch - not discovered broken in Search Console three weeks after it.
Content and metadata carry-over
A migration changes enough signals at once. Don’t add a content rewrite to the pile - carry titles and meta descriptions across one to one, and rewrite them later as separate, measurable changes. If rankings wobble after launch, you want one variable to examine, not two.
Structured data moves too, and it is the most commonly skipped item on this list. Whatever schema the old site emitted - organisation details, articles, FAQs, breadcrumbs - gets rebuilt on the new site, in code rather than as a plugin’s output. The same goes for the quieter on-page signals: heading structure, image alt text, and the internal anchor text that tells search engines what each page is about.
Media needs the same discipline as pages. Images that rank in image search or earn links keep their filenames where practical, or get redirected like any other URL.
Technical checks before launch
The pre-launch sweep runs on the staging site, before anything goes live:
- A new XML sitemap listing final URLs only - nothing that redirects, nothing that 404s.
- robots.txt reviewed, and the staging noindex ready to come off at launch. Shipping the staging robots block to production is the most famous migration failure there is, and it still happens.
- Canonical tags self-referencing on every new URL.
- Internal links pointing directly at final URLs, not routed through the redirects.
- Every form submitted end to end, every integration exercised - CRM, bookings, payments, email notifications.
- Analytics and Search Console continuity: the same properties kept, and the new domain verified in advance if the domain is changing.
- HTTPS everywhere, one canonical host (www or not - pick one), and a performance check against the baseline.
That last one deserves a sentence. A migration should never ship a slower site, and on a rebuild into plain code it goes the other way: our builds on Claude Code target Lighthouse 100s, so the migration usually banks a speed improvement Google notices in the same crawl that discovers the redirects.
Launch day, in order
- Freeze content changes on the old site, and run a final content sync so nothing published that morning gets lost.
- Deploy, with the full redirect map going live at the same moment as the new site. A gap between the two is a window of 404s.
- Spot-check the money pages by hand: the homepage, the top landing pages from your benchmark, the highest-value forms.
- Submit the new sitemap in Search Console, and use the change of address tool if the domain itself is moving.
- Start the re-crawl. The verification pass against the inventory begins the moment the site is live.
Two habits worth keeping: the old site stays reachable until the new one has passed its checks, and nobody launches at four o’clock on a Friday.
After launch: the check that matters most
The last check happens after launch, not before. That rule is on every migration page we publish, because it’s the one that separates a checklist from a hope. The live site gets re-crawled against the inventory: every redirect followed to its destination, every new page returning 200, nothing orphaned.
Then Search Console becomes a daily habit for a few weeks. Watch indexing coverage against the benchmark count, watch the 404 report for URLs the map missed, and watch performance for the terms you recorded. Some movement is normal - rankings usually wobble for two to six weeks while Google re-evaluates the site - so the question is the trend against the baseline, not any single day.
The worry signals are specific: a growing 404 report, indexed pages falling further than retired pages explain, or commercial terms still below benchmark after a month. Each one points back at the inventory, which is why it was built first.
Because our inventory lives in the repository, the re-crawl is a script, not an afternoon. We re-run it at launch, the day after, and on a schedule through the handover weeks - the same assertions every time, so drift shows up as a failing check instead of a sinking chart.