Rendrer AI JavaScript?

#Rendrer AI JavaScript

For søkemotoringeniører er ikke dette en ny tanke, men hittil var det argument og ikke bevis. Nå er det testet direkte, og beviset er ubehagelig for den store klassen av nettsteder bygget som JavaScript-applikasjoner som setter sammen innholdet i nettleseren.

#Slik ble testen av JavaScript-rendring i AI gjort

Testen, kjørt av Andre Alpar og publisert i juni 2026 på Search Engine World, var enkel og vanskelig å lure. Siden serverte et lokke-referansenummer i rå HTML. Det ekte nummeret ble først satt inn av ekstern JavaScript, hentet fra et annet endepunkt, og det sto ingen steder i HTML-en eller i kildekoden til skriptet. Hver av de tolv assistentene fikk sin egen, ulenkede og ugjettbare URL, slik at hvert treff på serveren kunne knyttes til én assistent, og serveren logget tre separate hendelser: sidehentingen, hentingen av JavaScript-filen og kallet til nummer-endepunktet. Logikken er vanntett. Returner det ekte nummeret, og du kjørte skriptet. Returner lokken, og du leste bare HTML.

Hentingen ble utløst av brukeren. Alpar limte hver URL inn i chatten for hånd og ba assistenten oppsummere siden og oppgi det interne referansenummeret. Testen måler altså hva som skjer når et menneske gir en assistent en lenke, ikke hva en crawler i bakgrunnen gjør etter sin egen timeplan. Alpar sier selv hvor grensene går: det er “en test med ett gjennomløp og live-henting: én prompt per assistent, fanget på ett tidspunkt”, og bakgrunnscrawlere som GPTBot og ClaudeBot “kan godt oppføre seg annerledes” (egen oversettelse). Les resultatet som et skarpt øyeblikksbilde av live-svarveien i juni 2026, ikke som en varig egenskap ved hvert produkt.

#Hvilke AI-assistenter leser bare rå HTML

I Alpars test returnerte disse assistentene lokken, altså grunnet de seg på rå HTML og kjørte aldri skriptet:

• ChatGPT
• Claude
• Gemini
• Perplexity
• Meta AI
• Microsoft Copilot

Grok kjørte JavaScripten på én node, men returnerte likevel lokken, så selv der skriptet kjørte, kom ikke den rendrede verdien med i svaret.

Tre detaljer fra serverloggene skjerper bildet. Blant de amerikanske systemene som ikke rendret, var Microsoft Copilot det eneste som lastet ned JavaScript-filen, via den eksterne skraperen Diffbot, men det gjorde aldri det påfølgende kallet etter nummeret og rapporterte lokken. Gemini, som Alpar kaller overraskelsen fordi den kommer fra Google, rendret heller ikke. Perplexity svarte at den ikke fikk tilgang til siden, selv om crawleren dens hadde hentet den med HTTP 200. Derfor er Alpars råd å stole på serverloggen, aldri på chatbotens egen fremstilling av hva den gjorde.

Glenn Gabe i GSQi stilte spørsmålet på nytt på fem plattformer og publiserte resultatet 19. oktober 2026. ChatGPT, Claude og Perplexity strøk på alle tre testene. Gemini og Copilot besto de to første: en side der hele innholdet lastes med JavaScript, og en side med statisk topp- og bunntekst, men innhold fra JavaScript. I den tredje testen, en parallakseside bygd på WebGL, leste Gemini innholdet, mens Copilot ikke gjorde det. Gabe forklarer det rett ut: “Gemini bruker Googles søkesystemer, så den kan se innhold som er rendret med JavaScript” (egen oversettelse). Copilots suksess tilskriver han på samme måte søkesystemene til Bing.

Begge resultatene kan være sanne samtidig. Alpar ga hver assistent en fersk URL som ikke var lenket fra noe sted og ikke lå i noen søkemotors indeks, så Gemini og Copilot måtte hente rå HTML som alle de andre. Gabe testet eksisterende nettsteder som Google og Bing allerede kjente, så Gemini og Copilot kunne bruke versjonen søkemotoren hadde rendret. For en ny side gjelder resultatet fra juni helt til en søkemotor har rendret den. ChatGPT, Claude og Perplexity leste bare HTML i begge testene.

#Hvilke AI-assistenter kjører JavaScript

Fem assistenter returnerte det ekte nummeret og beviste dermed at de kjørte skriptet:

• DeepSeek, ERNIE, Qwen og Kimi, alle fra Kina
• Mistral, fra Europa

