KI-Crawler steuern: TDM-Vorbehalt rechtssicher setzen

Fast jede SEO-Diskussion dreht sich derzeit um dieselbe Frage: Wie werde ich von KI-Systemen gefunden? Dieser Beitrag dreht die Perspektive um, ohne sie gegen Sichtbarkeit auszuspielen. Denn nach Artikel 4 der DSM-Richtlinie (EU) 2019/790 und § 44b UrhG ist Text und Data Mining an rechtmäßig zugänglichen Werken grundsätzlich zulässig – es sei denn, der Rechtsinhaber hat sich die Nutzung vorbehalten, und zwar bei online zugänglichen Inhalten in maschinenlesbarer Form (EUR-Lex; gesetze-im-internet.de). Wer nichts erklärt, erlaubt faktisch alles. Wer dagegen pauschal jeden Bot aussperrt, verliert Antwortqualität und Referral-Traffic aus generativen Suchsystemen. Die eigentliche Aufgabe ist deshalb Differenzierung: Trainings-Crawler und Retrieval-Crawler auseinanderhalten, den Nutzungsvorbehalt an drei Stellen sauber setzen und ihn dort technisch durchsetzen, wo die robots.txt an ihre Grenzen stößt. Dieser Leitfaden zeigt den rechtlichen Rahmen, die technische Umsetzung und eine Differenzierungsstrategie, die zur KI-Sichtbarkeit Ihres Shops und zu Ihrer Suchmaschinenoptimierung passt.

Text und Data Mining ist erlaubt, solange Sie nicht widersprechen

§ 44b UrhG definiert Text und Data Mining als die automatisierte Analyse von einzelnen oder mehreren digitalen oder digitalisierten Werken, um daraus Informationen insbesondere über Muster, Trends und Korrelationen zu gewinnen (gesetze-im-internet.de). Absatz 2 erlaubt dazu ausdrücklich Vervielfältigungen von rechtmäßig zugänglichen Werken. Entscheidend ist Absatz 3: Solche Nutzungen sind nur zulässig, wenn der Rechtsinhaber sie sich nicht vorbehalten hat – und ein Nutzungsvorbehalt bei online zugänglichen Werken ist nur dann wirksam, wenn er in maschinenlesbarer Form erfolgt (gesetze-im-internet.de). Die deutsche Norm setzt Artikel 4 der Richtlinie (EU) 2019/790 vom 17. April 2019 um (EUR-Lex).

Damit kehrt sich die vertraute urheberrechtliche Logik um. Sonst gilt: Nutzung nur mit Erlaubnis. Beim Text und Data Mining gilt: Nutzung ist erlaubt, bis Sie widersprechen. Erwägungsgrund 18 der DSM-Richtlinie stellt klar, dass bei online öffentlich zugänglich gemachten Inhalten ein Rechtsvorbehalt mit maschinenlesbaren Mitteln angemessen ist – ausdrücklich einschließlich Metadaten und Geschäftsbedingungen einer Website oder eines Dienstes (EUR-Lex). Genau daraus leitet sich die Drei-Ebenen-Struktur ab, die weiter unten beschrieben wird. Für Betreiber eines Online-Shops ist das keine akademische Frage: Produktbeschreibungen, Ratgeberartikel, Testberichte und eigene Produktfotos sind in der Regel urheberrechtlich relevante Investitionen.

Auf europäischer Ebene ist der Vorbehalt inzwischen auch aufsichtsrechtlich verankert. Artikel 53 Absatz 1 Buchstabe c der KI-Verordnung (EU) 2024/1689 verpflichtet Anbieter von KI-Modellen mit allgemeinem Verwendungszweck, eine Urheberrechts-Policy einzuführen sowie Rechtsvorbehalte nach Artikel 4 Absatz 3 der DSM-Richtlinie zu erkennen und einzuhalten (Europäische Kommission). Der am 10. Juli 2025 veröffentlichte Verhaltenskodex für KI-Modelle mit allgemeinem Verwendungszweck konkretisiert das: Unterzeichner verpflichten sich, Crawler einzusetzen, die Rechtsvorbehalte über das Robots Exclusion Protocol auslesen und befolgen, und zusätzlich weitere geeignete maschinenlesbare Protokolle zu berücksichtigen (Europäische Kommission).

Trainings-Crawler, Retrieval-Crawler und Agenten-Fetcher unterscheiden

