Why Google Cannot See Your JavaScript Site

A business pays for a modern website. It loads fast, it looks right, everything works. Months later it has almost nothing in Google, and nobody can say why — the pages are live, the sitemap is submitted, there is no noindex anywhere.

The usual cause is that the page a visitor sees and the page Google first receives are two different things. Your browser runs JavaScript and builds the page. Google's first look at a URL often does not.

What Google Actually Receives

When Googlebot requests a URL it gets the raw HTML the server sends. On a site built with React, Vue or Angular in the default setup, that raw HTML is nearly empty — a title, some script tags, and a single empty div. Everything a reader sees is assembled afterwards by JavaScript running in the browser.

Google can run that JavaScript. The problem is when. Rendering happens in a second pass, queued separately from crawling, and the queue is not instant — it can be hours or days behind. Until it runs, Google's record of your page is the empty div.

For a large site this compounds. Crawl budget is finite, rendering is expensive, and a site that needs rendering to say anything gets through its pages far more slowly than one that does not.

The Two-Minute Check

Do not use right-click then Inspect. That shows you the page after JavaScript has run, which is the view Google may not have.

Instead, view the raw source: Ctrl+U on Windows, Cmd+Option+U on a Mac. Then search the source for a sentence you can see on the page.

If the sentence is there, your content is in the HTML and this is not your problem. If the source is a few script tags and an empty div, it is.

The second check confirms it from Google's side. In Search Console, inspect the URL, open View Crawled Page, and read the HTML tab. That is literally what Google stored. If your headings and body text are missing there, you have found the issue — and the rest of your SEO audit can wait until it is fixed.

The Symptoms, Before Anyone Diagnoses It

This problem has a recognizable shape. Pages sit in Search Console as Discovered — currently not indexed for weeks. The ones that do get indexed show the same title and description as every other page, because the per-page metadata is also written by JavaScript. Search results quote nothing from the page, or quote the wrong thing.

And the site passes every other check. Fast, mobile-friendly, valid sitemap, clean robots.txt. That combination — everything correct and nothing indexed — is the tell.

Fix One: Server-Side Rendering

The server builds the full HTML for each request and sends it complete. JavaScript then takes over in the browser for interactivity. Google gets a finished page on the first look, with no rendering queue involved.

This is the right answer for anything with content that changes per user or per request — dashboards, logged-in areas, live inventory. It is also the most involved: you need a running server rather than static files, and the hosting cost and failure modes that come with one. Next.js is the common route for React sites.

Fix Two: Static Prerendering

At build time, every page is rendered once and written out as a real HTML file. Those files are served directly. The JavaScript still loads and the site still behaves like an application, but the first thing anyone receives — reader or crawler — is complete HTML.

For a marketing site, a blog, a service site, this is usually the better answer. There is no server to run, pages are served from a CDN so they are fast everywhere, and there is no rendering queue to wait on. The limit is that content is fixed at build time, so anything that changes needs a rebuild.

This site is built that way. React in the browser, every route written to static HTML at build time, so the title, description, headings, body and structured data are all present in the source before any script runs.

Fix Three: Dynamic Rendering, and Why to Avoid It

Detect the crawler, serve it a pre-rendered version, serve everyone else the JavaScript app. Google called this a workaround years ago and has since recommended against it.

It is worth knowing about because agencies still sell it, usually as a bolt-on service with a monthly fee. It means maintaining two versions of every page that have to stay identical, and the moment they drift you are serving crawlers something different from users — which is the definition of a problem you do not want. Treat it as a temporary patch on a site that cannot be changed, not a solution.

What This Costs to Fix

Honestly: it depends on how the site was built, and the range is wide. On a small site built with a standard framework, adding prerendering is a build-configuration change — days rather than weeks. On a site where routing, data loading and state were all written assuming a browser, it can mean reworking a substantial part of the front end.

The thing worth knowing before you ask anyone is that this is a build problem, not a content problem. No amount of writing, link building or keyword work moves a page Google is storing as an empty div. That is why it sits near the top of any list of techniques worth doing — not because fixing it improves a ranking, but because it removes the ceiling on everything else.

Before You Rebuild Anything

Run the two-minute check first. A good number of sites blamed for this do have their content in the HTML, and the real cause is something duller — a canonical pointing elsewhere, a crawl that has not reached the pages yet, or pages Google read and judged thin. Why your site is not showing on Google works through those causes in order.

If the source really is empty, the next question is which of the two real fixes suits your site, and that depends on how it was built rather than on preference. JavaScript SEO is the diagnosis and the plan; technical SEO covers the surrounding crawl and indexation work; and where the answer is a change to the build itself, that sits with web development.