JavaScript SEO: Rendering and Indexing

JavaScript now drives large parts of modern websites, from navigation and dynamically loaded content to the entire page structure of single-page applications. This creates a gap between what users see in the browser and what search engines and AI crawlers find without rendering. JavaScript SEO closes this gap. This article explains how Googlebot processes JavaScript, which rendering strategy works for visibility in classic search and in AI answers, and how you avoid typical pitfalls in the DACH region.

Why JavaScript SEO is business-critical

In Austria, search visibility is almost identical to visibility on Google. The search engine holds an 81.87 percent market share there, ahead of Bing with 9.01 percent (Austria, as of May 2026). The market is almost fully connected: in early 2025 there were 8.69 million internet users at 95.3 percent online penetration (Austria). If JavaScript prevents content from being indexed properly, a company drops out of exactly the channel that dominates the market.

For B2B providers, there is also an economic lever. Product and service pages built with JavaScript are often directly relevant to revenue. If they are poorly indexed, reach and sales suffer.

At the same time, visibility is shifting toward AI answers, and this layer is sensitive to JavaScript. An international study by Pew shows how strongly AI summaries change click behavior: in a search with an AI Overview, users click a classic result in only 8 percent of cases, without an AI Overview in 15 percent (international, USA). If you want to appear as a source in these AI answers, you have to make your content available to systems that usually do not execute JavaScript at all.

How Googlebot processes JavaScript: the two waves of indexing

Googlebot splits the processing of web pages into several steps. First, the crawler loads the raw HTML of a URL. Pure HTML content goes straight into indexing. Content that only comes into existence through JavaScript, by contrast, moves into a separate queue, the rendering queue. There, the Web Rendering Service, based on a headless Chromium, executes the JavaScript, completes the DOM and passes the rendered HTML back to indexing. In effect, this results in two waves of indexing: an immediate one for the raw HTML and a second, delayed one for the rendered result.

The good news first: Google renders reliably. A widely noted analysis by Vercel and MERJ based on more than 100,000 Googlebot fetches found that 100 percent of HTML pages were fully rendered, including complex JavaScript interactions (international). Content loaded asynchronously via API and streamed React Server Component content were captured as well, and modern frameworks such as Next.js were fully rendered. The claim that Googlebot cannot handle JavaScript is therefore outdated.

The problem is not whether, but when. The same analysis quantifies the rendering delay: the median is 10 seconds, the 75th percentile 26 seconds and the 90th percentile around three hours (international). For most pages, this is not critical; for time-sensitive content, the long tail is a real risk. The crawl effort makes it worse: an Onely study showed that Google needs considerably longer for JavaScript pages. Reaching the seventh page of a JavaScript folder took 313 hours, compared with only 36 hours for pure HTML, roughly nine times as long (international). If you want a lot of content indexed quickly, such as news or frequently changing offers, you pay a high crawl budget premium with JavaScript.

Rendering strategies compared

The strategy a website chooses determines what crawlers find in the first step.

• Client-side rendering (CSR): The server delivers an almost empty HTML skeleton, and the browser builds the page with JavaScript. Content only appears after rendering. For Google, this usually works, but with a delay. For crawlers that do not execute JavaScript, the page remains practically empty.
• Server-side rendering (SSR): The server renders the complete HTML for each request and sends it fully rendered. Crawlers and AI bots see the content immediately in the raw HTML, without depending on rendering.
• Static site generation (SSG): The pages are generated in advance at build time as static HTML. This delivers maximum speed and immediately indexable HTML, but is mainly suitable for content that does not change constantly.
• Dynamic rendering: A transitional solution in which crawlers receive a pre-rendered HTML version, while users get the JavaScript version. Google explicitly no longer recommends this approach and classifies it as an outdated workaround, because it increases maintenance effort and the risk of serving different content.

For most B2B projects, SSR and SSG are the reliable options. They deliver what both Googlebot and AI crawlers depend on: complete content in the initial HTML. CSR still makes sense for highly interactive, logged-in areas, but should not be used for publicly discoverable key content.

