It can be indexed, but it is a risk, and the honest answer separates Google from AI tools, because they behave differently. Google is able to render JavaScript and index content that appears only after scripts run, but it does so in a slower, more fragile second pass, so anything that fails to render cleanly can be indexed late or not at all. AI tools are less forgiving: many AI crawlers fetch the raw HTML a server returns and do not execute JavaScript the way a full browser does, so content that only appears after client side rendering may simply be invisible to them. A site built so that its words exist only after JavaScript runs is betting that every reader runs JavaScript, and not all of them do. The safe approach is to deliver your real content in the HTML the server sends, through server side rendering or static generation, so both Google and AI tools see it without executing anything. WPBuildAI scans your site and returns the content as it is actually delivered, so you can see what lives in the HTML versus what only appears after scripts run.
Google’s crawlers and the AI crawlers are not the same population and do not behave alike: Cloudflare’s figures showed Google crawling roughly 5.4 pages per referred visit while OpenAI’s ratio was about 1,091 to 1 and Anthropic’s about 38,065 to 1, so rendering assumptions that hold for Googlebot do not automatically transfer.
What rendering actually means
To decide the risk, you need the distinction between source HTML and rendered HTML. When a browser requests a page, the server sends an initial HTML document. If your content is in that document, anyone who reads the document sees it. If your content is not there, and instead a script runs in the browser to fetch and insert it, then the content exists only after rendering. A human with a modern browser sees no difference, because their browser runs the script. A machine reading your page sees a very large difference, depending on whether it runs scripts. That single fork, content in the source versus content added by rendering, decides most of what follows.
How Google handles JavaScript
Google sits on the more capable end. It can execute JavaScript and index content that appears only after rendering, but not in one step. As the JavaScript SEO basics guidance describes, rendering happens in a separate, later phase than the initial crawl, and it can be delayed or fail if scripts are heavy, blocked, or throw errors. So JavaScript content is indexable, but less reliably and less promptly than content already in the HTML. The practical reading is that relying on client side rendering for important content trades reliability for convenience. It often works, and it sometimes does not, and the failures are quiet.
How AI tools handle JavaScript
AI tools sit on the less forgiving end, and this is the part people miss. Many AI and large language model crawlers, listed among the agents in references like the Google crawlers overview and their own published names, fetch the raw HTML and read what is there. They commonly do not run a full browser to execute your scripts. So if your content is injected by JavaScript after load, an AI crawler may receive an almost empty shell: a page with navigation and a loading state, but not the article, product details, or answer you wanted quoted. For AI visibility specifically, client side rendering is the riskier choice, because the reader you are courting may never run your code.
The safe answer: put content in the HTML
The robust solution removes the gamble. Deliver your real content in the HTML the server returns, so it is present before any script runs. Two common ways to do this are server side rendering, where the server builds the full HTML for each request, and static generation, where pages are built ahead of time as complete HTML files. Both mean that every reader, human, Google, or AI, receives the content directly, with no execution required. This is also why static and server rendered sites tend to be read so cleanly, a theme explored in is a static site better than WordPress. The goal is not to avoid JavaScript entirely, but to make sure your meaning does not depend on it.
JavaScript is fine for interaction, not for core content
It is worth being balanced: JavaScript is not the enemy. It is the right tool for interaction, such as menus, filters, carousels, and forms, where it enhances a page whose content already exists. The problem is only when JavaScript is responsible for the existence of the content itself. A good rule is that the page should make sense with scripts disabled: the words, the answer, the product information should all be there, and JavaScript should add behavior on top. Used that way, JavaScript improves the experience without hiding your meaning from any reader. Used to deliver the content itself, it becomes a single point of failure for indexing.
How to tell what a crawler sees
You cannot fix what you cannot see, so the diagnostic step is to compare the rendered page with the source HTML. View the page as a browser shows it, then look at the raw HTML the server returns, and note what is present in the second but not the first. Anything that appears only after rendering is content a non rendering crawler will miss. Web Almanac 2024 (HTTP Archive) documents how script heavy modern sites have become, so this gap is common and easy to underestimate. WPBuildAI scans your site and returns the delivered content, which makes the comparison concrete: you see exactly which of your words live in the HTML and which depend on JavaScript.
Steps to make a JavaScript site readable
- Compare the rendered page with the raw HTML the server returns.
- Identify content that appears only after scripts run.
- Move core content into the HTML via server side rendering or static generation.
- Keep JavaScript for interaction, not for delivering the content itself.
- Confirm the page makes sense with scripts disabled.
- Recheck after any rebuild, since a new framework can change how content is delivered.
Worked example: an AI builder front end that would not get cited
Imagine a site rebuilt on a modern JavaScript framework where the articles load through a script after the page shell appears. In a browser it looks perfect. But traffic from AI tools never mentions the content, and new articles are slow to appear in search. An inspection shows the raw HTML contains only a navigation bar and a loading placeholder; the article text is injected by JavaScript. Google eventually renders and indexes most of it, late, while AI crawlers that do not run scripts see the empty shell and quote nothing. The team switches the article pages to server side rendering, so the text now ships in the HTML. From then on both Google and AI tools read the content directly, and citation becomes possible. Nothing about the writing changed; only its delivery did.
Limitation: rendering well does not guarantee ranking or citation
It is fair to mark the boundary. Delivering content in the HTML makes your pages readable by Google and AI tools, but readability is the entry ticket, not the prize. A perfectly server rendered page with thin or unhelpful content still will not rank or earn citation, because being readable is necessary, not sufficient. So fixing rendering removes a blocker; it does not replace the work of being a complete, accurate, useful answer, which is the substance described in the generative engine optimization guide. Treat readable delivery as the foundation that lets your good content count, not as a ranking tactic on its own.
Common mistakes
- Assuming that because a page looks fine in a browser, every crawler sees it.
- Relying on client side rendering to deliver core content, not just interaction.
- Treating Google’s ability to render JavaScript as a guarantee it always will.
- Forgetting that many AI crawlers do not run JavaScript at all.
- Changing frameworks in a rebuild without rechecking what ships in the HTML.
Key points
A JavaScript site can be indexed, but it is a risk that differs by reader. Google can render JavaScript in a slower, more fragile second pass, so content can be indexed late or missed, while many AI crawlers do not run JavaScript at all and may see only an empty shell. The reliable answer is to deliver your real content in the HTML the server returns, through server side rendering or static generation, and to keep JavaScript for interaction rather than for the content itself. Confirm the page makes sense with scripts disabled, and recheck after any rebuild changes how content is delivered. For the headless and static angle, see can you make an existing WordPress site headless and, for how AI tools read sites, can Perplexity crawl a WordPress site. WPBuildAI scans your site and returns the content as it is actually delivered, so you can see what lives in the HTML versus what only appears after scripts run. Send your web address for a free analysis.
Not affiliated with WordPress, Lovable, Webflow, Shopify, Wix, or Squarespace.