DeepSeek i denne listen er chatten. Suganthan Mohanadasan testet en annen vei fra samme selskap, Fetch API-et til DeepSeeks søk, og beskrev testen 19. oktober 2026. I rendringstesten lastet henteren CSS, men kjørte ikke JavaScript, lastet ikke bilder og utløste ikke XHR-beaconen, så innhold som krevde skriptet, kom ikke med i resultatet. Den presenterte seg som Firefox/149.0 fra AS136907 (Huawei Cloud, Hongkong), uten noe som nevnte DeepSeek, og hentet URL-er som var blokkert i robots.txt. Hele testen, 110 kall, kostet rundt 0,08 USD. DeepSeek-chatten og API-et for å hente sider er rett og slett to ulike veier til HTML-en din, og i disse testene kjørte bare chatten skriptet.

JavaScript-rendring fra AI skjer altså virkelig. Det er bare det at for de store vestlige assistentene europeiske bedrifter faktisk bryr seg om, er det unntaket ved live-henting, og Gemini og Copilot ser innhold fra JavaScript bare gjennom indeksen til søkemotoren sin. Skillet er tydelig nok til å planlegge rundt: bygg for assistentene kundene dine bruker, og de leser HTML i dag.

#Hva Vercels studie fant om AI-crawlere og JavaScript

Testen fra juni 2026 er ikke den første målingen som peker denne veien. I desember 2024 publiserte Vercel, sammen med MERJ, en analyse av trafikk fra AI-crawlere i sitt eget nettverk og konkluderte med at “ingen av de store AI-crawlerne rendrer JavaScript i dag” (egen oversettelse). ChatGPT og Claude hentet riktignok JavaScript-filer, henholdsvis 11,50 % og 23,84 % av forespørslene sine, men kjørte dem ikke. I måneden som ble målt, sto GPTBot for 569 millioner hentinger, Claude for 370 millioner og PerplexityBot for 24,4 millioner, mot 4,5 milliarder for Googlebot på tvers av Gemini og søk. ChatGPT brukte 34,82 % av hentingene sine på 404-sider, Claude 34,16 %.

Vercel nevnte to crawlere som rendrer: AppleBot, via en nettleserbasert crawler som ligner Googlebot, og Gemini, fordi den bruker infrastrukturen til Googlebot. Det siste punktet strider mot Alpars resultat fra 2026, der Gemini returnerte lokken. De to målingene ser på ulike veier, bakgrunnscrawling i Vercels nettverk og en live-henting utløst av en brukers prompt, og nettopp det gapet er lærdommen: at Google rendrer siden din for indeksen, sier lite om hva Gemini leser mens den svarer på et spørsmål. Vercels anbefaling stemmer med resten av denne artikkelen: render hovedinnhold, metainformasjon og navigasjon på serveren, og behold klientsiderendring for funksjoner som bare beriker siden.

#Rendrer Google JavaScript annerledes enn AI-assistenter

Dette er innvendingen som sporer av hele samtalen, så møt den direkte. Ja, Googlebot rendrer JavaScript for den klassiske søkeindeksen. Det er en separat pipeline fra grounding for AI-svar, og testen handler om den andre. En side kan rangere helt fint i klassisk Google-søk på innhold som først eksisterer etter at JavaScript kjører, og likevel være usynlig når ChatGPT eller Perplexity henter den for å sette sammen et svar. Å behandle “Google rendrer JS” som bevis på at “AI rendrer JS” er feilen. De to systemene oppfører seg ulikt, og det er nettopp i det gapet AI-synligheten lekker ut i stillhet.

#Hva Googles dokumentasjon om JavaScript-SEO sier om rendring

Google beskriver sin egen prosess i grunnleggende JavaScript-SEO: JavaScript-nettapper går gjennom tre faser, crawling, rendring og indeksering. Sider venter i en rendringskø før en hodeløs Chromium kjører JavaScripten deres, og ifølge Google kan en side “bli liggende i denne køen i noen sekunder, men det kan ta lengre tid enn det” (egen oversettelse). Den samme siden anbefaler fortsatt server-rendring eller forhåndsrendring, fordi det er raskere for brukere og crawlere, og fordi “ikke alle roboter kan kjøre JavaScript” (egen oversettelse).