Next.js in practice

Next.js is a widely used framework for SEO-critical applications. The analysis by Vercel, the company behind Next.js, and MERJ shows that Googlebot fully rendered the Next.js pages in the study (international). What matters is how the framework is used.

The App Router with React Server Components lets you render content on the server by default and ship only the truly interactive parts as client components. SSG and incremental static regeneration produce static HTML that is updated in the background when needed, without complete rebuilds. Streaming delivers content step by step, while hydration makes the statically delivered page interactive in the browser. For SEO, one rule applies: everything that should be indexed or cited by AI systems belongs in the server-rendered HTML, not in sections loaded on the client side.

Best practices: getting content into the initial HTML

JavaScript SEO succeeds when the decisive elements are already in the raw HTML before JavaScript runs. The most important levers:

• Render key content on the server: Text, product data and all content that should rank or be cited must be visible without JavaScript execution. This also keeps the content visible to AI crawlers that do not render.
• Links as real HTML anchors: Navigation and internal linking belong in regular anchor tags with an href attribute. Click handlers generated by JavaScript without a real link are often not recognized as followable paths during crawling.
• Set canonical and meta robots on the server: Canonical tags and directives such as noindex must be in the initial HTML. If they are only injected with JavaScript, Google may process a wrong or missing directive in the first wave.
• Deliver title and meta description without JavaScript: These snippet-relevant elements should not appear only after rendering, because otherwise they are captured inconsistently.
• Use lazy loading in a controlled way: The crawler may not see content that only loads on scroll interaction. Important content should be available without user interaction.

An analysis by the Web Almanac shows how relevant this discipline is: on desktop home pages, the median number of visible words after rendering is 400 words compared with 330 in the raw HTML, a difference of 17.5 percent (international). A significant part of the content is therefore created only by JavaScript. On purely client-rendered pages, exactly this part reaches the index late or not at all and remains completely invisible to AI crawlers that do not render.

Structured data in JavaScript environments

Structured data in JSON-LD format is the foundation for rich results and an important signal for AI discovery. In JavaScript-heavy environments, the question is whether the markup is in the HTML delivered by the server or only gets injected with JavaScript. The data is clear: according to the Web Almanac, the majority of sites deliver structured data in the raw HTML, and only 2 percent of mobile and desktop crawls add structured data via JavaScript (international).

JSON-LD delivered by the server is available immediately, independent of the rendering queue, and readable even for crawlers that do not execute JavaScript. Markup injected with JavaScript, by contrast, depends on rendering and is therefore more fragile. For reliable rich results and for discoverability by AI systems, JSON-LD should therefore be in the initial HTML, delivered by the server.

AI crawlers and GEO in a JavaScript context

The central difference between classic search and generative search lies in rendering. While Googlebot executes JavaScript, most AI crawlers only process the raw HTML. Content that is created exclusively on the client side simply does not exist for these systems. SSR or SSG is therefore not an optional extra but a prerequisite for AI visibility.

The volume of these crawlers is considerable. According to Cloudflare Radar, AI bots (excluding Googlebot) generated an average of 4.2 percent of all HTML requests in 2025, Googlebot alone 4.5 percent (international). Among verified bots, Googlebot clearly led with over 28 percent, ahead of GPTBot with around 7.5 percent. Most AI crawling serves model training. At its peak, training crawling was seven to eight times as extensive as the crawling AI providers do for their own search features. These bots collect content on a massive scale, and they collect what is in the HTML.

This leads to concrete measures for AI crawler management. With robots.txt, you can control which AI crawlers, such as GPTBot or ClaudeBot, get access. If you want to appear as a source in AI answers, you should not block relevant bots and should also make sure that your content is available on the server side. IndexNow complements this by actively notifying participating search engines about new or changed URLs, which speeds up discovery and softens the structural disadvantages of client-side rendering for discoverability.

Crawl budget, sitemaps and fast indexing

