JavaScript SEO in the AI Era: What GPTBot and ClaudeBot Actually See

JavaScript SEO used to be a question about one crawler. Google got good at rendering JavaScript years ago, the panic subsided, and most teams stopped thinking about it. Then a second class of crawler showed up (GPTBot, ClaudeBot, PerplexityBot, Meta-ExternalAgent) and it does not render anything. It requests your URL, reads whatever HTML comes back in that first response, and leaves. If your page assembles itself in the visitor’s browser, those crawlers get an empty shell. Your Google rankings look fine.

Your presence inside AI answers quietly does not exist.

This piece covers what JavaScript SEO means now that AI crawlers are in the mix, what the server-log evidence actually shows about which bots render and which don’t, how to check your own pages in under five minutes, and which rendering strategy to pick. Every figure below is attributed to a named, dated source.

Nothing is modeled or estimated.

What is JavaScript SEO, and what changed when AI crawlers arrived?

JavaScript SEO is the practice of making sure content built or loaded by JavaScript is still discoverable by the machines that read your site. The classic version of the problem was about Google: would Googlebot execute your scripts and index what they produced? The 2026 version is broader, because a growing share of the machines reading your site never execute anything at all.

Google’s own documentation describes a three-phase process, crawling, rendering, indexing. Googlebot fetches the URL, queues the page, and once resources allow, a headless Chromium renders it and runs the JavaScript; Google then indexes the rendered HTML. That architecture is why client-side content eventually shows up in Google. The same documentation, last updated March 4, 2026, adds a clause that’s easy to skim past and now matters enormously: server-side or pre-rendering is still a good idea “because it makes your website faster for users and crawlers, and not all bots can run JavaScript.”

That clause is the whole story. AI crawlers have no render queue and no second pass. Whatever arrives in the initial HTML response is the entire universe of what an AI system knows about your page, and that response is what gets summarized, cited, or ignored inside ChatGPT, Claude, and Perplexity. Search demand shows a market only starting to connect these dots: “javascript seo” draws 3,600 US searches a month and “react seo” 1,300, while “llm seo” has climbed to 1,300 and sits near its twelve-month peak (Semrush, US database, July 2026).

Two established problems and one new one, still being solved separately.

Do AI crawlers render JavaScript?

No. The most substantial published server-log evidence on this comes from Vercel and MERJ, who monitored crawler behavior across Vercel’s network and validated the findings against sites built on different technology stacks. Their conclusion, published December 17, 2024, was blunt: none of the major AI crawlers currently render JavaScript. The list they tested covered OpenAI’s OAI-SearchBot, ChatGPT-User and GPTBot; Anthropic’s ClaudeBot; Meta-ExternalAgent; ByteDance’s Bytespider; Perplexity’s PerplexityBot; and Common Crawl’s CCBot, which is widely used as a model training dataset.

The detail that makes the finding vivid is that these bots happily download JavaScript files. GPTBot fetched JavaScript in 11.50% of its requests and ClaudeBot in 23.84%. They simply never run them. The files are collected as text, not executed as instructions. Meanwhile ChatGPT’s crawler devoted 57.70% of its fetches to HTML and Claude’s devoted 35.17% to images, compared with Googlebot’s more even spread of 31.00% HTML, 29.34% JSON, 20.77% plain text and 15.25% JavaScript.

There are two documented exceptions. Google’s Gemini inherits Googlebot’s infrastructure and renders fully. AppleBot uses a browser-based crawler that processes JavaScript, CSS and Ajax requests. Everything else in that study reads raw HTML and moves on. One honest caveat: this is December 2024 data, and it is the largest published server-log analysis we could verify rather than a live 2026 measurement. We have not found a comparably rigorous re-test since, and we are not going to invent one. What we can say is that Google’s March 2026 documentation still warns that not all bots run JavaScript, and no major AI provider has announced a rendering capability in the interim.

Is JavaScript bad for SEO?

JavaScript isn’t bad for SEO. Depending on JavaScript to deliver your primary content is. The distinction decides everything that follows.

The evidence for Google is unusually clear. In the July 31, 2024 study, Vercel and MERJ analyzed over 100,000 Googlebot fetches and found that 100% of indexable HTML pages resulted in full-page renders, including pages with complex JavaScript interactions, asynchronously loaded API content, and streamed React Server Components. Rendering delay was far shorter than folklore suggested: a median of 10 seconds and 26 seconds at the 75th percentile, with a long tail reaching roughly three hours at the 90th percentile and about eighteen hours at the 99th.

So for Google, the honest answer is that a well-built JavaScript site is fine. The reason to server-render in 2026 is not Googlebot. It is everything else: the AI crawlers with no render step, the crawl-efficiency cost on large sites, and the plain fact that HTML in the first response is the only content every machine agrees it can read. That same study rated client-side rendering “poor” for crawl efficiency and rendering time even under Google, while static generation, incremental regeneration and server-side rendering all rated excellent or very good.

