Sådan gør du dit multi-location website agent-ready i 2026

Noget har ændret sig i måden, folk finder virksomheder på. Ikke et gradvist skifte, men et strukturelt. ChatGPT alene leverer nu mere end 5 milliarder besøg om måneden til 900 millioner ugentligt aktive brugere, og Geminis månedlige trafik voksede 647 procent til 2 milliarder besøg i året, der sluttede i marts 2026. Flere og flere af disse besøg involverer lokale søgninger: “Find en tandlæge med gode anmeldelser i nærheden af Kongens Nytorv” eller “Hvilken bilforhandler i Aarhus har de bedste serviceanmeldelser?” Inde i ChatGPT udløser prompts med lokal hensigt nu en live websøgning i 59 procent af tilfældene, hvilket gør spørgsmålet “hvad returnerer dit website, når en agent spørger?” til en direkte drivkraft for kundetrafikken til dine butikker.

AI-agenten browser ikke dit website på samme måde som et menneske. Den kalder protokoller, læser struktureret data og aktiverer værktøjer. Hvis dit site ikke kan besvare de forespørgsler, anbefaler agenten en anden, der kan.

Det er, hvad “agent-ready” betyder: dit website er bygget, så AI-systemer kan opdage det, forstå det og interagere med det uden menneskelig vejledning.

For multi-location brands er der endnu mere på spil end for andre. Du optimerer ikke én side eller én lokation. Du gør hundredvis eller tusindvis af lokationer synlige for en ny type digitale besøgende, der ikke bruger browsere på samme måde som mennesker.

Hvordan adskiller AI-agenters discovery sig fra traditionel søgning?

Søgemaskiner crawler HTML, følger links og opbygger et indeks. AI-agenter gør noget fundamentalt anderledes. De:

• Læser struktureret data som JSON-LD og Markdown i stedet for at parse rodet HTML
• Kalder protokoller for at finde ud af, hvad et website tilbyder, før de interagerer med det
• Aktiverer værktøjer for at udføre handlinger (booking, sammenligning, søgning) frem for blot at læse sider
• Forbinder sig til tjenester gennem standardiserede protokoller som MCP for at tilgå live virksomhedsdata

Det skifte betyder, at spillereglerne er ændret. Et website, der rangerer godt på Google, kan være fuldstændig usynligt for en AI-agent, hvis det ikke implementerer de discovery-standarder, agenterne læner sig op ad.

Den gode nyhed: standarderne findes, de er åbne, og du kan implementere dem i dag.

Hvad er agent readiness-stakken?

Agent readiness er ikke ét enkelt punkt på en tjekliste. Det er en stak af komplementære standarder, der hver især håndterer et aspekt af, hvordan AI-agenter interagerer med dit website.

Lag 1: Content Access

Kan AI-agenter læse dit indhold effektivt?

robots.txt med eksplicitte AI bot-regler er udgangspunktet. De største AI-crawlere annoncerer alle deres egne user agents, og det enkleste og bedst understøttede du kan gøre i dag er at navngive dem eksplicit og beslutte, om de skal have Allow eller Disallow:

User-agent: GPTBot
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Google-Extended
Allow: /

User-agent: Applebot-Extended
Allow: /

For de fleste multi-location brands er det rigtige valg at tillade dem alle. Du vil gerne citeres. Reglerne er standard RFC 9309-direktiver, som alle de navngivne crawlere læser, så det lag står på veletableret grund.

Content Signals er et nyere og mere granuleret lag oven på robots.txt. Content Signals-udkastet (et IETF Internet-Draft af Michael Tremante og Leah Romm hos Cloudflare) tilføjer Content-Signal-direktiver, der erklærer, hvordan AI må bruge dit indhold, ikke kun om det må hente det:

User-agent: *
Content-Signal: ai-train=yes, search=yes, ai-input=yes
Allow: /

Det fortæller AI-crawlere: I må bruge vores indhold til modeltræning (ai-train), til at opbygge søgeindekser (search) og til at generere AI-drevne svar (ai-input). Hver User-Agent-blok får sit eget Content-Signal, så du kan sætte forskellige tilladelser for forskellige crawlere.

Forslaget er lovende og værd at holde øje med. Det er stadig et tidligt IETF-udkast, så udbredelsen er ujævn: Cloudflare har bygget det ind i den robots.txt, de håndterer for sites på deres netværk, mens de store AI-laboratorier endnu ikke offentligt har bekræftet, om de læser Content-Signal-direktivet. At tilføje det i dag handler mere om at erklære din hensigt end at håndhæve den, hvilket er en helt rimelig ting at gøre.

