Nextjs llms.txt: llms-full.txt und .md-Seiten erzeugen

Du willst, dass Coding-Agenten und KI-Assistenten deine Doku so lesen, wie du sie geschrieben hast: ohne Navigation, Cookie-Banner und Script-Tags rund um jede Seite. Ein Setup für nextjs llms.txt erledigt das in drei Teilen: ein llms.txt-Index im Root, eine llms-full.txt mit allem in einer Datei und eine saubere Markdown-Version jeder Seite unter ihrer URL plus .md. Dieses Tutorial baut alle drei mit Route Handlern im App Router, erzeugt aus denselben Daten, die deine Seiten rendern. Dazu zeigen wir, was wir gelernt haben, als wir sie für den Komponentenkatalog von Wingo UI ausgeliefert haben.

Jedes Snippet ist TypeScript für Next.js 16 und React 19. Mehr dazu, wie Agenten Komponentenbibliotheken lesen, findest du unter UI mit KI-Agenten bauen.

Was ist llms.txt und was steht drin?

llms.txt ist eine Markdown-Datei im Root deiner Website. Sie sagt einem Sprachmodell, worum es auf der Website geht und wo die nützlichen Seiten liegen. Jeremy Howard hat den llms.txt-Vorschlag (opens in a new tab) am 3. September 2024 veröffentlicht und zuletzt am 10. August 2026 überarbeitet (geprüft am 16. Oktober 2026).

Das Format ist kurz:

• Eine H1 mit dem Namen der Website. Das ist der einzige Pflichtteil.
• Ein Blockquote mit einer Zusammenfassung.
• Optional Absätze oder Listen mit Details (ohne Überschriften).
• Beliebig viele ##-Abschnitte, jeder eine Linkliste im Format [name](url): notes.
• Ein Abschnitt namens ## Optional enthält zweitrangige Links, die ein Agent überspringen kann, wenn er weniger Kontext braucht.

Der Vorschlag sieht außerdem eine saubere Markdown-Version jeder Seite unter derselben URL mit angehängtem .md (page.html.md) oder mit .md statt der Endung (page.md) vor. Die aktuelle Fassung ergänzt einen rel="alternate"-Link vom Typ text/markdown, der auf diese Version zeigt, entweder als HTML-Element <link> oder als HTTP-Header Link.

llms-full.txt ist eine Konvention aus der Community, die der Vorschlag gar nicht erwähnt: der volle Text der Seiten in einer Datei. Next.js veröffentlicht alle drei für die eigene Doku, unter nextjs.org/docs/llms.txt (opens in a new tab), nextjs.org/docs/llms-full.txt (opens in a new tab) und als .md-Version jeder Doku-Seite (geprüft am 16. Oktober 2026).

Wie sieht ein echtes llms.txt Beispiel aus?

Hier ist der Anfang unserer Datei vom 16. Oktober 2026, gekürzt und im englischen Original. Die vollständige Datei liegt unter /llms.txt:

# Wingo UI

> Wingo UI is a library of animated, configurable, mobile-first React components and blocks you copy into your project, with a CLI and an MCP server for coding agents. 352 items (226 components, 90 blocks, 17 hooks, 19 helper libraries) for React 19 and Tailwind CSS v4, release 1.9.0. 75 items are free; the rest need a Pro plan.

Every item has an HTML docs page (live preview, props, usage) and the same docs as Markdown at the page URL plus `.md`.

## Docs

