Check this page with an assistantOpens a chat asking it to summarise this article and name the evidence behind each claim.
Claude opens with the prompt on your clipboard: Anthropic does not support prefilled prompts on the web, and we would rather copy it than ship a button that drops it.
“Google Renders JavaScript” Is a Capability, Not a Guarantee
Google processes JavaScript sites through crawling, rendering, and indexing. A 200 response can enter the rendering queue, where a recent Chromium-based Web Rendering Service executes scripts and produces rendered HTML for further link discovery and indexing.
Each stage can fail independently. The server may return an empty app shell. A bundle may be blocked. An API can time out. Content may appear only after a click. Client routing can produce fragment URLs. A second canonical can be injected after the first. To a user with a warm cache and active session, the application looks fine; to a fresh crawler, its meaning is absent or inconsistent.
The practical goal is not “avoid JavaScript.” It is to make the public page’s essential content and state dependable across response, render, and interaction boundaries.
Map the Three Processing Stages
| Stage | What must work | Common failure |
|---|---|---|
| Crawl | URL access, response status, resources, discoverable links | Robots block, redirect loop, app always returns 200 |
| Render | Bundles, APIs, compatible code, deterministic state | Console exception, authentication, timeout, stale bundle |
| Index | Visible content, metadata, canonical, quality, uniqueness | Empty DOM, duplicate state, conflicting directives |
Diagnose in this order. Changing headings cannot fix an API that fails during rendering. Pre-rendering cannot help a URL blocked in robots.txt. A successful screenshot does not prove Google selected the intended canonical.
Choose Rendering Per Template
Server rendering, static generation, and client rendering are tools, not ideologies. Public pages that depend on organic discovery usually benefit from useful initial HTML. Account dashboards and private application states may reasonably remain client-only.
| Pattern | Useful fit | Search tradeoff |
|---|---|---|
| Static generation | Articles, documentation, stable landing pages | Excellent response HTML; needs a freshness strategy |
| Server-side rendering | Dynamic public catalogs and listings | Reliable HTML; server latency and failure matter |
| Hydration | Interactive pages with useful server output | Preserves content; excess JavaScript can hurt responsiveness |
| Client-only rendering | Private tools and app states | Public meaning depends on successful rendering |
| Dynamic rendering | Temporary legacy workaround | Dual output, parity risk, and ongoing operational cost |
Google describes dynamic rendering as a workaround rather than a recommended long-term solution. Prefer one architecture that serves equivalent, useful output to users and crawlers. If bot-specific rendering remains temporarily, diff the two outputs and watch for accidental cloaking or stale content.
Put the Essential Contract in the Response
The response should communicate a truthful HTTP status, one canonical intent, indexability, a useful title, and enough page content to identify the destination. Hydration can add filtering, personalization, calculators, and richer interaction without becoming the only source of meaning.
Single-page applications often return the same 200 app shell for missing routes. That creates soft 404s. Configure the server or framework to return a real 404 for nonexistent public URLs and a useful error view. Redirect moved resources at the HTTP layer when possible instead of relying on a script after a successful response.
Keep canonical and robots directives stable. Google can recognize a JavaScript-injected canonical, but conflicting tags produce unpredictable results. An initial noindex is especially dangerous when a script intends to remove it, because Google may skip rendering after encountering the directive. The search-controls guide details the correct boundary for each mechanism.
Keep Resources and Data Fetches Available
Google needs access to the JavaScript, CSS, images, and API responses that produce the public page. Blocking bundle directories or rendering endpoints can leave the Web Rendering Service with a materially different experience. Signed URLs that expire, region restrictions, cookie walls, and authentication checks can create the same problem.
Build for a clean session: no local storage, no consent history, no logged-in state, and a crawler request that may originate from the United States. Public content should not require browser gestures or permissions. Handle API failure with a visible error and an honest status strategy rather than an empty component.
Fingerprint bundle filenames when content changes. Google notes that its renderer can cache JavaScript and CSS aggressively; immutable versioned assets prevent new HTML from depending on an old cached bundle.
Lazy-Load Enhancements, Not Discoverability
Lazy loading reduces initial work when it defers below-the-fold media or optional modules. It becomes a search risk when essential content has no source until a user scrolls, clicks, or changes a filter. Use native image loading where appropriate, preserve real image URLs, and include descriptive text and links in rendered HTML.
Do not lazy-load the likely LCP image. Make critical resources discoverable early and reserve media dimensions. JavaScript SEO and performance are connected: a large hydration task can delay interaction, while late resource discovery can delay the main visual. The Core Web Vitals playbook separates those causes by metric and template.
Run a Response-to-Render Test Matrix
Test representative URLs from every public template, including product states, empty results, paginated pages, redirects, and errors. Compare four views rather than trusting one browser:
- Raw response: status, headers, HTML, canonical, robots, title, content, and links before JavaScript.
- Fresh browser render: final DOM, network failures, console errors, content, links, and metadata.
- Google test render: URL Inspection or Rich Results Test screenshot, HTML, resources, and structured data.
- Indexed state: selected canonical, page-indexing status, search appearance, and recrawl timing.
Automate the first two in deployment checks. Fail releases when an H1 vanishes, canonical changes, internal-link count collapses, a public route returns the app shell for a 404, or a required API request fails. Use the indexing diagnostics manual when the live and reported states diverge.
Questions About JavaScript SEO
- Can Google index JavaScript-rendered content?
Yes. Google crawls a URL, queues eligible pages for rendering in its Web Rendering Service, executes JavaScript, and uses the rendered HTML for indexing. That capability does not remove failure risks: blocked resources, errors, slow APIs, interaction-only content, and inconsistent metadata can still prevent the intended output from appearing.
- Is server-side rendering required for SEO?
No, but Google recommends server-side rendering, static rendering, or hydration as durable approaches. Useful response HTML improves speed and reliability for people, crawlers, link unfurlers, and bots that do not execute JavaScript. Choose the rendering mode per template rather than rebuilding the whole application solely for a crawler.
- Should I use dynamic rendering for Googlebot?
Treat it as a temporary workaround, not the target architecture. Google no longer recommends dynamic rendering as a long-term solution because bot detection and dual output add complexity and drift. If it remains during a migration, keep user and crawler content equivalent and monitor parity closely.
- Can JavaScript change canonical and robots tags?
Google can process a canonical injected during rendering, but recommends avoiding that pattern when possible and warns against multiple or conflicting canonicals. Robots changes are riskier: if initial HTML contains noindex, Google may skip rendering, so JavaScript might never get the chance to remove it.
Primary Sources Reviewed
- Google Search Central: JavaScript SEO basics
- Google Search Central: Fix JavaScript search problems
- Google Search Central: Dynamic rendering as a workaround
- Google Search Central: Search-friendly lazy loading
- Google Search Central: Crawlable link best practices
Reviewed July 28, 2026. Rendering behavior, browser support, and framework defaults evolve; inspect the deployed response and rendered output for each template after significant releases.
