Flere og flere kunder spørger en AI-assistent i stedet for at scrolle en resultatside. Assistenten svarer, nævner et par kilder, og de kilder får besøget. Om dit website er en af dem, afgøres af ting du selv bestemmer.

Skiftet er ikke teoretisk. Når nogen spørger en assistent "hvem laver website-overvågning i Danmark" eller "hvad koster et TLS-certifikat", remser assistenten ikke en liste op, den kan udenad. Den søger, henter en håndfuld sider live, læser dem og skriver et svar der nævner sine kilder. De nævnte kilder får klikket, troværdigheden og — ofte — henvendelsen.

Dermed er synlighed i AI-svar en distributionskanal og ikke en kuriositet. Den er samtidig usædvanligt nem at vinde, fordi de færreste nogensinde har tjekket de fire indstillinger der afgør den. Denne vejledning gennemgår hvilke indstillinger det er, hvordan du finder ud af hvor du står, og hvorfor den mest almindelige fejl er en du aldrig opdager fra din egen browser.

Hvad er GEO (generative engine optimization)?

GEO er arbejdet med at gøre et website brugbart som kilde for AI-svarmaskiner som ChatGPT, Perplexity, Google AI Overviews og Gemini. Det overlapper i høj grad med almindelig SEO — siden skal stadig kunne hentes, læses og være relevant — men der kommer et selvstændigt krav til: svaret på et spørgsmål skal kunne løftes ud i ét selvstændigt stykke tekst, for det er den enhed en assistent citerer.

Netop dét er den praktiske forskel. Et almindeligt søgeresultat belønner en side der dækker et emne godt som helhed; den besøgende lander og læser selv. En assistent læser derimod selv og citerer bagefter. Er din forklaring spredt over fire afsnit, en indledning og en tabel, er der intet rent at løfte ud. Står den i tre sætninger direkte under en overskrift der matcher spørgsmålet, er der.

Skriverådene bliver derfor prosaiske og meget konkrete: skriv svaret først, hold det kort nok til at kunne citeres, og sørg for at det kan stå alene uden sætningerne omkring. Resten af siden må fylde lige så meget, som den skal.

Bruger AI-assistenter de samme crawlere som Google?

Nej. Assistenterne sender deres egne user agents, og hver udbyder kører flere. OpenAI alene bruger GPTBot til træningsdata, OAI-SearchBot til sit søgeindeks og ChatGPT-User når en person stiller et spørgsmål der kræver et live-opslag. At Googlebot har adgang siger intet om de andre, for reglerne i robots.txt matches pr. user agent.

Det er her mange taber uden nogensinde at have besluttet det. En robots.txt skrevet for år tilbage, et sikkerhedsplugin med en "bloker aggressive bots"-indstilling, en CDN-regel tilføjet under et scraping-angreb — hver af dem kan lukke en assistent ude uden at røre Google. Intet går i stykker, intet logges et sted marketing kigger, og sitet holder simpelthen op med at være citerbart.

Listen over crawler-tokens er desuden ustabil. Udbyderne tilføjer, omdøber og udfaser dem uden varsel og uden noget centralt register, så et tjek der var korrekt for et år siden, er det ikke i dag. Derfor behandler TrustCtrl en crawler den ikke kender som ukendt frem for tilladt: at påstå en dækning tjekket ikke har, ville være værre end at indrømme hullet.

Forhindrer det mig i at optræde i AI-svar, hvis jeg blokerer træning?

Ikke nødvendigvis, og den skelnen er det mest brugbare at forstå ved GEO. Trænings-crawlere som GPTBot, ClaudeBot og CCBot indsamler tekst der kan indgå i træningsdata. Retrieval-crawlere som OAI-SearchBot, PerplexityBot og Claude-User henter en side for at besvare et spørgsmål der bliver stillet lige nu, og det er dem der giver en henvisning. At blokere træning og tillade retrieval er et bevidst og fuldt gyldigt valg: indholdet forbliver citerbart uden at fodre nogen model.

Mange virksomheder vil præcis dét. De vil gerne være en citeret kilde — det giver trafik og autoritet — og er mindre begejstrede for at deres tekster bliver træningsdata til en model, der næste gang svarer uden om dem. Det er en sammenhængende holdning, og den kan udtrykkes i robots.txt.

Problemet er, at de to kategorier er nemme at blande sammen. Én Disallow rettet mod "AI-bots" rammer normalt begge, og dermed bliver "lad være med at træne på os" stille lavet om til "lad være med at citere os". TrustCtrl rapporterer derfor de to grupper hver for sig, så siden fortæller hvilket valg du reelt har truffet, i stedet for at slå dem sammen til ét tal.

  • Trænings-crawlere: GPTBot (OpenAI), ClaudeBot (Anthropic), CCBot (Common Crawl), Bytespider (ByteDance), Meta-ExternalAgent (Meta).
  • Retrieval-crawlere: OAI-SearchBot og ChatGPT-User (OpenAI), PerplexityBot (Perplexity), Claude-User (Anthropic), Applebot (Apple).
  • Kun signaler i robots.txt: Google-Extended og Applebot-Extended er fravalg af træning til henholdsvis Gemini og Apple Intelligence. Ingen crawler sender dem nogensinde som user agent — de findes udelukkende som et signal i robots.txt, der respekteres af crawlere som kalder sig noget andet.

