Why your React website isn't ranking on Google (and the Next.js fix)

If your React website isn't ranking on Google, the most likely reason is that your server sends Google an almost empty page and leaves the browser to build the real content with JavaScript. Google can run that JavaScript, but it does so in a second, slower step, and anything that goes wrong in that step leaves the page thin, late or missing from the index. Next.js fixes this by building the full page on the server, so Google, Bing, ChatGPT and every other reader gets your text, titles and links in the very first response.

Below I explain why in plain words, show you how to check your own site in about two minutes, and compare the fixes, from the cheap patch to the full move to Next.js. I'm a freelance web developer in Gurugram, India, and I build websites on Next.js, React and WordPress for clients in India, the UK and the US, so I'll also tell you where I think the money is well spent and where it isn't.

Why is my React website not ranking on Google?

A plain React website usually sends Google a page with no content in it, and the content only appears after JavaScript runs in the browser. Google has to do extra work to see what your visitors see, and that extra work is where rankings get lost.

Here is what happens. When someone opens a normal website, the server sends a finished page: the heading, the paragraphs, the links, all written out in HTML (HTML is the basic text format every web page is made of). When someone opens a classic React site, the server sends something closer to an empty box and a note that says "download this JavaScript file and it will fill the box in". Developers call this client-side rendering, which only means the visitor's browser (the client) builds the page instead of the server.

For a person with a decent phone, the difference is a short wait. For a search engine, the difference is bigger. Google describes its own process in its JavaScript SEO basics guide as three phases: crawling, rendering and indexing. Crawling means fetching the page. Rendering means running the JavaScript to see the finished page. Indexing means storing the page so it can show up in search results.

With a server-built page, Google has what it needs after the first phase. With a browser-built React page, Google has nothing useful until the second phase finishes. The same Google guide says a page "may stay on this queue for a few seconds, but it can take longer than that", and it describes sites built this way as ones where "the initial HTML does not contain the actual content".

You can see this yourself. Open your site in Chrome, right-click and choose "View page source". That is the first response, the thing a crawler gets before any JavaScript runs. If you see your headings and paragraphs in there, you're in good shape. If you see a few lines of code, a line like <div id="root"></div> and nothing you'd recognise as your content, you've found your problem.

Can Google read a JavaScript website at all?

Yes. Google can run JavaScript and index React pages, and anyone who tells you Google "can't read React" is a few years out of date. The honest problem is delay and risk, and it gets worse for every other crawler that isn't Google.

The best public data on this comes from a study Vercel ran with the SEO firm MERJ. They analysed over 100,000 Googlebot fetches in April 2024, mostly on nextjs.org, and measured how long Google took to render each page after fetching it.

So half of the pages were rendered within 10 seconds. That's good news, and it kills the old myth that Google takes weeks to render JavaScript. But look at the tail. In the same study, one page in ten waited about 3 hours or longer, one in twenty waited about 6 hours or longer, and one in a hundred waited about 18 hours or longer. URLs with query strings (the part after a question mark, like ?colour=blue) did worse: about 8.5 hours at the 90th percentile.

Two things in that study matter more to a business owner than the timings.

First, the site they measured was mostly nextjs.org, a site run by the company that makes Next.js. Google rendered 100% of the HTML pages in the study. Your React site, built by a contractor three years ago with a very large JavaScript file and a few errors in the console, is not the site in the study. In Vercel's own comparison of rendering methods, client-side rendering is the only one marked as "might fail" for rendering and "poor" for crawl efficiency.

Second, the study found that when rendering does fail, the page may not be indexed, and links on it may never be discovered. A server-built page doesn't carry that risk, because there is no second step to fail.

Google's own advice lines up with this. The JavaScript SEO guide says "server-side or pre-rendering is still a great idea", because it makes the site faster for people and crawlers and because "not all bots can run JavaScript".

What are the most common React SEO problems?

The common React SEO problems are an empty first response, the same title on every page, links that aren't real links, error pages that claim to be fine, and slow loading. A site with one of these usually has several.

1. The first response is empty. Covered above. Everything else on this list makes it worse.

2. Every page has the same title and description. A basic React site has one HTML file for the whole site. That file has one title tag. Unless a developer added code to change the title for each page, Google sees "My App" or your company name on every URL. Even when the title is changed with JavaScript, it only changes after rendering. Google says you can set titles and descriptions with JavaScript, but apps that preview links, such as WhatsApp, Slack, LinkedIn and X, mostly read the first response and stop. That's why your link previews show a blank card or the home page text for every page.

3. Links are buttons in disguise. Google's guide on crawlable links is clear that it follows links that are an <a> element with an href attribute, pointing at a real web address. React makes it easy to build a menu out of clickable boxes that run a script when pressed. People can click them. Google can't follow them reliably, so the pages behind them are never found.

