Skip to content

How many software company websites are empty to AI crawlers without JavaScript?

Ronan Liedmeier

Published , updated

On this page
  1. How many software company websites fail the JavaScript check?
  2. What exactly counts as a fail?
  3. Why do AI crawlers need content in the raw HTML?
  4. How much lower do these sites score?
  5. What happened on my own site?
  6. How do you test your own pages?
  7. Which fix should you pick: server-side rendering, static generation or prerendering?
  8. How I ran the check
  9. What I'd do
  10. FAQ
  11. Sources

Short answer

Of 1,586 software company websites I scored on 22 October 2026, 170 (10.7%) had under 150 words of text in raw HTML on both the homepage and sampled pages, and 74 (4.7%) on one of the two; on the 1,481 sites whose homepage loaded, 87 (5.9%) failed and 53 (3.6%) were partial. The crawlers behind ChatGPT search, Claude and Perplexity do not run JavaScript, so those pages reach them close to empty.

Of the 1,586 software company websites I scored, 170 (10.7%) failed the JavaScript check: under 150 words of text in the raw HTML of the homepage, and a median under 150 words across the sampled pages. Another 74 (4.7%) failed on one of the two. Counting only the 1,481 sites whose homepage loaded for my checker, 87 (5.9%) failed and 53 (3.6%) were partial. Those pages reach OAI-SearchBot, GPTBot, ClaudeBot and PerplexityBot close to empty, because those crawlers read the HTML the server sends and do not run the scripts that build the page. Of all the checks in my 22 October 2026 AI search readiness run on 1,601 software company websites, this article covers the one that decides whether an engine can read a page at all.

By Ronan Liedmeier, fractional head of growth. Last updated 23 October 2026.

Text without JavaScript is the text a crawler gets from the raw HTML a server returns, before any script runs. A page built in the browser by a JavaScript framework can look complete to a person and still arrive at a non-rendering crawler as an empty shell.

How many software company websites fail the JavaScript check?

Of all 1,586 scored software company websites, 170 (10.7%) failed and 74 (4.7%) were partial. On the 1,481 sites whose homepage loaded, the numbers drop to 87 failed (5.9%) and 53 partial (3.6%).

Result All scored sites (1,586) Sites whose homepage loaded (1,481)
Pass 1,342 (84.6%) 1,341 (90.5%)
Partial (homepage or sampled pages under 150 words) 74 (4.7%) 53 (3.6%)
Fail (both under 150 words) 170 (10.7%) 87 (5.9%)

The 1,586 figure includes the 105 sites whose homepage did not load for the checker, and most of those fail the word count too, because the checker counts the words on whatever error or block page came back. Many of them refuse automated requests in general, covered in do software companies block AI crawlers?. In the 1,481 base, a fail means the server sent a page and the page was empty, which is the rendering problem this article is about.

The rate barely differs by region. The check failed on 11.6% of the 639 US sites and 10.1% of the 947 European sites.

In points, the check cost the sample 1,242 of the 51,121 points lost across all checks, against 6,156 for question-shaped headings alone (full breakdown in the study of 1,586 software company websites). It still matters more than its points, because every content check reads the same HTML.

What exactly counts as a fail?

A site passes when the homepage has 150 or more words in its raw HTML and the pages sampled from the same site have a median of 150 or more words. It is partial when only one of the two clears 150, and it fails when neither does.

The scoring code of version 2 applies four rules.

  1. Raw HTML means the response to a plain HTTP request. No JavaScript is executed.
  2. Words are counted on the body text after removing script, style, noscript, svg, template and iframe elements. A "please enable JavaScript" message inside a noscript tag does not count.
  3. Sampled pages are up to eight per site, taken from the sitemap and homepage links, with article pages first plus the about, contact and pricing pages where they exist. The median site had 9 URLs read, the homepage included.
  4. Only sampled pages that returned HTTP 200 count toward the median. If none loaded, the homepage result stands for both halves.

The bar is low on purpose. Navigation, footer links and a cookie notice count toward the 150 words, so a page that fails has close to nothing in its HTML.

