Republic / Artiklar /

Artikeln uppdaterad 2026-10-11.
Skriven av Christofer Sandin.

Gör webben redo för agenter

Mer än hälften av trafiken på webben kommer inte längre från människor. I juni rapporterade Cloudflare att 57 procent av förfrågningarna till ett urval av sajterna i deras nätverk kom från automatiserade bottar. Enligt Cloudflares vd är det framför allt AI-agenterna som driver ökningen – agenter som läser, jämför och allt oftare gör saker åt andra, även om många bottar fortfarande mest gör fuffens.

För ett par år sedan skrev vi att Google brukar kallas webbens viktigaste blinda besökare. Nu har den besökaren fått sällskap. Häromdagen höll jag ett frukostseminarium om vad som händer när en AI-agent knackar på dörren till er webbplats – och vad det faktiskt är värt att göra åt det. 

Tre lager: läsbart, frågbart, handlingsbart

Arbetet går att dela upp i tre lager:

  • Läsbart. Agenten ska kunna hämta och förstå ert innehåll.
  • Frågbart. Era system ska kunna svara på frågor från Claude eller ChatGPT via MCP.
  • Handlingsbart. Agenten ska kunna använda funktionerna på er webbplats via WebMCP.

Strukturerad information är sen gammalt

Runt millennieskiftet hette argumentet sökmotorer, runt 2010 hette det tillgänglighet och nu heter det agenter. Arbetet är detsamma: märk upp innehållet så att en maskin förstår vad som är rubrik, text och navigering. Det mesta handlar om att göra det vi redan gör, och välstrukturerad HTML är fortfarande grunden.

Det finns tre saker som man hinner på en eftermiddag:

  1. Kolla robots.txt. Blockerar ni GPTBot och ClaudeBot? Vissa tjänster, som Cloudflare, blockerar AI-bottar som standard på nya domäner, så det kan ha skett utan att någon har fattat något beslut. Med Content-Signal kan ni dessutom svara på tre olika frågor: får ni synas i sökresultat, får ni användas som underlag i AI-svar och får modeller tränas på er? Det är signaler och inga lås, och ingen av de stora AI-aktörerna har ännu bekräftat att de följer dem – men poängen är att göra ett aktivt val.
  2. Lägg till en llms.txt. Detta är ett förslag och inte en standard, och det är oklart hur ofta det används. Men att skapa filen är i princip gratis – och tanken är att den fungerar ungefär som en kurerad innehållsförteckning för agenter.
  3. Skicka Markdown. Samma URL med .md på slutet, eller samma URL där klienten ber om Accept: text/markdown. Då får den ren text i stället för HTML.

robots.txt

Du kan göra många inställningar i robots.txt – så här ser inställningen vi pratar om ut:

93 procent mindre att läsa

Vi har testat det på oss själva. Startsidan på republic.se var vid testtillfället 127 129 byte som HTML och 8 445 byte som Markdown, alltså runt 93 procent mindre. HTML-versionen är till största delen div-taggar, script och CSS-klasser. Någonstans därinne finns texten.

Missförstå mig rätt, det är inte bandbredden som är vinsten. Agenterna är duktiga på att tolka HTML, och 93 procent färre byte betyder inte 93 procent lägre kostnad. Vinsten är kontextfönstret. Varje fråga mellan dig och agenten skickar med hela den konversation ni haft fram tills dess, så ju mindre brus som följer med, desto mer kapacitet finns kvar till det agenten faktiskt ska göra.

Det ger snabbare svar och tydligare resonemang. Dessutom minskar risken för hallucinationer, som ökar när informationen inte får plats i kontextfönstret – framför allt med enklare modeller som har mindre fönster.

Är det inte cloaking att visa något annat för agenter? Nej. Cloaking är när bottar får annat innehåll än människor. Här är innehållet detsamma, och det är klienten själv som ber om formatet. Det är samma mekanism som API:er har använt i snart 30 år.

