What is SSR (server-side rendering)?

When someone, or something, requests a product page, the store answers with an HTML document. The question this term settles is what that first document carries: the product's name, price and data already written out, or a nearly empty page and a JavaScript file that assembles them afterward in the browser. Here SSR is not the "SSR" rarity tier of gacha games: it is server-side rendering. It matters to you because not everything that reads your store runs JavaScript, and what is not in the first response may never be read by anyone except a person with a browser.

How it works

The reference guide on web.dev, written by Addy Osmani and Jason Miller and updated on January 5, 2026, distinguishes these ways of producing a page:⁠^{[1]web.dev (Addy Osmani and Jason Miller). Rendering on the Web}

Web.dev defines SSR as rendering an application on the server to send HTML, rather than JavaScript, to the client, and client-side rendering as rendering it in the browser, using JavaScript to modify the DOM.⁠^{[1]web.dev (Addy Osmani and Jason Miller). Rendering on the Web} The practical difference is in the first response: with SSR, whoever downloads it already has the content; with client-side rendering, they have to run the JavaScript to see it.

Google does run JavaScript, but in a second phase. It processes pages in three steps: crawling, rendering and indexing. Googlebot queues pages that respond with a 200 status code for rendering, and a page can spend a few seconds or longer in that queue. Even so, Google's documentation says that server-side rendering or pre-rendering is still a great idea, because it makes the website faster for users and crawlers, and because not all bots can run JavaScript.⁠^{[2]Google Search Central. Understand JavaScript SEO basics}

For years, one way out was dynamic rendering: serving bots a pre-rendered version and people the usual one. Google now describes it as a workaround it does not recommend, because it adds complexity and uses resources, and proposes instead server-side rendering, static rendering or hydration.⁠^{[3]Google Search Central. Dynamic rendering as a workaround}

AI crawlers and the initial HTML

The "not all bots" part has become concrete with the crawlers of the AI companies. Vercel, with the consultancy MERJ, analyzed its network's and nextjs.org's traffic for several months, and published on December 17, 2024 that none of the major AI crawlers rendered JavaScript: among them, OpenAI's (OAI-SearchBot, ChatGPT-User and GPTBot) and Anthropic's (ClaudeBot). They downloaded JavaScript files but did not execute them. The exceptions it pointed out were Gemini, which uses Googlebot's infrastructure, and AppleBot, which renders with a browser.⁠^{[4]Vercel, with MERJ. The rise of the AI crawler}

Read that figure with its date and its scope: it is one company's measurement of its own network, from late 2024, and crawlers change. What does not change is the practical conclusion, which matches Google's: if a piece of data has to be readable by any crawler, it has to be in the initial HTML.

In a store

Fictional example. The same backpack product page, served two ways. With client-side rendering, the store's first response is this:

<body>
  <div id="app"></div>
  <script src="/assets/store.js"></script>
</body>

The name, the price and the structured data exist, but inside store.js, and they only appear when someone runs it. With server-side rendering, the first response already carries them:

<body>
  <h1>Hiking backpack 30 L</h1>
  <p class="price">$89.00</p>
  <script type="application/ld+json">
    {
      "@context": "https://schema.org",
      "@type": "Product",
      "name": "Hiking backpack 30 L"
    }
  </script>
</body>

On Shopify, themes are written in Liquid, which is resolved on the server, and Shopify recommends painting essential content that way, with Liquid and HTML, instead of with JavaScript frameworks in the browser: the initial HTML works without JavaScript.⁠^{[5]Shopify.dev. Render essential content server-side} That is why a piece of data stored in metafields and painted by the theme arrives in the first response. Clione publishes its structured data through each platform's native routes, rendered on the server: a BigCommerce widget on BigCommerce, and metafields with a Shopify app embed on Shopify, without injecting them with JavaScript in the browser.

How to check it

1. Open the product page and look at the source code (in most browsers, Ctrl+U or Cmd+Option+U). That is the initial response. Look for the product name, the price and application/ld+json.
2. Compare it with the inspector. What appears in the inspector and not in the source code was added by JavaScript afterward.
3. Download it from the terminal, with no browser: curl -s https://your-store.example/products/backpack | grep "ld+json". If it returns nothing, the structured data is not in the initial HTML.
4. Turn off JavaScript in the browser and reload the product page. Whatever disappears depends on JavaScript to be shown.
5. Look at what Google rendered. The URL Inspection tool in Search Console and the one Google offers to check rich results, the Rich Results Test, show the rendered HTML.⁠^{[2]Google Search Central. Understand JavaScript SEO basics} Remember that this is what Google sees after running JavaScript, not what a bot that does not run it sees.

Related concept: JavaScript rendering

JavaScript rendering is the step in which a browser, or a crawler like Googlebot, executes a page's scripts to get its final content. SSR aims to make that step unnecessary for reading the essentials: the content already arrives written out, and JavaScript only adds interactivity on top, as in hydration.⁠^{[1]web.dev (Addy Osmani and Jason Miller). Rendering on the Web} A headless store can use either technique, which is why it pays to ask which one it uses before assuming its product pages can be read.

To keep going, the publishing by platform reading path explains how each piece of data reaches the store on Shopify and on BigCommerce.