<![CDATA[Shipping Notes]]>https://thedolceway.hashnode.devhttps://cdn.hashnode.com/res/hashnode/image/upload/v1593680282896/kNC7E8IR4.pngShipping Noteshttps://thedolceway.hashnode.devRSS for NodeTue, 15 Sep 2026 09:07:46 GMT60<![CDATA[My SPA served every URL the same 3,780 bytes, and Google believed it]]>, zero

, zero body text. The homepage, a blog post and a product page w]]>https://thedolceway.hashnode.dev/my-spa-served-every-url-the-same-3-780-bytes-and-google-believed-ithttps://thedolceway.hashnode.dev/my-spa-served-every-url-the-same-3-780-bytes-and-google-believed-itTue, 25 Aug 2026 10:07:22 GMTChecked with a Googlebot user agent one morning: every single URL on my site returned the same 3,780-byte shell. Same <title>, zero <h1>, zero body text. The homepage, a blog post and a product page were byte-identical before JavaScript ran.

Search Console agreed with the crawler rather than with me. Of 741 URLs, 116 had earned a single impression in 28 days, and a landing page that had been live for five months was still reported as "URL is unknown to Google".

Here is what I actually learned fixing it, including the two things that cost me the most time.

Google does render JavaScript. That is not the point.

The standard reply to this problem is "Googlebot executes JS now, you are fine." It does. Several of my pages were indexed, so rendering clearly happened.

But rendering is a separate, budgeted queue. A domain with little authority does not get much of that budget. So the practical question is not "can Google render my page", it is "will Google spend its budget rendering this page, today, before it decides what the page is about".

There is a second problem that has nothing to do with rendering: 741 URLs that are byte-identical before render look like duplicates. You are handing a duplicate-content signal to the crawler and hoping the render queue fixes your first impression.

What I built, and what I deliberately did not

I wrote a post-build script that injects a real <head> into each generated HTML file: title, description, canonical, robots, Open Graph, Twitter.

Head only. I left the body exactly as the SPA shipped it. That was deliberate:

  • No hydration flash.
  • No risk of a static copy drifting out of sync with what users see.
  • Nothing that could be read as cloaking, because the static markup is a subset of the rendered markup, not a different page.

Every value is read from the same source the React page reads. Where a title is a literal inside a component, the script extracts it from that component's source rather than having me retype it. A number retyped in two places is a number that will disagree with itself eventually.

Trap 1: react-helmet-async deletes tags you did not mark

My shell had static <meta name="description"> in index.html. Helmet sets its own on mount. I assumed the later one wins.

What actually happens: on its first commit, Helmet removes every tag carrying data-rh and re-inserts its own. Tags without that attribute survive. So the static tag stayed, Helmet's tag was added, and the page shipped two descriptions — with the static one first in the head, which is the one scrapers and crawlers read.

Every blog post on the site was advertising the generic homepage copy.

The fix is to mark the tags Helmet actually emits:

<meta data-rh="true" name="description" content="..." />

With one sharp edge: only mark tags Helmet will re-add. A data-rh tag that Helmet does not re-insert gets deleted on mount and never comes back. I marked og:image and lost my share image everywhere until I worked out why.

The matching bug in my own script: I wrote the replace as a regex keyed on attribute order, <meta name="description" ...>. The shell writes <meta data-rh="true" name="description" ...>. It silently matched nothing. Match on a tag containing the key, never on attribute order.

Trap 2: the script read the sitemap, and nothing regenerated the sitemap

This one cost the most time and had the least to do with SEO.

My prerender script takes its URL list from sitemap.xml. Reasonable: one source of truth for what exists.

But npm run build did not include the sitemap generator. It ran vite, then redirects, then the crawl index, then prerender. The sitemap was generated by a separate command somebody had to remember to run.

So I added a new route, built, deployed, and the page was live and completely absent from the prerendered set. No error. No warning. The build exited 0. The route simply was not in the list, so it was never processed, and it shipped with the generic shell head.

I burned two builds assuming my code was wrong before checking whether the input was stale.

If a build step consumes a generated artifact, that artifact's generator belongs in the same build command. Otherwise you have an ordering dependency that lives only in somebody's memory, and it fails silently rather than loudly.

Trap 3: a dead ternary that read as intentional

I found this while adding static content for a specific route:

const key = m ? m[1] : route === '/some-route' ? null : null;

Both branches return null. It was presumably mid-refactor when someone got interrupted. It looks purposeful enough to skim past in review — there is a route name in it, so it reads like a handled special case.

The effect was that the route fell through to a generic fallback body, which contained none of the terms the page existed to rank for. The page had been quietly pointless for weeks.

Grep your codebase for ? null : null. I will wait.

What I would tell myself at the start

  • Verify with curl and a crawler user agent, not with your browser. Your browser runs the JavaScript. That is exactly the thing you are trying to see past.
  • Static head, dynamic body, always from one source. Two hand-maintained copies of the same string are a future contradiction.
  • When something silently does nothing, check the input before you debug the logic.
  • data-rh is not decoration. It decides which tags survive.

If you want to see the output, it is running on CVBooster, a resume builder I run. Every page announces what it is before a line of JavaScript executes, which is all this work was ever about.

]]>