Unsere Position ist klar: Wir sind Geonode und verkaufen Proxys, stehen also aus kommerziellen Gründen auf der Seite der Crawler. Ehrlich gesagt besteht die Umgehung von Honeypots größtenteils darin, einfach ordnungsgemäß zu crawlen, und die mit Abstand wirksamste Maßnahme kostet nichts: Halten Sie sich an robots.txt. Ein großer Teil der Fallen befindet sich auf Pfaden, die die Website Crawlern bereits untersagt hat, sodass ein regelkonformer Crawler niemals darauf stößt. Der Rest lässt sich vermeiden, indem man CSS rendert, keine Formulare absendet, zu deren Nutzung man nicht aufgefordert wurde, und den Crawl begrenzt. Nichts davon erfordert den Kauf von Produkten bei uns, und ein Crawler, der Proxys benötigt, um einen Honeypot zu umgehen, ist ein Crawler, der bereits einen grundlegenderen Fehler begangen hat.
Was ist eine Honeypot-Falle?
Die Definition ist eher verhaltensbezogen als technisch: Es handelt sich um Inhalte, mit denen nur ein automatisierter Client interagiert, und die so platziert sind, dass diese Interaktion den Client als automatisiert identifiziert.
Die Logik ist einfach und kaum zu widerlegen. Ein menschlicher Besucher nutzt einen Browser, der CSS anwendet, ein Layout rendert und ihm anzeigt, was sichtbar ist. Ein Crawler, der HTML analysiert, sieht alles im Markup gleichermaßen – einschließlich eines Links, der so gestaltet ist, dass er unsichtbar ist, eines Formularfelds, das außerhalb des Bildschirms verborgen ist, und eines Pfads, auf den niemand von einer Stelle aus verlinkt, die ein Mensch normalerweise betrachten würde.
Die Interaktion mit einem dieser Elemente ist ein starkes Signal. Nicht schlüssig, da sich auch Barrierefreiheits-Tools und Textmodus-Browser anders verhalten, aber stark genug, dass Websites darauf reagieren.
Die Konsequenzen variieren je nach Website. Manche protokollieren dies und ignorieren es. Manche begrenzen die Zugriffsrate. Manche blockieren die Adresse. Manche stellen auf unbestimmte Zeit eingeschränkte Inhalte bereit – was das schlimmste Ergebnis ist, da es wie ein Erfolg aussieht. Und manche gehen mittlerweile noch einen Schritt weiter, worauf im Folgenden eingegangen wird.
Die sechs Arten, denen Sie begegnen werden
1. Unsichtbare Links. Ein Link, der mit „display: none“, „visibility: hidden“, null Abmessungen, einer dem Hintergrund entsprechenden Farbe oder außerhalb des Bildschirms positioniert gestaltet ist. Im HTML vorhanden, auf der gerenderten Seite nicht sichtbar.
<a href="/trap/do-not-follow" style="display:none">Products</a>
<a href="/hidden" class="visually-hidden">Sitemap</a>
Die häufigste Form und am einfachsten zu vermeiden.
2. Unzulässige Pfade. URLs, die nur in der Datei „robots.txt“ unter einer „Disallow“-Anweisung erscheinen und von nirgendwo aus verlinkt sind. Die einzige Möglichkeit, einen solchen Pfad zu finden, besteht darin, die Ausschlussdatei zu lesen und ihn anschließend zu ignorieren – was eine Anfrage an diesen Pfad zu einem nahezu perfekten Hinweis auf eine absichtliche Nichteinhaltung macht.
3. Versteckte Formularfelder. Ein mit CSS verstecktes Feld, das von einem Menschen niemals ausgefüllt wird. Jede Übermittlung, die einen Wert dafür enthält, stammt von etwas, das den HTML-Code auswertet. Häufig anzutreffen in Kommentarformularen und Anmeldeabläufen, wo es eine legitime und wirksame Anti-Spam-Maßnahme darstellt.
4. Unendliche URL-Räume. Nicht immer beabsichtigt, aber in jedem Fall gleichermaßen schädlich. Ein Kalender mit einem „Nächster Monat“-Link erzeugt unbegrenzt viele URLs. Die facettierte Navigation in einem großen Katalog führt zu einer explosionsartigen Zunahme von URL-Kombinationen. Ein Crawler ohne Tiefen- und Musterbegrenzungen folgt diesen so lange, bis ihn etwas stoppt.
5. Zeitfallen. Inhalte, die erst nach einer Verzögerung erscheinen, oder Formulare, die Eingaben ablehnen, die schneller ausgefüllt wurden, als es ein Mensch schaffen könnte. Diese fangen Clients ab, die sofort reagieren, anstatt solche, die das Markup analysieren.
6. Manipulierte oder generierte Inhalte. Die neueste Kategorie, die bedeutend genug ist, um einen eigenen Abschnitt zu verdienen.
KI-Tarpits und generierte Labyrinthe
Eine wirklich neue Entwicklung und der Grund dafür, dass sich dieses Thema in den letzten Jahren gewandelt hat.
Das AI Labyrinth von Cloudflare ist das am weitesten verbreitete Beispiel. Cloudflare beschreibt es als „einen neuen Abwehransatz, der KI-generierte Inhalte nutzt, um KI-Crawler zu verlangsamen, zu verwirren und deren Ressourcen zu verschwenden“.
Der Mechanismus: Die KI von Workers generiert vielfältige HTML-Seiten zu unterschiedlichen Themen, die zur schnellen Bereitstellung in R2 gespeichert werden. Diese Köder-Seiten sind über versteckte Links mit echten Seiten verknüpft, die „für menschliche Besucher unsichtbar, für Bot-Crawler jedoch zugänglich“ sind.
Cloudflares Erklärung, warum dies funktioniert, ist die prägnanteste Beschreibung des Honeypot-Prinzips, die je verfasst wurde:
Kein echter Mensch würde sich vier Links tief in ein Labyrinth aus KI-generiertem Unsinn vorwagen.
Entscheidend ist, dass der bereitgestellte Inhalt „echt und mit wissenschaftlichen Fakten verbunden ist, nur eben nicht relevant oder urheberrechtlich geschützt für die gecrawlte Website“ – ein Crawler kann ihn also nicht erkennen, indem er prüft, ob der Text kohärent ist. Er ist kohärent. Er handelt lediglich von etwas anderem.
Die Funktion ist in allen Cloudflare-Tarifen einschließlich der kostenlosen Stufe verfügbar, und die Aktivierung erfolgt über einen einzigen Schalter im Bereich „Bot-Management“ ohne „zusätzliche Konfiguration“.
Unabhängige Tools arbeiten nach demselben Prinzip. Nepenthes generiert ein unendliches Labyrinth aus Seiten ohne Ausstiegslinks. Iocaine fungiert als Reverse-Proxy und unternimmt einen zusätzlichen Schritt, den es zu verstehen lohnt: Es „vergiftet“ die von ihm bereitgestellten URLs, sodass ein Crawler, der später als Browser getarnt zurückkehrt, dennoch daran erkannt werden kann, dass seine Anforderungswarteschlange ausschließlich URLs enthält, die jemals vom Tarpit ausgegeben wurden. Das ist eher ein dauerhafter als ein momentaner Marker.
Daraus ergeben sich zwei Konsequenzen für jeden, der einen Crawler betreibt.
Eine Erkennung anhand der Inhaltsqualität funktioniert nicht. Die Seiten sind in sich schlüssig und sachlich. Was sie verrät, ist, dass sie für die Website irrelevant sind, von keiner Stelle aus verlinkt sind, an der ein Mensch sie finden würde, und in ihrer Anzahl unbegrenzt sind.
Die Begrenzung Ihres Crawls ist mittlerweile unerlässlich und nicht mehr nur eine Frage der Ordnung. Ein Crawler ohne Tiefenbegrenzung, Seitenanzahlbegrenzung und Duplikatserkennung kann Tage an Rechenzeit und Gigabyte an kontingentierter Bandbreite für generierten Unsinn verschwenden, ohne jemals eine Fehlermeldung zu erhalten. Bei einer Abrechnung pro Gigabyte ist das eine echte Rechnung für nichts.
Wie man sie vermeidet, ohne hinterhältig zu sein
Jede der hier genannten Maßnahmen ist etwas, was ein gut programmierter Crawler ohnehin tun sollte.
Halten Sie sich an die „robots.txt“. Allein dadurch lässt sich ein Großteil der Fallen vermeiden, da unzulässige Pfade genau dort liegen, wo Websites sie platzieren. Dies ist mittlerweile ein Standard – RFC 9309 –, bei dem die Übereinstimmung nach Spezifität statt nach Reihenfolge erfolgt. Wie man diese Datei richtig liest, haben wir in „Wie man eine robots.txt-Datei liest“ behandelt.
Überprüfen Sie die berechnete Sichtbarkeit, bevor Sie einem Link folgen. In einem Headless-Browser ist dies unkompliziert:
const links = await page.$$eval('a[href]', els =>
els.filter(el => {
const s = getComputedStyle(el);
const r = el.getBoundingClientRect();
return s.display !== 'none' && s.visibility !== 'hidden' &&
parseFloat(s.opacity) > 0 && r.width > 1 && r.height > 1;
}).map(el => el.href)
);
Beachten Sie, dass „getComputedStyle“ verwendet wird, anstatt das Inline-Attribut „style“ auszulesen – ein durch eine Stylesheet-Regel ausgeblendeter Link hat keinen Inline-Stil, der überprüft werden könnte.
Ohne Browser sollten Sie heuristische Verfahren anwenden: Überspringen Sie Links, deren Inline-Stil „display:none“ oder „visibility:hidden“ enthält, überspringen Sie leeren Ankertext, überspringen Sie Klassennamen wie „hidden“, „visually-hidden“ und „sr-only“ und seien Sie misstrauisch gegenüber Links, deren „href“-Attribut nirgendwo im sichtbaren Text vorkommt.
Begrenzen Sie das Crawling absolut. Eine maximale Tiefe, eine maximale Seitenanzahl und ein Budget pro Domain. Nicht als Ausweichlösung – sondern als harte Grenze. Dies ist die einzige Verteidigung gegen unendliche Räume, die unabhängig davon funktioniert, wie diese erzeugt werden.
Erkennen Sie Wiederholungen. Durch Content-Hashing lassen sich generierte Seiten erkennen, die sich nur oberflächlich unterscheiden. Die URL-Musteranalyse erkennt Pfade, die grenzenlos wachsen. Wenn ein Verzeichnis zweihundert Seiten erzeugt hat und keine Anzeichen für ein Ende zeigt, halten Sie inne und prüfen Sie die Situation.
Senden Sie keine Formulare ab, zu deren Ausfüllung Sie nicht aufgefordert wurden. Fallen mit versteckten Feldern erwischen nur Clients, die jedes gefundene Eingabefeld ausfüllen.
Ratenbegrenzung und Tempo. Ein menschenähnliches Timing umgeht die Zeitfallen und reduziert gleichzeitig alle anderen Signale.
Identifizieren Sie sich. Ein Crawler mit einem Namen und einer Kontakt-URL ist einer, den ein Betreiber zulassen kann. Dies ist zwar nicht unbedingt eine Maßnahme zur Vermeidung von Fallen, aber es verändert, was passiert, nachdem Sie in eine Falle getappt sind.
Eine Falle in freier Wildbahn erkennen
Anzeichen dafür, dass Sie in eine Falle geraten sind, in grober Reihenfolge danach, wie schnell sie auftreten.
Die Seitenanzahl konvergiert nicht. Die Warteschlange wird immer länger, anstatt kürzer zu werden – dies ist das früheste Warnzeichen und am einfachsten zu messen.
Der Inhalt ist schlüssig und irrelevant. Seiten, die sich gut lesen lassen, aber nichts mit dem eigentlichen Thema der Website zu tun haben. Dies ist das Erkennungsmerkmal des „AI Labyrinth“.
URLs folgen einem generierten Muster. Lange Pfade, ungewöhnliche Segmentstrukturen und keine Wiederholung von URLs, wie man sie von einer echten Website erwarten würde.
Keine eingehenden Links von sinnvollen Quellen. Die Seiten verlinken untereinander, aber es gibt keine externen Verweise darauf.
Die Antwortzeiten sind verdächtig einheitlich. Generierte Inhalte werden aus einem Cache bereitgestellt; echte Seiten variieren.
Ihre Datenqualität sinkt, ohne dass sich Ihre Fehlerquote ändert. Das deutlichste Signal im fortgeschrittenen Stadium und der Grund, warum es wichtig ist, dass alles einen 200-Status zurückgibt.
Die praktische Überprüfung erfolgt eher durch eine laufende Assertion als durch eine manuelle Kontrolle: Wenn das Verhältnis von neu entdeckten URLs zu abgerufenen Seiten im Verlauf eines Crawls nicht sinkt, generiert etwas URLs schneller, als Sie sie verarbeiten können – und kein Crawl einer endlichen Website verhält sich so.
Für Website-Betreiber: Die Implementierung
Kurz zur anderen Seite, da das gleiche Verständnis für beide gilt.
Versteckte Formularfelder bieten den größten Nutzen. Sie lassen sich ganz einfach hinzufügen, sind wirksam gegen automatisierte Formularübermittlungen und haben keine Auswirkungen auf echte Nutzer. Geben Sie dem Feld einen harmlosen Namen, blenden Sie es mit CSS in einem Stylesheet statt inline aus und lehnen Sie jede Übermittlung ab, bei der dieses Feld ausgefüllt wird.
Versteckte Links fangen Crawler ab, die keine Inhalte rendern. Wirksam und lohnenswert in Kombination mit der Anweisung „robots.txtdisallow“, damit konforme Crawler nicht erwischt werden. Einen gut funktionierenden Crawler für eine Falle zu bestrafen, die Sie nicht ausgeschlossen haben, ist ein selbstverschuldetes Problem.
Verwaltete Tarpits sind nun ein Schalter. Die Funktion von Cloudflare ist in allen Tarifen einschließlich des kostenlosen verfügbar und erfordert keine Konfiguration, wodurch sie für jede Website zugänglich ist.
Barrierefreiheit ist die eigentliche Einschränkung. Bildschirmleseprogramme und Textbrowser wenden visuelle Formatierungen nicht auf dieselbe Weise an wie der Browser eines sehenden Nutzers. Eine Falle, die „display: none“ verwendet, ist im Allgemeinen sicher, da assistive Technologien diese Funktion respektieren; eine Falle, die Positionierung außerhalb des Bildschirms oder transparenten Text nutzt, wird möglicherweise einem Screenreader-Nutzer angesagt, der ihr dann folgt und blockiert wird. Wenn Sie solche Fallen einsetzen, testen Sie sie mit einem Screenreader.
Und entscheiden Sie, was Sie tatsächlich wollen. Suchmaschinen, Preisvergleichspartner, Barrierefreiheits-Tools, Überwachungsdienste und KI-Agenten senden alle automatisierten Zugriffsverkehr, und einen Teil davon möchten Sie haben. Eine pauschale Falle fängt alles ab. Das Ausschließen bekannter, vertrauenswürdiger Crawler anhand des User-Agents und das Setzen von Fallen nur auf Pfaden, die „robots.txt“ bereits verbietet, ist die Vorgehensweise, die den unerwünschten Zugriffsverkehr abfängt und den Rest verschont.
Wann man besser aufhört, anstatt sich anzupassen
Diese Ermessensentscheidung sollte klar und deutlich ausgesprochen werden, da wir ein Anbieter sind, dessen Produkt die übliche „Anpassung“ ist.
Wenn eine Website Schutzmaßnahmen eingerichtet hat, hat sie damit eine Botschaft gesendet. In Verbindung mit Sperren durch „robots.txt“ und Bestimmungen, die den automatisierten Zugriff verbieten, ist diese Botschaft eindeutig, und der Versuch, diese Maßnahmen weiterhin zu umgehen, ist eine Entscheidung mit Konsequenzen, die über den rein technischen Bereich hinausgehen.
Die Alternativen sind oft besser und fast immer kostengünstiger:
Fragen Sie nach. Eine E-Mail, in der Sie erklären, wer Sie sind und was Sie benötigen, löst das Problem häufiger, als man erwartet, und ein Partner-Feed beseitigt das Problem gänzlich.
Prüfen Sie, ob es eine offizielle API gibt. Viele Websites mit aggressiven Schutzmaßnahmen veröffentlichen auch eine solche, gerade damit legitime Nutzer eine Anlaufstelle haben.
Prüfen Sie, ob die Daten anderswo verfügbar sind. Öffentliche Datensätze, Archive, amtliche Unterlagen, lizenzierte Anbieter.
Reduzieren Sie Ihren Bedarf. Bei vielen Scraping-Vorgängen werden weit mehr Daten gesammelt, als eigentlich benötigt werden. Ein geringerer Bedarf lässt sich leichter auf legitime Weise decken.
Und der praktische Aspekt: Tarpits sind so konzipiert, dass sie Sie mehr kosten als die Website selbst. Cloudflare generiert die Seiten einmalig und stellt sie aus dem Speicher bereit; Sie zahlen pro Gigabyte, pro Rechenstunde und in Entwicklungszeit. Diese Asymmetrie ist beabsichtigt und lässt sich durch zusätzlichen Aufwand nicht verbessern.
Häufig gestellte Fragen
Was ist eine Honeypot-Falle beim Web-Scraping?
Inhalte auf einer Seite, mit denen nur ein automatisierter Client interagiert – ein unsichtbarer Link, ein verstecktes Formularfeld oder ein Pfad, auf den von keiner Stelle aus verwiesen wird, an der ein Mensch suchen würde. Durch die Interaktion damit wird der Client als Bot identifiziert, woraufhin Websites mit Protokollierung, Ratenbegrenzung oder Sperrung reagieren.
Wie vermeide ich Honeypot-Fallen?
Beachten Sie die „robots.txt“, da sich viele Fallen auf unzulässigen Pfaden befinden. Überprüfen Sie die berechnete Sichtbarkeit, bevor Sie Links folgen, anstatt rohen HTML-Code zu analysieren. Füllen Sie keine Formularfelder aus, die Ihnen nicht angezeigt wurden. Und legen Sie für Ihren Crawl feste Grenzen für die Crawl-Tiefe und die Anzahl der Seiten fest – dies ist der einzige Schutz vor unendlichen Räumen.
Was ist ein KI-Tarpit?
Ein System, das automatisierten Crawlern ein endloses Labyrinth aus generierten Seiten serviert, um deren Ressourcen zu verschwenden. Das AI Labyrinth von Cloudflare generiert kohärente, sachliche Inhalte, die für die Website jedoch völlig irrelevant sind und unsichtbar von echten Seiten verlinkt werden. Es ist in allen Tarifen, einschließlich des kostenlosen, verfügbar und lässt sich mit einem einzigen Schalter aktivieren.
Kann ich einen Honeypot erkennen, bevor ich hineintappe?
Teilweise. Das Rendern der Seite und das Überprüfen der berechneten Stile erkennen versteckte Links zuverlässig. Generierte Labyrinthe sind schwieriger zu erkennen, da der Inhalt zusammenhängend ist – die Anzeichen sind eine ständig wachsende Warteschlange, für die Website irrelevante Inhalte und sich nicht wiederholende URL-Muster. Die Begrenzung des Crawls ist die Abwehrmaßnahme, die in jedem Fall funktioniert.
Beeinträchtigen versteckte Links die Suchmaschinenoptimierung (SEO) oder die Barrierefreiheit?
Versteckter Text wurde von Suchmaschinen in der Vergangenheit als Manipulation gewertet, daher werden Fallen in der Regel mit einem „disallow“ in der Datei „robots.txt“ kombiniert. Die Barrierefreiheit ist das größere Problem: „display: none“ wird von assistiver Technologie beachtet, aber Text außerhalb des Bildschirms oder transparenter Text kann einem Screenreader-Nutzer vorgelesen werden, der ihm dann folgt.
Was passiert, wenn mein Crawler auf einen Honeypot stößt?
Das ist unterschiedlich. Manche Websites protokollieren es, manche begrenzen die Zugriffsrate, manche blockieren die Adresse und manche liefern auf unbestimmte Zeit minderwertige Inhalte – was der schlimmste Fall ist, da alles einen 200-Status zurückgibt und sich die Qualität Ihrer Daten unbemerkt verschlechtert. Tarpits verhalten sich anders: Sie liefern Ihnen weiterhin Inhalte – und zwar für immer.
Sind Honeypot-Fallen legal?
Sie auf Ihrer eigenen Website zu platzieren, ist völlig legal – Sie entscheiden, was Sie bereitstellen. Was eine Website mit den daraus resultierenden Identifikationsdaten macht, richtet sich nach ihren Nutzungsbedingungen. Aus Sicht des Crawlers ist das Auslösen einer solchen Falle an sich nicht rechtswidrig; es kann jedoch gegen die Nutzungsbedingungen verstoßen, was eine vertragliche Angelegenheit ist.
Wie verhindere ich, dass mein Crawler Geld an einem Tarpit verschwendet?
Strenge Begrenzungen hinsichtlich der Crawling-Tiefe und der Seitenanzahl pro Domain, das Hashing von Inhalten zur Erkennung von fast identischen Seiten sowie eine Warnmeldung, wenn das Verhältnis von neu entdeckten URLs zu abgerufenen Seiten nicht sinkt. Ohne diese Maßnahmen kann ein Crawler mit begrenztem Datenvolumen Tage und Gigabyte für generierte Seiten verschwenden, während er gleichzeitig eine perfekte Erfolgsquote meldet.
Fazit
Honeypot-Fallen basieren auf einer Annahme: dass ein Crawler den Quellcode sieht, während ein Mensch die gerenderte Seite sieht. Alles andere ist eine Variante – ein unsichtbarer Link, ein verstecktes Feld, ein Pfad, der nur unter robots.txt erwähnt wird, oder ein Labyrinth, das niemals endet.
Diese Abwehrmaßnahmen sind alles Dinge, die ein gut programmierter Crawler ohnehin tun sollte. Halten Sie sich an „robots.txt“, denn dort lauern viele Fallen, und die Einhaltung kostet nichts. Überprüfen Sie die berechnete Sichtbarkeit, anstatt rohes HTML zu parsen. Lassen Sie Formulare in Ruhe, es sei denn, sie wurden Ihnen angezeigt. Und legen Sie für Ihren Crawl feste Grenzen fest – das ist die einzige Maßnahme, die Sie vor generierten Labyrinthen schützt, deren Inhalt absichtlich nicht von echtem Text zu unterscheiden ist.
Diese letzte Kategorie hat die Wirtschaftlichkeit verändert. Ein verwalteter Tarpit generiert seine Seiten einmal und liefert sie aus dem Cache aus; ein Crawler zahlt pro Gigabyte und pro Rechenstunde und erhält jedes Mal einen 200er-Status. Die Asymmetrie ist der springende Punkt – sie steht nun jeder Website hinter einem einzigen Schalter zur Verfügung und lässt sich nicht durch Aufwand überwinden.
Das macht diese unscheinbare Option zu einer ernst zu nehmenden Alternative. Eine Website, die Fallen eingesetzt hat, hat Ihnen etwas mitgeteilt, und die Anforderung eines Feeds, die Suche nach einer API oder das Auffinden der Daten an anderer Stelle ist in der Regel schneller, kostengünstiger und nachhaltiger, als jemanden technisch zu überlisten, der es so eingerichtet hat, dass Sie scheitern.