Optimizing JavaScript Rendering for SEO
Case: an e-commerce store on React with 10,000 products — Google indexed only 200 pages. Cause: content generated by JS, bot didn't wait for full rendering. Solution: we implemented ISR (Incremental Static Regeneration) on Next.js. Within two weeks, indexed pages grew to 8,000, organic traffic doubled. We've learned to solve such problems: after an audit, we implement SSR or static generation, and indexing recovers in a few days.
Google Search Central: "JavaScript SEO techniques ensure indexing of JavaScript-generated content."
Googlebot processes JavaScript through headless Chrome (WRS — Web Rendering Service), but with a delay: HTML is indexed immediately, while JS rendering enters a queue. For SEO, this means content available only after JS execution may be delayed by days or weeks. This is especially critical for SPAs and sites with dynamic content. The difference in indexing speed between SSR and CSR can be 3–5 times. Average indexing delay for CSR is 2–3 weeks, for SSR — 1–2 days.
How Google Handles JavaScript
Stage 1: Crawling — Googlebot downloads the raw HTML. Stage 2: Rendering queue — the page is queued for JS rendering. Delay: from hours to weeks.
Stage 3: Indexing after render — content after JS execution enters the index.
Yandex, Bing, DuckDuckGo render JS significantly worse or not at all. Therefore, it is important to pre-render content for bots.
How We Diagnose Rendering Issues
We use Google Search Console → URL Inspection → View Crawled Page. If important content is present in the final DOM but not indexed, the issue is not rendering but the markup itself.
Screaming Frog with JS rendering — we compare HTML source with rendered DOM. Example script for comparison:
# Compare source HTML with rendered (via curl vs puppeteer) curl -s https://site.com/page | grep -c "product-title" # vs node -e "const puppeteer = require('puppeteer'); (async () => { const browser = await puppeteer.launch(); const page = await browser.newPage(); await page.goto('https://site.com/page'); await page.waitForSelector('.product-title'); const count = await page.$$eval('.product-title', els => els.length); console.log(count); await browser.close(); })()" Why We Recommend SSR for SEO
SSR — server-side rendering, the bot receives ready HTML without executing JS. It's the standard for SEO-oriented projects. SSR allows indexing content 3–5 times faster than CSR.
Next.js:
// getServerSideProps — render on each request export async function getServerSideProps({ params }) { const product = await fetchProduct(params.id) return { props: { product } } } // getStaticProps — build at deploy time (faster) export async function getStaticProps({ params }) { const product = await fetchProduct(params.id) return { props: { product }, revalidate: 3600 // ISR: update every hour } } SSG, other things being equal, reduces server load by 5–10 times compared to SSR.
When to Use SSG
For content with infrequent updates, SSG gives better performance and load speed. Incremental Static Regeneration (ISR) allows updating pages without full rebuild.
How Prerendering Can Help SPAs
If SSR is not feasible, prerendering generates static HTML snapshots for bots.
# nginx: serve prerendered HTML to bots, SPA to humans map $http_user_agent $is_bot { ~*(googlebot|bingbot|yandex|baiduspider|facebookexternalhit) 1; default 0; } server { location / { if ($is_bot = 1) { proxy_pass http://prerender-service:3000; break; } try_files $uri /index.html; } } Comparison of Rendering Methods
| Method | Load Speed | SEO-friendliness | Implementation Complexity | Server Resource Consumption |
|---|---|---|---|---|
| CSR (SPA) | High (client) | Low | Low | Low |
| SSR | Medium | High | Medium | High |
| SSG/ISR | High (CDN) | High | High | Low |
| Prerendering | High | Medium | Medium | Medium |
Common Problems and Their Solutions
| Problem | Solution |
|---|---|
| Content not indexed | Implement SSR or SSG |
| Slow loading due to JS | Code splitting, lazy loading for images |
| Meta tags invisible to bots | Move title/description to HTML |
How to Assess Impact on Core Web Vitals?
Long TBT (Total Blocking Time) due to heavy JS degrades the Page Experience signal. Use Chrome DevTools Performance API to identify long tasks. Analyze loading and split heavy scripts into chunks. In practice, we've reduced TBT from 350 ms to 80 ms with code splitting and preloading critical JS.
Critical JS SEO Rules
Content in the raw HTML is more important than content in JS. For example, title must be in HTML, not generated by script. Use <a href> for links, not just onClick. Apply lazy loading only for images — text content should be immediately available. Use JSON-LD for structured data.
<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "Product", "name": "iPhone 15 Pro", "offers": { "@type": "Offer", "price": "price-on-request", "priceCurrency": "USD" } } </script> // Lazy loading only for images, not for text <img src="product.jpg" loading="lazy" alt="Optimizing JavaScript SEO"> What's Included in Our Work
- Rendering audit and indexing issue identification — using Search Console, Lighthouse, Puppeteer.
- Selection of optimal method: SSR, SSG, ISR, or prerendering — tailored to your architecture.
- Implementation on Next.js or Nuxt.js — with caching and revalidation configuration.
- Core Web Vitals optimization — reduce TBT and LCP.
- Testing via Google Search Console and Rich Results Test — ensure content is indexed.
- Documentation and access handover.
Our experience: 10+ years in web development, over 40 successful projects improving indexing. We guarantee that after implementation, content will be indexed within a week. Clients save on advertising through organic traffic.
Timeline
Audit and turnkey SSR/ISR implementation — from 3 to 10 business days. We'll give an accurate estimate after analyzing your project. Get a consultation — we'll assess your current situation free of charge. Contact us to discuss details. Request a free rendering audit for your site.