AI crawlers handle JavaScript and what to render server-side

Your site ranks position one on Google. Search Console shows healthy impressions. Core Web Vitals are green. But ChatGPT has never cited you, Perplexity doesn't see you, and Claude can't read your product pages. The problem isn't your content or your authority. The problem is that a Vercel and MERJ analysis of more than 500 million GPTBot fetches found zero evidence of JavaScript execution .

As of June 2026, none of the major AI crawlers render JavaScript. This includes GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-SearchBot, PerplexityBot, Meta-ExternalAgent, and Bytespider . Only Googlebot renders JavaScript, using headless Chrome in a two-phase indexing system . That gap between what Google sees and what AI crawlers see is where citation invisibility starts.

The operational reality is this. If your content requires JavaScript to appear in a browser, AI crawlers fetch an empty shell and move on. GPTBot, ClaudeBot, and PerplexityBot do not execute JavaScript, do not wait for rendering, and do not make second attempts . They pull the raw HTML your server returns, extract text, and leave. When that HTML is a minimal container plus script tags, your entire site is blank to them.

I have run this diagnosis on audits for SMEs in Jakarta, Singapore, and Kuala Lumpur. The pattern shows up every time someone built on React or Vue without server-side rendering. Google visibility looks fine. AI visibility is zero. The founders assume it is an authority problem or a schema problem. It isn't. The AI crawler literally cannot read the page.

What AI crawlers actually see

The data indicates that while ChatGPT and Claude crawlers do fetch JavaScript files (ChatGPT 11.50%, Claude 23.84% of requests), they don't execute them . Downloading a file and running it are different operations. GPTBot downloads your React bundle. It does not run it. The product descriptions, pricing tables, FAQ sections, and testimonials that mount after hydration never make it to the crawler.

The test is simple. Open your critical pages in Chrome. Disable JavaScript in DevTools. Reload. What you see is what AI crawlers see . If the page shows a loading spinner, a blank content area, or navigation without body text, you have a rendering gap. View source, not the Elements panel. Elements shows the DOM after JavaScript runs. View source shows the raw HTML the server sent. AI crawlers see view source.

If your structured data, canonical tags, or meta descriptions are injected by JavaScript after the initial page load, AI crawlers never see them . Schema markup inserted client-side does not exist for GPTBot. An FAQ accordion that loads on click is invisible. A product spec table fetched from an API after mount is blank. This is not partial visibility. It is binary. The content is either in the initial HTML response or it is not readable by AI engines.

The one exception worth naming is Google Gemini. Google Gemini leverages Googlebot's Web Rendering Service infrastructure and can execute JavaScript with the same caveats around timing, resource blocking, and rendering queue delays that apply to Googlebot itself . That means Google AI Overviews might surface your client-rendered content. ChatGPT, Perplexity, and Claude will not.

What to render server-side and what can stay client-side

Not everything needs server-side rendering. The decision is simple. If the content defines what the page is about, it goes in the initial HTML. If it enhances interactivity or personalisation after the page loads, client-side is fine.

Server-side render this:

• Product names, descriptions, specifications, pricing
• Service descriptions, case study text, testimonials
• FAQ questions and answers
• Article body text, headlines, author bylines
• Breadcrumb navigation, category pages, filters
• Schema markup (JSON-LD), meta descriptions, canonical tags, Open Graph tags
• Any text you would expect to appear in an AI citation

Client-side render this:

• View counters, like buttons, share widgets
• Live chat popups, notification badges
• Interactive calculators, configurators that personalise based on user input
• Real-time inventory indicators, countdown timers
• Social media embeds, comment threads that load on scroll
• A/B test variants, behavioural targeting overlays

The line is whether the content is factual or interactive. Factual content about your product, service, or expertise must be in the HTML. Interactive UI that responds to user behaviour can load later.

Frameworks that support server-side rendering natively make this straightforward. Implement server-side rendering using a framework that supports it natively. Next.js for React, Nuxt for Vue, and Angular Universal for Angular all render critical content server-side before sending it to the client . The page arrives with full text already in the HTML. JavaScript hydrates interactivity after load. Crawlers see the content. Humans get the interactions.

If a full SSR migration is not feasible this quarter, pre-rendering is the fallback. Pre-rendering services generate static HTML snapshots of your SPA pages and serve them to crawlers while human visitors receive the dynamic JavaScript version. SSR is the stronger long-term solution, but pre-rendering works when a full SSR migration is not feasible . The trade-off is maintenance overhead. Snapshots need regeneration when content changes. SSR stays current automatically.

For WordPress or CMS-based sites where core content is already server-rendered but specific elements rely on JavaScript, replace those elements with HTML and CSS alternatives. Use `<details>` and `<summary>` for accordions. Static HTML tables for pricing. Visible sections with headings instead of tabbed content that hides information behind JavaScript clicks . A tabbed interface that shows all tabs with anchor links works for crawlers and humans. An accordion built with `<details>` renders the full text in view source but collapses visually for users.

After any fix, verify the same way. View source. Disable JavaScript. Check your server logs to confirm GPTBot is receiving HTML responses that match the byte size of your full content, not a 4KB shell. Schema markup (JSON-LD) is present in the HTML source , not inserted by a script.

The SME teams I work with in consultancy engagements usually discover this gap during an AI search audit. The site performs well in Google Search. Traffic is steady. But AI citation volume is zero or near-zero, and nobody knows why. Running a JavaScript-disabled test on the top 20 commercial intent pages surfaces the issue in five minutes. Half the content is missing. The product pages are shells. The FAQ is blank. Fixing it is a prioritisation decision, not a mystery.

With GPTBot traffic growing 305% year-over-year and AI bots now accounting for 4.2% of all HTML page requests , the gap between Google visibility and AI visibility translates directly into lost citation opportunities. Google's ability to render JavaScript is the exception, not the standard. The vast majority of crawlers consuming your content work without JavaScript rendering . If you want to be cited by ChatGPT, readable by Claude, and surfaced by Perplexity, your content must exist in the raw HTML the server sends.

The fix is technical but not complicated. Render factual content server-side. Let client-side JavaScript enhance interactivity. Test with JavaScript disabled. Verify in view source. The crawlers will tell you whether it worked.