Den setningen er broen til AI-assistentene. Google skriver at du kan generere JSON-LD med JavaScript og sette det inn i siden, og Googlebot leser det etter rendringstrinnet. Alpar testet et nummer i synlig tekst, ikke strukturerte data, men schema som et skript setter inn, når en assistent gjennom den samme mekanismen. En assistent som aldri kjører skriptet, ser det derfor aldri. Googles dokumentasjon er skrevet for Googlebot. AI-svarlaget er tilfellet “ikke alle roboter”.

Googles egen side om dynamisk rendring, sist oppdatert 10. desember 2025, stenger snarveien der serveren gjenkjenner roboter og gir dem en server-rendret kopi, mens brukerne får versjonen som rendres i nettleseren. Google kaller dette en midlertidig løsning og anbefaler den ikke, fordi den gir mer kompleksitet og krever ekstra ressurser, og viser i stedet til server-rendring, statisk rendring eller hydrering. Forhåndsrendring ved bygging, forklart lenger ned, hører til statisk rendring, så alle klienter, roboter som nettlesere, får den samme HTML-en.

#JavaScript-mønstre som skjuler innhold for AI

Risikoen samler seg i et gjenkjennelig sett av mønstre:

• Single-page-applikasjoner som sender et nesten tomt HTML-skall og setter sammen siden i nettleseren.
• Priser, lagerstatus eller spesifikasjoner som settes inn av JavaScript fra et API etter innlasting.
• Innhold gjemt bak klientsidens faner, trekkspill eller “last mer” som først hentes ved interaksjon.
• Produkt- eller tjenestebeskrivelser rendret av et klientrammeverk uten server-side reserveløsning.
• Anmeldelser, vurderinger og FAQ-widgeter innebygd som tredjeparts JavaScript.

Hvis noen av disse bærer faktaene du vil at en AI skal gjenta, satser du AI-synligheten din på en rendringsatferd som seks av sju vestlige assistenter nettopp feilet på.

#Slik gjør du JavaScript-innhold synlig for AI

Botemiddelet er regelen klassisk SEO har gjentatt i et tiår: legg de bærende faktaene i server-rendret HTML. Statisk sidegenerering og server-rendring oppfyller den begge. Rammeverket spiller ingen rolle, det som teller er hvor HTML-en settes sammen. Rendre innholdet på serveren, send det i det første svaret, og la JavaScript berike det i stedet for å levere det.

Ditt eget nettsted sjekker du på et minutt. Hent en side uten nettleser og les hva som kommer tilbake:

curl -s https://ditt-nettsted.example/din-side/ | less

Hvis overskrifter, brødtekst, priser, spesifikasjoner og Schema.org JSON-LD alle er i det rå svaret, kan AI-assistenter lese dem. Hvis siden er et tynt skall som fylles inn etter at skriptet kjører, er det ditt problem, og nå ser du det.

#Hvilke user agents AI-assistenter bruker når de henter sider

Leverandørene dokumenterer egne agenter for trening, søkeindeksering og hentinger som brukeren utløser, og robots.txt-reglene er forskjellige:

• OpenAI: GPTBot crawler innhold som kan brukes til å trene grunnmodeller, OAI-SearchBot avgjør om et nettsted kan vises i søkesvar i ChatGPT, og ChatGPT-User henter sider for brukerhandlinger. ChatGPT-User brukes ikke til automatisk crawling, og fordi handlingene settes i gang av brukeren, gjelder robots.txt-reglene kanskje ikke. Hver innstilling er uavhengig, og ifølge OpenAI kan det ta rundt 24 timer før en endring i robots.txt slår gjennom i søkeresultatene.
• Anthropic: ClaudeBot samler inn treningsdata, Claude-SearchBot indekserer for søkekvalitet, og Claude-User henter sider når et menneske stiller Claude et spørsmål. Anthropic oppgir at botene respekterer robots.txt, og publiserer IP-listen til crawlerne sine.
• Perplexity: PerplexityBot viser nettsteder i Perplexity-søk og brukes ikke til modelltrening. Perplexity-User støtter brukerhandlinger og ignorerer som regel robots.txt, fordi en bruker ba om hentingen.
• Google: Google-Extended er et produkt-token for robots.txt, ikke en egen crawler. Det styrer bruk til trening av Gemini og til grounding, har ingen egen HTTP-user agent og påvirker verken om nettstedet tas med eller hvordan det rangerer i Google-søk.

