Zum Hauptinhalt springen
Von robots.txt zu agents.json: Die Evolution der Website-Discovery
Zurück zum Blog
KI & Automatisierung 15. Februar 2026 10 min Lesezeitvon Matthias Meyer

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

1994 kam robots.txt, 2005 sitemap.xml, 2011 schema.org -- und jetzt agents.json. Jede Ära brachte eine neue Discovery-Datei. Die Geschichte und Zukunft der Website-Erkennung.

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 Loesung 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 darueber, was auf einer Website ist -- nur was nicht besucht werden soll.

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

Elf Jahre spaeter hatte Google ein anderes Problem: Wie findet ein Crawler effizient alle relevanten Seiten einer Website? Besonders bei grossen 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 ueber den Inhalt der Seite. Dafuer 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: Ueber 800 definierte Schemas fuer Personen, Organisationen, Events, Produkte, Rezepte und mehr

Der Fortschritt gegenueber 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 schliesst sich der Kreis. agents.json ist der naechste logische Schritt in dieser Evolution:

DateiJahrFrage die sie beantwortet
robots.txt1994Was soll eine Maschine NICHT tun?
sitemap.xml2005WO sind die Inhalte?
schema.org2011WAS bedeuten die Inhalte?
agents.json2025Was 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 fuer Lesen, POST fuer Aktionen -- klar definiert
  • Endpoints: Direkte URL zum Service, kein HTML-Parsing noetig

Der entscheidende Unterschied

Alle bisherigen Discovery-Dateien waren passiv: Sie beschrieben Inhalte, die gelesen werden koennen. agents.json ist aktiv: Es beschreibt Aktionen, die ausgefuehrt werden koennen.

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 grossen 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 ueber Jahre durchgesetzt hat. Erst 2022 -- 28 Jahre nach der Einfuehrung -- 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 fuer SEO.

Was agents.json braucht, um sich durchzusetzen

  1. Einen grossen Akteur: Wenn ChatGPT, Gemini oder Claude anfangen, agents.json aktiv auszulesen, wird es schnell zum Standard
  2. Einen klaren Nutzen: Websites mit agents.json muessen fuer KI-Agenten besser funktionieren als Websites ohne
  3. Einfache Implementierung: Eine JSON-Datei ist einfacher als schema.org-Markup -- das ist ein Vorteil
  4. Tooling: Generatoren, Validatoren, Debugging-Tools muessen entstehen

Warum das Muster wichtig ist

Unabhaengig 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 pruefen, Termin buchen
  • Handwerker: Leistungen anzeigen, Angebot anfragen
  • E-Commerce: Produkte suchen, Verfuegbarkeit pruefen
  • 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 haette man fragen koennen: "Brauche ich wirklich eine robots.txt? Meine Website hat nur 5 Seiten." Heute hat sie jede Website.

2005 haette man fragen koennen: "Brauche ich wirklich eine sitemap.xml? Google findet meine Seiten doch." Heute ist es SEO-Standard.

2011 haette man fragen koennen: "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 dafuer, dass die Antwort in ein paar Jahren anders ausfaellt.

Zusammenfassung: 30 Jahre Discovery-Evolution

JahrDateiFrageFormatStatus heute
1994robots.txtWas NICHT?PlaintextRFC 9309 (2022), universal
2005sitemap.xmlWO?XMLSEO-Standard, universal
2011schema.orgWAS?JSON-LDSEO-Faktor, weit verbreitet
2025agents.jsonWas KANN man TUN?JSONCommunity-Proposal, frueh

Die Richtung ist klar: Von Verboten ueber Listen ueber 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 muessen KI-Agenten nicht nur zeigen was sie haben, sondern erklaeren 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 naechste Discovery-Datei wird kommen. Die Frage ist nur, ob Ihre Website bereit ist.

Matthias Meyer

Matthias Meyer

Gründer & KI-Architekt

Full-Stack-Entwickler mit über 10 Jahren Erfahrung in Webdesign und KI-Systemen. Baut AI-Ready Websites und KI-Automatisierungen für KMU und Agenturen.

robots-txtagents-jsonsitemapschema-orgdiscoveryweb-history
Von robots.txt zu agents.json: Die Evolution der Website-Discovery