llms.txt Generator — Manual

Zurück zur Übersicht: llms.txt Generator · Tool live öffnen: www.jpkc.com/tools/llms/

Dieses Manual beschreibt den llms.txt Generator vollständig: jedes Eingabefeld des Generators, wie aus deinen Eingaben das Markdown wird, die Server-Snippets, was der Live-Checker prüft (mit allen Regeln und dem Link-Check), die Format-Referenz und die technischen Grenzen. Die Oberfläche des Tools ist auf Englisch — Tab-, Feld- und Button-Namen werden hier in ihrer englischen Original-Schreibweise genannt (mit deutscher Erläuterung), damit du dich im echten Interface zurechtfindest.

Was eine llms.txt ist

Die llms.txt ist ein Vorschlag für einen Standard (von Jeremy Howard / fast.ai, dokumentiert auf llmstxt.org (öffnet in neuem Tab) (englisch)): eine Markdown-Datei unter /llms.txt oder in einem Unterpfad, die KI-Agenten kuratierten, akkuraten Kontext über deine Inhalte gibt. Das Tool richtet sich nach der Fassung v2 (August 2026). Im Tips-Tab beschreibt es unter „How Agents Use llms.txt" drei Aspekte:

• On demand — Agenten lesen die llms.txt, wenn sie beim Helfen Informationen brauchen: Coding-Agenten für API-Doku, Chat-Assistenten für Produktfragen. Sie dient der Beantwortung von Anfragen, nicht als Crawler- oder Ranking-Signal.
• Follow the links — die Datei bleibt klein genug fürs Kontextfenster, die Details liegen hinter den Links. Agenten wählen anhand deiner Notizen aus, welche Seiten sie abrufen — deshalb lohnt es sich, saubere Markdown-Versionen (page.html.md) zu verlinken.
• Discovery — Seiten können per rel="describedby" auf ihre llms.txt und per rel="alternate" type="text/markdown" auf ihre Markdown-Version zeigen (v2). Laut Tool prüft auch Chrome Lighthouse in seinen Agentic-Browsing-Audits, ob die Datei vorhanden ist.

Die fünf Tabs im Überblick

Das Tool gliedert sich in fünf Tabs: Generator (Formular → Markdown, mit Prüfhinweisen und Server-Snippets), Check (Live-Validator mit Link-Check), Examples (vier Vorlagen), Tips (Best Practices) und Reference (Format-Spezifikation). Generator und Check sind die beiden Werkzeuge; Examples, Tips und Reference sind Nachschlage-Inhalte und funktionieren auch ohne Eingabe.

Der Generator-Tab

Der Generator ist zweispaltig: links das Formular (Configure your llms.txt), rechts der Output-Editor mit dem fertigen Markdown, darunter die Prüfhinweise und die Karte Serving & discovery. Jede Eingabe aktualisiert die Ausgabe live (mit 250 Millisekunden Verzögerung). Der Output-Editor ist ein schreibgeschützter ACE-Editor mit Markdown-Hervorhebung — du editierst also immer über das Formular, nie direkt im Markdown.

Name (Pflicht) und Summary

• Project / Site Name (Pflicht, rotes Sternchen) — wird zur H1-Überschrift: # Name. Laut Spezifikation ist das das einzige Pflichtelement. Bleibt das Feld leer, schreibt der Generator keinen Platzhalter, sondern lässt die H1 weg und meldet unter der Ausgabe als Fehler, dass mindestens der Name nötig ist.
• Summary (recommended, also empfohlen) — wird zum Blockquote direkt nach dem Titel: > deine Summary. Ein oder zwei Sätze mit den Kernfakten; das Tool beschreibt sie als das, was Agenten zuerst lesen. Fehlt sie, ist die Datei trotzdem gültig — der Validator warnt nur.

Name und Summary werden jeweils auf eine Zeile gebracht: Zeilenumbrüche und mehrfache Leerzeichen werden zu einem einzelnen Leerzeichen.

