Case Study 19.2 — The Redesign That Made the Content Disappear

A labeled composite, assembled from real, common industry patterns rather than one named company. The pattern — a replatform to a client-rendered single-page application that quietly de-indexes content, and the recovery via server-side rendering — is well documented across the SEO field. All numbers here are illustrative and constructed, marked as such; the mechanics are real.

Background

"Meridian Supply" (constructed) is a mid-size B2B distributor with a catalog of roughly 3,000 product and category pages that had, over a decade, earned steady organic traffic — the boring, compounding kind that pays the bills. The pages ran on an older server-rendered platform: unglamorous, but every page's content and links were in the HTML. The marketing team was proud of the traffic; the executives thought the site looked dated.

A redesign was commissioned. The agency proposed rebuilding the front end as a modern client-rendered single-page application — faster in-app navigation, a slicker feel, a trendier stack. Nobody in the room asked the question from §19.4: will our indexable content be in the initial HTML? The site looked flawless in every demo, because every demo happened in a browser that ran the JavaScript. It launched on a Friday.

The search/SEO issue

The first two weeks looked normal — the old pages were still in Google's index from before the launch, coasting on the previous crawl. Then, as Google re-crawled and re-processed the new URLs, organic traffic began to slide, and kept sliding. By week six it was down roughly 60% (illustrative), and the decline was still in progress.

The diagnosis, once someone finally ran the chapter's tests, took an afternoon:

  • View Source on any product page showed <div id="app"></div>, a bundle of scripts, and none of the product names, descriptions, or prices. The content was entirely client-built.
  • A site: phrase search for distinctive product-description sentences returned nothing — Google did not have that text.
  • URL Inspection confirmed it: for many URLs the rendered HTML was thin or empty, and the resource list showed the product-data API and several scripts timing out or erroring during Google's render. The render was failing or completing empty on a large share of the catalog.
  • The navigation had been rebuilt with <div> click handlers instead of <a href> anchors, so even the discovery path between pages was broken (Failure 1 from §19.6).
  • To finish the trifecta, the "related products" and specification tabs loaded their content only on click — which Googlebot never performs (Failure 2).

The redesign had not changed a word of the content. It had changed whether the content existed at the moment Google looked.

FIGURE C19.1 — "Same content, different visibility"           [constructed teaching example]
  BEFORE (server-rendered)          AFTER (client-rendered SPA)
  Product name in HTML   ✅          Product name only after JS   ❌ (often not rendered)
  Descriptions in HTML   ✅          Descriptions in a click-tab   ❌ (Googlebot won't click)
  <a href> nav links     ✅          <div onclick> "links"         ❌ (no road to follow)
  ~ steady organic       ✅          ~ −60% and falling            ❌  (illustrative)

Outcome

Meridian did not roll back the design — the business liked the new interface. Instead, working with the agency, they changed the rendering mode without changing the look:

  1. Server-side rendering was enabled for all indexable pages (via the framework's SSR capability), so the product content and specs were now in the initial HTML response.
  2. Navigation and internal links were converted to the framework's real-anchor link component (<a href>), restoring the discovery path and the flow of ranking authority (Chapters 15, 22).
  3. Tab and "related" content was rendered into the HTML (visually hidden until clicked, but present), so Googlebot had it without interacting.
  4. They re-verified every template with URL Inspection and site: phrase searches before declaring victory — the professional habit the launch had skipped.

Recovery of organic traffic began within weeks of re-indexing and, over a few months, returned toward the old baseline (illustrative) — the timeline SEO always runs on, never instant. The same interface that had cost 60% of the traffic now cost none, because the content was back in the HTML.

The lesson (and the limits)

This case teaches the chapter's boundaries as much as its rules:

  • A redesign is a rendering decision, whether or not anyone treats it as one. The single question "will our indexable content be in the initial HTML?" would have prevented the entire episode. It was never asked because the site looked perfect — in a browser that ran the JavaScript.
  • "It looks fine" is the most expensive sentence in JavaScript SEO. Every demo, every stakeholder review, happened in a full browser. The failure was invisible until someone looked at what Google saw.
  • The fix was not "abandon the framework." The same single-page application, reconfigured to server-render, was completely fine. This is the §19.4 point made painfully: the library was never the problem; the rendering mode was.
  • The limit: server-rendering was necessary but not sufficient. Meridian still had to fix the fake links and the interaction-gated tabs — architecture bugs that SSR alone does not cure — and still had to test. Turning on SSR is the beginning of getting it right, not the end.

Discussion questions

  1. Meridian's traffic looked normal for two weeks after launch, then fell. Explain why the damage was delayed, using the crawl-and-re-index cycle. Why does this delay make client-rendered launches especially dangerous?
  2. The company chose to fix the rendering rather than roll back the design. Under what circumstances would rolling back have been the better call? What would you need to know to decide?
  3. Identify all three §19.6 failures present in this case and match each to its fix. Which one, left unfixed, would still have hurt the site even after SSR was enabled?
  4. Write the one-sentence question that, asked before the redesign was approved, would most likely have prevented the whole episode. Who in the organization should have owned asking it?
  5. Contrast Meridian with Rivertown (WordPress, server-rendered by default). Why did one face this crisis and the other not — and what does that say about the advice "if it already puts content in the HTML, don't rebuild it into something that doesn't"?