Idag är det främst kodverktygen som ber om Markdown: Claude Code, Cursor och GitHub Copilot (även Microsofts Copilot-chatt gör det). Chattarna, som ChatGPT, Claude.ai, Gemini och Perplexity, hämtar fortfarande HTML, enligt acceptmarkdown.com. Är er målgrupp utvecklare som frågar sin kodagent om er dokumentation, så lönar det sig redan idag. För alla andra är kostnaden så låg att det ändå är värt det.

Hur skickar vi Markdown i praktiken?

Rent tekniskt finns det två sätt som kompletterar varandra. Vi kan erbjuda en adress med .md på slutet. Vi kan också låta klienten be om Markdown på den vanliga adressen genom att skicka Accept: text/markdown i sin förfrågan.

Det senare bygger på HTTP:s befintliga möjlighet att förhandla om format. Servern behöver då tala om för cachar att svaret kan variera med Accept, genom att skicka med Vary: Accept i svarets header. Innehållet ska vara likvärdigt i båda versionerna. HTTP Semantics beskriver hur den här förhandlingen fungerar.

På Republic har vi byggt plugins för Craft CMS och Statamic som genererar Markdown från webbplatsens innehåll. Craft-versionen används på republic.se och var det vi visade under seminariet.

Vi tillför alltså inte någon komplexitet, utan redaktören kan fortsätta uppdatera innehållet på ett ställe och systemet konverterar till det format som efterfrågas.

Saker som inte fungerar

Här är det lätt att bli lurad. Evil Martians gick igenom drygt trettio blogginlägg, repon och specförslag och utvärderade teknikerna de hittade. Åtta saknade stöd, bland annat:

  • Påhittade metataggar som ai-content-url och llms, liksom filer som /ai.txt.
  • HTML-kommentarer. De tas bort innan modellen ser texten.
  • ”AI-version”-knappar. Agenter klickar inte på knappar.
  • User-Agent-sniffning. Att visa bottar en egen version räknar Google som cloaking, så använd content negotiation i stället.
  • Viktig information enbart i JSON-LD. I ett test från SearchVIU missade ChatGPT, Claude, Perplexity, Gemini och Copilot produktdata som bara fanns där.

Ta alltså inte bort er strukturerade data – Google rekommenderar den fortfarande. Men lägg inte viktig information bara där.

Men varför föreslår då en massa människor de här teknikerna? Troligen så beror det på att någon hittar på en fil eller en metatagg, skriver ett blogginlägg, andra citerar inlägget och så är det igång – problemet är att ingen kontrollerar om något AI-system faktiskt drar nytta av tipset…

Det tråkigaste rådet är det bästa – skriv bättre text - men var noga med källor, citat och data.

Om ni bara tar med er en sak, ta med den här. En forskargrupp från Princeton och IIT Delhi testade nio strategier för att synas i AI-genererade svar. Det som fungerade var att berika den synliga texten. Källhänvisningar ökade synligheten med upp till 115 procent för sidor längre ner i resultaten, medan sidan högst upp i stället tappade runt 30 procent. Direkta citat gav runt 40 procent och statistik runt 30 procent.

Det bästa rådet för AI-optimering är det tråkigaste rådet i branschen: skriv bättre text.

Var konkret, citera källor och ta med siffror. Det är också det enda rådet som fungerar oavsett vilken standard som vinner.

Nästa del handlar om information och funktioner som finns i era system, men som kanske kräver att någon loggar in och letar fram dem manuellt.

MCP kopplar AI-verktyg till era system

Ett API är som en kontakt, och varje applikation har valt sin egen typ. Model Context Protocol, MCP, är adaptern: en kontakt på agentens sida som sedan kan kopplas till vad som helst på den andra – ert CMS, er e-handel eller ert bokningssystem. Protokollet skapades av Anthropic och förvaltas idag av Linux Foundation, med stöd från bland andra OpenAI, Google och Microsoft, så i praktiken har det blivit dagens standard.

