JavaScript SEO is the practice of making sure search engines and AI systems can find, render and understand pages that rely on JavaScript to load their content. If your site is built with React, Vue, Angular or a similar framework, it is the difference between a page Google can read and a page that looks empty to a crawler.
What is JavaScript SEO?
JavaScript SEO is a branch of technical SEO focused on how JavaScript affects crawling, rendering and indexing. It covers how content, links, URLs, status codes and meta tags look to a crawler.
The core question is simple: when a bot requests your URL, is the important content in the HTML response, or does it only appear after JavaScript runs in a browser? Everything else in JavaScript SEO flows from that answer.
Why JavaScript SEO matters
Google can render JavaScript, but rendering is an extra step. According to Google's JavaScript SEO basics, pages can sit in a rendering queue for a few seconds or longer before a headless Chromium browser processes them. If scripts fail, are blocked, or time out, Google may never see the content.
AI crawlers raise the stakes. A December 2024 analysis by Vercel found that the AI crawlers it studied from OpenAI, Anthropic, Perplexity and others did not render JavaScript (ChatGPT's and Claude's crawlers fetched JavaScript files but didn't execute them). The exceptions were Gemini, which uses Google's infrastructure, and AppleBot. That study is a snapshot and crawler behavior can change, but content that only exists after client-side rendering may be invisible to systems that power AI answers. If you care about being cited in AI search, your key content should be in the initial HTML.
How JavaScript SEO works
Google describes three phases for JavaScript pages: crawling, rendering and indexing.
Crawling
Googlebot requests the URL and reads the raw HTML response. It checks robots.txt rules and pulls out links from standard anchor elements that have an href attribute. Links built from click handlers on buttons or divs are not reliably discovered.
Rendering
Pages that return a 200 status are queued for rendering. Google's Web Rendering Service runs your JavaScript using an evergreen version of Chromium, then produces the rendered DOM (the final page structure after scripts run). Google won't render JavaScript from files or pages blocked by robots.txt.
Indexing
Google uses the rendered HTML to understand the page and decide whether to index it. Signals like titles, meta descriptions and canonical tags can be set or changed by JavaScript, but Google advises that a canonical set by JavaScript should match the one in the original HTML.
Rendering options: client-side, server-side and in between
How your site renders determines how much work a crawler has to do. The main options are:
- Client-side rendering (CSR): the server sends a mostly empty HTML shell and the browser builds the page. This is the riskiest setup for search and AI visibility.
- Server-side rendering (SSR): the server sends fully formed HTML for each request, then JavaScript takes over for interactivity.
- Static rendering (pre-rendering): HTML is generated at build time and served as files. Fast and very crawlable.
- Hydration: the server-rendered HTML is "brought to life" with JavaScript in the browser, so users get interactivity and bots get content.
Google once suggested dynamic rendering (serving bots a pre-rendered version and users a JavaScript version). Its current documentation calls dynamic rendering a workaround rather than a recommended solution, and points to server-side rendering, static rendering or hydration instead.
JavaScript SEO in practice
Picture a hypothetical online furniture store built as a single-page app. Product pages look great in a browser. But when you view the page source, the body holds a single empty div and a script tag. Product names, prices and descriptions arrive later through an API call.
Problems pile up. Category filters use # fragments, so Google treats many views as one URL. "Out of stock" pages show an error message while returning a 200 status, which Search Console flags as soft 404s. And an AI crawler that does not run JavaScript sees no product information at all.
Moving product and category templates to server-side rendering, switching to real URLs with the History API, and returning proper status codes for missing products would fix most of this without changing what shoppers see.
JavaScript SEO best practices
- Put critical content in the initial HTML. Use SSR or static rendering for pages you want ranked or cited. This helps users, Google and crawlers that skip JavaScript.
- Use real links. Navigation should use standard anchor links with an href pointing to crawlable URLs, which also supports healthy internal linking.
- Use the History API, not fragments. Google's docs discourage #/ style routing because Googlebot can't reliably resolve those URLs.
- Return meaningful status codes. For missing content in a single-page app, Google suggests either redirecting to a URL that returns a real 404 or adding a noindex robots meta tag to the error view.
- Don't rely on JavaScript to remove noindex. Google says it may skip rendering when it sees a noindex tag, so removing that tag with JavaScript may not work.
- Don't block resources. Make sure robots.txt allows the JavaScript and CSS files needed to render the page.
- Test the rendered result. Use the URL Inspection tool in Google Search Console and the Rich Results Test, as recommended in Google's JavaScript troubleshooting guide, to compare raw and rendered HTML.
Common JavaScript SEO mistakes
- Assuming "Google renders JavaScript" means no work is needed. Rendering can be delayed or fail, and other bots may not render at all.
- Content behind interactions. Text that only loads on click, scroll or a permission prompt may never be seen. Google notes Googlebot declines permission requests.
- Conflicting canonicals. One canonical in the HTML and a different one injected by JavaScript sends mixed signals.
How Butter approaches JavaScript SEO
At Butter, JavaScript issues usually surface during technical reviews, when a page that looks fine to people shows thin or missing content in the raw HTML. Our first check is simple: what does a crawler get before any script runs? Because our GEO work is about earning visibility in AI answers, we pay close attention to that initial HTML, since some AI crawlers may never execute your scripts.
On our GEO+SEO plan, technical fixes like crawl issues and broken links are part of the monthly work, and we flag rendering problems in our on-page recommendations. Larger changes, like moving a framework to server-side rendering, are a developer project. In those cases we explain the problem clearly and help your team prioritize the templates that matter most.
Frequently asked questions
Can Google index JavaScript content?
Yes. Google renders pages with an evergreen version of Chromium and can index content added by JavaScript. Rendering happens in a queue, though, and can fail if scripts error out or are blocked. Server-side or static rendering removes that risk.
Do AI crawlers run JavaScript?
Many don't. A December 2024 Vercel analysis found that AI crawlers from OpenAI, Anthropic and Perplexity did not execute JavaScript, while Gemini (via Google's infrastructure) and AppleBot could render it. Behavior may have changed since. The safest approach is to put important content in the initial HTML.
Is dynamic rendering still recommended?
No. Google describes dynamic rendering as a workaround, not a recommended long-term solution. It suggests server-side rendering, static rendering or hydration instead.
How do I check what Google sees on a JavaScript page?
Use the URL Inspection tool in Google Search Console to view the rendered HTML, loaded resources and JavaScript errors. The Rich Results Test also shows rendered HTML for any public URL.