Server Side Rendering: SEO Trade-Offs

Server side rendering (SSR) means your server builds a page’s full HTML on every request, so crawlers and visitors receive real content in the first response. For SEO it solves the biggest risk of client rendering, which is content that only exists after JavaScript runs. It also costs more to run and can slow the first byte.

This guide is for owners, marketers and developers choosing how a site should render. It compares SSR, static generation and client rendering for Google and for AI crawlers, then gives a decision rule by site type.

On this page

• What server side rendering sends to a crawler
• Does Googlebot need server side rendering?
• Do AI crawlers render JavaScript?
• SSR, static generation and client rendering compared
• What does server side rendering cost?
• Which rendering model fits your site?
• How to test what a crawler receives
• Getting server side rendering right for your site

What server side rendering sends to a crawler

A crawler that does not run JavaScript sees exactly what your server returns, and only that. The rendering model decides whether that response contains your content or an empty container.

The diagram below shows what each approach puts in the first response.

Frameworks blur the lines. In Next.js, pages and layouts are Server Components by default, and the HTML is prerendered from them before JavaScript hydrates the interactive parts. Hydration is React’s process of attaching event handlers to static HTML. That is SSR plus a thin client layer, and it is the pattern most “SSR” sites use.

Does Googlebot need server side rendering?

No, but it still helps. Googlebot can render JavaScript, so a client-rendered page can be indexed. The cost is a queue: Google describes three phases of crawling, rendering and indexing, and says a page may stay in the render queue “a few seconds, but it can take longer than that.”

Google’s own guidance is that server-side or pre-rendering “is still a great idea,” in part because not all bots can run JavaScript. It also lists specific ways JavaScript sites go wrong: links must be <a> elements with an href, and error pages that return a non-200 status may skip rendering, which makes soft 404s easy to create in client-routed apps.

Google calls dynamic rendering, where bots get a prerendered copy and users get the client app, “a workaround and not a recommended solution.” It recommends server-side rendering, static rendering or hydration instead. If a vendor pitches you a bot-detection prerender layer, that is the thing Google is steering you away from.

So for Google alone, client rendering is survivable. The wider problem is everything else that now fetches your pages.

Do AI crawlers render JavaScript?

Most do not. The best public evidence is a Vercel and MERJ study published in December 2024. It found that none of the major AI crawlers it measured rendered JavaScript, including OpenAI’s, Anthropic’s and Perplexity’s. ChatGPT’s and Claude’s crawlers fetched JavaScript files (11.50% and 23.84% of requests respectively) but did not execute them. Googlebot, and Gemini through Google’s infrastructure, rendered fully.

Treat that as a dated snapshot. It reflects crawler behavior in late 2024 on sites Vercel could observe, and crawlers change. But the safe assumption has not changed: if content is not in the initial HTML, plan for some crawlers never seeing it.

The chart below uses the study’s monthly fetch counts. The point is scale: AI crawlers are small next to Googlebot, but large enough to matter.

We cover what breaks and the three-step test in JavaScript rendering and AI crawlers. This post is about the architecture choice that prevents the problem.

SSR, static generation and client rendering compared

The three models trade crawler safety, speed and running cost against each other. Static generation wins on all three for content that does not change per visitor; SSR wins when data must be fresh; client rendering wins only for app-like screens crawlers do not need.

The speed and cost cells follow web.dev’s rendering guide. It notes that server generation “can increase your page’s TTFB” and can carry “significant compute overhead costs,” while static rendering delivers a consistently fast first byte if you keep client JavaScript small. Its limit for static: it “must generate individual HTML files for every possible URL.”

What does server side rendering cost?

SSR costs compute, a slower first byte on uncached requests, and engineering complexity. None of those is a reason to avoid it for the right pages, but all three show up on a real budget.

• Server compute. Every uncached request runs your app. Traffic spikes, including crawler spikes, become server load.
• Time to first byte. The server must finish rendering before it sends anything, so a slow database call delays every visitor and every bot. Caching the rendered HTML at the edge fixes most of it.
• Hydration weight. web.dev warns that hydration can have “a significant negative impact on TBT and INP, even if it improves FCP.” A fast first paint does not guarantee a responsive page. The speed side of this is covered in site speed optimization and Core Web Vitals explained.
• Two runtimes. Code must behave on the server and in the browser, which is where many “works locally” bugs come from.

One more cost is crawl-related. If SSR makes responses slow, Googlebot may fetch fewer URLs per visit on large sites, a risk we describe in crawl budget.

Is SSG better than SSR?

For most content sites, yes. Static generation does the expensive work once, ships plain files, and leaves nothing for a crawler to wait on. This site is built that way, and Astro SEO explains how Astro’s defaults support it: Astro’s docs say it renders components to HTML and CSS and loads JavaScript only for components you mark with a client:* directive.

Static is not free of trade-offs. A catalog of 100,000 products means 100,000 files to rebuild, and a price change is stale until the next build or revalidation. That is when teams reach for SSR, or for a hybrid where most routes are static and a few render on demand. Astro’s server islands, via the server:defer directive, are one example of the hybrid idea: a slow personalized block is deferred while the rest of the page stays fast.

Which rendering model fits your site?

Pick the most static option that still keeps the page correct. The rule below runs from simplest to most dynamic, and it stops at the first match.

A few cases deserve a sentence each.

• Local service business or small brand site. Static. The content is the same for every visitor, so there is no reason to pay for per-request rendering.
• Ecommerce store. Category and product templates should render server-side or statically with revalidation. Live stock and price can load after, but the product name, description and a default price belong in the HTML. Pair this with the ecommerce SEO checklist.
• SaaS marketing site with a product app. Render the marketing site statically and keep the app client-rendered behind login. Mixing them in one SPA is the common mistake.
• Publisher or directory with huge page counts. Static for evergreen pages, SSR with edge caching for listings and search.
• Legacy SPA you cannot rebuild. Prerender or server render only the routes that need to rank, as the JavaScript rendering post suggests.

How to test what a crawler receives

Fetch the URL without running scripts and see whether your content is in the response. The test takes under a minute.

1. Run curl -s https://yoursite.com/page/ | grep -i "a sentence from the page". No match means a non-rendering crawler has no match either.
2. Open View Source, not the inspector. Look for the H1, body copy, internal links and JSON-LD.
3. Check status codes on missing pages. Client-routed apps often return 200 for a “not found” screen, which Google treats as a soft 404.
4. In Search Console’s URL Inspection, compare the rendered HTML Google produced with your raw HTML. The gap is what depends on JavaScript. Setup for that is in Google Search Console setup.
5. Confirm AI crawlers are not blocked before you blame rendering. Access and rendering are separate gates, and the access side is in robots.txt for AI crawlers.

Run the same test after every framework upgrade or redesign. Rendering regressions ship silently, and the website migration SEO checklist includes a pre-launch version of it. The broader list of gates is the technical SEO audit checklist.

Getting server side rendering right for your site

The decision usually comes down to one question: does the page’s content change per request? If not, generate it statically. If it does, render it on the server and cache aggressively. Reserve client rendering for screens that do not need to be found.

Whatever you pick, keep three rules. Put the content, links and structured data in the first HTML response. Keep client JavaScript small so hydration does not erode your interactivity metrics. Test with curl rather than the browser.

If you are planning a rebuild, or inheriting a client-rendered app that no one can see into, our web development service builds sites with rendering chosen for search and AI retrieval from the start. The pairing of design and crawlability is also covered in web design for SEO, and the audit-first view is in the technical SEO checklist for AI search.