En lille bemærkning: indtil slutningen af maj 2026 udløste Content-Signal-linjer en kosmetisk advarsel “robots.txt is not valid” i PageSpeed Insights, fordi validatoren kun kendte direktiverne i den oprindelige robots.txt-RFC. Googles validator er siden blevet opdateret, og fra den 26. maj 2026 vises advarslen ikke længere. Nogle ældre SEO-værktøjer flagger den måske stadig, men direktivet er sikkert alligevel: RFC 9309 fortæller crawlere, at de skal ignorere linjer, de ikke genkender, så hverken din søgeplacering eller AI-adgang påvirkes.

Markdown content negotiation giver AI-agenter rent, struktureret indhold i stedet for rå HTML. Når en agent sender Accept: text/markdown i sin HTTP-forespørgsel, returnerer serveren Markdown for den samme kanoniske URL, mens browsere fortsat modtager HTML. Markdown’en kan genereres on the fly på edge’en (Cloudflares tilgang) eller forhåndsbygges som en sibling .md-fil ved origin (det mønster, Vercel, Sentry, Sanity og dette site bruger). Uanset hvad er der én URL for indholdet, og svaret varierer på Accept-headeren.

Hvorfor agenter bekymrer sig om det. Argumentet for Markdown handler mest om økonomi. Hvert token, en agent læser eller genererer, koster compute, og det oversættes direkte til latency, API-forbrug og båndbredde. En simpel Markdown-overskrift koster omkring tre tokens, mens den tilsvarende HTML-markering bruger tolv til femten, ifølge Cloudflares lancering af “Markdown for Agents”. På tværs af en hel side er ren HTML typisk to til tre gange dyrere end det samme indhold i Markdown, og virkelighedens HTML med CSS, JavaScript og tracking kan vokse til otte til ti gange mere, ifølge Beam.ais HTML-vs-Markdown-analyse. Cloudflare målte deres eget annonceringsindlæg til 16.180 tokens som HTML og 3.150 som Markdown, en reduktion på 80 %. Vercel rapporterede en lignende historie fra båndbreddevinklen: HTML-versionen af en side på deres site vejede omkring 500 KB, mens Markdown-versionen lå på 3 KB, en reduktion på 99 % i payload oven i token-besparelserne. De to tal måler forskellige ting (tokens vs bytes) og kommer fra forskellige leverandører med forskellige metoder, men de peger på den samme historie. Til frontier-modellens priser løber forskellen hurtigt op over en session, og den sparede compute og båndbredde kan i stedet bruges på mere ræsonnement, flere tool calls eller simpelthen en billigere forespørgsel.

Besparelserne kaskaderer også ud over omkostningerne. Færre tokens betyder mere plads i agentens kontekstvindue til den faktiske opgave, hurtigere time-to-first-token, fordi der er mindre at hente og parse, og et renere signal-støj-forhold til retrieval (ingen navigation, annoncer, modaler eller layout-wrappere, der konkurrerer med indholdet). Markdown er også det format, LLM’er i vid udstrækning er trænet på (GitHub READMEs, teknisk dokumentation, genererede outputs), så det er typisk deres mest flydende input som udgangspunkt. Cloudflare sender endda en x-markdown-tokens-response-header sammen med det konverterede output, dokumenteret i Cloudflare Fundamentals, så agenten kan tjekke token-tallet på forhånd og afgøre, om dokumentet passer ind i dens kontekstvindue eller skal chunkes.

Hvem understøtter det i dag. Ifølge acceptmarkdown.com-statustrackeren begyndte client-side-understøttelsen i kodningsværktøjer og breder sig nu ud i mere generelle arbejdsflader. Anthropics Claude sender Accept: text/markdown fra Claude Code og fra Cowork i Claude desktop-appen (verificeret i vores egen request-log-test på skrivetidspunktet), hvilket betyder, at Markdown content negotiation ikke længere kun er en kodningsagent-bekymring: Cowork er research-, drafting- og browsing-fladen i desktop-appen, så ethvert forretningsdokument, konkurrentopslag eller artikel, en Claude-bruger beder Cowork om at hente, går gennem den vej. Den almindelige chat-oplevelse i desktop-appen og på claude.ai sender ikke headeren endnu. Cursor, OpenCode og OpenClaw sender den også. OpenAIs Codex CLI understøtter den delvist: den henter først den kanoniske URL som HTML og leder så efter et <link rel="alternate" type="text/markdown"> i head’en, før den anmoder om sibling Markdown-filen. De forbrugerrettede flader (ChatGPT browse, Gemini, Perplexity, Copilot browse) sender generelt ikke headeren i dag, så indtil videre er det mest meningsfuldt at forstå dette som en optimering for kodningsagenter og Claudes arbejdsflader, hvor forbrugeragenter sandsynligvis følger efter. Værd selv at tjekke, før du forlader dig på en bestemt klient, da de adfærdsmønstre ændrer sig hurtigt.

