Does Google index pages that require JavaScript?

Yes, Google renders JavaScript in a second pass and can index client-rendered pages. The costs are delay and rationing: the first pass sees no content or links, rendering is queued according to how valuable a page appears, and pages that look empty compete poorly for it. Many other crawlers, including several AI crawlers, do not execute JavaScript at all.

Is the JavaScript-disabled test a reliable SEO check?

It is a smoke alarm, not an instrument. It correctly flags that content is client-rendered, but it cannot show crawler-specific behavior: sites serving prerendered HTML to bots fail the browser test while passing the crawler one, and bot-protected sites can pass your test while blocking real crawler requests. Comparing a raw fetch against a rendered version measures what the test approximates.

Should I add a noscript tag?

As a courtesy, yes — a brief message beats a silent white screen. But understand its limits: noscript content only renders for browsers with JavaScript actually disabled. Users whose scripts failed to load have JavaScript enabled, so they never see it, and it contributes nothing to how crawlers evaluate the page. It fixes the smallest slice of the problem.

Why do some users see a blank page even with JavaScript on?

Because the scripts arrived and then failed: a startup exception with no error boundary, a deploy that changed bundle filenames while cached HTML still requested the old ones, or a content security policy blocking the site's own scripts. Client-rendered architectures turn these failures into fully blank pages, since there is no server-rendered content underneath to fall back on.

Is progressive enhancement still worth doing?

The full old-school version — every feature working without JavaScript — is rarely justified for modern applications. The durable core of the idea absolutely survives: meaningful content and navigation in the server response, JavaScript layering interactivity on top. Server-rendered frameworks deliver exactly that shape by default, which is why they answer both the search and the resilience version of this problem.

HomeFixBlank without JavaScript

Blank without JavaScript: one symptom, two different problems.

Short answer

A page that goes blank without JavaScript is rendered entirely in the browser: the server sends an empty shell and scripts build the rest. That's two problems in one — crawlers see nothing on their first pass, and any user whose scripts fail to load sees that same white screen. Server-rendering the content addresses both.

Someone — you, an auditor, a nervous stakeholder — switched JavaScript off, reloaded, and got a white page. Before anyone declares an emergency, it's worth being precise about what that test measured, what it didn't, and which of the two problems it revealed actually applies to you.

Is this your situation?

!With JavaScript disabled, the page shows pure white — or only a “please enable JavaScript” line

!An SEO audit flagged “content requires JavaScript” and now you're verifying it

!Occasional real-user reports of a blank page that “fixes itself on refresh”

!The site is a SPA (React, Vue, Angular) built without a server-rendering layer

!Search Console screenshots sometimes show partial or empty renders

!You're deciding whether this is worth fixing before a launch or migration

The two problems inside the one symptom

The search problem.Crawlers read the raw response first — the version your test just showed you. If it's blank, the first pass finds no content to evaluate and, worse, no links to follow. Rendering may come later; for some crawlers, including many AI crawlers, it never comes at all.

The resilience problem.Almost nobody browses with JavaScript deliberately disabled — that's the true part of the usual dismissal. But "JavaScript failed to arrive or execute" happens constantly: a dropped connection mid-load, a CDN hiccup, an ad blocker eating a bundle it mistook for tracking, a browser extension breaking, a bad deploy. On a fully client-rendered site, every one of those users gets the exact white screen your test produced. The no-JS test isn't simulating a rare preference; it's simulating your site's failure mode.

Why the distinction changes the fix

If only search matters — say the blank page is a logged-out shell for an app — the fix is scoped to the public pages that need indexing. If resilience matters, the fix extends past rendering into failure handling: error boundaries, bundle monitoring, a noscript message. Teams that skip this step either over-build (server-rendering an internal tool for no one) or under-build (fixing SEO while users still get white-screened by a bad deploy).

Where the JS-disabled test misleads

