Client-side rendering

What is client-side rendering?

When you visit most websites, the server sends back a complete page — all the text, images, and links are already there in the HTML. Search engines can read this immediately.

Some modern sites work differently. The server sends back a nearly empty page with a lot of JavaScript code. Your browser downloads that code, runs it, and the page content appears — all happening in your browser, not on the server. This is called client-side rendering.

From a user's perspective, both approaches can look identical. But from a search engine's perspective, they're very different.

Why search engines struggle with it

Think of it like a book vs a flat-pack furniture box.

A traditional website is like a book — Google opens it and can immediately read everything on the page. A client-side rendered site is like a flat-pack box — Google opens it and finds a pile of parts and an instruction manual. To see what it actually looks like assembled, Google has to run the instructions first.

Google can assemble the flat-pack — but it takes much longer, and they have a huge queue of other boxes to get through first.

How Google indexes client-side rendered sites

Google uses a two-wave process:

• Wave 1 — immediate. Google fetches your page and indexes whatever is in the raw HTML. For a client-side rendered site, this is often almost nothing — just a blank shell with some script tags.
• Wave 2 — delayed. Google puts your page in a queue to be rendered with a real browser. This queue can take hours, days, or weeks to process depending on how often Google crawls your site.

The practical consequences:

• New pages take longer to appear in search results. If you publish a new blog post, it might be weeks before Google fully indexes it.
• Your crawl budget gets used up faster. Google limits how many pages it crawls per 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 much 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, Facebook, or Twitter/X, those platforms don't run JavaScript. They show whatever is in the raw HTML — which on a client-side rendered site is often nothing.

How Evalta handles client-side rendered sites

Evalta detects client-side rendering automatically during your first scan. When we find that a site's pages are rendered in the browser rather than the server, we adjust our approach:

• Page discovery — we use a full browser to crawl your site, so we find all your pages accurately rather than just seeing empty shells.
• Performance scores — these come from Google PageSpeed Insights, which runs its own browser. These are always accurate regardless of how your site is rendered, and are available on all plans.
• SEO checks (Pro/Agency) — Pro and Agency users get SEO checks run against the fully rendered page, using a real browser. This gives accurate results for navigation structure, internal links, content analysis, and heading structure.
• SEO checks (Free) — some checks that require rendered content show a note explaining that a browser render is needed. Upgrading to Pro unlocks these for your site.

Is this a big deal?

It depends on your situation. Many client-side rendered sites rank well — Google does eventually index them. But it creates real disadvantages:

• Slower indexing of new content
• Reduced visibility on non-Google search engines
• Broken social media previews
• Harder for Google to understand your site's structure

If your site is primarily a web application (a SaaS dashboard, a tool, something users log in to use), client-side rendering is fine — those pages probably shouldn't be indexed anyway.

If your site is a marketing site, blog, or e-commerce store where you rely on organic search traffic, it's worth fixing.

What to do about it

The right fix depends on your technical setup and how much control you have over your site.

If you use a developer or agency

Show them the “client-side rendering detected” issue in your Evalta report and ask about migrating to server-side rendering. Specifically mention:

• Next.js (if you're on React) — a popular framework that adds server-side rendering to React sites. Many agencies are familiar with it.
• Nuxt.js (if you're on Vue) — the equivalent for Vue.js.
• Astro — a newer framework that generates fast, SEO-friendly static pages and works with React, Vue, or plain HTML.

If you manage the site yourself

The minimum changes you can make without a full rebuild:

• Add Open Graph tags to your server response. Your title, description, and social image need to be in the raw HTML, not added by JavaScript. Most hosting platforms let you configure this.
• Add a sitemap.xml. A sitemap helps Google discover all your pages faster and is especially important for sites that are harder to crawl. Most frameworks have plugins that generate this automatically.
• Submit your sitemap to Google Search Console. This tells Google directly where to find your pages and speeds up indexing.

If you're on a website builder (Wix, Squarespace)

These platforms handle rendering for you and generally produce crawlable pages. If Evalta has flagged client-side rendering on a Wix or Squarespace site, it's usually limited to specific dynamic sections rather than the whole site. The built-in SEO settings in these platforms let you control your meta tags and Open Graph data without touching code.

Long-term: server-side rendering

The most thorough fix is moving to server-side rendering or static site generation — where pages are built with their full content already in the HTML before they're sent to the browser. This is how most high-ranking sites work and is the gold standard for SEO.

This typically requires developer involvement but the SEO benefits are significant — faster indexing, better rankings on all search engines, and working social media previews.