JavaScript SEO: Will Google See Your Content?
You launched a fast, modern site. It looks great in your browser. Then you check Google and the page that ranks shows almost none of your text. The culprit is often JavaScript. The content your visitors see was built by a script that Google had not run yet when it indexed the page.
Google can run JavaScript. It just does not do it the way a browser does, or on the same schedule. That gap is the difference between a site Google reads in full and one it files away half-empty.
Quick Navigation
- How Google Processes JavaScript
- Why a JavaScript Site Can Look Empty
- Server-Side vs Client-Side Rendering
- What This Means for Wix, Squarespace, and React Sites
- How to Check What Google Sees
- Frequently Asked Questions
How Google Processes JavaScript
Google handles a page in three phases, and they do not all happen at once. Google's Search Central documentation, collected in the JavaScript SEO research topic, names them as crawling, rendering, and indexing. First Googlebot crawls the raw HTML your server sends. If that HTML depends on JavaScript to fill in the content, the page goes into a render queue.
Rendering is the second phase, and Google performs it later. The documentation states that a page "may stay on this queue for a few seconds, but it can take longer." When resources free up, a headless version of Chromium, the same engine behind Chrome, loads the page and runs its JavaScript. Only after that does the content become available to index.
The point is timing. A plain HTML page is ready to index the moment it is crawled. A JavaScript-dependent page waits for a second pass on Google's schedule. If that pass is delayed or fails, your content is not there when Google decides what the page is about.
Why a JavaScript Site Can Look Empty
Brass-SEO sees this pattern often: a page that renders beautifully for a person shows up thin or blank in search. The primary content never made it into what Google indexed.
Several things break the render pass. A script blocked by robots.txt cannot run. A script that throws an error, or one that loads content only after a click, leaves that content hidden. Google's documentation also lists hard limits on its renderer: the Web Rendering Service clears Local Storage, Session Storage, and cookies between page loads, and it does not open WebSocket or WebRTC connections. Anything that waits on a stored session or a live connection will not appear.
Then there is the silent failure. When rendering is delayed or breaks, Google can index the page in its pre-render state, which for a browser-built app is often an empty shell. The page sits in the index with nothing to rank for. It looks fine to you and reads as blank to a search engine.
Server-Side vs Client-Side Rendering
The fix lives in where your content gets built. Google's engineering guide "Rendering on the Web" lays out the options, and they differ sharply in how friendly they are to crawlers.
Client-side rendering sends a near-empty HTML file and lets JavaScript build everything in the browser. It is the riskiest approach for SEO because it depends entirely on that deferred render pass. Server-side rendering builds the full HTML on the server and sends it complete; Google notes this "generally produces a fast FCP" because the browser is not waiting on a pile of JavaScript. Static rendering goes one step further by building the HTML ahead of time, which Google says "achieves a consistently fast TTFB."
Hydration is the hybrid most modern frameworks use. The server sends real HTML, then JavaScript activates it in the browser. Crawlers get your content immediately. One caution from Google's guide: a hydrating page "can't actually respond to input until the client-side scripts ... have been executed," so a button can look ready before it works. For search, what counts is that the words arrive in the HTML.
Google's own recommendation settles the debate. Its documentation now calls dynamic rendering, an older crawler-only trick, "a workaround and not a long-term solution," and points sites toward server-side rendering, static rendering, or hydration. Put the content in the page for everyone.
What This Means for Wix, Squarespace, and React Sites
Brass-SEO gets this question from owners on every platform, and the answer splits by how the site is built. Hosted builders like Wix and Squarespace render most content on the server, so their pages generally reach Google readable. The platform's other limits matter more there, a subject covered in the guide on working around Wix SEO limits.
Custom builds on React, Vue, or similar frameworks are where the risk concentrates. A single-page app that renders only in the browser is the classic empty-shell case. The fix is the framework's server or static mode. Next.js, Nuxt, and Astro all produce HTML on the server or at build time by default, which makes them a safer foundation for a content site than a browser-only build.
How to Check What Google Sees
You do not have to guess. Brass-SEO's Page Audit button crawls a single URL the way a search engine would and reports the title, headings, and body text it can actually read. A result that comes back nearly empty is a strong sign your content depends on a render pass that is not completing.
Google's URL Inspection tool in Search Console is the other half of the check. It shows the rendered HTML Google produced for a page, so you can confirm whether your text survived rendering. If the rendered output is missing your main content, you have found the problem. The mechanics of how crawlers fetch and index pages are collected in the crawling and indexing research topic, and the deeper question of how Google understands what it does read is covered in query understanding.
Frequently Asked Questions
Can Google index JavaScript content at all?
Yes. Google renders pages with a headless, evergreen version of Chromium and runs their JavaScript. The catch is that rendering is deferred to a queue and happens on Google's schedule, which can take seconds or longer after the first crawl. Content that depends on JavaScript is indexed only after that second pass, so a broken or slow script can keep it out of the index.
How do I know if my site has a JavaScript SEO problem?
Use the URL Inspection tool in Google Search Console to view the rendered HTML for a page. If your main content is missing from that output, Google is not seeing it. Brass-SEO's Page Audit button gives a second read by crawling the URL and reporting the text it can extract. A page that looks full in your browser but empty in these tools is relying on a render pass that is not finishing.
Is server-side rendering better than client-side rendering for SEO?
For a content site, yes. Server-side and static rendering put your text into the HTML before it reaches the browser, so crawlers get the content right away. Client-side rendering leaves everything to JavaScript in the browser, the setup most likely to produce a blank page in search. Google recommends server-side rendering, static rendering, or hydration.
Does using React or Vue hurt my SEO?
Not by itself. React and Vue can render on the server or at build time, which is search-friendly. The risk is a single-page app that renders only in the browser. Frameworks like Next.js, Nuxt, and Astro default to server or static rendering, which keeps your content visible to Google while still using the JavaScript tools developers prefer.
Your content can only rank if Google can read it. Build the words into the HTML, then confirm with URL Inspection or a free first analysis that what you see is what Google sees.