Von robots.txt zu agents.json: Die Evolution der Website-Discovery

Matthias Meyer

Jede Aera des Webs hat eine neue Datei hervorgebracht, die Maschinen erklaert, was auf einer Website zu finden ist. 1994 war es robots.txt. 2005 kam sitemap.xml. 2011 brachte schema.org strukturierte Daten. Und jetzt, 2025, steht agents.json an der Tuer.

Das ist kein Zufall. Es ist ein Muster. Und wer es versteht, sieht klarer, wohin das Web sich entwickelt.

1994: robots.txt -- "Bitte nicht hier lang"

Im Juni 1994 veroeffentlichte Martijn Koster den Robots Exclusion Protocol Standard. Das Problem war simpel: Webcrawler besuchten Seiten, die nicht besucht werden sollten -- Admin-Bereiche, temporaere Dateien, private Verzeichnisse.

Die Lösung war eine Textdatei im Wurzelverzeichnis einer Website:

User-agent: *
Disallow: /admin/
Disallow: /tmp/
Allow: /

Was robots.txt macht

Verbieten: Sagt Crawlern, welche Pfade sie nicht besuchen sollen
Erlauben: Definiert Ausnahmen innerhalb verbotener Bereiche
User-agent: Unterscheidet zwischen verschiedenen Bots (Googlebot, Bingbot, etc.)

Was robots.txt nicht macht

robots.txt ist eine hoefliche Bitte, kein Sicherheitsmechanismus. Es gibt keinen technischen Schutz -- jeder Bot kann die Anweisungen ignorieren. Serioese Suchmaschinen halten sich daran, Scraper und Spam-Bots nicht.

Trotzdem: Heute hat praktisch jede Website eine robots.txt. Was 1994 als informelle Konvention begann, ist de facto Standard geworden. Kein RFC, kein W3C-Standard -- einfach eine Textdatei, die sich durchgesetzt hat.

Die Perspektive

robots.txt beantwortet eine einzige Frage: "Was soll eine Maschine NICHT tun?" Es ist eine Negativliste. Es sagt nichts darüber, was auf einer Website ist -- nur was nicht besucht werden soll.

2005: sitemap.xml -- "Hier ist alles, was wir haben"

Elf Jahre später hatte Google ein anderes Problem: Wie findet ein Crawler effizient alle relevanten Seiten einer Website? Besonders bei großen Websites mit tausenden Unterseiten war das Crawling langsam und unvollstaendig.

Google schlug sitemap.xml vor, Bing und Yahoo unterstuetzten es, und 2006 wurde es als sitemaps.org-Protokoll veroeffentlicht.

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/</loc>
    <lastmod>2026-02-01</lastmod>
    <changefreq>weekly</changefreq>
    <priority>1.0</priority>
  </url>
  <url>
    <loc>https://example.com/services</loc>
    <lastmod>2026-01-15</lastmod>
    <priority>0.8</priority>
  </url>
</urlset>

Der Paradigmenwechsel

Wo robots.txt sagte "Geh hier nicht hin", sagt sitemap.xml "Hier ist alles, was relevant ist." Es ist der Wechsel von einer Negativliste zu einer Positivliste.

URLs: Jede indexierbare Seite wird aufgelistet
Aktualitaet: lastmod sagt dem Crawler, wann sich eine Seite zuletzt geaendert hat
Prioritaet: Der Webmaster kann signalisieren, welche Seiten wichtiger sind
Referenz in robots.txt: Sitemap: https://example.com/sitemap.xml

Was sitemap.xml nicht macht

Es beschreibt wo Inhalte sind, aber nicht was sie sind. Eine URL wie /services sagt einer Suchmaschine nichts über den Inhalt der Seite. Dafür muss der Crawler die Seite besuchen und den HTML-Code analysieren.

2011: schema.org -- "Das bedeutet der Inhalt"

2011 gruendeten Google, Bing, Yahoo und Yandex gemeinsam schema.org. Das Ziel: strukturierte Daten, die Suchmaschinen nicht nur sagen wo Inhalte sind, sondern was sie bedeuten.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Pizzeria Roma",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Marienplatz 1",
    "addressLocality": "Muenchen"
  },
  "telephone": "+49 89 12345678",
  "openingHoursSpecification": {
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
    "opens": "11:00",
    "closes": "22:00"
  }
}
</script>

