Check for client-side rendering issues

SiteCurl reads the HTML response from your server and checks if real content is there or if the page relies on JavaScript to build its content after loading. Pages that return mostly empty HTML with JS bundles are flagged as client-side rendered.

The check looks for common signs of single-page apps: a bare HTML shell with a root div, large JS bundles, and frameworks like React, Vue, or Angular that build content in the browser.

SiteCurl reports if the first HTML contains real content or is mainly a JS app shell. Pages with content in the HTML pass. Pages with empty shells that need JS to render are flagged.

When a standard site sends a page, the HTML holds all the visible content: headings, text, images, and links. The browser reads the HTML and shows it. Crawlers do the same: they read the HTML and index the content.

Single-page apps (SPAs) work in a new way. The server sends a bare HTML file with a JS bundle. The browser runs the JS, which then builds the page content on the client side. The user sees the same result, but the process is different.

The issue is that Google and AI crawlers may not run JS. Google says Googlebot renders JS, but it does so in a later phase that can lag by days. Bing, DuckDuckGo, and AI crawlers may not render JS at all. If your content only exists after JS runs, these tools see a blank page.

This makes a gap in who can see your content. Your site looks fine to users with JS turned on, but it is blank to any tool that reads only the HTML response. The gap hits search indexing, AI citations, social media previews, and any tool that fetches your pages.

Google may not index content that needs JS to render. While Google has gotten better at JS rendering, it is delayed and not assured. Bing and AI crawlers may skip JS fully. Content in the first HTML is always indexed.

Social media previews (Open Graph, Twitter Cards) read meta tags from the HTML response. If your meta tags are built by JS, social shares will show blank or default previews. That cuts clicks from social media posts.

Page speed drops when the browser must load, parse, and run JS before any content shows up. Server-rendered pages show content right away. Client-rendered pages show a blank screen or spinner until the JS finishes.

SaaS products built with React, Vue, or Angular as single-page apps are hit hardest. The marketing site and the app may share the same framework. That means marketing pages that need to rank in search are built by JS instead of served as HTML.

Headless CMS setups that use a JS frontend (Next.js, Nuxt.js, Gatsby) can fall into this trap if SSR is not turned on. The default build of many frameworks makes a client-rendered app unless SSR or static export is set up on purpose.

Any site that uses a JS framework to build page content rather than serving HTML is at risk. The content exists, but Google and AI tools may not see it.

Step 1: Turn on server-side rendering (SSR). In Next.js, use getServerSideProps or getStaticProps for pages that need to be indexed. In Nuxt.js, set render mode to 'universal.' In Angular, use Angular Universal. SSR sends full HTML from the server while keeping client-side features.

Step 2: Use static export for content pages. For pages that rarely change (blog posts, marketing pages, docs), build static HTML at compile time. This makes fast, fully crawlable pages with no JS rendering needed.

Step 3: Add pre-rendering for key pages. If full SSR is too complex, use a pre-rendering tool that makes HTML copies of your pages for crawlers. Tools like Prerender.io or Rendertron serve static HTML to bots while users get the JS version.

Step 4: Test with a fetch check. Use Search Console's URL tool to see how Google renders your page. Compare the result to what your server sends. If key content is missing from the server response, SSR or pre-rendering is needed.

Thinking Google renders all JS. Google renders JS, but with a lag of hours to days. Bing may not render it at all. AI crawlers often skip JS. Do not rely on client-side rendering for pages that need to be found.

Turning on SSR for the app but not the marketing site. If your marketing site uses the same JS framework as your app, make sure SSR is on for marketing pages too. These are the pages that need search reach the most.

Testing only in a browser. Your browser always runs JS, so client-rendered pages look fine. Test with tools that fetch the raw HTML (curl, View Source, Search Console's URL tool) to see what crawlers see.

After enabling SSR or pre-rendering, check the raw HTML response. Run curl -s https://yoursite.com/page | grep 'your heading text' to verify that key content appears in the HTML without JavaScript. If the heading text is in the HTML, the page is server-rendered.

Run another SiteCurl scan. The client-side rendering flag should clear for pages that now serve content in the initial HTML response.

Content that requires JavaScript to render may be invisible to search engines and AI systems. Serve your important content in the initial HTML response using server-side rendering or static generation. Test with tools that do not execute JavaScript to see what crawlers actually see.