Hvorfor innlasting av innhold er kritisk for AI-søk

Et selskap kan rangere som nummer én på Google for et konkurransedyktig søkeord, og samtidig være totalt fraværende når noen stiller det nøyaktig samme spørsmålet til ChatGPT. Ikke fordi innholdet er dårlig, og ikke fordi noe er galt med rangeringen. AI-en har rett og slett aldri sett innholdet.

Google og AI-søk leser nettet på to fundamentalt ulike måter

Googlebot bruker en headless Chrome-basert renderer som laster siden omtrent slik en vanlig nettleser ville gjort, kjører JavaScript-en, og indekserer det ferdig rendrede resultatet. Det er derfor en moderne React-, Vue- eller Angular-side stort sett rangerer greit på Google selv om innholdet bygges opp av JavaScript i nettleseren.

De store AI-crawlerne følger ikke samme mønster. Vercel og MERJ analyserte over 500 millioner forespørsler fra OpenAIs GPTBot og fant null tilfeller av JavaScript-kjøring. Samme mønster gjaldt for ClaudeBot, PerplexityBot og de andre store AI-crawlerne som ble undersøkt. GPTBot laster faktisk ned JavaScript-filer i rundt 11,5 prosent av forespørslene, og ClaudeBot i overkant av 23 prosent, men ingen av dem kjører koden. De henter den rå HTML-en, trekker ut det som faktisk står der, og går videre.

Det ene kjente unntaket er Googles Gemini, som arver Googlebot sin renderingsinfrastruktur og dermed kan kjøre JavaScript på samme måte. GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot, ChatGPT-User og de øvrige store AI-crawlerne kan det ikke.

Hvorfor gjør AI-crawlerne dette?

Det kan virke som et bevisst, unødvendig kompromiss fra AI-selskapenes side, men det handler i bunn og grunn om skala og hastighet.

Googlebot bruker en to-fase-modell: den henter først den rå HTML-en umiddelbart, og setter deretter siden i kø for en full rendering med en egen, ressurskrevende Chrome-instans i en separat fase som kan ta alt fra timer til uker å fullføre. Google har bygget og finansiert denne renderingsinfrastrukturen over mer enn et tiår, og bygger i praksis bare opp ett samlet, langsiktig indeks over nettet.

AI-crawlere som GPTBot, ClaudeBot og PerplexityBot jobber under helt andre forutsetninger. De opererer ofte med svært stramme tidsbudsjetter per side, gjerne bare ett til fem sekunder, og skal hente enorme mengder innhold fortløpende, ikke bygge én ferdig indeks én gang for alle. Å kjøre full JavaScript-rendering for hver eneste side ville redusert farten deres med en faktor på 10 til 100, noe som verken er praktisk eller økonomisk mulig i den skalaen disse selskapene opererer på. Løsningen deres er derfor enkel: hent den rå HTML-en, trekk ut teksten som faktisk finnes der, og gå videre til neste side.

Dette er spesielt kritisk i praksis når en bruker snakker direkte med en AI-chatbot og forventer svar med det samme. En chatbot som skal hente og sammenligne informasjon fra flere kilder for å svare på ett enkelt spørsmål, har rett og slett ikke tid til å vente på at hver eneste side skal rendres fullstendig først.

Konsekvensen: en side kan være en Google-suksess og en AI-spøkelse samtidig

Se for deg en nettside bygget som en ren klientrendret enkeltside-applikasjon, der selve produktbeskrivelsen, prisen og FAQ-svarene først bygges opp i nettleseren etter at JavaScript-en er lastet og kjørt. Google ser det ferdige resultatet, siden Googlebot venter på at JavaScript-en kjører før siden indekseres, og siden kan rangere helt fint i vanlig søk.

En AI-crawler som besøker akkurat samme URL, ser noe helt annet: en tom side med en skript-tag som peker mot appen, uten selve teksten. For AI-en finnes ikke innholdet, uansett hvor godt det er skrevet, uansett hvor riktig strukturert data den ellers har, og uansett hvor godt den ville rangert hvis noen faktisk kunne lese den.

Løsningen: sørg for at innholdet faktisk finnes i den første HTML-en

