The Short Version
Most AI crawlers do not run JavaScript. They request the HTML and read what is in it. If your main content is injected on the client, those agents see a page with a header, a nav and nothing to quote.
This is the most common invisible cause of never being cited, and it is invisible precisely because the page looks perfect in your browser.
Why AI Crawlers Differ From Googlebot
Google renders JavaScript at scale, because it has spent two decades building the infrastructure to do it. That capability is expensive and most AI crawler operators have not replicated it.
So the mental model many teams carry, that a crawler will eventually render the page, is true for Google and false for most of the agents that decide whether you appear in an AI answer. Ranking in Google and being quoted by an assistant now have different technical prerequisites.
How to Test What a Crawler Receives
Fetch the page without a browser
Request the URL the way a crawler does and capture the raw response. No rendering, no JavaScript, no waiting.
Search that response for a sentence from your article
Pick a distinctive line from the middle of the page. If it is not in the raw HTML, it does not exist for any agent that does not render.
Repeat for a page type, not just the homepage
Homepages are frequently server rendered while article or product templates are not. Test the template that carries your actual content.
The one command test
This is the highest value check in AI visibility work and it takes seconds. Everything else, the writing, the schema, the licensing files, is downstream of whether the content is present at all.
What an Empty Shell Looks Like
A shell response usually contains the document head, the navigation, a root element, and a script tag. It reads as a complete page to a validator and as nothing at all to a reader. If the body of your response is a single empty div, that is what every non rendering agent has been reading.
Rendering Strategies That Work
| Strategy | Content in initial HTML | Notes |
|---|---|---|
| Static generation | Yes | Best fit for articles and documentation, and the cheapest to serve |
| Server side rendering | Yes | Right when content is personalised or changes per request |
| Prerendering for bots | Yes, for the agents you configure | Works, but you maintain a second path and it can drift |
| Client side only | No | The failure case, and the default in several popular setups |
Content Behind Interactions
Tabs, accordions and read more toggles are fine if the text is in the HTML and merely hidden with styling. They fail if the content is fetched when the user clicks, because nothing that reads your page will ever click.
The test is the same as for the page overall. Ask whether the words exist in the response, not whether they appear on the screen.
It Is the Strategy, Not the Framework
No modern framework prevents you from shipping complete HTML, and plenty of sites built with them are cited constantly. The problem is a default configuration that renders on the client, which is common enough that it is worth verifying rather than assuming.
Before you rewrite anything
Run the fetch test first. Teams routinely rebuild content that was fine, when the actual fault was that nothing could read it. Confirm the content is reaching the crawler before you touch a single sentence of it.