llms.txt- og agentmanifest-sider: Et vedlikeholdt maskinlesbart nettsideindeks

En llms.txt- og agentmanifestside er et maskinrettet indeks som forteller AI-systemer hva et nettsted representerer, hvilke offentlige sider som er autoritative, og – når virksomheten støtter agenthandlinger – hvilke verifiserte kapabiliteter og retningslinjer som gjelder. Det er et kart til vedlikeholdte kilder, ikke en erstatning for disse kildene, og ikke et løfte om at noen bestemt kraveller vil bruke det.

Dets kontrakt er identitet → omfang → autoritative destinasjoner → valgfrie kapabiliteter → begrensninger → ferskhet. Filen lykkes når en maskin kan hente den, tolke den uten gjetting, følge levende kanoniske URL-er, og komme frem til fakta som fortsatt samsvarer med produksjonsvirkeligheten.

Spørsmål den besvarer

Hovedspørsmålet er: “Hvilke deler av dette nettstedet bør et AI-system bruke for å forstå organisasjonen, innholdet og dens støttede handlinger?” Støttende spørsmål inkluderer:

• Hva er nettstedets kanoniske navn, domene, formål og målgruppe?
• Hvilke produkt-, tjeneste-, dokumentasjons-, pris-, retningslinje- og supportsider er autoritative?
• Hvilke sider bør foretrekkes fremfor arkiver, kampanjesider, parametere eller dupliserte regionale versjoner?
• Eksponerer nettstedet en faktisk agentkapabilitet, eller kun menneskelesbar informasjon?
• Hvor er autentisering, ratebegrensninger, datahåndtering, kommersielle vilkår og support dokumentert?
• Hvilke utsagn er beskrivende veiledning snarere enn tilgangskontrollregler?
• Hvem eier filen, hvilken hendelse utløser en oppdatering, og hvordan oppdages avdrift?

Når du skal bruke denne innholdstypen

Bruk denne typen når nettstedet har nok offentlig, varig innhold til å dra nytte av et kuratert maskinrettet indeks, og noen kan påta seg vedlikeholdet. Grunnen til å publisere den er å redusere tvetydighet for innhentingssystemer, ikke for å opprette én URL til for dens egen skyld.

Ikke forveksle veiledning med kontroll. robots.txt uttrykker kravelleringspreferanser; et XML-nettstedkart hjelper kravellere med å oppdage URL-er; autentisering og autorisasjon avgjør om en handling kan skje. llms.txt gir kuratert kontekst. En setning i llms.txt kan ikke gi tilgang, tilbakekalle tilgang, beskytte en hemmelighet eller overstyre en destinasjonssides vilkår.

Best for disse virksomhetstypene

1. SaaS . Den sterkeste passformen fordi et programvareselskap vanligvis har distinkte produkt-, funksjons-, pris-, integrasjons-, API-, sikkerhets-, status- og dokumentasjonskilder. Indekset kan avgjøre hvilken side som eier hvilket faktum, mens et separat kapabilitetsmanifest kan beskrive kun handlinger produktet virkelig støtter.
2. E-handel . Sterk når produkter, frakt, returer, tilgjengelighet og kundeserviceretningslinjer er offentlige og kanoniske. Hold volatile varedata i feeder eller API-er; bruk indekset til å peke til disse vedlikeholdte kildene i stedet for å kopiere en katalog inn i Markdown.
3. Markedsplasser . Verdifullt når kjøper-, selger-, leverandør- og plattformretningslinjer er forskjellige. Merk hvert publikum og jurisdiksjon slik at en agent ikke anvender selgerregler på en kjøper eller slutter seg til plattforminventar fra én annonse.
4. B2B-tjenester . Nyttig for å klargjøre kapabiliteter, bransjer, tjenestegrenser, dokumentasjon, anskaffelsesmateriell og kontaktveier. Ikke konverter et forhandlet omfang eller kundespesifikt løfte til et universelt maskinrettet krav.
5. Byråer . Nyttig når firmaet vedlikeholder mange tjeneste-, metode-, casestudie- og ekspertisesider. Klientportaler, legitimasjon, private rapporter og interne spillebøker holdes utenfor den offentlige filen.
6. Produsenter og industribedrifter . Nyttig for å dirigere systemer til produktfamilier, spesifikasjoner, sertifiseringer, manualer, distributører og sikkerhetsdokumenter. Indekset må aldri parafrasere sikkerhetskritisk veiledning når det kontrollerte dokumentet er autoriteten.

