Your website might be invisible to ChatGPT. Here is the ten-second test.
3 min read
In short
Most AI crawlers read the raw HTML your server sends and never run JavaScript. If your site is a single-page app, they can receive an empty container instead of your copy — and a page with nothing to read is a page with nothing to quote. One curl command tells you which one you are.
Run this before you read anything else
Open a terminal and put your own domain in place of ours:
curl -s -A "GPTBot" https://yourdomain.com/ | grep -o 'id="root"[^<]*'If that prints something like id="root"></div>, an AI crawler is receiving an empty box where your page should be. If it prints headings and sentences, you are fine and you can stop reading.
The flag that matters is -A "GPTBot". It asks the server for the page the way OpenAI's crawler asks for it: one plain HTTP request, no browser, no JavaScript.
What the two answers look like
This is our own homepage, measured both ways on the same afternoon.
Why this happens
Modern sites are often built as single-page applications. The server sends a nearly empty HTML shell and a JavaScript bundle, and the browser assembles the page in front of the visitor. This is a good architecture for the person using the site. It is a terrible one for anything that does not run JavaScript.
Google renders JavaScript before indexing, so search has mostly hidden this problem for years. The crawlers behind AI answers largely do not. They fetch, they read what arrived, and they move on.
Why it matters more than it used to
An AI assistant cannot cite a page it could not read. Not rank it lower — cite it at all. If your competitor's site sends real HTML and yours sends an empty container, they are quotable and you are not.
Be careful about how much you expect from this. The traffic arriving from AI assistants is still small for most businesses, and anyone promising you a flood is selling something. The reason to fix it is narrower and more durable: when someone asks an assistant who does what you do, you want to be one of the names it can actually repeat.
How to fix it
- Server-side rendering. The server assembles the HTML before sending it. Cleanest, and the most work to retrofit into an existing app.
- Prerendering. Render each page once at build time, store the HTML, and serve that. Much less work, and enough for marketing pages that change on a deploy rather than on a database write.
- A hybrid. Prerender the static pages, render anything database-driven on the server per request.
There is a trap in the middle option worth naming, because it is easy to walk into and hard to notice. A frozen snapshot of a page whose content comes from a database will keep serving whatever was true when it was captured. Visitors see current data because their browser refetches it; crawlers see the old copy indefinitely. Now you are showing two different pages to two different audiences, which is a worse problem than the one you set out to fix.
We had this exact problem
The measurement above is not a hypothetical. Until this week, every page on myralum.com sent an AI crawler an empty container — twenty-five characters, no headline, no sentences, nothing to quote. We build websites for a living and our own site was doing it.
It is a quiet failure. Nothing looks broken. Every visitor sees a normal site, analytics look fine, and the only symptom is an absence you would never think to check for.
So check. It takes ten seconds and you already have the command.