Server-side rendering: why AI crawlers can't read most React sites.

AI crawlers can't read most React sites because those sites send an empty page and build the content in the browser after the fact. The crawler asks for your page, gets a near-blank shell of JavaScript, and moves on before your content ever appears. Server-side rendering fixes this by building the full HTML on the server first, so the crawler gets real words on the first request.

This is one of the quietest ways a professional business disappears from search. Your site looks fine to you. It loads, it works, the design is clean. But the machines deciding whether to show you — Google, and now ChatGPT, Perplexity, and Google's AI Overviews — may be seeing nothing at all. If you paid for a modern-looking React build in the last few years, this is worth ten minutes of your attention.

What does "server-side rendering" actually mean?

Server-side rendering means your web server sends a complete, finished HTML page — with all your text already in it — the moment anyone or anything asks for it. The alternative, called client-side rendering, sends an almost-empty page plus a bundle of JavaScript. The browser then runs that JavaScript to draw your content. A human with a modern browser waits a moment and sees the page. A crawler in a hurry does not.

Think of it like a restaurant. Server-side rendering is a plated meal handed to you at the door. Client-side rendering is a box of ingredients and a recipe. A hungry diner will cook. A food critic with forty other restaurants to visit that hour will not — they will write down that your kitchen looked empty and leave.

Many React sites — and Vue and Angular sites — ship as the box of ingredients. That was the default for years. Frameworks like Next.js and Remix exist partly to fix this, but plenty of sites were built without them, or built with the rendering settings turned the wrong way.

Why can't AI crawlers read client-side React?

AI crawlers can't read client-side React because most of them do not run JavaScript, and the ones that do run it inconsistently and on a delay. When a crawler requests a client-side React page, it receives a shell — often a single empty div and a script tag. There is no headline, no body copy, no service description. To the crawler, your page about estate planning in San Diego contains zero words about estate planning.

Google's traditional crawler does run JavaScript, but it does so in a second pass that can lag by days or weeks, and it skips pages when its budget runs thin. That delay alone hurts. The bigger problem is the new wave of AI crawlers. GPTBot, Perplexity's crawler, and the bots feeding AI Overviews are far less patient. Many of them read raw HTML and nothing else. If your content only exists after JavaScript runs, these systems treat your page as blank.

So you end up in a strange spot. Your site works perfectly for the client sitting in your office looking at it on your laptop. It is invisible to the systems that decide whether a stranger searching "immigration lawyer near me" ever finds you. The gap between how your site looks to you and how it reads to a machine is where the traffic quietly leaks out.

How do I check if my own site has this problem?

You can check whether your site has this problem in about two minutes using a tool already built into your browser. The test tells you what a text-only crawler sees, which is close to what many AI systems see.

Here is the simplest version:

1. Open your site in Chrome.
2. Right-click anywhere on the page and choose "View Page Source" — not "Inspect." View Source shows the raw HTML the server sent, before any JavaScript runs.
3. Press Ctrl+F (Cmd+F on a Mac) and search for a sentence you know is on the page — your headline, or a line from your about section.
4. If the text is there, you are fine. If the search finds nothing and the source looks like a short block of script tags and one empty div, your content is being built in the browser. A crawler reading raw HTML sees none of it.

A second check: use Google's Rich Results Test or the URL Inspection tool inside Google Search Console. Both show you the rendered version Google eventually sees. If those look empty or thin, that is a strong signal.

When we run a Search Foundations audit, this is one of the first things we look at, because it sits underneath everything else. There is no point writing better service pages or chasing rankings if the page arrives at the crawler empty. Foundations first. The plumbing has to carry water before you argue about the taps.

What are the real fixes, ranked by effort?

The real fix is to make your server send finished HTML, and there are three common paths depending on how your site was built. You do not need to understand the code. You need to know the options so you can have a short, specific conversation with whoever maintains your site.

Path one — switch on server-side rendering in your framework. If your site already uses Next.js or Remix, the capability is built in and may already be paid for. Someone flipped a setting toward client-side rendering, or the pages were built as fully client-side by habit. Moving them to server-side rendering or static generation is a configuration change, not a rebuild. This is the cheapest fix when it applies.

Path two — add static generation for pages that rarely change. Your homepage, service pages, about page, and location pages do not change hour to hour. These can be generated once as plain HTML files and served instantly to everyone, crawler or human. This is fast, cheap, and durable. For most professional-services sites, the pages that matter for search are exactly the pages that barely change — which makes this a strong fit.

Path three — pre-render for crawlers with a middleware service. If a full framework change is too costly right now, a service like Prerender.io can detect crawlers and hand them a finished HTML snapshot while regular visitors keep the client-side experience. It is a patch, not a foundation. It adds a dependency and a monthly cost. But it can buy you visibility while you plan the proper fix.

A warning on effort estimates. A developer may tell you this is a big job. Sometimes it is. Often it is a settings change that takes an afternoon. Ask them to first run the View Source test on three of your key pages and tell you which are already rendering server-side. You may find the problem is smaller — or larger — than assumed. Get the diagnosis before you approve the invoice.

Does this connect to speed and rankings too?

Yes — server-side rendering usually makes your site faster for humans and clearer for machines at the same time, which is why it pays off twice. When the server sends finished HTML, the visitor sees real content sooner instead of staring at a blank screen while JavaScript loads and runs. That improves the numbers Google uses to judge your site.

Google measures how quickly your main content appears and how stable the page is while it loads. Client-side rendering tends to hurt both — the screen is empty, then everything pops in at once. We wrote about these measurements in Core Web Vitals: the three numbers that decide if Google bothers, and rendering strategy sits right at the center of them.

The business cost is easy to miss because it is invisible. A slow, empty-first-paint page does not throw an error. It just quietly loses the impatient visitor and the impatient crawler. We made the money argument in Why your slow site is a sales problem, not an IT problem, and rendering is often the root cause hiding under a speed complaint.

We saw this pattern with McShanes Solicitors. The site looked modern and the team was happy with it. Underneath, the pages were being built in the browser, and the content search engines needed was arriving late or not at all. Fixing how the pages were delivered was part of turning a good-looking site into one that actually got found. The design did not change. What the machines could read did.

What we won't tell you

We won't tell you every React site is broken — plenty are built correctly, and a two-minute View Source check will tell you which camp you are in. We also won't tell you server-side rendering fixes weak content or thin service pages. It makes sure the crawler can read what you wrote. If what you wrote is thin, rendering it faster only means the machine sees the thin page sooner. This is a foundation fix, not a content strategy.

One more honest caveat. If your traffic is strong and holding, and View Source shows your content, you may not need to touch anything. Do the test before you spend. The goal is a page that arrives finished, loads fast, and reads clearly — for the client and the crawler alike.