SourceCited / Rendering & crawlability
Technical · Rendering
Most AI crawlers don't execute JavaScript. If your content is client-side rendered, they see an empty shell — test it in 30 seconds, then fix it with SSR or static HTML.
AI retrieval crawlers (GPTBot, ClaudeBot, PerplexityBot) do not run JavaScript — a Vercel/MERJ study of 500M+ GPTBot fetches found zero JS execution. So client-side-rendered content is invisible to AI answers no matter how good it is. Test it with View Source or curl; fix it with server-side rendering or static generation so your words are in the first HTML response.
Most AI crawlers do not run JavaScript. They fetch your HTML, read what is in it, and leave — so if your content is painted into the page by a client-side framework after load, the crawler sees an empty shell. A joint Vercel/MERJ analysis of over half a billion GPTBot fetches found zero evidence of JavaScript execution; ClaudeBot, PerplexityBot and the other retrieval bots behave the same way. This is the single most catastrophic and most common GEO failure: a beautiful React site that ranks fine for Googlebot (which does render) can be completely invisible to the AI engines — every other tactic on this site is wasted if the bot never sees your words.
A client-side SPA with no server rendering. View-source shows a near-empty <div id="root"></div> and a bundle of JS. Googlebot fills it in; GPTBot and ClaudeBot see nothing. You are invisible to AI answers and will not know why.
You do not need tooling to check this. Two ways, either one is decisive:
curl -s https://yoursite.com/page | grep "a sentence from the page". No match means the text is injected by JavaScript and retrieval bots miss it.I'll paste two things: (1) my page's raw HTML from View Source / curl, and (2) the visible text I see in the browser. Tell me which visible content is MISSING from the raw HTML — that's the content AI crawlers can't see. For each gap, say whether it's the main body, navigation, structured data, or metadata, and rank the fixes by how much citation-visibility they'd recover.
The fix is to ship real HTML on first response. Which route depends on your stack:
| If you run… | Do this |
|---|---|
| A static site (HTML, Hugo, Eleventy, Astro) | You are already fine — content is in the HTML. This is why static site generators are quietly ideal for GEO. |
| Next.js / Nuxt / SvelteKit | Use SSR or static generation (SSG/ISR) for content pages, not client-only rendering. Ship the words in the initial HTML. |
| A React/Vue/Angular SPA | Add server-side rendering or pre-rendering (a prerender service, or a static export of key pages). At minimum, pre-render your money pages. |
| WordPress / classic CMS | Usually fine — it renders server-side. Watch for JS-only content injected by plugins or page builders. |
| Content behind tabs / accordions / “load more” | Keep it in the DOM on load (CSS-hide is fine); do not fetch it on click. A bot never clicks. |
If you are choosing a stack for a content or tools site whose whole point is getting cited, a static generator is the safest choice: the content is in the HTML by definition, it is fast (great TTFB and Core Web Vitals), and there is nothing for a non-rendering bot to miss. This site is built exactly that way.
Being readable is not enough — you have to be readable fast. AI retrieval works on short timeouts, and the priorities are not the ones classic Core Web Vitals trains you to chase. A non-rendering bot never paints your page, so LCP and CLS barely matter to it; what matters is time to first byte and how quickly the HTML arrives. A page that scores well on visual metrics but answers slowly is still a page that gets skipped.
Three distinct ways slowness costs you citations:
| Where it bites | What happens |
|---|---|
| Live retrieval | Engines like Perplexity and ChatGPT search fetch pages while composing the answer. If you do not respond in time, the answer is written without you — there is no second chance. |
| Crawl budget | Slow servers get fewer pages crawled per visit, so new and updated pages are discovered later. |
| Agentic browsing | Agents acting on your pages compound every delay across multiple steps; slow flows get abandoned. |
1. TTFB — caching, a CDN, and real server response time. This is the number that decides whether a bot waits for you. 2. HTML payload — ship the content, not megabytes of inline bloat. 3. Visual metrics (LCP, INP, CLS) — still worth fixing for humans and for classic ranking, and CLS matters for agents clicking moving targets, but they are not what gets you fetched. Static hosting and a CDN solve most of this by default.
You can measure the first two right now: the checker reports how long your server took to answer and how large the HTML was when it fetches a live URL.
Rendering is the big one, but the same principle — is it in the first HTML response? — covers a few more traps:
| Trap | Why it hides content |
|---|---|
| Lazy-loaded body text / infinite scroll | Text fetched as you scroll is not in the initial HTML; keep primary content in the first response |
| Facts only in images | Non-rendering bots do not OCR — prices, specs, and key numbers must be HTML text |
| Important content in iframes | Often not attributed to your page; inline it instead |
| Cookie/consent walls that blank the DOM | If the wall replaces content server-side, the bot gets the wall; gate politely, do not blank the page |
| Soft 404s (HTTP 200 on a “not found” page) | Wastes crawl budget and pollutes the index — return real status codes |
Overwhelmingly no. Retrieval bots like GPTBot, ClaudeBot, and PerplexityBot fetch raw HTML and don't run client-side JavaScript — a Vercel/MERJ analysis of over 500 million GPTBot fetches found zero JS execution. Googlebot does render, which is why a site can rank in classic Google yet be invisible to AI answers.
View the page source (Ctrl/Cmd+U) or curl the URL, then search for a sentence you can see on the page. If the text isn't in the raw HTML, it's injected by JavaScript and AI crawlers can't see it. Disabling JavaScript in DevTools and reloading shows roughly what a non-rendering bot gets.
Ship real HTML on first response: server-side rendering (SSR), static generation (SSG/ISR), or pre-rendering your key pages. Static site generators avoid the problem entirely because the content is in the HTML by definition.
Yes, but different metrics than you'd expect. AI crawlers fetch on short timeouts and live-retrieval engines like Perplexity and ChatGPT search fetch pages while composing an answer — respond too slowly and the answer is written without you. Because non-rendering bots never paint the page, time to first byte and HTML size matter far more to them than LCP or CLS. Fix TTFB first, then payload, then the visual metrics.
For a content or tools site whose goal is citations, yes — static HTML is guaranteed visible to non-rendering bots, loads fast, and has nothing for a crawler to miss. It's a quietly ideal default for GEO.