Små brosjyrenettsteder med fem stabile sider kan ha lite nytte av nok et vedlikeholdt artefakt. Nettsteder uten en tydelig innholdseier bør fikse kanonisering, navigasjon og kildekvalitet før de publiserer en fil som umiddelbart vil avdrift.

Søkeintensjon

søkeintensjon er resultatet forventet fra et søk. Denne typen har to målgrupper med ulik intensjon. En maskin henter en forutsigbar rotsti og forventer konsis Markdown, stabile overskrifter, kanoniske lenker og ingen dekorativ støy. Et menneske som søker, ønsker vanligvis implementeringsveiledning: «llms.txt-eksempel», «hva hører hjemme i llms.txt» eller «agentmanifest-format». Den offentlige forklaringssiden kan svare på disse spørsmålene, mens den distribuerte /llms.txt forblir optimalisert for maskininnhenting.

Filen i seg selv er ikke en søkeordlandingsside. Ikke legg til generiske definisjoner, gjentatte kategoritermer eller hundrevis av blogginnlegg for å få den til å «rangere». Hver ekstra linje forbruker oppmerksomhet og skaper nok en vedlikeholdsforpliktelse. Foretrekk ti bevisste lenker med klare beskrivelser fremfor et dump av ti tusen URL-er.

Fordi konvensjoner og forbrukerstøtte kan endre seg, angi hva implementeringen din er basert på og unngå å hevde universell adopsjon. En vellykket henting beviser kun at filen er tilgjengelig og tolkbar; den beviser ikke at et bestemt AI-produkt bruker den til rangering, innhenting, trening eller sitering.

Sidestruktur

Ordbånd er redigeringsbegrensninger, ikke mål. Den distribuerte filen bør forbli konsis nok til å revideres linje for linje. Det menneskerettede implementeringsnotatet kan være lengre, men det må ikke kopieres inn i maskinfilen.

En typisk kuratert fil er omtrent 200–700 ord. Lengde er ikke et kvalitetssignal: den riktige størrelsen er det minste indekset som etablerer identitet og dirigerer en forbruker til vedlikeholdte kilder uten å skjule viktige distinksjoner.

Påkrevede elementer

Indekset må være kjedelig i beste forstand: forutsigbart, eksplisitt og enkelt å diff-isere. Plasser kritisk tolkning før valgfrie lenker slik at en delvis lesing ikke gir en falsk konklusjon.

Frontmatter

Følg frontmatter-spesifikasjonen . På denne innholdstype-spesifikasjonen, bruk entity = "post-type-llms-txt-page" og schemaType = "Article". På en menneskerettet implementeringsside for en spesifikk organisasjon, bruk en stabil identitet som acme-ai-access-index, ikke et kampanjeuttrykk eller en dato.

Bruk Article fordi nettsiden forklarer implementeringen. skjemamerking beskriver synlig innhold; det gjør ikke råtekstfilen om til en anerkjent agentprotokoll. Ikke merk siden som SoftwareApplication, Dataset eller HowTo med mindre dens synlige innhold og mal oppfyller de relevante kravene uavhengig.

Råfilen /llms.txt har normalt ingen frontmatter fordi frontmatter ikke må lekke inn i det publiserte resultatet. Lagre dens operasjonelle metadata i CMS-et, generator-oppsettet eller repositorieposten: kanonisk domene, lokasjonsomfang, eier, kildesamling, genereringsmodus, siste verifiserte dato, neste gjennomgangsregel, validatorresultat og varslingsdestinasjon. Hvis lokaliserte filer finnes, dokumentér utvalgsregelen og behold ett entydig kanonisk rotsvar.

