JavaScript SEO: Crawling and Rendering on SPA, SSR and Next.js Sites
A React, Vue or Angular site can look flawless in the browser while Search Console shows pages with empty titles or no indexing at all. The problem is usually not the content but when and where it is produced.
This article covers the difference between client-side (CSR), server-side (SSR) and static (SSG) rendering, how Google processes JavaScript, how to test with URL Inspection, and the mistakes I see most often on SPA and Next.js projects.
Short answer: Google can render JavaScript with an up-to-date Chromium, but rendering is a separate stage and does not work equally reliably on every page. Serving the main content, title, canonical and robots tags in the initial HTML response (SSR or SSG) is the safest route. Confirm the result with the rendered HTML in URL Inspection's live test.
What is the difference between CSR, SSR and SSG?
The key question is whether the first HTML the browser receives contains the content. With CSR the server sends an almost empty shell and JavaScript draws the content later. With SSR the HTML is built on the server for every request. With SSG pages are generated at build time and served as files.
| Method | Content in initial HTML | SEO risk | Good fit for |
|---|---|---|---|
| CSR (client-side) | None or very little | High: depends on rendering | Logged-in dashboards, app screens |
| SSR (server-side) | Yes | Low | Frequently changing product, price, stock pages |
| SSG (static) | Yes | Low | Blog, guides, company pages |
| ISR / hybrid | Yes (from cache) | Low | Many pages that change rarely |
In the Next.js App Router, components render on the server by default; trouble usually starts when critical content lives in "use client" components and data fetched in the browser. I cover general crawling and indexing logic in the technical SEO guide.
How does Google crawl and render JavaScript?
Google's JavaScript SEO documentation describes three phases: crawling, rendering and indexing. The flow below summarises how a URL moves through them.
- robots.txt checkBlocked URLs are not crawled, and JavaScript is not run on blocked pages or files.
- CrawlingGooglebot fetches the initial HTML and discovers the links in it.
- Render queuePages returning 200 are queued; the wait may be a few seconds or longer.
- RenderingAn evergreen Chromium runs the page, and new links in the result are crawled too.
- IndexingThe rendered HTML is evaluated and an indexing decision is made.
Two details cause a lot of work in practice. First, the documentation says rendering might be skipped for pages with a non-200 status code. Second, if the initial HTML contains noindex, Google may skip rendering and JavaScript execution, so removing noindex with JavaScript may not work.
The most common mistakes on SPA and Next.js sites
Most of the JavaScript issues I find in audits fall into these six groups:
Most of these show up in Search Console as "Crawled – currently not indexed" or soft 404s; for diagnosis, use the grouping method in fixing crawled but not indexed pages. On the resource-blocking side, the robots.txt configuration article will help.
How to test rendering with URL Inspection
"View source" shows the initial HTML, developer tools show your own browser's DOM. To see what Google sees, the live test in Search Console's URL Inspection tool is the most accurate source. According to the help documentation, a screenshot of the rendered page is only available in a live test.
- In URL Inspection, click "Test live URL", then open "View tested page".
- In the HTML tab, are the main text, h1, title, meta description and canonical present?
- Does the screenshot show the content area filled in, or a loading spinner?
- Under More info, check page resources that failed to load and JavaScript console messages.
- For pages you do not own, use the Rich Results Test, which also shows rendered HTML.
- Repeat the check on a few examples from every template (product, category, blog).
Large JavaScript bundles also put pressure on LCP and INP; for thresholds, see the Core Web Vitals 2025 guide.
Is dynamic rendering still an option?
Dynamic rendering, serving pre-rendered HTML to bots and the JavaScript version to users, was once widely recommended. Google's current documentation is clear: dynamic rendering is a workaround and not a recommended solution.
As the documentation notes, not every bot runs JavaScript, so a complete initial HTML also matters when AI assistants fetch your pages.
Which rendering method for which page?
The practical rule: every page that expects search traffic should carry its content in the initial HTML. Logged-in dashboards, cart and account screens can stay on CSR.
- Product and category pages: SSR or ISR with a short revalidation window. Price and stock should be in the HTML too.
- Blog posts and guides: SSG. Generate structured data on the server as well; the schema generator gives you a JSON-LD draft.
- Filter and sort screens: real URLs for combinations you want indexed, parameter control for the rest.
- User-specific screens: CSR; they usually sit behind a login, so noindex is rarely needed.
On large stores this decision should be made per template; the ecommerce SEO guide offers a good framework for filters and variants. Trimming heavy bundles and setting a performance budget is part of my performance and growth service.
If you want to know which templates on your Next.js or SPA project carry risk, I can run a rendering audit as part of SEO consulting; a short call is a good place to start.
Frequently Asked Questions
Can Google index a site built with React?
Yes, Google can render JavaScript and many React sites are indexed without trouble. The risk is that content only exists after rendering, which may be delayed or incomplete. SSR or SSG on important pages removes most of that risk.
How long does a page wait in the render queue?
Google's documentation says a page may stay in the queue for a few seconds, but it can take longer. No exact time is given. That uncertainty is another reason to serve frequently updated content in the initial HTML.
Does infinite scroll hurt SEO?
Googlebot does not scroll or click, so products loaded only on scroll may never be discovered. Offering paginated links with real URLs for each chunk alongside infinite scroll is a safe approach.
If I use Next.js, am I safe from JavaScript SEO problems?
Next.js makes server rendering easier when set up well, but it does not solve everything by itself. Client components that fetch data in the browser, missing metadata and wrong status codes are common on Next.js sites too.
Is structured data added with JavaScript read?
Google can read JSON-LD from the rendered DOM. Still, generating structured data on the server reduces dependence on rendering; confirm the result with the Rich Results Test.
8+ years of hands-on SEO and GEO experience across 150+ projects in e-commerce, SaaS, healthcare and local business sectors. Writes based on real client data, not theory.