JavaScript og AI-crawlere: Derfor skal kerneindholdet stå i HTML

Googlebot renderer JavaScript — det gør flere af AI-crawlerne ikke, eller kun delvist og med lav prioritet. Konsekvensen er kontant: indhold, der først opstår i browseren, findes ikke for en stor del af AI-søgeøkonomien. En side kan se perfekt ud for mennesker og for Google og samtidig være et tomt skelet for GPTBot og PerplexityBot.

Problemet er ikke nyt — SEO-verdenen har kendt JavaScript-faldgruberne i årevis — men AI-crawlerne har gjort det akut igen. Googlebot har siden 2019 renderet sider med en løbende opdateret Chromium og fanger derfor det meste; AI-crawlerne prioriterer hastighed og volumen og nøjes typisk med den rå HTML, serveren sender. Denne artikel viser testen, der afslører problemet på 30 sekunder, og løsningerne i prioriteret rækkefølge.

Test det på 30 sekunder

Hent din vigtigste side fra kommandolinjen, og søg efter en sætning fra kerneindholdet:

curl -s https://ditdomæne.dk/vigtig-side/ | grep "en sætning fra kerneteksten"

Står sætningen der ikke, er den usynlig for ikke-renderende crawlere — uanset hvor fint den vises i browseren. Test også undersider, ikke kun forsiden: mange opsætninger server-renderer forsiden, mens artikellister, filtre og produktdata hentes klientside. Husk desuden fænomenet content shifting, hvor serveren sender skeletindhold (“Indlæser…”), som JavaScript derefter erstatter — det består et overfladisk kig, men fejler grep-testen.

Hvorfor renderer AI-crawlere ikke bare JavaScript?

Fordi rendering er dyrt. At udføre JavaScript kræver en fuld browserinstans pr. side — hukommelse, CPU og ventetid på scripts og API-kald. Googlebot amortiserer den omkostning over verdens største søgeforretning; en AI-crawler, der skal hente fem kilder til ét svar på to sekunder, har hverken tid eller budget til det. Den henter HTML’en, og hvad der ikke står i den, findes ikke.

Det forklarer også, hvorfor problemet rammer skævt. Klassiske server-renderede sites — herunder de fleste WordPress-opsætninger — er upåvirkede, mens moderne JavaScript-frameworks i ren klientside-konfiguration (SPA’er) rammes hårdt. Ironisk nok er de teknisk mest ambitiøse sites ofte de mest usynlige i AI-søgning.

En side kan se perfekt ud for mennesker og Google — og være et tomt skelet for AI-crawlerne.

Løsningerne, rangeret efter robusthed

1. Server-side rendering eller statisk genereringIndholdet fødes i HTML på serveren, før noget script kører. Det er den rigtige løsning for indholdssites, og moderne frameworks som Next.js og Nuxt understøtter det som førstevalg. Fuld tjekliste i SSR-tjeklisten.
2. Hybrid renderingKerneindholdet leveres i HTML, og interaktivitet hydreres ovenpå i browseren. De fleste moderne frameworks kan konfigureres sådan — kravet er, at tekst, overskrifter og links ikke afhænger af hydreringen.
3. Prerendering-proxy for legacy-SPA’erEn tjeneste renderer siderne og serverer den færdige HTML til bots, mens mennesker får SPA’en. Det fungerer, men er endnu et system, der kan fejle uden at nogen opdager det — mellemløsningen, ikke målet.

Hvad betyder det for WordPress-sites?

Klassiske WordPress-temaer leverer HTML server-side og er dermed AI-crawler-venlige fra fødslen — en af platformens undervurderede styrker i AI-æraen. Men garantien kan brydes: page builders, der bygger indhold klientside, “headless” opsætninger med JavaScript-frontend, og widgets, der henter kerneindhold via AJAX, genindfører alle problemet. Reglen er enkel: verificér med curl-testen efter enhver større ændring af frontend-arkitekturen, og lad aldrig kerneindhold afhænge af klientside-kode.

JavaScript-afgrænsningen er én af de fire tekniske barrierer i crawler-guiden — og den, der oftest overrasker, fordi intet ser galt ud i browseren. Sammen med hastighed (se Core Web Vitals i agent-æraen) udgør den fundamentet for al synlighed i agentic SEO.

Hvilke sider skal du teste først?

Test i værdirækkefølge, ikke alfabetisk. Start med de sider, der skal vinde dine vigtigste kundespørgsmål — typisk prissider, ydelsessider og de dybeste guides — for det er dem, et renderingsproblem koster mest på. Fortsæt med skabelonerne: én test pr. sidetype (artikel, kategoriside, produktside) afslører systemiske problemer, fordi alle sider af samme type deler skæbne. Slut med de dynamiske elementer: filtre, “load more”-lister, anmeldelsesvisninger og andre komponenter, der erfaringsmæssigt er JavaScript-afhængige.

Symptomjagt i data kan supplere: sider, der rangerer fint klassisk, men aldrig optræder i AI-svar, og sites helt uden referral-trafik fra AI-platforme, er kandidater til netop dette problem. Og find du én ramt skabelon, så antag, at alle dens sider er ramt — regn i sidetyper, ikke i enkeltsider, når du planlægger udbedringen.

Ofte stillede spørgsmål

Renderer ChatGPT og Perplexity slet ikke JavaScript?

Regn ikke med det. Adfærden varierer og dokumenteres sparsomt, men mønsteret på tværs af test er, at AI-crawlere primært arbejder med den rå HTML. Strategien er derfor defensiv: alt, du vil citeres for, skal stå i første svar fra serveren.

Er lazy-loading af billeder et problem?

Kun hvis det er JavaScript-afhængigt uden fallback. Native lazy-loading med rigtige src-attributter i HTML er uproblematisk. JS-baseret lazy-loading, hvor billedernes URL’er først indsættes klientside, gør billederne usynlige for ikke-renderende crawlere.

Hvad med indhold bag “vis mere”-knapper?

Hvis den fulde tekst står i HTML’en og blot foldes ud visuelt (fx et details-element), er den synlig for crawlere. Hvis knappen henter indholdet via et API-kald, er det usynligt. Samme regel som altid: curl-testen afgør det.

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