Scale context is worth stating carefully. The HTTP Archive’s 2024 Web Almanac found React on 10% of pages, up from 8% the year before, while jQuery still appears on 74%. Those figures measure library presence, not rendering mode: plenty of React sites are server-rendered and plenty of jQuery sites are static HTML. We can’t responsibly turn them into a count of invisible websites, and we won’t. What they do establish is that framework-driven front ends are common enough to make this a mainstream risk rather than an edge case.

How do you check whether an AI crawler can see your page?

View the raw HTML your server returns and search it for your actual content. If your headline, body copy, product names or prices aren’t in there as text, no AI crawler can read them. Three checks, escalating in effort:

1. View source, not inspect element. This trips up more teams than anything else. “Inspect element” shows the live DOM after JavaScript has run — it will always look complete. “View page source” shows the raw HTML the server actually sent, which is what a non-rendering crawler receives. Open source view and use find to search for a distinctive sentence from your page. Found it? Good. Not found? That content is invisible to AI crawlers.
2. Fetch the page with JavaScript disabled. Turn JavaScript off in your browser settings and reload your most commercially important pages: your top service page, a category page, a product detail page. What remains is roughly what GPTBot and ClaudeBot see. A blank screen or a bare loading spinner is a definitive answer.
3. Read your server logs for the bots by name. Filter for GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, PerplexityBot, Meta-ExternalAgent and CCBot. This tells you which AI systems are visiting, how often, and which URLs they hit — and whether your CDN’s bot management is quietly blocking traffic you meant to serve.

That third check has a strategic dimension worth understanding before you widen the gates. Cloudflare began publishing crawl-to-refer ratios on July 1, 2025: how many HTML pages a platform crawls for every visitor it sends back. In the first week of August 2025, the unfiltered figures were Anthropic near 50,000:1, OpenAI at 887:1 and Perplexity at 118:1; for news and publications sites the same week, those fell to 2,500:1, 152:1 and 32.7:1. Cloudflare also found that training accounted for nearly 80% of AI bot crawling. Those numbers argue for deciding crawler by crawler with your eyes open, not for blanket permission or blanket blocking. The technical work in this piece makes you readable; it doesn’t settle whether every bot deserves the read.

How do you make JavaScript SEO-friendly for AI crawlers?

Get your meaningful content into the initial HTML response and keep JavaScript for enhancement. Six steps, in the order they pay off:

1. Server-render or pre-render everything that matters. Main content, product data, pricing, documentation, and the meta information around it — titles, descriptions, canonical tags. Static generation, incremental static regeneration and server-side rendering all put that content in the first response. This is the single highest-leverage fix, and it makes every subsequent item easier.
2. Keep client-side rendering for genuine enhancements. View counters, live chat widgets, social feeds, interactive filters, personalization. Nobody needs an AI crawler to see your cart badge. The test is simple: if a machine summarizing your page would need it, render it server-side.
3. Put critical SEO tags in the HTML, not in scripts. Titles, meta descriptions, canonicals and structured data belong in the served markup. Google’s documentation permits injecting canonicals and JSON-LD with JavaScript, and Google will pick them up on render — but a crawler that never renders sees none of it. Structured data does double duty here as the machine-readable layer AI systems check, which we covered in our guide to schema markup for AI search.
4. Use real anchor tags for navigation. Google can only discover links in <a> elements with an href attribute, and it warns specifically against fragment-based routing in single-page apps. A crawler that doesn’t render is stricter still: if your navigation is a JavaScript click handler, your site has no discoverable structure at all beyond the entry page.
5. Don’t block the resources you need rendered. Robots.txt rules that disallow your JavaScript, CSS or API endpoints break rendering for the crawlers that do render, which means Google sees a broken page while AI crawlers see an empty one. Audit these deliberately.
6. Keep an accurate sitemap. The Vercel and MERJ research found that an updated sitemap.xml significantly reduces, and can eliminate, the discovery-time differences between rendering strategies. It’s the cheapest insurance in this list.

Almost none of this is exotic, and most of it overlaps with work that was already justified on performance and accessibility grounds. That’s the pattern across this whole area: the same foundations that make a site fast and accessible make it legible to machines, which is why they anchor how we approach website strategy generally.

Which rendering strategy should you choose?

Pick static generation or incremental static regeneration for content that doesn’t change per user, server-side rendering for content that does, and reserve client-side rendering for interface behavior. The comparison Vercel and MERJ published, based on Googlebot’s observed behavior, sorts cleanly:

The first three columns are Vercel and MERJ’s ratings for Google. The last column follows directly from their AI crawler findings: content that only exists after client-side rendering cannot reach a crawler that doesn’t render. Note too that content included in the initial HTML response (JSON payloads, streamed React Server Components) may still be readable by AI systems, because models interpret non-HTML text. The dividing line isn’t “did you use a framework.” It’s “did the content ship in the first response.”

If you’re on a client-rendered stack and a rewrite isn’t happening this quarter, sequence it by commercial value: server-render your highest-intent pages first (services, pricing, key products, the pages you’d want quoted in an AI answer) and work outward. Partial coverage of the pages that matter beats a perfect plan you never ship. This is the technical floor beneath the broader work of making a website agent-ready; agents that drive a real browser can render, but the crawlers feeding the models that recommend you cannot.