In short: JavaScript SEO is the practice of making JavaScript-rendered websites crawlable, indexable and rankable. Google renders JavaScript – but with a render budget, delayed indexing and pitfalls around client-side routing, lazy content and links. In 2026, with JS frameworks everywhere, getting rendering right is the difference between ranking and invisibility. This guide covers how Google handles JS, the rules, testing methods and the fix list.
Last updated: October 2026.
Your beautiful React/Vue/Angular site might be invisible to Google. Not because Google can’t run JavaScript – it can – but because rendering happens in a second wave, days after the initial crawl, with a limited budget. Content that only exists after JavaScript runs gets indexed late, partially, or never. Here’s how to make JS sites rank.
How Google handles JavaScript
Two-wave indexing. Wave 1: Google crawls the raw HTML immediately. Wave 2: the page enters the render queue, gets rendered (sometimes days later), and the rendered content is indexed. Anything only in the rendered version waits for wave 2 – and wave 2 has a budget.
The render budget is real. Google won’t render everything, every time. Heavy, slow or complex pages get rendered less often – meaning updates take longer to appear in the index, or never do.
Other crawlers are worse. Bing renders too, but less reliably. Social crawlers (Facebook, LinkedIn, Twitter) and many SEO tools don’t run JavaScript at all – your meta tags must be in raw HTML or link previews break.
The JavaScript SEO rules
1. Critical content in server-rendered HTML. Headings, body copy, product info, prices – if it matters for rankings, it should be in the initial HTML (SSR, SSG or pre-rendering). Client-side rendering for critical content is gambling with wave 2.
2. Links must be real links. Google discovers pages through anchor href links. JavaScript click handlers, buttons that navigate via JS, infinite scroll without paginated URLs – all hide pages from crawlers. Use real anchor tags with real hrefs, always.
3. Don’t block rendering resources. robots.txt must allow JS/CSS files. Blocked resources = broken renders = misjudged pages.
4. Metadata in raw HTML. Titles, meta descriptions, canonicals, hreflang, Open Graph tags – in the server response, not injected by JS. Social and SEO crawlers that skip JS need them upfront.
5. Lazy content, carefully. Lazy-loaded images below the fold: fine. Lazy-loaded content (tabs, accordions hiding key copy): risky – if Google doesn’t trigger the interaction, the content doesn’t exist for indexing. Keep important copy visible by default.
6. Status codes matter. SPAs that serve 200 for everything break error handling: 404 pages must return 404 status, redirects must be server-side 301s. Soft-404 SPAs confuse crawlers and waste budget.
Rendering options, ranked
Server-Side Rendering (SSR). HTML generated per request on the server. Best for dynamic content; costs server resources. The gold standard for JS SEO.
Static Site Generation (SSG). HTML pre-built at deploy time. Fastest option; ideal when content doesn’t change per request. Best of both worlds for content sites.
Pre-rendering. Serve pre-rendered HTML to crawlers, JS app to users. Pragmatic retrofit for existing SPAs – but maintain parity carefully; cloaking risks if versions differ meaningfully.
Client-Side Rendering (CSR) only. Empty HTML shell + JS builds the page. Works for apps behind login; terrible for public SEO content. Avoid for anything that should rank.
Hydration (SSR + CSR). Server HTML for first paint and crawlers, JS takes over for interactivity. The modern default for frameworks like Next.js and Nuxt – and the right one.
How to test JavaScript SEO
- View source vs inspect. View-source shows raw HTML (wave 1); Inspect shows rendered DOM (wave 2). Critical content must appear in view-source.
- URL Inspection tool. Search Console’s “Test Live URL” → View Tested Page → screenshot + HTML tabs show exactly what Google rendered. Compare against expectations.
- Mobile-Friendly Test. Renders the page like Googlebot smartphone – quick rendering sanity check.
- Disable JavaScript. Browse with JS off: whatever remains is your wave-1 baseline. If the page is an empty shell, you have a problem.
- Crawl as Googlebot. Screaming Frog in JS-rendering mode approximates the two-wave process and surfaces what raw crawls miss.
Common JavaScript SEO failures
- Content in tabs/accordions never indexed. If it needs a click to appear, assume crawlers won’t click it.
- Infinite scroll without pagination. Replace with paginated URLs + proper links, or implement scroll with History API URL updates and accessible page URLs.
- Hash URLs (#/page). Fragments aren’t sent to servers and create crawl chaos. Use the History API for clean URLs.
- Client-side redirects. JS window.location redirects are unreliable for crawlers. Server-side 301s, always.
- Slow rendering. Pages taking 5+ seconds to become interactive exhaust render budget. Performance IS a JS SEO factor – see Core Web Vitals.
- Blocking JS in robots.txt. Still happens. Check.
JavaScript SEO checklist
- Critical content present in raw HTML (view-source test)
- All internal links are real anchor href links
- Titles, metas, canonicals, OG tags server-rendered
- JS/CSS allowed in robots.txt
- Proper status codes (404s return 404)
- Server-side redirects, not JS redirects
- Clean URLs via History API, no hash routing
- Rendered HTML verified in URL Inspection tool
- SSR/SSG/hydration – not CSR-only – for public content
- Performance budget respected (render budget is finite)
JS + SEO can coexist
JavaScript isn’t the enemy of SEO – careless JavaScript is. Server-render the critical stuff, link properly, test what Google actually sees, and JS frameworks rank just fine. The teams that struggle are the ones who discover wave 2 exists after launch.
At Vans Marketing, technical audits include full rendering analysis – raw vs rendered diffs, crawl-path verification, fix prioritisation. Get a free audit and see what Google really sees on your site.
JavaScript SEO – frequently asked questions
What is JavaScript SEO?
JavaScript SEO is the practice of ensuring JavaScript-rendered websites are properly crawled, rendered, indexed and ranked by search engines – covering server rendering choices, link structures, metadata handling, and testing what crawlers actually see.
Can Google crawl JavaScript?
Yes – Googlebot runs JavaScript and indexes rendered content. But rendering happens in a delayed second wave with a limited budget, so JS-only content gets indexed late, partially, or sometimes never. Critical content should be server-rendered.
Is React bad for SEO?
Not inherently. React with SSR/SSG (Next.js) ranks perfectly well. The problem is client-side-rendered React SPAs where content only exists after JavaScript runs – that’s what struggles. The framework isn’t the issue; the rendering strategy is.
How do I check what Google sees on my JS site?
Search Console’s URL Inspection tool (Test Live URL → screenshot/HTML tabs), view-source vs inspect comparison, browsing with JavaScript disabled, and JS-rendering crawls in Screaming Frog.
Should I pre-render pages for crawlers?
Pre-rendering is a valid retrofit for existing CSR SPAs, but SSR/SSG is cleaner long-term. Whatever you choose, keep crawler and user versions in parity – meaningful differences risk cloaking penalties.