llms.txt- og agentmanifest-sider: Et vedligeholdt maskinrettet webstedsindeks

En llms.txt- og agentmanifest-side er et maskinrettet indeks, der fortæller AI-systemer, hvad et websted repræsenterer, hvilke offentlige sider der er autoritative, og—når virksomheden understøtter agenthandlinger—hvilke verificerede kapaciteter og politikker der gælder. Det er et kort til vedligeholdte kilder, ikke en erstatning for disse kilder og ikke et løfte om, at en bestemt crawler vil bruge det.

Dets kontrakt er identitet → omfang → autoritative destinationer → valgfri kapaciteter → begrænsninger → friskhed. Filen lykkes, når en maskine kan hente den, fortolke den uden at gætte, følge levende kanoniske URL’er og nå frem til fakta, der stadig matcher produktionsvirkeligheden.

Spørgsmål den besvarer

Det primære spørgsmål er: “Hvilke dele af dette websted bør et AI-system bruge til at forstå organisationen, dens indhold og dens understøttede handlinger?” Understøttende spørgsmål inkluderer:

• Hvad er webstedets kanoniske navn, domæne, formål og målgruppe?
• Hvilke produkt-, service-, dokumentations-, pris-, politik- og supportsider er autoritative?
• Hvilke sider bør foretrækkes frem for arkiver, kampagnesider, parametre eller duplikerede regionale versioner?
• Eksponerer webstedet en faktisk agentkapacitet eller kun menneskelæsbar information?
• Hvor er autentifikation, hastighedsbegrænsninger, datahåndtering, kommercielle vilkår og support dokumenteret?
• Hvilke udsagn er beskrivende vejledning frem for adgangskontrolregler?
• Hvem ejer filen, hvilken hændelse udløser en opdatering, og hvordan opdages afdrift?

Hvornår skal denne indlægstype bruges

Brug denne type, når webstedet har tilstrækkeligt offentligt, holdbart indhold til at drage fordel af et kurateret maskinrettet indeks, og nogen kan påtage sig vedligeholdelsen. Grunden til at udgive den er at reducere tvetydighed for hentningssystemer, ikke at skabe endnu en URL for sin egen skyld.

Forveksl ikke vejledning med kontrol. robots.txt udtrykker crawler-adgangspræferencer; et XML-sitemap hjælper crawlers med at opdage URL’er; autentifikation og autorisation afgør, om en handling må finde sted. llms.txt giver kurateret kontekst. En sætning i llms.txt kan ikke give adgang, tilbagekalde adgang, beskytte en hemmelighed eller tilsidesætte betingelserne på en destinationsside.

Bedst til disse forretningstyper

1. SaaS . Det stærkeste match, fordi en softwarevirksomhed normalt har distinkte produkt-, funktions-, pris-, integrations-, API-, sikkerheds-, status- og dokumentationskilder. Indekset kan afgøre, hvilken side der ejer hvert faktum, mens et separat kapacitetsmanifest kun kan beskrive handlinger, produktet reelt understøtter.
2. E-handel . Stærkt, når produkter, forsendelse, returnering, tilgængelighed og kundeservicepolitikker er offentlige og kanoniske. Hold volatile varedata i feeds eller API’er; brug indekset til at pege på disse vedligeholdte kilder frem for at kopiere en katalog ind i Markdown.
3. Markedspladser . Værdifuldt, når købers, sælgers, udbyders og platformspolitikker adskiller sig. Mærk hver målgruppe og jurisdiktion, så en agent ikke anvender sælgerregler på en køber eller udleder platformlager fra én annonce.
4. B2B-tjenester . Nyttigt til at afklare kapaciteter, brancher, servicegrænser, dokumentation, indkøbsmateriale og kontaktveje. Konvertér ikke et forhandlet omfang eller kundespecifikt løfte til et universelt maskinrettet krav.
5. Bureauer . Nyttigt, når virksomheden vedligeholder mange service-, metode-, case-study- og ekspertisesider. Klientportaler, legitimationsoplysninger, private rapporter og interne playbooks holdes ude af den offentlige fil.
6. Producenter og industrielle virksomheder . Nyttigt til at dirigere systemer til produktfamilier, specifikationer, certificeringer, manualer, distributører og sikkerhedsdokumenter. Indekset må aldrig omskrive sikkerhedskritiske instruktioner, når det kontrollerede dokument er autoriteten.