It over-reportsin one way: Google can render JavaScript, so "blank without JS" does not mean "invisible to Google forever." It means indexing is slower, rationed, and dependent on a second pass that thin-looking pages may never earn — a real cost, but not the apocalypse the white screen implies.

It under-reportsin two ways. Your browser without JS is not a crawler: sites that serve crawlers prerendered HTML will fail your test while passing Google's. And bot protection can do the reverse — your browser test passes while actual crawler requests get challenged. The test is a decent smoke alarm and a poor instrument.

Cross-check against what crawlers actually get

See the crawler's version of this page

https://

Reading the result

Verdict	Read alongside your no-JS test
CSR	Both tests agree: the blank screen is real for crawlers and for failed-script users alike. Fix per steps four and five — search and resilience both apply.
HYBRID	Softer than your test implied. The shell and some content are served; specific sections are client-built. Scope the fix to what the missing-elements list shows instead of treating the whole site as blank.
SSR	Interesting disagreement: crawlers get real HTML even though your browser test went blank. Usual causes — prerendered serving for bots, or your test hit cached/errored state. Search is likely fine; the resilience question may still stand.

Image slot

Screenshot: the no-JS white screen beside the rendered page — the test that sends people here.

The test everyone runs. Useful smoke alarm; imprecise instrument.

How to fix it

Six steps. Step one is the fork; steps four and five are the two prongs it forks into.

Decide which problem you're solving

The blank screen bundles two concerns. Search: crawlers' first pass sees nothing. Resilience: any user whose JavaScript fails to arrive — flaky connection, aggressive extension, a bad deploy — gets that same white screen. Name your concern before choosing fixes; they diverge at step four.

Re-run the test properly

Disable JavaScript in the browser's site settings or DevTools, then hard-reload with cache disabled. A soft reload can replay cached, already-rendered state and pass a page that would fail cold. Test a deep URL, not just the homepage.

Cross-check against what crawlers actually receive

The no-JS test shows what your browser gets without scripts — which isn't necessarily what a crawler gets. Sites that serve crawlers prerendered HTML fail the browser test and pass the crawler one; sites behind bot protection do the reverse. Compare a raw fetch with a full render to see the real gap.

For search: move content into the server response

If the page has a search audience, the durable fix is server rendering or static generation through your framework's path, so the first response carries content and links. This is the same destination as every rendering fix — the no-JS test was just how you found the road.

For resilience: fail visibly, not blankly

Server rendering helps here too — a server-rendered page shows content even when scripts die. Beyond that: monitor bundle delivery failures, add error boundaries so one crashed component doesn't blank the app, and put a minimal noscript message up so no one ever stares at pure white.

Verify both audiences

Re-run the raw-vs-rendered comparison for the crawler view, and repeat the no-JS hard-reload for the human view. Passing one doesn't imply the other — that asymmetry is the entire reason this page exists.

A note on <noscript>: it's a courtesy, not a strategy. A short "this page requires JavaScript" message beats a silent white screen for the rare no-JS visitor — but it does nothing for search and nothing for the far larger group whose scripts failed rather than were disabled, because their browsers have JavaScript enabled and never render noscript content at all.

The uglier cousin: blank WITH JavaScript on

If users report blank pages with JavaScript fully enabled, you're past testing hypotheticals — scripts are arriving and then failing. The usual culprits: an unhandled exception during startup with no error boundary to contain it, a bundle 404 after a deploy changed hashed filenames while stale HTML still referenced the old ones, or a CSP rule blocking your own scripts. A fully client-rendered architecture turns each of these from a degraded experience into a blank one — which is the resilience argument for server rendering, restated by your error tracker.

Common questions

Deliberately, very few — well under one percent in most measurements. But that is the wrong denominator. The population that matters is users whose JavaScript failed to arrive or execute on a given load: dropped connections, CDN failures, interfering extensions, bad deploys. On a fully client-rendered site, all of them see the same blank page the disabled-JS test shows.