I nogle løsninger vises siden ikke på helt samme måde for mennesker og søgemaskiner. Dynamic rendering, på dansk dynamisk rendering, betyder, at et website sender én version til almindelige brugere og en særskilt, færdigrenderet HTML-version til crawlere.
Formålet er at gøre indholdet lettere for søgemaskiner at læse og indeksere, især på websites der er meget afhængige af JavaScript. Brugeren får stadig den normale, interaktive side, mens crawleren modtager en version, hvor indholdet allerede er gjort klar.
I teknisk SEO bruges løsningen for at sikre, at vigtige tekster, links og metadata kan opdages korrekt. Det er især relevant, når søgemaskiner ellers kan have svært ved at gengive siden fuldt ud.
Løsningen bygger på, at serveren først vurderer, hvem der beder om siden. Når en forespørgsel kommer ind, registreres brugeragenten, så systemet kan skelne mellem en almindelig browser og en søgemaskinerobot som Googlebot. Formålet er ikke at vise forskelligt indhold, men at levere samme indhold i et format, der er lettere at behandle for robotter, når JavaScript ellers ville gøre siden tung at gengive.
Hvis forespørgslen kommer fra en almindelig bruger, sendes den normale version af siden. Her indlæses indhold, funktioner og elementer i browseren med JavaScript, præcis som webstedet er bygget til. Kommer besøget derimod fra Googlebot eller andre søgemaskiner, sendes en forudrenderet HTML-version. Den er allerede genereret på forhånd eller lige før levering, så væsentligt indhold kan læses direkte uden at vente på, at JavaScript bliver kørt.
I praksis betyder det, at et forudrenderingsværktøj henter siden, afvikler JavaScript og gemmer resultatet som færdig HTML. Når robotten besøger siden, får den denne udgave, mens brugere fortsat ser den interaktive version. Det gør indeksering mere stabil, især på komplekse JavaScript-tunge sider, men kræver løbende vedligeholdelse for at sikre, at begge versioner svarer til det samme indhold.
Metoden er især relevant, når søgemaskiner har svært ved at se det samme indhold som brugeren. Det gælder ofte JavaScript-tunge websites, hvor centrale tekster, produktdata, kategorier eller interne links først indsættes efter rendering i browseren. Et typisk eksempel er en single-page application, hvor vigtige landingssider fremstår næsten tomme i den rå HTML.
Dynamic rendering kan også være fornuftigt, hvis et større site allerede er i drift, og en fuld teknisk omlægning ikke er realistisk på kort sigt. Her kan løsningen fungere som en bro, mens udviklingsteamet arbejder mod server-side rendering, statisk generering eller bedre prerendering. Det er normalt en midlertidig løsning, ikke det langsigtede ideal.
Valget giver mest mening, når problemet er konkret dokumenteret: utilstrækkelig indeksering, manglende gengivelse af vigtigt indhold eller tydelige forskelle mellem det, brugere og crawlere modtager. Hvis jeres sider allerede kan crawles og indekseres korrekt, vil ekstra kompleksitet sjældent være umagen værd.
Dynamic rendering kan i nogle tilfælde gøre det lettere for søgemaskiner at crawle og indeksere sider, der ellers er tunge at gengive i JavaScript. Det kan især hjælpe på websites, hvor vigtigt indhold først bliver synligt sent i browseren, eller hvor interne links er svære at finde for crawlere. En servergenereret version kan derfor forbedre adgangen til tekst, metadata og navigation og dermed mindske risikoen for, at væsentlige sider overses.
Løsningen har dog klare begrænsninger. Den tilfører et ekstra teknisk lag, som skal driftes, overvåges og vedligeholdes. Det gør fejlfinding mere kompleks, fordi problemer kan opstå i både den normale version og den version, der vises til crawlere. Hvis rendering-pipelinen fejler, kan søgemaskiner modtage tomme sider, forældet indhold eller mangelfulde elementer.
Der er også en reel risiko for uoverensstemmelse mellem versioner. Hvis brugere ser ét indhold, mens crawlere får en anden udgave, kan det skabe inkonsistens i indekseringen og i værste fald ligne cloaking. Forskellene behøver ikke være tilsigtede for at give problemer; de kan opstå gennem cache, deployments, scripts eller forskelle i skabeloner og data.
Dynamic rendering bør derfor ses som en midlertidig eller situationsbestemt løsning, ikke som generel bedste praksis. Metoden kan afhjælpe konkrete crawlerudfordringer, men den øger også driftsbyrden og fejlrisikoen. Derfor kræver den løbende test, dokumentation og kontrol af, at indhold, links og metadata stemmer overens på tværs af versionerne.
Dynamic rendering skal især forstås som en særlig leveringsstrategi, ikke som en grundlæggende renderingsmodel. Hvor client-side rendering sender et let HTML-skelet og lader browseren bygge indholdet med JavaScript, sender dynamic rendering i stedet en forudrenderet HTML-version til søgemaskiner og ofte den normale JavaScript-baserede version til brugere. Formålet er primært bedre indeksering, ikke nødvendigvis hurtigere brugeroplevelse.
Server-side rendering genererer HTML på serveren ved hver forespørgsel. Det giver som regel søgemaskiner og brugere samme indhold med det samme, men kræver mere serverkapacitet og en mere avanceret opsætning. Statisk rendering bygger derimod HTML på forhånd, typisk ved deploy eller build. Det er ofte hurtigt, stabilt og enkelt at cache, men mindre fleksibelt ved hyppige ændringer eller personaliseret indhold.
Hydration er ikke en konkurrerende metode i sig selv, men et lag oven på server-side eller statisk rendering. Her vises HTML først, hvorefter JavaScript gør siden interaktiv i browseren. Det kan forbedre oplevelsen, fordi indholdet bliver synligt tidligt, men det øger også kompleksiteten og kan give fejl, hvis serverens HTML og browserens tilstand ikke matcher.
I praksis adskiller dynamic rendering sig ved at levere forskellige versioner afhængigt af modtageren. Det kan løse indekseringsproblemer i JavaScript-tunge løsninger, men gør arkitekturen mere kompleks og skaber risiko for forskelle mellem det, brugere og crawlere ser. Derfor betragtes det ofte som en midlertidig løsning, mens server-side rendering eller statisk rendering som regel er mere robuste valg.
Dynamic rendering bliver stadig i visse tilfælde accepteret af søgemaskiner, men det opfattes som udgangspunkt ikke som den foretrukne, langsigtede løsning. Google har i dag beskrevet metoden som en midlertidig afhjælpning, der kan være relevant, hvis et website har væsentlige problemer med JavaScript-rendering og endnu ikke kan implementere en bedre arkitektur.
Det betyder ikke, at løsningen nødvendigvis er forkert. I praksis kan den fortsat bruges, når den samme primære information vises til både brugere og crawlere, og når formålet er teknisk tilgængelighed frem for manipulation. Der er dog forbehold, fordi opsætningen ofte er mere kompleks at vedligeholde og kan øge risikoen for uoverensstemmelser mellem versioner.
I de fleste moderne opsætninger vil andre renderingsstrategier ofte være at foretrække, for eksempel serverside-rendering, statisk generering eller hybride løsninger. De giver typisk en mere robust, fremtidssikret og vedligeholdelsesvenlig struktur end særskilt rendering til bots.
De største SEO-problemer opstår sjældent i princippet, men i selve implementeringen. En klassisk fejl er forældet cache, hvor crawleren får en ældre prerenderet version end den bruger, der besøger siden i browseren. En anden fejl er, at den prerenderede HTML mangler centralt indhold som produkttekst, interne links eller metadata. Det kan svække både indeksering og forståelse af siden.
Der ses også fejl i brugeragent-detektion. Hvis systemet identificerer crawlere forkert, kan rigtige søgemaskiner få den almindelige JavaScript-version, mens andre klienter fejlagtigt får prerenderet indhold. I værste fald opstår der store forskelle mellem versionerne, så opsætningen ligner cloaking, selv om det ikke var hensigten.
Test derfor altid med flere metoder. Brug URL-inspektion til at kontrollere, hvordan søgemaskinen gengiver og læser siden. Sammenlign også den rå HTML fra den prerenderede version med den HTML, en normal bruger modtager, og se efter forskelle i tekst, links, titler og strukturerede data. Gennemgå desuden logfiler for at bekræfte, at crawlere faktisk rammer prerender-tjenesten og får opdaterede svar med korrekt statuskode.
Dynamic rendering er en metode, hvor et website viser den normale JavaScript-version til brugere, men sender en forudrenderet HTML-version til søgemaskiners crawlere. Formålet er at gøre indholdet lettere at crawle og indeksere, når siden ellers er tung at gengive.
I SEO bruges løsningen især på websites, hvor vigtigt indhold, links eller metadata først bliver synligt efter JavaScript er kørt i browseren.
Systemet registrerer, hvilken type klient der besøger siden, typisk via brugeragenten. Almindelige brugere får den normale version, mens en crawler som Googlebot kan få en HTML-version, hvor siden allerede er renderet færdig.
Det sker normalt ved hjælp af en prerender-tjeneste, som henter siden, afvikler JavaScript og gemmer resultatet som HTML. Den version sendes derefter til crawleren.
Det giver mest mening, når et JavaScript-baseret website har dokumenterede problemer med crawling eller indeksering. Det kan for eksempel være, hvis søgemaskiner ikke ser centrale tekster, interne links eller produktsider korrekt.
Som regel bør det ses som en midlertidig løsning, især hvis en mere holdbar arkitektur som server-side rendering endnu ikke kan indføres.
Google har beskrevet dynamic rendering som en midlertidig løsning og ikke som den foretrukne langsigtede tilgang. Den kan stadig være acceptabel i særlige tilfælde, men den regnes normalt ikke som bedste praksis.
Hvis det er muligt, vil løsninger som server-side rendering eller statisk generering ofte være mere robuste og enklere at vedligeholde.
Ved dynamic rendering får brugere og crawlere ikke nødvendigvis samme tekniske version af siden. Brugeren kan få den JavaScript-baserede udgave, mens crawleren får færdigrenderet HTML.
Ved server-side rendering genereres HTML på serveren til alle besøgende. Det giver typisk en mere ensartet løsning, fordi både brugere og søgemaskiner modtager det samme grundindhold fra starten.
Ja, i nogle tilfælde kan det forbedre indekseringen, fordi søgemaskinen modtager indholdet direkte som HTML i stedet for selv at skulle gengive hele siden med JavaScript. Det kan hjælpe, hvis vigtigt indhold ellers bliver overset.
Effekten afhænger dog af, om problemet faktisk skyldes rendering. Hvis siden allerede bliver læst korrekt af søgemaskiner, giver løsningen ofte ingen reel gevinst.
Den største risiko er, at versionen til crawlere og versionen til brugere ikke længere stemmer overens. Hvis indhold, links eller metadata afviger, kan det give fejl i indekseringen og skabe mistanke om cloaking.
Derudover øger løsningen den tekniske kompleksitet. Cache-fejl, forældet prerenderet indhold og fejl i brugeragent-detektion er blandt de mest almindelige problemer.
Ikke nødvendigvis. Dynamic rendering er normalt acceptabelt, hvis formålet er at gøre det samme indhold teknisk tilgængeligt for crawlere, ikke at vise søgemaskiner noget andet end brugerne ser.
Det bliver problematisk, hvis der opstår væsentlige forskelle mellem versionerne. Derfor er det vigtigt, at budskab, indhold og links i praksis svarer til hinanden.
Start med at sammenligne den prerenderede HTML med den version, en almindelig bruger får. Se især på hovedindhold, interne links, metadata, kanoniske tags og strukturerede data.
Brug også URL-inspektion i Google Search Console og gennemgå serverlogfiler. På den måde kan du kontrollere, om crawlere faktisk får den rigtige version, og om statuskoder, cache og opdateringer fungerer som forventet.
Behovet ses oftest på JavaScript-tunge websites, især single-page applications og større frontendløsninger, hvor indhold først bliver indsat sent i browseren. Det gælder for eksempel nogle e-handelsløsninger, katalogsites og avancerede webapps.
Hvis vigtige sider allerede kan crawles og indekseres uden problemer, er der som regel ikke grund til at indføre dynamic rendering.