ANSWERS

Do AI crawlers execute JavaScript?

It depends on the system. Training crawlers, search indexing, live fetching, and browser automation behave differently: some fetchers rely on the initial HTML, Googlebot renders JavaScript for Google Search including AI features, and browser agents can interact with rendered pages. Content that appears only after scripts run may be missed by non-rendering fetchers. ye5's GEO Web audit diagnoses site access and readability.

Which systems render JavaScript and which don't?

Four behaviors sit behind the question, and they differ. Training crawlers such as ClaudeBot and GPTBot collect content that may be used for future model training. Search indexing is separate: Googlebot renders JavaScript for Google Search, including AI features. Live user-triggered fetching happens when a system pulls a page during a conversation, and retrieval does not always fetch live. Browser automation agents drive a real browser and can interact with rendered pages.

What content becomes invisible to them?

Content that exists only after a script runs may be missed by a fetcher that does not render JavaScript. Common patterns include:

—Text injected by a JavaScript framework after the page's initial load — common in React, Vue, and Angular single-page apps.
—Prices, specs, or reviews pulled from an API call and written into the page in the browser.
—Navigation menus, tabs, or accordions built entirely in the browser, not in the HTML response.
—Content that loads only after a scroll or a click — infinite scroll, a "load more" button, a lazy-loaded image gallery.

None of it is present in the initial HTML response. A page can look finished in a browser, and a non-rendering fetcher may still miss what the scripts add. This is the pattern behind the most common blocker (see: What blocks AI crawlers most often?).

How do you make JavaScript content visible to crawlers?

Server-side rendering and static pre-rendering both solve this the same way. Each sends a crawler a full HTML page instead of an empty shell plus a script. Server-side rendering builds the HTML on your server for each request. Static pre-rendering builds it once, at deploy time, and serves the same file to each visitor, human or bot. Either approach works; the right choice depends on how often the content changes. Put important content in the initial HTML, and test the behavior of each system you care about rather than assuming it.

The fix is usually a handful of templates, not a site-wide rewrite (see: How do I make my website readable to AI crawlers?). ye5's GEO Web audit finds which templates deliver content only after a script runs, and diagnoses website access and readability.

FAQ

Does every AI system read a page the same way?

No, it varies by system. Some fetchers work from the initial HTML response, Googlebot renders JavaScript for Google Search including AI features, and browser agents can interact with rendered pages. Put important content in the initial HTML, then test the specific systems you care about.

Is a JavaScript framework the problem by itself?

No. The framework is not the problem. The problem is when it renders key content only in the browser, after the initial HTML loads. A React or Vue site that pre-renders or server-renders its output sends crawlers the same full page a person sees.

Is this the same issue as slow page speed?

No. Speed affects whether a crawler keeps reading a page. Rendering affects whether the content exists in the response. A non-rendering fetcher may miss content that appears only after scripts run, however fast the page is.