SEO without SSR: how far you can actually get
Google renders JavaScript, so a client-rendered app can rank. The wall is everything that is not Googlebot: AI crawlers, link previews and slow first paint. Where the line sits, and what to do on each side of it.
Aug 20, 2026 · 6 min read
Field Notes from Thunkle, a studio that takes AI-built apps from prototype to secure, production-ready software.
If you are searching for this, someone has probably told you your app cannot rank because it is client-rendered, and that the fix is rebuilding it with server-side rendering. You have a working product. The rebuild is not small. You would like to know whether the advice is actually true.
Partly. Less than the people selling rebuilds imply, and the part that is true is not about Google.
Worth declaring up front: converting client-rendered apps to SSR is a service we sell. So treat everything below that argues against needing it as testimony against interest.
Google runs your JavaScript
This is the thing the scary advice skips. Googlebot renders pages in an up-to-date version of Chromium. It executes your JavaScript, waits for the content to arrive, and indexes what appears. It has worked this way for years.
So a client-rendered React app, the kind every AI builder produces, can absolutely be indexed and can absolutely rank. Rendering happens as a second pass after crawling, and that pass can lag behind, but for a site with a normal number of pages the gap is not the thing standing between you and traffic.
There are conditions, and they are the same short list every time:
Every view needs its own real URL. Path-based routes, not /#/pricing. Google treats everything after a # as one page. If your router uses hash routing, that is a one-line change worth more than everything else in this article.
The title and description need to exist before your app boots. Your shell HTML, the index.html the server actually sends, should carry a real title and meta description. Libraries that set them from inside React work for Google, because Google renders. Nothing else reads them, for reasons coming below.
Content has to arrive without anyone touching the page. Googlebot does not click, scroll to trigger your lazy loader, or fill in a form. If a section only fetches after an interaction, it does not exist. Content that is in the DOM but visually collapsed, like tabs and accordions, is fine.
A sitemap, submitted in Search Console. Client-rendered apps are bad at internal links, since navigation often happens in JavaScript click handlers rather than real <a> tags. A sitemap routes around that, and Search Console tells you what actually got indexed instead of leaving you guessing.
Do those four things and Google sees a normal website. For a lot of apps, that is genuinely the end of the SEO conversation.
What every other crawler sees
Here is the part that has changed recently, and the reason this article is not just "relax, Google renders."
Fetch a client-rendered app the way a crawler without a browser does:
curl -s https://your-app.com
<!doctype html>
<html>
<head>
<title>MyApp</title>
<script type="module" src="/assets/index-BpR7Uxkm.js"></script>
</head>
<body>
<div id="root"></div>
</body>
</html>
That is the entire page. Every feature, every paragraph of copy, every product name your customers might search for lives on the far side of that script tag, and only a crawler willing to execute it will ever see any of it.
Google is willing. Almost nothing else is.
AI crawlers do not run JavaScript. The bots behind ChatGPT, Claude and Perplexity request your HTML and read what comes back. Vercel measured this across their network: the crawlers sometimes download your JavaScript files, and none of them ever execute one. When someone asks an assistant "what is the best tool for X" and it goes looking, your site answers with an empty div. It cannot quote you, cite you, or recommend you, because as far as it can tell your site says nothing. Referral traffic from assistants is still a small slice of the total, and it is also the fastest growing one, with ChatGPT referrals roughly tripling year over year. The cost of being invisible to them is going up, not down.
Link previews do not run JavaScript. The card that appears when your site is shared in Slack, iMessage or LinkedIn is built from the raw HTML. If your Open Graph tags are set from inside React, every share of your app renders as a blank card with a bare URL. People share links far more often than they link to websites, and this is the face your product makes every time.
Bing renders less, and less predictably. It executes JavaScript some of the time, with a smaller budget than Google, and Bing's own guidance suggests serving it pre-rendered HTML rather than relying on that. Bing matters more than its market share suggests, because its index feeds other engines and several of the AI assistants.
And the user pays too. A client-rendered page cannot show content until the JavaScript downloads, parses, runs and fetches data. That chain sits directly under Largest Contentful Paint, which is a ranking input. Rendering on the server does not just change what crawlers see, it changes how fast humans see anything.
So the honest summary of "SEO without SSR" in 2026: visible to Google, invisible to the assistants your customers are starting to ask instead of Google.
When skipping SSR is the right call
If your app is a product that lives behind a login, most of it should not be indexed anyway. Nobody needs your dashboard in search results. What needs to rank is the marketing surface: the homepage, a pricing page, a handful of feature pages, maybe a blog.
For that shape of product, the answer is not rewriting the app. It is taking those few public routes and making them static: prerender them at build time, or serve a small static marketing site in front of the app. The product stays exactly as it is, the pages that need to be read by everything are readable by everything, and the whole job is measured in days.
That is not a compromise version of SSR. For this shape of product it is simply the correct architecture.
When it is not enough
The calculation flips when the content is the product. A blog that drives your funnel. Programmatic pages, one per city or integration or use case. A directory, a docs site, anything where the pages people search for number in the dozens or hundreds and change often. Prerendering strains and then breaks under that, and you end up rebuilding a worse version of server rendering out of build scripts.
It also flips if being quoted by AI assistants matters to your business. There is no client-rendered route to that. The crawler gets HTML once, with no browser and no second pass, and either the content is in it or you are not in the answer.
That is the point where converting to a framework that renders on the server, usually Next.js for the React apps we see, stops being an SEO chore and becomes the thing that puts you in front of both kinds of searcher at once.
Deciding in one paragraph
Ask where your next customer's first impression happens. If it is your homepage and a pricing page, prerender those and spend the rebuild money on the product. If it is a search result for content you publish, or an answer inside ChatGPT, the pages doing that work need to exist as real HTML, and rendering on the server is how they come to exist.
This is the work we do at Thunkle: making apps built with AI tools visible to the things that now decide visibility, from technical SEO on what you have through converting it to render on the server when that is what the goal requires. If you are not sure which side of the line your app sits on, send it over and we will tell you which one you actually need.
Working on something like this?
If you're migrating, securing or building an AI-made app, Thunkle can help. Get a fixed quote in 24 hours.