All posts
SEOAI SearchGEO

JavaScript SEO for AI Crawlers: Why Client-Side Sites Get Ignored

JavaScript SEO for AI crawlers: Googlebot renders JS on a delay, most AI crawlers do not render at all. Why client-side sites get ignored and how SSR and prerendering fix it.

January 8, 20277 min read

JavaScript SEO is the practice of making sure search engines and AI crawlers can actually see content that your site renders with JavaScript. Here is the blunt version: Googlebot can render JavaScript, but it does so on a delay and imperfectly, and most AI crawlers do not render JavaScript at all. If your React, Vue, or Angular site ships an empty HTML shell and builds everything client-side, you are betting your entire visibility on the one crawler that renders, while every AI engine sees a blank page. That is why so many client-side-only single-page apps post threads like "my React site had almost zero Google impressions."

The fix is almost always to deliver real HTML content in the initial server response through server-side rendering, static generation, or prerendering. This is not optional for AI visibility in 2026. ChatGPT's crawlers, OAI-SearchBot, PerplexityBot, and others largely fetch HTML and parse it as-is. If your content is not in that HTML, it does not exist to them.

This post explains what renders, what does not, and how to fix a JavaScript site so both Googlebot and AI crawlers can read it. For the broader crawler landscape, see our AI crawlers guide.

What Actually Renders JavaScript

The rendering story differs sharply between traditional and AI crawlers, and this is the core misunderstanding.

Googlebot renders, eventually. Googlebot uses a two-wave process: it crawls the raw HTML first, then queues the page for rendering with a headless browser later. Rendering can be delayed, and complex or error-prone JavaScript can fail to render, leaving content unseen. Relying on it is fragile even for Google.

Most AI crawlers do not render at all. GPTBot, OAI-SearchBot, PerplexityBot, ClaudeBot, and similar agents generally fetch HTML and parse the response without executing JavaScript. If your content only appears after client-side hydration, these crawlers see the empty shell, and you are invisible to AI answer engines.

Grounding compounds the problem. When an AI engine grounds an answer in live search results, it often fetches your page directly. A client-rendered page returns no usable content, so even if you rank, you are not citable. See how AI search engines choose sources.

Why Client-Side-Only Sites Get Ignored

The empty-shell problem has a few concrete symptoms worth recognising.

The initial HTML is nearly empty. View source on a client-side-only SPA and you often see a near-empty body with a script bundle. That is exactly what a non-rendering crawler stores: nothing useful.

Indexing is delayed or partial. Even Googlebot's deferred rendering means content appears in the index late or inconsistently, which shows up as the "almost zero impressions" pattern for new SPA content.

Links and metadata are missing at fetch time. If internal links, titles, and meta tags are injected by JavaScript, crawlers that do not render miss your site structure and your descriptions, hurting both discovery and presentation.

AI engines never enter the picture. Without server-rendered content, you are not in the AI candidate set at all, regardless of how good the content is once it loads in a human's browser.

How to Fix a JavaScript Site

The goal is simple: put real content in the initial HTML response.

Server-side rendering (SSR). Frameworks like Next.js, Nuxt, and SvelteKit render pages on the server so the HTML response already contains the content. This is the most robust option for dynamic content that must be crawlable.

Static site generation (SSG) or prerendering. Pre-build pages to static HTML at build time, or prerender routes into static snapshots served to crawlers and users alike. For content that does not change per request, this is fast, cheap, and fully crawlable. This site, for instance, prerenders its public routes to static HTML for exactly this reason.

Hydration after content, not before. Ship the meaningful HTML first, then hydrate for interactivity. The crawler gets content immediately; the user gets a fast first paint plus interactivity once JavaScript loads.

Verify what crawlers actually see. Use Google Search Console's URL Inspection to view the rendered HTML, and fetch your own pages with JavaScript disabled to see what a non-rendering crawler gets. Then confirm AI engines can actually cite the page; a tool like bing.ly shows whether AI engines surface your content, which is the real test for client-rendered sites.

Common JavaScript SEO Mistakes That Hide Content

Even teams that adopt SSR or prerendering trip over a handful of recurring issues.

Hydration mismatches that blank the page. If the server-rendered HTML and the client render disagree, some frameworks throw away the server markup and re-render client-side, which can briefly or persistently leave a non-rendering crawler with nothing. Test the raw response, not the hydrated browser view.

Content loaded on interaction. Tabs, accordions, and "load more" patterns that fetch content only after a click hide that content from crawlers that never click. Render the important content into the initial HTML, even if it is visually collapsed.

Blocking critical resources in robots.txt. If you block the scripts or APIs Googlebot needs to render, its deferred render fails and it sees the empty shell. Allow the resources required for rendering.

Lazy-loading the primary content. Aggressive lazy-loading of main text or images can keep them out of the initial render. Reserve lazy-loading for below-the-fold media, not the core content you want crawled and cited.

Assuming Googlebot behaviour applies to AI crawlers. The biggest conceptual mistake. Even a perfectly rendering setup for Googlebot leaves you invisible to AI engines if the content is not in the raw HTML, because those crawlers do not render at all.

Frequently Asked Questions

Q: Can Googlebot read JavaScript content? Yes, but with caveats. It renders in a deferred second wave, rendering can be slow or fail on complex scripts, and relying on it leaves you exposed. Serving content in the initial HTML is far more reliable than trusting Googlebot to render correctly and on time.

Q: Do AI crawlers like GPTBot render JavaScript? Generally no. Most AI crawlers fetch and parse HTML without executing JavaScript. If your content only appears after client-side rendering, these crawlers see an empty page and cannot cite you, which is the single biggest reason SPAs are invisible to AI search.

Q: Is server-side rendering required for AI visibility? Effectively yes for content that matters. SSR, static generation, or prerendering ensures real content is in the HTML response that non-rendering crawlers read. Without it, you are betting solely on Googlebot's rendering and forfeiting AI engines entirely.

Q: How do I check what a crawler sees on my site? Use Search Console URL Inspection to see Google's rendered HTML, and load your page with JavaScript disabled to simulate a non-rendering crawler. If the body is empty, every non-rendering crawler and AI engine sees the same emptiness.

The Bottom Line

JavaScript SEO comes down to one rule: deliver real content in the initial HTML response. Googlebot renders JavaScript on a delay and imperfectly, and most AI crawlers do not render it at all, so a client-side-only site is invisible to AI answer engines and fragile even for Google. Use server-side rendering, static generation, or prerendering, ship content before hydration, and verify what crawlers and AI engines actually see. Do that and your JavaScript framework stops being a visibility liability.

Track your AI visibility with bing.ly

See how ChatGPT, Perplexity, Claude, and Gemini answer questions about your brand, and monitor community signals across Reddit, Hacker News, and more.

Get started free