Millions of websites built on React, Vue, Angular, and similar frameworks have a hidden AI SEO problem: their content is generated by JavaScript at runtime, and most AI crawlers never execute JavaScript. The result is that when GPTBot, ClaudeBot, or PerplexityBot visits these sites, they see blank shells — empty div tags, loading spinners, and a few script tags — rather than actual content. If your site was built with a modern JavaScript framework and you haven't addressed rendering, your content may be effectively invisible to every major AI system. This guide explains how AI crawlers handle JavaScript, how to audit your site's rendering status, and the specific solutions available for every framework and hosting environment.
The JavaScript Rendering Problem: Why AI Crawlers Miss Your Content
Modern single-page applications (SPAs) work like this: the server sends a minimal HTML file containing mostly JavaScript bundle references. The browser downloads and executes the JavaScript, which then fetches data from APIs and renders the actual page content into the DOM. From a user's perspective, this works seamlessly. From an AI crawler's perspective, this is catastrophic. GPTBot, ClaudeBot, and most other AI crawlers are HTTP clients — they make one request, receive the response, and process the HTML. They do not execute JavaScript. When they receive your SPA's initial HTML, it looks like: '<html><head>...</head><body><div id="root"></div><script src="bundle.js"></script></body></html>'. There is no content for the crawler to extract. Your entire site — every blog post, every product page, every resource article — is invisible to these systems. This is not a niche problem. Estimates suggest 40-60% of marketing websites have significant JavaScript rendering issues that would affect AI crawler content extraction.
- SPAs render content via JavaScript — AI crawlers that skip JS execution see blank pages
- React, Vue, Angular, and similar frameworks all produce SPA architecture by default
- AI crawlers receive initial HTML only — no subsequent API calls or DOM manipulation
- Even if 90% of your content is in JS, AI crawlers may extract 0% of it
- Google's crawler renders JS (slowly), but AI crawlers generally do not
- This affects ChatGPT, Perplexity, Claude, and Gemini citations simultaneously
How to Audit Your Site for JavaScript Rendering Issues
The fastest way to audit your site's rendering status is to view your pages without JavaScript. In Chrome DevTools: Settings → Debugger → Disable JavaScript. Visit your most important pages with JavaScript disabled. If you see blank pages, loading states, or minimal content, you have a JavaScript rendering problem. A more systematic approach: use curl to fetch your page and examine the raw HTML. Run 'curl -s https://yoursite.com/your-page | grep -c "<p"' to count paragraph tags in the raw HTML. If this returns 0 or a very low number for a content-rich page, your content is JavaScript-rendered. You can also use tools like Screaming Frog with JavaScript rendering disabled to audit your entire site at scale. Screaming Frog will report the word count and content it extracts without JS — compare this to the rendered version to quantify the gap. Google Search Console's URL Inspection tool shows you the rendered HTML as Googlebot sees it — while this uses Google's JS rendering (not typical of AI crawlers), it gives you a baseline understanding of your rendering architecture.
- Disable JavaScript in Chrome DevTools and browse your site — content should still appear
- Use curl to fetch page HTML and check for actual content in the response
- Run Screaming Frog with JS rendering disabled to audit at scale
- Compare raw HTML word count to rendered word count across key pages
- Use Google Search Console URL Inspection to see how crawlers experience your pages
- Check your framework's documentation to confirm its default rendering mode
Solutions: Server-Side Rendering and Static Site Generation
The definitive fix for JavaScript rendering issues is server-side rendering (SSR) or static site generation (SSG). With SSR, your server executes the JavaScript and returns fully-rendered HTML containing all content. With SSG, pages are pre-rendered at build time and served as static HTML files — even faster than SSR with no server computation at request time. Next.js (React) supports both: use 'getServerSideProps' for dynamic SSR or 'generateStaticParams' (previously 'getStaticPaths') for SSG. Nuxt.js (Vue) supports SSR natively with 'useFetch' or 'useAsyncData' on the server. SvelteKit renders server-side by default. Gatsby is a pure SSG framework. For teams that cannot migrate to a full SSR framework, Next.js offers Incremental Static Regeneration (ISR) — pages are statically generated and periodically regenerated from a CDN. This works well for blogs and marketing sites with content that changes infrequently. The key test after implementing SSR/SSG: curl your pages and verify that all substantive content appears in the raw HTML response, not just empty wrapper divs.
- SSR: server renders HTML on each request — content always in initial response
- SSG: pages pre-rendered at build time — fastest delivery, best for mostly-static content
- Next.js: use getServerSideProps (SSR) or generateStaticParams (SSG)
- Nuxt.js: SSR mode is default — ensure useFetch/useAsyncData runs server-side
- SvelteKit: server-side rendering is the default for all routes
- Gatsby: pure SSG — all pages rendered at build time
Dynamic Rendering: The Intermediate Solution for Complex SPAs
For complex enterprise SPAs that cannot be fully migrated to SSR without a multi-month engineering project, dynamic rendering provides an intermediate solution. Dynamic rendering serves pre-rendered HTML to bots and the normal SPA to human users, based on User-agent detection. Tools that implement dynamic rendering: Prerender.io (SaaS service, easiest to implement), Rendertron (Google's open-source rendering service), and custom implementations using Puppeteer or Playwright to pre-render pages. To implement dynamic rendering in Nginx: detect bot User-agents in the request headers and proxy those requests to your pre-rendering service instead of your SPA server. In Cloudflare Workers: inspect the User-agent and serve cached pre-rendered responses for known bot strings. The main caveat: dynamic rendering requires maintenance — your pre-rendering service must stay synchronized with your SPA's content. Also, pre-rendering may not handle highly dynamic content (real-time data, user-specific content) correctly. Use dynamic rendering as a bridge while planning a proper SSR migration.
- Dynamic rendering: serve pre-rendered HTML to bots, normal SPA to users
- Prerender.io: easiest SaaS implementation — integrates with most stacks
- Rendertron: Google's open-source option — self-hosted, more control
- Implement User-agent detection in Nginx, Cloudflare Workers, or your load balancer
- Cache pre-rendered snapshots — regenerate them when underlying content changes
- Document dynamic rendering in your architecture — it adds complexity to deployments
Framework-Specific Recommendations and Common Pitfalls
Even with SSR implemented, there are common pitfalls that leave content JavaScript-rendered in practice. In React/Next.js: watch for 'use client' directives on components that fetch and render substantive content — client-side components do not SSR their dynamic data. In Nuxt.js: ensure your API calls use server-side composables, not client-only 'onMounted' hooks. In Vue 3: watch for data fetching inside 'onMounted' lifecycle hooks — these execute only client-side and will produce empty content in SSR mode. A common pattern that causes issues: a content component that fetches from a headless CMS API client-side. The initial SSR response contains the component shell, but the content arrives via a subsequent client-side API call. AI crawlers see the shell. Fix: move the CMS API call to a server-side data fetching function in your framework (getServerSideProps in Next.js, server-side 'useFetch' in Nuxt). After any framework change, re-run your curl audit to verify content appears in initial HTML.
- Next.js: avoid 'use client' on content components — keep them server components
- Nuxt.js: use server-side useFetch, not client-side onMounted for content fetching
- Vue 3: data fetching in onMounted hooks is client-only — move to server context
- Headless CMS content must be fetched server-side in your SSR data layer
- Test after every framework update — Next.js major versions have changed SSR defaults
- Monitor rendered vs. raw HTML word counts in CI to catch rendering regressions
JavaScript rendering is one of the most impactful and most overlooked technical AI SEO issues. A site with brilliant content but a client-side rendering architecture has invested heavily in a library that only a small fraction of its potential audience can access. Fixing rendering is an engineering investment, but it is a one-time fix with permanent ROI: once your SSR is implemented and validated, every page you publish immediately becomes accessible to every AI crawler. Audit your rendering status this week using the curl test, quantify the content gap, and build the remediation into your next engineering sprint.
Frequently Asked Questions
Does Perplexity AI execute JavaScript when it crawls pages?
Perplexity has invested in a rendering pipeline that can handle some JavaScript, but it is less comprehensive than a full browser rendering environment. For reliable Perplexity indexing, server-side rendering remains the gold standard. Content in the initial HTML payload will always be extracted; content loaded via client-side JavaScript is inconsistent. When in doubt, test by curling your page with Perplexity's User-agent string and verifying content appears.
We use a headless CMS (Contentful, Sanity, etc.) — does this cause rendering problems?
Not inherently, but the rendering problem often originates from how the CMS content is fetched. If your frontend fetches from the CMS API client-side (in browser), you have a rendering problem. If your SSR framework fetches from the CMS API server-side (during SSR data fetching), the rendered HTML will contain the content. Review your framework's data fetching documentation and ensure all CMS content is retrieved server-side.
Will fixing JavaScript rendering affect my Google Search rankings?
Almost certainly positively. While Googlebot renders JavaScript, it does so slowly in a deferred queue. Pages that provide fully-rendered HTML in the initial response are processed faster and more accurately. Googlebot's JavaScript rendering can also miss dynamically-loaded content. SSR implementation typically results in improved Google indexing completeness and can positively influence rankings for content that was previously only partially indexed.