Hvem skubber på. Det er en multi-vendor-konvention, ikke et enkelt firmas push. Der er ikke noget formelt IETF-arbejde, blot et mønster, der bygger ovenpå eksisterende standarder (RFC 7231 content negotiation og text/markdown-mediatypen fra RFC 7763). På infrastruktur- og platformssiden konverterer Cloudflares “Markdown for Agents” HTML til Markdown på edge’en for sites på Pro-, Business- og Enterprise-planer, mens Vercel leverer content-negotiated Markdown på deres egne properties med en Next.js-implementeringsguide. Origin-baserede implementeringer akkumuleres også på tværs af CMS- og dev-tools-økosystemet: Sentry serverer Markdown via Accept-headers, Sanity har udgivet en field guide til at servere indhold til agenter, DeployHQ dokumenterer mønstret på tværs af Laravel, Express, Django og statiske sites, og Roots har lanceret et WordPress-plugin, der håndterer content negotiation på kanoniske URL’er. Der er også en Next.js GitHub-diskussion, hvor framework-brugere arbejder på, hvordan de skal koble det ind, og implementeringsguides, der eksplicit dækker den non-Cloudflare-vej. På klientsiden drev Anthropic og Anysphere udbredelsen først gennem Claude Code og Cursor. Ingen enkelt virksomhed kontrollerer konventionen, og bredden af stacks, der adopterer den uafhængigt af hinanden, er det, der gør distributionen reel.

Hvor Google står. Googles John Mueller har været offentligt skeptisk over for “Markdown for bots” generelt og kaldte idéen “a stupid idea” på Bluesky og spurgte på Reddit, hvorfor agenter skulle have brug for en side, ingen bruger ser, eftersom LLM’er altid har trænet på og parset HTML. Googles officielle AI optimization guide tager samme linje og lister AI-specifikke Markdown-filer blandt de ting, du ikke behøver at tilføje, for at dine sider kan optræde på deres generative AI-flader. Microsofts Fabrice Canel har givet udtryk for en lignende bekymring om at skabe separate indholdsversioner til crawlere og peger på ekstra crawl-belastning og risikoen for, at versioner, der ikke vendes mod brugeren, bliver forsømt og kommer ud af synk med originalen. Det er dog værd at læse deres indvendinger nøje, fordi de retter sig mod et beslægtet, men anderledes mønster: at servere helt anden Markdown på en separat URL baseret på user-agent-sniffing. Ægte content negotiation, hvor den samme URL serverer enten HTML eller Markdown for det samme underliggende indhold baseret på Accept-headeren, er en længe etableret HTTP-mekanisme (på samme måde som billeder kan serveres som WebP eller JPEG afhængigt af, hvad klienten understøtter). Værd at huske, at Googles vejledning handler om at optræde i deres egne AI-produkter, mens den token-økonomiske case ovenfor handler om effektivitet for enhver agent, der allerede har valgt at læse dit indhold. Skillelinjen mellem de to har betydning.

Trade-offs at være opmærksom på. Den mest diskuterede risiko er en variant af cloaking. SEO-forskeren David McSweeney har vist, at Cloudflares edge-implementering videresender Accept: text/markdown-headeren til origin og dermed reelt fortæller origin, at “denne forespørgsel kommer fra en AI-agent.” I hans proof-of-concept returnerede origin én side til mennesker og en helt anden side til agenter, og Cloudflare konverterede pligtopfyldende den agent-rettede HTML til Markdown. Den foreslåede mitigering er, at edge-udbydere stripper headeren, før de henter fra origin, men det er ikke standard endnu. Den samme egenskab åbner en prompt injection-vektor for agenter, der udfører handlinger på vegne af en bruger, eftersom brugeren aldrig ser, hvad agenten læser. Andre ting at veje: Vary: Accept muliggør korrekt cachning af begge repræsentationer, men kan sænke hit rates og komplicere CDN-adfærd, og edge-konverteret Markdown er generisk, så for rigt designede marketing- eller produktsider læser en origin-skrevet Markdown-version typisk bedre end det, der overlever en automatisk HTML-til-MD-rundtur.

llms.txt er en Markdown-fil i roden af dit site, der giver et kurateret overblik over dit website for AI-systemer. Konventionen blev foreslået i 2024 og er blevet adopteret af nogle sites, men ingen større AI-crawler honorerer den officielt som et discovery-signal endnu. Googles AI optimization guide grupperer eksplicit llms.txt blandt de ting, du ikke behøver at lave, med den begrundelse, at AI-systemer kan parse almindelig HTML udmærket. Samtidig har Googles egen Lighthouse-auditor tilføjet en kategori “Agentic Browsing” i v13.2 (april 2026) og gjort den til en del af standardkonfigurationen i v13.3 ugen efter. Kategorien tjekker eksplicit for en llms.txt i din domæne-rod, så billedet er blandet. Kategorien er bevidst ikke scoret på en vægtet 0 til 100-skala, mens standarderne modnes, hvilket gør llms.txt-tjekket informativt snarere end et rangeringssignal. Med Markdown content negotiation på plads modtager agenter allerede rent Markdown for enhver side, de henter, hvilket fjerner det meste af den oprindelige use case. llms.txt er nok mest nyttig for sites med tæt teknisk dokumentation, hvor et kurateret kort hjælper agenter med at finde det rigtige indgangspunkt. For multi-location brands, hvor hver lokation og hvert blogindlæg er uafhængigt synligt gennem sitemap’et og Markdown content negotiation, er udbyttet mindre.

