Chapter 21: Site Migrations — Changing Domains, Redesigning, or Moving CMS Without Losing All Your Traffic

"Moving a website is like moving house when your entire income arrives by mail: the building is the easy part. Making sure every letter still finds you is the whole job." — a constructed maxim, in the spirit of this book

Overview

Here is the phone call every SEO dreads, usually delivered as good news. "We're rebranding — we've bought a better domain and we're launching the new site next Friday." Or: "Marketing hired an agency to redesign the whole website; it looks incredible; it goes live at the end of the month." Or: "We're finally moving off this ancient platform onto something modern." Each of these is a site migration, and each one is the single most dangerous operation in all of SEO — the one moment when years of patiently earned organic traffic can vanish in a weekend because of a single line of code, a spreadsheet nobody finished, or a launch that happened on a Friday afternoon with no one watching.

The stakes are asymmetric, and that is the whole reason this chapter exists. A migration done well is invisible: a brief wobble, then business as usual, and often a site that is faster, cleaner, and better positioned to grow. A migration done badly is a cliff. Traffic that took five years to build can drop by half — or by nearly all of it — in a matter of days, and clawing it back can take months, if it comes back at all. The difference between those two outcomes is almost never luck and almost never talent. It is discipline: a checklist executed completely, in the right order, with someone paying attention.

The real question this chapter answers is not "how do I move my site?" Any developer can point a domain at a new server. The question is: how do I change the thing search engines have spent years learning to trust, without making them start over from zero? Because that is what a migration risks. To Google, your site is a set of URLs it has crawled, indexed, ranked, and connected to the rest of the web through links. Change those URLs carelessly and you are not "updating your website." You are, from Google's point of view, deleting a site it trusted and publishing a new one it has never seen.

In this chapter, you will learn to:

• Tell the five kinds of migration apart and size up the risk of each before anyone commits to a date.
• Take a complete inventory of every URL that earns traffic, rankings, or links — the crown jewels you must not lose.
• Build a redirect map that preserves the value of every old page, and recognize the traps (chains, loops, lazy homepage redirects) that quietly throw that value away.
• Run a go-live checklist whose first line prevents the most common catastrophe in this entire book.
• Watch the aftermath like a hawk, and — the hardest skill — know the difference between a normal dip you should wait out and a real emergency you must fix tonight.

Learning Paths

