Your page looks perfect to you. To an AI crawler that doesn’t run scripts, it can be a blank shell — and a blank shell never gets cited.
JavaScript breaks AEO because many AI crawlers do not execute it. When a page’s content is rendered client-side — assembled in the visitor’s browser by scripts rather than delivered complete in the HTML — a crawler that doesn’t run those scripts receives an empty or skeletal page. The content exists for human visitors and is invisible to the engine. You cannot be cited for content an engine never received.
This is one of the most common and most invisible AEO failures, because the page looks flawless to everyone who checks it the normal way. You open it in a browser, the browser runs the JavaScript, and the content appears. The crawler doesn’t run the JavaScript, so for the crawler, the content was never there. The gap between what you see and what the engine sees is the entire problem.
Running JavaScript is expensive. Rendering a page the way a browser does — executing scripts, waiting for content to assemble, handling all the ways it can go wrong — costs far more time and computation than simply reading the HTML that was delivered. At the scale answer engines operate, many of them economize by reading the raw HTML and moving on. If your content isn’t in that raw HTML, it isn’t in their picture of your page.
This sits at the very bottom of the structured data hierarchy — the access layer. It joins crawler permissions as one of the two ways a page can be perfectly built and still completely invisible. Schema, capsules, authority: none of it matters if the content that carries it never reaches the engine.
Check what the engine checks: the raw HTML. View the page source directly, or fetch the page without executing scripts, and look for your actual content — the headings, the paragraphs, the answers. If the main content is present in the raw HTML, you’re fine. If the raw HTML is mostly empty containers that the browser fills in later, your content is rendering client-side and an AI crawler likely can’t see it.
The fix is to deliver your content in the HTML rather than assemble it in the browser — through server-side rendering, static generation, or pre-rendering, depending on how the site is built. The principle is simple: the content an engine needs to read should be present without JavaScript. Interactivity can be layered on top — menus, animations, tools — but the core content must arrive complete. A well-built site treats content as the default and scripts as the enhancement, which is exactly the order an answer engine needs.
Because many AI crawlers don't execute JavaScript. If your content is rendered client-side — assembled in the browser rather than delivered in the HTML — the crawler sees an empty or skeletal page and has nothing to cite. The content is there for humans and invisible to the engine.
View your page's raw HTML source, or fetch it the way a simple crawler would, without running scripts. If the main content isn't present in that raw HTML, an AI crawler likely can't see it either. The fix is server-side rendering or static delivery of the content.
No. JavaScript is fine for interactivity layered on top of content that's already in the HTML. The rule is that the core content an engine needs to read must be present without JavaScript; scripts can enhance it, but shouldn't be required to render it.
We fetch your pages the way an AI crawler does — without running scripts — and show you exactly what content is reaching the engine and what's invisible.