Lag 2: Struktureret data

Kan AI-agenter forstå, hvad dit indhold betyder?

JSON-LD struktureret data giver AI-agenter eksplicitte, standardiserede beskrivelser af din virksomhed. For multi-location brands fortæller LocalBusiness-skema på hver lokationsside agenterne dit navn, adresse, telefonnummer, åbningstider, bedømmelser og services i et format, de kan behandle uden at gætte.

Tilføj FAQPage-, Product-, Article- og BreadcrumbList-skemaer, hvor det giver mening. Jo mere struktureret data du leverer, desto mere sikkert kan en AI-agent citere og anbefale dig.

Lag 3: Protocol Discovery

Kan AI-agenter finde dine værktøjer og funktioner?

Det er det nyeste lag og det, der udvikler sig hurtigst. Tre fremvoksende standarder håndterer forskellige aspekter af tool discovery:

MCP Server Cards (SEP-2127, foreslået af MCP-teamet ledet af David Soria Parra hos Anthropic) lader dig annoncere din Model Context Protocol-server på /.well-known/mcp-server-card. Hvis din virksomhed har en MCP-server, fortæller det AI-klienter præcis, hvordan de finder og forbinder sig til den.

{
  "$schema": "https://static.modelcontextprotocol.io/schemas/v1/server-card.schema.json",
  "name": "com.example/my-location-mcp",
  "version": "1.0.0",
  "description": "Query location data across all business locations"
}

Agent Skills (Cloudflare RFC) publicerer et katalog over dit sites funktioner på /.well-known/skills/index.json. Hver skill er en Markdown-fil, der beskriver, hvad agenter kan gøre med dit site, fra at søge i din vidensbase til at sammenligne dine produkter med konkurrenternes.

WebMCP (en W3C Community Group-specifikation redigeret af ingeniører fra Google og Microsoft) registrerer værktøjer via navigator.modelContext.registerTool(), som browser-baserede AI-agenter kan aktivere direkte. I stedet for at en agent skal gætte, at der findes en “Request Demo”-knap et sted på din side, registrerer du et request_demo-værktøj med en beskrivelse, parametre og en callback til udførelse.

navigator.modelContext.registerTool({
  name: "request_demo",
  description: "Book a personalized demo of the platform",
  execute: async () => {
    window.location.href = "/requestademo/";
    return { navigated: "/requestademo/" };
  }
});

Google beskriver WebMCP som “en direkte kommunikationskanal”, der “fjerner tvetydighed og muliggør hurtigere, mere robuste agentworkflows.”

Lag 4: Access Control

Hvilke agenter må hvad?

Content Signals (dækket i Lag 1) er designet til at håndtere tilladelserne til, hvordan indhold må bruges. Du kan tilkendegive, at søgeindeksering er tilladt, mens træning ikke er, eller tillade alt. Udbredelsen er stadig tidlig, så betragt det som en erklæring af dine præferencer snarere end garanteret håndhævelse.

AI bot-regler i robots.txt lader dig eksplicit tillade eller blokere specifikke crawlere: GPTBot, ClaudeBot, PerplexityBot, Google-Extended, Applebot-Extended og andre. For de fleste brands giver det mening at tillade alle AI-crawlere. Du vil gerne være synlig.

Hvorfor får multi-location brands størst udbytte af agent readiness?

En enkelt kaffebar kan måske findes alene via Google Maps. Men et brand med 500 lokationer på tværs af 12 lande står over for en fundamentalt anderledes udfordring. Hver lokation skal være individuelt synlig for AI-agenter, og data på tværs af alle lokationer skal være konsistente, strukturerede og maskinlæsbare.

Skala forstærker fordelen. Hvis én konkurrents lokation er agent-ready, og din ikke er, mister du netop den anbefaling. Hvis du har 500 agent-ready lokationer, og din konkurrent har nul, vinder du 500 anbefalinger.

Lokale forespørgsler bliver agentiske først. “Find en … i nærheden af …” er en af de mest almindelige forespørgsler, folk stiller AI-assistenter. Det er de forespørgsler, der direkte driver kundetrafik i butikkerne, og de kræver struktureret lokationsdata, anmeldelser og virksomhedsinformation, som agenter kan tilgå programmatisk.

AI-agenter har brug for realtidsdata. En MCP-server kan levere live anmeldelsesscorer, aktuelle åbningstider og opdaterede servicelister. Statiske HTML-sider kan ikke. Brands, der forbinder deres live data via MCP, giver agenterne de friskeste og mest nøjagtige informationer, hvilket gør det mere sandsynligt, at agenterne anbefaler dem.

