llms.txt och agentmanifest-sidor: En underhållen maskinriktad webbplatsindex

En llms.txt- och agentmanifest-sida är ett maskinriktat index som talar om för AI-system vad en webbplats representerar, vilka offentliga sidor som är auktoritativa och – när verksamheten stöder agentåtgärder – vilka verifierade kapaciteter och policyer som gäller. Det är en karta till underhållna källor, inte en ersättning för dessa källor och inte ett löfte om att någon specifik crawler kommer att använda den.

Dess kontrakt är identitet → omfattning → auktoritativa destinationer → valfria kapaciteter → begränsningar → färskhet. Filen lyckas när en maskin kan hämta den, tolka den utan att gissa, följa levande kanoniska URL:er och nå fakta som fortfarande överensstämmer med produktionsverkligheten.

Frågor den besvarar

Den primära frågan är: “Vilka delar av denna webbplats bör ett AI-system använda för att förstå organisationen, dess innehåll och dess stödda åtgärder?” Stödfrågor inkluderar:

• Vad är webbplatsens kanoniska namn, domän, syfte och målgrupp?
• Vilka produkt-, tjänst-, dokumentations-, pris-, policy- och supportsidor är auktoritativa?
• Vilka sidor bör prioriteras framför arkiv, kampanjsidor, parametrar eller duplicerade regionala versioner?
• Exponerar webbplatsen en faktisk agentkapacitet, eller endast mänskligt läsbar information?
• Var dokumenteras autentisering, hastighetsbegränsningar, datahantering, kommersiella villkor och support?
• Vilka påståenden är beskrivande vägledning snarare än åtkomstkontrollregler?
• Vem äger filen, vilken händelse utlöser en uppdatering och hur upptäcks avvikelse?

När denna posttyp ska användas

Använd denna typ när webbplatsen har tillräckligt med offentligt, varaktigt innehåll för att dra nytta av ett kurerat maskinriktat index och någon kan äga dess underhåll. Anledningen att publicera är att minska tvetydighet för hämtningssystem, inte att skapa ytterligare en URL för dess egen skull.

Förväxla inte vägledning med kontroll. robots.txt uttrycker crawler-åtkomstpreferenser; en XML-webbplatskarta hjälper crawlers att upptäcka URL:er; autentisering och auktorisering avgör om en åtgärd får utföras. llms.txt tillhandahåller kurerad kontext. En mening i llms.txt kan inte bevilja åtkomst, återkalla åtkomst, skydda en hemlighet eller åsidosätta villkoren på en destinationssida.

Bäst för dessa företagstyper

1. SaaS . Starkast passform eftersom ett programvaruföretag vanligtvis har distinkta produkt-, funktions-, pris-, integrations-, API-, säkerhets-, status- och dokumentationskällor. Indexet kan avgöra vilken sida som äger varje faktum, medan ett separat kapacitetsmanifest endast kan beskriva åtgärder som produkten verkligen stöder.
2. E-handel . Starkt när produkter, frakt, returer, tillgänglighet och kundservicepolicyer är offentliga och kanoniska. Håll föränderlig artikeldata i feedar eller API:er; använd indexet för att peka på dessa underhållna källor istället för att kopiera en katalog till Markdown.
3. Marknadsplatser . Värdefullt när köpar-, säljar-, leverantörs- och plattformspolicyer skiljer sig åt. Märk varje målgrupp och jurisdiktion så att en agent inte tillämpar säljarregler på en köpare eller antar plattformslager från en annons.
4. B2B-tjänster . Användbart för att förtydliga kapaciteter, branscher, tjänstegränser, bevis, upphandlingsmaterial och kontaktvägar. Omvandla inte en förhandlad omfattning eller kundspecifikt löfte till ett universellt maskinriktat påstående.
5. Byråer . Användbart när företaget underhåller många tjänste-, metod-, fallstudie- och expertissidor. Kundportaler, referenser, privata rapporter och interna spelböcker hålls utanför den offentliga filen.
6. Tillverkare och industriföretag . Användbart för att dirigera system till produktfamiljer, specifikationer, certifieringar, manualer, distributörer och säkerhetsdokument. Indexet får aldrig paraphransera säkerhetskritisk vägledning när det kontrollerade dokumentet är auktoriteten.

Små broschyrsajter med fem stabila sidor vinner föga på ytterligare en underhållen artefakt. Webbplatser utan en tydlig innehållsägare bör åtgärda kanonisering, navigering och källkvalitet innan de publicerar en fil som omedelbart kommer att bli inaktuell.

Sökintention

