Your React Site Serves an Empty Page to Google. Here Is How to Check.

Why an empty shell is a real problem

A client-side rendered application ships an almost empty HTML document and builds the page in the browser. For a visitor this is invisible and often excellent. For everything that reads your page without being a browser, it is the difference between a page and a stub.

The confusing part is that this does not fail cleanly. Google will frequently index a client-rendered page eventually, so the site is not absent from search and there is no error to point at. What you get instead is a set of soft symptoms: pages taking far longer than expected to appear, new content sitting unindexed for weeks, previews breaking when links are shared, and a Search Console report that shows a rendered page while the performance data says nobody found it.

It is not that crawlers cannot see your page. It is that seeing it costs them more, so it happens later, less often, and not at all outside Google.

Who renders JavaScript and who does not

This is the part worth being precise about, because the blanket claims in both directions are wrong.

• Google renders JavaScript. It does so in a second pass, queued after the initial crawl, and the delay varies from minutes to considerably longer depending on how much it wants to spend on your site. Rendering is a budget, and you are competing for it.
• Bing renders, with similar caveats and generally less patience.
• Facebook, LinkedIn, X, WhatsApp and Slack crawlers do not render JavaScript. They read the HTML response, look for Open Graph tags, and stop. If your tags are injected client-side, they do not exist.
• Most AI and answer-engine crawlers do not render either. They fetch and parse. Content that appears only after hydration is content they never see.
• Smaller search engines, feed readers, link checkers, monitoring tools — almost none of them render.

So the honest summary is: Google will probably cope, slowly. Nothing else will. And the share of discovery that happens outside Google's index has been growing, not shrinking.

The two-minute test

1. Open the page and copy a distinctive sentence from the middle of the visible content.
2. Press Ctrl+U (Cmd+Option+U on a Mac) to view source. This is the raw response, before JavaScript.
3. Press Ctrl+F and search for your sentence. Present means it is server-rendered. Absent means it is not in the response.
4. Search for your <title> and og:image too. These matter independently — a page can have server-rendered tags and client-rendered body content, which is a much better position to be in.

Note what this test does not do: it does not tell you Google has failed to index the page. Google may render it fine. It tells you what arrives in the first response, which is what every non-rendering consumer of your page gets, and which determines how cheap you are to crawl.

The symptoms, and what they mean

“Our link previews never show an image”

The clearest signal of all. Social crawlers do not render, so if the preview is empty while the page looks fine in a browser, your Open Graph tags are being added client-side. This one is worth fixing on its own merits even if search is going well.

“New pages take weeks to appear in Google”

Consistent with render queueing. The initial crawl gets a shell with nothing to index, and the page waits for the rendering pass before it means anything. On a large site this compounds, because the render budget is shared.

“Search Console shows the page rendered fine”

The URL Inspection tool renders on demand, with more patience than the indexing pipeline has at scale. It answers “can this be rendered?” not “is this being rendered promptly in production?” Useful, but not the reassurance it appears to be.

“ChatGPT and other AI tools do not know our site exists”

Very likely this, at least in part. Most such crawlers fetch and parse without rendering. An empty shell gives them nothing, no matter how good the content is once it loads. This interacts with everything in how content is structured for extraction — structure cannot help content that never arrives.

Four fixes, ranked by effort

1. Get the meta tags into the HTML (hours)

The cheapest meaningful win. Even if the body stays client-rendered, having title, description, canonical and Open Graph tags in the served response fixes every social preview and gives crawlers something real on the first pass. Most frameworks have a first-party way to do this.

2. Prerender the pages that matter (days)

Generate static HTML at build time for the routes that need to be found — homepage, services, blog, landing pages. Application routes behind a login can stay client-rendered, because nothing is trying to index them anyway. This is the best effort-to-benefit ratio on the list for most sites.

3. Server-side rendering (weeks)

The complete answer, and a genuine architectural change with real operational cost. Worth it when organic search is a primary channel and the site is large enough that route-level prerendering becomes unmanageable. Not worth it for a five-page marketing site that could have been static.

4. Dynamic rendering (avoid unless stuck)

Serving prerendered HTML to crawlers and the app to browsers. Google has explicitly described this as a workaround rather than a recommendation, it requires user-agent sniffing, and it means maintaining two versions of the truth. Use it as a bridge, not a destination.

Why check with a tool that reads the raw response

Most page checkers analyse the rendered DOM, because that is easier and produces friendlier results. It also means they cheerfully report a title, a description and full content on a page that serves none of it — which is precisely backwards for this problem.

The SEO page checker here fetches the raw HTML and analyses that. When it finds an empty shell it says so directly, rather than marking you down on twenty separate checks for content that exists but is not in the response. It never executes the fetched page — which is both a safety property and the reason its answer is the one that matters here.

And when the fetch is blocked, by bot rules or a login or a staging password, there is a paste tab: view source, copy, paste, identical analysis. That fallback matters more than usual for this particular check, because sites still in development are exactly the ones where you want to catch this.

None of it costs anything, needs an account, or stores what you check.

FAQ