Was schema.org brachte

Semantik: Nicht nur "hier ist Text", sondern "das ist eine Adresse", "das ist ein Preis", "das sind Oeffnungszeiten"
Rich Snippets: Google zeigt Bewertungen, Preise, Oeffnungszeiten direkt in den Suchergebnissen
Knowledge Graph: Strukturierte Daten fuettern Googles Wissensdatenbank
Standardisierte Typen: Über 800 definierte Schemas für Personen, Organisationen, Events, Produkte, Rezepte und mehr

Der Fortschritt gegenüber sitemap.xml

sitemap.xml sagte: "Diese URLs existieren." schema.org sagt: "Auf dieser URL ist ein Restaurant mit diesen Oeffnungszeiten und dieser Speisekarte."

Der Crawler muss die Seite nicht mehr interpretieren. Die Bedeutung ist explizit kodiert.

Was schema.org nicht macht

schema.org beschreibt Inhalte, bietet aber keine Interaktion. Eine Suchmaschine kann lesen, dass ein Restaurant Dienstag bis Samstag offen hat -- aber sie kann keinen Tisch reservieren. Die Daten sind read-only.

2025: agents.json -- "Das koennt ihr hier tun"

Und hier schließt sich der Kreis. agents.json ist der nächste logische Schritt in dieser Evolution:

Datei	Jahr	Frage die sie beantwortet
robots.txt	1994	Was soll eine Maschine NICHT tun?
sitemap.xml	2005	WO sind die Inhalte?
schema.org	2011	WAS bedeuten die Inhalte?
agents.json	2025	Was KANN eine Maschine hier TUN?

agents.json liegt unter /.well-known/agents.json und beschreibt die Services einer Website als maschinenlesbare Tools:

{
  "version": "1.0",
  "tools": [
    {
      "name": "make_reservation",
      "description": "Tisch reservieren im Restaurant",
      "endpoint": "/api/v1/reservation",
      "method": "POST",
      "parameters": {
        "date": { "type": "string", "required": true, "description": "Datum (YYYY-MM-DD)" },
        "time": { "type": "string", "required": true, "description": "Uhrzeit (HH:MM)" },
        "guests": { "type": "number", "required": true, "description": "Anzahl Gaeste" },
        "name": { "type": "string", "required": true, "description": "Name der Reservierung" }
      }
    },
    {
      "name": "get_menu",
      "description": "Aktuelle Speisekarte abrufen",
      "endpoint": "/api/v1/menu",
      "method": "GET"
    }
  ]
}

Was agents.json anders macht

Interaktion: Nicht nur "lies diese Daten", sondern "ruf diesen Endpoint auf und du bekommst ein Ergebnis"
Parameter-Beschreibung: Ein KI-Agent weiss genau, welche Daten er senden muss
Methoden: GET für Lesen, POST für Aktionen -- klar definiert
Endpoints: Direkte URL zum Service, kein HTML-Parsing nötig

Der entscheidende Unterschied

Alle bisherigen Discovery-Dateien waren passiv: Sie beschrieben Inhalte, die gelesen werden können. agents.json ist aktiv: Es beschreibt Aktionen, die ausgeführt werden können.

robots.txt sagte: "Bitte nicht hier lang." sitemap.xml sagte: "Hier sind unsere Seiten." schema.org sagte: "Das hier ist ein Restaurant mit diesen Oeffnungszeiten." agents.json sagt: "Du kannst hier einen Tisch reservieren. So geht's."

Der ehrliche Stand: Wo stehen wir wirklich?

Was agents.json heute ist

agents.json ist ein Community-Proposal, kein offizieller Standard. Es wurde von der Community (Wildcard AI / nicepkg) entwickelt und ist kein W3C- oder IETF-Standard. Stand Februar 2026 gibt es keine Suchmaschine und keinen großen KI-Agenten, der agents.json aktiv ausliest und nutzt.

Die Parallele zu robots.txt

Das ist nicht so dramatisch, wie es klingt. robots.txt war auch kein offizieller Standard. Es war eine informelle Konvention unter Webmaster, die sich über Jahre durchgesetzt hat. Erst 2022 -- 28 Jahre nach der Einführung -- wurde robots.txt als RFC 9309 formalisiert.