Tänk er att ni arrangerar ett seminarium och vill få fram vilka deltagare som har angett att de har en allergi. Eller att ni varje vecka behöver sammanställa information om alla nya ordrar. Med rätt koppling kan en agent hämta underlaget genom ett avgränsat verktyg, med de behörigheter ni har valt att ge den.

För många av våra kunder är det interna arbetsflöden som är en naturlig början när det kommer till MCP. MCP går givetvis också att använda för tjänster som har externa användare. Jag kan till exempel använda MCP för att hämta hem mina mail från vår e-postklient. Det avgörande är vilken data och vilka funktioner man väljer att erbjuda, och vem som ska få använda dem.

Här behöver vi prata om det arbete som faktiskt ska bli enklare. Vilka uppgifter upprepas ofta? Vilket underlag tar tid att få fram? Ett tydligt ärende gör det lättare att avgöra om integrationen är värd att bygga.

WebMCP beskriver vad webbplatsen kan göra

Sedan har vi användaren som vill utföra ett ärende på själva webbplatsen. Hon vill jämföra produkter, fylla i ett formulär eller boka en tid.

En agent kan försöka att göra det genom att tolka sidans struktur eller ta skärmdumpar och klicka sig fram. Det fungerar i många fall, men kan bli skört när gränssnittet förändras eller nästa steg är otydligt. Och det tar framför allt lång tid, den gör samma jobb som en människa men sämre och långsammare.

WebMCP erbjuder en möjlighet att beskriva funktioner som verktyg (tools) direkt i webbsidan. Ett verktyg har ett namn, en beskrivning och ett schema för vilka uppgifter det tar emot. En agent med stöd för detta kan anropa funktionen genom webbläsaren. WebMCP-förslaget beskriver hur det är tänkt att fungera.

Under seminariet visade vi vår demobutik Republic Coffee Co. Där kan en agent använda butikens sökfunktion för att hämta information om espressomaskiner. Ett av verktygen heter search_products och anropar den sökfunktion som butiken redan använder.

await document.modelContext.registerTool({
  name: "search_products",
  description: "Sök bland produkter",
  inputSchema: {
    type: "object",
    properties: { query: { type: "string" } },
    required: ["query"]
  },
  annotations: { readOnlyHint: true },
  execute: async ({ query }) => await searchCatalogue(query)
});

Det är ganska konkret när man ser det. Kunden frågar om en viss maskin och agenten hämtar uppgifterna från webben utan att behöva leta runt. Kunden kan sedan be om en jämförelse och få hjälp att lägga en produkt i kundvagnen.

I vår demo erbjöd butiken tre verktyg till en anonym besökare och sexton efter inloggning. Det visar hur utbudet av verktyg kan följa situationen på sidan. Servern måste fortfarande kontrollera att användaren har rätt att utföra varje handling, precis på samma sätt som vi gör med en mänsklig besökare på webben.

Jag tycker att det här är den mest intressanta delen på sikt. Funktionerna som vi redan har byggt kan bli lättare att använda för den som tar hjälp av en agent. En produktfiltrering kan till exempel få en väg in där kunden beskriver sitt behov med egna ord.

Användaren behöver förstå och kunna styra handlingarna

När en agent kan göra något åt användaren blir återkopplingen viktig. Det behöver framgå vad som har hänt och om det finns något att ta ställning till för användaren.

En sökning, en ändrad leveransadress och en betalning har olika konsekvenser. Jag skulle därför utforma kontrollpunkterna efter handlingen. Att leta i en produktkatalog kan ske direkt. Innan en betalning genomförs behöver däremot kunden få se vad som ska köpas, det totala beloppet och aktivt bekräfta köpet för att känna tillit till systemet.

Vi måste även validera indata och kontrollera behörigheter på servern, precis som vid andra anrop. Tydliga verktyg gör avsikten lättare att beskriva, men ersätter inga av de kontrollerna.