Implementeringsprioritering for multi-location brands

Ikke alle standarder er lige vigtige i dag. Her er rækkefølgen, der giver dig mest synlighed for mindst indsats:

Start her

1. Opdater robots.txt med eksplicitte AI bot-regler (GPTBot, ClaudeBot, PerplexityBot, Google-Extended, Applebot-Extended)
2. Verificér JSON-LD struktureret data på alle sidetyper (LocalBusiness for lokationer, Product, FAQPage, Article)

Næste skridt

3. Implementér Markdown content negotiation, så AI-agenter får rent indhold

Avanceret

4. Udgiv et MCP Server Card, hvis du har en MCP-server
5. Implementér WebMCP-værktøjer for nøglehandlinger (demoforespørgsler, lokationssøgning, produktnavigation)
6. Udgiv Agent Skills, der lister dit sites funktioner

Hvis du har tid og ressourcer, kan dette hjælpe

7. Tilføj llms.txt og llms-full.txt kun hvis du vedligeholder tæt teknisk dokumentation. For de fleste multi-location brands kan du springe det over. Udbredelsen er ujævn blandt de største AI-crawlere, Googles AI optimization guide siger eksplicit, at du ikke behøver det, og Markdown content negotiation dækker allerede det samme felt for enhver side, en agent henter. Det kuraterede overblik-mønster er mest nyttigt, når agenter har brug for hjælp til at finde det rigtige indgangspunkt i dyb udviklerdokumentation, ikke når hver lokation og hvert blogindlæg allerede er uafhængigt synligt gennem dit sitemap.
8. Tilføj Content Signals-direktiver til robots.txt for at erklære, hvordan AI må bruge dit indhold. IETF-udkastet bevæger sig fremad og er værd at følge. Udbredelsen blandt de største AI-crawlere er stadig tidlig, men direktivet er sikkert at tilføje (crawlere ignorerer direktiver, de ikke genkender), og en pæn måde at sætte sin pæl i jorden til senere.

Test alt

Kør dit site gennem isitagentready.com, Cloudflares officielle agent readiness-scanner (lanceret i april 2026), for at se, hvilke tjek der består. Den evaluerer den samme fire-lags stak, som denne artikel er organiseret omkring (Discoverability, Content Accessibility, Bot Access Control og Capabilities), og markerer præcis, hvad der mangler.

Hvis du vil have en second opinion, er GEO Metrics’ Agent Readiness Score også gratis og dækker de samme fire dimensioner, med en ekstra redaktionel akse for struktureret data, forfatterskab og andre AI-citationssignaler. Det er en nyttig krydskontrol, når du vil se, om dine scorer holder mod en anden metodik.

Derudover har Lighthouse tilføjet en ny kategori “Agentic Browsing” i v13.2 (april 2026), aktiveret som standard i v13.3, med audits for WebMCP-værktøjsregistrering, schemavaliditet, en llms.txt i din domæne-rod og nogle signaler for tilgængelighed for agenter. Kategorien scores bevidst ikke på en vægtet 0 til 100-skala (“standarderne for det agentiske web er stadig under udvikling”), så behandl den som en tjekliste snarere end et tal, der skal optimeres. Auditsne kører i Chrome DevTools, hvilket gør dem til et hurtigt supplement til de dedikerede agent readiness-scannere ovenfor.

Standarderne (maj 2026)

Disse standarder bevæger sig hurtigt. Sådan ser det ud lige nu:

Den fælles tråd: disse er alle åbne standarder, som store teknologivirksomheder står bag. Ingen af dem er bundet til én enkelt leverandør. Ved at implementere dem i dag bygger du på fundamenter, som hele branchen er på vej til at samles om.

Hvilke agent readiness-standarder er på vej?

Standarderne omkring agent readiness udvikler sig stadig hurtigt. Et par ting at holde øje med:

Agent Card (fra AI Card-projektet) sigter mod at være et protokol-agnostisk discovery-format på /.well-known/ai-catalog.json. Tænk på det som en telefonbog for AI-tjenester på et domæne.

Handelsprotokoller er gået fra “fremvoksende” til “leveret.” Den 11. januar 2026 lancerede Google Universal Commerce Protocol (UCP), en åben standard for agentisk handel udviklet sammen med Shopify, Etsy, Wayfair, Target og Walmart og støttet af over 20 andre, herunder Best Buy, The Home Depot, Macy’s, Adyen, Stripe, Visa, Mastercard, Flipkart og Zalando. UCP er eksplicit kompatibel med MCP, A2A og AP2, så den struktureret data- og protokol-indsats, der er dækket tidligere i artiklen, er genanvendelig snarere end engangsarbejde. Stripe og OpenAIs Agentic Commerce Protocol (ACP) dækker det samme problem fra betalingssiden, og x402 forbliver en mulighed for mikrobetalinger. Hvis du sælger online, er agentisk handel den næste implementeringsmilepæl efter discovery-stakken, ikke et “monitor og vent”-punkt.