sitemap.xml hatte einen aehnlichen Weg: Erst von Google vorgeschlagen, dann von anderen Suchmaschinen uebernommen, heute de facto Pflicht für SEO.

Was agents.json braucht, um sich durchzusetzen

Einen großen Akteur: Wenn ChatGPT, Gemini oder Claude anfangen, agents.json aktiv auszulesen, wird es schnell zum Standard
Einen klaren Nutzen: Websites mit agents.json müssen für KI-Agenten besser funktionieren als Websites ohne
Einfache Implementierung: Eine JSON-Datei ist einfacher als schema.org-Markup -- das ist ein Vorteil
Tooling: Generatoren, Validatoren, Debugging-Tools müssen entstehen

Warum das Muster wichtig ist

Unabhängig davon, ob genau agents.json der Standard wird oder eine Alternative sich durchsetzt -- das Muster ist klar:

1994: Maschinen lesen das Web (robots.txt: "Nicht hier")
2005: Maschinen indexieren das Web (sitemap.xml: "Hier sind wir")
2011: Maschinen verstehen das Web (schema.org: "Das bedeutet es")
202x: Maschinen nutzen das Web (agents.json: "Das koennnt ihr tun")

Jeder Schritt hat die vorherigen nicht ersetzt, sondern ergaenzt. Wir haben heute noch robots.txt und sitemap.xml und schema.org. agents.json (oder sein Nachfolger) wird sich dazugesellen.

Ein Blick auf die eigene Website

Die Frage ist nicht "Brauche ich agents.json?" -- die Frage ist: "Habe ich Services, die maschinenlesbar sein sollten?"

Wo agents.json Sinn macht

Restaurants: Speisekarte abrufen, Tisch reservieren
Aerzte/Kanzleien: Verfuegbarkeit prüfen, Termin buchen
Handwerker: Leistungen anzeigen, Angebot anfragen
E-Commerce: Produkte suchen, Verfuegbarkeit prüfen
Dienstleister: Services auflisten, Beratung buchen

Wo agents.json (noch) keinen Sinn macht

Reine Content-Websites: Ein Blog braucht keine agents.json. Schema.org und sitemap.xml reichen
Interne Tools: Keine oeffentlichen Services, kein Bedarf
Websites ohne API: Wenn es keine maschinenlesbaren Endpoints gibt, gibt es auch nichts zu beschreiben

Die Analogie zum Abschluss

1994 hätte man fragen können: "Brauche ich wirklich eine robots.txt? Meine Website hat nur 5 Seiten." Heute hat sie jede Website.

2005 hätte man fragen können: "Brauche ich wirklich eine sitemap.xml? Google findet meine Seiten doch." Heute ist es SEO-Standard.

2011 hätte man fragen können: "Brauche ich wirklich schema.org? Mein Content ist doch lesbar." Heute bestimmt es, ob Sie Rich Snippets bekommen.

2025 kann man fragen: "Brauche ich wirklich eine agents.json?" Vielleicht noch nicht. Aber das Muster spricht dafür, dass die Antwort in ein paar Jahren anders ausfaellt.

Zusammenfassung: 30 Jahre Discovery-Evolution

Jahr	Datei	Frage	Format	Status heute
1994	robots.txt	Was NICHT?	Plaintext	RFC 9309 (2022), universal
2005	sitemap.xml	WO?	XML	SEO-Standard, universal
2011	schema.org	WAS?	JSON-LD	SEO-Faktor, weit verbreitet
2025	agents.json	Was KANN man TUN?	JSON	Community-Proposal, frueh

Die Richtung ist klar: Von Verboten über Listen über Bedeutung hin zu Interaktion. Ob agents.json der endgueltige Name ist oder sich ein anderes Format durchsetzt, ist weniger wichtig als das zugrundeliegende Konzept: Websites müssen KI-Agenten nicht nur zeigen was sie haben, sondern erklären was man damit tun kann.

Das Web war immer dann am besten, wenn es neue Teilnehmer willkommen geheissen hat. Erst Menschen mit HTML. Dann Suchmaschinen mit robots.txt und sitemap.xml. Dann Wissenssysteme mit schema.org. Und jetzt KI-Agenten mit agents.json.

Die nächste Discovery-Datei wird kommen. Die Frage ist nur, ob Ihre Website bereit ist.