← All posts

Your website might be invisible to ChatGPT. Here is how to check in ten seconds

Our own site served zero words to an AI crawler on a Tuesday morning and 1,565 by the afternoon. Nothing about the page changed. Here is the one-line test that shows whether yours has the same problem.

Your website might be invisible to ChatGPT. Here is how to check in ten seconds

On the morning of 19 August 2026, every page of jumpahead.ai returned the same 922 bytes to anything that did not run JavaScript: an empty container and no words at all. By that afternoon the home page returned 1,565 words. Nothing about the design changed. Nobody wrote new copy. What changed was where the page gets assembled.

If your site was built in the last few years, there is a reasonable chance it has the same problem, and almost nothing will tell you.

What is actually going on#

Modern websites often ship as instructions rather than as pages. Your browser downloads a small file, runs the code inside it, and builds the page on your screen. A person sees a finished website. This is normal and it is why sites feel fast.

The automated readers that feed search engines and AI assistants mostly do not do that step. They request the address, take whatever comes back, and move on. Google runs the code. Most AI crawlers do not.

So the same address serves two very different things. A person gets your argument, your pricing, your case studies. A crawler gets an empty container.

The page is not ranked badly. It is not there.

The ten-second test#

Open a terminal. Paste this, with your own address:

curl -s https://yoursite.com | wc -w

That prints a number: how many words your site hands over before any code runs.

Under about 50 means your page is effectively empty to anything that does not execute JavaScript. Ours printed a number in that range on Tuesday morning.

Do it for your home page, one blog post, and your most important product page. If the number is similar on all three, that is another symptom: it usually means every address is serving the same file.

If you are not comfortable in a terminal, paste your result into any AI assistant with this:

I ran a command against my website to see what it serves before any JavaScript runs, and I got a word count back. Help me interpret it.
Ask me:
1. What word count did each page return?
2. Roughly how many words does each of those pages show a human?
Then tell me plainly whether my site is likely readable to crawlers that do not run JavaScript, or not. If it is not, explain in one paragraph what I should ask a developer for, in language I can paste to them. Do not give me a general SEO lecture. Answer only this question.

What we measured, before and after#

The full record is public in our repository. The relevant part:

PageWords served on Tuesday morningWords served that afternoon
Home01,565
About01,240
A blog post0596

Three other findings from the same check, each of which is its own small problem:

  • Every page shared one title. Eight different addresses, one identical title tag. To a crawler they were indistinguishable.
  • `robots.txt` and `sitemap.xml` did not exist, but did not fail either. Both returned a web page pretending to be a text file, with a success code attached.
  • A page that did not exist returned success. A made-up address returned the same "everything is fine" response as a real one, which means nothing could tell a real page from a typo.

What to ask for, in plain language#

This is a build change, not a content change. The phrase that gets you the right conversation:

"Our pages need to be server-rendered or pre-rendered at build time, so the HTML contains the actual content before any JavaScript runs. Each page needs its own title, description and canonical URL in that HTML. We also need a real robots.txt and sitemap.xml, and missing pages should return a real 404."

Two things worth knowing before that conversation, because they are where this goes wrong.

If your content comes from a content management system, the content has to be fetched while the site is being built, not while it is being viewed. Skip that and every page gets pre-rendered with the word "Loading" as its body, permanently, for every crawler. That is worse than the original problem, because now it is cached.

Pre-rendering makes missing pages worse before it makes them better. Once your real pages contain real content, every mistyped address serves a full copy of your home page with a success code, unless the missing-page handling is fixed in the same change. Ours did, for a few hours.

Why this matters more than it used to#

A blog post is worth writing because somebody eventually reads it, or because an assistant quotes it when somebody asks a question it answers. Both routes require the page to be readable by something that is not a browser.

Everything else in a content strategy sits downstream of that. Better writing, better topics, better structure, all of it assumes the words arrive. Ours did not arrive for the entire time our site had been live.

The test takes ten seconds. Most sites pass it. The ones that do not have usually never been checked, because nothing about the site looks broken to the person who built it.

Ahead pairs you with an expert operator who works on your own setup, in your own tools. If you ran that command and did not like the number, that is a good first hour.