Løsningen krever ikke at man forlater moderne rammeverk, bare at siden er satt opp slik at innholdet ligger klart i HTML-en serveren sender ut, før noe JavaScript kjører i det hele tatt. Med "innholdet" menes helt konkret den faktiske teksten AI-crawleren skal hente: selve produktbeskrivelsen, kategoriteksten, artikkeltittelen og brødteksten, ikke bare tekniske metadata rundt den. Interaktive elementer kan fortsatt bygges videre ut i nettleseren etterpå for menneskelige besøkende, uten at det påvirker hva en AI-crawler ser i det første kallet.

Det samme gjelder strukturert data som JSON-LD: hvis den settes inn via JavaScript etter at siden er lastet, er den like usynlig for en AI-crawler som resten av det JavaScript-genererte innholdet, uansett hvor korrekt den ellers er utformet.

En enkel test du kan gjøre selv

Man trenger ingen teknisk bakgrunn for å sjekke dette selv. Skriv inn nettsiden din i nettleseren, men legg til view-source: foran hele adressen, slik at det ser slik ut:

view-source:https://www.nettsidendin.no

Siden som dukker opp er akkurat det en AI-crawler faktisk ser når den besøker siden din, ingenting mer og ingenting mindre. Hvis du kan finne igjen produkttekstene, kategoritekstene og bloggtekstene dine i denne visningen, vet du at en AI-crawler også kan se dem. Hvis du derimot ser en tom side eller en side med bare kode, JavaScript og lignende, og ingen av tekstene du kjenner igjen fra den vanlige siden, er det et tegn på at innholdet lastes inn av JavaScript etter at siden er levert, og at det dermed er usynlig for de fleste AI-crawlere.

Hvordan løser jeg dette?

Dette er i stor grad et arkitekturvalg som ligger i selve plattformen nettsiden er bygget på, ikke noe man justerer med en enkel innstilling. Hvor mye innflytelse man har, avhenger derfor av hvilken plattform man allerede bruker.

Plattformer som Shopify og WooCommerce har dette bygget inn som en del av selve plattformen. Sidene på disse plattformene leveres allerede med innholdet klart i HTML-en, slik at man normalt ikke trenger å gjøre noe ekstra for at en AI-crawler skal kunne lese produkt- og kategorisidene.

Bygger nettsiden på Vercel, som blant annet driver mange Next.js-nettsider, er situasjonen litt annerledes. Selve plattformen støtter riktig oppsett godt, men det er ikke nødvendigvis satt opp riktig automatisk. Der er det opp til hvordan hver enkelt side i prosjektet faktisk er bygget: sider som er satt opp med server-rendering leverer innholdet klart i HTML-en fra start, mens sider som i stedet er satt opp til å bygge innholdet i nettleseren fortsatt vil ha samme usynlighetsproblem. Dette er i praksis samme sjekk som beskrevet over, bare at løsningen her ofte handler om å endre hvordan den enkelte siden er bygget, ikke om å bytte plattform.

Er nettsiden bygget på en annen plattform, spesielt en som bygger opp mye av innholdet med JavaScript i nettleseren, finnes det likevel løsninger. Ett eksempel er å sette opp en tjeneste som fanger opp AI-crawlere spesifikt (ofte via en Cloudflare Worker) og sender dem en ferdig rendret HTML-versjon av siden, mens vanlige besøkende fortsatt får den vanlige, interaktive opplevelsen. Det finnes flere slike tjenester å velge mellom. Alternativet, hvis plattformen ikke lar seg tilpasse på denne måten, er å bytte til en plattform som allerede leverer innhold riktig for AI-crawlere fra start.

Konklusjon

Google sin evne til å rendre JavaScript har gjort det fristende å anta at samme fleksibilitet gjelder overalt. Det gjør den ikke. AI-crawlerne som bygger svarene i ChatGPT, Claude og Perplexity leser nettet omtrent slik det så ut for tjue år siden: rå HTML, ingenting mer. Innhold som først dukker opp etter at JavaScript har kjørt, finnes rett og slett ikke for dem, uavhengig av hvor godt det er skrevet eller hvor riktig det ellers er merket opp.