A domain change, a platform replatform (WordPress to a headless CMS, Magento to Shopify), or even a large-scale URL restructure can lose double-digit percentages of organic traffic within weeks if handled carelessly — and recovering that traffic can take months, because every lost signal (link equity, crawl history, indexed URL trust) has to rebuild from near-zero. The core risk isn't the new site being worse; it's the transition itself failing to preserve what search engines already trust about the old one.

Step 1: full URL inventory before anything changes

Before writing a single redirect rule, crawl the live site (and cross-reference against Search Console, analytics, and the existing XML sitemap) to produce a complete list of every indexed, traffic-receiving, or link-receiving URL. This inventory is the baseline you'll map against — skipping it means discovering missed URLs only after they start 404ing in production, which is the single most common migration failure mode.

Step 2: one-to-one URL mapping

Every old URL needs an explicit mapping to its new-site equivalent — not a generic redirect to the homepage or category root, which is often called a 'lazy redirect' and preserves only a fraction of the original equity. Mapping is tedious at scale (tens of thousands of URLs on a large catalog), but it's the highest-leverage work in the entire migration. Where no true equivalent page exists on the new site, map to the closest topically relevant page rather than the homepage by default.

url-mapping.csv

text

old_url,new_url,redirect_type
/shop/mens-shoes,/men/shoes,301
/shop/mens-shoes/trail-runner-xl,/men/shoes/trail-runner-xl,301
/blog/2021/how-to-choose-running-shoes,/learn/how-to-choose-running-shoes,301
/shop/discontinued-item-882,/men/shoes,301  # no direct equivalent, mapped to nearest category

Step 3: redirect strategy and implementation

301 redirects should be implemented at the server or CDN/edge level, not via client-side JavaScript or meta-refresh, both of which are slower to resolve and less reliably followed by crawlers. Redirect chains — URL A to B to C — should be collapsed to a single hop (A to C directly), since each additional hop both dilutes equity transfer and slows crawl resolution. Validate the full mapping file against a staging environment before the domain cutover, not after.

Launching without redirects live is often irreversible in effect

If the new site goes live before redirects are active — even for a few hours — crawlers that happen to hit old URLs during that window record them as 404s. Recovering from that requires the URL to be recrawled and found healthy again, which can take weeks even after the redirect is fixed. Redirects must be live and tested before DNS or platform cutover, not patched in afterward.

Pre-launch vs. post-launch migration tasks

Phase	Key tasks	Risk if skipped
Pre-launch	Full URL inventory, 1:1 mapping, redirect staging tests, updated sitemap/robots.txt ready, baseline ranking/traffic snapshot	Blind to what's actually at risk; no way to measure impact later
Launch	Redirects live before DNS cutover, canonical tags updated, internal links updated to new URLs (not redirected old ones)	404 spikes, equity loss, crawl confusion
Post-launch (weeks 1-4)	Daily crawl error monitoring, Search Console coverage checks, rank tracking on priority terms, log file review	Issues compound unnoticed; recovery window extends
Post-launch (month 2+)	Redirect cleanup (remove unneeded chains), old sitemap decommissioned, stable ranking confirmation	Residual technical debt and unresolved crawl waste

Don't forget the supporting signals

URLs and redirects get the most attention, but a migration touches everything: the XML sitemap needs to reflect new URLs only, robots.txt needs re-review (a staging-environment block that accidentally ships to production is a recurring disaster), internal links across the site should point directly to new URLs rather than relying on redirects to patch old links, and structured data/canonical tags need to be re-verified against the new templates rather than assumed to have carried over correctly.

Monitoring: before, during, and after

Capture a pre-migration baseline — organic traffic by landing page, keyword rankings for priority terms, indexed page count — so that any post-launch drop has something concrete to compare against. In the days immediately after launch, monitor Search Console's Coverage and Crawl Stats reports daily for spikes in 404s or 'not found' errors, and spot-check that redirects resolve correctly for a sample of high-traffic URLs. Expect a temporary dip even in a well-executed migration, since re-crawling and re-evaluating the new URLs takes time; the signal to worry about is a dip that doesn't start recovering within several weeks.

Log files are the ground truth during a migration

Rankings and Search Console data lag behind reality by days. Server log files show, in near real-time, whether Googlebot is actually hitting the new URLs, still crawling the old ones, or hitting redirect chains unexpectedly — making them the fastest diagnostic tool in the first week after launch.

What's next

Redirects are the backbone of any migration, and getting the distinction between redirect types — and between a 404 you should fix versus one that's actually fine — right is worth its own deep dive.

Next: Redirect Management & 404s →

I build these systems professionally.

Whether it's a RAG pipeline, analytics migration, or AI workflow — let's talk.

Work With Me →

Need production AI or MarTech expertise? I build custom LLM workflows, server-side GTM tagging, and analytics infrastructures professionally.

Need custom AI or MarTech setup? Let's build together.

Let's talk →