Server-side rendering: Tjeklisten for indholdssites

Server-side rendering er den enkleste garanti for, at både klassiske og AI-drevne crawlere ser dit fulde indhold: alt væsentligt står i den HTML, serveren sender i første svar. Men “vi har SSR” er en påstand, ikke et faktum — den skal verificeres punkt for punkt, for moderne opsætninger bryder garantien de mest overraskende steder.

Denne tjekliste er skrevet til indholdssites — blogs, vidensbaser, nyhedsmedier og virksomhedssites — og gennemgår de ni punkter, der i praksis afgør, om et “server-renderet” site reelt leverer. Kør den efter temaskift, større opdateringer og ved mistanke om synlighedsproblemer. De tre hyppigste syndere er punkt 1, 4 og 7.

De ni kontrolpunkter

1. Curl-testen på kerneindholdHent siden med curl, og bekræft at kernetekst, overskrifter og interne links står i den rå HTML. Fejler dette punkt, er resten af listen ligegyldig — se JavaScript-guiden for løsninger.
2. Titel og meta description server-sideBegge skal genereres på serveren. Klient-JavaScript, der omskriver <title>, er usynligt for ikke-renderende crawlere og giver inkonsistente snippets.
3. Canonical og robots-direktiver i første svarDirektiver, der først indsættes klientside, bliver ignoreret eller mislæst — med duplikatindhold og utilsigtet afindeksering som konsekvens.
4. Strukturerede data i det leverede dokumentJSON-LD skal med i serverens svar. Tag-managers, der injicerer schema klientside, består Googles test i browseren, men fejler for AI-crawlere. Se schema-guiden.
5. Billeder med rigtige src-attributterNative lazy-loading med korrekte src-værdier er fint; JS-baseret lazy-loading uden fallback gør billederne usynlige.
6. Pagination som rigtige linksArkiver og lister skal bruge ægte <a href>-links. “Load more”-knapper uden URL’er gør alt efter side 1 usynligt for crawlere.
7. RSS-feeds med fuldt indholdFeeds er agenters og AI-systemers foretrukne genvej til struktureret indhold. Verificér at feedet virker, indeholder fuldt indhold eller fyldige uddrag, og opdateres ved publicering.
8. Korrekte statuskoder404 skal svare 404 — ikke en pæn fejlside med status 200 (soft-404), og redirects skal være 301/308 på serverniveau, ikke JavaScript-omdirigeringer.
9. Indhold uden tredjepartsafhængighedSiden skal vise sit kerneindhold, selv når tredjepartsscripts fejler eller blokeres. Test med scripts slået fra — det er sådan, en crawler ser siden.

“Vi har SSR” er en påstand, ikke et faktum — den skal verificeres punkt for punkt.

Hvorfor er netop 1, 4 og 7 de hyppigste syndere?

Punkt 1 fejler, fordi delvist SSR er blevet normen: skelettet renderes på serveren, mens indholdsblokke hydreres ind bagefter — og ingen opdager det, fordi browseren viser det hele. Punkt 4 fejler, fordi schema ofte lever i en tag manager, som var det bekvemmeste sted at implementere det — og tag managers kører klientside. Punkt 7 fejler, fordi RSS opfattes som en relikvie fra 2010 og glemmes ved redesigns, selvom feeds i praksis har fået nyt liv som datakilde for AI-systemer og indholdsagenter.

Fællesnævneren er, at alle tre fejl er usynlige i en browser. Det er derfor, tjeklisten insisterer på at teste med curl og uden scripts: du skal se sitet, som maskinerne ser det, ikke som det præsenterer sig for mennesker.

Gør verifikationen til en rutine

Kør den fulde liste kvartalsvis og efter enhver ændring af tema, framework eller cache-opsætning. De tre kritiske punkter (1, 3 og 8) kan automatiseres med et simpelt script, der curl’er nøglesider og tjekker for kernetekst, canonical og statuskoder — fem minutters arbejde, der fanger regressioner, før de koster synlighed. SSR-tjeklisten hører hjemme i samme rutine som crawler-adgangstjekket og udgør sammen med det den tekniske bund i AgenticSEO-pyramiden.

Automatisér de tre kritiske punkter

Punkt 1, 3 og 8 kan overvåges maskinelt med et script på under en skærmfuld: curl mod en håndfuld nøglesider, grep efter en kendt kernetekst-streng, tjek af canonical-tagget i outputtet og verifikation af statuskoder på en kendt 404-URL og en kendt redirect. Kør det dagligt via cron, og lad det alarmere ved afvigelser. Det lyder banalt — og det er netop pointen: de fleste SSR-regressioner er banale at opdage maskinelt og pinlige at opdage manuelt tre måneder senere.

Gør samtidig verifikationen til et leverancekrav: enhver frontend-opgave — temaskift, ny page builder, cache-ændring — afsluttes med, at tjeklisten køres, og resultatet dokumenteres. Det flytter ansvaret derhen, hvor ændringen sker, og gør “vi har SSR” fra en antagelse til en løbende verificeret egenskab.

Ofte stillede spørgsmål

Mit site består Googles mobilvenlighedstest — er jeg så ikke dækket?

Nej. Googles testværktøjer renderer JavaScript, ligesom Googlebot gør. De fanger derfor ikke indhold, der kun findes efter rendering — og det er netop det, AI-crawlere ikke ser. Curl-testen er den eneste, der viser maskinernes rå udgangspunkt.

Gælder tjeklisten også for webshops?

Ja, med skærpet vægt på punkt 5, 6 og 8: produktbilleder, kategori-pagination og statuskoder på udgåede varer. Dertil kommer Product-schema med priser i det server-leverede dokument, så sammenlignende agenter kan læse dem — se schema-guiden.

Hvor tit brydes SSR-garantien i praksis?

Oftest ved redesigns og skift til nye frameworks eller page builders — altså netop de projekter, hvor ingen tænker på crawlere, fordi alt ser flot ud i browseren. Gør curl-verifikationen til et fast punkt i enhver frontend-leverance, så fanges regressionen samme dag, den opstår.

Senest revideret 31. august 2026. Artiklen gennemgås løbende, når AI-søgelandskabet flytter sig.