Free JavaScript Rendering Check for AI Crawlers

The check answers one question: does the text that matters exist in the HTML your server sends, before any JavaScript runs?

That matters because most AI crawlers read only that first response. Vercel's study of AI crawler traffic found that ChatGPT and Claude crawlers fetch JavaScript files (11.50% and 23.84% of their requests) but don't execute them, so they can't read client-side rendered content. Independent re-testing in June 2026 found the same for GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-SearchBot, PerplexityBot, Meta-ExternalAgent and Bytespider. Googlebot and AppleBot are the exceptions: they render.

So if your pricing table, product names or main headings load through JavaScript, a ChatGPT search crawler may see an empty shell. If you build on React or a similar framework, read whether ChatGPT can read a React website for the framework-specific detail.

You need a browser and, optionally, a terminal. Pick one page that carries facts buyers ask about, such as your pricing or main product page.

1. Read the raw HTML. In Chrome, type view-source: before the URL, for example view-source:https://example.com/pricing. This shows the server's response before JavaScript runs.
2. Search it. Press Ctrl+F (Cmd+F on Mac) and search for the exact facts you expect: a price, a plan name, the H1 text.
3. Or fetch it from a terminal. Run curl -s https://example.com/pricing | grep -i "starter". No output means the word is not in the raw HTML.
4. Load the page with JavaScript off. Open DevTools (F12), open the Command Menu (Ctrl+Shift+P or Cmd+Shift+P), type "Disable JavaScript" and reload. What you see is roughly what a non-rendering crawler gets.
5. Compare with the normal page. Turn JavaScript back on, reload, and note every fact that appears only now.
6. Open hidden panels. Click tabs, accordions and "load more" buttons. Content fetched on interaction is missing from the raw HTML too.

For a fuller method, including how to diff extracted text at scale, follow the raw HTML vs rendered DOM playbook.

Don't check everything. Check the sentences an AI answer would need to describe you correctly.

• Prices and plan names. These are the facts AI answers most often get wrong, and the ones buyers ask about.
• Product and feature names. If your product name sits in a JavaScript-rendered hero block, the crawler may not see it at all.
• Headings (H1 and H2). They tell any reader what the page covers.
• One-line definitions of what you do. A specific, fetchable sentence gives an engine something it can quote.
• Locations, integrations and contact details. Often loaded from a widget or API call.

Say you run a hypothetical project-management SaaS. Your pricing page shows three plans in the browser, but view-source shows only a loading spinner and a script tag. For a non-rendering crawler, you have no prices. The guide to finding facts hidden behind JavaScript walks through a page-by-page inventory.

Sort every fact you checked into one of three outcomes.

• Present in raw HTML. Good. Non-rendering crawlers can read it.
• Present only after JavaScript. This is a gap. Fix it by moving that content into the server response through server-side rendering, prerendering or static generation. The comparison of SSR, prerendering and static generation helps you pick one.
• Present only after a click. Put the key facts in the initial HTML, even if the interactive version stays.

One nuance: Vercel notes that data embedded as JSON or React Server Components payloads inside the initial HTML response may still be read. If you find your price inside a script block in view-source, it is in the response, but plain visible text is the safer target.

For Google, the stakes differ. Googlebot renders JavaScript, so a gap here rarely explains missing AI Overviews. See whether AI Overviews need server-side rendering.

Be clear about the boundaries before you act on the result.

• It doesn't test access. A page can pass this check and still be blocked by robots.txt or by a firewall or CDN returning 403 to an AI crawler. OpenAI's crawler documentation treats each bot separately, so check them one by one. The free AI crawler checker page covers that test.
• It doesn't predict citations. Fixing rendering decides whether your content exists for the crawler. It does not make an engine more likely to retrieve or cite you. Retrieval and citation depend on the query and on the engine. Read whether SSR will increase your AI citations for what the evidence supports.
• It doesn't reach answers without search. When a model answers from memory with no web access, nothing on your site this quarter changes that answer.
• It's a snapshot. A redeploy or a new framework version can reintroduce the gap. Re-run it after major front-end changes.

What stays in your control is concrete: make sure the facts that matter are in the HTML your server sends.

The manual method works for one page. It gets slow across a site, and it doesn't show what each crawler actually receives.

The 99Visibility AI Crawler Checker requests a page as each AI crawler and shows which ones your firewall turns away. Pair that with the raw HTML check above and you cover the two questions that come first: can the crawler reach the page, and can it read what's on it.