Innledning
I juni 2026 dukker det samme spørsmålet stadig opp i utviklertidslinjer og SEO-kanaler: hvordan bør du servere innholdet ditt til AI-agenter? Ren Markdown, fordi det er det modellene ser ut til å like? Et separat maskinendepunkt? Et nytt kunnskapsformat? Diskusjonen er høylytt, den er meningssterk, og det meste av den snakker forbi seg selv.
Her er praktikerstandpunktet med en gang, for vi har noe på spill her. Vi serverer allerede ren, semantisk, serverrendret HTML pluss Schema.org fra en Astro-frontend på Cloudflare. Denne debatten bekrefter det valget. Den truer det ikke. Nesten hvert “du må bytte til Markdown for agenter”-argument faller fra hverandre i det øyeblikket du skiller tre lag som stadig knas sammen til ett.
Dette er ikke kommentar fra sidelinjen. I det nordiske markedet, der kunder gjerne vil ha rene, etterprøvbare oppsett framfor hype, kjører vi på nøyaktig den infrastrukturen debatten handler om, og vi driver allerede agentlaget debatten stadig peker på som den egentlige fremtiden. Så dette er en rapport innenfra, ikke et gjenfortelling fra de billige plassene.
De viktigste poengene i et nøtteskall
- Argumentet blander sammen tre lag som ikke er samme problem: Markdown som agentutdata, Markdown som en måte å servere sider på, og OKF som et kunnskapslag.
- Markdown som agentutdata er et maskin-til-menneske-visningsvalg, og en av dem som presset hardest på for det, har nettopp forlatt det til fordel for HTML.
- Å servere Markdown til bots på samme URL der mennesker får HTML er i beste fall overflødig og i verste fall cloaking. Google og Bing sa begge nettopp det, rett ut.
- OKF er et kuratert kunnskapsformat for agentrørledninger, ikke et nettstedsleveringsformat. Det er et annet lag enn SEO.
- Det eneste leveringssignalet som både Google og Bing dokumenterer som faktisk konsumert, er ren semantisk HTML pluss Schema.
- Observer, ikke skynd deg å implementere, de nye leveringsformatene. Det ekte fremtidsveddemålet er agent-handlingslaget, og akkurat den delen har vi allerede bygget.
Tre lag alle blander sammen
Det meste av varmen i denne debatten kommer av å behandle tre separate spørsmål som ett. Skill dem fra hverandre, og motsetningene løser seg opp.
Lag 1: Markdown som agentutdata
Dette handler om hva en modell skriver tilbake til et menneske, ikke om hvordan et nettsted serveres. Når en agent genererer en rapport, et chatsvar eller et dokument, i hvilket format bør den sende det ut?
Lenge var standardsvaret Markdown. Det er rent, det er tokenbillig, det rendres pent i en chatboble. Så trakk Thariq Shihipar, som jobber med Claude Code hos Anthropic, det offentlig tilbake. Etter å ha bygget side-om-side-eksempler som sammenligner effektiviteten til HTML og Markdown, var konklusjonen hans at HTML vinner for agentutdata, fordi HTML bærer strukturen, semantikken og interaktiviteten som en rikere menneskevendt flate trenger. Markdown flater ut for mye.
Les det nøye, for det blir rutinemessig sitert baklengs. Personen som står agentutdata nærmest, beveger seg mot HTML, ikke vekk fra det. Og avgjørende: dette laget sier ingenting om hvordan du bør servere markedsføringsnettstedet ditt til en crawler. Det er maskin-til-menneske-kommunikasjon. Den som siterer Thariq som en grunn til å konvertere nettstedet ditt til Markdown, har snudd hans eget argument på hodet.
Lag 2: Markdown-for-Agents som sidelevering
Dette er laget som faktisk berører oss, fordi vi kjører på Cloudflare. Cloudflares Markdown-for-Agents konverterer HTML-en din til Markdown i sanntid når en klient sender Accept: text/markdown, annonserer et tokenantall via x-markdown-tokens og rapporterer rundt 80 prosent tokenreduksjon mot rå HTML. Det er i beta på betalte planer, og klienter som Claude Code og OpenCode sender allerede headeren. Det styres av Content-Signal, som på Cloudflare er opt-in som standard, så dette kan være på for domenet ditt uten en bevisst beslutning. Akkurat den på-som-standard-detaljen bør enhver Cloudflare-kunde faktisk sjekke.
Tokenbesparelsen er reell. Synlighetspåstanden er ikke det. Det finnes ingen dokumentert bevis for at det å servere en Markdown-representasjon endrer om et AI-system siterer deg. Og i det øyeblikket du serverer bots en annen representasjon av samme URL enn mennesker mottar, står du rett ved cloaking-grensen.
Googles John Mueller sa det helt uten diplomati:
“Converting pages to markdown is such a stupid idea. Did you know LLMs can read images? WHY NOT TURN YOUR WHOLE SITE INTO AN IMAGE?”
Det er sarkasme med et poeng inni. Hvis modellen allerede kan lese HTML-en din, er en parallell Markdown-kanal ikke nytt signal, det er en ekstra ting å vedlikeholde og holde synkronisert. Bings Fabrice Canel var tørrere og uten tvil enda mer fellende for alle som håper å spare crawl-budsjett:
“Really want to double crawl load? We’ll crawl anyway to check similarity.”
Med andre ord: søkemotoren henter HTML-en uansett, for å verifisere at Markdown-en din stemmer med det mennesker ser. Du reduserer ikke last, du legger til en flate som må stemme overens med den kanoniske, ellers blir du flagget. To av planetens største crawl-operatører fortalte deg, offentlig, at dette ikke gjør det tilhengerne håper.
Lag 3: OKF som et kunnskapslag
- juni 2026 publiserte Google Cloud Open Knowledge Format, OKF, med et offentlig referanserepositorium. Det er bevisst ydmykt: Markdown-filer med YAML-frontmatter, ett konsept per fil, kun
type-feltet påkrevd, produsent og konsument holdt uavhengige. Rammen er “et format, ikke en plattform”, og det skylder åpenbart Andrej Karpathys LLM-wiki-gist noe, ideen om en menneskekuratert kunnskapsbase skrevet for maskiner.
Her er det som betyr noe og det oppsummeringene bommer på: OKF er ikke en måte å servere nettstedet ditt på. Det er en måte å pakke kuratert kunnskap på slik at en agentrørledning kan konsumere den. Det lever oppstrøms for gjenfinning, i kontekst- og grunnlagslaget, ikke ved URL-en der en crawler møter siden din. Som Adam Rogala påpekte i en LinkedIn-kommentar til kunngjøringen, gir OKF mening, men på et annet lag enn SEO. Å blande sammen “Google ga ut et Markdown-kunnskapsformat” med “Google vil at du skal servere nettstedet ditt som Markdown” er den klart vanligste feilen i den nåværende syklusen, og de to er ikke i nærheten av å være det samme.
Det finnes en fornuftig versjon av Markdown i en publiseringsstack, og den er verdt å nevne så ingen hører dette som anti-Markdown. Markdown i kildekoden din, rendret til HTML ved byggetid, er nøyaktig slik denne artikkelen er skrevet. Det er rett sted for det. Å sende rå Markdown til en nettleser, eller til en crawler som forventer HTML, er delen som ikke gir mening. Som Bartosz Łaszczewski understreket i samme diskusjon, er konsumenten i den andre enden bygget rundt HTML, og å sende rå Markdown til en nettleser går på tvers av det.
Hvorfor denne debatten bekrefter stacken vår
Skill de tre lagene fra hverandre, og konklusjonen er nesten kjedelig, noe som er poenget. Det som allerede fungerer, fortsetter å fungere.
Vi serverer serverrendret, semantisk HTML. Overskrifter er overskrifter, lister er lister, article, nav og time betyr det de sier, og de strukturerte dataene er ekte Schema.org i stedet for dekorasjon. Det er representasjonen Google indekserer, representasjonen Bing crawler, og representasjonen en LLM tar inn når den henter siden. Det er også, ikke tilfeldig, representasjonen som rendres raskt for mennesker. Det finnes ingen forgrening å holde synkronisert, ingen andre kanal som kan drive fra hverandre, ingen cloaking-risiko.
Alt debatten er engstelig for, får vi gratis ved å ikke jage det. Når Mueller sier Markdown-konvertering er meningsløst fordi modellen leser HTML-en din, er det en beskrivelse av oppsettet vårt som fungerer som tiltenkt. Når Canel sier Bing crawler HTML-en uansett, er det greit, fordi HTML-en er det kanoniske artefaktet, og det er ingenting annet å avstemme. Vi måtte ikke reagere på noen av uttalelsene. Arkitekturen hadde allerede besvart dem.
Det ene dokumenterte signalet
Hvis du vil ha en regel som overlever neste formatkunngjøring, her er den. Ren, serverrendret, semantisk HTML med gyldig Schema.org er den eneste leveringstilnærmingen som både Google og Bing dokumenterer som noe de faktisk konsumerer. Alt annet i dette feltet er enten et forslag uten målt konsum, eller en optimalisering av kostnad heller enn synlighet.
Bing, gjennom Copilot, leser strukturerte data. Google leser strukturerte data for sine egne flater. De store språkmodellene tar inn den rendrede HTML-en. Ingen av de nye leveringsformatene, llms.txt, Markdown-for-Agents, ai.txt, har en dokumentert effekt på om du blir sitert. Så den ærlige ingeniørholdningen er: hold HTML-en ren, hold Schema gyldig, og behandle nye leveringsformater som noe å observere heller enn å implementere. Samme disiplin gjelder en headless WooCommerce-bygg på Astro: handelsdataene er ekte semantisk markering, ikke en bot-kun-sidekanal.
Den ærlige vurderingen av llms.txt
Vi publiserer /llms.txt og /llms-full.txt, så dette er selvkritikk, ikke et billig stikk mot noen andre. Skeptikerne har et sterkt poeng. Mueller har sagt at formatet i praksis ignoreres, og en uavhengig serverlogg-studie fant null AI-crawler-forespørsler etter llms.txt på tvers av hundrevis av domener over flere måneder. Som en frittstående fil sluppet på et nettsted i håp om at noe leser den, utretter den svært lite.
Vårt eget AI-synlighetsplaybook sier nøyaktig det, skriftlig: ingen stor LLM-leverandør forplikter seg formelt til å lese disse filene, men de dukker opp i loggene våre ofte nok til å rettferdiggjøre å beholde dem. Vi holder begge tankene samtidig. En generisk, foreldreløs llms.txt er nær dødvekt. Samme fil som én node i et integrert agent-oppdagelsesoppsett, koblet til et ekte handlingslag, er et annet objekt med en annen kostnad-nytte-profil. Feilen er å sitere “ingen leser llms.txt”-studiene som om de avgjorde spørsmålet for enhver implementering. De avgjorde det for tilfellet med den frittstående filen.
Det ekte fremtidsveddemålet: agent-handlingslaget
Her bryter vi helt med “bare server Markdown”-gjengen, og her ligger den virkelig interessante fremtiden. Neste steg er ikke et bedre dokument for en agent å lese. Det er å la agenten handle uten å lese et dokument i det hele tatt.
Det er agent-handlingslaget: WebMCP, Agent2Agent (A2A) og Model Context Protocol. I stedet for å skrape en tjenesteside og gjette, kaller en agent en funksjon, request_quote, browse_services, search_site, og får et typet svar. WebMCP, et samarbeid mellom Google og Microsoft, har vært i Chrome-utviklerforhåndsvisning siden februar 2026, og det peker rett mot denne modellen: siden eksponerer kapabiliteter, agenten påkaller dem.
Vi har allerede bygget dette. Under public/.well-known/ publiserer vi et A2A-AgentCard, et MCP-server-card etter SEP-1649, en ACP-deskriptor og Markdown-innholdsforhandling gjennom et .md-URL-suffiks og Accept: text/markdown-håndtering i mellomvare, med det hele annonsert via Link-headere og robots-regler. fetch_markdown-ferdigheten på AgentCardet vårt peker mot /llms-full.txt, som er nøyaktig derfor llms-filene ikke er foreldreløse her, de er koblet inn i handlingslaget i stedet for å stå alene.
Legg merke til asymmetrien. Markdown-for-Agents og innholdsforhandling, leveringsformatene, behandler vi som observer-ikke-implementer, til stede fordi infrastrukturen tilbyr dem, ikke fordi vi har målt en nytte. Handlingslaget behandler vi som en bevisst fremtidsinvestering, fordi det er retningen Thariqs HTML-argument, WebMCP og hele bølgen av agentverktøy alle peker mot. Lesing er nåtiden. Handling er veddemålet.
Hva vi faktisk gjør
For å gjøre holdningen konkret, her er fordelingen.
- Levering: ren semantisk HTML pluss Schema.org, serverrendret, raskt. Dette er den bærende beslutningen, og den endrer seg ikke.
- Markdown-for-Agents og Content-Signal: til stede på Cloudflare, latt være aktivert der det er harmløst, men sjekket, for opt-in-standarden betyr at det kan være på uten en beslutning. Ingen synlighetspåstand knyttet til.
- llms.txt og llms-full.txt: publisert, men som innkoblede noder i agent-oppdagelsessystemet, ikke som et frittstående veddemål, og ærlig beskrevet i vårt eget playbook.
- OKF: arkivert under kunnskapslag. Relevant hvis og når vi mater kuratert kunnskap inn i en agentrørledning. Ingen endring i nettstedslevering.
- Agent-handlingslag, A2A, MCP, WebMCP-nært: bevisst investering, allerede levert under
/.well-known/, og delen av hele denne debatten vi er mest trygge på.
Konklusjon
Debatten i 2026 om “HTML mot Markdown for agenter” ser ut som et veiskille. Det er den ikke. Når du først skiller agentutdata fra sidelevering fra kunnskapslaget, slutter de tre argumentene å motsi hverandre, og de peker alle samme vei. Server ren semantisk HTML og gyldig Schema, for det er det ene signalet begge de store crawlerne dokumenterer at de konsumerer. Observer de nye leveringsformatene i stedet for å jage dem, for ingen har en målt effekt på siteringer. Og legg fremtidsenergien din i agent-handlingslaget, for det er der lesing blir til handling.
Vi kom ikke hit ved å forutsi debatten. Vi kom hit ved å bygge på det kjedelige, dokumenterte signalet og behandle alt nyere som noe å måle først. Det er hele metoden. Den høylytte delen av internett krangler om formatet. Det stille, dokumenterte svaret har ikke endret seg.
Hvis du vil ha det bredere synlighetsbildet, samler vårt playbook for AI- og LLM-synlighet resten av spakene i prioritert rekkefølge.
Sist oppdatert: 15. juni 2026.
