JavaScript SEO: Can Search Engines Read Your Site?

TL;DR Here is the short version of JavaScript SEO. Google renders JavaScript, and usually within minutes, not days. The risk is not that Google cannot run your code. It is content that only exists after a client-side render, and AI crawlers that often do not run JavaScript at all. The fix is simple to state: server-render anything that matters for search, so it is in the HTML before any script runs.

Is your JavaScript site invisible to crawlers?

It is a fair worry, and the new AI crawlers make it sharper. You have built a fast, modern site in React, Angular or Vue, and now you are wondering whether Googlebot, ChatGPT and Perplexity can actually see your content. That is the question JavaScript SEO answers.

The short answer is reassuring, and the detail matters. Google reads JavaScript well. Many AI crawlers do not. So the way you render your content decides whether it gets indexed and cited, or quietly skipped. Here is how rendering works, where JavaScript SEO usually breaks, and what to do about it.

Can Google read JavaScript?

Yes, and it is worth understanding how, because the myth that Google cannot handle JavaScript is years out of date.

Google processes a page in three phases. First it crawls, fetching the raw HTML. Then it renders, running the page's JavaScript in a headless browser to build the final content. Then it indexes what the render produced. The key point: Googlebot renders with an evergreen version of Chromium, the same engine behind Chrome, kept current. If your site works in a recent Chrome, Googlebot can almost certainly render it.

The data backs this up. A study by MERJ and Vercel looked at more than 100,000 Googlebot fetches. Effectively every HTML page that returned a 200 status was rendered. The old idea of a multi-day render queue did not hold: the median delay between crawl and render was around 10 seconds. The spread mattered at the tail. The 75th percentile was still in the seconds, but the 99th percentile stretched to roughly 18 hours. So for the vast majority of pages, rendering is quick and reliable. For a small slice, it is slow. Either way, "Google cannot read my JavaScript" is rarely the real problem.

Two clarifications keep this honest. Rendering is not free: Google spends real resources running your JavaScript, so a heavy, slow site can be crawled and rendered less often than a light one. And rendering only helps if the JavaScript Google runs actually produces the content. If your content needs a user action first, a click, a scroll, a login, the render will not trigger it, and that content stays invisible no matter how well Google handles JavaScript.

Where JavaScript SEO actually breaks

If Google can render JavaScript, why do JS sites still lose rankings? Because of how they are built, not whether they use JavaScript. These are the failure modes that actually cost you.

• Content that only exists after a client-side render. If your main content is fetched and injected by JavaScript after load, you are betting on the render step every time. When it is slow or fails, the page indexes thin or empty.
• Links that are not real anchor tags. Google follows real anchor links. A div with an onclick handler is not a link Google can crawl. If your navigation is built from click handlers, crawlers cannot follow it.
• A noindex tag in the initial HTML. If your page ships with noindex and removes it with JavaScript later, it does not work. Google often acts on the noindex in the raw HTML before the render removes it.
• JavaScript and CSS blocked in robots.txt. If you block the resources Google needs to render the page, it cannot build the final content. Keep your scripts and styles crawlable.
• Soft 404s in single-page apps. When a missing page returns a 200 status with an empty not-found view, Google sees a thin page, not an error. Return real status codes.
• Fragment-based routing. URLs that use hash fragments to change content are not treated as separate pages. Use the History API so each view has a real, crawlable URL.

The pattern under all of these is the same: the content or signal Google needs is not in the HTML at the moment it matters. Sometimes it arrives late, sometimes never, sometimes the render contradicts the raw response. Fixing JavaScript SEO is mostly about making sure the important things are present and correct in the initial response, before any of the uncertainty kicks in.

Get these wrong and even a site Google can render will underperform. This is the section worth handing to your developer.

Rendering strategies compared

How you render decides what crawlers receive. Frameworks like React, Angular and Vue all support these strategies; the strategy matters more than the framework. Four common options, scored for search:

Strategy	Crawl efficiency	Discovery	Rendering reliability	Speed	Best for
SSR (server-side rendering)	High	High	High	Good	Dynamic pages that need to rank
SSG (static generation)	High	High	High	Excellent	Content that rarely changes
ISR (incremental static regeneration)	High	High	High	Excellent	Large sites with changing content
CSR (client-side rendering)	Low	Low	Low	Poor first load	App screens behind login

Read the table as a risk gradient. SSR and SSG put content in the HTML, so crawlers and AI bots get it whether or not they run JavaScript. CSR pushes all the work to the browser, which is fine for a logged-in app and a gamble for anything you want found.

The takeaway is simple. Use SSR or SSG, or ISR for scale, for any page that needs organic traffic or AI citations. Save CSR for app screens where search does not matter, like a logged-in dashboard. The Next.js SEO guide covers how to apply these in practice.

