Tarpite und vergiftete Seiten: wie der Parser Müll sammelt

Der Parser funktioniert. HTTP 200 fließen ununterbrochen, Proxys sind aktiv, Captchas erscheinen nicht, die Warteschlange der Links wächst. Nach einer Woche stellt sich heraus, dass die Hälfte der gesammelten Preise erfunden ist und Gigabytes an Traffic auf Seiten verschwunden sind, die auf der echten Website nicht existieren. Das ist kein Fehler des Parsers und kein schlechtes IP-Pool. Das ist ein neuer Schutzmodus: Die Website blockiert Sie nicht, sie füttert Sie.

In anderthalb Jahren hat die Anti-Bot-Schutzindustrie stillschweigend ihr Ziel gewechselt. Blockierung ist eine teure und auffällige Maßnahme: Der Scraper sieht 403, repariert den Fingerabdruck, wechselt das Subnetz und kommt zurück. Es ist viel rentabler, ihm nicht zu schaden, sondern seine Arbeit sinnlos zu machen. Im Folgenden sind drei Mechaniken aufgeführt, die bereits bei Millionen von Websites im Einsatz sind, sowie eine Reihe von Prüfungen, die sie auf Ihrer Seite erkennen.

Erste Mechanik: Tarpit statt Blockade

Ein Tarpit (tarpit, „Teergrube“) ist ein Generator unendlicher Seiten. Der Crawler erhält eine gültige HTML-Seite mit Dutzenden von Links, jeder Link führt zu einer ähnlichen generierten Seite, und die Warteschlange der Crawls wird niemals leer.

Das bekannteste Open-Source-Tool ist Nepenthes. Seine Einstellungen zeigen gut die Absicht: Standardmäßig hält der Server die Antwort von 10 bis 65 Sekunden, liefert Text „Markov-Geschwätz“, generiert aus einem Korpus, und macht dies deterministisch – dieselbe URL gibt immer denselben Müll zurück, damit die Seiten wie gewöhnliche statische Dateien und nicht wie Fallen aussehen. Die Daten werden in kleinen Portionen, „ein paar Bytes“, ausgegeben, um die Timeouts des Clients auszureizen. Der Autor führt eine Messung über eine Stunde durch: 1850 verschiedene Clients, 10.015 Anfragen und 56.020 Sekunden Gesamtlatenz – etwa fünfzehn Stunden fremder Maschinenzeit, die umsonst verschwendet wurde.

Iocaine funktioniert anders: Es agiert als Reverse-Proxy vor der echten Website, gibt beim ersten Abfangen dem Bot einen einzigartigen „vergifteten“ Link und erkennt ihn bei der Rückkehr, während der Text mit Markov-Ketten generiert wird – in der Annahme, dass dieser Text in die Trainingsdaten gelangt.

Bei Cloudflare wurde dasselbe Prinzip zu einem Produkt – AI Labyrinth, das im März 2025 vorgestellt wurde. Die Lockseiten werden nicht in Echtzeit generiert: Es wird eine Vorproduktionspipeline auf Workers AI verwendet, das Ergebnis wird in R2 gespeichert und schnell verteilt. Links zum Labyrinth werden über HTML-Transformationen in normale Seiten eingebettet, und auf den Lockseiten stehen Meta-Direktiven gegen die Indizierung, um die Ausgabe nicht zu gefährden. Das Wichtigste hier ist nicht die verschwendete Zeit des Bots, sondern das Signal: Über Links, die für Menschen verborgen und mit nofollow gekennzeichnet sind, navigiert nur der Automat, und ein Wechsel auf drei Ebenen in ein solches Labyrinth wird selbst zu einem Fingerabdruck eines schlechten Bots. Das Ausmaß des Problems, für das dies getan wurde, schätzt Cloudflare auf mehr als 50 Milliarden Anfragen von KI-Crawlern pro Tag – etwas weniger als 1% des gesamten Netzwerkverkehrs.

Wie Tarpit in Ihren Logs aussieht

Ein typisches Bild: Eine Warteschlange von mehreren tausend URLs, die nur wächst, die Antwortzeit liegt stabil bei anderthalb Sekunden und mehr, HTTP-Codes sind durchweg 200, und die Anzahl der extrahierten nützlichen Einträge ist null. Kein 403, kein Captcha und kein Ausweg: So viele Seiten auch durchlaufen werden, neue Links erscheinen schneller, als alte geschlossen werden.

