Do AI crawlers execute JavaScript?
Or do they only fetch the files?

What is the practical answer?

The practical answer is simple. If you care about AI visibility, assume the crawler will request the page, request supporting JavaScript files, and stop there. Do not assume a browser-like render pass. Do not assume hydration. Do not assume the assistant can see text that only appears after an app boots.

This matters because many teams still build pages where the headline is in HTML but the useful substance arrives later through client-side components. That pattern can look fine in a browser and still be thin to an AI crawler. The crawler has the shell, the script references, and not much else it can quote with confidence.

The verified figure we can actually use is unusually clear. In the Vercel and MERJ server log study from late 2024, AI crawlers fetched JavaScript files and never executed them. That does not mean every system behaves identically forever. It does mean the safe operating assumption today is server first, not browser first.

Why does fetching JavaScript still confuse teams?

Because logs can be misleading if you are not used to reading crawler behavior. People see requests for app bundles, chunk files, or other static assets and conclude the bot rendered the page. It did not. Requesting a file is not the same thing as executing it.

A crawler can fetch JavaScript for several boring reasons. It may discover linked assets during HTML parsing. It may mirror browser-like resource fetching patterns without running the code. It may want metadata about file dependencies. None of that proves the script was executed and the resulting DOM was available for extraction.

This is where operator discipline matters. If your visibility strategy depends on a hopeful interpretation of logs, you are setting yourself up for phantom wins. The standard I use is stricter. If the meaningful text is not present in the first HTML response, I treat it as absent for AI search until proven otherwise.

What content breaks when JavaScript is required?

The obvious breakage is body copy loaded into a root div after hydration. But the more damaging failures are often quieter. Brand descriptions, product specs, comparisons, author bios, supporting examples, definitions, and trust signals frequently live inside client-rendered modules. Those are exactly the fragments assistants need when they synthesize answers or select citations.

• Entity descriptions that only appear after a framework renders the component
• Pricing or plan tables loaded by client-side requests, even when the page title suggests a comparison
• Use case sections hidden behind tabs that require JavaScript to reveal their text
• Knowledge base answers inserted after page load from an API call
• Reviewer, author, or company identity details rendered by widgets instead of the server

The pattern is consistent. If the answer-bearing text is optional to the initial HTML, extraction quality drops. AI systems need text they can parse cleanly. They are not rewarding clever front-end architecture. They are rewarding availability.

How should you build pages for AI extractability?

Start with a harsh principle. Anything you would be happy to see quoted by an assistant should exist in the raw HTML response. Headline, summary, definitions, product facts, author details, evidence, and contact context all belong there. JavaScript can enhance the experience, but it should not be responsible for delivering the facts.

This is less about chasing a ranking trick and more about reducing ambiguity. An assistant that cannot see your substantive text will rely on third-party sources, stale copies, or generic summaries. That is how brands get flattened, misdescribed, or omitted.

• Server-render the core answer and supporting copy
• Expose definitions and key claims in visible HTML, not hidden app state
• Keep a plain-text summary near the top of the page
• Make tables and comparison criteria available in source HTML
• Use schema to clarify meaning, but do not expect schema to replace missing page text

That last point matters. Schema helps disambiguate entities and relationships, but schema is not a magic override for absent content. If the page lacks extractable prose, adding more markup does not solve the underlying problem.

What should you test before changing the whole site?

Do not begin with a full rebuild. Pick a handful of pages that matter commercially and diagnostically. A product page, a category page, a thought leadership page, and one comparison page are usually enough to reveal the pattern. Compare what exists in the first HTML response with what only appears after scripts run in a browser.

Then ask a harder question. If an assistant had only the first HTML response, would it understand who you are, what the page is about, what claims are being made, and what evidence supports them? If the answer is no, the page is under-instrumented for AI visibility regardless of how polished it looks in Chrome.

I would also separate discoverability from extractability. A crawler may find the URL. That does not mean it can quote the page accurately. Many teams conflate those two steps and wonder why they are visited but not cited.

Where does this advice fail or need nuance?

Here is the trade off. Not every page needs to be rebuilt into a fully server-rendered masterpiece. Some authenticated app surfaces, dashboards, calculators, and highly interactive tools exist mainly for human use after the click. For those pages, the AI visibility goal should sit on surrounding documentation, landing pages, or explainer content, not the app shell itself.

There is also a limit to what logs alone can prove. The verified evidence supports the safe assumption that AI crawlers fetch JavaScript files and do not execute them. It does not prove every downstream AI pipeline works the same way, or that no system ever sees rendered content through another path. That is why I recommend building for the conservative case. It is the only case you can operationalize reliably.

This advice is also not for teams whose actual problem is outbound execution or pipeline math. If your issue is meeting generation, that belongs on the parent brand. We run managed outbound under Outbound Pros, but that is a different problem set. Here, the job is making your pages legible to AI systems before any human ever books a call.

What should operators do next?

Run a brutal audit of your money pages. View source, not inspector. If the explanation, evidence, positioning, and key facts are missing from source HTML, fix that before you buy another visibility tool. Tooling can help measure symptoms. It cannot compensate for pages that never present the answer in the first place.

Also ignore folklore metrics that claim exact uplift multipliers from specific schema types or recency tweaks. Those numbers circulate widely and are often repeated as if settled fact. They are not part of the evidence base I trust. The stronger move is boring: make the important text visible in HTML, tighten entity consistency, and verify what assistants can actually quote.