4. Pages live behind a # in the address. Some older React sites use addresses like yoursite.com/#/services. Google's JavaScript guide says "don't use fragments to load different page content". To Google, everything after the # is the same page, so your whole site looks like one URL.

5. Missing pages say "200 OK". When a page doesn't exist, a server should answer with a 404 status code (a status code is the short number a server sends to say how the request went). A React app usually answers 200, meaning "all fine", and then shows a "page not found" message with JavaScript. Google calls these soft 404s. Its troubleshooting guide for JavaScript tells developers to prevent them, so that error pages don't get indexed.

6. A "noindex" tag that JavaScript was meant to remove. A noindex tag tells Google not to list a page. Some React setups ship one in the first response and remove it later with JavaScript. Google's guide says it may skip rendering completely when it meets a noindex tag, so the removal never happens. The Vercel study confirmed it: pages with noindex in the first HTML were not rendered at all.

7. The site is slow on phones. Google measures real visitors with three numbers called Core Web Vitals. The targets on web.dev are a largest contentful paint (how long the main content takes to show) of 2.5 seconds or less, an interaction to next paint (how quickly the page reacts to a tap) of 200 milliseconds or less, and a cumulative layout shift (how much the page jumps around) of 0.1 or less, for 75% of page loads. A React site that has to download, read and run a large JavaScript file before showing anything struggles with the first of those on a mid-range Android phone.

8. Files are blocked or there's no sitemap. The Vercel study notes that when rendering fails, the cause is often JavaScript or data files blocked in robots.txt (the small text file that tells crawlers what they may fetch). It also found that an up-to-date sitemap largely removes the difference in how quickly pages are discovered. Plenty of React sites have neither a correct robots.txt nor a sitemap, because nothing in a basic React setup creates them for you.

9. Content that depends on the visitor. Google's troubleshooting guide says its renderer clears cookies and local storage between page loads and declines permission requests. If your page only shows prices after it reads a saved location, or only loads content after a cookie banner is accepted, Google sees the version with nothing in it.

How do I check if my JavaScript site is not indexed?

Check three things: what the first response contains, how many of your pages Google lists, and what Google saw when it rendered one of them. You don't need a developer for any of it.

1. 1

   View the page source

   Open a key page in Chrome, right-click, choose View page source and search for a sentence from the page. If the sentence isn't there, your content is built in the browser.

2. 2

   Count what Google has

   Search Google for site:yourdomain.com. Compare the rough number of results with the number of pages you actually have. A 60-page site showing 4 results has an indexing problem.

3. 3

   Inspect a URL in Search Console

   In Google Search Console, paste a page address into URL Inspection. Read the status, then open View crawled page to see the HTML Google stored.

4. 4

   Run a live test

   Click Test live URL and look at the screenshot and the list of page resources that could not be loaded. A blank or half-built screenshot is your answer.

5. 5

   Share a link

   Paste an inner page link into WhatsApp or Slack. If the preview shows the home page title or nothing, your titles are set by JavaScript only.

Google recommends the same tools. Its troubleshooting guide points to the URL Inspection Tool and the Rich Results Test, which show the rendered page, the resources that loaded and any JavaScript errors.

In Search Console's Pages report, two statuses come up again and again on React sites. "Discovered, currently not indexed" means Google knows the address but hasn't fetched it. "Crawled, currently not indexed" means Google fetched it and decided not to list it, which on a React site often means it found very little to read. I've written a separate guide on that second status: Crawled, currently not indexed: how to fix it.

One caution. A JavaScript site not indexed is one possible cause of poor rankings, not the only one. If your page source does contain your content and Search Console says the pages are indexed, then rendering isn't your problem. Look at the content itself, at competition for the search terms, at links from other sites and at speed. Moving to Next.js will not fix a page that says nothing useful.

Do ChatGPT and other AI assistants see a React website?

Mostly no. Google's crawler runs JavaScript, but when Vercel tested the crawlers behind ChatGPT, Claude and Perplexity in December 2024, none of them did, so a browser-built React site is close to invisible to them.

Vercel published a second study on this in December 2024, The rise of the AI crawler. Across Vercel's network in one month, OpenAI's GPTBot made 569 million requests and Anthropic's Claude crawler made 370 million. Together with Apple's and Perplexity's crawlers, that came to nearly 1.3 billion requests, a little over 28% of Googlebot's volume. And the finding that matters here, in Vercel's words: "none of the major AI crawlers currently render JavaScript". They download the JavaScript files sometimes, but they don't run them. (The same study found Apple's crawler does render JavaScript, as Google's does.) That study is about two years old now and these crawlers change, so treat it as the last good public measurement, and use the View page source test to stay on the safe side.

That means when a buyer asks an AI assistant "who makes custom packaging in Leeds" or "best accounting software for a small clinic", the assistant can only quote sites whose text is in the first response. If yours is a classic React site, there is nothing for it to quote.