Why do AI crawlers need content in the raw HTML?

The crawlers behind ChatGPT search, Claude and Perplexity read the HTML and do not execute the JavaScript that builds a client-rendered page. Vercel's analysis of crawler traffic on its network, published 17 December 2024, states that "none of the major AI crawlers currently render JavaScript" (Vercel).

The crawlers it lists as non-rendering are OpenAI's OAI-SearchBot, ChatGPT-User and GPTBot, Anthropic's ClaudeBot, Meta-ExternalAgent, ByteDance's Bytespider and PerplexityBot. The same analysis found that ChatGPT's and Claude's crawlers do fetch JavaScript files and still do not execute them. Its recommendation to site owners is to "prioritize server-side rendering for critical content."

For being cited in search answers, two of these bots matter most. OpenAI describes OAI-SearchBot as "used to surface websites in search results in ChatGPT's search features" (OpenAI). Perplexity says PerplexityBot is used to surface and link websites in its search results and "is not used to crawl content for AI foundation models" (Perplexity). GPTBot, by OpenAI's description, crawls content that may be used to train its models.

Google is the main exception, and that is why the problem goes unnoticed. In Google's words, "once Google's resources allow, a headless Chromium renders the page and executes the JavaScript" (Google Search Central). Vercel reports that Gemini uses Googlebot's infrastructure and that AppleBot also renders. So a client-rendered site can be indexed in Google while ChatGPT search, Claude and Perplexity see an empty page. Google's own guidance still says "server-side or pre-rendering is still a great idea" and notes that "not all bots can run JavaScript."

Vercel's data is from late 2024 and crawlers change. Until a crawler operator documents that its bot renders JavaScript, I treat raw HTML as what it reads.

How much lower do these sites score?

Sites that fail the check score a mean of 25.0 (median 25), inside the band my tool labels "Mostly invisible to AI search". Sites that pass average 69.4 (median 71).

JavaScript check result Sites Mean score Median score
Fail 170 25.0 25
Partial 74 53.2 51
Pass 1,342 69.4 71

Part of that gap is mechanical. The content checks read the same raw HTML. A page with no text there has no question-shaped headings, no answer-first paragraphs, no tables, no FAQ, no article depth and no facts to count, so one rendering problem shows up as failures across many checks. The fail group also contains sites whose homepage did not load at all, which pulls its mean down further. What the table does show is that a reader behaving like a non-rendering crawler finds little to score on these sites beyond access and metadata.

None of these scores count citations. In my 209-vendor citation test, the JavaScript check showed a weak relationship with being cited that was not statistically significant, because too few vendors failed it. The five checks that did predict citation within an answer were FAQ, named author with about page, article depth, comparison tables and visible dates.

What happened on my own site?

My own site had this problem. On 15 October 2026 the raw HTML of the growthmarketing.solutions homepage contained only the head and an empty root div, so GPTBot, OAI-SearchBot, PerplexityBot and ClaudeBot saw no content.

The site is built with Lovable, a React app builder. An empty root div is what a client-rendered React app sends before its scripts run: the browser fills it in, a non-rendering crawler gets nothing.

The same day, the Insights section was switched to static HTML generated at build time from markdown. A crawl test fetched without JavaScript then returned the full article: the H1, the byline, the dated last-updated line, the table, the FAQ and the sources. This article sits in that section.

How do you test your own pages?

Look at the raw HTML the server sends and check whether your actual content is in it.

  1. Use View Source. In Chrome, Ctrl+U (Cmd+Option+U on a Mac) shows the raw HTML. The DevTools Elements panel shows the page after JavaScript ran and hides the problem.
  2. Search the source for a sentence from the middle of the page. If it is missing and the body is little more than <div id="root"></div> or <div id="app"></div>, crawlers that do not run JavaScript see an empty page.
  3. Fetch it from the command line. curl -sL https://yourdomain.com/ -o raw.html saves the raw response; then grep -c "a sentence from your page" raw.html returns 0 if the text is not there.
  4. Count the words. lynx -dump -nolist https://yourdomain.com/ | wc -w counts the text a non-JavaScript browser sees. A rough alternative is curl -sL https://yourdomain.com/ | sed 's/<[^>]*>/ /g' | wc -w, which overstates because it also counts inline script code. Under 150 words is a fail by my threshold.
  5. Turn JavaScript off and reload. In Chrome DevTools, open the command menu, run "Disable JavaScript" and reload the page. What is left is roughly what OAI-SearchBot gets.
  6. Test more than the homepage. Check one article, the pricing page and one product page. The 53 partial sites among those whose homepage loaded passed on one side and failed on the other, so one page type on a site can be fine while another is empty.