sökintention är det resultat som förväntas från en sökning. Denna typ har två målgrupper med olika intentioner. En maskin hämtar en förutsägbar rotväg och förväntar sig koncis Markdown, stabila rubriker, kanoniska länkar och inget dekorativt brus. En mänsklig sökare vill vanligtvis ha implementationsvägledning: “llms.txt-exempel”, “vad som ska ingå i llms.txt” eller “agentmanifest-format”. Den offentliga förklarande sidan kan besvara dessa frågor, medan den distribuerade /llms.txt förblir optimerad för maskinhämtning.

Själva filen är ingen målgruppslandningssida. Lägg inte till generiska definitioner, upprepade kategoritermer eller hundratals blogglänkar för att få den att “rankas”. Varje extra rad förbrukar uppmärksamhet och skapar ytterligare ett underhållsåtagande. Föredra tio avsiktliga länkar med tydliga beskrivningar framför en dumpning av tiotusen URL:er.

Eftersom konventioner och konsumentstöd kan ändras, ange vad din implementation baseras på och undvik att påstå universell användning. En lyckad hämtning bevisar endast att filen är tillgänglig och tolkningsbar; den bevisar inte att en specifik AI-produkt använder den för rankning, hämtning, träning eller citering.

Sidstruktur

Ordintervall är redigeringsbegränsningar, inte mål. Den distribuerade filen bör förbli tillräckligt koncis för att granskas rad för rad. Den mänskliga implementationsnoten kan vara längre, men den får inte kopieras in i maskinfilen.

En typisk kurerad fil är ungefär 200–700 ord. Längd är ingen kvalitetssignal: rätt storlek är det minsta index som etablerar identitet och dirigerar en konsument till underhållna källor utan att dölja viktiga distinktioner.

Obligatoriska element

Indexet måste vara tråkigt i bästa bemärkelse: förutsägbart, explicit och lätt att diffa. Placera kritisk tolkning före valfria länkar så att en partiell läsning inte producerar en felaktig slutsats.

Frontmatter

Följ frontmatterspecifikationen . På denna posttypspecifikation, använd entity = "post-type-llms-txt-page" och schemaType = "Article". På en mänsklig implementationssida för en specifik organisation, använd en stabil identitet som acme-ai-access-index, inte en kampanjfras eller ett datum.

Använd Article eftersom webbsidan förklarar implementationen. schemanärkning beskriver synligt innehåll; den omvandlar inte råtextfilen till ett erkänt agentprotokoll. Märk inte sidan som SoftwareApplication, Dataset eller HowTo om inte dess synliga innehåll och mall uppfyller relevanta krav oberoende.

Råfilen /llms.txt har normalt ingen frontmatter eftersom frontmatter inte får läcka ut i den publicerade utgången. Lagra dess operativa metadata i CMS:et, generatorkonfigurationen eller arkivposten: kanonisk domän, lokalomfattning, ägare, källsamling, generationsläge, senast verifierade datum, nästa granskningsregel, validatorresultat och varningsdestination. Om lokaliserade filer finns, dokumentera urvalsregeln och behåll en entydig kanonisk rotsvar.

Fullständigt exempel

Denna fiktiva fil demonstrerar ett koncist index för en SaaS-plattform. Dess URL:er, produkt och kapacitet är exempel; mönstret är specifikationen.

# Northstar Analytics

> Northstar Analytics är en rapporteringsplattform för driftteam. Detta index pekar på de offentliga sidor som definierar produkten, planerna, dokumentationen, policyerna och den stödda agentkapaciteten.

Åtkomstbehörigheter styrs av robots.txt, autentisering och policyerna som länkas nedan. Denna fil ger inte åtkomst eller tillstånd att återanvända innehåll.

## Produkt

