Does Google Index JavaScript? How Rendering and Indexing Work

"Does Google index JavaScript?" is the wrong question if you stop at yes or no. Google does index JavaScript-generated content, but how and when it does explains nearly every "my page is crawled but not indexed" mystery on modern sites. This is the 2026 reference guide to how JavaScript rendering and indexing actually work, and what to do about it.

Does Google index JavaScript?

Yes, Google indexes JavaScript-generated content, but it does so in three stages rather than all at once:

1. Crawl. Googlebot downloads the raw HTML your server returns and indexes what is already there.
2. Render. The page enters the render queue, where Google's Web Rendering Service (WRS) runs your JavaScript in a headless, evergreen version of Chromium.
3. Index. Only after that render finishes does the JavaScript-generated content become indexable.

This is the model Google's own JavaScript SEO documentation describes as crawling, rendering, and indexing. Because "all pages with a 200 HTTP status code are sent to the rendering queue," every page waits for that second stage before its scripted content counts. Google runs the render with an evergreen version of Chromium, meaning it tracks current stable Chrome, a setup it has used since 2019 that closes most of the gap with a real browser. So capability is not the issue. The issue is that anything depending on the render stage, your main content, internal links, even your title tag, is indexed later than the static HTML, and only if the render succeeds.

Can Google read JavaScript?

Yes. Google can read and execute JavaScript: its Web Rendering Service runs each page in a headless, evergreen version of Chromium, so client-side content is not invisible to it the way it was a decade ago. But reading is not the same as indexing at crawl time. Because Google executes your JavaScript in the separate render stage above, any content, link, or tag that only exists after the script runs is read and indexed on a delay, not the moment Googlebot first fetches the URL. "Can Google read it" is rarely the real problem on a modern site. "How long until the rendered version is indexed, and does the render succeed" is.

How does the JavaScript render queue work?

Three systems do the work in sequence: Googlebot crawls the URL, Google's Web Rendering Service (WRS) renders it, and Google's indexing system stores the result. The gap between crawling and rendering is the render queue. When Googlebot crawls a URL, it immediately indexes whatever is in the raw HTML, then places the page in the queue for WRS to render. Google's docs note a page "may stay on this queue for a few seconds, but it can take longer than that." Rendering also draws on limited resources, so on very large sites a constrained rendering and crawl budget pushes JavaScript pages further back in line. This is the origin of the widely cited "two waves of indexing" model from Google I/O 2018: the first wave indexes the server HTML, and a second wave indexes the rendered content once the queue clears. The practical consequence is that discovery of links buried inside JavaScript is slower. An Onely experiment found Googlebot took roughly 9 times longer to follow a JavaScript-injected link than a plain HTML link, and the gap widened deeper into the site. If your navigation and internal links only exist after rendering, your whole site is crawled more slowly.

How long does Google take to render JavaScript?

The median render is fast, but the slow tail is measured in hours. The strongest current data comes from a 2024 study by Vercel and MERJ analyzing more than 37,000 matched crawl-and-render pairs:

Percentile	Time from crawl to render
25th	about 4 seconds
50th (median)	about 10 seconds
75th	about 26 seconds
90th	about 3 hours
95th	about 6 hours
99th	about 18 hours

For most pages, JavaScript is rendered almost immediately, which is why many JS sites index fine. The risk lives in the long tail: the slowest 10% of pages wait hours, and any rendering error during that window can drop the content entirely. The same study found Google fully rendered 100% of pages returning a 200 status regardless of JavaScript complexity, so when JS content fails to index, the cause is almost always a specific, fixable problem rather than Google's inability to render.

What stops Google from indexing JavaScript content?

When JavaScript content does not get indexed, it is usually one of a few concrete failures, not a general rendering limit:

• JavaScript blocked in robots.txt. Google's docs are explicit: "Google Search won't render JavaScript from blocked files or blocked pages." A single disallowed script directory can strip your content.
• Hash-based routing. URLs built with # fragments are not crawled as separate pages. Google's guidance is to use the History API so routes are real, crawlable URLs.
• Soft 404s. A JavaScript route that shows "not found" but returns HTTP 200 looks like a thin real page. Return a genuine 404 status or a noindex.
• A noindex you try to strip with JS. Google's docs warn that when it sees noindex in the raw HTML, "it may skip rendering," so removing the tag later with JavaScript does not work.
• Critical tags injected by JavaScript. A title, canonical, or robots tag that only appears after rendering is read late and can be missed if the render fails. Set title, canonical, and especially noindex in the server HTML so they are reliable on the first pass.
• Rendering that errors or times out. Hydration mismatches, render-blocking scripts, or content that loads too slowly can leave the rendered DOM incomplete.

These are also the same patterns that land pages in crawled but not indexed.

How do I stop Google from indexing a JavaScript page?

If your goal is the opposite, keeping a page out of the index, put the block in the raw HTML, not in JavaScript. Add a noindex robots meta tag or an X-Robots-Tag HTTP header in the initial server response. Google's docs warn that when it sees noindex in the raw HTML it may skip rendering entirely, so a noindex you inject with client-side JavaScript is unreliable: Google may index the page before your script ever runs. To keep a page out completely, set noindex server-side and remove internal links pointing to it. Do not rely on a robots.txt Disallow alone, because a blocked URL can still be indexed without its content if other pages link to it.

Do Bing and AI search engines render JavaScript?

No, not reliably, and this is where the stakes changed in 2026. Bing says it can process JavaScript but warns of "limitations to processing JavaScript at scale" and still recommends dynamic rendering. The bigger shift is AI search: Vercel's 2024 analysis found that none of the major AI crawlers behind ChatGPT, Claude, and Perplexity execute JavaScript at all (Google's Gemini is the exception, since it uses Googlebot's renderer). So client-rendered content can be entirely absent from AI answer engines even when classic Googlebot eventually renders it. For the full breakdown of which AI crawlers run JavaScript and the exact numbers, see do AI crawlers render JavaScript.

How do I check whether my content is rendered or in the HTML?

Compare the raw HTML to the rendered DOM, because the difference tells you exactly what is at risk. The fastest manual check: open the page, view source, and search for a sentence of your main content. If it is there, every crawler can see it. If the content only appears in your browser's DevTools "Elements" panel but not in view source, it is client-rendered and depends on the render queue, which AI crawlers will never run. To see what Google specifically got, use the URL Inspection tool in Search Console, run "Test Live URL," then "View Crawled Page" to inspect the rendered HTML. The durable fix is to put critical content in the server response using server-side rendering, static rendering, or incremental regeneration. Note that Google has deprecated dynamic rendering, calling it "a workaround and not a long-term solution." For a framework-specific walkthrough, see why React and Next.js pages don't get indexed.

Keeping JavaScript pages indexed over time

Even a correctly rendered page is not indexed forever. A framework upgrade, a new client-only component, or a slow third-party script can quietly move content out of the HTML on the next deploy, and you usually discover it from a traffic drop weeks later. SearchOptimo re-checks the index status of every URL on a schedule and alerts you the moment a page falls out, so a rendering regression shows up in a dashboard instead of in your analytics.

If you run a JavaScript-heavy site, see whether SearchOptimo is worth it for your case, or start free and watch your own URLs.