Verificeret bot-autentificering bliver undersøgt, hvor AI-agenter kan dokumentere deres identitet og få forskellige adgangsniveauer. Det kan gøre det muligt at give verificerede agenter adgang til rigere data, mens ukendte bots begrænses.

Brand-agenter i Search: Google Business Agent

I januar 2026 lancerede Google Business Agent, en konfigurerbar virtuel sælger, som brands aktiverer fra Merchant Center, og som optræder direkte inde i Google Search. Ifølge Googles annoncering gik kvalificerede amerikanske retailere som Lowe’s, Michael’s, Poshmark og Reebok live med den indledende udrulning, mens retailer-specifik træning på egne data, relaterede produkttilbud og agentisk checkout er positioneret som efterfølgende funktioner. Trænings-, relaterede tilbuds- og checkout-funktionerne afhænger af Googles udrulningsplan, så tjek Merchant Center for, hvad der aktuelt er tilgængeligt på din konto, før du forpligter dig på specifikke datoer over for stakeholders.

Sammen med Business Agent introducerede Google dusinvis af nye Merchant Center-dataattributter designet til AI Mode-, Gemini- og Business Agent-flader. De attributter går videre end nøgleord og inkluderer svar på almindelige produktspørgsmål, kompatibelt tilbehør og substitutter.

For multi-location brands er implikationen ligetil. Den samme strukturerede data, FAQ-skema og live lokationsfeeds, du publicerer for agent readiness-stakken, fodrer den konversationsflade, hvor kunderne i stigende grad starter deres rejse. Hvis en konkurrent publicerer Merchant Center FAQ-attributter, og du ikke gør, er det mere sandsynligt, at den Business Agent, der besvarer en kundes spørgsmål, fremhæver deres brand frem for dit.

Hvordan implementerer du agent readiness på tværs af hundredvis af lokationer?

At implementere disse standarder for et enkelt website er ligetil. At gøre det på tværs af hundredvis eller tusindvis af lokationer er en helt anden udfordring. Hver lokation har brug for konsistent struktureret data, korrekte åbningstider, aktuelle anmeldelsesscorer og korrekt formateret skemamarkering. Når de data begynder at glide fra hinanden (og det gør de), får AI-agenter modstridende signaler og mister tilliden til dit brand.

Det er her, platforme til location management bliver essentielle. PinMeTo’s PLACES AI håndterer struktureret data på tværs af 100+ listing-netværk og forbinder live lokationsdata til AI-assistenter gennem PinMeTo Location MCP og giver dermed agenterne et direkte, realtidsbaseret feed af dine virksomhedsoplysninger i stedet for forældet HTML.

Vil du have et dybere indblik i, hvordan AI-søgning omformer lokal discovery, kan du læse vores komplette GEO-guide til multi-location brands og vores ordbogsopslag om AI Overviews og Generative Engine Optimization.

Opdateringer

Det er et område, der bevæger sig hurtigt, så vi vender tilbage til indlægget, når standarderne lander. Seneste ændringer:

• 2026-05-27: Tilføjede en note om Lighthouses nye kategori “Agentic Browsing” (WebMCP, llms.txt, tilgængelighed for agenter, layoutstabilitet). Scoringen er bevidst ikke en vægtet 0 til 100-skala, mens standarderne modnes, så tjekkene er informative i dag. Tilføjet i llms.txt-afsnittet og i listen over testværktøjer.
• 2026-05-26: Googles PageSpeed Insights-validator genkender nu Content-Signal-direktivet, så det at tilføje Content Signals til robots.txt udløser ikke længere en advarsel om “robots.txt is not valid”. Afsnittet om indholdsadgang og implementeringstjeklisten er opdateret.
• 2026-05-22: Tilføjede kontekst om Google Business Agent og et FAQ-punkt om Universal Commerce Protocol (UCP) efter Googles annonceringer i januar 2026.

Ofte stillede spørgsmål

Hvordan tester jeg, om mit site er agent-ready?

Besøg isitagentready.com, Cloudflares officielle agent readiness-scanner, og indtast din URL. Scanneren tjekker alle aktuelle standarder og giver dig en pass/fail-rapport med konkrete anbefalinger. Hvis du vil have en second opinion, der dækker en ekstra redaktionel dimension, er GEO Metrics’ Agent Readiness Score også gratis og værd at køre ved siden af.

Vil implementering af agent readiness-standarder ødelægge min eksisterende SEO?

Nej. Agent readiness bygger oven på eksisterende SEO best practices. robots.txt, struktureret data og sitemaps er allerede en del af SEO. De nye standarder (Content Signals, MCP Server Cards, WebMCP) er additive. De ændrer ikke, hvordan søgemaskiner interagerer med dit site.