Details (optional)

Das Feld Details nimmt beliebiges Markdown auf, das nach der Summary und vor der ersten Sektion steht: Absätze und Listen, etwa Zielgruppe, Zweck oder Hinweise, wie die verlinkten Dateien zu lesen sind. Überschriften sind hier nicht erlaubt, weil sie die Struktur brechen würden. Beginnt eine Zeile wie eine Überschrift (# bis ######), schreibt der Generator sie maskiert als \# und weist unter der Ausgabe darauf hin; Zeilen innerhalb von Code-Blöcken bleiben unangetastet. Leer gelassen, entfällt der Block komplett.

Sektionen, Links und Subsektionen

Der dynamische Bereich Sections & Links ist der Kern. Über Add Section legst du beliebig viele Sektionen an; jede wird zu einer H2-Überschrift (## Name). Jede Sektion hat ein Namensfeld, Pfeil-Buttons zum Verschieben nach oben und unten sowie einen Button zum Entfernen. Innerhalb einer Sektion:

• Links über Add Link: drei beschriftete Felder pro Zeile — Name, URL (z. B. https://example.com/docs/start.md) und Notes (optional, die Notiz zum Link). Ausgegeben wird - [Name](URL): Notes; ohne Notiz entfällt der Doppelpunkt. Jede Link-Zeile hat eigene Pfeil-Buttons und einen Entfernen-Button.
• Subsektionen (H3) über Add Subsection (H3): eine Sektion kann Untergruppen mit eigener Überschrift (### Name) und eigener Link-Liste enthalten — ebenfalls mit Pfeil-Buttons und Entfernen. Subsektionen werden nach den direkten Links der Sektion ausgegeben. Wichtig: H3 ist nicht Teil der Spezifikation, sondern eine Erweiterung des Generators. Agenten lesen sie problemlos, der Python-Referenz-Parser behandelt aber jede H3 als eigene Sektion.
• Text unter der Überschrift über Add Text: Es öffnet sich ein Feld „Text under the heading (not part of the spec)". Dieser Fließtext wird vor den Links der Sektion ausgegeben. Die Spezifikation sieht unter einer H2 nur Link-Listen vor; Agenten lesen den Text trotzdem, der Python-Referenz-Parser dagegen nicht — das Tool vermerkt das als Hinweis. Überschriften im Text werden wie bei den Details als \# maskiert.
• Sortieren: Sektionen, Subsektionen und Links verschiebst du mit den Pfeil-Buttons (Move up / Move down) — das funktioniert auch per Tastatur und Touch. Sektionen lassen sich zusätzlich mit der Maus am Griff-Symbol (dem Punktraster links) per Drag & Drop umsortieren.

Leere Sektionen (kein Name, kein Inhalt) und leere Subsektionen tauchen im Output nicht auf. Eine Sektion mit Inhalt, aber ohne Namen bekommt eine leere ##-Überschrift, und der Generator warnt davor.

Was der Generator beim Schreiben glättet

Damit deine Eingaben die Struktur nicht versehentlich brechen, bereinigt der Generator beim Schreiben:

• Links ohne URL fallen weg; unter der Ausgabe erscheint eine Warnung mit Name und Sektion.
• Links ohne Namen bekommen die URL als Namen (Hinweis).
• Eckige Klammern und Backslashes im Namen werden mit \ maskiert (\[, \], \\).
• Leerzeichen, runde und spitze Klammern in URLs werden prozentkodiert (%20, %28, %29, %3C, %3E) — sonst läse der Referenz-Parser den Link falsch.
• Name, URL und Notiz eines Links werden jeweils auf eine Zeile gebracht, Leerzeichen am Zeilenende entfernt.

Der llms-full.txt-Verweis

Das optionale Feld llms-full.txt URL verlinkt auf eine kombinierte Vollinhalt-Datei (siehe unten). Darunter liegt ein Feld für die Notiz zum Link; lässt du es leer, nimmt der Generator den Standardtext „The complete documentation in one file". Der Link landet in der Sektion ## Optional: Gibt es bereits eine Sektion dieses Namens, wird er dort angehängt, sonst entsteht sie am Ende. Das Ergebnis sieht so aus:

## Optional

- [llms-full.txt](https://deinedomain.de/llms-full.txt): The complete documentation in one file

Das Tool weist im Formular darauf hin, dass llms-full.txt eine Konvention ist und nicht zur Spezifikation gehört.

Linkziele: Markdown-Versionen

Die Auswahl Link targets legt fest, worauf die Links zeigen. Die llms.txt-Spezifikation v2 empfiehlt, saubere Markdown-Versionen deiner Seiten zu verlinken:

In beiden Markdown-Modi gilt: Ein Pfad ohne Endung bekommt .md angehängt (/docs/start → /docs/start.md), eine reine Domain wird wie ein Verzeichnis behandelt. URLs, die schon auf .md oder .txt enden, und andere Dateien wie PDFs oder JSON bleiben unverändert; Query-String und Fragment bleiben erhalten. In deinen Formularfeldern ändert sich nichts — umgeschrieben wird nur die Ausgabe. Ein Hinweis erinnert dich daran, dass diese URLs auf deinem Server auch existieren müssen; prüfen kannst du sie anschließend mit dem Link-Check im Check-Tab.

Output: Copy, Download, Reset

Über dem Editor liegen drei Buttons:

• Reset — setzt das Formular nach einer Rückfrage auf den Auslieferungszustand zurück (eine leere Sektion namens „Documentation") und löscht den gespeicherten Stand.
• Copy — kopiert das erzeugte llms.txt in die Zwischenablage.
• Download — speichert es als Datei llms.txt (Plain-Text, UTF-8). Bei Download und Copy warnt das Tool nur, wenn die Ausgabe ganz leer ist. Die vorbelegte Sektion „Documentation" ergibt allein schon eine Ausgabe (## Documentation) — die Warnung erscheint also erst, wenn du auch diese Sektion leerst oder entfernst.

Prüfhinweise unter der Ausgabe

Unter dem Editor prüft der Generator die Ausgabe laufend mit demselben Validator wie der Check-Tab. Oben steht ein Badge zum Python-Referenz-Parser: grün „Python reference parser reads it", wenn das Python-Paket llms-txt die Datei lesen kann, sonst grau „Python reference parser can't read it (optional tool)". Grau ist kein Fehler — seit v2 gehört dieses Werkzeug nicht mehr zum Vorschlag. Darunter folgen die Meldungen, mit Symbol nach Stufe: zuerst Fehler und Warnungen des Validators, dann die Hinweise des Generators (etwa zu ausgelassenen Links, Maskierung oder Section-Text) und zuletzt die Info-Meldungen. Welche Regeln dahinterstehen, steht unter Was der Validator prüft.

Serving & discovery: Konfiguration für den Server

Die Karte Serving & discovery unter den Prüfhinweisen erzeugt Konfigurationsschnipsel, damit die Datei korrekt ausgeliefert und von deinen Seiten aus gefunden wird. Das Tool erinnert daran: Die Datei gehört an den Pfad, den sie beschreibt — /llms.txt gilt für die ganze Site, /docs/llms.txt nur für /docs/.

• Path — das Verzeichnis, in dem die Datei liegt (Standard /). Erlaubt sind nur Buchstaben, Ziffern und . _ ~ - zwischen Schrägstrichen; fehlende Schrägstriche am Anfang und Ende ergänzt das Tool. Ein ungültiger Pfad wird rot markiert.
• nginx / Apache / HTML — Umschalter für die Art des Schnipsels; Copy kopiert ihn.

Für den Pfad /docs/ erzeugt der nginx-Schalter diesen Block für den Server-Block:

# nginx (server block): serve llms.txt and markdown pages as UTF-8 text
location = /docs/llms.txt {
    types { }
    default_type "text/plain; charset=utf-8";
}
location ~ \.md$ {
    types { }
    default_type "text/markdown; charset=utf-8";
}

# Every page points to the llms.txt that covers it (llms.txt v2)
add_header Link '</docs/llms.txt>; rel="describedby"' always;

Die Apache-Variante (für VirtualHost oder .htaccess) setzt AddType text/markdown .md und AddCharset utf-8 .txt .md und hängt per mod_headers den Header Link: </docs/llms.txt>; rel="describedby" an jede Antwort. Die HTML-Variante liefert die beiden <link>-Elemente für den <head>: rel="describedby" auf die llms.txt für jede abgedeckte Seite und rel="alternate" type="text/markdown" auf die Markdown-Version einer Seite.

Open File und automatisches Speichern

Mit Open File öffnest du eine vorhandene Datei (.txt oder .md, höchstens 5 MB); alternativ ziehst du sie einfach auf die Formularspalte. Das Tool liest sie im Browser, parst sie und füllt das Formular damit — Titel, Summary, Details, Sektionen, Links, Subsektionen und einen llms-full.txt-Link aus ## Optional.

Das Laden ist verlustfrei bis auf den Namen des llms-full.txt-Links (siehe unten): Was das Formular nicht als Feld abbilden kann, landet als Text in den Details oder im Section-Text, statt wegzufallen. Ein Byte-Order-Mark am Anfang wird entfernt. Musste das Tool etwas anpassen, erscheint über dem Formular ein Hinweiskasten „Loaded … — adjusted to fit the form" mit den Anpassungen und Zeilennummern (je Meldung die ersten fünf, dann „and N more"), zum Beispiel:

• Zeilen vor der H1 wandern in die Details;
• Überschriften in den Details werden maskiert (\#);
• Text unter einer H3-Subsektion wandert in den Section-Text;
• Zeilen in Sektionen, die keine Links sind, bleiben als Section-Text erhalten (vor den Links ausgegeben);
• Notizen nach einem Link beginnen künftig mit : (ein Trenner wie - wird ersetzt);
• Listenzeichen * und + werden zu -;
• eingerückte, verschachtelte Listenpunkte werden zu normalen Links.

Einige Normalisierungen nimmt das Tool still vor, ohne sie im Hinweiskasten zu nennen: Eine mehrzeilige Summary wird zu einer Zeile zusammengezogen, Leerzeichenfolgen in Linknamen und Notizen werden zu einem Leerzeichen, und der llms-full.txt-Link — beim Laden erkannt am Namen llms-full.txt oder an einer URL, die llms-full enthält — heißt beim Schreiben immer llms-full.txt (ein eigener Linkname geht dabei verloren) und landet hinter den übrigen direkten Links einer vorhandenen ## Optional-Sektion bzw. in einer neuen ## Optional-Sektion am Dateiende; ohne eigene Notiz bekommt er den Standardtext „The complete documentation in one file".

Unabhängig davon sichert der Generator deinen Zwischenstand bei jeder Änderung lokal im Browser (LocalStorage) — schließt du den Tab und kommst zurück, ist deine Arbeit wieder da. Reset löscht diesen Speicher.

Der Check-Tab: live prüfen und validieren

Der Check-Tab holt eine bestehende llms.txt von einer beliebigen Domain und prüft sie gegen die llmstxt.org (öffnet in neuem Tab)-Spezifikation (englisch). Mögliche Eingaben:

• eine Domain (z. B. example.com) — /llms.txt wird automatisch angehängt;
• ein Verzeichnis mit abschließendem Schrägstrich (z. B. example.com/docs/) — geprüft wird /docs/llms.txt;
• eine volle URL.

Fehlt das Schema, ergänzt das Tool https://. Standardmäßig läuft der Abruf über den serverseitigen Proxy. Optional gibt es einen Expert Mode (Umschalter im Seitenkopf), der die Datei über einen selbst betriebenen lokalen Proxy auf http://127.0.0.1:<port> holt — fortgeschritten und für den Normalbetrieb nicht nötig.

Was der Validator prüft

Die Validierung läuft clientseitig in deinem Browser und prüft Struktur und Format gegen die Spezifikation v2. Inhalte in Code-Blöcken (``` oder ~~~) zählen nie als Struktur. Meldungen derselben Art fasst der Validator zu einer Zeile zusammen und hängt die betroffenen Zeilennummern an (die ersten fünf, dann „and N more"). Das Ergebnis ist in drei Stufen gegliedert:

• Errors (rot) — Verstöße gegen das, was die Spezifikation verlangt:
  • leere Datei;
  • Inhalt vor der H1 — die Datei muss mit # Name beginnen;
  • fehlende H1-Überschrift bzw. eine vorhandene, aber leere H1;
  • ein Link mit leerer URL.
• Warnings (gelb, solltest du beheben):
  • kein Blockquote-Summary nach der H1 (optional, aber das, was Agenten zuerst lesen) bzw. ein Blockquote, das nicht direkt auf die H1 folgt;
  • Überschriften in den Details vor der ersten H2;
  • mehr als eine H1; leere H2; derselbe Sektionsname zweimal (Parser, die Sektionen nach Namen ablegen, behalten nur die letzte);
  • Listenpunkt ohne Link — jeder Eintrag einer Link-Liste braucht [Name](URL);
  • anderes Listenzeichen als - (der Referenz-Parser liest nur -);
  • Link mit leerem Namen;
  • relative URL — Agenten lesen die Datei womöglich losgelöst von ihrem Ort, nötig sind absolute URLs;
  • Notiz nach dem Link ohne : als Trenner;
  • Link, den der Referenz-Parser anders liest (] im Namen, ( ) in der URL — als %28 %29 kodieren);
  • nicht geschlossener Code-Block;
  • keine ##-Sektionen bzw. keine Links;
  • große Datei über 50.000 Bytes — Details gehören in die verlinkten Seiten.
• Info (Hinweise):
  • Fließtext in einer Link-Sektion bzw. H3-Subsektionen — nicht Teil der Spezifikation, für Agenten unproblematisch;
  • Link mit http:// statt https://;
  • „N of M links have no notes" — eine kurze Notiz hilft Agenten bei der Auswahl;
  • Sektion „Optional" — seit v2 eine Konvention ohne Sonderbehandlung;
  • Byte-Order-Mark am Anfang — seit v2 erlaubt;
  • sehr kurze Datei (unter 100 Bytes);
  • der Python-Referenz-Parser kann die Datei nicht lesen, mit Grund (z. B. kein Text zwischen H1 und erster Sektion oder Zeilen in Sektionen, die keine Links sind) — betrifft nur dieses Werkzeug;
  • die Erfolgsmeldung: „Structure follows the llms.txt specification", wenn weder Fehler noch Warnungen noch Abweichungen vorliegen, bzw. „No errors or warnings — minor deviations from the spec are listed as notes", wenn nur Section-Text oder H3 auffallen.

Kurz gefasst: Eine H1 am Anfang und keine leeren Link-URLs sind hart Pflicht (Fehler). Summary, Sektionen, saubere Link-Syntax und absolute URLs sind dringend empfohlen (Warnung), Notizen und https:// Feinschliff (Info).

Was der Check an der HTTP-Antwort prüft

Bevor der Inhalt validiert wird, bewertet der Check-Tab die Antwort des Servers selbst. Diese Meldungen erscheinen in denselben Listen:

• Fehler: Der Server liefert eine HTML-Seite (Content-Type text/html oder ein Inhalt, der mit <!doctype html bzw. <html beginnt) — meist gibt es dann gar keine llms.txt, und du siehst eine Fehler- oder Startseite.
• Warnung: anderer Content-Type als text/plain oder text/markdown.
• Warnung: Content-Type ohne charset=utf-8, obwohl die Datei Nicht-ASCII-Zeichen enthält — Browser und manche Clients zeigen Umlaute dann falsch.
• Warnung: Die Datei ist kein gültiges UTF-8.
• Warnung: Die Datei ist größer als 1 MB — geprüft wurde nur das erste Megabyte.
• Info: Die Anfrage wurde weitergeleitet („Redirected to …").

Liefert die Adresse HTTP 404 oder einen anderen Status außerhalb von 2xx, meldet das Tool „No llms.txt at … (HTTP nnn)"; eine leere Antwort meldet es als „returned an empty file", einen gescheiterten Abruf mit der Fehlermeldung.

Das Check-Ergebnis lesen

Oben steht ein Statusbanner mit der abgerufenen URL, dem HTTP-Status, dem Content-Type und einem Verdict:

• grün „No errors or warnings." — 0 Fehler und 0 Warnungen;
• gelb „N warning(s)." — keine Fehler, aber Warnungen;
• rot „N error(s)." — mindestens ein Fehler.

Darunter eine Summary-Tabelle:

Es folgen die Listen Errors, Warnings und Info (jeweils mit Anzahl, nur wenn nicht leer), die Karte Linked pages (siehe unten) und ein einklappbarer Raw content-Block mit Zeilennummern. Von dort kannst du den Rohinhalt per Copy kopieren oder per Load into Generator ins Formular übernehmen, um die Datei zu reparieren — das Laden funktioniert genauso verlustfrei wie Open File; hat der Generator schon eine Ausgabe, fragt das Tool vorher nach — wegen der vorbelegten Sektion „Documentation" ist das praktisch immer der Fall, außer du hast sie geleert oder entfernt.

Link-Check: die verlinkten Seiten prüfen

Enthält die Datei Links, zeigt die Karte Linked pages einen Button Check all N links — bei mehr als 20 Links Check the first 20 of N links. Der Link-Check läuft auf Knopfdruck, die Links nacheinander mit kurzer Pause. Relative URLs löst das Tool gegen die (ggf. weitergeleitete) Adresse der llms.txt auf. Für jeden Link fragt der Proxy nur Status und Content-Type ab (per HEAD-Request; lehnt der Server HEAD ab, mit einem kleinen GET). Die Tabelle zeigt Nummer, Link, Status, Typ und eine Bewertung:

• OK bzw. Redirect → Ziel — erreichbar, kein HTML (z. B. Markdown oder Text);
• HTML page — a markdown version (.md) is easier for agents — erreichbar, aber eine HTML-Seite;
• Broken link — Status 400 oder höher;
• Not an http(s) URL bzw. No response — nicht prüfbar oder keine Antwort.

Am Ende fasst eine Zeile zusammen, wie viele Links Markdown/Text, HTML oder kaputt bzw. nicht erreichbar sind.

Format-Referenz

Der Reference-Tab enthält die Spezifikation in der Fassung v2, die der Generator erzeugt und der Checker prüft: Markdown unter /llms.txt oder einem Unterpfad, in dieser Reihenfolge. Die Elemente:

Das Komplettbeispiel im Reference-Tab (Complete Format) kopierst du per Copy als Vorlage. Am Ende des Tabs verlinkt Further Reading die Spezifikation, das GitHub-Repository mit Änderungsprotokoll und Python-Referenz-Parser, drei Verzeichnisse von Websites mit llms.txt, die Beschreibung des Lighthouse-Audits und zwei reale Beispieldateien.

llms-full.txt — die kombinierte Inhaltsdatei

llms-full.txt enthält den zusammengeführten Textinhalt aller in der llms.txt verlinkten Seiten in einer einzigen großen Datei. Nützlich für LLM-Clients, die große Kontextfenster in einem Request verarbeiten, viele Einzel-HTTP-Requests vermeiden oder einen gecachten/Offline-Snapshot deiner Doku brauchen. Das Tool stellt klar, dass llms-full.txt eine Konvention ist und nicht zum llms.txt-Vorschlag gehört. Erzeugen solltest du sie beim Build, indem du die Markdown-Versionen der verlinkten Seiten aneinanderhängst.

Markdown-Versionen und Discovery (v2)

Der Reference-Tab fasst die Konventionen aus v2 zusammen, mit denen Agenten an saubere Inhalte kommen:

• Seiten, die Agenten brauchen könnten, bekommen eine Markdown-Version unter derselben URL: page.html.md (angehängt) oder page.md (Endung ersetzt); Verzeichnisse nutzen index.html.md bzw. index.md.
• rel="alternate" type="text/markdown" zeigt von einer Seite auf ihre Markdown-Version.
• rel="describedby" zeigt von einer Seite auf die llms.txt, die sie abdeckt.
• Beides geht als <link> im HTML oder als HTTP-Header Link: — der Header funktioniert auch für die Markdown-Dateien selbst.

Link: </docs/page.html.md>; rel="alternate"; type="text/markdown", </docs/llms.txt>; rel="describedby"

Die passenden Server-Schnipsel erzeugt der Generator unter Serving & discovery, die Linkziele stellst du unter Linkziele: Markdown-Versionen um.

Limits, Architektur und Datenschutz

• Generator: rein clientseitig. Die Datei wird vollständig in deinem Browser zusammengebaut und geprüft; auch eine per Open File geöffnete Datei liest der Browser selbst. Nichts wird übertragen. Dein Zwischenstand liegt im LocalStorage.
• Check und Link-Check: serverseitiger Proxy. Dein Browser darf eine fremde llms.txt wegen CORS nicht direkt laden. Ein serverseitiger JPKCom-Proxy holt sie per cURL und gibt Inhalt, Status, Content-Type und finale URL zurück; beim Link-Check fragt er nur Status und Content-Type ab. Validiert wird wieder lokal in deinem Browser. Die geprüfte Domain sieht den Request vom JPKCom-Server (mit dessen User-Agent), nicht deine IP-Adresse.
• SSRF-Schutz: Der Proxy blockiert localhost-, interne, private und reservierte IP-Adressen und prüft jeden Redirect-Hop erneut; nur HTTP und HTTPS sind erlaubt. Eine lokale Dev- oder Intranet-Datei lässt sich so nicht prüfen (dafür gibt es den Expert Mode mit lokalem Proxy).
• Abruf-Grenzen: Body-Limit 1 MB — größere Dateien werden abgeschnitten und nur das erste Megabyte geprüft (mit Warnung). Timeout 10 s pro Abruf, höchstens 30 s über alle Weiterleitungen, maximal 5 Redirect-Hops.
• Rate-Limits: Zwischen zwei Checks liegen im Browser mindestens 3 Sekunden (im Expert Mode umgangen); feuerst du schneller, bittet das Tool dich kurz zu warten. Serverseitig nimmt der Proxy pro IP-Adresse höchstens 120 Anfragen pro Minute an, sonst meldet das Tool „Too many requests — please wait a minute". Der Link-Check prüft deshalb maximal 20 Links pro Durchgang.
• Kein öffentliches API: Die beiden serverseitigen Endpunkte (Fetch-Proxy und ein token-basierter Authentifizierungs-Endpunkt) werden ausschließlich vom JavaScript des Tools genutzt und sind gegen Missbrauch gehärtet — sie sind nicht dafür gedacht, von außen aufgerufen zu werden.

Für den Einstieg und das große Bild siehe die Übersichtsseite, für konkrete Durchläufe die Beispiele und für Strategie die Tipps & Tricks. Ausprobieren kannst du alles direkt im Tool.