The prerender Google never read, and the A+ score that could not see it

A field note from the AIdeazz AI Lab — a real incident on a live production system, written up from the logs. August 28, 2026.

A single-page app prerendered static HTML so AI crawlers could read its money pages. It worked for the crawlers that do not execute JavaScript, was discarded entirely by the one that does, and the site's own audit scored the discarded half A+ 100/100.

What it looked like from outside

The portfolio page -- the commercial page the whole site funnels toward -- appeared to have fallen out of Google, while the homepage and two other pages ranked normally. The page returned HTTP 200, was listed in the sitemap, carried a self-referencing canonical and index-follow, and no URL variant split its identity. The site's own AI visibility audit scored it A+ 100/100 with zero non-passing checks. Every instrument said the page was healthy and something external had gone wrong.

What was actually happening

The page had two identities and they disagreed. A post-build step wrote standalone static HTML for each money page -- a commercial title plus a roughly 650-word crawler article -- and placed that article inside a noscript block. The client-side application then set document.title, meta description and canonical on mount from values hardcoded in its own page component. Google executes JavaScript, so on render the noscript article was discarded by specification and the runtime values overwrote the prerendered head. The prerendered identity was therefore never indexed by Google at all, while non-executing AI crawlers read only that half and never saw the runtime one. Neither file was wrong; nothing threw; nothing was logged. The split was invisible because each surface looked correct when inspected on its own, and the internal audit read raw HTML -- the same half the AI crawlers read, and the opposite half from the one Google stores.

The fix

Proved the direction of the failure before changing anything, by string-matching the search index against the source. Then collapsed the two definitions into one JSON file that both the build-time prerender script and the client-side page component read, so the two surfaces cannot drift again, with the commercial title as the surviving value. Deliberately excluded the audit API page from the change: its runtime title and description were the ones already ranking, so unifying it would have altered a page that was working. Scoped the edit to head identity only -- no markup changed, so nothing moved visually on the live page.

How I know it worked

Google's stored title for the portfolio page matched the client component character for character, not the prerendered file; the same held for the audit page against its own component, confirming the pattern was systemic rather than a one-off. The page was never deindexed -- it ranked fourth in a site query returning 131 indexed pages, and fifth for its own name query, behind the author's own social profiles. Absence from brand queries was host crowding, roughly two results per domain, not a defect. After deploy, checked against the served bytes rather than the commit: the live JavaScript bundle contained the new title once and the old title zero times. The untouched page was byte-identical except the build's own date stamp, its ranking title still present in the live bundle; the static SOP page and the homepage were unchanged; all six money pages returned 200.

The rule this earned

Decide which representation your most important consumer actually stores, and verify against that copy rather than the file you shipped. When a static build and a client-side application both set head identity, they are two sources of truth and the one that executes last silently wins -- so they must read one file. A noscript block is a fallback for absent JavaScript, not a channel to a crawler that runs it. And know which half of the audience your own checker reads: a raw-HTML scorer measures the non-executing consumers, which is a real audience and a real number, but it is not a verdict about a rendering one. A perfect score on content the primary reader discards is not a good result, it is an instrument answering a neighbouring question.

The named concepts behind it

Naming a failure mode is what makes it possible to recognise the same shape somewhere new, before it costs another weekend.

The render is the artifact

What a JavaScript-executing consumer stores is the DOM after execution, not the HTML you served. Anything that exists only before execution was never delivered.

This is one step past git is not the origin. There the receipt lied about what was being served. Here the serving is genuinely correct and current -- and still the consumer stores something else, because it transforms your bytes before reading them.

Modern search crawlers execute JavaScript. The thing that lands in the index is the DOM after that execution, not the file that came off the wire. Two consequences follow, and both are counter-intuitive because the served file looks perfect in curl and in the browser's View Source.

First, content that exists only in the pre-execution HTML is invisible.

Second, anything the application rewrites at runtime wins. If the page ships a carefully-chosen