14 min read · Technical SEO · Last updated July 2026
Quick answer: Googlebot can render JavaScript, but it does so in a two-wave process that can delay indexing by days to weeks. Server-side rendering (SSR) or static site generation (SSG) eliminates this delay and is strongly preferred for SEO-critical pages.
Introduction
JavaScript broke SEO for a decade. Modern web apps moved logic from servers to browsers, and Google’s crawler — built for HTML documents — suddenly needed to run millions of React and Vue apps just to read page content.
Google eventually built Evergreen Googlebot, which runs a full Chrome rendering engine. But “can render” and “renders on time” are different things. The second wave of rendering — where Googlebot actually executes your JavaScript — can lag by days or weeks behind the initial crawl.
For any business running a JavaScript-heavy site, that gap is lost indexation, delayed rankings, and slower organic growth.
What you’ll learn:
– The difference between SSR, CSR, SSG, and dynamic rendering
– How Googlebot’s two-wave rendering process works in practice
– How to test what Google actually sees on your pages
– Which rendering approach to choose based on your tech stack and SEO goals
Table of Contents
- How Googlebot Renders Pages: The Two-Wave Model
- Client-Side Rendering (CSR) and Its SEO Risks
- Server-Side Rendering (SSR): The Gold Standard for SEO
- Static Site Generation (SSG): Fast, Predictable, Excellent for SEO
- Dynamic Rendering: The Workaround Worth Understanding
- Rendering Comparison: Choosing the Right Approach
- Testing What Google Sees With URL Inspection
- Common JavaScript SEO Mistakes
How Googlebot Renders Pages: The Two-Wave Model
Google’s crawl process has two waves for JavaScript-heavy pages:
Wave 1 — HTML crawl: Googlebot fetches the raw HTML response from your server. It extracts links, basic metadata, and any content in the initial HTML. This happens quickly and frequently.
Wave 2 — JavaScript rendering: Googlebot queues the page for rendering. A headless Chrome instance executes the JavaScript, builds the DOM, and Google can then read the fully rendered content. This can happen minutes, hours, days, or weeks after Wave 1.
The lag between Wave 1 and Wave 2 is the core problem. If your critical content (product descriptions, H1 tags, internal links, body text) only appears after JavaScript executes, Google may crawl your page in Wave 1 and see nothing useful for an extended period.
Pages that depend on client-side API calls, lazy-loaded content, or React/Vue/Angular frameworks to populate their main content are most at risk.
Client-Side Rendering (CSR) and Its SEO Risks
In a CSR setup, your server sends a near-empty HTML document — usually just a <div id="app"></div> — and the browser (or Googlebot) downloads and executes JavaScript to build the entire page.
The problem is straightforward: if Googlebot hits your page in Wave 1, it sees almost nothing. If Wave 2 rendering is delayed, your content is invisible to Google for days.
Real-world impact from a 2025 case study: An e-commerce site migrated from WordPress to a React SPA. Within 6 weeks, organic traffic dropped 43%. Investigation revealed that product page content was entirely client-side rendered, and Googlebot Wave 2 rendering was taking an average of 11 days. New products weren’t appearing in search results until nearly 2 weeks after publication.
CSR isn’t a death sentence for SEO, but it requires mitigation — either through SSR, SSG, or dynamic rendering.
Rendering Comparison Toggle
Server-Side Rendering (SSR): The Gold Standard for SEO
With SSR, your server executes the JavaScript at request time, builds the complete HTML document, and sends it to the browser (and Googlebot) fully rendered. Wave 1 crawl immediately sees all content.
Frameworks: Next.js (getServerSideProps), Nuxt.js SSR mode, SvelteKit, Remix.
The trade-off is server cost and latency. Every request requires server computation. Mitigate this with incremental static regeneration (ISR) in Next.js — pages are statically generated on first request and revalidated on a schedule, giving you SSG performance with SSR freshness.
For e-commerce product pages, service pages, and blog content, SSR or SSG is non-negotiable if organic search is a priority.
Static Site Generation (SSG): Fast, Predictable, Excellent for SEO
SSG pre-builds every page at deploy time. The server sends pure HTML with zero computation. Googlebot’s Wave 1 crawl sees the complete document immediately.
Frameworks: Next.js static export, Gatsby, Astro, Hugo, Eleventy.
SSG is ideal for content that doesn’t change with every request — marketing pages, blog posts, documentation, landing pages. For e-commerce with large catalogs (100,000+ products), full SSG builds become slow, but ISR solves this by generating pages on-demand and caching them.
A Netlify benchmark from 2024 showed SSG pages achieving TTFB under 50ms globally via CDN edge. SSR pages averaged 180ms. Both are acceptable for SEO, but SSG wins on Core Web Vitals.
Dynamic Rendering: The Workaround Worth Understanding
Dynamic rendering detects whether the visitor is a bot or a human and serves different content accordingly. Bots get server-side rendered HTML; humans get the CSR app.
Tools: Rendertron (open source), Prerender.io (SaaS), Puppeteer-based custom solutions.
Google officially acknowledges dynamic rendering as a workaround and recommends migrating to SSR or SSG long-term. It works, but it has risks: if implemented sloppily, it can trigger cloaking flags (showing different content to Google vs. users, which violates guidelines). Ensure the rendered content for bots is identical to what users see — just pre-rendered.
Use dynamic rendering as a bridge solution when you can’t immediately rewrite a large CSR app. Set a migration deadline and move to proper SSR/SSG within 12 months.
Googlebot Rendering Timeline Visualizer
Googlebot Rendering Timeline: CSR vs SSR
Testing What Google Sees With URL Inspection
The URL Inspection tool in Google Search Console is your primary diagnostic tool. Enter any URL and click “Test Live URL” to see:
- Screenshot: What the rendered page looks like to Googlebot
- HTML: The fully rendered HTML Google sees
- More Info: Console errors, resource load failures
Common findings that reveal JS SEO problems:
- Screenshot shows a loading spinner or blank page
- HTML source shows
<div id="root"></div>with no content - Console errors indicate failed API calls or CORS issues
- Critical JavaScript files are blocked by robots.txt
Also use the Rich Results Test (search.google.com/test/rich-results) to check if structured data embedded in JavaScript is being parsed correctly.
For deeper testing, use the Remote URL feature in Screaming Frog to compare rendered HTML against raw HTML. Any content that appears in rendered but not raw HTML is dependent on JavaScript execution.
Common JavaScript SEO Mistakes
Blocking JS files in robots.txt. The most destructive mistake. If Disallow: /*.js or Disallow: /static/ is in your robots.txt, Google can’t render your pages. Check GSC Coverage for “Blocked by robots.txt” to catch this.
Lazy-loading above-the-fold content. Content that requires user scroll to load won’t be seen by Googlebot. Never lazy-load H1 tags, primary body content, or main images.
Rendering critical metadata in JavaScript. Title tags and meta descriptions generated by JavaScript (rather than server-side) may not be seen in Wave 1. Use SSR for all metadata.
Links in JavaScript onclick handlers. <span onclick="goTo('/product')"> is not a crawlable link. Use real <a href=""> elements for all navigation that should be crawled.
Client-side redirects. window.location.href = '/new-page' executed via JavaScript doesn’t pass PageRank like a 301 redirect. Use server-side redirects for all permanent URL changes.
Key takeaway: Google can render JavaScript, but every millisecond of delay and every Wave 2 queue position costs you indexation speed. SSR and SSG eliminate the problem entirely — choose them for every page where organic search matters.
Frequently Asked Questions
Q: Can Google index content that’s loaded via AJAX calls?
A: Yes, if Googlebot can execute the JavaScript that triggers the AJAX call and the content appears in the rendered DOM. However, AJAX calls to authenticated APIs, CORS-restricted endpoints, or APIs that require cookies will fail.
Q: Does Next.js automatically fix JavaScript SEO problems?
A: Next.js gives you the tools to fix them (SSR, SSG, ISR), but you still have to use them correctly. A Next.js app using useEffect to fetch and render all content on the client side has the same CSR problems as a plain React app.
Q: How do I know if my JavaScript rendering is causing SEO issues?
A: Use URL Inspection in GSC. Click “Test Live URL” and compare the screenshot and HTML to what you see in a browser. Also check the Coverage report for “Discovered – currently not indexed” — this often indicates rendering delays.
Q: Is React bad for SEO?
A: React itself isn’t bad for SEO. A React app using SSR (Next.js) or SSG ranks just as well as any other properly-built site. React CSR without rendering mitigation is bad for SEO.
Q: What about Google’s Evergreen Googlebot — doesn’t it solve all JS SEO problems?
A: Evergreen Googlebot means Google uses an up-to-date version of Chrome for rendering. It doesn’t eliminate the Wave 2 delay or crawl budget consumption from JavaScript rendering. Those are architectural problems, not browser version problems.
Conclusion
JavaScript SEO is fundamentally an architecture question. CSR puts content behind a rendering delay that can cost you weeks of indexation. SSR and SSG solve the problem at the source by delivering complete HTML on the first byte.
If you’re building new, choose Next.js with SSR or SSG. If you’re inheriting a CSR app, implement dynamic rendering as a bridge and plan the migration to SSR within the next 6-12 months.
Test your rendering monthly with URL Inspection. The moment Googlebot sees a blank page when you see content, you have a problem worth fixing immediately.
Let Ignited Nepal Handle This
JavaScript SEO audits require both technical development knowledge and deep SEO expertise — a combination most agencies don’t have. We’ve diagnosed and fixed JavaScript rendering issues for SaaS platforms, e-commerce stores, and media sites, recovering indexation for thousands of pages within weeks of implementation.
→ Request a Free Technical SEO Audit
Written by the Ignited Nepal SEO team. We build organic search systems for businesses across Nepal, Australia, UAE, USA, UK, and beyond. ignitednepal.com