Definitie
Bij server-side rendering maakt de server per request de complete HTML van een pagina. Browser en zoekmachine krijgen direct alle content, zonder eerst JavaScript uit te voeren.
Wat is server-side rendering?
Bij server-side rendering (SSR) bouwt de server de volledige HTML van een pagina en stuurt die naar de browser. Titel, productnaam, prijs, beschrijving en links staan direct in het antwoord. JavaScript kan daarna interactie toevoegen, maar is niet nodig om de content te zien.
Het tegenovergestelde is client-side rendering, waarbij de browser een bijna lege pagina krijgt en alles met JavaScript opbouwt. Daartussen zitten varianten: static site generation (HTML vooraf bouwen), incremental static regeneration (vooraf bouwen en periodiek verversen) en streaming SSR (HTML in delen versturen).
Waarom het ertoe doet voor webshops
Googlebot kan JavaScript renderen, maar doet dat in een aparte stap die later kan komen en kan mislukken. Met SSR staat alles in de eerste HTML en is er niets om op te wachten. Dat geldt ook voor andere crawlers: voor zover bekend voeren de meeste AI-crawlers geen JavaScript uit. Wat niet in de HTML staat, bestaat voor hen niet.
Voor snelheid helpt SSR vooral bij LCP: de browser ziet de hoofdafbeelding meteen in de HTML en kan hem direct ophalen. De keerzijde is serverwerk per request. Zonder caching gaat dat ten koste van TTFB.
Er is nog een voordeel dat vaak vergeten wordt: social previews en berichten-apps. Als iemand een productlink deelt, haalt de app de Open Graph-tags op uit de HTML. Bij SSR staan titel, afbeelding en prijs er direct in. Bij een pure client-side app ziet de preview vaak alleen de algemene sitetitel.
Zo werkt het in Magento, Shopify en headless
Magento is van zichzelf server-side: PHP-templates leveren de HTML, Varnish cachet het resultaat. Luma laadt daarna veel JavaScript, maar de content staat al in de HTML. Hyvä houdt hetzelfde server-side model en voegt met Alpine.js alleen lichte interactie toe.
Shopify rendert thema's met Liquid op de server en cachet aan de rand van het netwerk. Ook hier staat de content standaard in de HTML. Let wel op apps die content (reviews, specificaties, gerelateerde producten) pas in de browser toevoegen.
Bij headless commerce, zoals een React- of Vue-frontend op Magento of Shopify (Hydrogen), is SSR een keuze die je bewust moet maken. Frameworks als Next.js, Nuxt en Remix ondersteunen het, maar een verkeerd geconfigureerde route valt zonder dat iemand het merkt terug op client-side rendering.
Hoe controleer je het?
Bekijk de paginabron (view-source), niet de element-inspector. De inspector toont de DOM na JavaScript; de bron toont wat de server stuurde. Staan productnaam, prijs, H1, canonical en de links naar andere producten in de bron, dan zit je goed. Een snelle check is curl met een grep op je H1.
Doe die check op verschillende templates: homepage, categorie, product, CMS-pagina en een gefilterde URL. Het komt voor dat één template, vaak een nieuw toegevoegde, toch client-side rendert.
Staat de content in de server-HTML?
curl -s https://www.voorbeeldshop.nl/heren/sneakers \
| grep -o '<h1[^>]*>[^<]*</h1>'Verder lezen
Veelgestelde vragen
Is SSR altijd beter voor SEO?+
Voor webshops vrijwel altijd. Alles wat moet ranken staat dan in de eerste HTML. Het kost wel serverwerk, dus caching hoort erbij.
Is mijn Magento- of Shopify-shop server-side gerenderd?+
Standaard wel. Controleer alleen of apps, zoek- of filtertools content niet alsnog in de browser toevoegen.