The short answer is that JavaScript doesn't hurt SEO, but the way you render it can. I build sites in Next.js, a JavaScript framework, and they rank. The framework was never the risk. The risk is shipping a page where the content only exists after a browser has downloaded, parsed, and executed your code, because not everything that reads the web is a browser.
That distinction has become more important, not less, over the past couple of years. Google has got steadily better at rendering JavaScript. The AI crawlers that increasingly decide whether your business gets mentioned in an answer have not. So this post covers both halves, what Google actually does with your JavaScript, and what everything else sees when it doesn't run your JavaScript at all.
What Google actually does with JavaScript
Google processes JavaScript pages in stages. Googlebot fetches the raw HTML first, and anything in that initial response can be indexed straight away. Pages that need JavaScript to show their content go into a render queue, where Google's Web Rendering Service loads them in a headless version of Chromium, the same engine behind Chrome, kept permanently up to date. Whatever exists in the DOM after that render is what gets indexed.
The render queue used to be the scary part, with talk of content waiting days or weeks to be seen. That fear is out of date. Research by Vercel with the crawler-monitoring firm MERJ found most pages were rendered quickly, with a quarter rendered within seconds of the initial crawl, and even the slowest tail measured in hours rather than weeks. For a normal business site, Google will see your JavaScript-rendered content, and usually promptly.
So if Google were the only reader that mattered, the sensible position would be mild caution rather than alarm. Rendering can still fail in specific ways, which I'll come to, but "Google can't handle JavaScript" stopped being true a long time ago.
Where JavaScript sites still lose rankings
The failures I actually find in audits are rarely "Google didn't render the page." They're more specific than that, and every one of them is checkable.
Blocked resources. If robots.txt blocks the JavaScript or API routes the page needs, the render produces a broken page and Google indexes the broken version. This one still turns up on sites that copied a robots.txt from somewhere in 2015.
Content behind interactions. Google renders the page as it loads. It doesn't click your tabs, expand your accordions with JavaScript-only content, or scroll to trigger your lazy loading. Content that needs a user action to exist in the DOM may as well not be there.
Links that aren't links. Client-side routers make it easy to build navigation out of click handlers instead of proper <a href> elements. Googlebot discovers pages by following href attributes, so a div with an onClick is invisible as a signpost, however well it works for users.
Metadata that arrives late or never. Titles, canonicals, and meta robots tags set by client-side JavaScript can conflict with what the initial HTML said, and the initial HTML often wins. Critical signals belong in the server response.
Performance drag. Heavy JavaScript bundles are the main reason sites fail INP, which I covered in my Core Web Vitals guide. This is a user experience cost as much as a rankings one, but it lands on the same budget.
None of these are exotic. They're the rendering section of my technical SEO checklist applied to a framework site, and they're all visible in Search Console's URL Inspection tool if you compare the rendered HTML against what you expected to be there.
The part that's changed: AI crawlers don't render at all
Here's the reason this topic deserves a fresh look in 2026. The crawlers feeding AI assistants, GPTBot for ChatGPT, ClaudeBot for Claude, PerplexityBot for Perplexity, do not execute JavaScript. They fetch the raw HTML response and that's the whole meal. Vercel's crawler research found GPTBot downloaded JavaScript files about 11 per cent of the time, but never ran them, and the same held for the others.
The one real exception is Google's Gemini, which sits on Googlebot's rendering infrastructure and sees what Google sees.
The practical consequence is blunt. A client-side rendered site, where the server sends a near-empty HTML shell and JavaScript fills in the content, is a blank page to most AI crawlers. Google might rank it fine while ChatGPT and Perplexity have no idea what's on it, and recommendations sourced from AI answers quietly route around you. If a growing slice of your would-be customers ask an assistant instead of typing a search, the rendering decision you made for Google now has a second audience it fails.
The rendering options, compared
Every framework site makes a rendering choice, whether or not anyone made it deliberately. The options reduce to a short list.
| Strategy | What the crawler receives | Suits | The catch |
|---|---|---|---|
| Client-side rendering (CSR) | A near-empty shell, filled by JavaScript | Apps behind a login, dashboards | Invisible to AI crawlers; leans entirely on Google's renderer |
| Server-side rendering (SSR) | Full HTML built per request | Pages with per-request or frequently changing content | Server cost and slower response if unmanaged |
| Static generation (SSG/ISR) | Full HTML built at deploy time | Marketing pages, blogs, most content | Content updates need a rebuild or revalidation |
| Hybrid | Full HTML, with JavaScript adding interactivity on top | Most real business sites | Requires the choice to be made per page type |
In short, anything you want found should arrive as complete HTML, and JavaScript should be the layer that makes it interactive rather than the thing that makes it exist.
That's the approach on the sites I build. Marketing and content pages are statically generated, anything properly dynamic renders on the server, and client-side JavaScript is reserved for the interactive bits where it belongs. Rendering is a design decision made at the start, because retrofitting server rendering onto a client-side app is some of the most expensive remedial work in technical SEO.
How to check your own site
You don't need tooling to get a first answer. Open a key page, view the page source (not inspect element, the raw source), and search for a sentence of your main content. If it's in the source, crawlers without rendering can read you. If the source is a sparse shell of script tags, everything you learned in the AI crawler section above applies to you.
For the Google side, run the page through URL Inspection in Search Console and read the rendered HTML it shows you. What's missing from that render is missing from the index. It's worth flagging that a site can pass the Google check and fail the view-source check, and plenty now do, which is exactly the gap between ranking in search and existing in AI answers.
JavaScript and SEO FAQs
Does Google penalise JavaScript websites?
No. There's no penalty for using JavaScript, and Google renders it with an up-to-date Chromium engine. Framework sites rank perfectly well when the content arrives as HTML or renders cleanly. The problems are specific and technical, blocked resources, content behind interactions, missing href links, rather than the language itself.
Can ChatGPT and other AI assistants read JavaScript content?
Mostly not. As of mid 2026, GPTBot, ClaudeBot, and PerplexityBot fetch raw HTML and don't execute JavaScript, so content that only exists after client-side rendering is invisible to them. Gemini is the exception because it uses Google's rendering infrastructure. Server-side rendering or static generation solves this for all of them at once.
Do I need server-side rendering for SEO?
You need your indexable content to arrive as HTML, and server-side rendering or static generation are the two reliable ways to get there. Pure client-side rendering can still rank on Google, but it leans on a render step you don't control and leaves you invisible to most AI crawlers, which is a poor trade for public-facing pages.
How can I tell if my JavaScript content is being indexed?
Search Google for an exact sentence from the page in quotes, and check the page in Search Console's URL Inspection tool, comparing the rendered HTML against what should be there. Then view the raw page source to see what non-rendering crawlers get. The combination tells you whether you have a Google problem, an AI visibility problem, or neither.
Want a site built to be seen?
Tell me what you're working on and what you're trying to achieve, and I'll give you an honest view of whether I can help and what it would take.
Get in touch