Der Sammelbegriff KI-Crawler verdeckt, dass sehr unterschiedliche Zugriffsarten dahinterstehen. Die Crawler-Übersicht von Google unterscheidet drei Kategorien: common crawlers für Produkte wie die Google Suche, die die robots.txt-Regeln befolgen, special-case crawlers für Produkte mit gesonderter Vereinbarung zwischen Website und Dienst sowie user-triggered fetchers, also Abrufe, die eine Nutzerin oder ein Nutzer selbst auslöst (Google Search Central). Wer diese Ebenen vermischt, trifft zwangsläufig grobe Entscheidungen.

Wie sauber diese Trennung technisch funktionieren kann, zeigt das Token Google-Extended. Laut Dokumentation ist es ein eigenständiges Produkt-Token, mit dem Websites steuern, ob gecrawlte Inhalte für das Training künftiger Gemini-Modelle und für das Grounding in Gemini-Apps und Vertex AI verwendet werden dürfen. Ausdrücklich gilt: Das Token hat keinen Einfluss auf die Aufnahme einer Website in die Google Suche und ist kein Ranking-Signal (Google Search Central). Sie können KI-Training also einschränken, ohne Ihre organische Sichtbarkeit anzutasten – ein Muster, das sich auf andere Anbieter übertragen lässt, sofern diese separate Tokens dokumentieren.

Den Nutzungsvorbehalt an drei Stellen rechtswirksam setzen

Jede der drei Ebenen hat eine eigene Schwäche: Die robots.txt ist weit verbreitet, aber urheberrechtlich unspezifisch. Nutzungsbedingungen sind rechtlich präzise, aber schwer automatisiert auswertbar. TDMRep ist maschinenlesbar im engeren Sinn, aber bislang kein verabschiedeter Standard. Erst zusammen ergeben sie eine Erklärung, die sowohl von Crawlern gelesen als auch von Gerichten gewürdigt werden kann. Die Umsetzung gehört in die Serverkonfiguration und damit in Ihr Hosting.

Ebene 1: robots.txt mit differenzierten Tokens

Die robots.txt ist der Kanal, den nahezu jeder seriöse Crawler ausliest. Wichtig ist, nicht mit User-agent: * und Disallow: / zu arbeiten, sondern pro Produkt-Token zu entscheiden. Das folgende Muster lässt die klassische Suche unberührt, behält sich redaktionelle Inhalte und eigene Bilder für das KI-Training vor und hält den Rest offen:

# 1) Klassische Suche unangetastet lassen
User-agent: Googlebot
Allow: /

# 2) KI-Training: redaktionelle Inhalte und eigene Bilder vorbehalten
User-agent: Google-Extended
Disallow: /ratgeber/
Disallow: /magazin/
Disallow: /testberichte/
Disallow: /media/produktfotos/
Allow: /

# 3) Unbekannte Sammler zunächst beobachten, nicht blind sperren
User-agent: *
Disallow: /warenkorb/
Disallow: /suche/
Disallow: /kundenkonto/
Allow: /

Sitemap: https://www.example.com/sitemap.xml

Ebene 2: Nutzungsbedingungen als rechtlicher Anker

Erwägungsgrund 18 der DSM-Richtlinie nennt Geschäftsbedingungen einer Website ausdrücklich als mögliches Mittel des Rechtsvorbehalts (EUR-Lex). Sie sind allein nicht ausreichend maschinenlesbar, tragen aber die inhaltliche Präzision, die robots.txt und TDMRep nicht liefern können. Eine belastbare Klausel sollte diese Punkte abdecken:

• Ausdrückliche Erklärung des Nutzungsvorbehalts nach § 44b Absatz 3 UrhG und Artikel 4 Absatz 3 der Richtlinie (EU) 2019/790
• Klare Bezeichnung der erfassten Inhalte: Texte, Bilder, Videos, Bewertungen, strukturierte Daten
• Abgrenzung der erlaubten Nutzung: Indexierung für Suchdienste und Beantwortung konkreter Anfragen mit Quellenangabe bleiben zulässig
• Verweis auf die maschinenlesbare Entsprechung: robots.txt sowie /.well-known/tdmrep.json
• Kontaktweg für Lizenzanfragen mit Nennung der zuständigen Stelle im Unternehmen
• Datumsangabe und Versionierung, damit der Stand zum Zeitpunkt eines Crawls belegbar bleibt