Det anknyter till det jag skrev om i UX-design för AI. Användaren behöver få tillräcklig insyn för att kunna bedöma vad systemet gör och ingripa där det behövs. När agenten hjälper till i en webbshop är det fortfarande kundens pengar och kundens beslut och det som görs, görs direkt i kundens namn och med hennes befogenheter.

Ett rimligt första projekt

WebMCP är fortfarande ett utkast från W3C:s Web Machine Learning Community Group. Det är ingen W3C-standard än och stöd finns inte i alla webbläsare och agenter man använder. Jag skulle börja med en begränsad pilot och utvärdera ett konkret ärende.

Sökning och produktjämförelse är bra kandidater. I HUMAN Securitys observationer för april 2026 gick omkring 69,6 procent av agenttrafiken till produkt- och sökadresser, medan omkring 3,2 procent gick till kassa och betalning. Detta gäller trafiken på deras plattform och beskriver besök på olika typer av adresser, inte genomförda köp, men ger oss ändå en bra fingervisning om hur läget är just nu. HUMAN Securitys rapport ger mer information om mätningen.

Min bedömning är därför att det ofta finns mer att lära genom att göra produktinformationen lätt att hitta än vad en helt automatiserad kassa skulle ge. Vi kan pröva om agenten hittar rätt produkt och om svaren hjälper kunden att välja. Sedan kan vi ta nästa steg utifrån det vi ser.

Vad är värt att göra nu?

För en vanlig innehållswebbplats skulle jag börja med att kontrollera åtkomsten och gå igenom textens struktur. Finns informationen som kunderna frågar efter? Går den att hitta och läsa även utanför det visuella gränssnittet? Därefter är Markdown ett rimligt komplement när det går att skapa och underhålla från samma källa.

För den som har återkommande arbete i interna system kan en MCP-koppling vara värd att undersöka. För en webbshop eller portal med tydliga ärenden kan en liten WebMCP-pilot ge erfarenhet av hur människor och agenter använder funktionerna tillsammans. Har anställda redan stor vana vid att använda Claude, ChatGPT eller Gemini på vettiga sätt och skulle ha hjälp av att kunna hämta in information från webbplatsen också så är det ingen jätteinstats som krävs för att prova.

De här delarna kan utvecklas var för sig. Det viktiga är att välja ett behov som går att beskriva och följa upp.

Vi på Republic har börjat med vår egen webbplats och våra egna tester för att få erfarenhet av vad som faktiskt fungerar. Det ger oss bättre underlag när vi diskuterar nästa steg med våra kunder.

Vill ni kika på vad som vore rimligt för er webbplats eller era system tar vi gärna ett samtal. Vi kan börja med en fråga era kunder redan ställer, eller ett ärende som era kollegor gör varje vecka. Det brukar vara en bra början!

Avslutningsvis

Lagren måste tas i tur och ordning. Det finns ingen mening med WebMCP-verktyg på en sajt som blockerar bottarna i robots.txt.

  • Läsbart – gör det nu. Robots.txt, llms.txt och Markdown kostar lite och fungerar oavsett hur agentvågen utvecklas.
  • Frågbart – kan vara intressant redan idag. En MCP-server över era funktioner går att använda i Claude och, beroende på plan, i ChatGPT redan nu.
  • Handlingsbart – förbered under hösten. WebMCP är inte en given standard idag, men allt tyder på att det är den som kommer gälla den närmaste tiden.

Den blinda besökaren har alltså fått sällskap, och den nya besökaren vill inte bara läsa. Men grunden är densamma som den alltid har varit: tydlig struktur och bra text. Vill ni testa er egen sajt kan ni köra isitagentready.com och acceptmarkdown.com medan kaffet svalnar.

Vi har plugins för Craft CMS och Statamic som serverar Markdown och llms.txt direkt från CM-systemet. Här på republic.se kör vi dem redan idag. Vill ni veta var er sajt står, eller vilka MCP- och WebMCP-verktyg som är värda att bygga hos er, tar vi gärna ett möte.

Referenser och mer information

Relaterade artiklar