Tjek om ChatGPT og AI-søgemaskiner kan læse dit site

Kort svar: Test i fire trin, fra hurtigst til grundigst: 1) bed en AI-tjeneste med webadgang om at læse og opsummere en konkret side, 2) tjek robots.txt og laget foran sitet (CDN, firewall, sikkerhedsplugin) for utilsigtede blokeringer, 3) hent siden med curl og se, om indholdet står i den rå HTML, og 4) mål svartiden. De fleste „AI kan ikke se os“-sager afsløres i trin 2 og 3 – en blokering eller indhold, der først bygges med JavaScript.

Fagligt gennemgået: 2. oktober 2026

Før du investerer i citérbart indhold og strukturerede data, skal fundamentet bekræftes: kan AI-tjenesterne overhovedet hente og læse dine sider? Det lyder banalt, men en blokering i en firewall eller et tema, der bygger indholdet i browseren, kan gøre de bedst skrevne sider usynlige for AI-søgning.

Denne guide er den praktiske tjekliste: fire trin, du kan køre på et kvarter, de typiske fund med løsninger, og hvordan du bagefter dokumenterer, at crawlerne faktisk kommer forbi. Kommandoerne virker i terminalen på macOS og Linux og i Windows, hvor curl er installeret som standard i nyere versioner.

Før du ændrer noget: Testene i denne guide læser kun – de ændrer intet. Finder du en blokering, så afklar først, om den er bevidst. Nogle virksomheder har valgt at holde bestemte AI-crawlere ude, og at åbne en firewallregel i blinde kan også lukke uønsket trafik ind. Beslutningen om, hvem der skal ind, står i guiden til AI-crawlere i robots.txt.

Tre slags AI-hentere – og hvorfor det betyder noget

„AI-crawleren“ er ikke én ting. De store udbydere bruger typisk tre typer hentere, og de kan behandles forskelligt både i robots.txt og i firewalls:

• Træningscrawlere indsamler indhold, der kan bruges til at træne modeller. Eksempler er GPTBot (OpenAI) og ClaudeBot (Anthropic).
• Søgecrawlere indekserer sider, så de kan vises og citeres i AI-søgesvar. Eksempler er OAI-SearchBot, Claude-SearchBot og PerplexityBot.
• Hentere på brugerens anmodning åbner en side, fordi en bruger lige har bedt tjenesten om det – fx ChatGPT-User, Claude-User og Perplexity-User.

Navnene ændrer sig, og udbyderne opdaterer jævnligt deres dokumentation, så tjek altid den aktuelle liste hos udbyderen. Pointen er, at du godt kan blokere træning og samtidig tillade søgning og brugerhentning – men kun hvis reglerne er skrevet bevidst. En bred regel mod „alle bots“ rammer dem alle.

1. Den direkte test

Start i toppen: bed ChatGPT, Claude, Perplexity eller en anden tjeneste med webadgang om at „læse denne side og opsummere de tre vigtigste punkter“ – med en konkret URL. Får du en præcis opsummering, virker kæden for netop den tjeneste. Får du „jeg kan ikke tilgå siden“ eller en opsummering, der tydeligvis kun bygger på titel og metabeskrivelse, er noget i vejen, og de næste trin finder ud af hvad.

Kør testen med både en artikel og en produkt- eller ydelsesside. De fejler ofte af forskellige årsager: artikler typisk på blokeringer, produktsider oftere på indhold, der hentes med JavaScript. Husk, at testen kun viser én tjeneste på ét tidspunkt – den er et signal, ikke et bevis for alle AI-tjenester.

2. Tjek robots.txt og laget foran sitet

Åbn ditdomæne.dk/robots.txt og læs efter. Blokerer en gammel wildcard-regel eller en velment „bloker alle bots“-regel også søgecrawlerne fra AI-tjenesterne? Står der en Disallow: / under User-agent: * fra dengang sitet var under udvikling?

Tjek derefter laget foran sitet. CDN’er som Cloudflare har indstillinger til at blokere AI-crawlere og til botbekæmpelse, som kan ramme bredere, end mange regner med – og på nye zoner kan blokering af AI-crawlere være slået til som standard. Menuerne ændrer sig, så find indstillingerne under bot- og sikkerhedsområdet i dit dashboard frem for at følge en gammel skærmsti. Sikkerhedsplugins og serverfirewalls kan gøre det samme på serverniveau.

Du kan se, om serveren behandler en AI-user-agent anderledes end en browser, ved at sende headeren selv:

curl -s -o /dev/null -w "%{http_code}\n" -A "Mozilla/5.0" https://ditdomæne.dk/en-side/
curl -s -o /dev/null -w "%{http_code}\n" -A "GPTBot" https://ditdomæne.dk/en-side/
curl -s -o /dev/null -w "%{http_code}\n" -A "OAI-SearchBot" https://ditdomæne.dk/en-side/

Svarer browseren 200, mens AI-user-agenten får 403, 429 eller en challenge-side, har du fundet blokeringen. En 200 er dog ikke en garanti: rigtige crawlere kommer fra udbyderens egne IP-områder, og nogle firewalls vurderer også IP-adresse og adfærd. Brug derfor også serverloggen (se trin 6).

3. Står indholdet i den rå HTML?

Mange AI-hentere læser HTML’en, som serveren sender den, uden at køre JavaScript. Testen er derfor: hent siden med curl (eller brug browserens „Vis kilde“ – ikke inspektøren, som viser den færdigrenderede side) og søg efter en sætning fra sidens brødtekst:

curl -s https://ditdomæne.dk/en-side/ | grep -c "en sætning fra brødteksten"