Ingen av disse sidene lover JavaScript-rendring. I et annet eksperiment, om robots.txt, fant Alpar at bare 3 av 12 assistenter lot en blokkert URL være i fred: ChatGPT som ChatGPT-User, Claude som Claude-User og Perplexity som Perplexity-User. Gemini kom med en naken user agent, “Google”, Copilot via Diffbot med en vanlig Chrome-streng, og Grok, DeepSeek, Qwen og Kimi med forfalskede nettleser-user agents. Den praktiske følgen for rendring: du kan ikke pålitelig gi AI-assistenter en egen forhåndsrendret versjon ved å gjenkjenne user agent, så HTML-en alle får, må bære fakta.

#Slik serverer WordPress innhold til AI uten JavaScript

Et klassisk WordPress-tema er på den trygge siden fra start: PHP bygger siden på serveren, så innlegg, produktbeskrivelser og priser fra databasen ligger i HTML-en før noe skript kjører. Risikoen oppstår når innhold flyttes til widgets på klientsiden, til blokker som henter data over REST API etter innlasting, eller til en headless frontend som bare rendrer i nettleseren.

For interaktivitet har WordPress en løsning som holder innholdet på serveren. Interactivity API, innført i WordPress 6.5, bruker direktiver i markeringen til en blokk, og servermessig behandling av direktivene lar WordPress generere den første HTML-en med riktig tilstand. Funksjonen wp_interactivity_process_directives finner direktivene og bruker HTML API til å skrive om markeringen ut fra starttilstand og kontekst. I eksempelet i dokumentasjonen forlater en liste bygd med data-wp-each og data-wp-text serveren som vanlige listeelementer, med fruktnavnene allerede fylt inn og ingen direktiver igjen. Siden kommer komplett, JavaScript legger til oppførsel etterpå, og en assistent som leser rå HTML, ser den samme listen som en besøkende. Dokumentasjonen gir selv begrunnelsen: tilnærmingen beholder “SEO- og ytelsesfordelene ved tradisjonell server-rendring i WordPress” (egen oversettelse).

#Statisk HTML med Astro og AI-synlighet

Vi er ikke nøytrale her, for vi tok dette veddemålet med vilje. wppoland.com kjører på Astro, som rendrer sider til statisk HTML ved byggetid og serverer dem fra kanten av nettet. Alt som betyr noe er i det rå svaret: brødteksten, hver overskrift, FAQ-en og Schema.org JSON-LD. Vi sjekket det på samme måte som testen, ved å lese rå HTML i stedet for den rendrede siden, og innholdet er alt sammen på plass før en eneste linje av vår JavaScript kjører. JavaScript på sidene våre er berikelse, aldri kilden til innholdet.

Det er samme konklusjon vi nådde den lange veien i å servere innhold til AI-agenter: rent, server-rendret, semantisk HTML pluss Schema er det ene signalet både klassiske crawlere og AI-systemer faktisk konsumerer. Denne testen er det reneste beviset så langt for det standpunktet. Det er også grunnen til at et GEO- og LLMO-program må starte med hvordan siden rendres, og ikke med smarte metadata, for metadata en assistent aldri kjører, leser den aldri.

#Server-rendring og klientsiderendring forklart

For lesere som driver en bedrift og ikke en byggepipeline:

• Server-rendring / statisk generering - sidens HTML settes sammen på serveren (eller ved byggetid) og kommer komplett i det første svaret.
• Klientsiderendring - serveren sender et nesten tomt skall, og nettleserens JavaScript bygger siden etterpå.
• Grounding - når en AI-assistent henter ekte sider for å grunne et svar på fakta i stedet for hukommelse.
• Hydrering - JavaScript som fester interaktivitet til allerede rendret HTML; trygt, fordi innholdet var der først.
• Forhåndsrendring - å kjøre en klientsideapp under bygging for å fange starttilstanden som statisk HTML, slik web.dev-guiden Rendering on the Web definerer det. Den samme guiden påpeker at crawlere kan forstå JavaScript, “men det er ofte begrensninger i hvordan de rendrer” (egen oversettelse).

#Bør du vente på at AI rendrer JavaScript

JavaScript-rendring fra AI-assistenter blir trolig bedre over tid, og de kinesiske assistentene pluss Mistral viser at det teknisk sett er rutine. Men du får ikke publisere for assistentene du skulle ønske fantes. Du publiserer for dem kundene dine bruker, og i juni 2026 leser de største vestlige assistentene rå HTML og stopper der. Det trygge, kjedelige, ti år gamle svaret viser seg å være det riktige også for AI: server faktaene dine i HTML serveren allerede har rendret, og behandle alt som først dukker opp etter JavaScript som innhold AI ikke vil se.