JS SEO & Rendering

Modern sites are built largely with JavaScript, and for good reasons: faster development, richer interfaces, flexible architectures. React, Vue, Svelte and their frameworks have made component-based frontends the default. But JavaScript raises a question classic HTML never had to answer: do the machines see the same thing your users see? The answer decides whether your content can be found at all, in Google as well as in the AI search engines.

Why rendering decides your visibility

Rendering is the process where JavaScript builds the finished page. On a server-rendered site, the content is already in the HTML the server sends. On a client-side rendered site, the server sends a nearly empty shell, and the content only appears once JavaScript has run in the browser.

For the user the end result is often identical. For the machines the difference is fundamental: a crawler that does not execute JavaScript sees the empty shell. No text, no links, no products.

How Google handles JavaScript

Google can render JavaScript, and does so with an up-to-date Chromium browser. But rendering happens in two steps. Googlebot first fetches the raw HTML, and the rendering itself goes into a queue that runs when resources allow. That has three consequences:

• Delay. Content that only exists after rendering can be discovered and refreshed more slowly than content in the raw HTML.
• Resources. Rendering is expensive, and large sites often find that only part of their pages get rendered as often as the content changes.
• Failure. Blocked JavaScript files, timeouts, or scripts that fail in Google's environment leave the page half empty in the index, with nothing looking wrong in a normal browser.

Links deserve their own point. Googlebot follows a tags with href attributes. Navigation that only works through JavaScript click handlers can leave whole sections of the site without internal paths a crawler can follow. That undermines both crawling and indexing and your internal link structure.

AI crawlers generally do not render JavaScript

This is where the AI surfaces part company with the old debate about JavaScript and SEO. The crawlers behind ChatGPT, Claude, Perplexity and the other AI search engines overwhelmingly fetch the raw HTML only. They do not run your JavaScript. Content that exists only after client-side rendering is therefore invisible to most AI surfaces, no matter how well it performs in Google.

That makes server-rendered content the safe choice on both surfaces. The HTML your server returns to the first request has to contain your real content. Classic search and AI search make exactly the same demand here, which is why AI search optimization so often starts in the frontend architecture.

Rendering strategies: CSR, SSR and SSG

• Client-side rendering (CSR). Everything is built in the browser. Quick to develop, and the weakest option for visibility: Google has to wait for the rendering queue, and AI crawlers see an empty shell.
• Server-side rendering (SSR). The server builds the finished HTML on each request. The content is complete from the first byte, and JavaScript then takes over interactivity in the browser.
• Static site generation (SSG). Pages are built as finished HTML ahead of time and served straight from a CDN. Ideal for content that does not change by the minute, and modern frameworks can rebuild individual pages as the content updates.

In practice most modern frameworks, Next.js, Nuxt, SvelteKit and Astro among them, land on a hybrid: static or server-rendered HTML as the foundation, JavaScript layered on for interactivity. That also gives you a good starting point for Core Web Vitals, because the user sees content before all the JavaScript has been fetched and executed.

Dynamic rendering, where you serve a pre-rendered version to bots and the client-side app to users, still exists as a fallback for legacy applications. Treat it as exactly that. It adds a second version of your site to maintain, and Google has recommended against it as a long-term solution for years.

The frontend decides, not the CMS

Many JavaScript discussions really start with a CMS choice. Headless architectures, where content lives in a system like Storyblok, Sanity, Contentful or Strapi and is served through an API to an independent frontend, are entirely normal now. From an SEO perspective the CMS choice matters less than it is usually made out to.

The machines cannot see which CMS sits behind the page. They see only the HTML the frontend delivers. Put roughly: the CMS looks after your content, and the frontend framework looks after your technical SEO. A well-chosen headless setup with server rendering can be a strong foundation, while the exact same CMS behind a pure client-side app can hide all the content. So put the attention where the decision actually lives, in the frontend architecture. That is also where we most often work alongside our clients' developers or our own team in web development.

How to test what the machines see

1. View the source. Open the page source, not the inspector, and search for a sentence from the body text. If it is there, the content is server-rendered. The inspector shows the fully rendered DOM instead, and the gap between the two is precisely what JavaScript built.
2. Turn JavaScript off. Disable JavaScript in the browser and reload. What you see now is roughly what an AI crawler sees.
3. Use URL Inspection in Search Console. The tool shows the rendered HTML Google actually indexes, and reveals blocked resources and rendering errors.
4. Fetch the page as a bot. A curl call against the URL shows the exact raw HTML your server delivers to crawlers that do not render.

Common pitfalls

• Metadata set in the browser. Page titles, meta descriptions and canonical tags injected by JavaScript are read unreliably. They belong in the raw HTML.
• Content behind interaction. Text that is only fetched on click, scroll or tab change usually does not get indexed. Lazy loading is good practice for images below the fold and a liability for body content.
• Blocked JavaScript. If your scripts sit behind robots.txt blocks, Google cannot render the page correctly.
• Soft 404s. Client-side apps often answer 200 OK on pages that do not exist. Return real status codes so errors can be found and handled, which ties directly into your site health and redirects.

JavaScript and SEO live together perfectly well when rendering is treated as an architecture decision rather than something you sort out at the end. If you are unsure what the machines actually see on your site, a free SEO analysis uncovers it along with the rest of your technical foundation.