What is JavaScript rendering?
JavaScript rendering is the step where a browser, or a crawler acting like one, runs the JavaScript on a page and builds the content a person actually sees. On many modern sites, the HTML the server sends is close to empty and JavaScript fills it in.
A page built entirely in the browser might arrive like this:
<body>
<div id="root"></div>
<script src="/app.js"></script>
</body>Every heading, paragraph, price and link on that page exists only after app.js runs. A visitor's browser runs it in a fraction of a second. A crawler that does not run JavaScript sees an empty div and nothing else.
This approach is called client-side rendering. The alternatives, where the server sends finished HTML, are covered in server-side rendering for crawlers.
How does Google render JavaScript?
Google renders JavaScript in a separate step after crawling, using a headless version of the Chromium browser. Google describes three phases: crawling, rendering and indexing [1].
- Crawling. Googlebot fetches the URL, checks robots.txt, and reads the raw HTML for links.
- Rendering. Google "queues all pages with a
200HTTP status code for rendering, unless a robotsmetatag or header tells Google not to index the page" [1]. When resources allow, "a headless Chromium renders the page and executes the JavaScript" [1]. - Indexing. Google reads the rendered HTML for content and further links, and indexes the page.
The gap between steps 1 and 2 is the catch. Google says a page "may stay on this queue for a few seconds, but it can take longer than that" [1]. Content in the raw HTML is available at crawl time. Content added by JavaScript waits for rendering.
Google also needs to fetch the scripts and stylesheets a page uses. Google warns that if a site hides important resources like CSS and JavaScript, Google "might not be able to understand your pages" [7].
Do AI crawlers render JavaScript?
No, most major AI crawlers do not render JavaScript. Vercel's December 2024 analysis of traffic on its network found that none of the major AI crawlers from OpenAI (OAI-SearchBot, ChatGPT-User, GPTBot), Anthropic (ClaudeBot), Meta, ByteDance or Perplexity (PerplexityBot) executed JavaScript [2].
Some of those crawlers do download JavaScript files. Vercel found ChatGPT's crawler fetched JavaScript files in 11.50% of its requests and Claude's in 23.84%, but neither executed them [2]. Downloading a script is not the same as running it.
Two exceptions in the same analysis: Google's Gemini uses Googlebot's infrastructure and so gets full rendering, and AppleBot renders JavaScript through a browser-based crawler [2].
The practical result is two audiences for the same page. Google sees the rendered page. GPTBot, ClaudeBot, PerplexityBot and most other AI crawlers see only the HTML the server sent. Content that exists only after JavaScript runs can rank in Google and still never be quoted by ChatGPT, Claude or Perplexity from their own crawls.
Vercel's measurement dates from December 2024, and crawler behavior can change. Test your own pages rather than assuming either way.
What is the difference between client-side and server-side rendering?
Client-side rendering builds the page in the visitor's browser with JavaScript, while server-side rendering builds the full HTML before it is sent. Google recommends server-side rendering, static rendering or hydration over workarounds [3].
| Approach | Where the HTML is built | What a non-rendering crawler sees |
|---|---|---|
| Client-side rendering | In the browser, by JavaScript | An almost empty page |
| Server-side rendering | On the server, for each request | The full content |
| Static rendering (pre-built) | Once, at build or deploy time | The full content |
| Hydration | Server sends full HTML, then JavaScript adds interactivity | The full content |
| Dynamic rendering | Server sends bots a pre-rendered copy and users the JavaScript app | The full content, via a separate copy Google calls a workaround [3] |
Search Insider's own site, searchinsider.io, is built with Astro and every page is pre-built as static HTML at deploy time and served from Cloudflare. No content on the site depends on JavaScript running, so the HTML a crawler downloads already contains the full article or glossary entry.
What JavaScript rendering problems hurt SEO?
The JavaScript rendering problems that most often hurt SEO are content, links and tags that only exist after scripts run. Common examples:
- Links that are not links. Google can generally only follow an
<a>element with anhrefattribute. Elements like<a onclick="goto(...)">or<span href="...">are not reliably followed [5]. - Noindex tags changed by JavaScript. When Google sees
noindexin the raw HTML, "it may skip rendering and JavaScript execution", so using JavaScript to remove a noindex tag "may not work as expected" [1]. - Canonical tags changed by JavaScript. Google says not to use JavaScript to change the canonical URL to something other than the one in the original HTML [1].
- Fragment URLs. Single-page apps that load views at
#/productsshould use the History API for routing instead [1][4]. - Soft 404s. A client-side app that shows "not found" with a 200 status creates a soft 404. Google suggests a JavaScript redirect to a URL that returns a real 404, or adding a noindex tag [1].
- Content behind interaction. Text that loads only after a click, scroll or login is not seen by crawlers that do not interact with the page.
How do you check if your content depends on JavaScript rendering?
To check if your content depends on JavaScript rendering, compare the raw HTML your server sends with the rendered HTML a browser builds. If a key sentence appears in the rendered version but not the raw one, crawlers that do not render JavaScript cannot see it.
A two-minute test:
- Raw HTML. Right-click the page and choose View Page Source (not Inspect). Search for a distinctive sentence from the main content, a product price and an internal link. View Page Source shows what the server sent, which is roughly what a non-rendering AI crawler receives.
- Rendered HTML for Google. In Search Console, run the URL Inspection tool, or use the Rich Results Test, and view the rendered HTML. Google says these tools show "loaded resources, JavaScript console output and exceptions, rendered DOM" [4].
- Compare. Content present in both is safe for every crawler. Content present only in step 2 is visible to Google and invisible to most AI crawlers.
From a command line, the same raw-HTML check is one line:
curl -s https://example.com/page | grep -c "a sentence from the page"A result of 0 means the sentence is not in the HTML the server sends.
How has JavaScript rendering for search changed?
Google has rendered JavaScript for years, and its guidance now steers sites away from workarounds and toward sending full HTML. The newer change is AI crawlers, which in the main do not render at all.
February 6, 2024: Google trims its JavaScript guidance
Google reviewed its JavaScript SEO basics, JavaScript troubleshooting and lazy-loading guidance on February 6, 2024, to "remove outdated or unnecessary information" [6]. Its dynamic rendering page now describes that technique as "a workaround and not a recommended solution" [3].
December 17, 2024: AI crawlers measured
Vercel published its analysis showing that the major AI crawlers from OpenAI, Anthropic, Meta, ByteDance and Perplexity did not execute JavaScript [2].
December 2025: noindex and canonical clarifications
On December 15, 2025, Google clarified how its crawler handles noindex tags on pages that use JavaScript, and on December 17, 2025, it added canonicalization best practices for JavaScript [6].
Should you avoid JavaScript for SEO?
No, JavaScript itself is not the problem; depending on JavaScript to deliver core content is. Google's own advice is that "server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript" [1].
A practical rule: main content, headings, internal links, title, meta description, canonical and robots tags should be in the HTML the server sends. JavaScript can then add interactivity on top. Vercel gives the same advice for AI visibility: prioritize server-side rendering for critical content [2]. Sites already on a client-side framework can usually switch on server-side or static rendering in the framework rather than rebuild.