Små brochuresider med fem stabile sider kan have ringe gavn af endnu et vedligeholdt artefakt. Sider uden en tydelig indholdsejer bør fikse kanonisering, navigation og kildekvalitet, før de udgiver en fil, der straks vil drive.

Søgeintention

søgeintention er det resultat, der forventes fra en forespørgsel. Denne type har to målgrupper med forskellig intention. En maskine henter en forudsigelig rodsti og forventer kortfattet Markdown, stabile overskrifter, kanoniske links og ingen dekorativ støj. En menneskelig søger ønsker normalt implementeringsvejledning: “llms.txt eksempel,” “hvad hører til i llms.txt,” eller “agentmanifest format.” Den offentlige forklaringsside kan besvare disse spørgsmål, mens den deployerede /llms.txt forbliver optimeret til maskinhentning.

Filen i sig selv er ikke en keyword-landingsside. Tilføj ikke generiske definitioner, gentagne kategoriord eller hundredvis af bloglinks for at få den til at “rangere.” Hver ekstra linje forbruger opmærksomhed og skaber endnu en vedligeholdelsesforpligtelse. Foretræk ti bevidste links med klare beskrivelser frem for en dump af ti tusind URL’er.

Da konventioner og forbrugerunderstøttelse kan ændre sig, angiv hvad din implementering er baseret på, og undgå at påstå universel adoption. En succesfuld hentning beviser kun, at filen er tilgængelig og kan parses; det beviser ikke, at et bestemt AI-produkt bruger den til rangering, hentning, træning eller citering.

Sidestruktur

Ordbånd er redigeringsbegrænsninger, ikke mål. Den deployerede fil bør forblive kortfattet nok til at kunne revideres linje for linje. Den menneskerettede implementeringsnote kan være længere, men den må ikke kopieres ind i maskinfilen.

En typisk kurateret fil er cirka 200–700 ord. Længde er ikke et kvalitetssignal: den rigtige størrelse er det mindste indeks, der etablerer identitet og dirigerer en forbruger til vedligeholdte kilder uden at skjule vigtige skel.

Påkrævede elementer

Indekset skal være kedeligt i bedste forstand: forudsigeligt, eksplicit og let at diffe. Placer kritisk fortolkning før valgfrie links, så en delvis læsning ikke producerer en falsk konklusion.

Frontmatter

Følg frontmatter-specifikationen . På denne indlægstypespecifikation, brug entity = "post-type-llms-txt-page" og schemaType = "Article". På en menneskerettet implementationsside for en specifik organisation, brug en stabil identitet såsom acme-ai-access-index, ikke en kampagnefrase eller dato.

Brug Article, fordi websiden forklarer implementeringen. schema-markup beskriver synligt indhold; det gør ikke råtekstfilen til en anerkendt agentprotokol. Markér ikke siden som SoftwareApplication, Dataset eller HowTo, medmindre dens synlige indhold og skabelon opfylder de relevante krav uafhængigt.

Den rå /llms.txt-fil har normalt ingen frontmatter, fordi frontmatter ikke må lække ind i det publicerede output. Gem dens operationelle metadata i CMS’et, generator-konfigurationen eller repository-posten: kanonisk domæne, lokaleomfang, ejer, kildesamling, genereringstilstand, sidst verificeret dato, næste gennemgangsregel, validatorresultat og alarmdestination. Hvis der findes lokaliserede filer, dokumentér udvælgelsesreglen og behold én utvetydig kanonisk roddestination.

