JavaScript sites and AI search: why your React app scores low

JavaScript SEO for AI search means putting useful page content in the HTML that a crawler can fetch. That matters this year because buyers are increasingly getting answers from AI systems that may read a page once, rather than from a browser that renders every script fully.

The empty document

Start with the document your server actually sends, not the page you see after the browser finishes loading. A visitor can receive a complete product page while a crawler receives a shell with a root element and very little else.

A client-rendered app sends a basic HTML document first. JavaScript then requests data, builds the interface and inserts the words your visitor came to read. That is a sensible browser architecture. It is a poor handoff when the first document contains no product name, explanation, price or answer.

AI crawlers fetch HTML. They may not execute the scripts that turn an empty shell into a page. The result is a page with no usable content for that fetch.

A single-page application can look healthy in Chrome and still fail the first test that matters to an AI system: whether the page says anything before JavaScript runs.

Our readiness check for content present without JavaScript passed on 92 of 121 sites, warned on 9 and failed on 18. Those 18 sites failed the basic handoff. Their visible application may work for people, but the initial HTML did not carry enough of the page for the check to pass.

That result comes from a sample, not a law of nature. We measure the sites we check, print the sample size, and do not know what we have not measured. The free AI readiness check shows the check itself and the other signals we inspect.

An empty first document also makes every later improvement harder to use. A crawler has little to work with when a product name, answer or price arrives only after a request completes.

React itself isn't the problem. The problem is important content that only appears after a script runs.

The rendering choice

Server-side rendering puts page content into HTML before the response reaches the browser. The browser can still hydrate that page into an interactive React application, but the first document already contains the words, headings and links a crawler needs.

Prerendering takes a different route. You generate HTML ahead of time for routes that can be known in advance, then serve those files to visitors and crawlers. It works well for marketing pages, documentation, articles and other routes that do not need fresh output on every request.

The choice is about when your content becomes available.

Server rendering suits pages whose output depends on the request, account, location or current data. It adds work to the server and can add operational complexity. You need to handle caching, data fetching, errors and the boundary between server and browser code.

Prerendering keeps delivery simpler and can make public pages fast to serve. Its limit is freshness. If a price, stock state or account-specific result changes often, a generated page can become stale unless your publishing process rebuilds it or the page uses a separate, carefully controlled update path.

There is a reasonable objection to this argument: if search engines can execute JavaScript, perhaps AI crawlers will catch up, and rebuilding an app for them could be wasted work. That is possible in principle, but it is not a safe assumption for a page that needs to be found or cited now. Your buyer does not get extra credit for an architecture that requires a crawler to behave like a full browser.

The practical answer is to keep the application and change the first response. You can render the important public content on the server or generate it before delivery, then leave client-side code to handle interaction rather than basic legibility.

The useful test is simple: is the content present without JavaScript? It checks whether the content exists in the initial response, rather than whether the page eventually looks correct in a browser. Passing it does not guarantee a citation, but failing it gives a crawler a strong reason to skip the page.

The ledger for this post contains no quotable vendor rendering or SEO documentation. A vendor pull-quote is therefore omitted here rather than fabricated.

The surrounding signals

Rendering fixes access. It does not tell an AI system what your company is, who it serves or why one page should answer a buyer's question. Once the HTML is available, the page still needs a clear subject and useful facts.

The same audit found that the check for one clear H1 passed on 101 of 121 sites and failed on 18. Title and description say what it is passed on 92 and warned on 27. These are not substitutes for rendered content, but they help confirm what the page is about when a crawler reads it.

The bigger wording gap sits in the business statement. Only 20 of 121 sites passed the check for a plain statement of what it is, for whom, at what price, against what. The check failed on 43 and warned on 56. A page can be technically available and still make the model work too hard to identify the product.

That is why client-side rendering and page clarity belong in the same repair. Put the important statement in the server response. Make it specific enough to answer the first buyer question. Link to pricing or show the price where appropriate. Give comparison pages their own routes instead of hiding the relevant text behind controls.

The audit found that price visible or a pricing page linked passed on 90 of 121 sites. Comparison or alternatives pages passed on 54, failed on 21 and warned on 46. Questions answered on the page passed on 56 and warned on 63.

The weak results cluster around the material buyers use to choose, not around the parts of a site teams usually polish first.

Technical access has smaller but still real gaps. AI crawlers were allowed in robots.txt on 116 of 121 sites, while 5 failed. A sitemap was published on 100, with 21 warnings. Product or SoftwareApplication schema passed on 60 and failed on 59.

Schema supports interpretation of a readable page. A sitemap helps crawlers find routes, while robots.txt controls access. None of these signals supplies the product explanation when it is missing from the response.

You can use the free AI visibility checker after the rendering change to look for evidence in assistant answers. Keep that result separate from the readiness check. One asks whether your site is prepared to be read. The other asks what assistants actually mention or cite in the checks you run.

The repair plan

Start with a public route that matters to revenue. It could be a product page, a category page or a page answering a question your sales team hears often. Fetch its HTML with scripts disabled, or inspect the raw response, and look for the product name, purpose, audience, price context and main answer.

If those words are absent, choose server rendering or prerendering for that route. Use server rendering when the response must be current or request-specific. Use prerendering when the route is public, stable and easy to rebuild.

Then check the links inside the returned HTML. A crawler needs a path to related product pages, pricing, documentation and comparisons. Client-side navigation that appears only after hydration can leave those routes harder to discover, even when each route works after a person opens it.

Next, test the page at its least favourable moment. Disable JavaScript. Clear the data. Inspect the response before the browser has fetched anything else. If the page becomes a blank shell, the implementation has put too much of its meaning in the browser.

Do not stop at the homepage. The readiness audit found that 119 of 121 homepages answered a plain request, so a homepage can look fine while deeper routes remain unusable. Check the pages an assistant would need to cite, including product detail, pricing, comparison and buyer question pages.

Keep the fix narrow at first. You can render the public marketing surface on the server while leaving an authenticated dashboard client-rendered. You can also prerender the stable parts of a route and keep interactive account features behind the initial content. The point is to expose the evidence before interaction, not to ban JavaScript from the site.

After deployment, compare the raw HTML with the hydrated page. Confirm that the main heading, description, links and buyer answer survive without scripts. Then watch for regressions when a component changes, because a new data dependency can quietly move an important sentence back into client-only code.

Measurement still needs care. A readiness pass says the crawler can reach and read the page. It does not say an assistant will choose it, cite it or recommend the product. For that second question, track the prompts and pages in a defined sample, using our methodology so you know what the result covers.

The answer is to server-render or prerender the public content, while JavaScript handles the interaction that content does not need.

Frequently asked questions