- Udgivet
- Opdateret
Gør din hjemmeside klar til AI-agenter
Agent- og AI-parathed handler om at gøre en hjemmeside forståelig for søgemaskiner, AI-assisterede søgefunktioner, søgerobotter og automatiserede agenter, uden at miste kontrol over adgang, belastning, privatliv og forretningsværdi.
Det er ikke et separat trick oven på SEO. Det bygger på det samme fundament: sider som søgemaskiner kan gennemgå, tydelig tekst, brugbare interne links, struktureret indhold, præcise metadata, sikre formularer og bevidste regler for bots.
På virksomhedshjemmesider viser det sig meget konkret. En håndværker skal have tydelige ydelsessider og dækningsområde. En webshop skal have produkter, priser, lager- og returinformation, der kan forstås uden gætværk. En servicevirksomhed skal gøre kontaktvej, troværdighed og vilkår synlige uden at gemme de vigtigste oplysninger i scripts eller billeder.
Jeg har en svaghed for scoreværktøjer: Hvis et værktøj giver mulighed for at nå 100%, går jeg som regel efter det, selv om 100% næsten aldrig er nødvendigt på en almindelig hjemmeside. :-) Den grønne markering er ikke det egentlige mål. Når jeg arbejder mig gennem alle kontrollerne, bliver jeg tvunget til at forstå protokollen, tage stilling til, om den hører hjemme på hjemmesiden, og sikre, at alt, hvad jeg udgiver, er forbundet til en funktion, der faktisk virker.
Jeg brugte Webstudiet som implementeringsprojekt. Den første fulde scanning placerede den offentlige hjemmeside på niveau 5, “Agent-Native”, men scoren var 93%. Det sidste pointgivende hul var ARD: Hjemmesiden havde allerede reelle MCP-, OpenAPI- og Agent Skills-ressourcer, men manglede et fælles manifest, der forbandt dem. Det var et nyttigt hul at lukke og ikke en protokol, der kun blev tilføjet for syns skyld.
Start med hvad Google faktisk kræver
Googles aktuelle vejledning for AI-funktioner som AI Overviews og AI Mode er ret konservativ: De samme SEO-grundprincipper gælder stadig, og der kræves ikke ekstra tekniske signaler eller særlige strukturerede data for at blive vist i funktionerne. Google skriver også, at en side skal være indekseret og kunne vises med et uddrag for at kunne optræde som understøttende link.
Det gør prioriteringen enkel. Før du tilføjer nye agentspecifikke filer, skal siden kunne gennemgås, indekseres, linkes, vises, forstås og vises med et passende uddrag. Det hænger direkte sammen med guiden om adgang for søgerobotter og indeksering.
Nye maskinlæsbare filer kan stadig være nyttige for andre AI-systemer og agenter. De erstatter bare ikke grundlæggende teknisk SEO.
Gør vigtigt indhold tekstbaseret og let at udtrække
AI-systemer og agenter kan bedre bruge indhold, når de vigtigste oplysninger findes som almindelig tekst i den renderede side. Lad ikke billeder, carousels, skjulte faner eller JavaScript-only widgets bære sidens vigtigste budskab.
En ydelsesside bør tydeligt forklare, hvad der tilbydes, hvem det er relevant for, hvor ydelsen leveres, hvilket problem den løser, hvad næste skridt er, og hvilke begrænsninger der gælder. Relevante detaljer kan være serviceområde, prisoplysninger, åbningstider, bookingforløb, kontaktvej eller samarbejdsform.
Det hjælper også mennesker. Hvis en agent kan udtrække ydelse, område, prisramme og kontaktvej uden gætværk, kan en travl virksomhedsejer som regel også.
Brug struktur og metadata til at fjerne tvetydighed
Agentparathed afhænger af en ren struktur. Overskrifter skal beskrive indholdet under dem. Interne links skal pege på relevante næste skridt. Sidetitler og beskrivelser skal matche siden. Canonical-tags, viderestillinger og sprogalternativer må ikke modsige hinanden.
Strukturerede data er nyttige, når de afspejler den synlige side. Brug Article, BreadcrumbList, Organization, LocalBusiness, Product, Offer eller Service, når siden faktisk understøtter den betydning. Googles retningslinjer for strukturerede data er tydelige om, at strukturerede data skal repræsentere den synlige side, ikke skjulte eller misvisende påstande.
Implementeringen af de signaler er gennemgået nærmere i guiden om struktur, semantik og metadata.
Styr søgerobotter og AI-botter bevidst
Regler for søgerobotter skal afspejle en forretningsbeslutning, ikke en tilfældig opsætning. Nogle robotter hjælper med synlighed. Nogle træner modeller. Nogle skaber belastning uden at sende relevant trafik tilbage. Nogle forsøger at nå URL’er, der aldrig bør automatiseres.
For Googles AI-funktioner i Search er adgang for Googlebot og styring af uddrag de relevante søgekontroller. Hvis du vil begrænse, hvad der kan vises fra en side i Search, skal du se på nosnippet, data-nosnippet, max-snippet og noindex. Hvis du vil begrænse bestemte former for AI-træning eller brug uden for Search, skal du gennemgå reglerne for den enkelte søgerobot, for eksempel Google-Extended til visse Google AI-formål uden for Search.
På resten af nettet kan hver søgerobot have sin egen tekniske identifikation og sine egne regler. Gennemgå serverens logfiler, begrænsning af forespørgsler, firewallregler og CDN-botkontrol, før du antager, at ét direktiv dækker alle automatiserede systemer.
Maskinlæsbare filer er valgfrie værktøjer
Filer som /llms.txt, /llms-full.txt, Markdown-adresser, feeds, API-kataloger og standardiserede filer til at opdage indhold kan hjælpe nogle automatiserede systemer med at forstå en hjemmeside. De er mest nyttige, når de er korrekte, vedligeholdte og hænger sammen med reelt offentligt indhold.
For en mindre servicehjemmeside kan en kort llms.txt eller Markdown-version af nøglesider være nok. For et bookingsystem, et SaaS-produkt, en markedsplads eller et API-drevet projekt kan mere detaljerede maskinlæsbare beskrivelser give mening: API-dokumentation, OpenAPI-filer, MCP server cards, WebMCP, A2A agent cards eller beskrivelser af færdigheder.
Reglen er enkel: tilføj maskinlæsbare formater, når de reducerer tvetydighed eller understøtter en reel arbejdsgang. Tilføj dem ikke som dekorative SEO-filer, som ingen vedligeholder.
Beskyt handlinger, formularer og kommercielle forløb
At læse indhold er noget andet end at udføre en handling. En agent, der opsummerer en ydelsesside, er lav risiko. En agent, der indsender en kontaktformular, booker en tid, beder om et tilbud, lægger en vare i kurven eller udløser en betaling, kræver stærkere grænser.
Vigtige forløb bør have tydelige etiketter på formularfelter, validering, CSRF-beskyttelse, beskyttelse mod misbrug, begrænsning af forespørgsler, bekræftelsestrin, brugbare fejlbeskeder og logning. Private områder, administrative adresser, dynamiske søge-URL’er, dyre genererede sider og bookinghandlinger bør ikke være åbne for ubegrænset automatiseret adgang.
Det overlapper med sikkerhed, privatliv og protokol. Agent-parathed må aldrig betyde, at alt åbnes.
Hvad isitagentready.com tjekker – og hvad hver kontrol kræver
Cloudflares isitagentready.com-scanner har i øjeblikket særskilte profiler til indholdssider og API’er eller applikationer samt en kontrol med alle punkter. Den forskel er vigtig: En bestået kontrol betyder, at scanneren fandt det protokolsignal, den leder efter. Det betyder ikke, at alle hjemmesider bør implementere alle protokoller.
Kravene nedenfor sammenfatter scannerens egne offentliggjorte implementeringsvejledninger fra september 2026. Mange af de agentspecifikke protokoller er udkast eller tidlige standarder, så kontrollér den aktuelle specifikation og scannerens vejledning før implementering. Kontrollerne viser, om bestemte signaler kan findes; de er ikke en fuldstændig sikkerheds- eller protokoltest.
Findbarhed
| Kontrol | Hvad scanneren forventer | Hvornår det er relevant |
|---|---|---|
robots.txt | /robots.txt svarer med HTTP 200 og text/plain, indeholder User-agent med Allow eller Disallow og henviser til sitemap, når der findes et. | Næsten alle offentlige hjemmesider. |
| Sitemap | /sitemap.xml svarer med gyldig XML, indeholder kanoniske URL’er i <loc>, holdes ajour og er angivet i robots.txt. | Hjemmesider med offentlige sider, som skal kunne findes. |
| Link-response-headere | Forsidens HTTP-svar har en RFC 8288 Link-header, der peger på en reel maskinlæsbar ressource med en relation som api-catalog, service-desc, service-doc eller describedby. | Hjemmesider, der udgiver et API-katalog, en specifikation, dokumentation eller et andet opdagelsesdokument. |
| DNS for AI Discovery (DNS-AID) | Udgiv ServiceMode-SVCB-poster, eller HTTPS-poster til HTTPS-endpoints, under navnerummet _agents – for eksempel _index._agents.example.com eller _a2a._agents.example.com. Medtag alpn og forbindelsesparametre, brug numeriske keyNNNNN-navne til eksperimentelle specialparametre, og returnér data, der er godkendt med DNSSEC. | Organisationer, der driver reelle agent-, MCP- eller A2A-endpoints. Det er unødvendigt på en almindelig hjemmeside, der kun udgiver indhold. |
På Webstudiet leverer jeg en robots.txt som almindelig tekst med henvisning til sitemap, genererer sitemap som /sitemap-index.xml og tilføjer Link-headere til Markdown-indekset, sitemap, API-kataloget og Agent Skills-indekset. Til DNS-AID har jeg udgivet en HTTPS-post på _index._agents.webstudiet.com med prioritet 1 og alpn=“mcp,h2”. Jeg har også aktiveret DNSSEC, så validerende resolvere returnerer et godkendt svar. De fire kontroller af findbarhed består nu på den offentlige hjemmeside.
DNSSEC er den del af DNS-AID-kontrollen, der let bliver overset. Scannerens DNS-AID-vejledning kræver, at offentlige discovery-zoner er signeret, så scannerens DNS-over-HTTPS-opslag kan validere svaret. I praksis betyder det normalt, at DNSSEC skal aktiveres for domænets DNS-zone, og at DS-posten skal være på plads hos domæneregistratoren. Det er ikke nok blot at tilføje en HTTPS- eller SVCB-post.
Scannerens krav er strengere end et ubetinget krav i det aktuelle Internet-Draft om DNS-AID. Udkastet siger, at DNS-AID-poster bør signeres med DNSSEC; bruges TLSA-poster, skal de være signeret. I denne scanner består usignerede DNS-AID-poster dog ikke kontrollen.
Adgang til indhold
| Kontrol | Hvad scanneren forventer | Hvornår det er relevant |
|---|---|---|
| Markdown-indholdsforhandling | En forespørgsel til sidens normale URL med Accept: text/markdown returnerer en brugbar Markdown-version og Content-Type: text/markdown. Forespørgsler uden denne header returnerer fortsat HTML. En x-markdown-tokens-header er nyttig, når den er tilgængelig, men er ikke det centrale krav. | Indholds-, dokumentations- og produktsider, hvor agenter har gavn af en version med mindre støj. |
Jeg har implementeret det i den fælles Cloudflare Worker, som bruges af begge Webstudiet-hjemmesider. En forespørgsel til en almindelig side med Accept: text/markdown bliver konverteret til Markdown undervejs, mens den samme URL fortsat returnerer HTML til en browser. Svaret indeholder Content-Type for Markdown og headere med antal tokens. Det er indholdsforhandling på samme URL, ikke bare en særskilt .md-fil.
Konverteringen bevarer nyttige overskrifter, tekst, lister, tabeller, links, billedbeskrivelser og kode, men udelader navigation og anden grænsefladestøj. Resultatet er mindre og lettere for en agent at bruge, uden at jeg opretter endnu en indholdskilde, som kan blive forældet.
Styring af botadgang
| Kontrol | Hvad scanneren forventer | Hvornår det er relevant |
|---|---|---|
| Regler for AI-bots | Eksplicitte User-agent-blokke i robots.txt til AI-crawlere med en Allow- eller Disallow-politik. Scanneren genkender blandt andet GPTBot, OAI-SearchBot, Claude-Web, Google-Extended, Amazonbot, anthropic-ai, Bytespider, CCBot og Applebot-Extended. En wildcard-blok alene består ikke kontrollen. | Hjemmesider, der vil have en udtrykkelig politik for AI-crawlere. |
| Content Signals | Et Content-Signal-direktiv under den relevante User-agent-blok, som angiver præferencer for ai-train, search og ai-input, for eksempel Content-Signal: ai-train=no, search=yes, ai-input=yes. | Udgivere, der vil beskrive tilladt brug mere præcist end med tillad eller afvis. Det er en ny konvention, ikke i sig selv en teknisk adgangskontrol. |
| Web Bot Auth | Et JWKS med mindst én offentlig nøgle til kontrol af signaturer på /.well-known/http-message-signatures-directory. En bot, som hjemmesiden selv driver, skal desuden signere udgående forespørgsler med headerne Signature-Agent og Signature-Input, så modtageren kan validere dem. | Hjemmesider, der driver en bot eller agent, som sender forespørgsler til andre hjemmesider. En almindelig indholdsside behøver ikke opfinde en udgående botidentitet. |
Min robots.txt tillader udtrykkeligt de vigtigste søge- og assistentcrawlere i stedet for kun at være afhængig af User-agent: *. Jeg udgiver også Content-Signal: search=yes, ai-input=yes. Jeg angiver bevidst ikke en præference for ai-train, før jeg har taget særskilt stilling til den politik.
Jeg har ikke udgivet et Web Bot Auth-nøglekatalog, fordi Webstudiet ikke driver en udgående bot, som besøger andre hjemmesider under sin egen identitet. Scanneren viser derfor kontrollen som information i stedet for en fejl. Hvis jeg senere tilføjer en sådan agent, skal den både sende reelt signerede forespørgsler og have offentlige nøgler. Et ubrugt JWKS-dokument ville ikke give meningsfuld godkendelse.
Opdagelse af protokoller
| Kontrol | Hvad scanneren forventer | Hvornår det er relevant |
|---|---|---|
| MCP Server Card | JSON på /.well-known/mcp/server-card.json med HTTP 200, serverInfo.name, serverInfo.version, et transportendpoint og serverens reelle funktioner. | En hjemmeside, der driver en MCP-server, som skal kunne findes. |
| Agent Skills | JSON på /.well-known/agent-skills/index.json med $schema sat til discovery-skemaet i version 0.2.0. Hver skill-post skal have et name med små bogstaver og bindestreger, en type på skill-md eller archive, en description, artefaktets url og en SHA-256-digest. | En hjemmeside, der udgiver genbrugelige instruktioner eller skill-pakker til agenter. |
| WebMCP | Sidens JavaScript kalder navigator.modelContext.registerTool() ved indlæsning. Hvert værktøj har navn, beskrivelse, input som JSON Schema og en funktion, der udfører handlingen, og bør afregistreres med en AbortController, når det ikke længere skal bruges. Scanneren registrerer API’et i en rigtig browser. | Interaktive hjemmesider, der vil stille eksisterende browserhandlinger til rådighed som agentværktøjer. |
| API Catalog | /.well-known/api-catalog svarer med HTTP 200 og Content-Type: application/linkset+json. Poster i linkset identificerer hvert API med et anchor og relationer som service-desc og service-doc. | Tjenester med et eller flere offentlige API’er. |
| OAuth discovery | OIDC-metadata på /.well-known/openid-configuration eller metadata om OAuth-autoriseringsserveren på /.well-known/oauth-authorization-server, herunder issuer, autoriseringsendpoint, tokenendpoint, JWKS-URI og understøttede grant- og svartypper. | API’er eller applikationer, der bruger OAuth eller OpenID Connect. |
| OAuth Protected Resource | JSON på /.well-known/oauth-protected-resource med identifikatoren for den beskyttede ressource og URL’erne til dens autoriseringsservere. Understøttede scopes kan også angives; et 401-svar kan pege på dokumentet via WWW-Authenticate. | Et API eller en MCP-ressource, der er beskyttet med OAuth. |
Auth.md | /auth.md returnerer Markdown med en H1, der indeholder auth.md. Dokumentet beskriver målgruppen af agenter, endpoints til registrering eller oprettelse, understøttede metoder og brugen af adgangsoplysninger. Findes OAuth-metadata, bør dokumentet forbinde til dem og beskrive registrering via agent_auth. | Tjenester, hvor agenter kan registrere sig eller få adgangsoplysninger. |
| ARD | /.well-known/ai-catalog.json returnerer JSON med Access-Control-Allow-Origin: *, en specVersion samt et vist værtsnavn og en stabil værtsidentifikator. Kataloget har mindst én post med en identifikator i formen urn:air:<fqdn>:<namespace>:<name>, et vist navn, medietype, præcis én af url eller data samt to til fem repræsentative forespørgsler. | Tjenester, der har brug for ét katalog over MCP-servere, A2A-agenter, skills eller API-værktøjer. |
| A2A Agent Card | Den aktuelle brugerdefinerede scanning tester også /.well-known/agent-card.json. Kortet skal have navn, version, beskrivelse, understøttede tjenestegrænseflader, funktioner og beskrevne skills. | En tjeneste, der implementerer kommunikation mellem agenter. |
Dokumenterne skal beskrive fungerende tjenester. Et tomt MCP-kort, et opdigtet API-katalog eller et OAuth-dokument uden en fungerende autoriseringsserver kan måske løfte en score, men gør hjemmesiden mindre pålidelig for agenter og kan skabe sikkerhedsrisici.
På Webstudiet udgiver jeg et API-katalog, der er forbundet til den fungerende URL-analyse og dens OpenAPI-dokument, et Agent Skills-indeks med en genereret SHA-256-digest, et MCP Server Card og discovery-dokumenter, som forklarer, at den nuværende offentlige adgang er anonym og ikke kræver adgangsoplysninger. Det står direkte i Auth.md i stedet for at foregive, at hjemmesiden udsteder OAuth-tokens.
Jeg har gjort URL-analysen tilgængelig via MCP
Det mest nyttige protokolarbejde var ikke discovery-filerne. Jeg har bygget et rigtigt MCP-endpoint til Webstudiets URL-analyse på /api/mcp. Det stiller værktøjet analyze_url til rådighed. En MCP-kompatibel agent kan sende en offentlig HTTP- eller HTTPS-URL gennem den samme analyse som en besøgende og få scoren sammen med beståede kontroller, advarsler og fejl.
MCP Server Card på /.well-known/mcp/server-card.json fortæller agenter, hvor endpointet findes, og hvilken funktion det stiller til rådighed. Jeg registrerer også tre WebMCP-værktøjer i browseren: ét til kontekst om hjemmesiden, ét til URL-analyse og ét til kontaktvejledning. Derfor giver MCP og WebMCP mening på denne hjemmeside: De forbinder agenter med et fungerende værktøj i stedet for kun at eksistere for at bestå en scanner.
Jeg har ikke tilføjet et A2A Agent Card, fordi Webstudiet ikke driver en selvstændig A2A-tjeneste. ARD var anderledes, fordi det kunne beskrive funktioner, der allerede fandtes. Derfor tilføjede jeg /.well-known/ai-catalog.json med poster til URL-analysens MCP Server Card, den offentlige OpenAPI-beskrivelse og Webstudiet Site Context-skillen. Hver post har en stabil urn:air-identifikator, sin egen medietype, præcis én URL og tre repræsentative forespørgsler. Manifestet lukker det pointgivende ARD-hul uden at opfinde en tjeneste.
Handel
| Kontrol | Hvad scanneren forventer | Hvornår det er relevant |
|---|---|---|
| x402 | En beskyttet API-rute svarer med HTTP 402 og maskinlæsbare x402-betalingskrav, understøttet af en konfigureret betalingsformidler og modtager-wallet. | API’er, der sælger forbrugsmålt adgang eller adgang per forespørgsel. |
| MPP | /openapi.json beskriver funktioner med betaling via x-payment-info, herunder intent som charge eller session, en understøttet betalings-method som tempo, stripe, lightning eller card samt amount. | API’er, der implementerer Machine Payment Protocol. |
| UCP | JSON på /.well-known/ucp med protocol_version, services, capabilities og endpoints. Der skal være adgang til de specifikationer og skemaer, dokumentet henviser til. | Webshops, der implementerer Universal Commerce Protocol. |
| ACP | JSON på /.well-known/acp.json med protokolnavnet acp og version, en absolut URL til API’ets base, mindst én transporttype og mindst én tjenestefunktion. | Webshops, der implementerer Agentic Commerce Protocol. |
Jeg har ikke implementeret nogen af handelsprotokollerne på Webstudiet, fordi hjemmesiden ikke er en automatiseret webshop, og URL-analysen ikke sælges per forespørgsel. Scanneren markerer med rette kontrollerne som neutrale på en hjemmeside uden handel. En almindelig virksomhedshjemmeside bør ikke tilføje betalingsendpoints alene for at opnå en score; de hører hjemme i systemer, der sikkert kan give tilbud, sælge, godkende og gennemføre transaktionen.
Sådan skal en agent readiness-score læses
Jeg går stadig efter 100%, fordi øvelsen afslører svage antagelser og halvfærdige integrationer. Men jeg læser 100% som “alt relevant er implementeret ordentligt” og ikke som “alle tænkelige protokoller findes”. På en offentlig indholds- eller servicehjemmeside er det praktiske udgangspunkt en gyldig robots.txt, et aktuelt sitemap, brugbar HTML, en udtrykkelig politik for crawlere og – når den kan vedligeholdes korrekt – Markdown-indholdsforhandling. Link-headere hjælper kun, når der findes en reel opdagelsesressource at linke til.
MCP, A2A, Agent Skills, WebMCP, API-kataloger, OAuth-metadata, Auth.md, ARD, DNS-AID og agentbaseret handel er signaler om reelle funktioner. Implementér dem, når funktionen findes eller bevidst er ved at blive bygget. En manglende valgfri protokol er ikke automatisk en fejl, og et dokument uden en fungerende tjeneste er værre end slet ikke at udgive dokumentet.
Webstudiets URL-analyse har sine egne bredere kontroller af agentparathed for signaler som llms.txt, Markdown-endpoints, crawlerregler, maskinlæsbare formater, discovery-headere, MCP, A2A, skills, DNS-AID, NLWeb, WebMCP og schema maps. Den er ikke en kopi af isitagentready.com, så resultater og beståelseskrav kan ikke sammenlignes punkt for punkt.
Hvad du ikke skal gøre
Undgå at gøre AI-parathed til endnu et mønster for tyndt indhold. Opret ikke doorway-sider for hver AI-promptvariant. Skjul ikke indhold for mennesker, som kun maskiner kan se. Markér ikke falske ydelser, falske anmeldelser, lokationer du ikke dækker, eller produkter du ikke tilbyder. Massegenerér ikke sider, bare fordi AI-værktøjer gør det billigt. Den slags bevæger sig mod mønstre, som er dækket af Googles spam-politikker.
God AI-parathed gør den rigtige hjemmeside tydeligere. Dårlig AI-parathed skaber flere svage URL’er, mere tvetydighed og større risiko.
En tjekliste
- Sørg for, at vigtige sider kan gennemgås og indekseres, har interne links og kan vises med et brugbart uddrag, hvor synlighed er ønsket.
- Hold ydelses-, produkt-, lokations-, pris-, kontakt- og policyoplysninger synlige som almindelig tekst.
- Brug overskrifter, links, metadata, canonicals og sprogalternativer konsistent.
- Tilføj kun strukturerede data, hvor de matcher den synlige side.
- Gennemgå
robots.txt, meta robots, kontrol af uddrag, CDN-botkontrol og serverens logfiler. - Tilføj
llms.txt, adresser med Markdown, feeds, API-kataloger eller standardiserede filer til at opdage indhold, når de faktisk bliver vedligeholdt. - Beskyt formularer, bookingforløb, betalingsforløb, administrationsområder og dyre dynamiske URL’er mod misbrug.
- Overvåg bottrafik, fejlede forespørgsler, ændringer i søgerobotternes aktivitet og kvaliteten af henvendelser efter ændringer.
- Tjek hjemmesiden igen efter ændringer i indhold, ruter, platform eller politikker.
Ofte stillede spørgsmål
Kræver det særlige strukturerede data eller ekstra filer at optræde i AI Overviews eller AI Mode?
Nej. Googles aktuelle vejledning siger, at de samme SEO-grundprincipper gælder uden ekstra tekniske krav eller særlige strukturerede data. Siden skal stadig være indekseret og kunne vises med et uddrag.
Er llms.txt et krav for at være agent-klar?
Nej. Det er en valgfri fil, der hjælper, når den er korrekt og vedligeholdt. En mindre servicehjemmeside kan nøjes med en kort version, mens et bookingsystem eller API-drevet projekt kan have gavn af mere detaljerede maskinlæsbare filer.
Kræver DNS-AID DNSSEC?
Ja, hvis kontrollen på isitagentready.com skal bestås: Scanneren forventer, at DNS-AID-svaret er godkendt med DNSSEC. Det aktuelle Internet-Draft om DNS-AID bruger “bør” frem for et ubetinget “skal” til signering af almindelige discovery-poster, mens TLSA-poster skal være signeret. Overholdelse af scannerens krav og overholdelse af selve protokollen er derfor beslægtede, men ikke helt det samme.
Skal alle hjemmesider have MCP, OAuth, ARD og discovery til handel?
Nej. De kontroller beskriver funktioner, ikke et fælles minimumskrav. Udgiv dem kun, når hjemmesiden faktisk stiller den tilsvarende server, API, loginløsning, agentkatalog eller handelstransaktion til rådighed. En ren indholdsside kan være nyttig for agenter uden at foregive, at den driver disse tjenester.
Kan en agent bruge Webstudiets URL-analyse direkte?
Ja. Jeg stiller analysen til rådighed via et MCP-endpoint på /api/mcp. Værktøjet analyze_url modtager en offentlig URL og returnerer en kort oversigt over scoren, beståede kontroller, advarsler og fejl. Browserversionen registrerer også URL-analysen som et WebMCP-værktøj, hvor det eksperimentelle API er tilgængeligt.
Bør indhold skjules for mennesker, men vises for søgerobotter eller agenter?
Nej. Den tilgang skaber mere tvetydighed og risiko i stedet for klarhed, og den bevæger sig mod mønstre, der er dækket af Googles spam-politikker. Indhold skal være synligt som almindelig tekst for både mennesker og maskiner.
Hvad er forskellen på robots.txt-regler og regler for AI-søgerobotter?
robots.txt og meta robots styrer primært søgeindeksering og uddrag. Særskilte regler som Google-Extended styrer visse former for AI-træning eller brug uden for Search, og andre søgerobotter kan have deres egne identifikationer og regler.
Hvorfor kræver formularer og bookingforløb ekstra beskyttelse, når en hjemmeside bliver klar til agenter?
At læse en side er forbundet med lav risiko, men det er det ikke at indsende en formular, booke en tid eller udløse en betaling. De forløb kræver stadig validering, CSRF-beskyttelse, begrænsning af forespørgsler og beskyttelse mod misbrug, så parathed aldrig bliver til åben automatiseret adgang.
Parathed betyder klarhed med grænser
For de fleste hjemmesider er agent- og AI-parathed værd at arbejde med, men kun med grænser. Du vil gerne have, at relevante systemer forstår ydelser, artikler, produkter, lokation, kontaktmuligheder og troværdighedssignaler. Du vil ikke have, at enhver automatiseret klient scraper alt, indsender formularer frit, belaster dynamiske URL’er eller udvisker grænsen mellem offentligt indhold og interne forretningsprocesser.
Svaret er det samme som ved god teknisk SEO: Gør hjemmesiden klar, struktureret, hurtig, sikker og tilgængelig for søgemaskiner, og vær tydelig om, hvad der er offentligt.
Denne guide er trin 6 i Teknisk SEO-guiden.
Brug Teknisk SEO URL-analyse til at kontrollere en offentlig side inden for de samme områder. Hvis hjemmesiden skal gennemgås og forbedres, kan du læse om implementering af teknisk SEO eller sende URL’en og problemet.