Google can run your JavaScript, but that doesn't guarantee it sees the same page your visitors do. When the two versions differ, pages drop out of the index, links go undiscovered, and AI search tools read an almost empty shell.
This guide covers how Google's crawl, render and index steps treat JavaScript, where sites lose content along the way, and how to test your own pages. It also covers what other crawlers, including those feeding AI answers, do with the same code. If you need the groundwork first, start with our explainer on what SEO is.
Short answer: Google fetches the raw HTML, queues pages that return a 200 status for rendering, runs them in headless Chromium, and indexes the rendered result. Content, links and directives present in the raw HTML are the safest. Rendered-only content usually works in Google but arrives later and can fail quietly. None of the major AI crawlers Vercel tested (OpenAI, Anthropic, Meta, Perplexity) render JavaScript at all.
How Google processes a JavaScript page
JavaScript SEO is the work of making sure the content, links and indexing signals your scripts produce can be found, rendered and indexed. Rendering here means running a page's code to build the version a browser shows, instead of reading the bare HTML the server sent.
Google splits the job into three phases: crawling, rendering and indexing, with a queue in front of both crawling and rendering. The official JavaScript SEO basics describe the sequence.
Rendering is not part of the first fetch. Pages wait in a rendering queue, and Google says the wait may be a few seconds or considerably longer. That ordering explains most JavaScript SEO trouble, because the raw response gets judged first.
A page returning anything other than a 200 may never be rendered. Google added a note to that effect in its documentation in December 2025, as Search Engine Land reported. Vercel and MERJ's testing (linked in the statistics table below) also found that a no index tag in the initial HTML stays in force even if your script removes it later, because the page is never rendered and the script never runs.
Canonicals are read before and after rendering. Google's advice is to set the canonical in the raw HTML to the URL your script will end up with, or to leave it out of the raw HTML if JavaScript has to set it, according to Search Engine Journal's coverage of the update.
Rendering is also stateless. Googlebot loads each page in a fresh session and generally doesn't click tabs or dismiss cookie banners, so text that only exists after an interaction is text Google probably never sees.
Where JavaScript sites lose visibility
Most failures come from a short list of causes, and they tend to arrive together. Picture a property developer whose project pages pull unit availability, pricing and floor plans from an API after load. In a browser the page looks complete. In the raw HTML there's a heading and an empty container.
Lazy loading deserves its own warning because it's usually added with good intentions, for speed. Images and sections that load as they approach the viewport are fine. Content that waits for a user gesture isn't. Google's lazy-loading guidance covers the patterns that work, and each one is worth testing rather than assuming.
Rendering usually works, which is exactly why the failures go unnoticed: nothing looks broken in the browser.
Choosing a rendering approach
The main patterns are laid out in web.dev's guide to rendering on the web. For search, what matters is where the content first appears: in the server's response, or only after the browser runs code.
The Google ratings summarise a comparison published by Vercel, a hosting vendor with a stake in server rendering, so read them as directional. Google's own position points the same way: it calls dynamic rendering a workaround rather than a long-term solution and recommends server-side rendering, static rendering or hydration instead, per Search Engine Land.
For lead-generation and local business sites, static or server rendering is the sensible default for anything public. That content rarely needs per-visitor computation, and the same HTML then serves Google and AI crawlers alike. Logged-in application screens can stay client-rendered, since nothing there needs to rank, and hybrids are common. Search Engine Land's 2026 review of no-JavaScript fallbacks lands in a similar place: blanket fallbacks aren't universally required, but critical content, links and signals shouldn't depend entirely on JavaScript.
Scale changes the calculation. Vercel and MERJ note that on sites with more than 10,000 unique, frequently changing pages, the extra cost of rendering can affect crawl budget. Google's crawl budget documentation helps you check whether you're in that group. Most small business sites sit far below it.
Testing what Google, and everyone else, actually sees
Compare view-source with the rendered page. View-source shows the raw HTML. The Elements panel in Chrome DevTools shows the page after scripts run. Anything present in the second but missing from the first depends on rendering.
Run key URLs through Google's own tools. The URL Inspection tool and the Rich Results Test let you verify how Googlebot sees a page. Check that text, links and JSON-LD survived.
Crawl twice. Screaming Frog and Sitebulb can crawl with JavaScript rendering on or off, and rendering is often an optional, slower setting. Compare titles, canonicals, word counts and link counts between the two runs. Big gaps show which templates to fix first.
Fetch the page without scripts. Disable JavaScript in DevTools or request the URL with curl. URL Inspection shows only Googlebot's view, so this is your closest approximation of what script-skipping crawlers receive.
Read the server logs. Look for Googlebot and for AI user agents such as GPTBot, ClaudeBot and PerplexityBot, and confirm they get 200 responses with real HTML.
Repeat after releases. A framework upgrade or a new tag-manager script can change rendered output overnight.
When the findings point at templates and rendering strategy rather than a stray tag, the fix becomes shared work between SEO and development. That's the kind of technical audit our SEO team in Coimbatore runs alongside client developers.
What the numbers say
Treat the render-delay row as direction, not a guarantee. The Search Engine Land review linked earlier notes that the 2024 sample is small relative to Googlebot's scale and limited to certain frameworks, and that newer Google documentation should take precedence where the two conflict.
AI search: Google's features and everyone else's
For Google's own AI surfaces the requirement is plain. A page must be indexed and eligible to show in Search with a snippet, and Google says there are no additional technical requirements. That's spelled out in Google's AI features documentation. For AI Overviews and AI Mode, JavaScript SEO reduces to getting indexed with your content intact, and a stray no snippet or no index can quietly remove you from both.
Other engines are a different matter. In Vercel's testing (linked in the statistics table above), none of the major AI crawlers rendered JavaScript, while Gemini borrowed Googlebot's infrastructure and AppleBot rendered pages through a browser-based crawler. That study dates from late 2024 and vendors change behaviour, so your logs are the final word. In principle a client-rendered page can rank well in Google while showing those crawlers an empty shell. Search Everywhere Optimization only works if the HTML-first rule holds beyond Google.
In practice, server-render the parts you want cited: definitions, comparison tables, FAQs and JSON-LD. Keep internal links as real anchors, so the relationships between a service page, its supporting articles and your case studies are visible without rendering. Structured data helps machines read a page accurately, but it isn't an AI shortcut, and it doesn't guarantee rich results.
Who needs this, what it costs, and how to measure it
Sites built on React, Vue or Angular, headless builds, and any site where pricing, availability, reviews or listings arrive by script after load should treat this as a priority. Standard WordPress and Shopify themes usually send their main content in the HTML, so there is more often a specific widget: a reviews plugin, a product tabs component, a filtered listing.
Cost depends on which of two jobs you have. Fixes to links, status codes, canonicals and blocked resources are template-level changes. Moving a client-rendered application to server rendering is an engineering project, scoped by framework, number of templates and how data is fetched. Any fixed price quoted without seeing the codebase is a guess.
Where this is heading
Google is more relaxed about JavaScript than it used to be. According to the Search Engine Land review linked earlier, it now says it has rendered JavaScript for multiple years and has removed older wording suggesting JavaScript makes things harder for Search, yet it still recommends pre-rendering approaches such as server-side rendering and edge-side rendering. The rest of the web is slower to follow. HTML-first for anything you want found, quoted or linked, with JavaScript layered on for interaction, remains the safer bet. If server rendering is slow to deploy on your stack, ask your developers about edge rendering.
Frequently Asked Questions
What is JavaScript SEO?
It's the practice of making sure pages built or changed by JavaScript can be crawled, rendered and indexed, so their content, links and metadata reach search engines intact. It sits inside technical SEO and touches rendering strategy, internal linking, status codes and page speed.
Can Google index content loaded with JavaScript?
In most cases, yes. Google renders pages with a 200 status in headless Chromium and indexes the rendered HTML. The catches are rendering delays, blocked resources, and content that needs a click or arrives after a failed script.
How long does Google take to render a page?
Google says a page may wait a few seconds or longer. A 2024 study of one large site measured a median of 10 seconds, with the slowest 1 percent taking around 18 hours. Keep critical content in the HTML rather than betting on timing.
Is client-side rendering bad for SEO, and do I need server-side rendering?
Not automatically. Google can process client-side rendering, but the risk rises on large or fast-changing sites, and non-Google crawlers get an empty shell. For public pages meant to rank and be cited, server or static rendering is the safer default. Logged-in apps don't need it.
Can ChatGPT, Claude or Perplexity read JavaScript-rendered content?
In Vercel's late 2024 testing, none of the major AI crawlers executed JavaScript, though some downloaded script files. Behaviour can change, so check your logs and test your pages with JavaScript switched off.
How do I see what Google sees?
Use URL Inspection in Search Console for the rendered HTML, the Rich Results Test for structured data, and compare view-source with DevTools. For other crawlers, load the page without JavaScript.
Does JavaScript affect Core Web Vitals?
Yes. Heavy scripts delay loading and can hurt responsiveness, especially on mid-range mobile phones. Fewer scripts and less third-party code usually help before any architectural change does.
How much does it cost to fix JavaScript SEO problems?
There's no honest fixed figure. Template-level fixes are small, while moving a client-rendered application to server rendering is an engineering project whose cost depends on the framework and page templates.
Is dynamic rendering still recommended?
No. Google calls it a workaround, not a long-term solution, and recommends server-side rendering, static rendering or hydration.




