Site Migration

A site migration is any change that alters the URLs, host, platform, or structure search engines have already learned about your site — domain moves, HTTPS switches, replatforms, redesigns that touch URL paths, or merging sites together. The stakes are as high as technical SEO gets: a clean migration dips for a few weeks and recovers; a botched one can vaporize years of accumulated ranking signals in a single deploy, and some of that traffic never comes back.

What actually breaks

Google doesn't rank "your site" — it ranks specific URLs, each carrying its own history of links, engagement, and indexed content. When a URL changes and nothing tells Google where the page went, that history is orphaned. The 301 redirect is the forwarding address that carries signals to the new URL. Every migration disaster I've dissected reduces to the same root cause: URLs changed, and the redirect map was missing, wrong, or lazy. Our case study of a migration that lost 90% of its traffic shows exactly how this plays out when nobody owns the mapping.

A real redirect map example

The deliverable at the heart of every migration is embarrassingly simple: a spreadsheet of old URL → new URL, one row per indexed page. It looks like this:

old_url,new_url,status
/products/kalamata-olives-370g.html,/shop/olives/kalamata-370g/,301
/products/nyons-olives-250g.html,/shop/olives/nyons-250g/,301
/blog/2023/06/olive-harvest-guide,/guides/olive-harvest/,301
/about-us.php,/about/,301
/category/recipes?page=3,/recipes/,301

Which becomes server configuration. Pattern-based rules handle whole sections; the stragglers get explicit lines:

# Apache .htaccess — pattern rule for a consistent section
RewriteEngine On
RewriteRule ^products/([a-z0-9-]+).html$ /shop/olives/$1/ [R=301,L]

# Explicit one-offs
Redirect 301 /about-us.php /about/

# nginx equivalent
location ~ ^/products/([a-z0-9-]+).html$ {
    return 301 /shop/olives/$1/;
}

Two rules of thumb: redirect to the single final URL (no chains — old URL → new URL in one hop, not old → new-http → new-https → new-with-slash), and never let the map fall back to "everything else goes to the homepage." Google treats mass homepage redirects as soft 404s, and the signal transfer you were counting on doesn't happen. If you need help generating the mapping at scale, our redirect map generator exists for exactly this.

Migration types by risk

How to check it on your own site

Whether you're planning one or inheriting the aftermath of one:

1. Benchmark before anything moves. Full Screaming Frog crawl of the old site (export all 200s), top pages from Search Console and analytics, ranking positions for money terms. Without a baseline you can't even prove what you lost.
2. Build the map from real inventory — crawl data plus GSC's indexed pages plus backlink targets from your link tool. The pages you forgot exist are the ones that bleed.
3. Test redirects pre-launch on staging: curl -s -o /dev/null -w "%{http_code} %{redirect_url}n" https://staging.example.com/products/kalamata-olives-370g.html across the whole map in a loop. Every row should return exactly one 301 to the mapped target.
4. Launch-day sweep: re-run the curl loop against production, confirm robots.txt didn't ship with the staging Disallow: /, submit the new sitemap, and use Change of Address if the domain moved.
5. Watch the handover for 4–8 weeks: GSC Coverage and Crawl Stats on both properties, plus server logs to watch Googlebot re-crawl the old URLs and follow the 301s. Old URLs should trend to "Page with redirect"; new ones to Indexed.

For the full pre-launch discipline, our site migration planning checklist goes phase by phase.

Common audit mistakes (and fixes)

Redirecting everything to the homepage

The classic. It looks done, it validates as "no 404s," and it transfers almost nothing. Fix: per-page mapping to the closest equivalent; a genuinely retired page can 410 or redirect to its parent category.

Shipping the staging robots.txt

The site launches beautifully, blocked from crawling. It happens to teams of every size, and it's why launch-day checklists exist. Fix: make "curl /robots.txt on production" the first post-deploy command, every time.

Ignoring parameters, pagination, and non-HTML URLs

The map covers pretty page URLs; meanwhile PDFs, images with backlinks, paginated archives, and parameter variants all 404. Fix: build the inventory from logs and backlink data, not just the CMS page list.

Leaving internal links pointing at old URLs

Post-migration, every internal link routes through a 301 forever — sloppy, slow, and it muddies crawl efficiency. Fix: bulk-update internal links to final URLs; see our redirects and status codes FAQ for what each hop costs.

Declaring victory at week one

Rankings often hold for days while Google works off cached signals, then dip as re-crawling proceeds. Teams celebrate, stand down, and miss the slide. Fix: the migration isn't done until old URLs are deindexed, new URLs are stable, and traffic has plateaued — measured in weeks.

FAQ

How much traffic loss is normal?

A well-executed migration commonly dips for two to six weeks while Google re-crawls and reconciles, then recovers. There's no honest universal percentage — scale, crawl rate, and how much you changed all move the number. What's NOT normal is a cliff that keeps falling after week two; that means broken mapping, and you should be in the logs the same day.

How long do the 301 redirects need to stay up?

Google has said signals consolidate after a redirect has been seen and processed for a long period — treat one year as the working minimum and "indefinitely" as the goal, because users, browsers, and backlinks keep hitting old URLs for years. Redirects are cheap; lost link equity isn't.

Can I migrate in stages, section by section?

Yes, and for large sites it's often smarter — you validate the process on one section before betting the whole domain. The tradeoff is a longer period of mixed states, which demands cleaner tracking. What you shouldn't stage is a single page's redirect chain: each old URL should hop once, even mid-transition.

Do I lose PageRank through a 301?

Google's guidance for years has been that 301/302 redirects don't leak PageRank as they once did. In practice, per-page equivalence is what protects you — redirecting a strong page to something topically unrelated behaves like a soft 404 regardless of status code.

What about a migration forced by an acquisition or rebrand deadline?

Scope ruthlessly: keep URL paths identical wherever humanly possible and change only the hostname. A domain-only move with 1:1 paths is the most survivable high-stakes migration there is; a rushed everything-at-once move is how the 90%-loss horror stories happen.