When someone visits your website, how does the browser know what to display? The answer depends on your rendering strategy. It changes when content becomes available to browsers and crawlers.
Some AI website builders generate client-rendered applications. That can suit an app behind a login. For public content, check whether the main text is present before JavaScript runs.
The Two Approaches Visualized
Client-Side Rendering
Static Site Generation
What Search Engines Actually See
Google can render JavaScript, but it starts with the HTML response. Other search services use their own crawlers and access rules. Compare what is available before client-side rendering:
<!DOCTYPE html> <html> <head> <title>My Website</title> </head> <body> <div id="root"></div> <script src="/bundle.js"></script> </body> </html>
Googlebot sees: Empty page, no content
<!DOCTYPE html>
<html>
<head>
<title>Pricing - My Website</title>
<meta name="description" content="...">
</head>
<body>
<nav>...</nav>
<main>
<h1>Simple Pricing</h1>
<p>Start free, upgrade when ready</p>
<div class="pricing-table">...</div>
</main>
</body>
</html> Googlebot sees: Complete content, ready to index
SEO Impact: The Data
Google can render JavaScript. Its documentation also explains the extra processing involved:
Two-Wave Indexing
Google crawls the page, sends it to a rendering queue, and uses the rendered HTML for indexing. Content already present in HTML does not depend on this rendering stage.
Render Budget
Browser-created content depends on scripts and resources working in Google's rendering environment. Check the rendered HTML when Search Console reports an indexing problem.
JavaScript Errors
Any JavaScript error during rendering can prevent content from being indexed. Errors that work fine in browsers may fail in Googlebot's older Chrome version (typically months behind current release).
Performance: Core Web Vitals
Core Web Vitals are now a Google ranking factor. Here's how rendering strategy affects them:
| Metric | CSR (Client-Side) | SSG (Static) |
|---|---|---|
| LCP Largest Contentful Paint | 2.5s - 4.0s+ Waits for JS + API | < 1.0s HTML ready on arrival |
| FID First Input Delay | 100-300ms Main thread blocked | < 50ms Minimal JS to execute |
| CLS Cumulative Layout Shift | 0.1 - 0.25+ Content pops in | < 0.05 Layout defined in HTML |
| TTFB Time to First Byte | Fast But empty content | Fast Full content from CDN |
How rendering affects AI search access
AI search services also use crawlers to reach public pages. Each service has its own access rules and fetch systems.
Keep public content independent of crawler-side JavaScript
Pre-rendered HTML makes the main content available without an extra rendering dependency. You still need to allow the relevant crawler and keep the page public. Inclusion and citations are not guaranteed.
Content may depend on JavaScript
Content is available in HTML
Still need crawl access and useful content
When to Use Each Approach
CSR Makes Sense For:
- • Apps behind authentication (SEO irrelevant)
- • Internal dashboards and tools
- • Complex interactive applications
- • Prototypes and MVPs (non-production)
- • Real-time collaborative tools
SSG Makes Sense For:
- • Marketing websites
- • Landing pages
- • Blogs and content sites
- • Documentation
- • Any site where SEO matters
- • Any site where AI discovery matters
How Pagesmith Solves This
Pagesmith generates static Astro sites that deliver pre-rendered HTML by default:
- SSG by Default: Every page pre-rendered at build time. No JavaScript required to see content.
- Islands Architecture: Interactive components hydrate on demand. Static content stays static.
- SSR When Needed: Need dynamic content? Enable server-side rendering for specific pages.
- SEO foundations: Sitemaps, metadata, supported structured data, and social sharing tags.