Why AI Cannot See Your JavaScript Website

The gap between what you see and what they see

Open your site in a browser. Everything is there: headlines, body copy, product detail, the whole page. It looks finished because it is finished, in the browser.

Now consider what a crawler receives. It makes a request, your server returns a file, and whatever is in that file is what the crawler has. If your content is assembled afterward by JavaScript running in the visitor browser, then the file itself may contain almost nothing: a title, some meta tags, a couple of empty container elements, and a script tag.

Googlebot handles this reasonably well. It fetches the raw HTML, queues the page, and comes back later to render it with a real browser engine. It is slower and less reliable than serving finished HTML, but it generally works.

Several AI crawlers do not do the second pass at all. They take the raw HTML and move on. Whatever was not in that first response effectively does not exist, and the model deciding whether to cite you never reads a word of your actual content.

How to check in about thirty seconds

There is a specific trap here worth naming, because most people test this wrong.

Right-clicking and choosing Inspect shows you the DOM: the page after scripts have executed. It will almost always look complete, which is exactly why it tells you nothing about this problem.

What you want is View Page Source, which shows the raw HTML the server actually sent. Search that source for a distinctive sentence from the middle of your page copy.

If the sentence is there, you are fine. If it is not, you have found the issue: your visitors see a full page and script-blind crawlers see an empty shell.

A second check worth running is to disable JavaScript in your browser and reload. Whatever remains on screen is approximately what a non-rendering crawler gets. On a lot of modern sites, what remains is a blank white page or a loading spinner.

Where this bites hardest

The pattern shows up most often in a few predictable places.

• Single-page applications. A default React, Vue, or Angular build ships an empty root element and constructs everything client-side. The framework is not at fault; the default configuration is.
• Tabbed and accordion content. Specification tables, FAQ panels, and detail sections that only load when a user clicks. If the content is fetched on interaction rather than present in the HTML, a crawler that never clicks never receives it.
• Infinite scroll and lazy-loaded text. Fine for images. Harmful when the body copy itself only appears as the user scrolls.
• Third-party embedded reviews and pricing widgets. Often the most persuasive content on a commercial page, and often entirely invisible in the source.
• Cookie walls and consent gates. Some implementations withhold page content until consent is given, which means an automated fetch receives nothing but the banner.

What it costs you

This failure is unusually expensive because it is total rather than partial.

Most visibility problems are matters of degree. Thin content ranks a little worse. Missing schema makes parsing a little harder. Slow pages get crawled a little less. You lose ground, but you remain in the picture.

Client-side rendering against a non-rendering crawler is different. There is no degraded version. The crawler receives a shell containing no substance, and no amount of quality in the content it cannot see will help. You can have the best resource on your topic anywhere on the internet and still be invisible to the systems increasingly deciding what buyers hear about.

It is also silent. Nothing breaks. No error appears. Analytics look normal because real visitors with real browsers see everything correctly. The only symptom is an absence: you never get cited, and nobody can tell you why.

Fixing it

The direction of the fix is always the same: get meaningful HTML into the initial server response. How you get there depends on your stack.

Server-side rendering generates the HTML on the server for each request. Next.js, Nuxt, and their equivalents support this directly, and for most sites it does not require a rewrite so much as a configuration change plus some care around data fetching.

Static generation pre-builds pages at deploy time. For content that does not change per visitor, which describes most marketing pages, service pages, and blog posts, this is usually the simplest and fastest option.

Selective conversion is the pragmatic middle path. Your application dashboard genuinely needs to be client-rendered and no crawler needs to see it anyway. Your public content pages are what get cited. Converting only those is a much smaller project than converting the whole codebase, and it captures nearly all the benefit.

For tabs and accordions, ship the content in the HTML and use CSS or JavaScript to control visibility, rather than fetching it on click. The user experience is identical and the content becomes readable by machines.

Confirming the fix worked

After deploying, run the same View Page Source check on the pages you changed. Your body copy should be present in the raw HTML.

A DidItIndex scan checks JavaScript rendering as part of the Technical Trust module, alongside crawler access, redirect chains, and page weight, so you can confirm the fix landed across your key pages at once rather than inspecting each by hand. It is a fast check to clear, and it is worth clearing early: every other improvement you make to a page depends on a crawler being able to read that page in the first place.