---
title: "Von robots.txt zu agents.json: Die Evolution der Website-Discovery"
description: "1994 kam robots.txt, 2005 sitemap.xml, 2011 schema.org, jetzt agents.json. Jede Ära brachte eine neue Discovery-Datei. Geschichte und Zukunft."
author: "Matthias Meyer"
published: 2026-02-15
updated: 2026-02-15
language: de
tags: ["robots-txt", "agents-json", "sitemap", "schema-org", "discovery", "web-history"]
canonical: "https://studiomeyer.io/de/blog/robots-txt-zu-agents-json"
markdown_versions: ["https://studiomeyer.io/de/blog/robots-txt-zu-agents-json.md", "https://studiomeyer.io/en/blog/robots-txt-zu-agents-json.md", "https://studiomeyer.io/es/blog/robots-txt-zu-agents-json.md"]
publisher: "StudioMeyer, https://studiomeyer.io (llms.txt: https://studiomeyer.io/llms.txt)"
---

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

Jede Ära des Webs hat eine neue Datei hervorgebracht, die Maschinen erklärt, 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 veröffentlichte 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 unterstützten es, und 2006 wurde es als sitemaps.org-Protokoll veröffentlicht.

```xml
<?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 geändert 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*.

```html
<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 Öffnungszeiten"
- **Rich Snippets:** Google zeigt Bewertungen, Preise, Öffnungszeiten 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 Öffnungszeiten 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 könnt 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:

```json
{
  "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 Öffnungszeiten."
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 ähnlichen Weg: Erst von Google vorgeschlagen, dann von anderen Suchmaschinen übernommen, heute de facto Pflicht für SEO.

### Was agents.json braucht, um sich durchzusetzen

1. **Einen großen Akteur:** Wenn ChatGPT, Gemini oder Claude anfangen, agents.json aktiv auszulesen, wird es schnell zum Standard
2. **Einen klaren Nutzen:** Websites mit agents.json müssen für 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 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 könnnt ihr tun")
```

Jeder Schritt hat die vorherigen nicht ersetzt, sondern ergänzt. 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
- **Ärzte/Kanzleien:** Verfügbarkeit prüfen, Termin buchen
- **Handwerker:** Leistungen anzeigen, Angebot anfragen
- **E-Commerce:** Produkte suchen, Verfügbarkeit 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, früh |

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.

## Weiterlesen, AI-Ready Websites

- [Häng .md an jede unserer Blog-URLs. Darum ist das wichtig](https://studiomeyer.io/de/blog/agent-readable-blog.md)
- [AI-Ready ist universell. Hosting ist regional.](https://studiomeyer.io/de/blog/ai-ready-hosting-regionen.md)
- [AI-Ready Webdesign 2026: Wenn deine Website fuer Menschen UND Maschinen gebaut ist](https://studiomeyer.io/de/blog/ai-ready-webdesign-2026.md)
- [AI-Ready vs. klassische Website: Was sich wirklich ändert](https://studiomeyer.io/de/blog/ai-ready-vs-klassisch.md)