I deal with this on my own site. mohitgoyal.in is an AI portfolio built on TanStack Start and React, where visitors ask questions in a chat interface. Because not every reader of the site is a person with a browser, I also publish a plain-text version of it, written for AI assistants, answer engines and crawlers that do not execute JavaScript.

If you want to know which AI crawlers your site currently allows or blocks, my free AI Crawler Checker reads your robots.txt and reports on 14 of them. It won't tell you whether your content is in the first response, though. For that, use the View page source test above.

How does Next.js fix a React site that isn't ranking?

Next.js fixes it by building each page on the server and sending finished HTML, so the content, the title and the links are all there before any JavaScript runs. Your site is still React. The visitor still gets the same smooth, app-like feel once the page has loaded.

Next.js is a framework built on top of React (a framework is a ready-made structure that handles the common jobs so a developer doesn't build them from scratch). It gives a developer three ways to produce a page, and a good build mixes them page by page.

In the Vercel and MERJ comparison, the first three all score "excellent" or "very good" for crawl efficiency and rendering time. Client-side rendering is the one marked "poor" on both.

After the server sends the finished page, Next.js loads the JavaScript and "wakes up" the page so buttons, menus and forms work. Developers call this step hydration. To Google, it doesn't matter, because the content was already there. To your visitor, it means text appears quickly and the interactive parts follow a moment later.

This is the approach Google itself recommends. Its page on dynamic rendering says sites should "use server-side rendering, static rendering, or hydration as a solution". The React team has moved the same way. In February 2025 it deprecated Create React App, the tool many older React sites were started with, and now recommends starting new projects with a framework such as Next.js or React Router.

What does not change in a move to Next.js: your design, your brand, most of your React components and the way the site feels. What does change: where pages are built, how addresses are handled, how data is loaded and where the site is hosted.

Related guide: Hire a freelance React developer: rates and what to check

What does Next.js SEO optimization involve beyond server rendering?

Next.js SEO optimization means using the tools Next.js gives you for titles, sitemaps, links, status codes, images and speed. Server rendering gets your content seen. These get it understood and ranked.

Moving to Next.js and doing nothing else is a common mistake. A Next.js site can still load all its content in the browser, if the developer copies the old React code across and marks every page as client-only. The page source test catches this too.

Here is what a proper job includes.

• A title and description for every page. Next.js has a built-in Metadata API that writes the title, description and social sharing tags into the page on the server. For pages that come from a database, such as products or blog posts, it can pull the title from the data.
• Sharing images. The same Next.js feature can generate the preview image that shows when a link is shared, per page.
• A sitemap and robots.txt that update themselves. Next.js can generate both from your content, so a new product or post is in the sitemap as soon as it's published.
• Real links. The Next.js link component produces a proper <a href> link, which is what Google's crawlable links guide asks for.
• Honest status codes. A missing page returns a real 404, and a moved page returns a real redirect.
• One address per page. A canonical tag tells Google which address is the main one when the same page can be reached in several ways. Google's guide prefers this to be in the HTML, not added by JavaScript.
• Structured data. This is a small block of code that tells Google "this is a product, this is its price, these are its reviews". It should be in the server response too.
• Images and fonts that don't slow the page. Next.js resizes images for each screen and loads them only when needed, which helps with the 2.5 second target for main content.
• Less JavaScript sent to the browser. With server components, parts of the page that don't need to be interactive send no JavaScript at all.

I keep a longer, more technical list in my Next.js technical SEO checklist, which is the one to hand to your developer.

Do I have to rebuild in Next.js, or are there cheaper fixes?

No, a full rebuild isn't the only option. There are four realistic routes, and the right one depends on how big the site is, how much it earns you from search and how long you plan to keep it.

A few honest notes on each.

Fixing the basics is worth doing first whatever else you decide, because some of it (real links, a sitemap, unblocked files) carries over to any future setup. It doesn't remove the wait in Google's render queue, and it does nothing for AI crawlers.

Prerendering services work, and they're quick to switch on. Prerender.io, the best known one, lists plans, at the time of writing, at $59 a month for 30,000 page renders, $169 a month for 100,000 and $419 a month for 500,000. Before you sign up, know that Google's own page on this technique, which it calls dynamic rendering, describes it as "a workaround and not a recommended solution, because it creates additional complexities and resource requirements". You're also paying every month, forever, for something a server-built site does for free. I'd treat it as a bridge while you plan something better, not a home.

Prerendering at build time is the underrated middle option. If your React site is a brochure site with a blog, a developer can often make it write out finished HTML for every page during the build. The React team's post on Create React App notes that its recommended frameworks can do static generation or server rendering page by page, so moving to one of those is not all-or-nothing.

Moving to Next.js costs the most upfront and solves the most. What moves the price:

• The number of different page layouts, more than the number of pages. Forty blog posts share one layout. Twelve unique landing pages are twelve jobs.
• How the site gets its data. Content typed into the code is simple to move. Content loaded from several services with logins is not.
• Whether there's a logged-in area. Accounts, carts and dashboards take more care than public pages.
• The state of the existing code. Clean, tested components move across quickly. A tangle doesn't.
• Whether addresses change. If they do, each old address needs a redirect.

I'm not going to quote a market price range here, because I couldn't find a source for React to Next.js migration prices that I'd trust enough to put a number on. I break the cost down by part in Create React App to Next.js migration: cost and SEO. On hosting, Vercel, the company behind Next.js, lists a free Hobby plan and a Pro plan at $20 a month, and Next.js also runs on Cloudflare and on your own server.

And there's a case where you should do nothing. If your React app is a tool behind a login (a dashboard, a booking admin, an internal system), nobody needs Google to index it. Keep it as it is, and put a small, server-built marketing site in front of it.

How long does it take to rank after moving a React site to Next.js?

There's no fixed time, and anyone who promises one is guessing. What I can tell you is the order things happen in and what speeds them up.

Once the new site is live, Google has to fetch each page again. Server-built pages can be indexed from that first fetch, so you skip the render queue. Submitting the new sitemap in Search Console tells Google which pages exist, and the Vercel study found that an up-to-date sitemap largely removes the gap in how fast pages are discovered. Pages that were never indexed before usually start appearing in the Pages report first. Rankings come after that, and they depend on the same things they do for any site: how good the content is and how strong the competition is.

The move itself has risks, and they're the same ones as any site move:

• Changed addresses without redirects. If /#/services becomes /services, or /product?id=42 becomes /products/blue-kettle, every old address must point to its new one. Missed redirects throw away whatever ranking you had.
• Content that got lost. Text that lived in a pop-up, a tab or a slider is easy to leave behind. Compare old and new pages side by side.
• Tracking that stopped. Analytics and ad tracking are wired differently in Next.js. Check that conversions are still being recorded on day one.
• A staging site left open to Google. Test versions should be blocked from search. The live version must not be. Both mistakes happen.
• Client-only pages carried over. As mentioned, a Next.js site can still build pages in the browser. Check the page source on the new site before launch, not after.

What should I ask a developer before paying for a React SEO fix?

Ask questions that show whether the developer understands the problem or is selling a rebuild by habit. The answers should be specific to your site.

1. "What does my page source contain right now?" They should look before they quote. If the content is already in the first response, the problem is somewhere else.
2. "Which pages will be static, which server-rendered and which stay client-side?" A good answer names your actual pages.
3. "Will any addresses change, and where's the redirect list?" You want to see a spreadsheet of old and new addresses.
4. "How will titles, descriptions and sharing images be set for each page?" And who can edit them later without a developer.
5. "What happens to my logged-in area?" It usually stays client-side, and that's fine.
6. "How will you prove it worked?" Expect: page source checks, Search Console URL Inspection on key pages, and the indexed page count over the following weeks.
7. "What will hosting cost each month, and who owns the account?" The hosting, domain and code repository should be in your name.
8. "Can I see a Next.js site you built, and its page source?" Then do the right-click test on it yourself.

Red flags:

• A promise of a specific ranking or a specific date.
• "Google can't read React", said as a flat fact. It can. The real argument is about delay, risk and other crawlers.
• A quote with no look at your Search Console data.
• A plan that installs a prerendering service and calls it a permanent fix.
• No mention of redirects.
• A rebuild proposed for an app that sits entirely behind a login.

How can I help with a React site that isn't ranking?

I build marketing sites and web apps on Next.js, React, TypeScript and Tailwind CSS, server rendered and deployed on Vercel or Cloudflare. That's my Next.js and React websites service, and moving an existing React site across is part of it.

I also do the search side as its own job. My technical SEO and Core Web Vitals work covers schema markup, sitemaps, redirects, security headers and Google Search Console on Next.js and WordPress sites, so I can do the diagnosis first and only suggest a rebuild if the diagnosis calls for one.

What I'd do with your site, in order: read the page source and your Search Console reports, tell you plainly whether rendering is the cause, and lay out the options from the table above with what each would involve for your pages. Sometimes the answer is a few days of fixes on the React site you already have. Sometimes it's a move to Next.js. I'd sooner tell you the first when it's true.

I'm one person, based in Gurugram, India, and I work with clients remotely. If a project needs design or a mobile app as well, I bring in people I trust and stay your single point of contact.

What should you do next?

Do the two-minute check first. Right-click your most important page, choose View page source and search for a sentence you can see on the page. Then search Google for site:yourdomain.com and count.

If the sentence isn't in the source and the count is low, send me the address through the contact page with a line about what the site is for. I'll look at the source and tell you what I'd fix first.