JavaScript rendering
42 established claims - 2 refused by the grounding gate
No verdict
Nothing has been written for this subject that survived the grounding check, so nothing is asserted here. The claims below stand on their own.
Documented position13
What the operator of the system says in its own documentation.
Google Search Central's JavaScript SEO basics documentation states that Google processes JavaScript web apps in three main phases.
1 quote from 1 source
Google processes JavaScript web apps in three main phases:
Google Search Central's JavaScript SEO basics documentation states that Google Search runs JavaScript with an evergreen version of Chromium.
1 quote from 1 source
While Google Search runs JavaScript with an evergreen version of Chromium, there are a few things that you can optimize.
Google Search Central's JavaScript SEO basics documentation states that all pages with a 200 HTTP status code are sent to the rendering queue, no matter whether JavaScript is present on the page.
1 quote from 1 source
All pages with a 200 HTTP status code are sent to the rendering queue, no matter whether JavaScript is present on the page.
Google Search Central's JavaScript SEO basics documentation states that Googlebot queues all pages with a 200 HTTP status code for rendering, unless a robots meta tag or header tells Google not to index the page.
1 quote from 1 source
Googlebot queues all pages with a 200 HTTP status code for rendering, unless a robots meta tag or header tells Google not to index the page.
Google Search Central's JavaScript SEO basics documentation states that…
- a page may stay on the rendering queue for a few seconds but can take longer.
- once Google's resources allow, a headless Chromium renders the page and executes the JavaScript.
1 quote from 1 source
The page may stay on this queue for a few seconds, but it can take longer than that. Once Google's resources allow, a headless Chromium renders the page and executes the JavaScript.
Google Search Central's JavaScript SEO basics documentation states that…
- server-side or pre-rendering is still a great idea.
- server-side or pre-rendering makes your website faster for users and crawlers.
- not all bots can run JavaScript.
1 quote from 1 source
Keep in mind 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.
Google Search Central's JavaScript SEO basics documentation states that Google Search won't render JavaScript…
- from blocked files.
- on blocked pages.
1 quote from 1 source
If it marks the URL as disallowed, then Googlebot skips making an HTTP request to this URL and skips the URL. Google Search won't render JavaScript from blocked files or on blocked pages.
Google Search Central's JavaScript SEO basics documentation states that…
- Google's Web Rendering Service may ignore caching headers.
- ignoring caching headers may lead Google's Web Rendering Service to use outdated JavaScript or CSS resources.
1 quote from 1 source
Googlebot caches aggressively in order to reduce network requests and resource usage. WRS may ignore caching headers. This may lead WRS to use outdated JavaScript or CSS resources.
Measured finding23
Something someone actually measured, with the method attached.
Vercel's blog post on AI crawlers reports that its analysis found none of the major AI crawlers currently render JavaScript.
2 quotes from 1 source
Our analysis shows a clear divide in JavaScript rendering capabilities among AI crawlers. To validate our findings, we analyzed both Next.js applications and traditional web applications using different tech stacks.
The results consistently show that none of the major AI crawlers currently render JavaScript.
Vercel's blog post on AI crawlers reports, regarding JavaScript rendering, that…
- ChatGPT crawlers fetch JavaScript files at 11.50% of requests.
- Claude crawlers fetch JavaScript files at 23.84% of requests.
- ChatGPT and Claude crawlers do not execute JavaScript files.
- ChatGPT and Claude crawlers cannot read client-side rendered content.
1 quote from 1 source
The data indicates that while ChatGPT and Claude crawlers do fetch JavaScript files (ChatGPT: 11.50%, Claude: 23.84% of requests), they don't execute them. They can't read client-side rendered content.
- JavaScript rendering by AppleBot is performed through a browser-based crawler.
- The browser-based crawler used for JavaScript rendering by AppleBot is similar to Googlebot.
- JavaScript rendering by AppleBot processes JavaScript, CSS, Ajax requests and other resources needed for full-page rendering.
1 quote from 1 source
AppleBot renders JavaScript through a browser-based crawler, similar to Googlebot. It processes JavaScript, CSS, Ajax requests, and other resources needed for full-page rendering.
Vercel's blog post on AI crawlers reports that Google's Gemini leverages Googlebot's infrastructure, enabling full JavaScript rendering.
1 quote from 1 source
Google's Gemini leverages Googlebot's infrastructure, enabling full JavaScript rendering.
Vercel's blog post on how Google handles JavaScript reports that out of over 100,000 Googlebot fetches analyzed on nextjs.org, excluding status code errors and non-indexable pages, 100% of HTML pages resulted in full-page renders.
1 quote from 1 source
Out of over 100,000 Googlebot fetches analyzed on nextjs.org, excluding status code errors and non-indexable pages, 100% of HTML pages resulted in full-page renders, including pages with complex JS interactions.
The study described in Vercel's blog post on how Google handles JavaScript…
- used Vercel's infrastructure.
- used MERJ's Web Rendering Monitor technology.
- focused on nextjs.org.
- used supplemental data from monogram.io and basement.io.
- spanned from April 1 to April 30, 2024.
1 quote from 1 source
To investigate the following myths, we conducted a study using Vercel's infrastructure and MERJ's Web Rendering Monitor (WRM) technology. Our research focused on nextjs.org , with supplemental data from monogram.io and basement.io , spanning from April 1 to April 30, 2024.
Vercel's blog post on how Google handles JavaScript…
- reports a median (50th percentile) rendering delay of 10 seconds.
- measures the rendering delay as the time between Google's initial crawl of a page and its completion of rendering.
- uses data from over 37,000 matched server-beacon pairs on nextjs.org.
2 quotes from 1 source
Rendering delays: We examined the time difference between Google's initial crawl of a page and its completion of rendering, using data from over 37,000 matched server-beacon pairs on nextjs.org .
50th percentile (median): 10 seconds.
Vercel's blog post on how Google handles JavaScript reports that the 25th percentile of pages were rendered within 4 seconds of the initial crawl.
1 quote from 1 source
Surprisingly, the 25th percentile of pages were rendered within 4 seconds of the initial crawl, challenging the notion of a long "queue."
Vercel's blog post on how Google handles JavaScript reports that…
- pages with noindex meta tags in the initial HTML response were not rendered, regardless of JS content.
- client-side removal of noindex tags is not effective for SEO purposes.
1 quote from 1 source
Pages with noindex meta tags in the initial HTML response were not rendered, regardless of JS content. Client-side removal of noindex tags is not effective for SEO purposes; if a page contains the noindex tag in the initial HTML response, it won't be rendered, and the JavaScript that removes the tag won't be executed.
Vercel's blog post on how Google handles JavaScript reports finding no…
- significant difference in Google's success rate in rendering pages with varying levels of JavaScript complexity.
- correlation between JavaScript complexity and rendering delay at nextjs.org's scale.
1 quote from 1 source
We found no significant difference in Google's success rate in rendering pages with varying levels of JS complexity. At nextjs.org 's scale, we also found no correlation between JavaScript complexity and rendering delay. However, more complex JS on a much larger site can impact crawl efficiency .
Changed on3
A dated change. This is where advice quietly stops being true.
Google Search Central's dynamic rendering documentation…
- states that dynamic rendering was a workaround.
- states that dynamic rendering was not a long-term solution.
- recommends server-side rendering, static rendering, or hydration instead.
2 quotes from 1 source
Dynamic rendering was a workaround and not a long-term solution for problems with JavaScript-generated content in search engines.
Instead, we recommend that you use server-side rendering, static rendering, or hydration as a solution.
Echoed without a primary source3
Widely repeated in the field, but traceable only to other repetitions. Listed because knowing something is merely echoed is worth as much as knowing it is documented.
- Vercel's blog post on how Google handles JavaScript lists 'Google can't render client-side JavaScript' as one of a number of old beliefs.
- The old beliefs listed in Vercel's blog post on how Google handles JavaScript have stuck around.
- The old beliefs listed in Vercel's blog post on how Google handles JavaScript have kept the community unsure about best practices for application SEO.
2 quotes from 1 source
We've noticed that a number of old beliefs have stuck around and kept the community unsure about best practices for application SEO:
"Google can't render client-side JavaScript."
Refused2
Claims the research produced that the grounding gate would not accept, with its reason. They are here because a site that only shows what passed gives you no way to judge whether the gate does anything.
Show what was refused
According to Vercel's blog post on AI crawlers, JavaScript rendering's primary data comes from monitoring nextjs.org and the Vercel network.
Refused: The quote says 'Our primary data' but never links it to JavaScript rendering.
Unsupported: JavaScript rendering's primary data
What it rested on
Our primary data comes from monitoring nextjs.org and the Vercel network for the past few months. To validate our findings across different technology stacks, we also analyzed two job board websites: Resume Library , built with Next.js, and CV Library , which uses a custom monolithic framework.
According to Vercel's blog post on AI crawlers, JavaScript rendering's primary data is validated against two job board websites, Resume Library and CV Library.
Refused: The quote says primary data comes from nextjs.org and the Vercel network, while the two job board websites were analyzed to validate findings, not as the primary data source.
Unsupported: JavaScript rendering's primary data is validated against two job board websites
What it rested on
Our primary data comes from monitoring nextjs.org and the Vercel network for the past few months. To validate our findings across different technology stacks, we also analyzed two job board websites: Resume Library , built with Next.js, and CV Library , which uses a custom monolithic framework.