Et tal over 0 betyder, at sætningen findes i den rå HTML. Står der 0, bygges indholdet først i browseren – typisk ved headless-opsætninger, page buildere med client-side rendering eller indhold i faner og harmonikaer, der hentes via AJAX, når brugeren klikker. Klassisk WordPress med servergenereret HTML består som regel dette trin, men tjek alligevel de sider, der betyder mest: priser, FAQ og produktbeskrivelser er dem, der oftest indlæses dynamisk.

4. Mål svartiden

AI-hentere arbejder med begrænset tid og vil ikke vente længe på en træg side. Mål din TTFB (tiden til første byte) med curl:

curl -s -o /dev/null -w "TTFB: %{time_starttransfer}s\n" https://ditdomæne.dk/en-side/

Vær særligt opmærksom på sider, der ikke ligger i cache. AI-crawlere rammer ofte dybe sider, som ingen har besøgt for nylig, så en cachestrategi med sidecache og varm cache på vigtige sider tæller direkte. Kør målingen et par gange: første svar viser den ucachede tid, de næste den cachede. Ligger TTFB konsekvent højt på almindelige sider – fx over et sekund – er det både et AI- og et Core Web Vitals-problem og oftest et spørgsmål om hosting og cache; se guiden til høj TTFB.

5. Tjek signalerne i selve siden

Selv når siden kan hentes, kan den sende signaler, der holder den ude af svarene. Se efter disse i den rå HTML og i svarets headere (curl -I):

• <meta name="robots" content="noindex"> eller en X-Robots-Tag: noindex-header, fx efter en staging-indstilling, der er fulgt med i en flytning.
• En kanonisk URL, der peger på en anden side, et andet domæne eller en gammel adresse.
• En titel og metabeskrivelse, der ikke passer til indholdet – AI-tjenester bruger dem som kontekst.
• Indhold bag cookie- eller samtykkevæg, som dækker hele siden i den rå HTML.

Struktureret data hjælper med at gøre indholdet entydigt, men kan ikke redde en side, der ikke kan hentes. Rækkefølgen er: tilgængelig først, forståelig bagefter – se strukturerede data, der understøtter AI-svar.

6. Bekræft i serverloggen

Den mest håndfaste dokumentation er serverens access-log. Søg efter AI-user-agents og se, hvilke sider de har hentet, og hvilken statuskode de fik:

grep -Ei "gptbot|oai-searchbot|chatgpt-user|claudebot|claude-searchbot|claude-user|perplexitybot" access.log | tail -20

Ser du mange 403- eller 429-svar, blokerer noget dem. Ser du slet ingen besøg, er det enten fordi tjenesterne ikke har fundet siderne endnu, eller fordi en blokering ligger foran serveren (fx i et CDN), så forespørgslerne aldrig når frem. Har du ikke selv adgang til loggen, kan din hostingudbyder normalt trække den. Læs mere om at tolke loggen i guiden til loglæsning.

Typiske fund og løsninger

Fund	Årsag	Løsning
—	—	—
AI får 403 eller en challenge	robots.txt, CDN-indstilling, botbekæmpelse eller sikkerhedsplugin	Justér reglerne, så de AI-hentere, du ønsker, er tilladt
Opsummering bygger kun på metadata	Indholdet kræver JavaScript	Servergenereret HTML for kerneindhold; undgå AJAX-indlæst brødtekst
Nogle tjenester ser gammelt indhold	Cache uden purge ved opdatering	Purge ved opdatering; korrekt cacheopsætning på CDN og server
Langsom eller ustabil hentning	Høj TTFB på ucachede sider	Sidecache, cache-opvarmning og tilstrækkelige serverressourcer
Siden hentes, men citeres aldrig	noindex, forkert kanonisk URL eller tyndt indhold	Ret signalerne, og gør indholdet konkret og citérbart
Ingen AI-besøg i loggen	Blokering før serveren eller nye sider uden links	Tjek CDN-regler, sitemap og interne links

Læs også

• Hub: AI-synlighed og GEO
• AI-crawlere i robots.txt: luk ind eller ud?
• Sådan bliver din side synlig i AI-søgning
• Skriv citérbart: FAQ, kort svar og struktur
• Page cache, object cache og browser cache
• WordPress hosting hos Hostious – LiteSpeed, NVMe-lager og dansk support døgnet rundt

Ofte stillede spørgsmål om AI-læsbarhed

Kan jeg teste med AI-crawlernes egen user-agent?

Ja, curl kan sende en vilkårlig user-agent, så du kan se, om serveren behandler fx GPTBot anderledes end en browser. En 403 afslører en blokering med det samme, mens en 200 ikke garanterer alt, da rigtige crawlere også kommer fra bestemte IP-områder. Serverloggen viser, hvad de rigtige crawlere faktisk får.

Min side er bag login. Kan AI læse den?

Nej, og det er som regel meningen. Konsekvensen er, at indhold bag login, betalingsmur eller samtykkevæg ikke findes i AI-svar. Læg de sider, I vil citeres på, offentligt, og hold resten lukket bevidst.

Hvor tit bør jeg køre tjekket?

Efter hver større ændring af tema, cache, CDN eller sikkerhedsopsætning, hvor blokeringer typisk opstår ubemærket, og ellers kvartalsvis sammen med en stikprøve af, hvordan AI-tjenesterne omtaler jeres brand.

Kan AI læse indhold, der bygges med JavaScript?

Nogle tjenester kan, mange kan ikke – og du kan ikke vide, hvilke der gør det hver gang. Det sikre valg er, at overskrifter, brødtekst, priser og FAQ står i den HTML, serveren sender. Test med curl eller „Vis kilde“, ikke med browserens inspektør.