Migrations touch every track, but the stakes and the details differ. 🏪 Local Business: your most likely migration is a redesign or a platform move (Rivertown's exact situation) — weight §21.5 (the noindex trap) and remember to update your name, address, and phone citations and Google Business Profile after any domain change (Chapter 25). 📝 Content Creator: domain changes and blog CMS moves are your risk — §21.3 (protect the URLs that have links) and §21.4 (chains) are yours. 🛒 E-Commerce: you face the highest-stakes migrations on the web — tens of thousands of URLs, parameters, and out-of-stock pages — so §21.2 (inventory) and §21.3 (mapping at scale) are survival skills; Chapter 31 goes deeper. 🔧 Developer: this is your chapter within the part — §21.4 (server-level 301s, not JavaScript redirects), §21.5 (staging discipline), and the go-live mechanics are on you. 📊 Strategist: own the plan, the timing (never before peak season), and above all §21.6–§21.7 — the monitoring and the when-to-worry judgment that separates a steady hand from a panicked rollback.

21.1 Types of migration: five ways to change, ranked by risk

Let us define the thing precisely, because the word "migration" gets used loosely and the looseness hides the danger. A site migration is any substantial change to a website that can alter how search engines discover, crawl, render, index, or rank it — even when, from a human's point of view, "the content is the same." That last clause is where people get hurt. A team convinces itself that because the articles did not change, nothing important changed. But Google does not rank articles; it ranks URLs, judged through templates, connected by links, at specific addresses. Change the addresses, the templates, or the links, and you have changed everything that matters to a search engine, whatever the words on the page say.

There are five recognizable kinds, and real projects often combine several — which, as we will see, is exactly what makes them dangerous.

1. Domain change. You move from oldbrand.com to newbrand.com — a rebrand, an acquisition, buying a domain you always wanted, or switching a country-code top-level domain (ccTLD, e.g., .co.uk to .com). Every URL on the site changes its address. This is the highest-risk migration, because you are asking Google to transfer everything it knows about thousands of old addresses to thousands of new ones, all at once, and to move the trust that other sites' links conferred on the old domain onto a domain with no history.

2. HTTP-to-HTTPS. You move from http:// to https:// — adding the encryption (the padlock) that has been the baseline for the modern web for a decade. This is an HTTPS migration, and here is the subtlety that trips people: technically, every URL on your site changes, because http://site.com/page and https://site.com/page are different URLs to a search engine. It feels trivial ("we just turned on security") and is therefore the migration most often done carelessly. Google confirmed back in 2014 that HTTPS is a lightweight ranking signal, so the move is worth making — but a botched HTTPS migration (no redirects from the old HTTP URLs, "mixed content" where a secure page still loads insecure images, canonical tags still pointing at http://) can cause weeks of indexing chaos over what should have been a clean win.

3. CMS or platform change. You move from one content management system (CMS) to another — WordPress to a custom build, a custom build to Shopify, Drupal to WordPress. The domain may stay the same, but almost everything underneath changes: the URL structure (platforms have different default URL patterns), the HTML templates, and — the silent killers — the on-page elements your SEO depends on. A new platform can quietly drop your title tags, your heading structure, your image alt text, your internal links, and your structured data, because the new system generates all of those differently and nobody thought to migrate them.

4. Redesign. You keep the domain, keep the platform, keep the URLs — and rebuild the look, the templates, and often the content structure. This is the migration people most underestimate, precisely because "the URLs didn't change, so it's not really a migration." But a redesign can change your internal linking (a new navigation menu that drops half your links), your content (a "cleaner" design that deletes 1,500 words of text Google was ranking you for), your page speed, and your mobile layout. Rivertown's move off its dated WordPress theme, the subject of this chapter's Strategy File, is exactly this kind.

5. Consolidation or restructure. You merge several sites into one, split one site into several, or reorganize the URL structure of a single site (flattening a deep hierarchy, changing a category system). This is close cousin to the content pruning and merging of Chapter 12 — every merged or moved page needs a redirect to its new home, and every decision to not carry a page over is a decision to let its traffic and links die, which should be made on purpose, not by accident.

🔎 How Search Sees It To you, a migration is a launch — a single triumphant moment. To Google, it is a burst of change that takes weeks to digest. Overnight, hundreds or thousands of URLs it knew stop responding as they did; new URLs appear; redirects tell it that addresses it had carefully indexed now live somewhere else. Google has to re-crawl the old URLs to discover the redirects, follow them, crawl the new URLs, re-render and re-index them, and slowly move the accumulated ranking signals from old to new. None of that is instant. This is why even a flawless migration causes temporary volatility — you have handed the search engine a giant reprocessing job, and it works through it at its own pace. Understanding this is what lets you stay calm at the right moments (§21.7) and panic at the right ones.

Here is the table to keep in front of you when someone proposes a migration, because the first strategic move is always to name what kind it is and how much it changes:

THE FIVE MIGRATIONS, BY RISK                                    [schematic — not to scale]
  TYPE              WHAT CHANGES               URLs CHANGE?   RISK    THE CLASSIC FAILURE
  Domain change     the whole address          ALL            ★★★★★   trust doesn't transfer; bad map
  Consolidation     which pages exist/where    MANY           ★★★★    pages dropped without redirects
  CMS / platform    URLs + templates + markup  MOST           ★★★★    lost titles/links/schema silently
  Redesign          look, templates, content   USUALLY NONE   ★★★     staging noindex ships; lost content
  HTTP → HTTPS      the protocol (http→https)  ALL (http→s)   ★★      no redirects; mixed content

Notice the counter-intuitive ranking: an HTTPS migration changes every URL yet is relatively low-risk when done right, because the mapping is perfectly mechanical (every http://X maps to https://X, one to one, no judgment required). A redesign changes no URLs yet earns three stars, because its failures are invisible until traffic drops. Risk is not about how much changes; it is about how much judgment the change requires and how easily a mistake hides.

🔗 Connection The one rule that governs all five types: change one variable at a time when you possibly can. A rebrand that simultaneously moves the domain, redesigns the templates, and switches the CMS is three migrations stacked into one launch — and if traffic drops, you will have no way to tell which of the three did it. The clean approach is to sequence them: migrate the platform first, stabilize, then change the domain, stabilize, then redesign. Businesses hate this because it is slower. Do it anyway when the traffic at stake is large; the diagnosis you buy is worth the wait. This is the same "isolate the variable" discipline that makes the whole pipeline model of Chapter 1 a diagnostic tool rather than a guessing game.

21.2 The pre-migration crawl and URL inventory

You cannot preserve what you have not counted. The foundational act of any migration — the one that, skipped, causes more silent damage than any other — is building a complete URL inventory: a definitive list of every URL on the current site that matters, so that every one of them gets a deliberate decision in the migration plan. Not "most of them." Every one. The page you forgot is the page that had the backlink from a local newspaper that was quietly sending you customers for six years.

The reason this is hard is that no single source knows all your URLs. You have to triangulate from several, because each source sees a different slice of your site:

• A site crawler (Screaming Frog is the standard; it is free for up to 500 URLs, and we tour it properly in Chapters 30 and 38) starts at your homepage and follows links, exactly as Googlebot does. This finds every URL that is internally linked — but only those. Anything orphaned (linked from nowhere — Chapter 15) is invisible to a crawl, which is precisely why the next sources matter.
• Your XML sitemaps (Chapter 14) — the list of URLs you already hand to Google.
• Google Search Console — the truth about what Google actually indexes and, in the Performance report, every URL that earned an impression or a click in the last sixteen months. This is your most valuable source, because it is ranked by value: the URLs at the top are the ones you cannot afford to lose.
• Your analytics (Google Analytics 4, GA4, Chapter 28) — every URL that received a visit, including orphans and old landing pages a crawl would miss.
• Server logs (Chapter 33) — every URL Googlebot actually requested, the ground truth of what the crawler cares about.
• A backlink tool — every URL on your site that has external links pointing at it. This list is sacred. These pages hold the authority other sites have vouched for (Chapter 22), and a broken redirect here throws away link equity you can never easily rebuild.

You then merge these into one master spreadsheet, de-duplicated, and — this is the part that turns a list into a plan — you annotate each URL with its traffic, its rankings, its backlinks, and its conversions, pulled from those same sources. Now you can see, at a glance, which URLs are crown jewels (high traffic, high links, converting), which are dead weight (zero traffic, zero links, thin), and which are in between. The crown jewels get white-glove treatment. The dead weight is a candidate for deliberate pruning (Chapter 12) — a migration is a rare, legitimate chance to clean house, as long as you decide it on purpose.

📄 Read the Report

text FIGURE 21.1 — "The migration inventory, annotated" [constructed teaching example] THE PAGE / REPORT The master URL inventory for a mid-size site preparing to migrate. One row per URL. WHAT'S THERE URL | 12-mo clicks | avg position | referring domains | conversions | decision /water-heater-replacement 1,900 #11 14 38 → MAP (crown jewel) /ac-repair-cedar-hills 420 #6 2 9 → MAP /blog/2019-holiday-hours 0 — 0 0 → PRUNE (410, on purpose) /old-promo-page 3 — 6 0 → MAP (has 6 links! keep it) /tag/uncategorized 110 — 0 0 → PRUNE / consolidate WHAT IT SHOWS Value is wildly uneven. A page with 3 visits but 6 referring domains is worth MORE to preserve than a page with 110 visits and none — because links are the hard-won asset. WHAT IT DOESN'T The spreadsheet can't decide *for* you which low-value pages deserve to live; that's a content-and-links judgment (Ch 12, Ch 22). It just makes the judgment visible. THE MOVE Every row gets a decision — MAP (to a specific new URL) or PRUNE (deliberately). No URL is allowed to have a blank in the "decision" column at go-live. THE LESSON You migrate a spreadsheet, not a website. If a URL isn't on the sheet with a decision, it will be lost — and the ones with backlinks are the expensive ones to lose.

Before you change anything, you also baseline. Record the current state — organic traffic by month, clicks and impressions by page, rankings for your priority terms, total indexed pages, top landing pages — and save it. This is not busywork. After launch, "did the migration hurt us?" is unanswerable without a before picture, and "have we recovered?" is unanswerable without knowing what you are recovering to. The baseline is the ruler you will measure the whole aftermath against.

🛠️ Try It on Your Site Open Google Search Console, go to the Performance report, set the date range to the last 12 months, and export the results grouped by Page. Sort by clicks, descending. The top of that list — the pages actually earning you search traffic — is the spine of your migration inventory and the list you would defend with your life in any move. Most site owners have never looked at their site this way and are startled by which pages do the quiet work. If you have no Search Console yet, that setup is the Chapter 27 task; put a date on it, because you cannot safely migrate a site you cannot measure.

What the inventory cannot do is worth stating plainly, in the honest spirit of this book. It tells you what exists and what each URL is worth; it does not tell you whether the new site will serve those users better. A perfect inventory and a perfect redirect map still cannot save a migration to a new design that is slower, thinner, or worse at matching intent (Chapter 3). The inventory protects continuity. Quality is a separate promise you have to keep.

21.3 Redirect mapping: every old URL to its single best equivalent

This is the heart of the operation, and the place where migrations are won or lost. When a URL's address changes, you must tell everyone — search engines, other websites' links, people's bookmarks — where the content went. The instrument for that is the 301 redirect, and it deserves a careful definition because almost everything in this chapter hangs on it.

A 301 redirect is a server instruction, sent as an HTTP status code (the family of codes is Chapter 14's territory), that says: this URL has moved permanently to this new URL. When a browser or a crawler requests the old address, the server answers "301" and hands over the new address, and the visitor is sent onward automatically. Two things make the 301 the hero of migrations. First, it is permanent, which tells Google to update its index to the new URL and stop expecting the old one to return. Second, and decisively, a 301 passes the old URL's ranking signals to the new one — the links, the authority, the accumulated history that made the page rank. Google has stated publicly that permanent redirects pass ranking signals and that sites do not lose PageRank through a 3xx redirect. That is the entire reason a well-executed migration can keep its rankings: you are not abandoning the old URLs' equity, you are forwarding it.

⚖️ Evidence Check Claim: "A 301 redirect passes 100% of a page's link equity, so a migration loses nothing." Where does this sit? — Confirmed by Google: that 301s pass ranking signals, and that sites do not lose PageRank through the redirect itself, are things Google representatives have stated publicly. So the mechanism is real and you should trust it: a correct 301 to a relevant page forwards the equity. — The honest caveats, which the confident version omits: (1) The transfer is only clean when the target is a genuine equivalent — an irrelevant target is a soft 404 that passes nothing (the myth below). (2) Signals move over time, not instantly; Google must re-crawl and reprocess, which is why rankings wobble for weeks (§21.7). (3) A redirect preserves the page's equity; it cannot make a worse new page rank as well as a better old one. "301s lose nothing" is true about the pipe and false about the water. Preserve the equity, and still make the new page as good or better.

Contrast this with the 302 redirect, its "temporary" sibling (again, Chapter 14 owns the full code family). A 302 tells Google "this is a temporary detour; keep indexing the old URL, I'll be back." Use a 302 for a permanent move and you send Google a contradictory message — the content is at the new URL but you have told Google to keep the old one — and signal consolidation stalls. For a permanent migration, the redirect is a 301. Always. This is not a stylistic preference; it is the difference between forwarding your mail and telling the post office you'll be right back while you actually move to another city.

Now the discipline. A redirect map is the master document that pairs every old URL with the single best new URL it should redirect to. Not a rough plan — an exhaustive, one-row-per-URL mapping, built directly from the inventory of §21.2, that a developer can implement mechanically and you can test line by line. The governing rule is deceptively simple and endlessly violated:

Map every old URL to its closest equivalent on the new site — the page that best serves the same content and the same search intent — and never to the homepage as a default.

The "closest equivalent" standard is the whole craft. The old /services/furnace-repair maps to the new /heating/furnace-repair, because it is the same content and the same intent. A deleted product maps to its category page, or to the closest replacement product — not to the homepage. A merged pair of thin blog posts (Chapter 12) both map to the single combined post. When there is genuinely no equivalent — the content is gone and not coming back and had no value — you make a deliberate choice: redirect to the most relevant parent page if any authority is worth salvaging, or return a clean 404/410 (Chapter 14) if the page should simply cease to exist. What you never do is shrug and point everything at the homepage.

🚫 SEO Myth: "Just redirect everything to the homepage — Google will figure it out." This is the most common and most expensive redirect mistake there is, and it does the exact opposite of what people think. When you redirect a specific old URL to an irrelevant destination like the homepage, Google does not gratefully accept the transfer of signals. It recognizes that the redirect target has nothing to do with the original page, and it treats the redirect as a soft 404 — that is, it treats the old page as gone, and passes along none of its ranking signals. So the lazy homepage redirect throws away precisely the link equity and history you were trying to preserve, page by page, while looking tidy to a human who visits and sees "well, it went somewhere." Every mass-to-homepage redirect is a quiet act of self-sabotage. Map to the equivalent, or the redirect is worse than useless.

What a disciplined map looks like in practice is easier to show than to describe. Notice, in the excerpt below, that every row carries a deliberate decision — a like-for-like 301, two thin posts consolidated into one, even a chosen 410 for a page that should simply die — and that nothing is pointed lazily at the homepage.

📄 Read the Report

text FIGURE 21.2 — "A disciplined redirect map (an excerpt)" [constructed teaching example] OLD URL NEW URL CODE NOTE /services/furnace-repair /heating/furnace-repair 301 like-for-like; 4 backlinks /services/ac-repair /cooling/ac-repair 301 like-for-like; crown jewel /water-heater-services /plumbing/water-heater-repair 301 the #11 page — preserve fixes /blog/best-thermostats-2019 /blog/best-thermostats 301 updated post; consolidate /blog/best-thermostats-2020 /blog/best-thermostats 301 merged into the one above /locations /service-areas 301 renamed hub /old-coupon-jan2018 (return 410 Gone) 410 dead, zero value, on purpose / (homepage) / (new homepage) — unchanged address on redesign ── every row has a decision; the "410" is a CHOICE, not an oversight; nothing points lazily at "/" ──

For a small site, a redirect map is a spreadsheet you build by hand. For a large site — an e-commerce catalog with fifty thousand URLs — it is built with pattern rules (all /old-category/* URLs map to /new-category/* by a transformation) plus a hand-checked list of the high-value exceptions, because patterns are efficient but blind, and the crown jewels deserve individual verification. Either way, the output is the same: a testable list where every old URL has exactly one deliberate destination.

🔗 Connection The pages you must protect most fiercely in the redirect map are the ones with external backlinks, because that is where off-site authority lives — the subject of Chapter 22 (how links work) and the whole of Part IV. A lost or broken redirect on a page with fifty referring domains does not just lose that page's rankings; it severs fifty other sites' votes from your domain. When you triage the map under deadline pressure, sort by referring domains and defend the top of that list first.

What a redirect map can and cannot do, stated at honest strength: it can preserve the ranking signals of every page you map correctly, which is most of the battle. It cannot, by itself, hold your rankings if the new pages are worse, if the internal linking collapses (§21.4), or if the whole site falls out of the index because of a launch error (§21.5). The map is necessary and not sufficient — the most important single document in the migration, and still only one document among the checklist.

21.4 Redirect chains and other traps

A correct redirect map can still be implemented in ways that quietly bleed value. The most common is the redirect chain: a URL that redirects to a URL that itself redirects, and perhaps redirects again — A points to B, B points to C, C points to D — instead of A pointing straight to the final destination. Chains are rarely created on purpose. They accumulate, one layer per migration, like sediment.

REDIRECT CHAIN vs. THE CLEAN SINGLE HOP                         [schematic — not to scale]

  THE CHAIN (bad):
    http://old.com/page  ──301──▶  https://old.com/page  ──301──▶  https://new.com/page
                                                                   ──301──▶  https://new.com/services/page
         (4 addresses, 3 hops: each hop adds delay, wastes crawl, risks a dropped signal)

  THE CLEAN HOP (good):
    http://old.com/page  ─────────────────301─────────────────▶  https://new.com/services/page
         (1 hop, straight to the final URL — update the OLD rules to skip the middlemen)

Picture how this happens to a real business. Years ago they migrated HTTP to HTTPS, adding a redirect layer. Later they changed domains, adding another. This year they restructured the URLs, adding a third. If each migration only ever redirected "the previous version" to "the current version," an original URL now limps through three hops to reach its home. Why does this matter? Three reasons. Each hop adds latency, so users and crawlers wait longer. Each hop consumes crawl budget, so Googlebot does more work to reach less content. And Google follows only a limited number of hops — historically around five to ten — before it gives up on a chain entirely, so a long enough chain means the final page is never reached at all, and any signal in the middle can be diluted or dropped along the way. The fix is a rule you apply every time you migrate: redirect the original URL directly to the final URL, and update old redirect rules to skip the middlemen. One hop, always.

Worse than a chain is a redirect loop — A redirects to B and B redirects back to A — which makes the page permanently unreachable for everyone, a total outage for that URL. Loops usually come from conflicting rules (one says "force www," another says "force non-www") fighting each other forever. Which points at another trap: the host variants. Your site can be reached as http or https, as www or non-www — four combinations of the same address. Exactly one should be canonical, and all the others should 301 to it in a single hop. Get this wrong and you either split your signals across variants or spin up a loop.

Then there is the quietest trap of all, the one that survives even a perfect redirect map: the internal links. Redirects are a safety net for external links and old bookmarks — things you do not control. Your own internal links you do control, and after a migration every one of them should point directly at the new URL, not at the old URL that now redirects. If you rely on redirects for internal navigation, every click inside your own site takes an unnecessary hop, you scatter needless load across your whole architecture, and you signal a sloppiness that a clean site never shows. Update the internal links in the new templates and content so they point at the final URLs from day one; let the redirects handle only the outside world. This is a direct application of the internal-linking discipline of Chapter 15.

🔄 Check Your Understanding A developer proudly reports that "all the redirects work — I tested a dozen old URLs and every one of them lands on the right new page." Name two things this test does not catch that could still be costing you.

Answer

(1) Chains. "It lands on the right page" is true of a three-hop chain and a clean single hop alike — the destination is correct either way. You have to inspect the number of hops, not just the final landing spot, with a crawler that reports the full redirect path. (2) Internal links still pointing at old URLs. The redirects "working" masks the fact that your own navigation and body links may be firing through redirects on every click; a crawl of the new site will surface internal links that resolve via a 301 instead of hitting the final URL directly. Also fair: missing redirects for orphan old URLs that weren't in the tested dozen (that's why the inventory in §21.2 must be exhaustive).

A few more traps to name so the checklist can catch them:

• 302 where a 301 belongs (§21.3) — a temporary code for a permanent move stalls signal consolidation.
• JavaScript or meta-refresh redirects instead of a server-side 301. Google can sometimes follow these, but they are slower, weaker, and unreliable as a migration mechanism. The migration standard is a server-level 301; do not hand your entire site's continuity to client-side code (the rendering risks of Chapter 19 apply).
• Broken redirects that point at a new URL which does not actually exist, producing a 404 at the end of the chain — a redirect map written against a new-site structure that changed after the map was frozen.
• The dropped inheritance. A migration must consciously carry over the things that live around the content: canonical tags, hreflang annotations (Chapter 20), the robots.txt rules, the XML sitemaps (now regenerated with the new URLs), the structured data (Chapter 18), and the analytics tags. Each of these is generated by the old platform and must be deliberately re-implemented on the new one, because none of them travels automatically through a redirect.

The through-line of every trap in this section is the same: a redirect moves a visitor, but the value of a page rides on a dozen other signals that a redirect does not carry. The discipline is to move all of them, in one clean hop, and then to prove you did.

21.5 Staging, launch, and the go-live checklist

You do not build the new site in public. You build it on a staging site — a private, pre-production copy of the new site, on a hidden URL or behind a password, where the team assembles and tests everything before it goes live. Staging is where redirects get verified, templates get checked, and the whole machine gets a dress rehearsal. It is indispensable. It is also the source of the single most catastrophic mistake in this entire book, and I want to give it the emphasis it has earned across a thousand ruined launches.

To keep Google out of the half-built staging site, teams block it from being indexed — usually with a site-wide noindex tag, a Disallow: / in robots.txt, or HTTP password protection. That is correct and necessary; you do not want Google indexing your unfinished site. The catastrophe is this: when the new site goes live, that block is still in place, and it ships to production. The beautiful new site launches. The team celebrates. And the entire website is carrying an instruction that tells Google to stay away, so within days it falls out of the index completely — every page, gone — and organic traffic collapses to nothing. The cause is a single line of code that should have been removed at launch and was not.

🔗 Connection This is the accidental-noindex catastrophe first flagged all the way back in Chapter 1 (§1.4), where it appeared as the archetype of "a good page that never gets indexed." Here it has a specific name, a specific cause (the staging block), and a specific home (launch day) — and a specific defense. It is the reason the first line of any go-live checklist is not "check the redirects" but "confirm the site is indexable at all." A perfect redirect map on a noindexed site is a beautiful forwarding system delivering mail to a house Google has been told to ignore.

The defense against every launch-day disaster is the same: a go-live checklist, executed in three phases — before, during, and after the switch. This is the operational core of the chapter, the artifact you actually run. Here is the shape of it:

THE GO-LIVE CHECKLIST                                           [schematic — the operational core]

  BEFORE LAUNCH (on staging, days ahead)
    [ ] Crawl staging; confirm every page returns 200 and renders fully
    [ ] Redirect map loaded and TESTED: sample old URLs → correct final new URL, ONE hop
    [ ] Internal links updated to new URLs (no internal link fires through a redirect)
    [ ] Titles, headings, body content, alt text carried over (nothing silently dropped)
    [ ] Canonical tags, hreflang, structured data present and correct on new templates
    [ ] New XML sitemap generated with the NEW URLs; old sitemap ready to submit too
    [ ] Analytics + Search Console tracking installed on the new site
    [ ] Mobile + Core Web Vitals checked — no regression vs. baseline (Ch 16, 17)
    [ ] Pick the timing: LOW-traffic window; NOT a Friday; NOT before peak season or a known update

  AT LAUNCH (the switch)
    [ ] ★ REMOVE the staging noindex / robots Disallow — and VERIFY it is gone on the LIVE site ★
    [ ] Redirects live at the INSTANT of switch (never "we'll add them after it's stable")
    [ ] robots.txt on the live site allows crawling; correct canonical host (one of www/non-www, https)
    [ ] Submit the new XML sitemap in Search Console; keep the old URLs' sitemap available
    [ ] For a DOMAIN change: use Search Console's Change of Address tool (Ch 27)

  AFTER LAUNCH (immediately, then daily — see §21.6)
    [ ] Live-crawl the production site: catch broken redirects, chains, 404s, missing pages
    [ ] Spot-check crown-jewel URLs in the URL Inspection tool: indexable? correct canonical?
    [ ] Watch Search Console coverage, 404 spikes, and Performance; watch analytics + rankings

Two items on that list carry more weight than the rest and deserve a second look. The starred item — verify the noindex is gone on the live site, not just intended to be gone — is non-negotiable, and "verify" means actually loading a production page and checking its source, or inspecting the live URL in Search Console, not trusting that someone remembered. The second is the redirects being live at the instant of the switch. There is a tempting, disastrous shortcut here that has its own myth.

🚫 SEO Myth: "We'll launch first and add the redirects once the site is stable." This sounds prudent and is ruinous. In the window between the old URLs disappearing and the redirects going live, every one of your old URLs returns a 404 — to users following links and bookmarks, and to Googlebot re-crawling your best pages. Google sees your crown jewels return "not found" en masse, and it does not wait patiently for you to get around to the redirects; it begins dropping those URLs and can start reassessing the site. External links now point at dead ends. Even a few days of this does real, sometimes lasting damage. The redirects are not a follow-up task. They go live in the same breath as the new site, which is why they are built and tested on staging first. There is no "later."

The timing choices on the checklist are strategy, not superstition. Launch in a low-traffic window (a quiet weeknight, not a Friday when no one is around for the weekend if something breaks) so that the inevitable volatility hits when the fewest customers are watching and the most engineers are available. Never migrate right before your peak season — a retailer does not replatform in November, a tax service does not migrate in March — because a normal temporary dip during your busiest weeks is a catastrophe even if it fully recovers in February. And if Google has announced a core update in progress (Chapter 6), wait, so that you are not trying to disentangle "did the migration hurt us or did the update?" in the aftermath.

⚖️ Evidence Check Claim: "Do the checklist right and you won't lose any traffic." — This is the reassuring promise clients want and no honest practitioner makes. What's true: a disciplined migration minimizes loss and makes recovery reliable and reasonably quick. What's not: "zero loss." Google itself says to expect temporary fluctuations while it reprocesses (§21.7); even textbook migrations usually dip before they recover, and some settle slightly below or above the old baseline for reasons no checklist controls. The honest promise is: we will protect the equity, minimize the dip, recover fast, and know within days if something is actually wrong — not "nothing will happen." Anyone guaranteeing no loss is selling confidence they cannot deliver.

21.6 Post-migration monitoring

The launch is not the finish line; it is the start of the phase that actually determines the outcome. Migration monitoring is the systematic tracking, in the hours, days, and weeks after go-live, of crawling, indexing, redirects, traffic, and rankings — so that problems are caught in days, when they are cheap to fix, rather than discovered in the next quarterly report, when the damage has compounded. The migrations that recover fastest are not the ones that were launched perfectly; no migration is launched perfectly. They are the ones that were watched closely enough to catch the three missed redirects and the one template still carrying a noindex within forty-eight hours.

Here is what to watch, and where, mapped to the tools you will meet in Part V:

• Google Search Console (Chapter 27) is mission control. Watch the Pages/indexing report for new URLs getting indexed and old ones dropping out — and above all for a spike in "Not found (404)", which means missed redirects, or a spike in "Excluded by noindex," which means the catastrophe of §21.5. Watch the Performance report for the cliff or the wobble in clicks and impressions. Check Crawl stats to confirm Googlebot is finding the new URLs. For a domain move, watch the Change of Address status. Keep both the old and new site verified as properties so you can see the handoff from both sides.
• Analytics (GA4, Chapter 28) for organic sessions and, more importantly, conversions — because a migration that holds traffic but breaks the booking form has still failed the business. Watch for a sudden drop that a traffic metric alone would miss.
• Rank tracking (Chapter 30) for your priority terms: did they hold, dip, or vanish, and — the key question — is the trend line pointing back up?
• A fresh crawl of the live site, run repeatedly in the first weeks, to catch broken redirects, chains that slipped in, new 404s, and pages that didn't make the move.
• Server logs (Chapter 33), if you have them, to confirm Googlebot is crawling the new URLs and successfully following the redirects rather than hammering dead old ones.

📄 Read the Report

text FIGURE 21.3 — "Migration monitoring, day 10" [constructed teaching example] THE REPORT The migration watch dashboard, ten days after a domain move. New + old properties. WHAT'S THERE New site indexed pages: climbing (310 of ~500 so far). Old site indexed: falling (as expected). Search Console "Not found (404)": SPIKED to 47 — a cluster of blog URLs. Organic clicks: down ~20% vs. baseline, flattening, not still falling. Priority rankings: wobbling ±3 positions. Conversions (form fills): steady. Change of Address: "processing." WHAT IT SHOWS Mostly a NORMAL early migration: indexing handoff underway, a shallow dip that has stopped deepening. But the 47 404s are a REAL, fixable problem — a batch of old blog URLs that never got redirects (they were orphans a crawl missed; see §21.2). WHAT IT DOESN'T It can't tell you *why* those 47 were missed or whether more are hiding among URLs Google hasn't re-crawled yet. Assume there are more; re-audit the inventory. THE MOVE Fix the 47 today: map each to its equivalent, add the 301s. Keep watching the dip — if it's bottoming and rankings are wobbling (not gone), that's recovery beginning. THE LESSON Monitoring turns a vague "is it okay?" into a specific to-do list. The 404 spike is the gift: it's the exact thing you can still fix while it's cheap.

The single most valuable reading habit in that dashboard is the one you can practice long before you ever run a migration — the fast, per-URL check that tells you whether a specific page is still in the index at all.

🛠️ Try It on Your Site You do not need a migration to practice the most important monitoring habit. Any time you make a significant change to a page — a new URL, a big edit — open that URL in Search Console's URL Inspection tool and ask it two questions: Is the URL on Google? and What is the Google-selected canonical? That forty-second check, run on your crown-jewel URLs the morning after a launch, is the single fastest way to catch a page that has silently fallen out of the index. Build the reflex now on calm days; you will run it under pressure on launch day.

The cadence matters. Day one: run the immediate checks — indexability, redirects, the crown jewels. First week: check daily; this is when fixable fires are still small. First month: check weekly as the picture settles. After that, fold it into the normal weekly Search Console review (Chapter 27). What monitoring gives you is early, specific information; what it cannot give you is certainty in the first week, because some signals — especially rankings and the full indexing handoff — genuinely take weeks to settle. Which raises the hardest question in the whole chapter, and the one clients ask on day three in a panic: is this dip normal, or are we in trouble?

21.7 What "normal" looks like — and when to worry

Even a flawless migration usually dips before it recovers. This is not a failure; it is the visible shape of Google reprocessing everything you changed. Remember the burst-of-change idea from §21.1: overnight, Google has to re-crawl old URLs, discover and follow redirects, crawl and re-render new URLs, re-index them, and move the accumulated signals from old addresses to new — across your whole site, at its own pace. While that work is in flight, rankings wobble and traffic sags. Google's own migration guidance says to expect temporary fluctuations and that recovery takes time. So the normal shape of a healthy migration looks like this:

THE NORMAL MIGRATION CURVE                                      [schematic — not to scale]

  organic
  traffic
   │        ┌─ baseline ──────────────                    ╭──────── recovered (often higher)
   │  ──────┘                        ╲                   ╱
   │                                  ╲__   wobble    __╱
   │                                     ╲___      ___╱
   │                                         ╲____╱  ← the dip: launch → a few weeks
   └────────────────────────────────────────────────────────────────▶ time
        LAUNCH ▲            weeks 1–4: dip + wobble        weeks 4–12: recovery

A dip of some size in the first one to four weeks, a few weeks of ranking wobble as positions bounce around, then a climb back toward — and, if the new site is genuinely better, past — the old baseline over roughly one to three months (longer for very large sites). That is a migration working. The instinct to panic in week two and rip the whole thing out is not just wrong; it is actively harmful, because a rollback forces Google to reprocess everything again — you have now migrated twice, doubling the volatility, and you did it right when recovery was probably beginning. Patience, here, is a technical skill.

But patience is not the same as passivity, and the professional judgment this chapter is building toward is knowing exactly which signals are "wait" and which are "act now." They are genuinely different, and confusing them is how migrations die twice.

NORMAL (wait and monitor)                  |  EMERGENCY (act today — do not "wait it out")
-------------------------------------------|-------------------------------------------------
 A shallow-to-moderate dip in weeks 1–4    |  Traffic falls off a CLIFF and keeps falling
 Rankings wobbling ± a few positions       |  Rankings for crown-jewel terms GONE, not moving
 New URLs indexing as old ones drop        |  The whole SITE dropping out of the index
 A dip that is bottoming / flattening      |  Indexed-page count collapsing toward zero
 A handful of 404s you're fixing           |  A FLOOD of 404s (redirects missing at scale)
 Change of Address "processing"            |  Old URLs still indexed, new ones not (redirects broken)
 Conversions holding                       |  "Excluded by noindex" climbing ← the §21.5 catastrophe

The right-hand column is not "a bad dip." It is a broken migration, and each row points at a specific, findable cause you fix immediately rather than wait out. A whole-site deindexing means the staging noindex shipped (§21.5) — find it and remove it tonight. A flood of 404s means redirects are missing at scale — go back to the inventory and map them. Old URLs still indexed with new ones absent means the redirects themselves are broken — test and fix them. These are emergencies precisely because waiting makes them worse. The skill is not "stay calm always" or "panic always"; it is reading which column you are in.

🚫 SEO Myth: "A well-planned migration has zero traffic loss — if you dipped at all, someone messed up." This myth punishes the honest and rewards the lucky. Even textbook migrations usually show a temporary dip, because the dip is Google reprocessing, not a mistake. Judging a migration by "did traffic ever drop?" is the wrong test; the right tests are did it recover, how fast, and to what level? A migration that dipped 20% and recovered fully in five weeks was a success. A migration that "never dipped" because it was tiny and no one was watching tells you nothing. Grade migrations on recovery, not on a flat launch week that real migrations rarely have.

If recovery is the real test, the natural next question — and the one clients ask most insistently — is how long does it take? Here honesty is the only professional answer, because the true response is a shape and a range, not a date.

⚖️ Evidence Check Claim: "Recovery takes X weeks." — What's confirmed: Google states that site moves cause temporary fluctuations and that reprocessing takes time; larger sites take longer. What no one can honestly give you is a precise number, because it depends on your site's size, how cleanly the redirects were done, how fast Google re-crawls you, and whether a core update lands in the middle. The professional honesty is a range and a shape — expect a dip, expect weeks (sometimes a couple of months), watch the trend line — not a promise of "back to normal by the 14th." And always check the calendar: if traffic moved the same week as a confirmed core update (Chapter 6), the update may be the cause, not your migration. Timing is the cheapest diagnostic you have.

This is where the chapter meets the sixth theme of the whole book: SEO is a long game. A migration is not a launch-day event; it is a multi-week-to-month process, and the value it protects — the years of authority, links, and history compressed into your redirect map — is exactly the compounding asset that patience builds and impatience destroys. It is also the clearest argument in the book for traffic diversification. The business that gets all its customers from Google organic is the business for which a botched migration is an extinction event. The business that also has email, direct, social, referral, and a real brand has a cushion while the organic channel recovers. Diversification is not defeatism about SEO; it is insurance for exactly the week when the ground moves under your site — and a migration is you moving it on purpose.

📈 The Strategy File

Rivertown Home Services is ready for a facelift. Marisa Delgado wants the site to look modern before the spring campaign — the current design, on a WordPress theme that predates most of the smartphones its customers use, embarrasses her every time she hands out a business card. Her brother and co-owner Tony has found a designer, picked a new theme, and set a launch date. Your job, as the SEO on this project, is to make sure the spring campaign does not launch onto a site Google can no longer see.

The good news, which you establish first, is that this is the least dangerous kind of migration: a redesign on the same domain and the same CMS (a WordPress theme change), not a domain move and not a platform switch. The URLs should not change at all — WordPress permalinks are set independently of the theme, so rivertownhome.example/plumbing/water-heater-repair stays exactly where it is. That means, in principle, almost no redirect map is required. But "least dangerous" is not "safe," and the two ways same-domain redesigns die are both live here.

Risk one — the silent element drop. A new theme regenerates every template, and a theme can quietly change or discard the on-page work the earlier chapters built: the rewritten title tags and heading structure (the water-heater page's fixes), the internal links that the architecture plan added, the LocalBusiness and Service and FAQ structured data, the image alt text. None of that travels automatically to a new theme. So your pre-launch checklist item is a template-by-template audit on staging: does the new theme still render our titles, our headings, our internal links, our schema, our alt text? Anything the theme drops, you re-implement before launch.

Risk two — the staging noindex, the catastrophe from Chapter 1. The designer is building the new theme on a staging site, and staging sites are blocked from Google. If that block ships to production at go-live, Rivertown's entire site — every location page, every service page, the whole thing — falls out of Google's index within days, and the spring campaign drives paid clicks to a site that has vanished from organic search entirely. This is the accidental-noindex disaster we first named in Chapter 1, §1.4, and it is the single starred line of Rivertown's checklist: at launch, remove the staging block and verify on the live site that the site is indexable — by loading a live page and inspecting a production URL in Search Console, not by trusting that the developer remembered.

Here is Rivertown's migration checklist, tuned to a same-domain theme redesign:

FIGURE 21.4 — "Rivertown's theme-migration checklist"           [the Strategy File]
  BEFORE (on staging)
    [ ] Baseline now: export GSC Performance (12 mo) by page; record rankings for priority terms
    [ ] Confirm the new theme does NOT change permalinks (URLs stay identical) — if any change, MAP it 301
    [ ] Audit every template on staging: titles, headings, body copy, internal links, alt text preserved
    [ ] Confirm LocalBusiness + Service + FAQ schema still present on the new theme (Ch 18)
    [ ] Check mobile + Core Web Vitals on staging — the redesign should IMPROVE the slow mobile site, not
        regress it (Ch 16, 17); a faster theme is the SEO upside of this move
  AT LAUNCH
    [ ] ★ Remove staging noindex / robots Disallow; VERIFY the live site is indexable ★  ← the #1 item
    [ ] Any changed URL has a live, tested, one-hop 301 (should be few or none)
    [ ] Regenerate + submit the XML sitemap; confirm robots.txt allows crawling
  AFTER (day 1, then daily for a week)
    [ ] Inspect crown-jewel URLs (water-heater page, the five location pages) in URL Inspection: indexed?
    [ ] Watch GSC for "Excluded by noindex" and "Not found (404)"; watch clicks + rankings for the dip
    [ ] Because the domain is unchanged: NO Change of Address tool, and NAP/GBP citations are unaffected

What this component settles, honestly, and what it does not. It protects the migration: done this way, Rivertown keeps its rankings and its hard-won on-page work through the redesign, and ideally gains the speed the old theme was bleeding. It does not, by itself, improve Rivertown's rankings — a prettier, faster site does not fix the thin location pages, win the local pack, or rank the service-by-city pages. Those belong to the local, architecture, and content work in Chapters 15, 25, and 33. The redesign's job is to make the move without loss and clear the ground for that work — not to substitute for it. Note it in the running strategy as a low-URL-change redesign with a verified go-live, and move on with the equity intact. (All Rivertown figures are a constructed teaching example.)

Conclusion

We began with the phone call that sounds like good news — a new domain, a redesign, a modern platform — and we treated it as what it really is: the most dangerous operation in SEO, and one that is survived by discipline rather than luck. The through-line is simple to state and hard to execute. A migration asks Google to move everything it knows about your old URLs onto new ones, and your entire job is to make that transfer lossless: inventory every URL that matters, map each old one to its single best equivalent with a 301, avoid the chains and traps that bleed the value away, launch behind a checklist whose first line is "is the site even indexable?", and then watch the aftermath closely enough to tell a normal dip from a real fire.

We were honest, too, about the limits. A redirect map preserves equity; it cannot make a worse page rank like a better one. A checklist minimizes loss; it cannot promise zero loss, because even flawless migrations dip while Google reprocesses. And "recovery in X weeks" is a range and a shape, never a guarantee — anyone selling you a no-loss migration is selling confidence they cannot back. What you can promise is real: protect the signals, minimize the dip, recover reliably, and know within days if something broke. That is the professional standard, and it is entirely achievable.

This chapter closes Part III. You now have the full technical foundation — crawlability and indexing (Chapter 14), architecture (Chapter 15), speed (Chapter 16), mobile (Chapter 17), structured data (Chapter 18), JavaScript rendering (Chapter 19), international targeting (Chapter 20), and the discipline to change any of it without losing what you have built (this chapter). Technical SEO makes a site Google can trust. Part IV turns to the other half of the ranking contest: why Google trusts one site more than another, and how that trust is earned off the page. It begins with the idea that built Google in the first place — links as votes — and the honest math of how authority flows across the web.

→ Continue to Chapter 22: How Links Work — PageRank, Authority, and Why Links Still Matter.

Key Terms

• Site migration — any substantial change to a website (domain, protocol, CMS, design, or structure) that can alter how search engines crawl, index, or rank it, even when the content appears unchanged.
• 301 redirect — a permanent server instruction that a URL has moved to a new address; it forwards visitors and passes the old URL's ranking signals to the new one, making it the correct redirect for a migration.
• Redirect map — the master document pairing every old URL with the single best new URL it should redirect to, built from the URL inventory and implemented one-to-one.
• Redirect chain — a URL that redirects to another URL that itself redirects (A→B→C…); each hop adds delay and risk, so redirects should always go straight from the original to the final URL in one hop.
• HTTPS migration — the move from http:// to https://; technically changes every URL, so it requires redirects and updated canonicals despite feeling trivial.
• Staging site — a private, pre-production copy of a site where the new build is assembled and tested; usually blocked from indexing, which is safe on staging and catastrophic if the block ships to production.
• URL inventory — the complete, de-duplicated list of every current URL that earns traffic, rankings, links, or conversions, annotated so each gets a deliberate migration decision.
• Migration monitoring — the systematic post-launch tracking of crawling, indexing, redirects, traffic, and rankings that catches problems in days rather than quarters.

Spaced Review

Retrieval practice. Two questions from this chapter, three that reach back to the technical foundation it rests on. Try each before revealing the answer.

1. Why is it a serious mistake to redirect every old URL to the new homepage during a migration, and what does Google do with such a redirect?
2. A team's new site launched last night and its entire organic traffic is gone this morning — not dipping, gone. Name the first thing you check, and why this is an "act now," not a "wait and see."
3. (Chapter 14) In your own words, what is the difference between a 301 and a 302 status code, and why does using a 302 for a permanent move cause a problem?
4. (Chapter 14) A page is blocked by Disallow in robots.txt. Why does that not reliably remove it from Google's index — and how does that differ from a noindex tag?
5. (Chapter 15) After a migration, why should you update your internal links to point at the new URLs directly, even though the redirects would make the old internal links "work"?