Server-Side Rendering in Rails: Does It Still Matter for SEO?

Every few months a Rails team asks us the same question, usually halfway through a front end rewrite. Google renders JavaScript now, so does it matter whether the new React front end ships real HTML? Can we point it at the Rails API and let Googlebot sort it out?

It is a fair question built on an outdated premise. The answer in 2026 has two halves, and they point in opposite directions. For Google, server-side rendering matters less than the folklore says. For almost every other system that decides whether people find you, it matters more than it ever has.

The core position

Google renders JavaScript. The crawlers behind ChatGPT, Claude and Perplexity do not. Server-rendered HTML is no longer a Google optimisation; it is the price of being readable by answer engines at all. And Rails, by default, already pays it.

What Google actually does with JavaScript in 2026

The best public data comes from Vercel and MERJ, who analysed more than 100,000 Googlebot fetches in April 2024. Every valid HTML page in the sample was fully rendered, including pages whose content existed only after JavaScript ran. Google did not apply separate indexing criteria to JavaScript pages. The old line that Google cannot see client rendered content is dead, and anyone still selling server-side rendering on that basis is selling a myth.

But look at the tail, because that is where the business risk lives. Rendering is not instant: pages wait in a queue. The median render delay was about 10 seconds, the 75th percentile 26 seconds, and the slowest tenth waited around three hours. For a price change, a product launch or a news page, three hours is a long time to exist in Google only as an empty shell. Rendering can also fail quietly: a blocked script, an API that times out for the crawler, an error on a route nobody tests in a headless browser. Google’s own documentation has not softened on this: it describes dynamic rendering as a workaround rather than a solution and recommends server-side rendering, static rendering or hydration instead.

The crawlers that never run your JavaScript

Now the half of the answer that changed. Across Vercel’s network, OpenAI’s GPTBot made 569 million requests in a single month and Anthropic’s crawler 370 million, together about 20 percent of Googlebot’s 4.5 billion. That is no longer a rounding error in your logs. And neither of them executes JavaScript. Both download script files (ChatGPT’s crawler in about 11.5 percent of its requests, Claude’s in about 23.8 percent) but they never run them. Across more than 500 million GPTBot fetches, the researchers found zero evidence of JavaScript execution. PerplexityBot behaves the same way.

The answer engines built on those crawlers see exactly what your server sends in the first response, and nothing more. If that response is an empty root element and a bundle, your content does not exist to them, however well the same page ranks on Google.

Why Rails is quietly in the best position of any stack

Here is the irony. Since Rails 7 shipped in December 2021, a new Rails app defaults to Hotwire: Turbo and Stimulus, a philosophy named, literally, HTML over the wire. The server renders the page, Turbo swaps it in without a full reload, and Stimulus attaches behaviour to markup that already exists. A default Rails app sends every crawler in that table a complete document. The stack many teams walked away from in search of a modern front end turns out to match how answer engines read the web better than most of the alternatives.

So the risk for Rails teams is not the framework. It is drift: the gradual, well intentioned decisions that move content out of the first response, one component at a time, until the page a crawler receives is a frame around a set of placeholders.

Five Rails front ends, ranked by what a crawler receives

• ERB or ViewComponent with Hotwire. The default, and the gold standard. Every URL returns a finished document. Turbo Drive’s fetch based navigation is irrelevant to crawlers, because they request each URL directly and get full HTML back.
• Inertia with SSR enabled. React, Vue or Svelte components, rendered to HTML by a Node process that Rails dispatches to. Full pages for every crawler, at the cost of running and monitoring a second runtime, as the Inertia Rails SSR guide sets out.
• Hotwire with lazy Turbo Frames. Mostly server rendered, with holes. This is the trap most healthy Rails apps fall into, and it gets its own section below.
• Inertia without SSR. The page props ship as a JSON payload inside a mostly empty shell. Google renders it into a page; the AI crawlers receive data, not content.
• Rails API plus a separate SPA. An empty root element and a bundle. Every word on the page depends on JavaScript running, which is exactly what half the crawlers above will not do.

The Turbo Frame trap

