**Most AI crawlers don't run JavaScript — so any content that only appears after JS executes is invisible to them.** This check compares your raw HTML against the fully-rendered page to see how much of your content is present before JavaScript runs. If your main text, headings or FAQ only exist client-side, ChatGPT, Perplexity and other AI engines can't read or cite them — making this the single most important GEO check.
It compares the page's raw HTML (what a non-JS crawler sees) against the fully-rendered DOM (what a browser shows after JS runs). Specifically:
- Content in raw HTML — whether your main text, headings and key elements are present before any JavaScript executes.
- JS dependency — how much of the visible content only appears after client-side rendering.
- Server-side rendering — whether the page is server-rendered (or pre-rendered) so content is delivered in the initial HTML.
Main content present in the raw HTML passes; some important content requiring JS is a warning; the body or key content being JS-only is a fail.
GEObubbly fetches the raw HTML and compares it against the rendered page to measure how much content depends on JavaScript. It's a core, scored Performance check (and a pivotal GEO signal) that runs partially, since assessing rendering requires comparing the served HTML with the executed result.
This is the check that ties performance to GEO most tightly. Google's crawler can render JavaScript, but it does so on a delay and not always completely — so client-rendered content is crawled later and less reliably. The AI crawlers behind ChatGPT, Perplexity, Claude and Google's AI features mostly don't run JavaScript at all. That means any content delivered only after JS executes — a body rendered by a single-page-app framework, an FAQ injected client-side, text loaded via fetch — is effectively invisible to the engines you most want to be cited by. The fix is server-side rendering (or static pre-rendering): deliver your main content, headings, structured data and FAQ in the initial HTML response, so it's there whether or not JavaScript runs. You can still use JavaScript for interactivity layered on top — the rule is that the content itself must exist in the served HTML. This principle is why every GEObubbly check-detail page is server-rendered, and it underpins both crawlability and citation.
Mostly no. The crawlers behind AI answer engines like ChatGPT, Perplexity and Claude generally fetch the raw HTML and don't run JavaScript, so any content that only appears after client-side JS executes is invisible to them. Google's traditional crawler can render JavaScript, but it does so on a delay and not always fully, so even for search, JS-only content is crawled later and less reliably. The safe approach is to make sure your important content exists in the HTML that's served before any JavaScript runs.
Server-side rendering (SSR) means the server sends a fully-formed HTML page with your content already in it, rather than sending a near-empty shell that JavaScript fills in on the user's device. It matters for GEO because AI crawlers read that initial HTML and generally don't execute JavaScript — so with SSR your text, headings, FAQ and structured data are visible and citable, whereas with client-side rendering they may not exist as far as the engine is concerned. Static pre-rendering achieves the same result for content that doesn't change per request.
View the page's raw HTML source (not the rendered DOM in dev tools) — for example, the "View Source" option or fetching the URL without running scripts — and check whether your main text, headings and FAQ are present in it. If the source is mostly an empty shell with a bundle of JavaScript and your content only appears once the page runs in a browser, it's client-rendered and at risk of being invisible to AI crawlers. If the content is right there in the served HTML, it's server-rendered (or pre-rendered) and readable without JS.
Yes — the goal isn't to avoid JavaScript, it's to make sure your content doesn't depend on it. Deliver the main content, headings, structured data and FAQ in the initial server-rendered HTML, then layer JavaScript on top for interactivity: menus, filters, animations, dynamic widgets. This is how modern frameworks' SSR and hydration work. Crawlers that don't run JS still get the full content from the HTML, while users with JavaScript get the enhanced, interactive version. Progressive enhancement like this keeps you fast, accessible and citable.
Because it's a gate: if your content isn't in the served HTML, none of your other GEO work — answer-first writing, question headings, structured data, FAQ schema — can help, since the engine never sees it. Getting cited by AI depends first on the engine being able to read your content at all, and most AI crawlers only read raw HTML. Server-rendering your content removes that gate and makes everything else you do for GEO actually count. That's why it's foundational and why it underpins the whole GEO-100 standard.