JavaScript SEO

Why JS rendering matters

• Googlebot can render JS but in a delayed second wave — content may take days/weeks to be indexed vs hours for HTML
• Other crawlers (Bingbot, AI crawlers like GPTBot, PerplexityBot, ClaudeBot) have weaker JS support — often see only initial HTML
• AI search engines preferentially cite content visible in initial HTML
• Core Web Vitals suffers when critical content depends on client-side JS

Rendering strategies (best to worst for SEO)

1. Static Site Generation (SSG) — pre-rendered HTML at build time. Best for content sites, marketing pages, blogs. Astro, Next.js Static, Gatsby.
2. Server-Side Rendering (SSR) — HTML generated on each request. Best for dynamic content (e-commerce, user-specific data). Next.js SSR, Remix.
3. Incremental Static Regeneration (ISR) — pre-render + revalidate. Good hybrid.
4. Client-Side Rendering (CSR) with prerendering — CSR + pre-rendered HTML snapshots for bots. Acceptable.
5. Pure CSR (no fallback) — content only visible after JS execution. Worst for SEO/AI search.

Diagnostic signals

• Google Search Console URL Inspection → “Test live URL” → “View tested page” → check if content appears in rendered HTML
• view-source: in browser shows raw HTML — if your content isn’t there, crawlers may miss it
• Screaming Frog rendering mode set to “JavaScript” — compare crawl with content vs without

Common patterns to avoid

• Critical content (h1, primary copy, internal links) loaded via fetch after page render
• Lazy-loaded content that depends on scroll/interaction
• Infinite-scroll feeds without ?page=N URLs
• Single-page apps (SPAs) without prerendering for bot user-agents