Question 1

Are React single-page apps visible to ChatGPT and Perplexity crawlers?

Accepted Answer

By default, most React single-page apps are partially or entirely invisible to AI search crawlers. GPTBot (OpenAI), ClaudeBot (Anthropic), and PerplexityBot do not execute JavaScript when crawling content. A React SPA that renders its content client-side via JavaScript delivers an essentially empty HTML shell to these crawlers — typically a root div with no readable text content, no headings, and no structured data. The crawler logs a visit, captures the empty shell, and moves on. Your content never enters the training corpus or the retrieval index. This is the single most common technical AEO failure mode in 2026, affecting millions of React applications built during the 2018-2023 era when Google's Googlebot reliably rendered JavaScript and teams stopped worrying about server-side rendering as a baseline requirement. To check whether your React app is affected, fetch your homepage with curl (which cannot execute JavaScript) and compare the output to what a browser renders. If the curl output contains only a script tag and an empty div, your site is invisible to AI crawlers.

Question 2

What is the best way to audit a React app for AI search crawler visibility?

Accepted Answer

The fastest React SPA AI crawler audit uses four tools in sequence. First, run curl -s https://yourdomain.com | grep -c '

' to count visible paragraph tags in the raw HTML response. A well-rendered page should return 10 or more; a React SPA typically returns zero. Second, use Google's Rich Results Test or the URL Inspection tool in Search Console to see what Googlebot sees — this is a rendered view, but it reveals JavaScript-dependent content. Third, use the Screaming Frog SEO Spider with JavaScript rendering disabled to simulate AI crawler behavior across your full site and flag pages that lose more than 70% of their word count without JS execution. Fourth, use a dedicated AI crawler simulation tool — Ahrefs' Site Audit with JS disabled, Sitebulb, or the open-source tool crawlee — to generate a per-URL word-count comparison between rendered and non-rendered states. Pages with a rendered-to-raw word count ratio above 5:1 are your highest-priority fixes. This audit typically takes one to two hours on a small site and reveals the full scope of the visibility gap before you commit to any migration effort.

Question 3

How do you add SSR to an existing React SPA for AI crawler compatibility?

Accepted Answer

Adding SSR to an existing React SPA follows one of three paths depending on your starting architecture. The fastest path for a Create React App codebase is to migrate to Next.js, which provides SSR out of the box with minimal component changes — most functional components and hooks work without modification, and the migration is page-by-page rather than all at once. Expect four to eight weeks for a medium-size CRA app. The second path is Vite with server rendering using vite-plugin-ssr or the newer Vinxi framework, which keeps your Vite toolchain and adds a thin SSR layer; this is faster if you cannot change build tooling but requires more manual configuration. The third path is pre-rendering with tools like react-snap or Netlify's prerendering feature, which crawls your app and saves static HTML snapshots — this is the lowest engineering effort but only works for sites with limited dynamic content and does not handle personalized or data-driven pages. For most SaaS and marketing sites, Next.js migration delivers the best AEO outcome with the most predictable timeline.

Question 4

What is the difference between Next.js ISR and SSR for AI search visibility?

Accepted Answer

Next.js ISR (Incremental Static Regeneration) and SSR (Server-Side Rendering) both produce HTML-first responses that AI crawlers can read, but they serve different use cases and have different freshness trade-offs that matter for AEO. SSR generates HTML on every request — the crawler always gets the current content, which is ideal for frequently updated pages like pricing, availability data, or changelog entries. ISR generates HTML at build time and then regenerates it on a configurable schedule (every 60 seconds, every hour, every day) — the crawler gets a snapshot of the content as of the last regeneration, which is slightly stale but nearly always acceptable for marketing and content pages. For AEO purposes, ISR is usually the right choice for blog posts, product pages, and documentation because it provides the HTML-first response AI crawlers need without the server cost of generating HTML on every crawl visit. SSR is the right choice for pages where freshness is load-bearing — pricing pages, availability calendars, or any page that shows data that changes faster than your ISR revalidation window. The critical point for AEO is that both deliver the HTML-first response; the choice between them is a performance and cost optimization, not a crawlability decision.

Question 5

Can you improve AI crawler visibility for a React SPA without a full migration to Next.js?

Accepted Answer

Yes, there are three meaningful improvements available without a full migration. First, implement a pre-rendering service using a headless Chrome instance (via Rendertron, Prerender.io, or a self-hosted Puppeteer setup) that detects AI crawler user agents from their specific strings — GPTBot, ClaudeBot, PerplexityBot, anthropic-ai — and serves pre-rendered HTML snapshots to those bots while serving the JavaScript SPA to human browsers. This is sometimes called dynamic rendering and it is explicitly permitted by Google's guidelines as long as you serve equivalent content to both audiences. Second, convert your highest-value pages — homepage, pricing, key feature pages, and your top 20 blog posts — to static HTML files that bypass the SPA entirely. Many marketing teams do this as a stopgap while the full SSR migration is planned. Third, add a server-side metadata endpoint that serves Open Graph tags, JSON-LD structured data, and a text summary of each page's content based on the URL pattern, allowing crawlers to at least capture your entity signals and schema even if the full text is unavailable. None of these substitutes for proper SSR or SSG, but collectively they can recover 40-60% of the AI citation gap at a fraction of the migration cost.