Can ChatGPT read my website if it's built with React?

ChatGPT can read a React site when the content is in the HTML the server returns. It can't read content that only exists after JavaScript runs in a browser.

That distinction is about how the page is rendered, not which framework built it. A React app using client-side rendering sends a near-empty HTML file plus a JavaScript bundle. A browser runs the bundle and builds the page. OpenAI's crawlers (GPTBot, OAI-SearchBot and ChatGPT-User) receive the same empty file and stop there.

A React app using server-side rendering or static generation sends finished HTML. The crawler reads it like any other page.

What it means: if your pricing, product names or positioning only appear after hydration, ChatGPT search has nothing of yours to retrieve for those facts. The next move is to check which of your pages fall into that group.

The main source is Vercel's study of AI crawler traffic, published December 2024 and updated February 2025. Vercel found that ChatGPT and Claude crawlers do fetch JavaScript files (11.50% and 23.84% of their requests respectively), but "they don't execute them. They can't read client-side rendered content." Our summary of Vercel's AI crawler study covers the method.

Independent re-testing in June 2026 found the same for GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-SearchBot, PerplexityBot, Meta-ExternalAgent and Bytespider. Among tested crawlers, Googlebot and AppleBot are the ones that render JavaScript.

Three caveats worth knowing:

• Vercel's data is a one-month snapshot from nextjs.org, a sample skewed toward Next.js sites.
• Microsoft Copilot was excluded because it has no unique user agent.
• Vercel sells server-rendered hosting, so it has a commercial interest in the finding. The result has replicated independently anyway.

Crawler behavior changes. Treat this as the state of things as of October 2026 and recheck when vendors update their documentation.

The test compares what a crawler gets with what a person sees. Our raw HTML vs rendered DOM check walks through it in full. The short version:

1. Pick your load-bearing pages: pricing, product, about, and your main category pages.
2. List the facts on each that you'd want an AI answer to quote (a price, a plan name, a one-line description).
3. Fetch the raw HTML with no JavaScript execution and search it for those facts.
4. Load the same page in a browser and compare.

From a terminal, the raw fetch looks like this (hypothetical URL and price):

curl -s https://example.com/pricing | grep -i "49"

If the browser shows your $49 plan and the raw HTML doesn't, crawlers that don't render can't see it. Browser "view source" (not the inspector, which shows the rendered DOM) gives the same answer without a terminal.

Also check content behind tabs, accordions and "load more" buttons that fetch text after the page loads. It fails the same way.

Put the facts that matter into the initial HTML response. There are three common ways to do it in a React stack:

• Server-side rendering (SSR): the server builds the HTML on each request. Frameworks like Next.js and Remix do this.
• Static generation: pages are built to HTML at deploy time. Good for pages that change rarely.
• Prerendering: a build step or service renders client-side pages to static HTML.

The trade-offs are laid out in our comparison of client-side vs server-side rendering for AI crawlers. You don't have to convert the whole app. Start with the pages that carry facts buyers ask about, then expand. The SSR and prerendering rollout plan orders that work.

Two details matter. Vercel notes that data embedded in the initial HTML response (such as a React Server Components payload) may still be indexed, while components loaded later are not. And every visitor, human or bot, should get the same content. Serving crawlers different content from users is cloaking, which is a manipulation risk, not a fix.

Rendering is an access fix. It decides whether your content exists for the crawler at all. It doesn't make an engine more likely to pick your page over others, and nobody can promise it will. See whether SSR increases AI citations for what the evidence does and doesn't support.

Rendering is also one of several gates. A readable page can still be missed if:

• your robots.txt blocks OAI-SearchBot, the bot OpenAI uses for ChatGPT search (GPTBot only governs training, and OpenAI says each setting is independent);
• your firewall or CDN returns 403 to crawlers that robots.txt allows;
• the answer is generated without web search, from what the model learned before its knowledge cutoff. No site change reaches that this quarter.

On Google the picture differs. Googlebot renders JavaScript, and Google says AI Overviews and AI Mode need a page to be indexed and eligible for a snippet, with no extra requirements. Our page on whether AI Overviews need server-side rendering covers that case.

Does using Next.js solve the problem automatically? Not automatically. Next.js supports server rendering and static generation, but individual components can still render on the client. A page built with Next.js can ship its pricing table only after hydration. Run the raw HTML test on each important page rather than assuming the framework handled it. The framework gives you the option. Your configuration decides whether the content lands in the initial HTML.

Does ChatGPT run JavaScript when a user pastes my link? ChatGPT-User handles user-initiated fetches, and the June 2026 re-testing found it does not render JavaScript either. So a user pasting a client-rendered page into ChatGPT can get an answer built from the empty shell. OpenAI also states that robots.txt rules may not apply to ChatGPT-User, because a person triggered the request. Server-rendered content avoids both issues for that path.

Is client-side rendering a problem for Google AI Overviews? Less so. Googlebot renders JavaScript, so Google can usually see client-rendered content. Google says a page must be indexed and eligible for a snippet to appear as a supporting link in AI Overviews or AI Mode, with no additional technical requirements. Rendering in the browser still adds a step that can fail, so server-rendered HTML remains the safer default across engines.

Will adding schema markup help crawlers read a client-rendered page? No. If the markup is injected by JavaScript, non-rendering crawlers can't see it either. And schema isn't an AI visibility lever: Google says structured data isn't required for generative AI search, and an Ahrefs matched-control study found AI Overview citations fell 4.6% after pages added it. Fix rendering for the visible content first.

Is serving prerendered HTML only to bots allowed? Serving bots a prerendered copy of the same content users see is a technical workaround. Serving bots different content, such as extra claims, hidden text or instructions aimed at AI models, is cloaking. That kind of manipulation is illegitimate and risky. The simplest safe path is server rendering or static generation, so every visitor gets identical HTML.