Zweite Mechanik: Vergifteter Inhalt für KI-Agenten

Wenn die erste Mechanik Ressourcen verbraucht, zielt die zweite auf die Ergebnisse ab. Die Forscher Minghao Luo und Liang Chen veröffentlichten im Juni 2026 eine Arbeit mit dem Simulator FORGE (Fake Online Recommendations in Generative Environments): Sie testeten 12 große Sprachmodelle auf 225 Produkten in 15 Kategorien – von Kleidung bis Elektronik. Die Angriffsmechanik ist einfach: In dem Text der Seite wird eine echte Marke durch eine fiktive ersetzt.

Das Ergebnis – eine gefälschte Seite führt zu bis zu 27% der Fälle, in denen der Assistent eine nicht existierende Marke empfiehlt, und die Ersetzung aller drei obersten Ergebnisse erhöht diesen Anteil auf 73,8%. Die Modelle wiederholten nicht einfach den gefälschten Namen – sie erfanden Vorzüge dafür, einschließlich angeblicher Beliebtheit in Gemeinschaften. Die drei vorgeschlagenen Schutzmaßnahmen (Prompt auf Skepsis, Konsens über internes Wissen des Modells, Abgleich zwischen Dokumenten) funktionierten entweder nicht oder schufen neue Probleme. Die Schlussfolgerung der Autoren: Die Überprüfung sollte weiter oben im Fluss erfolgen – in der Sammelphase und nicht in der Argumentationsphase.

Die dritte Mechanik schließt das Bild ab. In der Arbeit „A Whole New World: Creating a Parallel-Poisoned Web Only AI-Agents Can See“ (Shaked Zychlinski) wird Cloaking beschrieben, das speziell auf KI-Agenten abzielt: Die Website erkennt den Agenten anhand von Browserattributen, Signaturen des Automatisierungsframeworks und Netzwerkeigenschaften und liefert ihm eine andere Version der Seite – mit versteckten Anweisungen und falschen Fakten. Ein Mensch, der dieselbe URL öffnet, sieht eine normale Seite, daher beweist eine manuelle Überprüfung „Ich bin rein, alles ist in Ordnung“ nichts.

Warum das in erster Linie eine Budgetfrage ist

Der Tarpit ist so gestaltet, dass jede Seite für die Website billig und für Sie teuer ist. Wenn der Traffic nach Gigabytes bezahlt wird, wird der Generator unendlicher Seiten zu einem Zähler Ihrer Ausgaben: Sie zahlen für Megabytes Markov-Text, der niemals eine Zeile in der Datenbank wird. Genau dieselbe Arithmetik wie bei fehlgeschlagenen Anfragen – der Preis pro Gigabyte sagt nichts über die Kosten des Ergebnisses aus, bis Sie die Kosten eines erfolgreichen Eintrags und nicht einer Anfrage berechnen.

Daher die erste praktische Regel: Das Traffic-Limit sollte auf der Ebene der Domain und der Aufgabe stehen und nicht nur auf der Ebene des Kontos. Eine Domain, die mehr als ein Gigabyte verbraucht hat und keinen einzigen Eintrag zurückgegeben hat, sollte automatisch gestoppt werden – ohne dies kann eine Falle das Tagesbudget über Nacht aufbrauchen.

Sieben Prüfungen, die Müll erkennen

