The brief arrives with the fix already chosen: "make it server-side rendered, for SEO." It is usually the right instinct and the wrong instruction, and if a developer follows it literally you will pay for compute you never needed.
Render strategy is one of the few decisions on a web project that is genuinely hard to reverse. Worth ten minutes of thinking before it becomes a ticket.
Start from the requirement rather than the technology, because the requirement is narrower than most people assume.
An AI crawler needs the content to exist in the HTML response. That is the whole specification. It does not need the content to be fresh, because it is not going to come back this afternoon. It does not need personalisation, because it has no session. It does not need interactivity at all.
This matters because the standard argument for server-side rendering is freshness and personalisation per request, and neither is relevant here. As covered in Monday's piece on the render gap, none of the major AI crawlers execute JavaScript. ChatGPT's crawler fetches script files in 11.50% of its requests and Claude's in 23.84%, and neither runs them. Content that arrives after hydration does not arrive.
So the question is not "server rendered or not". It is: what is the cheapest, fastest, most maintainable way to guarantee this content is in the initial HTML.
StrategyContent in HTMLTTFBBuild timeServer costData freshnessSSG static generationYesFastestLongLowestStatic until rebuildISR incremental regenerationYesFastest when cachedVaries, much shorterLow to moderatePeriodic or on demandSSR per requestYesSlowestShortHighReal timeCSR client sideNoMediumShortLowestReal time
Three of the four satisfy the requirement. Only one fails it outright, and it fails completely rather than partially.
This is the part that gets skipped, and it is where the SSR reflex costs money.
If the goal is that a crawler finds your content in the HTML, SSG and ISR do that with the fastest response time and the lowest hosting cost. SSR does the same thing with the slowest time to first byte and high server compute, in exchange for freshness that no crawler will ever use.
Response time is not a vanity metric here. Crawlers operate under budget. Recall from the same Vercel dataset that ChatGPT's crawler already spends 34.82% of its fetches on 404 pages and Claude's 34.16%, against Googlebot's 8.22%. When a third of the crawl budget is already being wasted on dead URLs, adding server compute latency to every remaining request is not a neutral choice.
Vercel's own guidance on the subject is blunt about the default: lean on SSG and ISR as much as possible, and use SSR only when you need data fresh to that moment.
For a marketing site, a services site, a documentation set or a blog, which is most of what agencies build, ISR is the correct default. Content is in the HTML, response is edge-fast, cost is low, and the CMS can trigger regeneration when an editor publishes. Pure SSG is fine too if the content changes rarely and the site is small enough to rebuild quickly.
Not never. SSR earns its cost when the page content is different for each request in a way that matters:
Notice that almost none of those pages are pages you want cited by an AI system anyway. That is not a coincidence. The pages that need SSR and the pages that need to be citable are largely different pages, which is why applying one strategy to the whole site is the underlying error.
Client-side rendering is not a mistake. It is a mistake as a whole-page strategy for content pages.
Inside a page that is otherwise statically or server rendered, CSR is the right tool for interactive behaviour: a filter that reorders results, a cart, an image gallery, a configurator, a live preview. None of that needs to be crawlable, and forcing it through the server buys nothing.
The rule is simple. Content in the HTML, interaction in the client. The failure mode is not using JavaScript, it is using JavaScript to deliver the words.
Most of the time nobody is choosing a render strategy. They are looking at a three year old React application that a previous supplier built entirely client side, with a client who has no appetite for a rebuild.
Three honest options, in order of preference:
1. Migrate the content templates only. Move the marketing, service, article and product templates to server or static rendering, and leave the application areas alone. This is usually far less work than it sounds, because those templates are the simplest part of the codebase. It is the fix that actually resolves the problem rather than routing around it.
2. Prerender for bots as a stopgap. A prerendering layer detects crawler user agents and serves them a pre-rendered HTML snapshot while users get the normal application. Serving the same content in a different format is not cloaking, which is serving different content to manipulate rankings. But be clear-eyed: Google has consistently treated dynamic rendering as a workaround rather than a long-term architecture, most of the material promoting it is published by companies selling it, and you are adding a dependency that has to be maintained and monitored. It buys time. It is not the answer.
3. Accept and document. If neither is possible, say so in writing, and do not sell the client AI visibility work on that site. That is the honest version of the conversation, and it is a great deal cheaper than the one you have in month nine.
The mature answer is that a site does not have a render strategy. Each template does.
A worked example for a typical ecommerce build:
Modern frameworks support choosing per route. The reason most projects do not is that nobody was asked the question at the point where it was cheap to answer.
Rather than "make it SSR for SEO", the instruction that produces the right build is closer to this:
Content templates (home, services, product, article, category) must render their main content into the initial HTML, using static generation or incremental regeneration, with revalidation triggered by CMS publish. Application templates (account, cart, checkout, search) may render client side or per request. Acceptance test: for each content template, a sentence from the visible body copy must be findable in view-source with JavaScript disabled.
That last sentence is the part that matters. A render strategy without an acceptance test is a preference. With one, it is a requirement that gets checked before delivery rather than discovered nine months later.
Render migrations are a large share of what agencies send us, usually as the technical half of a visibility engagement they have already sold. Moving content templates from client side to static or incremental rendering, cleaning the crawl surface, and putting structured data into the initial HTML. The agency keeps the strategy and the client relationship, we do the build in white label.
Send us a sitemap and a note on the current stack. We will come back with a per-template render recommendation, which templates need to move, which can stay as they are, and a scoped estimate for the migration. No charge, 48 hours. See our technical services, or how we work with agency partners in white label.
Genesis Agency Insight: The question we ask before any render decision is which templates you would want an AI system to quote. It is usually five or six out of forty, and they are almost never the ones with the complicated data requirements. Once that list exists, the strategy for the rest of the site stops being contentious, because nobody is arguing about the checkout any more.
Whether you need to redesign your website, boost your social media presence, or launch high-performing advertising campaigns, we are here to support you. Free 30-minute strategic consultation to discuss your challenges, no commitment, no pressure. Just an honest, useful conversation.
.svg)
.png){kind=small}
