Your Site Ranks on Google and Is Invisible to AI. Here Is How to Check.
There is a comfortable assumption behind a lot of AI search advice: that if Google can read your site, everything else can too. Google is the hardest crawler to satisfy, the thinking goes, so clearing that bar clears all of them.
It is a reasonable assumption. It is also the single most expensive thing to get wrong, because when it fails it fails silently and completely — not a lower position, but absence.
Two kinds of crawler
Google's crawler renders JavaScript. It fetches your HTML, and then — separately, often later — runs a headless browser over the page to see what the scripts build. Google has documented this for years. It is why a site built entirely in the browser can still rank: Googlebot waits for the page to assemble itself.
Most crawlers do not do that. Rendering a page is enormously more expensive than fetching one: you are running a browser instead of reading a file. Plenty of crawlers, including several that feed AI systems, take the cheap path. They request the URL, read the HTML that comes back, and move on.
If your page ships its content from the server, those two crawlers see the same thing. If your page ships an empty shell and builds itself in the browser, they do not. Google sees your site. The other one sees a div.
Why this is worth thirty seconds of your time
The failure mode here is unusual, and that is what makes it dangerous. Most SEO problems are gradual — you slip from four to eleven, traffic sags, you investigate. This one is binary. Either your words are in the HTML or they are not. If they are not, you are not ranked badly in an AI answer; you are not a candidate for it at all.
And nothing tells you. Your Google traffic looks fine, because Google is the one crawler that does the expensive thing. Your analytics look fine. The absence is invisible from inside.
The test
You do not have to take anyone's word for this, which is the best feature of the whole problem. Two ways to check, neither of which needs a tool or a subscription.
View source, not inspect. In your browser, view the page source — the raw HTML the server sent, not the developer tools element inspector. The inspector shows you the page after JavaScript has run, which is exactly the thing you are trying to see past. In the raw source, search for a distinctive sentence from your homepage. If you cannot find it, a crawler that does not render will not find it either.
Turn JavaScript off. In your browser settings, disable JavaScript for your own domain and reload. What remains is roughly what a non-rendering crawler receives. If the page is blank, or a spinner, or a "please enable JavaScript" notice, you have your answer.
Do this on your homepage, one service page, and one article. Sites are rarely uniformly broken — it is common for a marketing homepage to be server-rendered while an interactive section is not.
What causes it
Almost always a framework used in its client-rendering mode. A single-page application — the pattern where the server sends a near-empty page and the browser assembles everything — is the classic case. So is a site where the main content arrives from an API call after load, or a page builder that injects text through a script.
WordPress sites are usually fine at the HTML level, because PHP composes the page on the server before it is sent. Where WordPress runs into trouble is elsewhere: speed, bloat, and the plugin scripts layered on top. Different problem, different article.
The fix, and why it is not a plugin
The answer is to render on the server: the HTML that leaves your server already contains your words. In modern frameworks this is a build-time and architecture decision, not a setting you toggle afterwards. Next.js, for example, server-renders by default — you have to opt out of it, which is the right way round.
If your site is client-rendered today, this is not a patch. It is a structural change to how pages are produced. That is unwelcome news, and it is better than the alternative, which is discovering it in eighteen months.
The honest limit of this advice
We can tell you with confidence that crawlers differ in whether they execute JavaScript, and that this is testable on your own site in a minute. We cannot tell you exactly which AI system uses which crawler with which behavior this quarter — that changes, the operators do not publish complete specifications, and anyone who gives you a definitive table of it is guessing with more confidence than the evidence supports.
Which is why the recommendation is not "optimize for crawler X." It is: put your content in the HTML, so the question stops mattering.
Next steps
Run the two tests above. If your own copy is missing from your own source, that is the finding — no audit required.
If it is missing and you want to know what a server-rendered version of your site would look like, we build them, and there is a complimentary mockup if you would rather see it than read about it. If you would like a second pair of eyes on the whole picture first, the site audit is free.
