A post-build script injects real head tags into a shared 3,780-byte shell, leaving the body untouched

Do the subtraction on the Search Console figures. 116 of 741 URLs had earned a single impression in 28 days ^[2], which leaves 625 URLs, 84.3 percent of the set, with none ^[18].

The writeup's explanation is that rendering is a separate, budgeted queue, and that a domain with little authority does not get much of that budget ^[4]. That inference is the author's; the post cites no Google documentation for it, and its own evidence is that several pages were indexed, so the renderer did run ^[4]. The duplicate-content half of the argument needs no such assumption. Before JavaScript ran, every one of the 741 URLs was the same 3,780 bytes, with the same title, no h1 and no body text ^[1]. Whatever the crawler concludes those pages are about, it concludes it from one document served 741 times ^[5].

The repair injects a real head into each generated HTML file after build and leaves the body exactly as the SPA served it ^[6]. Head-only was the load-bearing decision: no hydration flash, no static copy drifting away from what users see, and static markup that is a subset of the rendered markup rather than a different page, which is where the cloaking question is settled ^[7]. Values are read from the same source the React page reads, and a title that lives as a literal inside a component is extracted from that component's source rather than retyped ^[8].

Then react-helmet. On its first commit it removes every tag carrying `data-rh` and re-inserts its own, while tags without the attribute survive untouched ^[9]. So the static description in `index.html` stayed, Helmet appended its own, and pages shipped with two descriptions, the static one first in the head, which is the one crawlers read ^[10]. Read the attribute as a delete list that Helmet then re-populates, not as a marker of ownership: they marked `og:image`, Helmet does not re-insert it, and the share image vanished everywhere ^[11].

Their own injector failed for an unrelated reason. The replace was a regex keyed on attribute order, `<meta name="description"`, while the shell writes `data-rh="true"` first, so it matched nothing and said nothing ^[12]. Match on a tag containing the key attribute, never on the order the attributes happen to sit in ^[12].

The build bug is the one worth stealing. The prerender step takes its URL list from `sitemap.xml` ^[13], and `npm run build` ran vite, redirects, the crawl index and prerender, with the sitemap generator sitting outside as a command somebody had to remember ^[14]. A new route therefore deployed absent from the prerendered set, with no error, no warning, and exit 0, wearing the generic shell head ^[15]. Two builds went into suspecting the code before anyone suspected the input ^[16].

The same class of failure showed up in a dead ternary, `const key = m ? m[1] : route === '/some-route' ? null : null`, where both branches return null and the route fell through to a generic fallback body ^[17]. It has a route name in it, so it reads in review like a handled special case, which is exactly how it survived ^[17].

For the numbers to transfer, two things have to be true of your build: your metadata mounts client-side, and your prerender step reads a manifest generated somewhere outside the build command. The diagnostic is one request per route with a Googlebot user agent and a diff of the bytes ^[1].