Wie stark dieser Kanal genutzt wird, zeigt eine groß angelegte Längsschnittstudie: Bei einer Auswertung von rund 14.000 Web-Domains aus gängigen Trainingskorpora waren 45 Prozent des C4-Korpus über Nutzungsbedingungen eingeschränkt (Data Provenance Initiative). Gleichzeitig stellte die Untersuchung erhebliche Widersprüche zwischen dem fest, was Websites in ihren Nutzungsbedingungen erklären, und dem, was ihre robots.txt tatsächlich signalisiert (Data Provenance Initiative). Genau diese Inkonsistenz sollten Sie vermeiden.

Ebene 3: TDMRep als maschinenlesbare Erklärung

Das TDM Reservation Protocol (TDMRep) wurde als Antwort auf Artikel 4 der DSM-Richtlinie entwickelt und liegt seit dem 10. Mai 2024 als Final Community Group Report vor; ein offizieller W3C-Standard ist es nicht (w3.org). Das Modell besteht aus nur zwei Eigenschaften: tdm-reservation als boolescher Wert (1 = Rechte vorbehalten, 0 = nicht vorbehalten) und tdm-policy als URL, unter der Kontakt und Lizenzbedingungen abrufbar sind (w3.org). Es gibt drei Umsetzungswege – eine Datei unter /.well-known/tdmrep.json, HTTP-Antwortheader und HTML-Metadaten (w3.org).

[
  {
    "location": "/",
    "tdm-reservation": 0
  },
  {
    "location": "/ratgeber/",
    "tdm-reservation": 1,
    "tdm-policy": "https://www.example.com/tdm-policy.json"
  },
  {
    "location": "/media/produktfotos/",
    "tdm-reservation": 1,
    "tdm-policy": "https://www.example.com/tdm-policy.json"
  }
]

# Variante A: HTTP-Antwortheader (nginx, nur für Ratgeber-Pfade)
location /ratgeber/ {
    add_header tdm-reservation 1 always;
    add_header tdm-policy "https://www.example.com/tdm-policy.json" always;
}

<!-- Variante B: HTML-Metadaten im Head der jeweiligen Seite -->
<meta name="tdm-reservation" content="1">
<meta name="tdm-policy" content="https://www.example.com/tdm-policy.json">

Grenzen der robots.txt: eine Bitte, keine Sperre

Seit September 2022 ist das Robots Exclusion Protocol als RFC 9309 ein Proposed Standard der IETF (rfc-editor.org). Das Dokument beschreibt Syntax, Fehlerbehandlung und Caching und erweitert damit die Konvention, die Martijn Koster 1994 eingeführt hatte. Es legt auch technische Grenzen fest, etwa ein Parsinglimit von mindestens 500 Kibibyte je robots.txt (rfc-editor.org). Wer eine sehr lange Datei pflegt, sollte die wichtigsten Gruppen deshalb nach oben stellen.

Crawler sollten ein Parsinglimit anwenden, um ihre Systeme zu schützen; dieses Limit muss mindestens 500 Kibibyte betragen.

RFC 9309, Robots Exclusion Protocol (IETF)

Entscheidend ist aber etwas anderes: Die robots.txt ist keine Zugriffskontrolle. Sie ist eine Erklärung des Betreibers darüber, was ein automatischer Client tun sollte – nicht darüber, was er technisch kann. Eine per Disallow ausgenommene URL bleibt über HTTP abrufbar. Wer sich allein darauf verlässt, verwechselt eine Höflichkeitsregel mit einem Schutzmechanismus.

• Freiwilligkeit: Die Befolgung hängt vom Verhalten des Clients ab; es gibt keine technische Erzwingung
• Identität: Der User-Agent ist ein frei wählbarer Header und lässt sich fälschen
• Granularität: Pfadregeln passen selten exakt zu inhaltlichen Kategorien wie Ratgeber oder Testbericht
• Latenz: Änderungen wirken erst, wenn der Client die Datei neu lädt – RFC 9309 erlaubt Caching (rfc-editor.org)
• Reichweite: Inhalte, die über Feeds, Marktplätze oder Partner verbreitet werden, entziehen sich Ihrer robots.txt vollständig

