Site Migrations Without Traffic Loss: Redirects Done Properly

Where migration traffic losses actually come from

A migration is any change that alters your URLs or where they live: a new domain, a move from Wix to WordPress, a restructure of your page paths, or all three at once. Search engines have spent years learning which of your URLs deserve to rank. Break the thread between old and new addresses and that accumulated trust does not transfer.

The losses almost never come from mysterious algorithmic punishment. They come from mechanical mistakes:

• Old URLs that were never mapped and now return 404
• Everything redirected to the homepage, which Google treats as a soft 404
• Redirect chains that hop through three addresses before arriving
• A noindex tag or robots block copied over from the staging site
• Internal links still pointing at old URLs and leaking authority through redirects

Handled properly, a migration produces a wobble of a few weeks, not a cliff. The work happens before launch, in a spreadsheet.

Build the URL map before you touch anything

You cannot redirect URLs you do not know exist. Assemble a complete inventory of the old site from several sources, because each one misses things the others catch:

• A full crawl with Screaming Frog (free for up to 500 URLs, which covers most small sites)
• A Google Search Console performance export, which surfaces URLs earning impressions
• GA4 landing pages, which surface URLs earning visits from anywhere
• Your backlink profile from Search Console's links report, so externally linked pages are never orphaned

De-duplicate into one spreadsheet: old URL in column A, new URL in column B, one row per address. Every row needs a decision. Pages being retired should redirect to the closest relevant alternative, or return a deliberate 410 if nothing sensible exists. The one rule: no decision gets left for launch day.

Write redirect rules properly

Use 301 (permanent) redirects, mapped one-to-one from each old URL to its closest new equivalent. Resist the temptation to sweep everything to the homepage: Google treats irrelevant blanket redirects as soft 404s, and the equity you were trying to preserve evaporates.

Where URL patterns are consistent, one regex rule can replace hundreds of rows, for example rewriting /blog/2019/post-name to /blog/post-name. Collapse chains so every old URL reaches its destination in a single hop, including the HTTP-to-HTTPS and non-www steps. Where the rules live depends on your stack: an .htaccess file on Apache hosting, the server config on nginx, Cloudflare's bulk redirects if you proxy through it, or the Redirection plugin on WordPress when server access is limited. Whatever you choose, keep the redirects live for at least a year after launch; Google's own guidance says the same, and leaving them indefinitely costs nothing.

Pre-launch: crawl the staging site like a search engine

Before anything goes live, point Screaming Frog at the staging site (it can authenticate and ignore robots rules for this purpose) and check the new build cold:

• Canonical tags reference the new URLs, not staging or old addresses
• An XML sitemap of the new URLs is generated and ready to submit
• Internal links point directly at new URLs rather than travelling through redirects
• hreflang tags are updated if you run multilingual pages
• The staging noindex tag and robots.txt block are removed at launch, the single most common migration disaster

Then test the redirect map itself: load your old-URL list into the crawler's list mode against the new rules and confirm every row returns one 301 hop to the mapped destination.

Launch day and the first week

Deploy the redirects at the same moment the new site goes live, never afterwards. Then work through a short sequence:

• 1. Spot-check your top 100 old URLs by traffic and confirm single-hop 301s
• 2. Submit the new XML sitemap in Search Console
• 3. Temporarily keep the old sitemap submitted too, so Google recrawls old URLs and sees the redirects quickly
• 4. For a domain change, use the Change of Address tool in Search Console for the old property
• 5. Re-verify analytics, conversion tracking and any paid-ads destination URLs

Expect rankings and impressions to fluctuate for several weeks while both sets of URLs coexist in the index. That is normal and not a signal to start reversing decisions.

The 90-day monitoring routine

Migrations are not finished at launch; they are finished when the data settles. Put a weekly 20-minute check in the diary for the next three months:

• Search Console indexing report: watch for 404 spikes and add redirects for any real URLs that surface
• Performance report: compare clicks and impressions against the same weeks pre-migration
• Re-crawl the old URL list monthly to catch redirects that a plugin update or deploy silently dropped
• Track rankings for your top 20 terms so a template-level problem shows up as a pattern
• Watch server logs or host analytics for unexpected crawl errors

A dip that recovers within six to eight weeks is the migration working. A decline that keeps widening past that point means something is unmapped or blocked, and the weekly checks will usually tell you exactly what. If you would rather not carry that risk alone, our team handles migrations end to end.