The free readiness check runs the same test and reports the word counts it found.

Which fix should you pick: server-side rendering, static generation or prerendering?

Pick the option that puts your content into the HTML response for every visitor, bots included. For articles, docs and landing pages, static generation at build time is the simplest; for pages built from live data on each request, server-side rendering; for an existing client-rendered app you cannot rebuild yet, build-time prerendering is the stopgap.

Option When the HTML is produced What a non-JavaScript crawler gets Best fit Main trade-off
Client-side rendering only In the visitor's browser, after scripts run The head and an empty root element App screens behind a login Public pages are empty to OAI-SearchBot, ClaudeBot and PerplexityBot
Server-side rendering On the server, for each request The full page Pages built from live data per request Needs a server or edge runtime and more moving parts
Static generation Once, at build time The full page Articles, docs, landing pages, changelogs Every content change needs a rebuild
Build-time prerendering At build time, by loading each listed route in a headless browser and saving the HTML The full page for routes on the list An existing single-page app with a known set of public routes Routes missing from the list stay empty; snapshots age between builds
Dynamic rendering (prerendered pages for bots only) On request, by a service that renders for detected bots The full page, if the bot is detected A short-term patch Google calls it "a workaround and not a recommended solution"; depends on user-agent detection

Server rendering and static generation both work with hydration: the server sends the complete HTML, then the scripts attach to it and the page becomes interactive. Google lists the same three alternatives to dynamic rendering: "server-side rendering, static rendering, or hydration" (Google Search Central).

How I ran the check

The sample is software publishers (NAICS 51321 or 5112) with 11 to 200 employees, founded 2015 or later, headquartered in 13 countries: the US, the UK, Ireland, Germany, Austria, Switzerland, the Netherlands, Belgium, Luxembourg, Denmark, Sweden, Norway and Finland. The list came from an Apollo company search pulled on 22 October 2026, with agencies, consultancies, PR firms, online shops and staffing firms excluded by NAICS code. I did not verify HQ country company by company; it comes from the query's filter.

I attempted 1,601 sites and scored 1,586 (1,583 complete, 3 partial scans that ran out of the 45-second budget). Fifteen failed: 12 domains did not resolve and 3 hit other errors. Before the run I removed 12 companies I had already contacted and 20 very large, well-known brands; 65 more were dropped while pulling, mostly for having no domain.

The run was continuous on 22 October 2026, 18:03 to 18:28 Pacific time, with version 2 of the GMS AI search readiness check, the same scoring code as the free tool, run as a local batch on a residential connection. No site was checked twice.

This check has five limits of its own.

  1. The word count includes navigation and footer text, so it can pass a page whose main content is missing.
  2. A short, server-rendered homepage under 150 words fails even though nothing is wrong with its rendering.
  3. Most of the 105 homepages that did not load land in the fail or partial group, because the checker counts the words on the error or block page, which is why I report the 1,481 base alongside the full one.
  4. The check does not identify the framework or rendering method a site uses, so I make no claim about which tools produce these failures.
  5. Up to eight sampled pages per site is a sample; other pages can differ.