Har jeg brug for en udvikler for at implementere dette?

Det grundlæggende (robots.txt-regler, JSON-LD struktureret data, Content Signals-direktiver) kan klares af alle, der er fortrolige med at redigere tekst- og konfigurationsfiler. Markdown content negotiation er et enkelt klik, hvis dit site ligger bag Cloudflare Pro eller højere, men ellers kræver det en udvikler til enten at generere sibling .md-filer i build-processen eller sætte en origin rewrite op. WebMCP og MCP Server Cards kræver en vis viden om JavaScript og JSON. Ved enterprise-implementeringer på tværs af hundredvis af lokationer bør dit udviklingsteam eller din platformspartner håndtere det.

Hvad er Google Business Agent, og skal jeg gøre noget nyt for at imødekomme den?

Business Agent er en konfigurerbar virtuel sælger, som Google lancerede i januar 2026. Brands aktiverer den fra Merchant Center, og den optræder inde i Google Search, hvor den besvarer kundespørgsmål på brandets vegne. Kvalificerede amerikanske retailere som Lowe’s, Michael’s, Poshmark og Reebok var live ved lanceringen. For multi-location brands er det praktiske skridt at udfylde de nye Merchant Center-dataattributter, som Google rullede ud sammen med Business Agent (svar på almindelige produktspørgsmål, kompatibelt tilbehør, substitutter), fordi de attributter fodrer Business Agent, AI Mode og Gemini. Det agent readiness-arbejde, der er dækket i resten af denne guide (struktureret data, FAQ-skema, live lokationsfeeds), er det samme inputsæt, så det meste af indsatsen overføres direkte.

Hvad sker der, hvis disse standarder ændrer sig?

Det vil de. Sådan er det med nye specifikationer. Men kerneprincipperne (struktureret data, maskinlæsbart indhold, standardiseret discovery) er veletablerede. Eventuelle ændringer vil være iterative, ikke grundlæggende omskrivninger. At bygge på disse fundamenter nu betyder, at fremtidige opdateringer bliver inkrementelt arbejde, ikke en total genopbygning.

Er agent readiness kun relevant for websites, eller gælder det også for apps og andre platforme?

Standarderne her er web-fokuserede og designet til indhold, der leveres over HTTP. Mobilapps, stemmeassistenter og IoT-enheder har deres egne discovery-mekanismer. Når det er sagt, fungerer MCP som protokol på tværs af enhver klient, der understøtter den, så de data, du strukturerer til dit website, kan også betjene AI-agenter uden for webben, der forbinder sig via MCP-servere.

Hvordan passer Googles Universal Commerce Protocol (UCP) ind i agent readiness?

UCP er transaktionslaget oven på det discovery-lag, denne guide fokuserer på. Det er en åben standard, som Google lancerede i januar 2026 med Shopify, Etsy, Wayfair, Target og Walmart blandt medudviklerne, og den er kompatibel med MCP, A2A og AP2. Hvis du allerede publicerer struktureret produkt- og lokationsdata, eksponerer værktøjer gennem MCP og følger agent readiness-stakken, står du godt rustet til at koble dig på UCP. Ved lanceringen oplyste Google, at UCP ville drive checkout for kvalificerede produktopslag i AI Mode og Gemini for amerikanske retailere, med international udrulning til at følge efter. Tjek Googles aktuelle udrulningsstatus, før du går ud fra, at det er tilgængeligt på dit marked.

Leder du efter måder at gøre dine lokationer synlige for AI-agenter? Book en demo og se, hvordan PLACES AI hjælper multi-location brands med at forblive synlige på tværs af både traditionel søgning og AI-drevet discovery.

Kilder og referencer

