AI search cannot see your JavaScript
Google renders JavaScript. The crawlers behind ChatGPT, Claude and Perplexity mostly do not. If your content arrives in the browser rather than in the HTML, you are invisible to the fastest growing part of search.

There is a fifteen year old argument in web development about whether search engines run JavaScript. It was settled some time ago: Google does. It renders pages, waits for the client side to finish, and indexes what it finds.
That settlement is now out of date, because Google is no longer the only thing reading your site.
The crawlers that skip the browser
The crawlers feeding AI answers, GPTBot and OAI-SearchBot for ChatGPT, ClaudeBot, PerplexityBot, are fetchers rather than browsers. They request the document and read what comes back. They are not running a rendering engine and waiting for your framework to hydrate.
So the question is no longer whether search engines run JavaScript. It is what your page contains before any JavaScript runs at all.
How to see what they see
Turn JavaScript off in your browser and reload. Or from a terminal:
curl -s https://yoursite.com | wc -w
That word count is roughly what an AI crawler has to work with. If a page renders four hundred words to a human and returns forty in the raw HTML, the other three hundred and sixty do not exist as far as those systems are concerned.
The free site check on this site reports this number for any address, which is quicker than remembering the flag to disable JavaScript.
Why this happens to good sites
It is almost never a mistake. It is a default.
A single page application ships an empty div and fills it in the browser. That was a reasonable trade when the only reader that mattered rendered JavaScript. Client side data fetching does the same thing at a smaller scale: the layout arrives, then a request goes out, then the content appears. To a person that is a brief flash of a loading state. To a fetcher it is a page with no content on it.
Content behind an accordion, a tab, or a "read more" toggle usually is in the HTML, so that is generally fine. Content behind a fetch is not.
What to do about it
Render on the server. In practice that means server components, static generation, or plain server side rendering, and the choice matters less than the outcome: the words are in the response.
You do not need to move everything. The interactive parts of a page can stay client side. What has to be in the HTML is the part you would want quoted: the definitions, the specifics, the answer to the question the page exists to answer.
The part people get backwards
This is often filed under AI optimisation, as though it were a new discipline with its own tricks. It is not. Delivering your content in the document is the oldest advice in the field, and it was true when the only concern was a slow connection.
What has changed is the cost of ignoring it. When Google rendered your page anyway, client side content was a performance problem. Now it is an exclusion from a growing share of how people find things, and that share is not going back down. This is the specific gap our AI search visibility work closes: making sure the pages an assistant fetches contain what a person actually sees.
Tell us what needs building
Describe the problem, the system you have today, and the date it needs to be live. We reply with a written scope and a fixed price.