Fuldstændigt eksempel

Denne fiktive fil demonstrerer et kortfattet indeks for en SaaS-platform. Dens URL’er, produkt og kapacitet er eksempler; mønsteret er specifikationen.

# Northstar Analytics

> Northstar Analytics er en rapporteringsplatform for operationelle teams. Dette indeks peger på de offentlige sider, der definerer produktet, planer, dokumentation, politikker og understøttet agentkapacitet.

Adgangstilladelser styres af robots.txt, autentifikation og de politikker, der er linket til nedenfor. Denne fil giver ikke adgang eller tilladelse til at genbruge indhold.

## Produkt

- [Produktoversigt](https://www.northstar.example/product): Nuværende produktscope og understøttede rapporteringsarbejdsgange.
- [Planer og priser](https://www.northstar.example/pricing): Nuværende offentlige planer, inkluderede funktioner og faktureringsvilkår.
- [Integrationer](https://www.northstar.example/integrations): Understøttede datakilder og destinationssystemer.

## Dokumentation

- [Dokumentationsstartside](https://docs.northstar.example/): Nuværende bruger- og administrationsdokumentation.
- [API-reference](https://docs.northstar.example/api/): Offentlige endpoints, skemaer, autentifikation, fejl og hastighedsbegrænsninger.
- [Udgivelsesnoter](https://docs.northstar.example/releases/): Daterede ændringer i produkt- og API-adfærd.

## Tillid og support

- [Sikkerhed](https://www.northstar.example/security): Sikkerhedsprogram og nuværende assurancesdokumenter.
- [Privatlivspolitik](https://www.northstar.example/privacy): Databehandling, opbevaring og brugerrettigheder.
- [Support](https://www.northstar.example/support): Understøttede kontaktveje og servicestatus-link.

## Agentkapacitet

- [Rapporteksporteringshandling](https://docs.northstar.example/agents/export-report): Autentificeret handlingskontrakt, accepterede input, outputformat, hastighedsbegrænsninger og fejlhåndtering. Tilgængelighed afhænger af brugerens plan og rolle.

## Valgfrit

- [Forskningsbibliotek](https://www.northstar.example/research): Originale benchmark-rapporter med metoder og udgivelsesdatoer.

Verificeret 2026-08-27 af Dokumentationsoperationsteamet. Genereret fra det kanoniske offentlige ressource-register; valider efter produkt-, plan-, politik-, API- eller URL-ændringer.

Eksemplet erklærer kun én kapacitet, fordi en reel, dokumenteret handlingskontrakt findes. Hvis produktet ikke har nogen understøttet agenthandling, udelad den sektion. Slut aldrig en transaktionskapacitet ud fra tilstedeværelsen af en søgeboks, formular eller udokumenteret endpoint.

For et agentmanifest gemt separat fra /llms.txt, hold samme disciplin. Specificér et versionsbestemt format, kanonisk identifikator, produktions-endpoint, autentifikationsmetode, tilladte operationer, input- og output-skema, hastighedsbegrænsninger, samtykkegrænser, fejltilstande og politik-URL’er. Valider det mod det levende system. En syntaktisk gyldig erklæring, der reklamerer for en deaktiveret handling, er stadig forkert.

Designgalleri

Råfilen har lidt visuelt design med vilje. Gallerivarianter bør teste informationsarkitektur, scanningsrækkefølge, mobil læsbarhed af den menneskerettede implementationsside og operationel dokumentation—ikke dekoration.

Kvalitetstjekliste

Udgiv kun når hver relevant udsagn er sand:

• Filen opløses på den tilsigtede rod-URL uden autentifikation, redirect-løkker, samtykkemure eller en renderet applikationsskal.
• Responsen er læsbar ren tekst eller Markdown, bruger UTF-8 og afhænger ikke af JavaScript for at afsløre sit indhold.
• H1 giver det kanoniske organisations- eller webstedsnavn, og beskrivelsen angiver formål, målgruppe og omfang uden slogans.
• Hver linkede URL er kanonisk, offentlig, indekserbar efter politik, tilgængelig og ejet af organisationen eller tydeligt mærket som ekstern.
• Linkbeskrivelser siger hvilken autoritet destinationen har; de gentager ikke generisk ankertekst såsom “lær mere.”
• Primære produkt-, pris-, dokumentations-, politik- og supportkilder stemmer overens med indekset.
• Arkivsider, søgeresultater, sporingsparametre, duplikerede lokaliteter, kampagnesider og lavværdi-tagsider er udelukket.
• Kapacitetspåstande matcher en levende, understøttet, autentificeret kontrakt og inkluderer de relevante begrænsninger.
• Ingen hemmelighed, token, privat endpoint, personlige data, klientdokument, ikke-udgivet roadmap-element eller sikkerhedsfølsom implementeringsdetalje fremgår.
• Adgangs-, tilladelses-, licens- og politiksprog peger på kontrollerende kilder og modsiges ikke af indekset.
• Filen påstår ikke garanteret rangering, citering, træningseksklusion eller universel forbrugerunderstøttelse.
• Lokale og regionale omfang er eksplicitte, hvor priser, politikker, tilgængelighed eller dokumentation adskiller sig.
• Ejer, kilde-register, genereringsproces og valideringsmetode er registreret uden for eller i slutningen af filen.
• Kontrol af brudte links, uventede redirects, responsstatus, indholdshash og påkrævede sektioner køres efter relevante deployment’er.
• Verifikationsdatoen ændres kun, efter destinationer, beskrivelser, kapaciteter og politikker er substantielt kontrolleret.

Almindelige fejl

At behandle filen som et sitemap. En komplet URL-opgørelse ødelægger prioritering og er svær at gennemgå. Behold XML-sitemaps til opdagelse; kuratér llms.txt omkring autoritative kilder og meningsfulde grupper.

At behandle den som adgangskontrol. En anmodning i Markdown er ikke et håndhævelseslag. Udtryk crawl-regler i robots.txt, beskyt private ressourcer med autentifikation, og placer bindende krav i de relevante politik- og systemkontroller.

At kopiere destinationsindhold ind i indekset. Gentagne priser, produktspecifikationer og politikker divergerer. Opsummer kun nok til at identificere autoritet, og link derefter til den vedligeholdte kilde.

At offentliggøre spekulative kapaciteter. En udokumenteret formular eller API-rute gør ikke et websted agentklar. Erklær kun produktionsunderstøttede handlinger med autentifikation, skemaer, begrænsninger, fejl og en ejer.

At inkludere alt “bare for en sikkerheds skyld.” Flere links skaber mere tvetydighed og flere fejlpunkter. Valgfrit indhold bør fortjene inklusion ved at besvare et sandsynligt hentningsbehov, som primære sektioner ikke dækker.

At eksponere privat materiale. Offentlige maskinlæsbare filer er offentlige. List aldrig staging-værter, interne API’er, legitimationsoplysninger, kundeeksport, ikke-udgivne dokumenter eller sikkerhedsdetaljer, der ikke var bevidst godkendt til offentliggørelse.

At generere uden styring. Automatisering kan reproducere dårlige kildedata i høj hastighed. En generator har brug for et godkendt kilde-register, eksklusionsregler, deterministisk sortering, validering, gennemgangsejerskab og deployment-advarsler.

At håndredigere en genereret fil. Næste generation overskriver rettelsen. Korrigér kilde-posten eller generatoren, regenerér, og registrér den materielle ændring.

At påstå ikke-understøttede resultater. “Dette garanterer AI-citater” gør en usikker implementeringskonvention til et vildledende løfte. Rapportér tilgængeligheds- og hentningsdokumentation separat fra synligheds- og citeringsresultater.

At opdatere datoen uden at kontrollere virkeligheden. Et nyt tidsstempel kan ikke reparere en død dokumentations-URL, omdøbt plan eller deaktiveret handling. Verifikation betyder at sammenligne hver vigtig erklæring med dens produktionskilde.

Intern linking

Link den menneskerettede implementationsside opad til SEO-indlægstyper , når en forfatter skal skelne maskinindekset fra en fortegnelse, dokumentationsside eller politik. Link fra hvert operationelt krav til dets kontrollerende kilde: produktscope til produktsiden, aktuelle priser til priser, adfærd til dokumentation, tilladelser til adgangskontrol og forpligtelser til politik.

Råfilen bør bruge kanoniske absolutte URL’er, fordi den kan hentes uden for normal webstedsnavigation. Foretræk én autoritativ destination per faktum. Hvis to sider overlapper, afgør ejerskab før begge listes; indekset bør eksponere kildernes hierarki, ikke forevige intern uenighed.

Brug korte, stabile sektionsnavne såsom Produkt, Dokumentation, Politikker og Agentkapaciteter. Hold lokalitetsvarianter i tydeligt mærkede grupper, kun når de adskiller sig væsentligt. Link ikke til hvert blogindlæg; vælg holdbar forskning eller vejledninger kun, når de hjælper et system med at forstå webstedets emne og dokumentation.

Indgående links betyder også noget operationelt. Dokumentation, udviklerportaler og AI-tilgængelighedsvejledning bør pege vedligeholdere til implementationsposten, mens posten peger til den levende fil og validator. Det skaber en gennemgangssti for mennesker uden at fylde maskinindekset.

Hvordan man måler resultater

Mål filen som infrastruktur først og som synligheds-input derefter. En stigning i citater kan ikke tilskrives llms.txt blot fordi begge skete efter offentliggørelse.

Følg fire lag:

• Tilgængelighed: rod-URL responsstatus, redirect-adfærd, indholdstype, kodning, latenstid, render-uafhængighed og oppetid.
• Integritet: parse-succes, påkrævede sektioner, duplikerede URL’er, brudte links, redirect-mål, kanonisk uoverensstemmelse, uautoriserede domæner, eksponerede hemmeligheder og indholdshash-ændringer.
• Friskhed: dage siden substantiel verifikation, destinationsændringer siden verifikation, kilde-register-dækning, ejer-bekræftelse og tid til at reparere afdrift.
• Resultater: server-log-hentninger af identificerbare agenter hvor juridisk og teknisk passende, besøg på indekserede destinationer, AI-citater af foretrukne kanoniske sider og svar-nøjagtighed for sporede brand- eller produktspørgsmål.

Etablér en baseline før deployment: hvilke URL’er citeres, hvilke fakta er fejlagtigt angivet, om rodfilen eksisterer, og hvilke crawlers der anmoder om den. Annotér offentliggørelse og hver materiel opdatering. Sammenlign observationsvinduer, der er lange nok til at undgå at læse én hentning eller ét citat som en trend, og bevar skellet mellem korrelation og kausalitet.

Test fejltilstandene direkte. Omdøb en staging-kopi af en listet URL og bekræft at validatoren fanger bruddet. Ændr en kanonisk mapping og bekræft at generatoren opdaterer indekset. Deaktiver en kapacitet i et kontrolleret testmiljø og bekræft at manifest-tjekket fejler. Disse tests beviser vedligeholdelsessystemet, ikke ekstern adoption.

Brug hvordan vi måler resultater til at adskille teknisk tilgængelighed, maskinrepræsentation, opdagelse, citering, engagement og forretningsresultater. I AmICited, gennemgå den levende fil under Agent Accessibility og brug Cockpit-rapporten til at observere citerede URL’er og AI-synlighed sammen med deployment-annotationer. Det troværdige succesudsagn er “filen er gyldig, aktuel og dirigerer systemer til de tilsigtede kilder”; enhver downstream synlighedsændring kræver separat dokumentation.

FAQ

Ofte stillede spørgsmål