The received wisdom — and I held it too — was that Gemini renders JavaScript because it is Google, and for once the folklore had authoritative backing.

In an interview with Kenichi Suzuki of Faber Company, Google's Martin Splitt confirmed it on the record: the crawler behind Gemini renders too, because the Web Rendering Service is a shared service that, in his words, "Googlebot uses… and Gemini uses… as well."

The same WRS that paints pages for Search feeds Gemini.

There was empirical support to match: when searchVIU ran a controlled schema-and-rendering study in October 2025, Gemini was the only system that extracted a price injected purely by JavaScript at live fetch. The capability is real, Google has stated it plainly, and I had no reason to doubt it.

Then Andre Alpar and his team did the thing the rest of us had not: they built a trap and pasted links into twelve assistants by hand. The design is worth understanding, because its cleanliness is the point:

• Each assistant received its own secret, never-linked URL, so every server hit could be attributed to exactly one system.

• In the raw HTML, the visible "internal reference number" was a decoy — a fake value sitting in the source for any reader that only reads text.

• A single line of external JavaScript replaced it with the real number, and — this is the elegant part — the real value existed nowhere in the HTML and nowhere in the script's own source.

• To obtain it, a reader had to execute the code, which called a second endpoint that returned the real value.

A hit on that endpoint in the log is therefore hard proof of execution; there is no way to reach that value by reading files as text.

Every page also carried a unique canary string returned only on a genuine fetch, so a real read could be told apart from a confident hallucination.

The prompt was identical every time: summarize the page and report the internal reference number.

The entire US top tier reported the decoy. ChatGPT, Claude, Gemini, Perplexity, Meta AI, Microsoft Copilot, and Grok... every one of them answered from raw HTML. Gemini included.

The only systems that reported the real, JavaScript-only number were the four Chinese assistants and Mistral. A clean geographic split that nobody on the team predicted, and that appears in none of the vendor documentation.

So how can Splitt be right that Gemini renders, and Alpar be right that it did not?

Both are true, because they describe two different pipelines, and the contradiction dissolves the moment you stop conflating them.

Read Splitt's words precisely and the tell is in the timing: the render he describes happens after Googlebot crawls a page, on the way into an index, and completes within minutes. That is the corpus-building lane.

Gemini then grounds its answers on content that was already rendered, days earlier, by someone else's crawl.

Alpar tested something else entirely: a cold, live fetch of a brand-new URL that no crawler had ever seen, with the real value reachable only by executing the script in that moment. He deliberately removed the pre-rendered corpus as a shortcut, and on that path, Gemini read the shell.

The two events sit in different columns:

The real variable, then, is not "does Gemini render JavaScript?"

It is "can this content reach Gemini through the pre-rendered index, or only through a cold live fetch?"

If Googlebot has already crawled and rendered your page, Gemini can read that version and appear to render; when in fact it inherited a render it never performed.

If the content lives only behind a live fetch — a fresh URL, a page Google deprioritized and never rendered, anything that surfaces only after interaction — it falls back to raw HTML.

That also resolves the searchVIU result: its test page was discoverable, so Gemini could have answered from the corpus render rather than a live one.

Alpar's endpoint-gated canary is simply the stricter instrument, because it removes the index as a confound.

One correction while we are here, because the headline version of Splitt's quote travels badly. "Google-Extended renders JavaScript" is loose: Google-Extended is a robots.txt control token, not a crawler, and it renders nothing.

Googlebot and WRS do the rendering; Google-Extended is only the switch that decides whether that rendered content may be reused for Gemini, which keeps the rendering firmly in the index lane, exactly where the reconciliation puts it.

The industry, me included, collapsed those two lanes into one confident sentence — "Gemini renders because it's Google" — and the sentence was half-right in precisely the way that costs you visibility.

Two secondary lessons from that test are worth more than the headline.

1. Self-reports are worthless as evidence. Perplexity told the chat window it could not access the page while its own crawler had already fetched that exact URL and received a 200. Believe the assistant's account of its own behavior and you draw the opposite conclusion. The chatbot's description of what it did is a sign; the server log is the referent. When those two disagree — and they do — you trust the log.

2. The pipeline and the answer are different questions. Grok actually executed the JavaScript on one node of its proxy swarm; the follow-up endpoint fired in the log. And Grok still answered from the decoy. The machinery ran the script and the model ignored what it found. "Did a crawler touch my page" and "did the answer use what the crawler found" are not the same interrogation and conflating them will mislead you in both directions.

This is precisely why we must include a Breach Diagnostic analysis in any serious AI-crawlability audit: you do not ask a system what it can see, you construct a page whose two versions disagree and watch which one it reports back.

Alpar's decoy is a Breach Diagnostic run in public, at scale, on twelve subjects. Anyone auditing a client site can run a smaller version on their own domain tomorrow and should.