What I'd do

  1. Today, view source on the homepage, one article and the pricing page. If the sentence you search for is not in the source, stop optimising content until this is fixed.
  2. Move public marketing and content pages to static generation first. Leave the logged-in app client-rendered; crawlers have no business there.
  3. If a rebuild is not possible this quarter, prerender the public routes at build time. Skip bot-only dynamic rendering.
  4. Make sure the parts engines quote are in the HTML response itself: the full article text, a byline linked to an about page, a visible date, a table and an FAQ. Those cover the five features the 209-vendor test tied to citation.
  5. Add a check to your deploy: fetch three key URLs without JavaScript and fail the build if the word count drops under 150. A redesign or a framework change can bring the problem back.
  6. Then check whether your firewall lets the search bots in at all, covered in the access article, and work through the content checks in the guide to getting cited by ChatGPT, Perplexity and AI Overviews. The GEO audit checklist has the full list.

I work as a fractional head of growth for software companies, and the rendering check is the first thing I look at, because every content check depends on a crawler being able to read the page. Run the free readiness check on your homepage to see your word counts and the rest of the 22 checks. For the citation side, the paid AI Visibility Snapshot runs ten prompts in your category, scores your site on the 22 checks and sends a one-page readout in three working days.

Re-check by 23 January 2027: whether any of the major AI crawlers has started rendering JavaScript, whether Vercel or the crawler operators have published newer data, and the JavaScript check results when the same software company websites are re-run.

Is your site readable by AI search?

Run the free readiness check, or book a call if you want me to look at your category.

FAQ

How many software company websites are unreadable without JavaScript?

Of the 1,586 software company websites I scored on 22 October 2026, 170 (10.7%) had under 150 words of text in raw HTML on both the homepage and the sampled pages, and 74 (4.7%) failed on one of the two. Counting only the 1,481 sites whose homepage loaded for the checker, 87 (5.9%) failed and 53 (3.6%) were partial. The sample is software publishers with 11 to 200 employees, founded 2015 or later, in 13 countries.

Do ChatGPT, Claude and Perplexity crawlers run JavaScript?

No, according to Vercel's analysis of crawler traffic on its network, which states that none of the major AI crawlers currently render JavaScript. It lists OpenAI's OAI-SearchBot, ChatGPT-User and GPTBot, Anthropic's ClaudeBot and PerplexityBot among them. The exceptions it names are Gemini, which uses Googlebot's infrastructure, and AppleBot, which renders through a browser-based crawler.

How do I check whether my pages are readable without JavaScript?

Open the page, press Ctrl+U (Cmd+Option+U on a Mac) to see the raw HTML, and search it for a sentence from the middle of the page. If the sentence is missing and the body is little more than an empty root div, crawlers that do not run JavaScript see an empty page. For a word count, run lynx -dump -nolist on the URL and pipe it to wc -w; my check fails a site when the homepage and the median sampled page both have under 150 words.

Should I use server-side rendering, static generation or prerendering?

Use static generation for articles, docs and landing pages that change at most a few times a day, and server-side rendering for pages built from live data on each request. Build-time prerendering of known routes is a stopgap for an existing client-rendered app you cannot rebuild yet. Avoid serving prerendered pages to bots only: Google calls that dynamic rendering a workaround and not a recommended solution.

Does fixing JavaScript rendering get my site cited by AI search?

Not by itself. Fixing it lets crawlers read the page, and every content check depends on that. Sites that failed the check scored a mean of 25.0 against 69.4 for sites that passed, but part of that gap is mechanical because the content checks read the same raw HTML. In my 209-vendor citation test the JavaScript check showed a weak relationship with citation that was not statistically significant; the checks that predicted citation within an answer were FAQ, named author with about page, article depth, comparison tables and visible dates, and all five need a readable page first.

Sources

  1. Vercel: The rise of the AI crawler vercel.com
  2. OpenAI: Overview of OpenAI Crawlers developers.openai.com
  3. Perplexity: crawler documentation docs.perplexity.ai
  4. Google Search Central: Understand JavaScript SEO basics developers.google.com
  5. Google Search Central: Dynamic rendering as a workaround developers.google.com
  6. GMS: AI search readiness of 1,586 software company websites growthmarketing.solutions
  7. GMS: Which website features predict an AI citation? 209 vendors and 40 Perplexity prompts growthmarketing.solutions
  8. GMS: Free AI search readiness check growthmarketing.solutions

Re-check by 2027-01-23