JavaScript SEO is the practice of making JavaScript-rendered websites discoverable and indexable by search engines. The problem: search crawlers see raw HTML first and only execute JavaScript in a separate, slower pass. The solution: serve critical content (titles, meta tags, body copy, internal links) in the initial HTML response using server-side rendering (SSR), static generation (SSG), or pre-rendering, so crawlers never depend on client execution to find what matters.
Why JavaScript Breaks SEO
When Google fetches a page, it gets whatever HTML the server sends. If that HTML is an empty shell with a single <div id="root"> and a JavaScript bundle, the crawler has nothing to index until rendering completes. Rendering happens in a second pass through Google’s Web Rendering Service (WRS), and that pass is not guaranteed to be fast. It can take hours or days, and on low-priority pages it may not happen at all if the render budget is exhausted.
The render budget is the real constraint. Google allocates finite compute to rendering JavaScript across the web, and your site competes for it. Pages that miss the window get indexed with whatever was in the initial HTML, which for client-rendered apps is usually nothing useful.
Two-pass indexing also delays internal-link discovery, slowing how fast new pages get crawled. Content gated behind user interaction (clicks, scroll, hover) is essentially invisible even after rendering.
Rendering Modes Explained
Modern web frameworks offer five rendering modes, and choosing the right one is the single most important SEO decision for a JavaScript site.
Client-side rendering (CSR) ships an empty HTML shell plus a JavaScript bundle. The browser downloads, parses, executes, fetches data, then renders. CSR is the worst pattern for SEO because crawlers see nothing in the initial response.
Server-side rendering (SSR) generates HTML on the server per request. The crawler receives a fully populated page on the first byte. Next.js, Nuxt, and Remix make SSR practical at scale.
Static site generation (SSG) pre-builds HTML at deploy time and serves it from a CDN. This is the fastest, most reliable option for content that does not change per user, and it is ideal for blogs, marketing sites, and documentation.
Incremental static regeneration (ISR) combines SSG with on-demand rebuilds. Pages are static but regenerate in the background when data changes. It works well for sites with thousands of pages that update periodically.
Dynamic rendering serves pre-rendered HTML to bots and client-rendered content to users. Google deprecated its recommendation for this pattern in 2024. Use SSR or SSG instead.
Which Rendering Mode Is Best for SEO
For most sites, the answer is SSG or ISR. Static HTML is fast, cacheable, and trivially indexable. SSR is the right choice when content varies per request (logged-in dashboards, personalized pages, real-time data). CSR is acceptable only for authenticated areas with no SEO value, like an admin panel.
A common mistake: using SSR or SSG for the shell but loading critical content (product details, prices, descriptions) via client-side fetch after initial render. Crawlers see the shell, not the data. If content matters for ranking, it must be in the initial HTML response.
How Google Renders Pages in 2026
Google’s Web Rendering Service uses a current version of Chromium and runs JavaScript in two phases: index the raw HTML first, then re-index the rendered output asynchronously. The gap used to be days; in 2026 it averages a few hours for high-priority pages and longer for low-authority sites.
WRS respects most modern browser features (ES2022, fetch, IntersectionObserver) but ignores anything requiring user consent (camera, microphone, geolocation) or persistent state set after load. If your page takes longer than 5 seconds to reach interactive state, WRS may bail out before your content appears. Largest Contentful Paint is a useful proxy for render reliability: fast LCP renders cleanly, slow LCP correlates with rendering failures.
What Other Search Engines Do
Bing has its own rendering service and handles JavaScript reasonably well in 2026, though it is more conservative than Google about render budget. DuckDuckGo pulls from Bing, so the same constraints apply.
The bigger shift is AI crawlers. GPTBot, PerplexityBot, ClaudeBot, and Google’s AI Overviews crawler all index content for use in generative answers, and none of them execute JavaScript reliably. They read the initial HTML response and stop. If your content is not in that response, it will not appear in AI-generated answers, which means losing visibility in the fastest-growing surface for search traffic.
Common JS SEO Issues
The most frequent issue is client-only content: titles, headings, descriptions, or body copy that only appear after JavaScript runs. View page source (not the rendered DOM) and search for your key content. If missing, crawlers and AI bots will not see it.
Lazy-loaded components are second. Anything below the fold that loads on scroll is invisible to crawlers that do not scroll. Use lazy loading only for images and non-essential widgets, never for text or links.
Broken internal links are common in single-page apps. Links built with onClick handlers instead of <a href> tags are not crawlable. Every navigation needs a real anchor with a real URL.
Slow hydration is the fourth issue. If hydration blocks the main thread for several seconds, the page is unusable to users, which hurts engagement metrics that feed back into rankings.
Debugging JS SEO Issues
Start with the URL Inspection tool in Google Search Console. It shows the rendered HTML Google saw, the screenshot it captured, and any JavaScript errors during rendering. If the rendered HTML is missing your content, fix the rendering at the source.
Compare view-source (raw HTML) against the rendered DOM in DevTools. If your content appears in DevTools but not in view-source, you are relying on client rendering and need to move that content into the initial response.
Use the Rich Results Test as a second opinion; it runs Google’s renderer and surfaces errors the URL Inspection tool sometimes hides. The Coverage report flags pages that crawled but failed to index, which is often a rendering or content issue.
For headless debugging, run Lighthouse with the SEO audit enabled. It checks crawlable links, meta tags, canonicals, and structured data inside real Chromium, so its results approximate what Google sees.
Routing and Internal Links in JS Apps
Every internal link in a JavaScript app should be a real <a href> tag pointing to a real URL. Client-side routers like React Router and Next.js Link intercept clicks for client navigation, but the underlying anchor is still crawlable. Never replace anchors with div onClick handlers.
URL structure matters as much as link presence. Use clean, descriptive URLs with hyphens, avoid fragments for primary navigation, and keep hierarchies shallow. Internal linking is one of the highest-leverage SEO levers, and a JavaScript app that gets routing wrong forfeits it entirely.
Sitemaps are a safety net, not a replacement for in-page links. Generate sitemap.xml from your route manifest, submit it in Search Console, and update on every deploy, but do not rely on it alone. Crawlers prioritize pages linked from elsewhere on your site.
Meta Tags and Open Graph in SPAs
Single-page applications often forget to update meta tags on route changes. The title and description in the initial HTML are the only ones a crawler sees unless your framework updates them server-side. In Next.js, use the metadata API. In Nuxt, useHead or useSeoMeta. In Remix, the meta export.
Open Graph and Twitter Card tags must be server-rendered. Social platforms (Facebook, LinkedIn, Slack) fetch raw HTML and do not execute JavaScript. If og:title or og:image is set client-side, shared links will show generic previews. Meta tags are foundational, and missing them on a JS site is a self-inflicted wound.
Canonical tags also need to be in the initial response, reflecting the actual URL rather than a templated default.
Schema Markup in JS-Rendered Sites
Structured data should be in the initial HTML response, not injected by client JavaScript. Google’s documentation officially supports client-injected JSON-LD, but in practice, server-rendered schema indexes faster and more reliably. Schema markup drives rich results (FAQ snippets, review stars, product pricing), and a missing schema block costs visible SERP real estate.
For dynamic schema (product prices, event dates, review counts), generate it server-side per request. For static schema (organization, website, breadcrumbs), include it in the layout or template. Test every page type with the Rich Results Test before deploying.
Performance Implications for SEO
JavaScript weight directly affects Core Web Vitals. Every kilobyte adds parse and execute time, which delays interactivity. Pages that miss LCP, INP, or CLS thresholds get a ranking penalty in mobile search that has grown stronger every year since 2021.
Code-split aggressively. Ship only the JavaScript needed for the current route, lazy-load everything else, and audit bundles regularly with Next.js Bundle Analyzer or similar tools. Bundles tend to grow without anyone noticing.
Third-party scripts (analytics, chat widgets, A/B testing tools) are the silent killer of JavaScript site performance. Each one blocks rendering, ties up the main thread, and inflates page weight. Audit them quarterly and remove anything that does not justify its cost.
Framework-Specific Notes
Next.js is the de facto standard for SEO-friendly React. The App Router supports SSR, SSG, ISR, and streaming. Use the metadata API for tags, generateStaticParams for SSG, and revalidate for ISR.
Nuxt is the Vue equivalent. Nuxt 3 supports the same rendering modes with similar ergonomics. Use useHead and useSeoMeta for tags.
Astro ships zero JavaScript by default and is ideal for blogs, docs, and marketing sites where interactivity is minimal. Its island architecture lets you opt into JavaScript only where needed.
Remix is SSR-first and emphasizes web fundamentals. Forms, links, and navigation work without JavaScript by default, the gold standard for crawlability.
SvelteKit supports SSR, SSG, and CSR per route, and produces some of the smallest JavaScript bundles in the ecosystem, which helps Core Web Vitals.
Checklist for Shipping a JS Site Without Killing SEO
- Choose SSG or ISR for content pages, SSR for personalized or dynamic pages, CSR only for authenticated areas
- Confirm critical content (titles, headings, body, links) appears in view-source, not just rendered DOM
- Use real
<a href>anchors for every internal link - Set canonical, title, description, and Open Graph tags in the initial response
- Include JSON-LD schema in the server-rendered HTML
- Generate and submit a sitemap.xml on every deploy
- Audit Core Web Vitals (LCP, INP, CLS) before launching and monthly thereafter
- Test every page type with URL Inspection in Google Search Console after launch
- Run Lighthouse SEO audits in CI to catch regressions before deploy
- Audit third-party scripts quarterly and remove anything non-essential
If building a JavaScript site sounds like more risk than your team can manage, a fully managed Framer or static-first build removes the rendering question entirely. Talk to us about a build where SEO is solved at the platform level.
Frequently Asked Questions
Does Google fully render JavaScript in 2026?
Yes, but with caveats. Google uses a current Chromium-based Web Rendering Service that executes most modern JavaScript. The catch is timing and budget: rendering happens in a second pass that can take hours or days, and Google may skip rendering for low-priority pages or pages that exceed the render budget. Content in the initial HTML response is always indexed faster and more reliably than content that requires JavaScript execution.
Is React bad for SEO?
React itself is not bad for SEO. The problem is how React is deployed. A React app rendered entirely on the client (create-react-app, Vite SPA) is invisible to crawlers until JavaScript runs. The same React app rendered server-side with Next.js or Remix is fully indexable. The framework and rendering mode matter far more than the underlying library.
How do I check if my JavaScript site is being indexed correctly?
Open Google Search Console and use the URL Inspection tool on a few key pages. Look at the “View crawled page” section, which shows the HTML Google indexed. If your content is missing from that HTML, you have a rendering problem. Cross-check with the Coverage report to find pages that crawled successfully but failed to index, which often indicates content gaps in the rendered output.
Do AI search engines (ChatGPT, Perplexity, Claude) execute JavaScript?
No, not reliably. The major AI crawlers (GPTBot, PerplexityBot, ClaudeBot) fetch the raw HTML response and do not execute JavaScript. If your content is loaded client-side, it will not appear in AI-generated answers. As AI search captures more traffic, server-rendered content becomes essential for visibility in this growing surface.
Should I use dynamic rendering as a quick SEO fix?
Avoid it if possible. Dynamic rendering (serving pre-rendered HTML to bots and client-rendered content to users) was a workaround for the SSR gap that is no longer necessary. Google deprecated its recommendation in 2024, and the pattern adds operational complexity (cloaking risk, infrastructure overhead, divergent codepaths) without solving the underlying problem. Migrating to SSR or SSG is the durable fix.