Case Study 2 — The Domain Move That Forgot the Map: How a Rebrand Lost Half Its Traffic Twice

A complementary angle. Case Study 1 watched a well-resourced giant dip despite careful planning. This one watches a capable small team lose half its organic traffic through ordinary, avoidable mistakes — and then lose more by panicking. It teaches the chapter's discipline from the failure side, where it bites hardest.

This is a labeled composite. It is not one named company; it is a pattern that plays out constantly at agencies and in-house teams, assembled from the common, well-documented ways domain migrations go wrong. Every number below is illustrative — round figures chosen to show the shape. What is real is the sequence of mistakes, and how reasonable each one felt in the moment.

Background: a rebrand with a deadline

A profitable regional services company — call it a mid-size business with a solid seven-year-old website — rebrands. New name, new logo, and a new domain: oldbrand.com becomes newbrand.com. The marketing team is thrilled; the new domain is shorter and cleaner. The old site earns about 40,000 organic visits a month, built up patiently over years, and roughly 300 pages carry that traffic, with a few dozen pages holding the bulk of the company's hard-won backlinks from local press and industry directories.

The launch is scheduled around the rebrand announcement — a fixed marketing date that cannot move. The website move is treated as a subtask of the rebrand, owned by a web developer who is competent but has never run a migration, with no SEO in the room. Here is how it goes wrong, one reasonable-seeming step at a time.

The issue: four mistakes, each of which felt fine

  • No inventory, so no complete map. The developer maps the main navigation — the homepage, the service pages, the top-level sections — perhaps 40 URLs, and redirects those to their new equivalents. The other ~260 URLs (old blog posts, landing pages, deep pages, and — fatally — several orphaned pages that still held backlinks) are not on anyone's list. There was no §21.2 inventory pulled from Search Console, analytics, and backlink data, so nobody knew those pages existed to migrate. At launch, those 260 old URLs return 404 Not Found.
  • The leftover redirects go to the homepage. Realizing late that "lots of old links are breaking," the team adds a catch-all rule: any old URL not otherwise handled redirects to the new homepage. This feels like a safety net. It is the opposite. Google reads each of those as a soft 404 (§21.3), so the redirect passes no signals — the backlinks pointing at those old pages now point at a page Google treats as effectively gone, and the equity evaporates.
  • A staging block nearly ships — and a noindex on one template does. The new site was built on staging behind a site-wide noindex. Someone remembers to remove it from most of the site at launch — but the blog template, built separately, still carries noindex, so the entire blog (a third of the traffic) quietly stays out of the index. Nobody checks, because "we launched, it's up, it looks great."
  • The launch is on a Friday, and nobody watches. The switch happens Friday afternoon before a long weekend. No one runs the day-one checks. By the time anyone looks at analytics on Tuesday, four days of damage have compounded.

text FIGURE C21.2 — "Half the traffic, gone in a week" [constructed teaching example] WEEK 0 (before) WEEK 1 (after launch) WHAT HAPPENED ~40,000 organic visits/mo ~20,000 and falling 260 old URLs 404; blog noindexed 300 URLs mapped? NO 40 mapped, 260 unmapped no inventory → no complete map Backlinks intact Backlinks now hit soft-404s catch-all → homepage = signals lost Blog indexed Blog EXCLUDED by noindex staging block shipped on one template (All figures illustrative — the SEQUENCE of avoidable mistakes is the lesson, not the numbers.)

The panic: how they turned a bad week into a bad quarter

Here the case earns its place as the "failure" study, because the second half of the damage is self-inflicted and even more instructive than the first.

Tuesday, seeing traffic halved, the team panics. Someone senior declares the new site a disaster and orders a rollback to the old domain. The old site is restored, the redirects are pulled, and newbrand.com is mothballed "until we figure it out." This feels decisive and responsible. It is the worst possible move, because — per §21.7 — a rollback forces Google to reprocess everything again: it had begun moving signals to the new domain, and now it has to unwind that and re-establish the old one, which itself has been partly deindexed and redirected. The site has now migrated twice in ten days. Volatility doubles. Traffic, which might have been stabilizing, drops further and gets choppier, and now no one can tell what is causing what.

The team spends three weeks flip-flopping — new domain, old domain, half-redirected, contradictory signals — and by the end organic traffic is worse than after the initial botched launch, the backlink equity is scrambled across two domains, and morale is gone. The technical problems were fixable in days. The panic turned them into a quarter-long crisis.

What it shows

  1. The inventory is not optional; it is the whole safety net. Every downstream disaster traces back to the missing §21.2 inventory. You cannot map URLs you never listed, and the ones you forget are disproportionately the old, orphaned, link-bearing pages that a navigation-only view can't see. You migrate a spreadsheet, not a website — and this team never built the spreadsheet.
  2. The lazy homepage redirect is worse than no redirect. The catch-all felt like damage control and actively destroyed equity by converting real backlinks into soft-404s. A redirect to an irrelevant page is not a partial save; it is a full loss dressed up as a fix.
  3. Verify indexability on the live site, per template. "We removed the noindex" was true of most of the site and false of the blog. The go-live checklist's starred item (§21.5) is "verify," not "intend" — and verification is per-template, because templates are built and deployed separately.
  4. The rollback was the biggest mistake of all. A normal-to-bad dip is survived by fixing forward: add the missing redirects, remove the stray noindex, and let Google reprocess once. Ripping the migration out mid-flight makes the search engine reprocess twice and turns a recoverable week into a lost quarter. Patience is a technical skill; panic is a technical mistake.

Outcome

In the recoverable version of this story — the one a calm practitioner produces — nobody rolls anything back. Instead: on day one they would have run the live-crawl and URL-inspection checks, caught the 404 flood and the blog noindex within hours, built the missing redirect map from a proper inventory over the next two days, replaced the homepage catch-all with real one-to-one 301s to equivalents, removed the blog's noindex, resubmitted the sitemap, filed the Change of Address, and then waited and monitored while Google reprocessed a single, now-correct migration. Traffic dips, wobbles for a few weeks, and climbs back — the normal curve of §21.7 — because the equity was recovered before it was abandoned.

In the version that actually happened, the rollback turned a two-day fix into a three-month recovery, and the lasting lesson the team learned — expensively — was every heading in this chapter.

Connect it to Rivertown. This is the disaster Rivertown's Strategy File is built to avoid, in miniature and in the safer same-domain case. Rivertown's checklist leads with a baseline and inventory, keeps the URLs unchanged (so there's little to 404), stars "verify the live site is indexable" per template, and commits — in writing — to fix forward and monitor rather than panic-roll-back if the normal dip appears. The Delgados don't have 40,000 visits to lose; they have 8,000 they can't afford to. Same discipline, smaller margin for error.

Discussion questions

  1. Every downstream failure in this case traces to one skipped step. Name it, and explain why the pages it would have caught (old, orphaned, link-bearing) are exactly the ones a "just map the menu" approach misses.
  2. The catch-all redirect to the homepage felt like responsible damage control. Reconstruct the reasoning the team used, then rebut it with what Google actually does with such a redirect (§21.3).
  3. The rollback is described as "the biggest mistake of all." Explain, using the "burst of change" reprocessing idea, why undoing a migration mid-flight can do more damage than the botched launch it was meant to fix.
  4. The blog stayed noindexed because verification wasn't done per template. Design the specific launch-day check that would have caught this in the first hour, and say which free tool you would use.
  5. Contrast this case with Case Study 1 (M&S). One is a giant that planned carefully and still dipped; the other is a smaller team that planned poorly and then panicked. What single principle do both cases teach about how to judge — and how to survive — the days after a migration?