# Does Google Index JavaScript? Impact of JavaScript Rendering Updated September 5, 2025 When you’re evaluating a website from a technical SEO perspective, the first question is still the same as it’s always been: **what’s actually indexed?** At the most basic level, you need to establish: 1. Are the pages that should be indexed actually showing up in the index? 2. Are the pages that shouldn’t be indexed being correctly excluded? Indexing is tightly bound up with crawling. Googlebot requests a page, parses what it finds, pulls out links for the crawl queue, and keeps going. Simple enough. But in 2025, that process doesn’t stop at raw HTML. **Google now routinely renders pages with headless Chromium** before deciding what to index. This extra rendering step means JavaScript can completely change what Google ends up seeing; titles, canonicals, meta tags, links, even the page copy itself. And it’s not just Google you need to think about. **Most LLM crawlers and AI-powered search tools also don’t execute JavaScript**; they consume whatever is in your raw HTML. (Learn more about this in [our free JavaScript SEO training course](/content/javascript-seo-training/ "JavaScript SEO Training Course"/index.html).) If your key content only appears post-render, not only might this be slowing down indexing in search engines, but it might also be inaccessible to some LLM crawlers. So the real question isn’t just “does Google index JavaScript?” The answer is yes, mostly. The better question is: **how does JavaScript rendering impact indexing, and when can it break your expectations?** That’s what this article will unpack. Interested in learning about JavaScript SEO? Register for our free on-demand training. [Sign up now](/content/javascript-seo-training/index.html). ## Table of contents You can jump to a specific area of the guide using the jumplinks below: - [What is browser rendering?](/content/resources/guides/how-javascript-rendering-affects-google-indexing/#what-is-browser-rendering/index.html) - [Does Google index JavaScript?](/content/resources/guides/how-javascript-rendering-affects-google-indexing/#does-google-index-javascript/index.html) - [The evolution of crawling](/content/resources/guides/how-javascript-rendering-affects-google-indexing/#the-evolution-of-crawling/index.html) - [How Googlebot handles rendering](/content/resources/guides/how-javascript-rendering-affects-google-indexing/#how-googlebot-handles-rendering/index.html) - [Why is using a Chromium based crawler important?](/content/resources/guides/how-javascript-rendering-affects-google-indexing/#why-is-using-a-chromium-based-crawler-important/index.html) - [How to compare response vs render](/content/resources/guides/how-javascript-rendering-affects-google-indexing/#how-to-compare-response-vs-render/index.html) - [Why you need to investigate this stuff](/content/resources/guides/how-javascript-rendering-affects-google-indexing/#why-you-need-to-investigate-this-stuff/index.html) ## What is browser rendering? In SEO we talk about rendering as shorthand for browser rendering, which is the process of taking code (HTML, CSS, JS) and turning it into the visual page you see on screen. Search engines do the same thing at scale with a headless browser, which runs without a user interface. It executes scripts, builds the DOM, and then hands back the rendered HTML for indexing. ## Does Google index JavaScript? Since Chrome 59 (2017), Chromium has included Headless Chrome, which allowed Googlebot to render web pages at scale; and [website crawling tools](/content/features/index.html) (like Sitebulb) to mimic the same. So yes: **Google does index JavaScript content.** But, as we discussed in our [Real-World JavaScript Problems webinar](/content/resources/guides/webinar-recording-real-world-javascript-seo-problems/index.html), it’s not that simple. Indexing depends on resource availability, render queue delays, and whether your scripts block or mutate important elements. As Google’s own docs explain: “Googlebot queues all pages for rendering, unless a robots meta tag or header tells Google not to index the page.” In practice: noindex = no render. And even when a page is rendered, the indexed content may not look the way you expect. ## The evolution of crawling Back in the day, Googlebot just parsed the HTML it got from the server (what you see when you hit 'View Source'). Straightforward. But as sites became increasingly JavaScript-heavy, this broke down. Scripts can rewrite titles, inject or remove links, and replace entire content blocks. What’s in the response HTML may look nothing like the final rendered DOM. That’s why Google now cares far more about the rendered HTML than the raw response when making indexing decisions. ### How to view rendered HTML - View Source = raw response HTML (pre-JavaScript). - Inspect → Elements in Chrome = rendered DOM (post-JavaScript). If you are unsure what a 'DOM' is or are unfamiliar with the phrase, then a bit of additional reading might help: - [What is the DOM?](https://www.geeksforgeeks.org/dom-document-object-model/) - [Core Principles of SEO for JavaScript](https://www.briggsby.com/dealing-with-javascript-for-seo)(a bit old now but still relevant and a really good primer for understanding how it all breaks down) - [How the browser renders a web page?](https://developer.mozilla.org/en-US/docs/Web/Performance/How_browsers_work) ### Differences between response and rendered HTML If you want to know what Google actually sees, use Search Console: - Go to URL Inspection - Click Test live URL - Then View tested page → HTML tab This shows you the rendered HTML Googlebot processed. ## How Googlebot handles rendering Here’s the workflow simplified: 1. URL picked from crawl queue. 2. Robots.txt checked. 3. HTTP status checked. 4. Response HTML parsed; robots tags and href links extracted. 5. In parallel: - Links from response HTML queued. - URL queued for rendering → headless Chromium executes JS → rendered HTML parsed. 6. Rendered HTML processed, links extracted, content indexed. ## Why is using a Chromium based crawler important? Because rendering is slower and resource-heavy, it is often an optional setting on many SEO crawlers, with some even charging extra for rendering. But understanding whether your website renders content with JavaScript and using the correct crawling settings is fundamental to accurate auditing. If you only ever crawl response HTML, you risk missing: - Titles rewritten in JS - Canonicals changed post-load - Meta robots flipped from index to noindex - Links injected or removed ### There are 3 types of websites You can roughly bucket sites like this: 1. No JavaScript: Rendered HTML = Response HTML (e.g. Sitebulb’s own site). 2. Key content inserted with JavaScript: Rendered HTML ≠ Response HTML (e.g. React SPAs). 3. Some elements changed by JavaScript: Mostly the same, but JS changes key elements (the dangerous middle). ### What content does JavaScript change? Here are some of the page elements that may be deleted, created, or modified by JavaScript: - Meta robots - Canonicals - Titles - Meta Descriptions - Internal Links - External Links ## How to compare response vs render Sam Torres wrote an excellent guide on [how to audit JavaScript for SEO](/content/resources/guides/how-to-do-a-javascript-audit-for-seo/index.html). Best practice is to compare the response HTML with the rendered HTML. ## Why you need to investigate this stuff [Google’s Martin Splitt once suggested](https://x.com/g33konaut/status/1244547109686333440?s=20 "x.com") SEOs should “just assume your pages get rendered and get on with it.” As far as I can see, to _"assume my pages get rendered and get on with it"_ is to fundamentally misunderstand the purpose of an SEO. It's our job to **not** _"just assume and get on with it"_. It's our job to not accept things on blind faith, but to dig and explore and investigate; to test and experiment and verify for ourselves. ## TL;DR - Google does index JavaScript content, but only after rendering, and not always consistently. - noindex pages aren’t rendered for indexing: noindex ⇒ no render. - Always compare response vs rendered HTML for titles, canonicals, robots, and links. - Use Search Console → URL Inspection → Test live URL → View tested page to see Google’s rendered HTML.