Your website looks great in a browser. The navigation is smooth, the content loads cleanly, and everything feels fast. But there's a question worth asking: what does Google actually see when it visits your site?
For millions of websites built on modern JavaScript frameworks — React, Vue, Angular — the answer might surprise you. What Google often sees first is almost nothing. And that gap between what your visitors see and what search engines see could be quietly undermining your search rankings.
This is the client-side rendering problem. It's more common than most site owners realise, and it has real consequences for SEO.
What is client-side rendering?
Traditional websites work like this: you request a page, the server sends back complete HTML — all the text, headings, links, and metadata already assembled. Search engines can read it immediately.
Client-side rendered sites work differently. The server sends a mostly empty HTML file and a large bundle of JavaScript. Your browser downloads that JavaScript, runs it, and the page content appears — all happening inside your browser, not on the server.
From a user's perspective, both approaches can feel identical. The page loads, the content appears, everything works. But from a search engine's perspective, the experience is very different.
Think of it this way: a traditional site is like a printed book — Google opens it and can read every word immediately. A client-side rendered site is like a flat-pack furniture box — Google opens it and finds a pile of parts and instructions. To see what it looks like assembled, Google has to run the assembly process itself.
Google's two-wave indexing problem
Google can process JavaScript — but it does so in two waves, and the gap between them is where rankings get lost.
Wave 1 — immediate. Google fetches your page and indexes whatever is in the raw HTML. For a client-side rendered site, this is often a near-empty shell. Very little content gets indexed at this stage.
Wave 2 — delayed. Google puts your page in a rendering queue to be processed with a headless browser. This queue has no guaranteed timeline — it can take hours, days, or even weeks, depending on how frequently Google crawls your site and how large its rendering backlog is.
The practical consequences of this delay are significant:
- New pages take much longer to appear in search results. Publish a blog post today and it might be weeks before it's fully indexed.
- Your crawl budget gets consumed faster. Google limits how often it crawls each site. Rendering pages uses more of that budget, leaving less for discovering new content.
- Other search engines may not index you at all. Bing, DuckDuckGo, and Yandex have far more limited JavaScript rendering capabilities. Many pages on client-side rendered sites are effectively invisible to them.
- Social media previews break. When someone shares your page on LinkedIn or Facebook, those platforms don't execute JavaScript. The preview shows whatever is in the raw HTML — which on a client-side rendered site is often a blank title and no image.
What we're seeing in the wild
When Evalta AI scans websites, it detects the rendering approach automatically. What we've found is that client-side rendering is far more common than most site owners realise — and it consistently produces the same set of problems.
Sites built entirely on client-side frameworks often have no detectable H1 tags, no internal links, and no visible navigation from Google's first-wave perspective. Not because these elements don't exist — they do, and they look perfectly normal in a browser — but because they're injected by JavaScript after the initial page load.
We also frequently see thin content flags, low content-to-HTML ratios, and missing structured data — all false signals caused by the rendering gap rather than genuine content problems. A site can have excellent, well-written content and still look like a thin, under-optimised page to a search engine that only got the first wave.
Perhaps most surprisingly, many of the affected sites are marketing pages for legitimate businesses — not experimental side projects. The framework was chosen for developer experience or performance reasons, without fully considering the SEO implications.
It's not a death sentence
It's worth being clear: many client-side rendered sites rank well. Google does eventually process the second wave, and for established sites with strong domain authority, the delay may not cause significant ranking drops. The problem is most acute for:
- New sites or new pages, where timely indexing matters most
- Time-sensitive content like blog posts, news, events, or promotions
- Sites targeting non-Google search engines
- Marketing sites where social sharing is part of the acquisition strategy
If your site is primarily a web application — a SaaS product, a tool, something users log into — client-side rendering is entirely appropriate. Those pages shouldn't be indexed anyway. The concern is specifically for public-facing marketing, content, and e-commerce pages where search visibility drives business outcomes.
What to do about it
The right fix depends on your technical situation. In order of comprehensiveness:
Migrate to server-side rendering. This is the gold standard. Frameworks like Next.js (React), Nuxt.js (Vue), and SvelteKit make server-side rendering accessible without abandoning modern development practices. Pages are built with full HTML content before they reach the browser, giving search engines everything they need on the first wave.
Use static site generation. For content that doesn't change frequently, pre-rendering pages at build time gives you the SEO benefits of server rendering with excellent performance. Astro, Gatsby, and Next.js all support this approach.
At minimum, fix your metadata. If a full migration isn't feasible, ensure your title tags, meta descriptions, Open Graph tags, and structured data are present in the server-rendered HTML — not injected by JavaScript. These are the elements that matter most for search visibility and social sharing, and they can often be added server-side even on an otherwise client-rendered site.
Submit a sitemap. A well-maintained sitemap.xml helps Google discover and prioritise your pages for rendering, reducing the time between publication and full indexing.
Know what you're dealing with
The first step is understanding whether your site has this issue. Many site owners don't know how their site is rendered — they know it was built with React, but whether it's using server-side rendering, static generation, or pure client-side rendering may not be clear.
A simple test: disable JavaScript in your browser (most browsers have a developer tools option for this) and reload your page. If the content disappears and you're left with a blank page or a loading spinner, you're likely looking at a client-side rendered site.
Tools like Evalta AI detect this automatically as part of a full site audit, alongside the other technical and content factors that affect your search performance. If client-side rendering is a problem for your site, it'll flag it clearly — giving you a complete picture of what to fix and why it matters.
The web moves fast, and the frameworks developers love often prioritise build speed and developer experience over SEO compatibility. That's not a criticism — it's a tradeoff. But it's a tradeoff worth understanding, especially if your business depends on people finding you through search.