- [Installation](https://wingo-ui.com/docs/installation): Set up a project and add components
- [MCP server](https://wingo-ui.com/docs/mcp): Connect your coding agent

## Inputs

- [OTP Input](https://wingo-ui.com/components/otp-input): A React OTP input for one-time verification codes and PINs, with digits that roll into place and a caret that slides between slots. [Markdown](https://wingo-ui.com/components/otp-input.md)

Zwei Entscheidungen darin solltest du übernehmen. Die Zahlen und die Release-Nummer werden beim Build aus der Registry berechnet, deshalb ist die Zusammenfassung nie veraltet. Und jede Zeile enthält beide URLs: die HTML-Seite für Menschen und die .md-Version für Agenten. Die Doku zum OTP Input und /components/otp-input.md sind dieselbe Doku in zwei Formaten.

Für Menschen gerendert ergibt dasselbe Markdown einen gut lesbaren Index. Die Demo unten rendert einen Ausschnitt unserer Datei mit der Markdown-Komponente.

Woher sollen die Inhalte kommen?

Aus derselben Quelle, aus der auch deine Seiten gerendert werden. Ist llms.txt eine handgeschriebene Datei in public/, stimmt sie nicht mehr, sobald jemand eine Seite anlegt und die Datei vergisst. Unser Katalog hat eine meta.ts pro Komponente, und die HTML-Doku, die .md-Version, llms.txt, llms-full.txt und der MCP-Server lesen alle diese Objekte.

In diesem Tutorial ist die Quelle ein typisiertes Modul. Tausch das Array gegen deinen CMS-Client, deinen MDX-Loader oder deine Registry aus; der restliche Code braucht nur docs und getDoc.

// lib/docs.ts: die eine Quelle für Seiten, .md-Versionen und llms-Dateien
export type Doc = {
  slug: string;
  title: string;
  description: string;
  section: "Anleitungen" | "Komponenten";
  body: string; // markdown, ohne h1
};

export const SITE = {
  name: "Acme UI",
  origin: process.env.NEXT_PUBLIC_SITE_URL ?? "http://localhost:3000",
  summary: "Eine React-Komponentenbibliothek für Dashboards, installiert als Quellcode.",
};

export const docs: Doc[] = [
  {
    slug: "installation",
    title: "Installation",
    description: "Richte ein Next.js-Projekt ein und füg deine erste Komponente hinzu.",
    section: "Anleitungen",
    body: "## Voraussetzungen\n\nNext.js 16, React 19 und Tailwind CSS v4.\n\n## Komponente hinzufügen\n\n```bash\nnpx acme-ui add button\n```",
  },
  {
    slug: "button",
    title: "Button",
    description: "Ein Button mit fünf Varianten und einem Ladezustand.",
    section: "Komponenten",
    body: "## Verwendung\n\n```tsx\n<Button variant=\"soft\">Speichern</Button>\n```",
  },
];

export function getDoc(slug: string) {
  return docs.find((doc) => doc.slug === slug);
}

Wie erzeuge ich llms.txt im App Router?

Pack die Formatierung in ein Modul und liefere sie aus einem Route Handler aus. Das Modul baut das Markdown einer Seite einmal und verwendet es für die .md-Version und die volle Datei wieder.

// lib/llms.ts
import { SITE, docs, type Doc } from "@/lib/docs";

export const pageUrl = (doc: Doc) => `${SITE.origin}/docs/${doc.slug}`;
export const markdownUrl = (doc: Doc) => `${pageUrl(doc)}.md`;

// eine seite als markdown: die .md-version und ein abschnitt von llms-full.txt
export function docMarkdown(doc: Doc) {
  return [`# ${doc.title}`, "", `> ${doc.description}`, "", doc.body.trim(), "", `Quelle: ${pageUrl(doc)}`, ""].join("\n");
}

export function llmsTxt() {
  const lines = [`# ${SITE.name}`, "", `> ${SITE.summary}`, "", "Jede Seite gibt es auch als Markdown unter ihrer URL plus `.md`.", ""];
  for (const section of new Set(docs.map((doc) => doc.section))) {
    lines.push(`## ${section}`, "");
    for (const doc of docs.filter((d) => d.section === section)) {
      lines.push(`- [${doc.title}](${pageUrl(doc)}): ${doc.description} [Markdown](${markdownUrl(doc)})`);
    }
    lines.push("");
  }
  lines.push("## Optional", "", `- [Komplette Doku](${SITE.origin}/llms-full.txt): alle Seiten oben in einer Datei`);
  return lines.join("\n") + "\n";
}

// "# Titel" wird außerhalb von code-blöcken zu "## Titel", damit die seiten unter der h1 der datei liegen
function shiftHeadings(markdown: string, levels: number) {
  let inFence = false;
  return markdown
    .split("\n")
    .map((line) => {
      if (/^\s*(```|~~~)/.test(line)) inFence = !inFence;
      if (inFence) return line;
      return line.replace(/^(#{1,6})(?=\s)/, (hashes) => (hashes + "#".repeat(levels)).slice(0, 6));
    })
    .join("\n");
}

export function llmsFullTxt() {
  return [`# ${SITE.name}`, "", `> ${SITE.summary}`, "", ...docs.map((doc) => shiftHeadings(docMarkdown(doc), 1))].join("\n") + "\n";
}

Der Route Handler liegt in einem Ordner, der wie die Datei heißt. Route Handler werden standardmäßig nicht gecacht. force-static sagt Next.js deshalb, ihn einmal beim Build auszuführen und das Ergebnis als statische Datei auszuliefern.

Der Handler aus der Demo als Text:

// app/llms.txt/route.ts
import { llmsTxt } from "@/lib/llms";

export const dynamic = "force-static";

export function GET() {
  return new Response(llmsTxt(), {
    headers: { "content-type": "text/plain; charset=utf-8" },
  });
}

Wenn du cacheComponents eingeschaltet hast, lösch die Exporte dynamic und dynamicParams in jeder Datei dieses Tutorials: Next.js 16 hat sie unter Cache Components entfernt. Ein GET-Handler, der keine Request-Daten liest, wird dann von selbst vorgerendert. Ungecachte Daten kommen in einen Helper mit use cache, und die Prüfungen if (!doc) weiter unten liefern weiterhin die 404-Antworten.

Wie ergänze ich llms-full.txt in Next.js?

Mit einem zweiten Route Handler, der die andere Funktion aufruft. Die komplette Route für Next.js llms-full.txt:

// app/llms-full.txt/route.ts
import { llmsFullTxt } from "@/lib/llms";

export const dynamic = "force-static";

export function GET() {
  return new Response(llmsFullTxt(), {
    headers: { "content-type": "text/plain; charset=utf-8" },
  });
}

Behalte die Größe im Blick. Am 16. Oktober 2026 hat unser Dev-Server eine /llms-full.txt mit 5,3 MB ausgeliefert (die Installationsanleitung, die Designregeln, Props und Verwendung jedes Elements sowie die Blogartikel) und einen Index mit 139 KB, weil der Index jedes Element auflistet. Die Datei der Next.js-Doku hatte am selben Tag 4,4 MB. Ein Fetch-Tool kann eine lange Antwort abschneiden, und ein Modell, das die ganze Datei tatsächlich bekommt, verbraucht seinen Kontext für Seiten, die es nicht braucht. Deshalb teilen wir die Doku der Elemente zusätzlich pro Kategorie in Dateien unter /llms/<category>.txt auf. Der Code setzt PART_BYTES = 100_000, und eine Kategorie, die darüber hinauswächst, wird in -2.txt, -3.txt und so weiter fortgesetzt. Inputs (37 Elemente) ist auf vier Teile verteilt, beginnend mit /llms/inputs.txt, Templates (45 Elemente) auf fünf. Der Index verlinkt jeden Teil.

Wie liefere ich eine .md-Version jeder Seite aus?

Leg einen Route Handler unter einen internen Pfad und schreib die öffentliche .md-URL per Rewrite darauf um. Ein dynamisches Segment belegt immer den ganzen Ordnernamen, also ist app/docs/[slug].md/ keine Route. Ohne Rewrite bekommt deine Seite app/docs/[slug] dann button.md als Slug. Der Vorteil: Ein Agent, der eine einzelne Seite braucht, lädt ein paar KB statt einer Datei mit mehreren Megabyte.

// app/docs/md/[slug]/route.ts
import { docs, getDoc } from "@/lib/docs";
import { docMarkdown, pageUrl } from "@/lib/llms";

export const dynamicParams = false;

export function generateStaticParams() {
  return docs.map((doc) => ({ slug: doc.slug }));
}

export async function GET(_request: Request, { params }: { params: Promise<{ slug: string }> }) {
  const doc = getDoc((await params).slug);
  if (!doc) return new Response("Nicht gefunden\n", { status: 404 });
  return new Response(docMarkdown(doc), {
    headers: {
      "content-type": "text/markdown; charset=utf-8",
      // suchmaschinen fassen die .md-version mit der html-seite zusammen
      link: `<${pageUrl(doc)}>; rel="canonical"`,
    },
  });
}

generateStaticParams rendert eine Antwort pro Seite vor, und dynamicParams = false liefert für jeden Slug, den du nicht aufgelistet hast, eine 404. Einen Link-Header mit rel="canonical" schickt auch nextjs.org auf seinen eigenen .md-Seiten (geprüft am 16. Oktober 2026). Das Rewrite gehört in beforeFiles. Diese Phase läuft, bevor Next.js die Seiten zuordnet, deshalb landet /docs/button.md nie als Slug namens button.md auf der Seite app/docs/[slug]:

// next.config.ts
import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  async rewrites() {
    return {
      beforeFiles: [{ source: "/docs/:slug\\.md", destination: "/docs/md/:slug" }],
      afterFiles: [],
      fallback: [],
    };
  },
};

export default nextConfig;

Unsere Website nutzt dieselben Markdown-Routen für KI unter drei Präfixen: /components/:slug\\.md, /templates/:slug\\.md und /blog/:slug\\.md schreiben jeweils auf einen Handler unter md/[slug] um. Auch dieser Artikel hat eine: seine .md-URL.

Wie finden Agenten die Markdown-Version einer Seite?

Über einen Link im HTML-Head. In generateMetadata rendert alternates.types ein <link rel="alternate" type="text/markdown">. Das ist genau die Link-Relation, die der Vorschlag beschreibt:

// app/docs/[slug]/page.tsx
import type { Metadata } from "next";
import { notFound } from "next/navigation";
import { Markdown } from "@/components/ui/markdown";
import { docs, getDoc } from "@/lib/docs";

export const dynamicParams = false;

export function generateStaticParams() {
  return docs.map((doc) => ({ slug: doc.slug }));
}

export async function generateMetadata({ params }: { params: Promise<{ slug: string }> }): Promise<Metadata> {
  const { slug } = await params;
  const doc = getDoc(slug);
  if (!doc) return {};
  return {
    title: doc.title,
    description: doc.description,
    alternates: { canonical: `/docs/${slug}`, types: { "text/markdown": `/docs/${slug}.md` } },
  };
}

export default async function DocPage({ params }: { params: Promise<{ slug: string }> }) {
  const doc = getDoc((await params).slug);
  if (!doc) notFound();
  return (
    <article className="mx-auto max-w-2xl px-4 py-12">
      <h1 className="text-3xl font-semibold text-foreground">{doc.title}</h1>
      <p className="mt-2 text-muted-foreground">{doc.description}</p>
      <Markdown size="lg" headingIds className="mt-8">
        {doc.body}
      </Markdown>
    </article>
  );
}

Relative URLs in den Metadaten brauchen metadataBase im Root-Layout. Die Seite rendert dasselbe doc.body, aus dem auch die .md-Version entsteht. Die beiden können sich also nicht widersprechen. headingIds gibt jeder Überschrift einen Anker, und Codeblöcke laufen durch den Code Block mit Kopier-Button.

Next.js beantwortet auf den eigenen Doku-Seiten außerdem Accept: text/markdown mit Markdown und schickt Vary: Accept (geprüft am 16. Oktober 2026). Das kannst du mit einer has-Bedingung auf den Header in einem zweiten Rewrite nachbauen. Ein CDN, das nur nach URL cacht, kann dann aber Markdown an einen Browser ausliefern, wenn nicht jede Antwort Vary: Accept schickt. Wir haben darauf verzichtet: Separate .md-URLs lassen sich sauber cachen und leicht in einen Chat einfügen.

Was sind die llms.txt Best Practices?

Sieben Regeln, alle aus unserem eigenen Setup:

1. Erzeugen, nie von Hand bearbeiten. Zahlen, Preise und Seitenlisten kommen aus dem Code, also gehen die Dateien mit jedem Deploy raus.
2. Der Index bleibt eine Übersicht. Eine Zeile pro Seite, mit Notizen, die sagen, wann sich die Seite lohnt. Langer Text gehört in die .md-Versionen und die volle Datei.
3. Die volle Datei aufteilen. Dateien pro Abschnitt unter etwa 100 KB lassen sich leichter abrufen als eine Datei mit mehreren Megabyte.
4. Entwürfe weglassen. Unser Loader wirft Entwürfe aus dem Production-Build, also landen sie nie in den Dateien. Im Dev-Modus werden sie gerendert, und ihre .md-Versionen schicken X-Robots-Tag: noindex.
5. Jeder .md-Version ein Canonical mitgeben. Der Link-Header verhindert, dass die .md-URL in der Suche mit der HTML-Seite konkurriert.
6. Nicht blockieren. Unsere robots.ts sperrt nur private Pfade (Account, Checkout, Admin, API, Previews), also bleiben /llms.txt und jede .md-Route crawlbar. Ein Disallow würde sie vor genau den Agenten verstecken, für die du sie gebaut hast.
7. Nie private Inhalte preisgeben. Unsere llms-full.txt enthält Props und Verwendung für jedes Element, aber nie den Quellcode eines Pro-Elements.

Liest überhaupt jemand llms.txt?

Coding-Agenten und Assistenten, die deine URLs während der Arbeit abrufen, können sie lesen. Google braucht sie nicht: Laut der Dokumentation zu den KI-Funktionen (opens in a new tab) sind weder KI-Textdateien noch andere neue maschinenlesbare Dateien nötig, um in AI Overviews oder im AI Mode zu erscheinen (zuletzt aktualisiert am 10. Dezember 2025).

Ein Coding-Agent, der deine Bibliothek nutzen soll, oder ein Chat-Assistent, dem du deine URL gibst, bekommt deine echten Props mit einem einzigen Abruf. Deshalb sind die .md-Versionen auch wichtiger als der Index. „Lies https://wingo-ui.com/components/data-table.md (opens in a new tab) und schreib damit eine Tabelle für Bestellungen“ ist ein Prompt, der in jedem Assistenten funktioniert, der eine URL abrufen kann.

Wenn ein Agent mehr kann als lesen, ist ein MCP-Server der bessere Kanal: Er kann suchen, Props und Quellcode zurückgeben und auf Updates prüfen. Unser Guide zum MCP-Server für Komponentenbibliotheken beschreibt dieses Setup, und der Vergleich AGENTS.md vs CLAUDE.md behandelt die Regeldatei, die Agenten sagt, dass sie ihn nutzen sollen. Wenn du die App selbst aufsetzt, fang mit unserem Setup einer Komponentenbibliothek in Next.js an.

Wie prüfe ich, ob alles funktioniert?

Mit curl, gegen den Dev-Server oder einen Production-Build:

curl -s http://localhost:3000/llms.txt | head -20
curl -sI http://localhost:3000/docs/button.md   # content-type: text/markdown, link: rel="canonical"
curl -s http://localhost:3000/docs/button | grep -o '<link rel="alternate" type="text/markdown"[^>]*>'
curl -s -o /dev/null -w "%{http_code}\n" http://localhost:3000/docs/missing.md   # 404

Lass auch einmal next build laufen: Die Routenliste sollte /llms.txt, /llms-full.txt und /docs/md/[slug] als vorgerendert markieren (static oder SSG), nicht als dynamisch. Das bestätigt, dass nichts pro Request läuft.

Was solltest du als Nächstes tun?

Liefere zuerst den Index und die .md-Versionen aus: Der Index ist die Übersicht, und die .md-Versionen beantworten die Abrufe einzelner Seiten. Ergänze danach llms-full.txt und teil sie pro Abschnitt auf, sobald eine Datei größer als etwa 100 KB wird. Wenn deine Doku Code zeigt, fang mit dem kostenlosen Code Block an: npx wingo-ui@latest add code-block. Der oben verwendete Markdown-Renderer ist Teil von Pro.

Häufige Fragen

Wohin gehört llms.txt in einem Next.js-Projekt mit App Router?

Leg app/llms.txt/route.ts mit einem GET-Handler an, der den Text zurückgibt, und exportier const dynamic = "force-static", damit die Datei beim Build entsteht. Eine statische public/llms.txt geht auch, ist aber veraltet, sobald du die erste neue Seite anlegst.

Was ist der Unterschied zwischen llms.txt und llms-full.txt?

llms.txt ist ein kurzer Index: Name der Website, eine Zusammenfassung und Linklisten mit einzeiligen Notizen. llms-full.txt packt den vollen Text dieser Seiten in eine Datei; das ist eine Konvention aus der Community, die der Vorschlag auf llmstxt.org nicht definiert.

Wie liefere ich in Next.js eine .md-Version jeder Seite aus?

Ein dynamisches Segment belegt immer den ganzen Ordnernamen, deshalb funktioniert app/docs/[slug].md nicht. Leg einen Route Handler unter app/docs/md/[slug]/route.ts an und ein beforeFiles-Rewrite von /docs/:slug.md auf /docs/md/:slug in next.config.ts. Gib das Markdown mit content-type text/markdown und einem Link-Header zurück, der per rel=canonical auf die HTML-Seite zeigt.

Nutzt Google llms.txt?

Laut Google brauchst du keine KI-Textdateien oder andere neue maschinenlesbare Dateien, um in AI Overviews oder im AI Mode zu erscheinen (Search Central, zuletzt aktualisiert am 10. Dezember 2025). Die Dateien helfen Agenten und Assistenten, die deine URLs während der Arbeit abrufen, etwa Coding-Agenten, die deine Doku lesen.

Welchen Content-Type sollte llms.txt haben?

Der Vorschlag schreibt keinen vor. text/plain; charset=utf-8 ist für die .txt-Dateien die sichere Wahl, weil Browser sie direkt anzeigen, und text/markdown; charset=utf-8 passt zu den .md-Versionen.