Check for client-side rendering issues

SiteCurl examines the HTML response from your server and checks whether visible content is present or if the page relies on JavaScript to render its content after loading. Pages that return mostly empty HTML with JavaScript bundles are flagged as client-side rendered.

The check looks for common patterns of single-page applications: a minimal HTML shell with a root div, large JavaScript bundles, and frameworks like React, Vue, or Angular that render content in the browser.

SiteCurl reports whether the initial HTML contains meaningful content or is primarily a JavaScript application shell. Pages with content in the HTML response pass. Pages with empty shells that depend on JavaScript to render are flagged.

When a traditional website sends a page, the HTML contains all the visible content: headings, paragraphs, images, and links. The browser reads the HTML and displays it. Search engine crawlers do the same: they read the HTML and index the content.

Single-page applications (SPAs) work differently. The server sends a minimal HTML file with a JavaScript bundle. The browser downloads and runs the JavaScript, which then builds the page content in the browser. The visitor sees the same result, but the process is different.

The problem is that search engines and AI crawlers may not execute JavaScript. Google says Googlebot renders JavaScript, but it does so in a separate phase that can be delayed by days. Other search engines (Bing, DuckDuckGo) and AI crawlers may not render JavaScript at all. If your content only exists after JavaScript runs, these systems see an empty page.

This creates a visibility gap. Your site looks complete to visitors with JavaScript-enabled browsers, but it is blank or nearly blank to any system that reads only the HTML response. The gap affects search indexing, AI citations, social media previews, and any tool that fetches your pages.

Search engines may not index content that requires JavaScript to render. While Google has improved its JavaScript rendering, the process is delayed and not guaranteed. Other search engines and AI crawlers may skip JavaScript entirely. Content in the initial HTML is always indexed.

Social media previews (Open Graph, Twitter Cards) read the HTML meta tags from the server response. If your meta tags are generated by JavaScript, social shares will show blank or default previews. This reduces click-through from social media posts.

Page speed suffers when the browser must download, parse, and execute JavaScript before any content appears. Server-rendered pages show content immediately. Client-rendered pages show a blank screen or loading spinner until the JavaScript finishes.

SaaS products built with React, Vue, or Angular as single-page applications are the most affected. The marketing site and the application may share the same framework, meaning marketing pages that need to rank in search are rendered by JavaScript instead of being served as HTML.

Headless CMS setups that use a JavaScript frontend (Next.js, Nuxt.js, Gatsby) can fall into this category if server-side rendering is not configured. The default build of many frameworks produces a client-rendered app unless SSR or static generation is explicitly enabled.

Any site that uses a JavaScript framework to render page content rather than serving HTML directly is at risk. The content exists, but search engines and AI systems may not see it.

Step 1: Enable server-side rendering (SSR). If you use Next.js, enable getServerSideProps or getStaticProps for pages that need to be indexed. In Nuxt.js, set the render mode to 'universal.' In Angular, use Angular Universal. SSR sends fully rendered HTML from the server while keeping client-side interactivity.

Step 2: Use static site generation for content pages. For pages that do not change often (blog posts, marketing pages, documentation), generate static HTML at build time. This produces fast, fully crawlable pages with no JavaScript rendering required.

Step 3: Add pre-rendering for critical pages. If full SSR is too complex, use a pre-rendering service that generates HTML snapshots of your pages for search engine crawlers. Services like Prerender.io or Rendertron serve static HTML to bots while visitors get the JavaScript version.

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

Assuming Google renders all JavaScript. Google renders JavaScript, but with a delay that can range from hours to days. Other search engines may not render it at all. AI crawlers typically do not execute JavaScript. Do not rely on client-side rendering for pages that need to be discoverable.

Enabling SSR for the app but not the marketing site. If your marketing site uses the same JavaScript framework as your application, make sure SSR is enabled for marketing pages too. These are the pages that need search visibility the most.

Testing only in a browser. Your browser always runs JavaScript, so client-rendered pages look fine. Test with tools that fetch the raw HTML (curl, View Source, Google's URL Inspection) to see what search engines 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.