Dass Blockaden in der Breite eher zurückhaltend gesetzt werden, zeigen Auswertungen der robots.txt-Landschaft: In einer Analyse von rund 140 Millionen Websites lagen die Blockraten selbst für die bekanntesten SEO-Crawler nur bei 6,3 bis 6,5 Prozent (Ahrefs). Bei Nachrichtenangeboten sieht es anders aus: Ende 2023 blockten 48 Prozent der meistgenutzten Nachrichtenseiten aus zehn Ländern den Crawler eines großen KI-Anbieters, 24 Prozent den KI-Crawler von Google – in Deutschland lag der Wert für das Google-Token mit 60 Prozent am höchsten (Reuters Institute). Und eine Längsschnittstudie zu Trainingskorpora fand, dass innerhalb eines Jahres über 5 Prozent aller Token in C4 und rund 28 Prozent der aktivsten Quellen vollständig gesperrt wurden (Data Provenance Initiative).

Technisch wirksam wird der Vorbehalt erst mit Bot-Management

Der rechtliche Vorbehalt und die technische Durchsetzung sind zwei getrennte Baustellen. Der Vorbehalt entscheidet darüber, ob eine Nutzung zulässig ist. Ob sie faktisch stattfindet, entscheidet Ihre Infrastruktur. Wirksam sind vier Ebenen, die aufeinander aufbauen und sich in der Serverkonfiguration umsetzen lassen:

1. Identifikation: User-Agent-Regeln als erste Stufe, aber grundsätzlich kombiniert mit einer Verifikation über Reverse-DNS oder die veröffentlichten IP-Bereiche des jeweiligen Anbieters – Google dokumentiert diese Prüfung für die eigenen Crawler ausdrücklich (Google Search Central)
2. Rate-Limits: Begrenzung von Anfragen pro Minute je IP, Subnetz oder autonomem System, damit unbekannte Sammler den Origin nicht überlasten
3. Regelwerk auf der Firewall: gezielte Antworten mit Status 403 oder 429 für verifizierte Trainings-Crawler auf vorbehaltenen Pfaden, während Produktseiten offen bleiben
4. Entkopplung: eine vorgelagerte Cache-Schicht, damit Crawler-Last nicht direkt auf Datenbank und Applikation durchschlägt

Der vierte Punkt wird häufig unterschätzt. Crawler erzeugen typischerweise viele Anfragen auf Detailseiten mit geringer Trefferquote im Cache. Wie sich das abfedern lässt, beschreibt unser Beitrag zum HTTP-Cache-Rework in Shopware; für die asynchrone Verarbeitung im Hintergrund lohnt der Blick auf Message Queue und Worker im Produktivbetrieb. Beides senkt die Wahrscheinlichkeit, dass hohe Bot-Last als Performance-Problem bei echten Kundinnen und Kunden ankommt.

Server-Log-Analyse: Wer crawlt wirklich und wie teuer ist das?

Bevor Sie eine einzige Regel schreiben, brauchen Sie Zahlen. Analytics-Werkzeuge helfen dabei nicht: Crawler führen kein JavaScript aus und tauchen dort in der Regel gar nicht auf. Die belastbare Quelle sind die Zugriffsprotokolle Ihres Webservers. Wichtig sind vier Felder je Anfrage: Zeitstempel, angefragte URL, User-Agent und ausgelieferte Bytes, ergänzt um Statuscode und Antwortzeit.

1. Rohlogs über mindestens 30 Tage sichern, damit Wochenmuster und Kampagnenzeiträume sichtbar werden
2. Anfragen nach User-Agent gruppieren und in vier Klassen einsortieren: Suchmaschine, Retrieval, Training, unbekannt
3. Behauptete Identitäten stichprobenartig per Reverse-DNS prüfen und gefälschte Einträge gesondert zählen
4. Ausgelieferte Bytes und Antwortzeiten je Klasse aufsummieren, um die reale Last zu beziffern
5. Referral-Traffic aus KI-Oberflächen gegenüberstellen, um ein Verhältnis von Crawl-Aufwand zu Rückfluss zu bilden
6. Ergebnis quartalsweise wiederholen und Veränderungen dokumentieren

In Projekten sehen wir regelmäßig, dass ein erheblicher Teil der Bot-Last auf Pfade entfällt, die weder Umsatz noch Sichtbarkeit bringen – Filterkombinationen, Sortierparameter, Druckansichten (Projekterfahrung). Diese Pfade lassen sich meist ohne Nebenwirkungen ausschließen und entlasten den Server spürbar, bevor überhaupt über KI-spezifische Regeln gesprochen wird. Die laufende Auswertung gehört in den Regelbetrieb Ihres Hostings, nicht in ein einmaliges Projekt.

