Dynamic rendering

Bij dynamic rendering kijkt je server naar de user-agent. Is het een crawler, dan krijgt die statische HTML uit een prerender-dienst. Gewone bezoekers krijgen de JavaScript-app. Het idee was dat crawlers zo geen JavaScript hoeven uit te voeren.

Google schrijft in de documentatie dat dynamic rendering een workaround was en geen oplossing voor de lange termijn. Het wordt niet aangeraden, omdat het extra complexiteit en resources kost. Google raadt server-side rendering, static rendering of hydration aan.

Is het cloaking? Volgens Google meestal niet, zolang de inhoud voor crawler en bezoeker vergelijkbaar is. Krijgen crawlers totaal andere content, dan kan het wel als cloaking gelden.

Magento en Shopify renderen pagina's standaard op de server. Daar is dynamic rendering niet nodig. Het speelt alleen bij headless-opzetten, zoals een PWA Studio-, Vue Storefront- of Hydrogen-frontend, als die verkeerd geconfigureerd zijn.

Bij Hyvä is de HTML server-side gerenderd en voegt Alpine.js interactie toe. Crawlers krijgen direct de inhoud.

In Laravel met Inertia of een losse Vue- of React-frontend kun je beter SSR aanzetten dan een prerender-dienst ervoor zetten. Inertia ondersteunt SSR; dan krijgen crawler en bezoeker dezelfde HTML.

- Een prerender-cache die achterloopt. Crawlers zien dan oude prijzen of uitverkochte producten als beschikbaar.

- Andere content of andere links aan crawlers tonen dan aan bezoekers. Dat schuift richting cloaking.

- Bots verkeerd detecteren, waardoor AI-crawlers of Bingbot de lege JavaScript-versie krijgen.

- Dynamic rendering houden terwijl het framework allang SSR kan. Dan onderhoud je twee rendering-paden voor niets.