Den sidste kategori snyder. Fordi der aldrig kommer noget forbi, som kalder sig Google-Extended, beviser det ingenting at kigge i sine logfiler. Den skal læses ud af robots.txt.

Hvordan bliver mit website citeret af ChatGPT?

Der findes hverken en tilmeldingsformular eller en garanti. I praksis afgør tre ting det: retrieval-crawlerne skal have lov til at hente dine sider, svaret skal stå i den HTML crawleren modtager og ikke først samles af JavaScript bagefter, og siden skal besvare et rigtigt spørgsmål i et kort, selvstændigt stykke tekst. Fejler bare én af dem, er indholdet usynligt uanset hvor godt det er; opfylder du alle tre, er du med i opløbet.

Den midterste betingelse er den, moderne websites falder over. Mange assistenter læser HTML'en, som den kommer fra serveren. Hvis dine produkttekster, dine priser eller dine FAQ-svar først indsættes af et framework efter siden er loadet, kan crawleren modtage en næsten tom skal — en menu, en footer og en indlæsningstilstand. Siden ser perfekt ud i din browser, fordi din browser kørte JavaScriptet. Det gjorde crawleren ikke.

Den fejl kan ikke ses indefra, og derfor overlever den i årevis. TrustCtrl sammenligner det serveren returnerer med det siden ser ud som efter rendering, og markerer de sider hvor hovedindholdet kun findes i den anden version. Mekanikken gennemgår vi i indholdet Google ikke kan se.

Den fjerde indstilling: sider der svarer crawlere noget andet

Der er én fejltype mere, og det er den der oftest gør skade uden at nogen ved det. Nogle websites returnerer forskelligt indhold alt efter hvem der spørger — et bot-beskyttelseslag der viser en kontrolside, en betalingsmur der åbner for Googlebot men ikke for andre, en CDN-regel der behandler ukendte user agents som mistænkelige.

Søgemaskiner kalder det cloaking, og når det er bevidst, er det en risiko for placeringen. Når det er utilsigtet — hvilket er langt det mest almindelige — er effekten enklere: assistenten modtager en sikkerhedskontrolside i stedet for din artikel og citerer en anden. TrustCtrl henter dine sider som hver enkelt AI-crawler efter tur og rapporterer, når svaret adskiller sig væsentligt fra det en almindelig besøgende får. Det er den eneste måde at fange en regel, du ikke vidste var der.

Hvad med llms.txt?

Du vil se llms.txt stå på enhver GEO-tjekliste. Det er en foreslået fil i roden af dit website, som på én side i markdown fortæller en assistent hvad sitet er, og hvilke URL'er der er værd at læse. Idéen er fornuftig, og det koster næsten ingenting at udgive den.

Den er samtidig umoden i dag: ingen søgemaskine eller assistent er kendt for at kræve den, og udbredelsen er tynd. Betragt den som billig forsikring frem for en løsning. Hvad der skal stå i den — og den langt mere alvorlige ting en manglende fil kan afsløre om din server — gennemgår vi i llms.txt-vejledningen.

Hvordan tjekker jeg om AI-assistenter kan læse mit website?

Hent din egen robots.txt og læs den pr. user agent i stedet for at gå ud fra at én regel gælder alle, og bekræft derefter at svarteksten står i den rå HTML og ikke kun i den færdigrenderede side. TrustCtrl gør begge dele ved hver crawl: hver AI-crawler rapporteres for sig som tilladt, blokeret eller ukendt, opdelt efter træning og retrieval, og sider hvis indhold først dukker op når JavaScript har kørt, bliver markeret.

At gøre det i hånden én gang er tiden værd og tager en eftermiddag. Grunden til at automatisere det er, at ingen af indstillingerne bliver stående. Robots.txt bliver rettet under en helt anden hændelse, en CDN-regel tilføjes af den der har vagten, en framework-opgradering flytter indhold fra server- til klientrendering, og der dukker et nyt crawler-token op, som dine gamle regler ikke nævner. Hver ændring er lille, ingen af dem melder sig selv, og det første symptom er trafik der stille holder op med at komme.

TrustCtrl besøger dit website i en rigtig browser med faste mellemrum, tjekker AI-synligheden sammen med resten af sitets kvalitet — titler og beskrivelser, om dit sitemap passer, hastighed, tilgængelighed og sikkerhedsindstillinger — og fortæller på almindeligt dansk hvad der er ændret, og hvad du skal gøre ved det. Én crawl, ét billede, i en enkel visning til ejeren og en teknisk visning til den der retter.