Fullt eksempel

Denne fiktive filen demonstrerer et konsist indeks for en SaaS-plattform. Dens URL-er, produkt og kapabilitet er eksempler; mønsteret er spesifikasjonen.

# Northstar Analytics

> Northstar Analytics er en rapporteringsplattform for operasjonsteam. Dette indekset peker til de offentlige sidene som definerer produktet, planene, dokumentasjonen, retningslinjene og støttet agentkapabilitet.

Tilgangstillatelser styres av robots.txt, autentisering og retningslinjene lenket nedenfor. Denne filen gir ikke tilgang eller tillatelse til gjenbruk av innhold.

## Produkt

- [Produktoversikt](https://www.northstar.example/product): Nåværende produktomfang og støttede rapporteringsarbeidsflyter.
- [Planer og priser](https://www.northstar.example/pricing): Nåværende offentlige planer, inkluderte funksjoner og faktureringsvilkår.
- [Integrasjoner](https://www.northstar.example/integrations): Støttede datakilder og målsystemer.

## Dokumentasjon

- [Dokumentasjonshjem](https://docs.northstar.example/): Nåværende bruker- og administrasjonsdokumentasjon.
- [API-referanse](https://docs.northstar.example/api/): Offentlige endepunkter, skjemaer, autentisering, feil og rategrenser.
- [Utgivelsesnotater](https://docs.northstar.example/releases/): Daterte endringer i produkt- og API-atferd.

## Tillit og support

- [Sikkerhet](https://www.northstar.example/security): Sikkerhetsprogram og nåværende forsikringsdokumenter.
- [Personvernerklæring](https://www.northstar.example/privacy): Databehandling, oppbevaring og brukerrettigheter.
- [Support](https://www.northstar.example/support): Støttede kontaktveier og tjenestestatuslenke.

## Agentkapabilitet

- [Rapporteksporteringshandling](https://docs.northstar.example/agents/export-report): Autentisert handlingskontrakt, aksepterte inputer, output-format, rategrenser og feilhåndtering. Tilgjengelighet avhenger av brukerens plan og rolle.

## Valgfritt

- [Forskningsbibliotek](https://www.northstar.example/research): Opprinnelige referansetester med metoder og publiseringsdatoer.

Verifisert 2026-08-27 av dokumentasjonsoperasjonsteamet. Generert fra det kanoniske offentlig-ressursregisteret; valider etter produkt-, plan-, retningslinje-, API- eller URL-endringer.

Eksemplet erklærer én kapabilitet kun fordi en reell, dokumentert handlingskontrakt finnes. Hvis produktet ikke har noen støttet agenthandling, utelat den seksjonen. Slutt aldri fra tilstedeværelsen av en søkeboks, et skjema eller et udokumentert endepunkt.

For et agentmanifest som lagres separat fra /llms.txt, behold samme disiplin. Spesifiser et versjonert format, en kanonisk identifikator, produksjonsendepunkt, autentiseringsmetode, tillatte operasjoner, input- og output-skjema, rategrenser, samtykkegrenser, feiltilstander og retningslinje-URL-er. Valider det mot live-systemet. En syntaktisk gyldig erklæring som annonserer en deaktivert handling er fortsatt feil.

Designgalleri

Råfilen har lite visuelt design med vilje. Gallerivarianter bør teste informasjonsarkitektur, skanneorden, mobil lesbarhet av den menneskerettede implementeringssiden, og operasjonelle bevis – ikke dekorasjon.

Kvalitetssjekkliste

Publiser kun når hver gjeldende påstand er sann:

• Filen løses opp på den tiltenkte rot-URL-en uten autentisering, omdirigeringsløkker, samtykkevegger eller en rendret applikasjonsskall.
• Responsen er lesbar ren tekst eller Markdown, bruker UTF-8, og er ikke avhengig av JavaScript for å avsløre innholdet.
• H1 gir det kanoniske organisasjons- eller nettstedsnavnet, og beskrivelsen angir formål, målgruppe og omfang uten slagord.
• Hver lenkede URL er kanonisk, offentlig, indekserbar etter retningslinjer, tilgjengelig, og eid av organisasjonen eller tydelig merket som ekstern.
• Lenkebeskrivelser sier hvilken autoritet destinasjonen innehar; de gjentar ikke generisk ankertekst som «lær mer».
• Primære produkt-, pris-, dokumentasjons-, retningslinje- og supportkilder samsvarer med indekset.
• Arkivsider, søkeresultater, sporingsparametere, dupliserte lokasjoner, kampanjesider og lavverdige tag-sider er ekskludert.
• Kapabilitetspåstander samsvarer med en live, støttet, autentisert kontrakt og inkluderer de relevante begrensningene.
• Ingen hemmelighet, token, privat endepunkt, personlig data, klientdokument, upublisert veikart-element eller sikkerhetssensitiv implementeringsdetalj vises.
• Tilgangs-, tillatelses-, lisensierings- og retningslinjespråk peker til styrende kilder og motsies ikke av indekset.
• Filen hevder ikke garantert rangering, sitering, treningsutestenging eller universell forbrukerstøtte.
• Lokalitet og regionalt omfang er eksplisitt der priser, retningslinjer, tilgjengelighet eller dokumentasjon er forskjellige.
• Eieren, kilderegisteret, genereringsprosessen og valideringsmetoden er registrert utenfor eller på slutten av filen.
• Sjekker av brutt-lenke, uventet-omdirigering, responsstatus, innholdshash og påkrevde seksjoner kjøres etter relevante distribusjoner.
• Verifikasjonsdatoen endres kun etter at destinasjoner, beskrivelser, kapabiliteter og retningslinjer er substansielt sjekket.

Vanlige feil

Å behandle filen som et nettstedkart. En fullstendig URL-inventar ødelegger prioritering og er vanskelig å revidere. Hold XML-nettstedkart for oppdagelse; kurater llms.txt rundt autoritative kilder og meningsfulle grupper.

Å behandle den som tilgangskontroll. En forespørsel i Markdown er ikke et håndhevingslag. Uttrykk kravellingsregler i robots.txt, beskytt private ressurser med autentisering, og plasser bindende krav i de relevante retningslinjene og systemkontrollene.

Å kopiere destinasjonsinnhold inn i indekset. Gjentatte priser, produktspesifikasjoner og retningslinjer avviker. Oppsummer kun nok til å identifisere autoritet, lenk deretter til den vedlikeholdte kilden.

Å publisere spekulative kapabiliteter. Et udokumentert skjema eller en API-rute gjør ikke et nettsted agentklart. Erklær kun produksjonsstøttede handlinger med autentisering, skjemaer, begrensninger, feil og en eier.

Å inkludere alt «for sikkerhets skyld». Flere lenker skaper mer tvetydighet og flere feilpunkter. Valgfritt innhold bør fortjene inkludering ved å svare på et sannsynlig innhentingsbehov som primærseksjonene ikke dekker.

Å eksponere privat materiale. Offentlige maskinlesbare filer er offentlige. List aldri opp testmiljøverter, interne API-er, legitimasjon, kundeeksporter, upubliserte dokumenter eller sikkerhetsdetaljer som ikke var bevisst godkjent for publisering.

Å generere uten styring. Automatisering kan reprodusere dårlige kildedata i høy hastighet. En generator trenger et godkjent kilderegister, ekskluderingsregler, deterministisk sortering, validering, revurderingseierskap og distribusjonsvarsler.

Å håndredigere en generert fil. Neste generering overskriver rettelsen. Korrigér kildeposten eller generatoren, regenerer, og registrer den materielle endringen.

Å hevde ustøttede resultater. «Dette garanterer AI-siteringer» gjør en usikker implementeringskonvensjon til et misvisende løfte. Rapporter tilgjengelighets- og innhentingsbevis separat fra synlighets- og siteringsresultater.

Å oppdatere datoen uten å sjekke virkeligheten. Et nytt tidsstempel kan ikke reparere en død dokumentasjons-URL, omdøpt plan eller deaktivert handling. Verifikasjon betyr å sammenligne hver viktige erklæring med dens produksjonskilde.

Intern lenking

Lenk den menneskerettede implementeringssiden oppover til SEO-innholdstyper når en forfatter må skille maskinindekset fra en katalog, dokumentasjonsside eller retningslinje. Lenk fra hver operasjonell påstand til dens styrende kilde: produktomfang til produktsiden, gjeldende priser til prising, atferd til dokumentasjon, tillatelser til tilgangskontroller og forpliktelser til retningslinje.

Råfilen bør bruke kanoniske absolutte URL-er fordi den kan hentes utenfor normal nettstednavigasjon. Foretrekk én autoritativ destinasjon per faktum. Hvis to sider overlapper, løs eierskap før du lister begge; indekset bør eksponere kildearkitekturen, ikke minnes interne uenigheter.

Bruk korte, stabile seksjonsnavn som Produkt, Dokumentasjon, Retningslinjer og Agentkapabiliteter. Hold lokalitetsvarianter i tydelig merkede grupper kun når de skiller seg vesentlig. Ikke lenk hvert blogginnlegg; velg varig forskning eller guider kun når de hjelper et system med å forstå nettstedets emne og bevis.

Inngående lenker er også viktig operasjonelt. Dokumentasjon, utviklerportaler og AI-tilgjengelighetsveiledning bør peke vedlikeholdere til implementeringsposten, mens posten peker til livefilen og validatoren. Det skaper en revurderingssti for mennesker uten å rote til maskinindekset.

Hvordan måle resultater

Mål filen som infrastruktur først og som synlighetsinngang sekundært. En sitatøkning kan ikke tilskrives llms.txt bare fordi begge skjedde etter publisering.

Spor fire lag:

• Tilgjengelighet: rot-URL-responsstatus, omdirigeringsatferd, innholdstype, koding, ventetid, renderingsuavhengighet og oppetid.
• Integritet: parsing-suksess, påkrevde seksjoner, dupliserte URL-er, brutte lenker, omdirigeringsmål, kanonisk avvik, uautoriserte domener, eksponerte hemmeligheter og innholdshash-endringer.
• Ferskhet: dager siden substansiell verifikasjon, destinasjonsendringer siden verifikasjon, kilderegisterdekning, eierbekreftelse og tid til å reparere avdrift.
• Resultater: serverlogg-hentinger av identifiserbare agenter der det er juridisk og teknisk hensiktsmessig, besøk til indekserte destinasjoner, AI-siteringer av foretrukne kanoniske sider og svar-nøyaktighet for spores merkevare- eller produktspørsmål.

Etabler en baseline før distribusjon: hvilke URL-er som siteres, hvilke fakta som er feilsitert, om rotfilen finnes, og hvilke kravellere som ber om den. Annotér publisering og hver materielle oppdatering. Sammenlign observasjonsvinduer som er lange nok til å unngå å lese én henting eller sitering som en trend, og behold skillet mellom korrelasjon og årsakssammenheng.

Test feilmodusene direkte. Gi nytt navn til en testkopi av en oppført URL og bekreft at validatoren fanger bruddet. Endre en kanonisk kartlegging og bekreft at generatoren oppdaterer indekset. Deaktiver en kapabilitet i et kontrollert testmiljø og bekreft at manifestsjekken feiler. Disse testene beviser vedlikeholdssystemet, ikke ekstern adopsjon.

Bruk hvordan vi måler resultater for å skille teknisk tilgjengelighet, maskinrepresentasjon, oppdagelse, sitering, engasjement og forretningsresultater. I AmICited, gjennomgå livefilen under Agent Accessibility og bruk Cockpit-rapporten for å observere siterte URL-er og AI-synlighet sammen med distribusjonsannotasjoner. Det troverdige suksesskravet er «filen er gyldig, aktuell, og dirigerer systemer til de tiltenkte kildene»; enhver nedstrøms synlighetsendring krever separate bevis.

FAQ

Vanlige spørsmål