• Content Signals for Automated Processing - IETF Internet-Draft af Michael Tremante og Leah Romm om direktiver for AI-indholdstilladelser
• SEP-2127: MCP Server Cards - Model Context Protocol-forslag til at annoncere MCP-servere via well-known URIs
• WebMCP Specification - W3C Web Machine Learning Community Group-specifikation for browser-baserede AI-agentværktøjer
• WebMCP: An API for the Agentic Web - Chrome for Developers-overblik over WebMCP og dens rolle i agentworkflows
• Agent Skills Discovery RFC - Cloudflares foreslåede standard for at publicere website-funktioner til AI-agenter
• Introducing the Model Context Protocol - Anthropics annoncering af MCP som en åben standard for AI-værktøjsintegration
• Introducing Markdown for Agents - Cloudflares primære annoncering, inklusive 16.180-vs-3.150 token-benchmark og sammenligningen af omkostninger pr. element
• Markdown for Agents (Cloudflare Fundamentals docs) - Officiel dokumentation, inklusive x-markdown-tokens-response-headeren
• HTML vs Markdown for AI Agents (Beam.ai) - Sammenligning, der viser ren HTML til 2-3x og virkelighedens HTML til 8-10x token-omkostningen af tilsvarende Markdown
• Cloudflare Markdown for Agents: Complete Technical Guide (ALM Corp) - Sekundær teknisk gennemgang af 80 %-token-reduktionsbenchmark og SEO-implikationer
• Making agent-friendly pages with content negotiation (Vercel) - Vercels primære indlæg om at servere Markdown via Accept-headers, inklusive 500 KB-til-3 KB-payload-reduktionen på deres eget site
• Make your documentation readable by AI agents (Vercel) - Vercel-vidensbase-guide til content negotiation for dokumentationssites
• Allow pages to be served in markdown for AI Agents (Next.js Discussion #90579) - Community-diskussion om implementering af Markdown content negotiation i Next.js
• How to serve content to agents: a field guide (Sanity) - Sanitys guide til at levere indhold direkte til AI-agenter
• Content Negotiation for AI Agents: Why Sentry Serves Markdown Over HTML - Case study om Sentrys implementering af Markdown content negotiation
• How to Make Your Documentation AI-Friendly (DeployHQ) - Implementeringsguide, der dækker content negotiation på tværs af Laravel, Express, Django og statiske sites
• Serve Your WordPress Posts as Markdown (Roots) - Roots’ gennemgang af at servere Markdown fra WordPress via Accept-headeren
• post-content-to-markdown WordPress plugin (Roots, GitHub) - Open source-WordPress-plugin, der serverer indhold som Markdown via Accept-headers og .md-URL’er
• Implementing Markdown for Agents Without Cloudflare (Pragmate) - Implementeringsguide, der bevidst er bygget op om den non-Cloudflare-vej
• AI Statistics and Trends - Brugsdata om væksten og udbredelsen af AI-chatbots (2024-2025), bevaret som historisk kontekst
• Generative AI Statistics for 2026 (Similarweb) - Aktuelle tal for månedlige besøg og ugentligt aktive brugere for ChatGPT og andre førende chatbots
• AI Search Market Share 2026: ChatGPT, Gemini & Perplexity Stats (Stackmatix) - Geminis vækst på 647 procent år over år og markedsandelsforskydninger frem til marts 2026
• New Data Study: What Queries Is ChatGPT Using Behind The Scenes? (Nectiv) - Nectivs analyse af mere end 8.500 ChatGPT-prompts fra oktober 2025, primærkilden bag andelen på 59 procent, hvor prompts med lokal hensigt udløser en live websøgning inde i ChatGPT
• Is Your Site Agent Ready? - Cloudflares officielle agent readiness-scanner til test af dit site mod aktuelle standarder
• Introducing the Agent Readiness Score (Cloudflare) - Cloudflares annoncering af isitagentready.com-scanneren (april 2026), inklusive den fire-dimensionelle scoringsmodel
• Agent Readiness Score (GEO Metrics) - Uafhængig gratis scanner, der lægger redaktionelle og AI-citationssignaler oven på den samme fire-lags tekniske stak
• Model Context Protocol - Officiel MCP-dokumentation og -specifikation
• robots.txt RFC 9309 - IETF-standard for robots exclusion-protokollen
• New tech and tools for retailers to succeed in an agentic shopping era - Google Ads & Commerce-bloggen, 11. januar 2026, om UCP, Business Agent, nye Merchant Center-attributter og Direct Offers
• Universal Commerce Protocol - Officiel UCP-specifikation og partnerkatalog
• Business Agent in Merchant Center - Google Merchant Center-dokumentation for aktivering og konfiguration af Business Agent
• Agent Payments Protocol (AP2) - Google Clouds åbne protokol for agent-ledte betalinger, refereret af UCP
• Agent2Agent Protocol (A2A) - Åben protokol for interoperabilitet mellem AI-agenter, refereret af UCP
• Agentic checkout for the holiday shopping season - Googles tidligere annoncering om agentisk shopping, som UCP bygger videre på
• acceptmarkdown.com Status - Community-vedligeholdt tracker over hvilke AI-klienter, der sender Accept: text/markdown
• AI features and your website (Google Search Central) - Googles officielle AI optimization guide, inklusive Mythbusting-sektionen, der eksplicit siger, at du ikke behøver llms.txt, AI-tekstfiler eller Markdown for at optræde på deres generative AI-søgeflader
• Google’s Mueller Calls Markdown-For-Bots Idea ‘A Stupid Idea’ - Search Engine Journals dækning af John Muellers offentlige modstand mod bot-specifikke Markdown-sider
• Google & Bing don’t recommend separate markdown pages for LLMs - Search Engine Land om den bredere branchedebat, inklusive user-agent-sniffing- og cloaking-bekymringerne
• HTTP Content Negotiation (RFC 7231) - Standardgrundlag for Accept-header-forhandling mellem klient og server
• text/markdown media type (RFC 7763) - IETF-registrering af text/markdown-mediatypen, der bruges i content negotiation