Because JavaScript slows down crawling, measures that secure discoverability independently of rendering become more important. Up-to-date XML sitemaps are the most important tool here. They explicitly list all relevant URLs and make sure Google finds new pages, even if the internal linking is only created by JavaScript. For client-rendered pages whose links Google would otherwise only see after rendering, a complete sitemap noticeably reduces the discovery disadvantage.

The background is the crawl budget problem described above: the factor of roughly nine in crawl time for JavaScript compared with HTML (international) means that every avoidable rendering dependency saves budget. Clean sitemaps, a flat and reachable structure, server-side links and avoiding unnecessary JavaScript work together here.

Core Web Vitals for JavaScript-heavy pages

JavaScript is one of the main sources of weak Core Web Vitals. Three levers are central:

• LCP (Largest Contentful Paint): A large bundle size and render-blocking JavaScript delay the largest visible content. Code splitting, that is, dividing the JavaScript into smaller chunks, and delivering the main content from the server improve LCP.
• INP (Interaction to Next Paint): This metric measures how quickly the page responds to input. Expensive hydration and long JavaScript tasks block the main thread and worsen INP. Less client-side JavaScript and breaking up long tasks help.
• CLS (Cumulative Layout Shift): Content that is loaded later via JavaScript and shifts the layout increases CLS. Reserved space for elements that load later keeps the layout stable.

Cross-cutting issues are unused JavaScript and third-party scripts. Every loaded script costs performance and rendering time, including Googlebot's. Consistently removing unused code and reducing external scripts directly improves all three metrics.

GDPR, consent management and rendering in the DACH region

The DACH region adds a particular factor: consent banners and the tag loading tied to them. Many tracking and marketing scripts only load after consent through a consent manager, and these run on the client side via JavaScript. This affects JavaScript SEO in two places.

First, the number of these late-loading scripts affects performance and therefore the Core Web Vitals. Second, consent management must not hinder indexing. Googlebot does not accept cookies and does not dismiss banners. The crawler may not see content that only becomes visible after consent. The consequence is clear: the actual page content must be available on the server side regardless of consent status, while consent banners and optional scripts must not block the rendering of the main content. This keeps GDPR compliance and indexability compatible.

Testing, debugging and measurement

You cannot judge JavaScript SEO by gut feeling; you have to test it by comparing raw and rendered HTML. The most important checks:

• URL Inspection in Search Console: Shows the HTML of an indexed URL as Google actually rendered it. Here you check whether key content, canonical and meta robots are included in the rendered result.
• Compare raw and rendered HTML: Check whether the content visible in the browser matches the raw source code. Large discrepancies are a warning sign of rendering-dependent content.
• Rich Results Test: Checks whether structured data is recognized correctly, even if it is delivered via JavaScript.
• Lighthouse and CrUX: Provide lab and field data on Core Web Vitals and uncover JavaScript-related performance problems.
• Log file analysis: Shows how often and with what delay Googlebot fetches and renders pages, and reveals crawl budget bottlenecks.

The documented order of magnitude serves as a guide for the delay: a range from a median of 10 seconds to a 90th percentile of around three hours (international) shows how widely the indexing speed of rendered content varies. If you see unusual outliers in your logs, you have a concrete optimization target.

Conclusion and next steps

JavaScript SEO decides whether modern, JavaScript-driven websites reach their full visibility potential or whether content is captured late, incompletely or not at all. Googlebot does render reliably, but with a delay and high crawl effort, and most AI crawlers do not render at all. The answer is to put key content, links, canonical, meta robots and JSON-LD into the initial HTML on the server side, ideally via SSR or SSG, for example with Next.js.

Sensible next steps are a URL inspection of your most important pages to compare raw and rendered HTML, a review of the rendering strategy for content relevant to rankings and AI, an up-to-date XML sitemap for faster discovery, and a consent setup that leaves the main content accessible to Googlebot. This puts classic search and AI visibility on the same foundation, available on the server side.