- [Produktöversikt](https://www.northstar.example/product): Nuvarande produktomfattning och stödda rapporteringsflöden.
- [Planer och prissättning](https://www.northstar.example/pricing): Nuvarande offentliga planer, inkluderade funktioner och faktureringsvillkor.
- [Integrationer](https://www.northstar.example/integrations): Stödda datakällor och målsystem.

## Dokumentation

- [Dokumentationshem](https://docs.northstar.example/): Nuvarande användar- och administratörsdokumentation.
- [API-referens](https://docs.northstar.example/api/): Offentliga slutpunkter, scheman, autentisering, fel och hastighetsgränser.
- [Versionsanteckningar](https://docs.northstar.example/releases/): Daterade ändringar i produkt- och API-beteende.

## Förtroende och support

- [Säkerhet](https://www.northstar.example/security): Säkerhetsprogram och nuvarande försäkringsdokument.
- [Integritetspolicy](https://www.northstar.example/privacy): Databehandling, lagring och användarrättigheter.
- [Support](https://www.northstar.example/support): Stödda kontaktvägar och länk till tjänstestatus.

## Agentkapacitet

- [Rapportexportåtgärd](https://docs.northstar.example/agents/export-report): Autentiserat åtgärdskontrakt, accepterade indata, utdataformat, hastighetsgränser och felhantering. Tillgänglighet beror på användarens plan och roll.

## Valfritt

- [Forskningsbibliotek](https://www.northstar.example/research): Ursprungliga benchmarkrapporter med metoder och publiceringsdatum.

Verifierad 2026-08-27 av dokumentationsoperationsteamet. Genererad från det kanoniska offentliga resursregistret; validera efter produkt-, plan-, policy-, API- eller URL-ändringar.

Exemplet deklarerar endast en kapacitet eftersom ett verkligt, dokumenterat åtgärdskontrakt finns. Om produkten inte har någon stödd agentåtgärd, utelämna den sektionen. Anta aldrig en transaktionskapacitet från förekomsten av en sökruta, formulär eller odokumenterad slutpunkt.

För ett agentmanifest som lagras separat från /llms.txt, håll samma disciplin. Specificera ett versionshanterat format, kanonisk identifierare, produktionsslutpunkt, autentiseringsmetod, tillåtna operationer, indata- och utdataschema, hastighetsgränser, samtyckesgränser, feltillstånd och policy-URL:er. Validera det mot livesystemet. En syntaktiskt giltig deklaration som annonserar en inaktiverad åtgärd är fortfarande fel.

Designgalleri

Råfilen har lite visuell design avsiktligt. Gallerivarianter bör testa informationsarkitektur, skanningsordning, mobil läsbarhet av den mänskliga implementationssidan och operationella bevis – inte dekoration.

Kvalitetschecklista

Publicera endast när varje tillämpligt påstående är sant:

• Filen nås på den avsedda rot-URL:en utan autentisering, omdirigeringsloopar, samtyckesväggar eller en renderad applikationsskal.
• Svaret är läsbar oformaterad text eller Markdown, använder UTF-8 och är inte beroende av JavaScript för att visa sitt innehåll.
• H1 anger det kanoniska organisations- eller webbplatsnamnet, och beskrivningen anger syfte, målgrupp och omfattning utan slogans.
• Varje länkad URL är kanonisk, offentlig, indexerbar enligt policy, nåbar och ägd av organisationen eller tydligt märkt som extern.
• Länkbeskrivningar säger vilken auktoritet destinationen har; de upprepar inte generisk ankartext som “läs mer”.
• Primära produkt-, pris-, dokumentations-, policy- och supportkällor överensstämmer med indexet.
• Arki vsidor, sökresultat, spårningsparametrar, duplicerade språkversioner, kampanjsidor och lågvärdestaggsidor är exkluderade.
• Kapacitetspåståenden matchar ett levande, stödd, autentiserat kontrakt och inkluderar relevanta begränsningar.
• Ingen hemlighet, token, privat slutpunkt, personlig data, klientdokument, opublicerad roadmap-post eller säkerhetskänslig implementationsdetalj förekommer.
• Åtkomst-, behörighets-, licens- och policyspråk pekar på styrande källor och motsägs inte av indexet.
• Filen påstår inte garanterad rankning, citering, träningsuteslutning eller universellt konsumentstöd.
• Språk och regional omfattning är explicit där prissättning, policyer, tillgänglighet eller dokumentation skiljer sig åt.
• Ägaren, källregistret, generationsprocessen och valideringsmetoden är dokumenterade utanför eller i slutet av filen.
• Kontroller av brutna länkar, oväntade omdirigeringar, svarsstatus, innehållshash och obligatoriska sektioner körs efter relevanta distributioner.
• Verifieringsdatumet ändras endast efter att destinationer, beskrivningar, kapaciteter och policyer substantiellt kontrollerats.

Vanliga misstag

Att behandla filen som en webbplatskarta. En fullständig URL-inventering förstör prioritering och är svår att granska. Håll XML-webbplatskartor för upptäckt; kurera llms.txt kring auktoritativa källor och meningsfulla grupper.

Att behandla den som åtkomstkontroll. En begäran i Markdown är inget genomdrivningslager. Uttryck crawlregler i robots.txt, skydda privata resurser med autentisering och placera bindande krav i relevant policy och systemkontroller.

Att kopiera destinationsinnehåll till indexet. Upprepad prissättning, produktspecifikationer och policyer divergerar. Sammanfatta endast tillräckligt för att identifiera auktoritet, länka sedan till den underhållna källan.

Att publicera spekulativa kapaciteter. Ett odokumenterat formulär eller API-väg gör inte en webbplats agentredo. Deklarera endast produktionsstödda åtgärder med autentisering, scheman, begränsningar, fel och en ägare.

Att inkludera allt “för säkerhets skull.” Fler länkar skapar mer tvetydighet och fler felpunkter. Valfritt innehåll bör förtjäna inkludering genom att besvara ett sannolikt hämtningsbehov som primära sektioner inte täcker.

Att exponera privat material. Offentliga maskinläsbara filer är offentliga. Lista aldrig staging-värdar, interna API:er, referenser, kundexportfiler, opublicerade dokument eller säkerhetsdetaljer som inte avsiktligt godkänts för publicering.

Att generera utan styrning. Automation kan reproducera dålig källdata i hög hastighet. En generator behöver ett godkänt källregister, exkluderingsregler, deterministisk ordning, validering, granskningsägarskap och distributionsvarningar.

Att manuellt redigera en genererad fil. Nästa generation skriver över fixen. Korrigera källposten eller generatorn, generera om och registrera den materiella ändringen.

Att påstå icke-stödda resultat. “Detta garanterar AI-citeringar” omvandlar en osäker implementationskonvention till ett missvisande löfte. Rapportera tillgänglighets- och hämtningsbevis separat från synlighets- och citeringsresultat.

Att uppdatera datumet utan att kontrollera verkligheten. En ny tidsstämpel kan inte reparera en död dokumentations-URL, omdöpt plan eller inaktiverad åtgärd. Verifiering innebär att jämföra varje viktig deklaration med dess produktionskälla.

Internlänkning

Länka den mänskliga implementationssidan uppåt till SEO-posttyper när en författare måste skilja maskinindexet från en katalog, dokumentationssida eller policy. Länka från varje operationellt påstående till dess styrande källa: produktomfattning till produktsidan, aktuella priser till prissättning, beteende till dokumentation, behörigheter till åtkomstkontroller och skyldigheter till policy.

Råfilen bör använda kanoniska absoluta URL:er eftersom den kan hämtas utanför normal webbplatsnavigering. Föredra en auktoritativ destination per faktum. Om två sidor överlappar, lös ägarskap innan du listar båda; indexet bör exponera källhierarkin, inte befästa intern oenighet.

Använd korta, stabila sektionsnamn som Produkt, Dokumentation, Policyer och Agentkapaciteter. Håll språkvarianter i tydligt märkta grupper endast när de skiljer sig materiellt. Länka inte varje blogginlägg; välj hållbar forskning eller guider endast när de hjälper ett system att förstå webbplatsens ämne och bevis.

Inkommande länkar spelar roll operationellt också. Dokumentation, utvecklarportaler och AI-tillgänglighetsvägledning bör peka underhållare till implementationsposten, medan posten pekar på livefilen och validatorn. Det skapar en granskningsväg för människor utan att belamra maskinindexet.

Hur man mäter resultat

Mät filen som infrastruktur först och som en synlighetsinsats sekundärt. En citeringsökning kan inte tillskrivas llms.txt bara för att båda inträffade efter publicering.

Spåra fyra lager:

• Tillgänglighet: rot-URL:s svarsstatus, omdirigeringsbeteende, innehållstyp, kodning, latens, renderingsoberoende och drifttid.
• Integritet: tolkning framgång, obligatoriska sektioner, duplicerade URL:er, brutna länkar, omdirigeringsmål, kanonisk felmatchning, obehöriga domäner, exponerade hemligheter och innehållshash-ändringar.
• Färskhet: dagar sedan substantiell verifiering, destinationsändringar sedan verifiering, källregisters täckning, ägarebekräftelse och tid att reparera avvikelse.
• Resultat: serverlogg-hämtningar av identifierbara agenter där juridiskt och tekniskt lämpligt, besök på indexerade destinationer, AI-citeringar av föredragna kanoniska sidor och svarsnoggrannhet för spårade varumärkes- eller produktfrågor.

Etablera en baslinje före distribution: vilka URL:er som citeras, vilka fakta som är felaktigt angivna, om rotfilen finns och vilka crawlers som begär den. Annotera publicering och varje materiell uppdatering. Jämför observationsfönster som är tillräckligt långa för att undvika att läsa en enstaka hämtning eller citering som en trend, och behåll distinktionen mellan korrelation och kausalitet.

Testa feltillstånden direkt. Byt namn på en staging-kopia av en listad URL och bekräfta att validatorn fångar brottet. Ändra en kanonisk mappning och bekräfta att generatorn uppdaterar indexet. Inaktivera en kapacitet i en kontrollerad testmiljö och bekräfta att manifestkontrollen misslyckas. Dessa tester bevisar underhållssystemet, inte extern användning.

Använd hur vi mäter resultat för att separera teknisk tillgänglighet, maskinrepresentation, upptäckt, citering, engagemang och affärsresultat. I AmICited, granska livefilen under Agent Accessibility och använd Cockpit-rapporten för att observera citerade URL:er och AI-synlighet tillsammans med distributionsanteckningar. Det trovärdiga framgångspåståendet är “filen är giltig, aktuell och dirigerar system till avsedda källor”; eventuell förändring i nedströmssynlighet kräver separata bevis.

FAQ

Vanliga frågor