Differenzierungsstrategie für Shops: freigeben, was verkauft

Für Händler lässt sich die Entscheidung an einer einfachen Frage ausrichten: Bringt der Inhalt Nachfrage, oder ist er selbst das Produkt? Produktdaten, Preise und Verfügbarkeiten bringen Nachfrage – hier wollen Sie gefunden werden, auch von generativen Systemen. Ratgeber, Testberichte, Anwendungswissen und eigene Bildwelten sind dagegen eigene redaktionelle Leistungen, die ohne Rückverweis kaum Gegenwert erzeugen.

Diese Differenzierung ist kein Kompromiss aus Bequemlichkeit, sondern die konsequente Anwendung des Gesetzes: § 44b Absatz 3 UrhG verlangt keinen Totalvorbehalt, sondern einen erklärten Vorbehalt (gesetze-im-internet.de). Sie dürfen ihn so eng oder so weit fassen, wie es zu Ihrem Geschäftsmodell passt – solange die Erklärung maschinenlesbar und widerspruchsfrei ist. Genau dafür ist das TDMRep-Modell mit seinen pfadbezogenen location-Einträgen ausgelegt (w3.org).

Lizenzierung statt Totalblockade

Der Vorbehalt ist kein Selbstzweck. Das TDMRep-Modell sieht mit tdm-policy bewusst eine zweite Eigenschaft vor: eine URL, unter der Kontaktinformationen und Bedingungen für die Erteilung einer Nutzungserlaubnis abrufbar sind (w3.org). Wer nur sperrt, verzichtet auf einen Erlöskanal; wer sperrt und gleichzeitig einen Weg zur Lizenz öffnet, verwandelt eine Abwehrmaßnahme in ein Angebot.

• Eine schlanke Policy-Seite mit klarer Beschreibung der vorbehaltenen Inhaltsklassen und einem Kontaktweg
• Angabe, welche Nutzungsarten ohne gesonderte Vereinbarung erlaubt bleiben – etwa Antworten mit sichtbarer Quellenangabe
• Vermerk, ob Sie strukturierte Feeds oder Schnittstellen als lizenzierten Zugang anbieten können
• Hinweis auf die Zuständigkeit im Unternehmen, damit Anfragen nicht im Postfach versanden
• Regelmäßige Aktualisierung, weil sich Anbieter, Tokens und Protokolle laufend ändern

Ein Vorbehalt ohne Lizenzweg ist eine Tür ohne Klingel. Wer Inhalte schützt, sollte gleichzeitig sagen, unter welchen Bedingungen eine Nutzung möglich wäre.

XICTRON Entwicklungsteam

Technisch ist der Aufwand überschaubar: eine statische JSON-Datei, ein Header in der Serverkonfiguration, ein Absatz in den Nutzungsbedingungen und eine Policy-Seite. Der größere Teil der Arbeit steckt in der inhaltlichen Kartierung Ihres Shops – also in der Frage, welche Pfade welche Inhaltsklasse enthalten. Diese Kartierung lässt sich gut mit einer Bestandsaufnahme in der Programmierung und Architektur verbinden.

Kontrolle über KI-Crawler zurückgewinnen

Die Rechtslage ist eindeutiger, als sie oft dargestellt wird: Ohne maschinenlesbaren Nutzungsvorbehalt ist Text und Data Mining an rechtmäßig zugänglichen Werken zulässig (gesetze-im-internet.de; EUR-Lex). Unklar ist derzeit vor allem, welche Form ein Vorbehalt genau haben muss – das Oberlandesgericht Hamburg hat die Revision zum Bundesgerichtshof zugelassen und die Frage damit offengehalten (Legal Tribune Online). Bis dahin ist die pragmatische Antwort, den Vorbehalt gleichzeitig in robots.txt, Nutzungsbedingungen und TDMRep zu erklären, ihn technisch nur dort durchzusetzen, wo er wirtschaftlich zählt, und die Wirkung an den Server-Logs zu messen. Wenn Sie Ihren Crawler-Traffic auswerten, den Vorbehalt sauber setzen und die Bot-Steuerung so einrichten möchten, dass Ihre Produktdaten sichtbar bleiben, sprechen Sie uns an – unser Team begleitet Analyse, Umsetzung und Betrieb.