If your brand name only appears after hydration, AI never saw it. When to SSR, when to prerender, when a thin static shell is enough.
If your brand name only appears after hydration, many AI crawlers never saw it. Answer engines that fetch HTML once will not wait for your spinner, your client-side CMS call, or the A/B test that finally paints the H1.
Server-side rendering (SSR), static generation, and client-side rendering (CSR) are engineering choices. For answer-engine readiness they are also visibility choices.
Definitions that matter here
SSR / server HTML: The first response already includes the meaningful text (brand, definition, steps, prices).
Static / prerender: HTML generated at build or ISR time; still "full" on first fetch.
CSR: Browser downloads a shell, runs JS, then inserts content. Great for apps. Weak for one-shot crawlers.
You do not need to SSR your entire product. You need server-visible HTML on the URLs you hope assistants cite.
Why this shows up in AEO
Retrieval-based assistants and citation pipelines often start from fetched page text. If that text lacks your entity name, category, or the sentence that answers the query, you will not be the source — someone with a boring static page will.
This is adjacent to classic SEO, but the failure mode is harsher: classic crawlers may revisit and render; a single answer-time fetch might not. Background reading: JavaScript rendering and AI crawlers and serving AI crawlers on Next.js and Vercel.
Pew Research (March 2025) observed AI Overviews on about 18% of Google searches in their study, with lower clicks on traditional blue links when a summary appeared. Zero-click pressure makes the cited page more valuable when someone does dig in — 88% of those summaries cited three or more sources in that research. Your page still has to be readable to be that source.
Practical decision table
| Content | SSR / static? | CSR OK? | Notes |
|---|---|---|---|
| Homepage positioning | Yes | No | Entity intro belongs in first HTML |
| About / company | Yes | No | Machines learn who you are here |
| Pricing / plans | Yes | Calculator widgets only | Plan names and numbers in HTML |
| Docs / guides | Yes | No | Procedural pages get cited |
| Blog articles | Yes | No | Author, date, body in source |
| Interactive demo | Shell can be CSR | Yes | Keep a text summary above the fold in HTML |
| Logged-in app | No need | Yes | Not a citation surface |
| Personalization banner | Default SSR copy | Enhance client-side | Never replace the brand string |
When a thin static shell is enough
A thin static shell works when:
- The shell still contains the brand name, one-sentence definition, and primary CTA in raw HTML
- Heavier charts or configurators hydrate afterward
- You are not hiding the answer behind "Click to load"
A thin shell fails when:
- The only H1 arrives from an API after mount
- Schema JSON-LD is injected only by a client effect
- Pricing is entirely a client fetch with no fallback text
How to choose on a real roadmap
- List URLs you would be happy to see cited (usually Home, About, Pricing, top 10 docs/posts).
- For each, view source and search for the brand and a unique claim.
- Anything missing from source goes on the SSR/static backlog — not the "more blog posts" backlog.
- Keep dashboards and builders on CSR without guilt.
- Re-test after deploy with curl, not only with a logged-in Chrome profile.
- Add a regression check: disable JS and confirm the story still reads.
Before / after pattern (hypothetical)
Before (CSR-heavy homepage source): nav markup, empty <div id="root"></div>, "Enable JavaScript" noscript.
After (SSR homepage source): same nav, an H1 with the product name, a 40-word definition, Organization JSON-LD, then the interactive island markers.
Northstar Analytics did not rewrite their app. They moved three marketing routes to server components and left /app alone. Curl started returning the product category on line 40 instead of line never.
Comparison: SSR vs prerender vs CSR for AEO
| Approach | First-byte content | Freshness | Ops cost | AEO fit for marketing |
|---|---|---|---|---|
| SSR on request | Full | High | Medium | Strong |
| Static / ISR | Full | Tunable | Low–medium | Strong |
| CSR | Shell | N/A for bots that skip JS | Low for some teams | Weak for citations |
| Hybrid (SSR text + CSR widgets) | Full core | High | Medium | Best balance |
Mistakes
- Equating "Lighthouse says SEO 100" with "AI fetch saw the brand."
- Prerendering a loading skeleton and calling it static.
- Shipping different content to "bots" via cloaking. Detect crawlers to serve the same public HTML you show users, not a doorway page.
- Ignoring middleware that strips HTML for non-browser UAs.
- Waiting for a redesign quarter when three routes would unblock the issue.
How to verify
| Test | Expected |
|---|---|
| View source | Brand + definition present |
| Disable JS in browser, reload | Core story still readable |
| curl without cookies | 200 + same core story |
| Rich results / schema validator | Blocks parse from source |
Honest ceiling: choosing SSR does not force ChatGPT or Perplexity to name you. Gartner's February 2024 forecast that traditional search volume may drop 25% by 2026 is a forecast, not a promise that SSR wins the gap. What SSR does is remove a self-inflicted blindfold.
If the machine cannot read the name, it cannot cite the name. Start there.