The most common way we see well built Rails apps leak content is also the most innocent. Turbo Frames can load their content from a separate URL and, with lazy loading, only once the frame scrolls into view. It is a genuinely good performance pattern, and it hides content from crawlers by design:

<%= turbo_frame_tag "reviews",
      src: product_reviews_path(@product),
      loading: :lazy do %>
  <p>Loading reviews…</p>
<% end %>

A crawler that does not execute JavaScript receives exactly one sentence of that section: loading reviews. Googlebot usually triggers lazy frames, because it renders pages with a very tall viewport, but no AI crawler ever will. And reviews are precisely what answer engines quote when someone asks whether a product is any good.

The fix keeps the first page of real content in the initial response and reserves deferred loading for what is genuinely secondary:

<%= turbo_frame_tag "reviews" do %>
  <%= render @product.reviews.recent.limit(10) %>
  <%= link_to "More reviews",
        product_reviews_path(@product, page: 2) %>
<% end %>

The rule we apply in every audit is simple. If you want it ranked, cited or quoted, it goes in the first response. Lazy load personalisation, carts, notifications and anything behind a login. Never lazy load the answer.

Rendering is also a Core Web Vitals decision

Server-rendered HTML puts the largest element on screen without waiting for a bundle to download, parse and execute, which is most of the battle for Largest Contentful Paint. Shipping less JavaScript also helps Interaction to Next Paint, the responsiveness metric that replaced First Input Delay in March 2024, because a lighter main thread answers taps faster. We have seen what disciplined rendering does to these numbers; it is a large part of how we brought LCP under 1.5 seconds for a Shopify Plus store.

The trade is that server rendering moves work onto your servers, so Time to First Byte becomes your problem. Rails has mature answers to it: fragment and Russian doll caching around expensive partials, conditional HTTP caching with fresh_when and stale?, a CDN in front of anonymous pages, and, since Rails 8, Solid Cache as the default cache store, which makes large, disk backed caches cheap to run. A slow server-rendered page is a caching problem. It is not an argument for client rendering.

How to see what crawlers see, in five minutes

1. Fetch the raw HTML. Nothing executes JavaScript in curl, which makes it a faithful stand in for GPTBot and ClaudeBot. Pick a sentence that matters on the page and count it in the raw response; a zero means the answer engines cannot see it.
2. Inspect the rendered version. In Search Console, URL Inspection then View crawled page shows the HTML Googlebot produced after rendering. Every difference between that and the raw fetch is content that depends on the render queue.
3. Turn JavaScript off. Browse your key templates with JavaScript disabled. What you can still read is what half the crawlers read.
4. Audit the drift. Search the views for deferred frames and for routes that return an empty root element.

curl -s https://yoursite.com/products/example \
  | grep -c "a sentence from your reviews"

grep -rn "loading: :lazy" app/views

So, does it still matter?

For Google rankings alone, server-side rendering is no longer the difference between indexed and invisible. Google renders, and a carefully built client rendered site can rank. What server rendering buys you with Google today is speed, reliability and freedom from the render queue: real advantages, but incremental ones.

For AI search, it is binary. Either the answer is in the first response or, to the crawlers feeding ChatGPT, Claude and Perplexity, it does not exist. As more discovery moves into answer engines, that stops being an edge case and becomes the main event. Where the answer should shape the build:

• Public, indexable surfaces (marketing pages, product and category pages, documentation, articles): render on the server, always.
• Large or fast changing sites: render on the server, because every hour in the render queue is an hour of stale results.
• Logged in application surfaces: render however your product team is happiest. Crawlers never see them.

That split, a server-rendered public surface and whatever the product needs behind the login, is where most healthy Rails companies land, and it is the architecture we default to in our Tech engine. If a rebuild is on your roadmap, the rendering decision belongs in the first week of planning, not the last, for the same reasons we set out in how to redesign a website without losing SEO traffic, and it is the first question we ask on every website redesign we run. The answer engine half of the argument is covered in depth in our guide to getting your brand cited by AI.

Not sure what your Rails app actually sends to crawlers? Book 15 minutes and we’ll curl it together.