Why Your Next.js or React Pages Aren't Getting Indexed (JavaScript Rendering, Explained)

If your React or Next.js pages are crawled but never indexed, the cause is almost always the same: the content a search engine needs is not in the HTML it first receives. It arrives later, after JavaScript runs, and not every crawler waits or runs that code. This post explains exactly how that breaks indexing and how to fix it.

Why aren't my React or Next.js pages getting indexed?

React and Next.js pages fail to get indexed when their content is rendered on the client, so the HTML a crawler first downloads is an empty shell. Google can still index JavaScript, but it does so in two steps: it crawls the raw HTML immediately, then puts the page in a render queue where a headless browser runs your JavaScript before indexing. Google's own documentation states that "all pages with a 200 HTTP status code are sent to the rendering queue." If your content, links, or even your title depend on that second step, indexing is delayed, partial, or skipped entirely. Other crawlers, including the AI bots behind ChatGPT and Perplexity, do not run JavaScript at all, so for them a client-rendered page is simply blank. The fix is to put real content in the server response.

Does Google actually render JavaScript?

Yes. Google renders JavaScript using a headless, "evergreen" version of Chromium that tracks current stable Chrome, a setup it has used since 2019, which closes most of the gap with a real browser. A 2024 study by Vercel and MERJ, covering more than 100,000 Googlebot fetches, found that 100% of pages returning a 200 status were fully rendered regardless of JavaScript complexity, and that async-loaded content and React Server Components were indexed. So rendering capability is not the problem. The problems are timing and trust: Google still has to fetch your JavaScript and successfully execute it. Google's docs are explicit that "Google Search won't render JavaScript from blocked files or blocked pages," so a single Disallow on a script directory in robots.txt can quietly strip your content out of the index.

How long does Google take to render JavaScript?

The median delay is short, but the long tail is hours. In the 2024 Vercel and MERJ analysis of over 37,000 crawl-and-render pairs, the time between Google crawling a page and finishing its render broke down like this:

Percentile	Time from crawl to render
25th	about 4 seconds
50th (median)	about 10 seconds
75th	about 26 seconds
90th	about 3 hours
95th	about 6 hours
99th	about 18 hours

For most pages, rendering is nearly immediate. But the slowest 10% wait hours, and discovery of new links buried inside JavaScript compounds that. An older Onely experiment found Googlebot took roughly 9 times longer to follow a JavaScript-injected link than an HTML link (52 hours versus 25 hours for the first link). If your internal links only exist after rendering, your whole site crawls slower.

CSR vs SSR vs SSG vs ISR: which Next.js rendering mode is safe for SEO?

For indexing, prefer any mode that puts content in the initial HTML: SSR, SSG, or ISR. The danger zone is pure client-side rendering. Here is how the Next.js rendering modes compare:

Mode	Content in initial HTML?	Indexing risk
SSR (Server Components, getServerSideProps)	Yes	Low
SSG (getStaticProps, static export)	Yes	Low
ISR (static, periodically revalidated)	Yes	Low
CSR (SPA, data fetched in useEffect)	No	High

In the App Router, every component is a Server Component unless you add 'use client', so the default is SEO-safe: the markup renders to HTML on the server. A 'use client' component is still server-rendered on its first load. The specific failure is fetching data on the client after the component mounts, which moves that content out of the HTML and into a render Google may delay and AI crawlers will never run.

What pushes a React page into "Crawled – currently not indexed"?

A handful of recurring React and Next.js patterns put pages in this state, and most live entirely in client-side code:

• Content fetched in useEffect. It is absent from the initial HTML, so a crawler sees a loading spinner, not your article.
• Hash-based routing. Google's docs say to use the History API for routing. URLs built with # fragments are not crawled as distinct pages.
• Soft 404s. A client route that shows "Not found" but returns HTTP 200 looks like a thin, real page. Return a real 404 or inject a noindex.
• JavaScript-stripped noindex. Google's docs warn that when it sees noindex in the raw HTML, "it may skip rendering," so trying to remove that tag with JavaScript fails.
• Blocked scripts. Disallowing your JS bundle in robots.txt means the content that depends on it never renders.

If you are seeing this status across many pages, our deeper guide on why pages get crawled but not indexed covers the content-quality side of the same problem.

Do Bing and AI crawlers render JavaScript?

For practical purposes, assume they do not. Bing's own guidelines say it "is generally able to process JavaScript" but warns of "limitations to processing JavaScript at scale" and still recommends dynamic rendering. The bigger shift is AI search. Vercel's 2024 "Rise of the AI Crawler" analysis concluded that "none of the major AI crawlers currently render JavaScript." GPTBot (OpenAI) fetched JavaScript files in about 11.5% of requests but did not execute them; ClaudeBot (Anthropic) downloaded JavaScript in about 23.84% of requests "and never executes them." Perplexity parses static HTML only. The one notable exception is Google's Gemini, which rides Googlebot's rendering service. The takeaway for 2026: if your content is client-rendered, it can be invisible to AI Overviews and AI answer engines even when classic Googlebot can eventually render it.

How do I fix and verify JavaScript indexing?

Get your content into the server response, then confirm what crawlers actually receive. A practical order of operations:

1. Render critical content server-side. Use SSR, SSG, or ISR so the title, body, and internal links are in the initial HTML. Note that Google has deprecated dynamic rendering, calling it "a workaround and not a long-term solution."
2. Compare view-source to the rendered DOM. If content shows in your browser's DevTools but not in "View Source," it is client-rendered and at risk. View-source is the better proxy for what AI crawlers see.
3. Use URL Inspection in Search Console. "Test Live URL," then "View Crawled Page," to see the exact HTML Google rendered.
4. Unblock your JS and CSS in robots.txt, and use real URLs via the History API.
5. Monitor the outcome over time. Rendering is non-deterministic, so a page can index this week and slip next week after a deploy.

That last point is where most teams get caught: a framework upgrade or a new client component can silently move content out of the HTML, and you find out from a traffic drop weeks later. SearchOptimo re-checks the index status of every URL on a schedule and alerts you the moment a page falls out, so a bad deploy surfaces in a dashboard instead of in your analytics.

If indexing reliability matters for your stack, see whether SearchOptimo is worth it for your case, or start free and watch your own URLs.