Can AI search crawlers render JavaScript?

This is the live question, and it deserves an honest answer rather than a confident one.

Google AI Overviews draw on Google's existing index, and that index is built from rendered pages. So content Google can render can show up in AI Overviews. That part is reasonably safe to say.

Standalone AI crawlers are a different story. Many of the bots behind AI assistants fetch raw HTML and do not run JavaScript the way Googlebot does. Their behaviour changes, and no one should claim to know exactly what each one executes on any given day. But the pattern is clear enough: if your content only appears after a client-side render, you are taking a real risk that a chunk of AI crawlers never see it.

There is an easy way to see the gap yourself. Open your page, disable JavaScript in the browser, and reload. Whatever disappears is roughly what a non-rendering AI crawler also misses. If your headline, body and key links survive, you are in good shape. If the page goes blank, that is your warning.

So the safe conclusion does not depend on any single bot. Server-render the content that matters into the initial HTML. Then it is visible to Googlebot, to AI crawlers that render, and to the many that do not. You stop guessing about crawler behaviour and make the question moot.

A practical JavaScript SEO checklist

A list you can hand to a developer:

• Server-render critical content and metadata so it is in the initial HTML.
• Use real anchor links for navigation.
• Return meaningful HTTP status codes: real 404s, 301s and 200s.
• Use the History API for routing, not hash fragments.
• Set the canonical tag in the HTML, not via JavaScript.
• Never rely on client-side removal of a noindex tag.
• Keep JavaScript and CSS resources crawlable in robots.txt.
• Ship XML sitemaps with accurate lastmod dates.

None of this needs exotic tooling. Most of it is decided when a developer picks a rendering strategy and wires up routing and status codes. Get those defaults right at the start and JavaScript SEO stops being a recurring fire and becomes a one-time setup.

Run through it and most JavaScript SEO problems disappear before they start.

The real problem is the build

The problem is rarely that Google cannot read JavaScript. Google reads it well. The problem is almost always how the site is built: content trapped behind a client render, broken links, blocked resources, the wrong rendering strategy. Fix the build and the rankings follow.

It is also cheaper to prevent than to fix. Retrofitting server rendering onto a large client-side app is real work. Choosing the right rendering strategy on day one costs nothing extra. If you are starting a new build, that is the decision to get right before you write a line of feature code.

If you are not sure what Google and AI crawlers actually see when they hit your site, we can check. We will test how your pages render, find what is getting skipped, and give you a fix list. Building on Webflow or a code stack? Our Webflow vs Vercel SEO guide comparison and the WebMCP guide are good next reads.

Frequently asked questions

Can Google read and index JavaScript?

Yes. Googlebot crawls the HTML, renders the page with an evergreen Chromium, then indexes the result. In a large study of Googlebot fetches, effectively all HTML pages were rendered, with a median delay of about 10 seconds. JavaScript itself is not the barrier.

Why is my JavaScript content not showing up in Google?

Usually because of how the site is built, not the language. Common causes: content only injected after a client-side render, links that are not real anchor tags, a noindex in the initial HTML, blocked JS or CSS in robots.txt, or soft 404s in a single-page app. Fix those and indexing improves.

Do AI search engines like ChatGPT and Perplexity render JavaScript?

Often not. Google AI Overviews use Google's index, which does render JavaScript. Many standalone AI crawlers fetch raw HTML and do not execute JavaScript the way Googlebot does. The safe move is to server-render content into the initial HTML so every crawler can read it.

Is server-side rendering necessary for SEO?

Not strictly for Google, which renders most pages fine. But it is the safest choice for pages that need organic traffic or AI citations, because it puts content in the HTML for every crawler, including the ones that do not run JavaScript. Use SSR or SSG for anything that needs to be found.

What is the difference between SSR, SSG and CSR for SEO?

SSR renders pages on the server per request. SSG renders them at build time into static files. Both deliver fully formed HTML, which is ideal for search. CSR renders in the browser after load, which is risky for SEO because crawlers may not run the JavaScript. Use server or static rendering for pages that need to rank.

How do I check what Google sees on my JavaScript page?

Use the URL Inspection tool in Google Search Console to view the rendered HTML and a screenshot of what Googlebot built. Compare it to your raw page source, not the inspector, since the inspector shows the rendered DOM. Quicker still: disable JavaScript and reload the page. Whatever is missing from the source or vanishes without JavaScript is content that depends on rendering, which is the risk to fix.

Is React or Next.js bad for SEO?

No. React is fine when you render it on the server. Next.js is built for exactly that, with SSR, SSG and Server Components that hand crawlers rendered HTML. Problems come from client-only rendering, not from the framework. In short, the framework is not the issue, how you render it is. See our Next.js SEO guide for the details.