.webp)
.avif){kind=logo}
AI-assistenter har blitt en ny type besøkende på nettet, og de leser nettsider på en annen måte enn mennesker. Hvordan vi gjorde heihuset.no agent-klar ved hjelp av Cloudflares nye agent-readiness-skanner? Og hvorfor er tradisjonelle SEO-grep lenger er nok dersom du vil bli anbefalt av ChatGPT, Claude og andre AI-tjenester?
Se for deg at noen spør ChatGPT eller Claude om et problem produktet ditt løser. Assistenten prøver å lese nettsiden din, får et tomt HTML-skall i retur, og anbefaler noe annet i stedet. Ingen feilmelding, ingen logg som varsler deg; du er bare ikke med i samtalen. Kanskje du har brukt flere år på å rangere i Google, og så dukker det opp en ny lesergruppe som ikke får åpnet døra.
Når vi bygger heihuset.no, produktet jeg jobber med for Gjensidige, er vi svært bevisste på dette. Cloudflares skanner isitagentready.com ga oss 0 poeng: «Level 0, Not Ready». Én arbeidsdag senere viste samme skanner «Level 5, Agent-Native». Imellom lå en spesifikasjon som vurderte hver enkelt sjekk, en runde pull requests med review og verifisering i produksjon. Agenter gjorde alt sammen, med meg som godkjenner underveis.
Det mest slående i etterkant er hvor lite som skulle til. Alt vi bygde er velkjent webteknologi, og den egentlige jobben var å vite hva agenter ser etter når de banker på døra. Den sjekklisten får du her, sammen med begrunnelsen for det vi med vilje lot stå rødt.
Klassisk SEO handler om å bli funnet av Google. Det som har endret seg, er hvem som leser nettsider nå: i 2026 passerte bot-trafikken menneskene, med 57,5 prosent av HTML-trafikken ifølge Cloudflare. Samtidig faller klikkene fra tradisjonelt søk, fordi AI Overviews (Googles AI-genererte svar øverst i søkeresultatet) besvarer spørsmålet før brukeren rekker å klikke.
Trafikken fra AI-assistenter som ChatGPT, Claude og Perplexity er fortsatt liten, rundt én prosent av totalen, men den konverterer flere ganger bedre enn organisk søk i målinger fra flere analyseleverandører. Når en assistent anbefaler deg ved navn, kommer besøkeren ferdig overbevist. Samtidig koster crawlingen (automatisk henting og lesing av nettsider) mer enn den gir tilbake i klikk: Cloudflare har målt at OpenAI crawlet over tusen sider per besøkende de sendte tilbake.
Bransjen har rukket å lage minst tre akronymer for å optimalisere mot dette: GEO (Generative Engine Optimization), AEO (Answer Engine Optimization) og ASO (Agentic Search Optimization). De beskriver i praksis det samme: å bli funnet, sitert og brukt av AI-systemer. «Agent-readiness» er den tekniske enden av begrepsfloraen: at en agent som besøker siten din, faktisk klarer å lese og bruke den.
isitagentready.com er Cloudflares svar på «hvordan står det til med vår applikasjon?», lansert i april 2026. Skanneren kjører 19 sjekker i fem kategorier og gir en score fra 0 til 100 med nivåer fra «Not Ready» til «Agent-Native». Før du scanner, velger du hvilken type nettsted du har, og det avgjør hvilke sjekker du måles på:
Driver du en innholdsside, kan du trygt ignorere hele API-familien av sjekker. heihuset.no er utad en ren innholdsside, så Content Site-presetet var det vi målte oss mot.
Tallene fra lanseringen viser hvor lav lista ligger. Blant de 200 000 største domenene har 78 prosent robots.txt, 4 prosent Content Signals og 3,9 prosent markdown-støtte. Det skal med andre ord lite til for å ligge langt foran, og det gjelder også her hjemme:
Baseline-scanen ga 0 poeng fordi alt manglet. Hver eneste sti skanneren prøvde, endte i en såkalt soft-404: serveren svarte «200 OK» og returnerte den vanlige nettsiden, uansett hva du ba om. Ba du om /robots.txt, fikk du altså appens HTML i retur i stedet for en tekstfil. Agentene fikk skannerens funn som utgangspunkt og bygde fem ting:
Content-Signal: search=yes, ai-train=no, ai-input=yes. Den siste betyr ja til at assistenter bruker innholdet som kilde når de svarer (såkalt RAG eller grounding).text/markdown, får du ren markdown i stedet for HTML-skallet. Her er gevinsten stor for agenter som betaler per token: Cloudflare målte en typisk bloggpost til 16 180 tokens som HTML og 3 150 som markdown.
Alt dette er offentlig og kan sjekkes fra terminalen din:
curl <https://www.heihuset.no/robots.txt>
curl <https://www.heihuset.no/sitemap.xml>
curl -H "Accept: text/markdown" <https://www.heihuset.no/>
Da alt var merget og deployet, kjørte vi skanneren på nytt og fikk 21 poeng. Implementasjonene var riktige; det var infrastrukturen mellom appen og verden som serverte noe annet enn koden returnerte.
Detaljene er spesifikke for vårt oppsett og lite overførbare, men mønsteret er generelt: gatewayer, cacher og rolling deploys kan alle gjøre at produksjon svarer noe annet enn koden din tilsier. Hos oss endte robots.txt en kort stund med å be samtlige crawlere holde seg unna. Avhengig av hosting-leverandør og løsning må du regne med et par slike triks før alt stemmer.
To lærdommer er verdt å ta med seg uansett oppsett. Verifiser innholdet i svaret i produksjon, og la aldri en grønn statuskode alene telle som bevis: vår «verifisert i prod»-sjekk så på statuskode og content-type, og begge var riktige mens selve innholdet var feil. Og husk at cachede svar kan overleve deployen din, så kjør skanneren på nytt etter at cache-TTL-en (levetiden på den lagrede kopien) har gått ut, ellers jakter du spøkelser.
Selve verifiseringen er for øvrig en jobb det lønner seg å gi agenten. Det er tross alt agenter som skal konsumere disse endepunktene, og en agent curler seg gjennom robots.txt, sitemap og markdown-svarene og sjekker hvert svar mot Cloudflares anbefalinger langt mer systematisk (og raskere) enn en utvikler som klikker seg rundt i nettleseren.
Hver feilet sjekk i skanneren kommer med en forklaring, en «Copy prompt»-knapp du kan lime rett inn i din egen coding-agent, og en lenke til en SKILL.md, altså en ferdig agent-skill med oppskriften på fiksen. Skanneren publiserer en indeks med slike skills på sitt eget /.well-known/agent-skills/-endepunkt, én for hver standard den sjekker, og hver skill avslutter med et maskinsjekkbart valideringssteg mot skannerens API.
Dermed oppstår en pussig loop: agenten som fikser nettstedet ditt, henter oppskriften fra tjenesten som klaget, og verifiserer fiksen mot samme tjeneste. Verktøyet som måler agent-readiness, er selv agent-ready. Nå har tjenester begynt å publisere prosessene sine i samme format.
To av sjekkene i Content Site-presetet lot vi stå røde. DNS-AID (agent-oppdagelse via DNS) forutsetter agent-endepunkter å annonsere, og Link headers-sjekken godkjenner bare lenker til API-kataloger og tjenestedokumentasjon. Resten av de røde hører til API / Application-siden: MCP Server Card (et maskinlesbart visittkort for en MCP-server), API-katalog (RFC 9727) og OAuth discovery. Alt sammen forutsetter infrastruktur dette produktet ikke har: et offentlig API, en OAuth-utsteder eller en MCP-server. Vi landet på å hoppe over dem, dokumentere begrunnelsen for hver enkelt, og la sjekkene stå røde.
Tallet du får, avhenger altså av hvilke sjekker du slår på, og samme side kan lande på alt fra toppnivå til midt på treet. Den viktige øvelsen er å velge sjekkene som gjelder for produktet ditt, og å kunne forklare de røde som blir stående.
llms.txt (en foreslått konvensjon der en tekstfil i roten skal gi AI-modeller en kompakt oversikt over nettstedet) dukker alltid opp i disse diskusjonene. Ahrefs analyserte serverlogger fra 137 000 domener og fant at 97 prosent av llms.txt-filene ikke fikk en eneste forespørsel fra AI-crawlere i mai 2026, og Googles John Mueller har sammenlignet filen med keywords-metataggen fra gamle dager, altså en egenerklæring om hva siten handler om, som søkemotorene endte med å ignorere fordi påstandene like gjerne kunne være usanne, og innholdet uansett kan leses direkte. Cloudflares skanner sjekker den ikke engang.
Kodeagenter ber i stedet om markdown via Accept-headeren; Checkly målte at Claude Code, Cursor og OpenCode gjør nettopp det. Skal du prioritere én ting for agentlesbarhet, er det content negotiation på HTTP-nivå.
Mens jeg skrev dette innlegget, kjørte jeg skannerens API mot heihuset.no på nytt. Alle de fem sjekkene passerer fortsatt. Det fine er at sitemap-en nå inneholder en artikkel publisert etter at vi gjorde webapplikasjonen agent-ready, uten at noen har rørt agent-readiness-koden siden juni. robots.txt, sitemap og markdown-endepunktene genereres fra innholdet, så nytt innhold blir agent-klart uten ekstra arbeid. Riggingen ligger i systemet og blir med videre.
Magnus bygger AI i Capra, nå på Gjensidiges «Hei, huset!». Han er opptatt av AI som fungerer i praksis og av å rigge tverrfaglige team for en AI-first arbeidsform. Det skriver han om og holder foredrag om.