Zählen Sie den Ertrag, nicht die Antwortcodes. Die Hauptmetrik der Pipeline ist der Anteil der Anfragen, die einen gültigen Eintrag mit ausgefüllten Pflichtfeldern ergeben haben. Solange Sie sich den Anteil der 200er ansehen, sieht der Tarpit wie eine perfekt gesunde Quelle aus.
Kanaren-URL. Fragen Sie alle N Anfragen nach einer absichtlich nicht existierenden Adresse innerhalb der Domain – mit einem zufälligen Pfadsegment. Eine normale Website antwortet mit 404 oder einer Weiterleitung, der Generator liefert eine vollständige Seite mit Text und Links. Das ist die billigste und zuverlässigste Prüfung.
Kreuzvalidierung von einem anderen IP-Profil. Nehmen Sie dieselbe URL über zwei verschiedene Routen – zum Beispiel über residential IP und über mobile – und vergleichen Sie die Hashes der Schlüsselbereiche: Preise, Namen, Verfügbarkeit. Abweichungen bei identischer URL und ähnlicher Anfragezeit bedeuten, dass Ihnen verschiedene Versionen der Seite angezeigt werden, und mindestens eine davon ist nicht für Menschen bestimmt.
Gehen Sie nicht auf unsichtbare Links. Links mit nofollow, null Größen, display:none oder außerhalb des Bildschirms platziert – das sind Lockangebote, und das Klicken darauf ist der Fingerabdruck des Bots. Filtern Sie sie in der Phase der Linkextraktion und nicht danach.
Strenge Obergrenzen für Antworten. Begrenzen Sie nicht nur das Timeout, sondern auch die maximale Größe des Körpers und die maximale Tiefe des Crawls vom Einstiegspunkt. Langsame Ausgaben in kleinen Chunks sind ein typisches Zeichen für eine Grube und nicht für einen langsamen Server.
Suche nach Textmuster. Markov-Generierung gibt sich durch Statistiken zu erkennen: verdächtig gleichmäßige Absatzlängen, sich wiederholende n-Gramme zwischen „verschiedenen“ Seiten, Dutzende von ausgehenden Links ohne strukturelle Elemente wie Preis, Artikelnummer oder Datum. Eine einfache Überprüfung auf wiederholte Shingles zwischen benachbarten Seiten der Domain filtert solche Quellen in einer Charge aus.
Überprüfen Sie Zahlen auf Plausibilität. Preise außerhalb des historischen Korridors, Produkte ohne einzige Übereinstimmung in Ihrer eigenen Marken-Datenbank, plötzliche Sprünge im Sortiment – das sind Validierungsregeln, die vor dem Eintrag in die Datenbank stehen sollten und nicht im Bericht nach einem Monat. Besonders wenn die Daten dann in ein Modell oder in eine automatische Kaufentscheidung gelangen.

Was mit bereits gesammelten Daten zu tun ist

Wenn der Verdacht nachträglich aufkommt, sortieren Sie nicht nach Daten, sondern nach Quellen. Gruppieren Sie die Einträge nach Domain und betrachten Sie drei Größen: den Anteil der Seiten ohne Pflichtfelder, die durchschnittliche Anzahl von ausgehenden Links auf der Seite und die Streuung der Textlängen. Fallen-Domains heben sich normalerweise sofort in allen drei Punkten hervor. Überprüfen Sie dann stichprobenartig strittige URLs von einem anderen IP-Profil – wenn die Daten nicht übereinstimmen, muss der gesamte Datensatz von dieser Domain neu erstellt werden und nicht mit Filtern repariert werden.

Es ist auch wichtig, die Regeln für Agentenszenarien zu überdenken, in denen das Modell selbst durch die Seiten navigiert und selbst Entscheidungen trifft. Genau dort hat die Ersetzung einer Seite den maximalen Effekt, und es gibt keinen Zwischenmenschen, der eine Anomalie bemerken könnte. Die minimale Absicherung besteht darin, die Bestätigung des Faktums aus zwei unabhängigen Quellen zu verlangen und dem Agenten nicht zu erlauben, auf Daten zuzugreifen, die von einer einzigen Domain stammen.

Kurz gesagt

Bots haben längst die Menschen im Anteil des Traffics überholt, und der Schutz hat nicht nur mit Filtern reagiert: Heute ist es billiger, einem Automaten glaubwürdigen Müll zu füttern, als sich mit Blockierungen auseinanderzusetzen. Es gibt drei praktische Konsequenzen. Zählen Sie nützliche Einträge und nicht die Statuscodes der Antworten. Halten Sie Kanarienprüfungen und Traffic-Limits für jede Domain ein. Vergleichen Sie strittige Seiten von verschiedenen IP-Profilen – die Abweichung der Versionen derselben Seite ist der Beweis dafür, dass Ihnen ein separater, speziell für Bots vorbereiteter Internet angezeigt wird. Proxys lösen in diesem Schema nur eine Aufgabe – sie bieten einen unabhängigen zweiten Blick auf die Seite; alles andere erledigt die Validierung auf Ihrer Seite.