Modern web frameworks (React, Vue, Angular) and single-page apps can rank in Google. They can also get silently buried. The difference is whether you understand Google's JavaScript rendering pipeline. Googlebot can execute JS, but it's slower, pickier, and more error-prone than processing static HTML. This page walks through how Google actually handles JavaScript, which rendering strategy to pick for your site, and the specific mistakes that break SPAs for search.
JavaScript isn't forbidden for SEO. But every line of JS between Googlebot and your content is a place something can go wrong. Plain HTML is boring. Plain HTML also ranks.
For content-heavy sites, JavaScript should enhance the user experience, not be the only way to deliver the content.
The key issue: the render step is delayed and uses more resources than plain HTML crawling. Google processes static HTML sites faster and more thoroughly than JS-rendered ones. A heavy SPA can wait days to get its full content indexed.
HTML pre-generated at build time. Deployed as static files. Fastest possible delivery, cheapest hosting, best SEO. Requires a rebuild when content changes. Frameworks: Astro, Next.js (SSG mode), Hugo, Jekyll.
Server generates full HTML on each request. Browser and Googlebot both see complete content immediately. Best for dynamic sites. Higher server cost. Frameworks: Next.js, Nuxt, SvelteKit.
Hybrid. Pages are static but can be regenerated on demand. Combines SSG speed with some dynamic flexibility. Next.js does this well.
Serve plain HTML to bots, JS-rendered content to users. Historically a workaround. Now considered a last resort. Can be viewed as cloaking if not implemented carefully.
Browser runs JS to build the page. Initial HTML is a skeleton (often an empty root div). Googlebot must execute JS to see content. Slow, fragile, content invisible until JS succeeds. Not recommended for content SEO.
Content only available after JS runs. If JS fails, content is gone. If it loads slowly, Google indexes the empty shell before the content.
Fix: use SSR or SSG. If CSR is your only option, server-render at least the critical content (title, H1, meta, hero text, main navigation).
// Bad. Google can\'t follow.
<div onclick="navigate(\'/page\')">Link</div>
// Good. Google follows.
<a href="/page">Link</a>/#!/page is an ancient SPA pattern. It never indexed cleanly. Always use clean URLs via the HTML5 history API.
If content lazy-loads only when the user scrolls, Googlebot may not see it. It doesn't scroll like a human. Use intersection observers that trigger on render, or pre-render critical content.
Title and meta description set via JS after initial load. Googlebot often indexes the pre-JS values (which are empty or placeholder). Set meta tags server-side or in the initial HTML.
Old content is only reachable by scrolling. Googlebot doesn't scroll. Paginate under the hood (/blog/page/2) so Googlebot can follow, or offer an "Older posts" link.
If your site is primarily content (blog, documentation, marketing), go static. Fewer moving parts, better SEO, faster delivery. Use an SSG framework, deploy to a CDN, and don't look back. The "we need React for the content site" default is usually wrong.
Open your top-ranking page in Chrome. Disable JavaScript in DevTools. Reload. Do you still see the title, the main content, the links? If yes, you're fine. If no, you have a JavaScript SEO bug that's worth fixing. Start with pre-rendering the H1 and body content server-side.
Next: Core Web Vitals deep dive, the detailed breakdown of the three performance metrics Google weights.