Does JavaScript affect SEO? Less than the received wisdom says, and in different ways. The long-standing advice was that Google struggles to render JavaScript and that client-rendered content may never be seen. The best recent evidence says Google renders everything it fetches. What JavaScript changes is when content is seen, and which signals Google acts on before rendering happens at all.
What the study measured
In July 2024 Vercel published how Google handles JavaScript throughout the indexing process, an analysis of over 100,000 Googlebot fetches, mainly on nextjs.org. It matched over 37,000 rendered pages with server beacons, which let it see not just that Googlebot requested a page but when the page was actually rendered.
The headline finding is unambiguous: “100% of HTML pages resulted in full-page renders, including pages with complex JS interactions.” On that site, at least, Google did not skip rendering for heavy pages or give up partway through. The idea that JavaScript content is invisible to Google does not survive this data.
It helps to be clear about what “rendering” means here. Googlebot first fetches the raw HTML your server returns. Anything in that response, including text, links, titles and meta tags, is available straight away. Rendering is the later step, where Google runs the page’s scripts in a headless browser and reads the resulting page. Content that exists only after scripts run is content Google learns about at the render, not at the crawl.
That distinction is what JavaScript SEO is really about. It is not a question of whether Google can execute your framework. It is a question of which parts of your page arrive in the first response and which have to wait. A server-rendered page and a client-rendered page can look identical in a browser and still differ completely in what Google sees first.
The real cost: rendering delay
Full rendering is not instant rendering. Vercel measured the gap between Googlebot’s crawl and the render, and the distribution has a long tail.
| Percentile | Time from crawl to render |
|---|---|
| Median (50th) | 10 seconds |
| 75th | 26 seconds |
| 90th | About 3 hours |
| 95th | About 6 hours |
| 99th | About 18 hours |
For most pages the delay is seconds and does not matter. For the slowest tenth it runs to hours. If a page depends on JavaScript to show its main content, its links or its title, those elements wait in that queue. For a news story, a price change or a page you need indexed quickly, a delay of hours can matter a good deal.
The URL Inspection tool in Search Console shows the rendered HTML and a screenshot of how Google sees a page, which is the quickest way to check that client-side content appears at all. It cannot show you how long a given page sat in the rendering queue, which is why the timing data above is useful context rather than something you can measure for your own pages directly.
Rules JavaScript cannot override
The most practical finding concerns noindex. Vercel found that “pages with noindex meta tags in the initial HTML response were not rendered.” Google reads the directive in the first response and stops there. A script that removes the tag later never runs as far as Google is concerned.
This catches out sites that ship a default noindex and lift it client-side once data loads, or that use JavaScript to decide whether a page should be indexable. The decision has to be in the server response. If pages are disappearing from the index for this reason, our guide to the excluded by noindex tag report covers how to find them.
Blocked resources are the second trap. If robots.txt blocks the scripts or API endpoints a page needs to render, Google renders a broken version. Vercel’s recommendation is simple: do not block resources Google needs. Our guide to robots.txt for SEO covers how to check what you are disallowing.
JavaScript SEO best practices
Vercel’s recommendations come down to putting the important things where Google sees them first.
- Render critical SEO elements on the server. Titles, meta tags, canonical tags, main content and internal links should come from server-side rendering or static generation, not from client-side scripts.
- Keep indexing directives in the initial HTML. Never rely on JavaScript to add or remove noindex.
- Do not block rendering resources. Check robots.txt against the scripts and data your pages load.
- Keep sitemaps updated. They help Google discover pages without depending on links that only appear after rendering.
None of this means abandoning JavaScript frameworks. Most modern frameworks support server-side rendering or static generation out of the box, and the interactive parts of a page can still run in the browser. The goal is narrower: make sure the parts Google needs to understand and index the page are already present in the HTML your server sends, and let scripts add everything else.
Lazy loading deserves a note. Content and images that load only on scroll or on a click rely on Google’s renderer behaving like a user. Loading content as it enters the viewport is generally safe; content that appears only after an interaction may never be triggered. When in doubt, check the rendered HTML rather than assuming.
A simple test is to load the page with JavaScript switched off in your browser. Whatever disappears is content that depends on rendering. That does not mean Google will miss it, but it tells you exactly which elements are exposed to the delay, and whether any of them are ones you cannot afford to have indexed late.
Where the evidence runs out
The limitation is scope. This is one site’s data, and that site is built on Next.js by the company that makes it, with fast servers and well-structured pages. A slower site, a heavier application or a site Google considers less important may see different timing. The 100% render finding is strong evidence about Google’s capability, not a guarantee about any particular page.
It also says nothing about other crawlers. Other search engines and the crawlers behind AI assistants may not render JavaScript the way Google does, and some may not render it at all. If you want your pages read by those systems, server-rendered content is the safe assumption. Our guide on how to rank in ChatGPT covers what those crawlers can access.
So the honest answer is that JavaScript does not stop Google from seeing your content. It can delay it, it cannot override what your first response says, and it may hide your content from crawlers other than Google. Server-rendering the elements that matter removes all three risks at once.
Frequently asked questions
Does JavaScript affect SEO?
It can delay when Google sees content, and indexing directives in the initial HTML are final. In Vercel’s study Google fully rendered every HTML page it fetched.
How long does Google take to render JavaScript?
In Vercel’s study the median was 10 seconds, but the 90th percentile was about 3 hours and the 99th about 18 hours.
Can I remove a noindex tag with JavaScript?
No. Vercel found pages with noindex in the initial HTML response were not rendered, so a script removing it never runs for Google.
Do AI crawlers render JavaScript?
Not necessarily in the way Google does. Server-rendered content is the safer assumption for crawlers other than Googlebot.
The takeaway Google renders JavaScript, but on its own schedule and only after reading your initial HTML. Put titles, content, links and indexing rules in the server response.
