← Alle Beitrage

Agents.txt ist keine Zugriffskontrolle

DreamHost dokumentiert inzwischen, dass Web-Hosting-Tarife automatisch standardmäßige robots.txt- und agents.txt-Dateien enthalten, wenn eine Website keine eigenen Versionen bereitstellt.1

Dieses kleine Hosting-Detail zeigt eine größere Verschiebung. Websites sprechen heute mindestens 3 Zielgruppen gleichzeitig an: Suchmaschinen-Crawler, KI-Crawler und Assistenten zur Inferenzzeit, die sauberen Kontext suchen. Die Dateinamen lassen diese Veränderung ordentlich wirken. robots.txt sagt, was automatisierte Clients crawlen dürfen. llms.txt gibt LLMs eine kuratierte Übersicht. agents.txt deutet eine Richtlinie für Agenten an. Keine dieser Dateien sollte Betreibern das Gefühl geben, geschützt zu sein.

Agents.txt ist keine Zugriffskontrolle. Behandeln Sie Crawler-Dateien als öffentliche Richtlinienhinweise und Orientierungshilfen. Echte Kontrolle entsteht weiterhin durch serverseitige Autorisierung, Bot-Identitätsprüfung, Ratenbegrenzung, Protokolle, Cache-Verhalten und Nachweise, dass die für Sie relevanten Crawler die aktuellen Dateien tatsächlich gesehen haben.

Kurzfassung

Der Standard des Robots Exclusion Protocol sagt, Crawler-Regeln seien „not a form of access authorization“.2 Auch Google warnt, dass eine in robots.txt ausgeschlossene URL trotzdem in der Suche erscheinen kann, wenn andere Seiten darauf verlinken.3 DreamHosts eigener Artikel zur Bot-Steuerung erklärt, dass Robots-Dateien für konforme Suchmaschinen eher Empfehlungen sind und schlechte Bots die Datei ignorieren oder irreführende User-Agents verwenden können.1

KI-Crawler bringen zusätzliche Richtliniendimensionen mit. OpenAI trennt OAI-SearchBot für die ChatGPT-Suche von GPTBot für trainingsbezogenes Crawling und erklärt, dass ChatGPT-User benutzerausgelöste Aktionen repräsentiert, bei denen robots.txt möglicherweise nicht greift.4 Google sagt, Google-Extended habe keinen eigenen HTTP-User-Agent-String und funktioniere als robots.txt-Produkttoken für Trainings- und Grounding-Präferenzen, nicht für die Aufnahme in die Google-Suche.5 Die Crawler-Steuerdatei braucht deshalb Richtlinien nach Zweck, nicht nur einen einzelnen Zulassen-oder-Blockieren-Schalter.

Nutzen Sie agents.txt, wenn Ihr Host, Ihre Plattform oder Ihr Agenten-Ökosystem sie erwartet. Nutzen Sie llms.txt, wenn Werkzeuge zur Inferenzzeit Ihre besten Seiten verstehen sollen. Halten Sie robots.txt korrekt, weil große Crawler sie weiterhin verwenden. Prüfen Sie anschließend Anfragen an der Server-Edge und lesen Sie die Protokolle. Eine Textdatei kann Absicht ausdrücken. Einen nicht vertrauenswürdigen Client stoppen kann sie nicht.

Wichtigste Punkte

Für Website-Betreiber: - Veröffentlichen Sie robots.txt für Crawling-Richtlinien, llms.txt für KI-lesbaren Kontext und agents.txt nur als Hinweis für Agenten. - Legen Sie private Routen, geheime Dateinamen, interne Prompts oder sensible Pfade niemals in einer öffentlichen Crawler-Datei offen. - Prüfen Sie nach Änderungen die Protokolle. Eine Richtliniendatei zählt nur, wenn der richtige Crawler sie abruft und sein Verhalten ändert.

Für SEO- und AIO-Teams: - Trennen Sie Suchsichtbarkeit von Trainingserlaubnissen und benutzerausgelösten Abrufen. - Machen Sie die Allowlist für gewünschte Bots ausdrücklich, etwa für Suchmaschinen-Crawler und KI-Antwortoberflächen. - Kombinieren Sie Crawler-Dateien mit Sitemap-, Canonical-, Schema- und llms.txt-Prüfungen.

Für Sicherheitsteams: - Behandeln Sie User-Agent-Strings als Behauptungen, nicht als Identität. - Verifizieren Sie Crawler per Reverse DNS oder veröffentlichten IP-Bereichen, sofern der Betreiber das unterstützt. - Erzwingen Sie den Zugriff auf sensible Ressourcen durch Authentifizierung, WAF-Regeln, Anwendungsrichtlinien und Ratenbegrenzung, nicht durch Crawler-Etikette.

Was hat sich mit Agents.txt geändert?

robots.txt gibt es seit Jahrzehnten. Der RFC definiert eine robots.txt-Datei, die Dienstbetreiber bereitstellen, damit Crawler entscheiden können, auf welche URIs sie zugreifen dürfen.2 Die Grundform der Datei wirkt vertraut:

User-agent: *
Disallow: /private-draft/
Sitemap: https://example.com/sitemap.xml

agents.txt gehört in eine andere Phase. Das Web bekommt nicht mehr nur Suchmaschinen-Crawler. Es bekommt Trainings-Crawler, Antwortmaschinen-Crawler, Crawler für Anzeigensicherheit, Browser-Assistentenabrufe, benutzerausgelöste LLM-Abrufe, Archiv-Crawler, SEO-Werkzeuge und Spam-Bots, die Namen legitimer Crawler übernehmen.

DreamHosts Dokumentation ist relevant, weil sie agents.txt von einer Nischenidee in das Standardverhalten mindestens eines etablierten Hosts verschiebt. Der Artikel sagt, DreamHost füge bei Web-Hosting-Tarifen automatisch standardmäßige robots.txt- und agents.txt-Dateien hinzu und lasse Website-Betreiber beide Dateien überschreiben, indem sie eine eigene Datei im Stammverzeichnis der Website platzieren.1 Dadurch wird agents.txt nicht zu einem Standard mit Durchsetzungssemantik. Der Dateiname wird aber wahrscheinlicher in freier Wildbahn auftauchen.

Die sichere Lesart ist eng:

Datei Beste Rolle Falsche Annahme
robots.txt Crawling-Präferenz für konforme Crawler. „Blockiert heißt privat.“
llms.txt Kuratierte, für LLMs lesbare Übersicht für die Nutzung zur Inferenzzeit. „Aufgeführt heißt gerankt oder zitiert.“
agents.txt Richtlinienhinweis für Agenten, wenn eine Plattform danach sucht. „Ein Bot muss sich daran halten.“
Sitemap Vollständige URL-Erkennung für indexierbare öffentliche Seiten. „Eingereicht heißt indexiert.“
Serverprotokolle Nachweis dessen, was tatsächlich passiert ist. „Kein sichtbarer Referrer heißt, kein Crawler hat die Seite genutzt.“

Die Dateinamen sollten nicht konkurrieren. Sie sollten ein Richtlinienpaket bilden: was Crawler anfordern dürfen, was KI-Systeme lesen sollten, was Agenten wissen sollten und was der Server tatsächlich beobachtet hat.

Robots.txt bleibt wichtig, schützt aber nicht

Crawler-Dateien versagen, wenn Teams sie als Sicherheitsgrenze verwenden.

Der RFC zieht diese Grenze ausdrücklich. Das Protokoll bittet automatisierte Clients, beim Zugriff auf URIs Regeln zu beachten; es autorisiert keinen Zugriff.2 Google beschreibt dieselbe Lage operativ: Wenn eine andere Seite auf eine gesperrte URL verweist, kann Google die URL-Adresse und andere öffentliche Linkinformationen trotzdem finden und indexieren, auch ohne den Inhalt der blockierten Seite zu crawlen.3 DreamHost warnt, dass Robots-Regeln für konforme Suchmaschinen als Empfehlungen wirken und schlechte Bots die Datei ignorieren oder falsche User-Agents verwenden können.1

Daraus folgt eine einfache Regel: Schreiben Sie nichts in robots.txt, agents.txt oder llms.txt, das Ihnen schaden würde, wenn es in ein Suchergebnis kopiert, in einen Datensatz gescrapt oder von einem LLM angezeigt würde.

Schlechte Crawler-Dateien verraten mehr, als sie schützen:

User-agent: *
Disallow: /internal-product-roadmap/
Disallow: /legal-private/
Disallow: /prompt-drafts/
Disallow: /customers/acme-renewal-risk/

Diese Datei sagt jedem Besucher, wo sensibles Material liegen könnte. Ein konformer Crawler meidet diese Pfade vielleicht. Ein Angreifer bekommt eine Verzeichnisübersicht.

Eine sicherere Datei formuliert öffentliche Crawling-Regeln, ohne sensible Bestände zu benennen:

User-agent: *
Allow: /
Disallow: /*.md$
Sitemap: https://example.com/sitemap.xml

Diese Version drückt eine echte Präferenz aus, ohne private Struktur offenzulegen. Falls /prompt-drafts/ existiert, sollte der Server den Pfad mit Authentifizierung und, wo passend, noindex-Headern schützen. Die Crawler-Datei sollte diese Last nicht tragen.

KI-Crawler brauchen Richtlinien nach Zweck

Suchcrawler-Richtlinien wirkten früher binär: Googlebot zulassen, laute SEO-Werkzeuge blockieren, private Seiten mit Serverkontrollen privat halten.

KI-Crawler bringen den Zweck hinzu. Ein Website-Betreiber möchte vielleicht, dass eine Seite in ChatGPT-Suchergebnissen erscheint, dieselbe Seite aber nicht für Modelltraining genutzt wird. OpenAIs Crawler-Dokumentation macht diese Trennung ausdrücklich. Dort heißt es, OAI-SearchBot unterstütze ChatGPT-Suchfunktionen, während GPTBot Inhalte crawle, die für das Training generativer KI-Grundlagenmodelle von OpenAI verwendet werden können.4 OpenAI sagt außerdem, diese Einstellungen seien unabhängig: Ein Webmaster kann OAI-SearchBot zulassen und GPTBot ausschließen.4

Google zieht eine ähnliche Grenze auf andere Weise. Die Google-Crawler-Dokumentation sagt, Google-Extended habe keinen eigenen HTTP-Request-User-Agent-String; vorhandene Google-User-Agents führen das Crawling aus, und Google-Extended dient als robots.txt-Produkttoken.5 Google sagt, das Token steuere, ob gecrawlte Website-Inhalte künftiges Gemini-Modelltraining und Grounding unterstützen dürfen, und beeinflusse weder die Aufnahme in die Google-Suche noch das Ranking.5

Diese beiden Beispiele zeigen, warum eine flache Blockierliste am Kern vorbeigeht. Die echte Richtlinienmatrix fragt:

Zweck Beispielsignal Betreiberfrage
Sucherkennung Googlebot, Bingbot, OAI-SearchBot Soll die Seite in Such- oder Antwortergebnissen erscheinen?
Trainingspräferenz GPTBot, Google-Extended Soll die Seite für Modelltraining oder Modell-Grounding verwendet werden?
Benutzerausgelöster Abruf ChatGPT-User, Browser-Assistenten Hat ein Mensch den Assistenten gebeten, die Seite abzurufen?
Website-Verständnis llms.txt, Schema, RSS Habe ich KI-Systemen eine klare Erklärung der öffentlichen Inhalte gegeben?
Missbrauchsverkehr Gefälschte User-Agents, Scraper-Werkzeuge Hat die Anfrage Identität belegt und sich innerhalb der Richtlinie verhalten?

Die Richtliniendatei sollte zum Zweck passen. Schließen Sie nicht jeden KI-User-Agent aus und wundern Sie sich dann, warum KI-Suchoberflächen die Website ignorieren. Lassen Sie nicht jeden KI-Crawler zu und beschweren Sie sich danach, wenn Trainings-Crawler Seiten abrufen, die nur für benutzerorientierte Suche gedacht waren. Trennen Sie die Zwecke, formulieren Sie die Präferenz und prüfen Sie das Verhalten.

Llms.txt löst ein anderes Problem

llms.txt ersetzt robots.txt nicht. Jeremy Howards Vorschlag beschreibt /llms.txt als Möglichkeit, Informationen bereitzustellen, die LLMs bei der Nutzung einer Website zur Inferenzzeit helfen.6 Derselbe Vorschlag sagt, llms.txt könne mit bestehenden Webstandards koexistieren: Sitemaps listen Seiten für Suchmaschinen auf, während llms.txt LLMs eine kuratierte Übersicht bietet und robots.txt mit Kontext zu erlaubten Inhalten ergänzen kann.6

Für AIO-Arbeit ist diese Unterscheidung wichtig.

robots.txt beantwortet: „Darf dieser Crawler diesen Pfad anfordern?“

llms.txt beantwortet: „Wenn ein Assistent meine Website liest, was sollte er zuerst verstehen?“

agents.txt kann beantworten: „Was sollten agentenbasierte Clients über gewünschtes Verhalten wissen?“

Diese Fragen liegen nah beieinander, fallen aber nicht in einer Datei zusammen. Eine ernsthafte Website sollte KI-Auffindbarkeit wie eine Veröffentlichungsfläche behandeln:

  1. Veröffentlichen Sie kanonische Seiten mit klaren Titeln und Beschreibungen.
  2. Ergänzen Sie strukturierte Daten, die zur sichtbaren Seite passen.
  3. Halten Sie Sitemap- und RSS-Ausgaben aktuell.
  4. Veröffentlichen Sie llms.txt und llms-full.txt für kuratierten KI-Kontext.
  5. Veröffentlichen Sie robots.txt mit ausdrücklicher Crawler-Richtlinie.
  6. Ergänzen Sie agents.txt nur, wenn die Plattform oder das Agenten-Ökosystem der Datei einen konkreten Leser gibt.
  7. Prüfen Sie die Protokolle, um zu bestätigen, dass Crawler die geänderten Dateien anfordern.

Wer den letzten Schritt auslässt, macht aus AIO ein Hoffnungsritual. Die Crawler-Datei existiert. Die Route gibt 200 zurück. Kein Nachweis belegt, dass die vorgesehenen Clients sie gesehen haben.

Verifizierung gehört an die Server-Edge

User-Agent-Strings beweisen keine Identität. Ein beliebiges Skript kann User-Agent: Googlebot senden. Ein Scraper kann User-Agent: GPTBot senden. Eine Richtlinie, die allein dem Header vertraut, behandelt die am großzügigsten, deren Behauptung am leichtesten zu fälschen ist.

Google dokumentiert 2 Verifizierungswege für Anfragen, die behaupten, von Google zu stammen: Reverse DNS plus Forward DNS für Einzelprüfungen und Abgleich mit veröffentlichten IP-Bereichen für größere Systeme.7 OpenAI veröffentlicht IP-Adress-JSON-Dateien für OAI-SearchBot, GPTBot und ChatGPT-User in seiner Crawler-Dokumentation.4 Diese Mechanismen decken nicht jeden Crawler ab. Sie zeigen aber die richtige Form: Identität braucht mehr Nachweise als eine Zeichenfolge.

Die minimale Richtlinie an der Server-Edge sollte aufzeichnen:

Nachweis Warum er zählt
User-Agent Zeigt die Behauptung des Clients.
Quell-IP und ASN Hilft, Cloud-Scraper von verifizierten Crawler-Bereichen zu trennen.
Reverse-DNS- oder IP-Bereichsergebnis Belegt Identität, wenn der Betreiber Verifizierung unterstützt.
Angeforderter Pfad Zeigt, welche Inhalte der Client tatsächlich berührt hat.
Abrufzeitpunkt von robots.txt Zeigt, ob der Client vor dem Crawling die Richtlinie geprüft hat.
Statuscode und Cache-Ergebnis Zeigt, was der Crawler erhalten hat.
Rate und Pfadmuster Deckt Missbrauch auch bei benannten Bots auf.

Dieses Protokollpaket macht aus Crawler-Richtlinien Nachweise statt Meinungen. Wenn GPTBot weiter ausgeschlossene Pfade anfordert, können Sie es belegen. Wenn ein falscher Googlebot private wirkende URLs von einem privaten Proxy aus hämmert, können Sie ihn blockieren, ohne den echten Googlebot zu bestrafen. Wenn OAI-SearchBot den geänderten Artikel nie anfordert, wissen Sie, warum die Seite in der ChatGPT-Suche nicht erscheint.

Ein praktisches Richtlinienpaket für KI-Crawler

Beginnen Sie nicht mit der Datei. Beginnen Sie mit dem Ergebnis.

Ergebnis Erforderliche Kontrolle
Suchmaschinen sollen öffentliche Seiten indexieren. Sitemap, Canonical-Tags, Schema, schnelle 200-Antworten und erlaubte Suchcrawler.
KI-Antwortmaschinen sollen die Website verstehen. Saubere Artikel, Schema, RSS, llms.txt und Quellseiten mit ausdrücklichen Zusammenfassungen.
Trainings-Crawler sollen bestimmte Inhalte meiden. Zweckbezogene robots.txt-Gruppen plus Serverdurchsetzung, wo Richtlinien oder Recht es verlangen.
Private Inhalte müssen privat bleiben. Authentifizierung, Autorisierung, keine öffentlichen Links, keine Offenlegung in Crawler-Dateien und kein Cache-Leck.
Schlechte Bots sollen keine Ressourcen aufzehren. Ratenbegrenzung, WAF-Regeln, Ausnahmen für verifizierte Bots und Missbrauchsprotokolle.
Richtlinienänderungen sollen prüfbar sein. Routenprüfungen, Crawler-Abrufprotokolle, Deployment-Zeitstempel und ein kurzes Review-Paket.

Dieses Paket gibt jeder Ebene die richtige Aufgabe. robots.txt kommuniziert Präferenzen. llms.txt kommuniziert Kontext. agents.txt kommuniziert agentenbezogene Absicht, sofern ein Leser existiert. Der Server setzt durch. Die Protokolle belegen.

Auf meiner eigenen Website folgt Crawler-Arbeit dieser Trennung. Die öffentliche Richtliniendatei heißt legitime Crawler willkommen und blockiert rohe Markdown-Pfade, die Crawler aus Codeblock-Beispielen abgeleitet hatten. Die KI-Kontextdateien geben Assistenten einen kuratierten Einstieg in die öffentlichen Texte. Die nächtliche Crawling-Bestandsaufnahme zeigt mir, ob Crawler Fehler, veralteten Cache, fehlende Routen oder alte URLs gesehen haben, die inzwischen 410 zurückgeben sollten. Die Richtliniendatei liefert Absicht. Die Protokolle entscheiden, ob die Absicht funktioniert hat.

Was in Agents.txt gehört

Solange sich das Ökosystem nicht stabilisiert hat, sollte agents.txt langweilig und öffentlich bleiben.

Gute Kandidaten:

  • Website-Kontakt und Richtlinien-URL.
  • Verweise auf robots.txt, Sitemap, llms.txt und RSS.
  • Eine Aussage zur bevorzugten Nutzung öffentlicher Inhalte.
  • Ein Hinweis, dass private oder authentifizierte Routen Autorisierung erfordern.
  • Eine Support-Adresse für Crawling-Probleme.

Schlechte Kandidaten:

  • Geheime Pfade.
  • Interne Prompt-Regeln.
  • Nicht öffentliche API-Routen.
  • Kundennamen.
  • Sicherheitsausnahmen.
  • Anweisungen, die der Website schaden würden, wenn ein feindlicher Client sie kopiert.

Der richtige Maßstab für agents.txt lautet nicht: „Würde ein guter Agent das hilfreich finden?“ Der richtige Maßstab lautet: „Wäre es für mich in Ordnung, wenn ein schlechter Agent, ein Suchergebnis und ein beliebiger Benutzer diese Datei alle lesen?“

Das bessere Denkmodell

Crawler-Dateien sind Schilder an einer öffentlichen Straße.

Ein Schild kann „Lieferanteneingang“, „Einfahrt verboten“ oder „Hier beginnen“ sagen. Rücksichtsvolle Fahrer halten sich daran. Rücksichtslose ignorieren es. Trotzdem hilft das Schild, weil der meiste legitime Verkehr klare Anweisungen möchte. Das Schild scheitert, sobald Sie es wie eine verschlossene Tür behandeln.

KI-Crawler machen diese Schilder zugleich wichtiger und weniger ausreichend. Wichtiger, weil KI-Systeme klaren öffentlichen Kontext, zweckbezogene Richtlinien und Routenübersichten brauchen. Weniger ausreichend, weil sich User-Agents vermehren, Training und Suche auseinanderfallen und schlechte Clients gute imitieren können.

Die Antwort besteht nicht darin, Crawler-Dateien aufzugeben. Die Antwort besteht darin, ihre Autorität auf die richtige Ebene zu senken. Veröffentlichen Sie klare öffentliche Richtlinien. Verifizieren Sie, wer die Dateien anfordert. Beobachten Sie, was abgerufen wird. Erzwingen Sie private Grenzen am Server. Behandeln Sie jede Behauptung über „KI-Sichtbarkeit“ als unbewiesen, bis Protokolle und Live-Routen sie stützen.

Das ist der Unterschied zwischen AIO-Theater und echtem Crawler-Betrieb.


FAQ

Was ist agents.txt?

agents.txt ist eine entstehende Textdatei für Agenten, die einige Hosts oder Werkzeuge im Stammverzeichnis einer Website ausliefern können. DreamHost dokumentiert standardmäßige agents.txt-Dateien für Web-Hosting-Tarife, aber diese Dokumentation macht die Datei nicht zu einem Zugriffskontrollstandard. Behandeln Sie sie als öffentlichen Hinweis, bis eine konkrete Agentenplattform genau dokumentiert, wie sie die Datei liest und anwendet.1

Blockiert robots.txt KI-Crawler?

Konforme Crawler können robots.txt beachten, und große Betreiber dokumentieren spezifische Tokens für ihre Crawler. OpenAI dokumentiert Steuerungen für OAI-SearchBot und GPTBot, während Google Google-Extended als Produkttoken für Trainings- und Grounding-Präferenzen dokumentiert.45 robots.txt authentifiziert den Client aber weiterhin nicht, verbirgt keine Inhalte und stoppt keinen Bot, der die Datei ignorieren möchte.23

Sollte ich llms.txt veröffentlichen?

Veröffentlichen Sie llms.txt, wenn KI-Assistenten eine kuratierte Übersicht Ihrer öffentlichen Inhalte finden sollen. Der Vorschlag beschreibt llms.txt als Kontext zur Inferenzzeit, nicht als Ersatz für Sitemap oder robots.txt.6 Eine nützliche Datei verweist auf die Seiten, die Agenten tatsächlich verstehen sollen.

Kann eine ausgeschlossene URL trotzdem in der Suche erscheinen?

Ja. Google sagt, dass eine durch robots.txt blockierte URL trotzdem erscheinen kann, wenn andere Seiten darauf verlinken, auch wenn Google den Inhalt der blockierten Seite nicht crawlt oder indexiert.3 Nutzen Sie Authentifizierung, noindex dort, wo Crawling-Zugriff erlaubt ist, und serverseitige Richtlinien für Seiten, die aus öffentlichen Ergebnissen herausbleiben müssen.

Wie unterscheide ich einen echten Crawler von einem falschen?

Nutzen Sie mehr als den User-Agent-String. Google dokumentiert Reverse-DNS-plus-Forward-DNS-Prüfungen und den Abgleich mit veröffentlichten IP-Bereichen.7 OpenAI veröffentlicht IP-Adress-JSON-Dateien für seine dokumentierten Bots.4 Wenn ein Crawler-Betreiber keine Verifizierungsdaten veröffentlicht, behandeln Sie die Anfrage als Behauptung und begrenzen oder prüfen Sie sie nach Verhalten.

Was ist die sicherste Crawler-Datei-Konfiguration für eine öffentliche Website?

Nutzen Sie robots.txt für Crawler-Richtlinien, eine Sitemap für URL-Erkennung, llms.txt für kuratierten KI-Kontext und agents.txt nur für öffentliche Hinweise an Agenten. Halten Sie sensible Pfade aus allen öffentlichen Dateien heraus. Prüfen Sie danach Live-Routen, Cache-Zustand, Crawler-Abrufe und Serverprotokolle, bevor Sie sagen, dass die Einrichtung funktioniert.

Referenzen


  1. DreamHost, “Control bots, spiders, and crawlers,” DreamHost Knowledge Base. Abgerufen am 18. Mai 2026. 

  2. Koster, M., Illyes, G., Zeller, H., and Sassman, L., “RFC 9309: Robots Exclusion Protocol,” IETF, September 2022. 

  3. Google Search Central, “Introduction to robots.txt,” Google for Developers. 

  4. OpenAI, “Overview of OpenAI Crawlers,” OpenAI API Documentation. 

  5. Google Crawling Infrastructure, “Google’s common crawlers,” Google for Developers. 

  6. Jeremy Howard, “The /llms.txt file,” llms-txt proposal, 3. September 2024. 

  7. Google Crawling Infrastructure, “Verify requests from Google crawlers and fetchers,” Google for Developers, zuletzt aktualisiert am 20. März 2026. 

Verwandte Beiträge

Die Fork-Bomb hat uns gerettet

Der LiteLLM-Angreifer machte einen einzigen Implementierungsfehler. Dieser Fehler war der einzige Grund, warum 47.000 In…

5 Min. Lesezeit

Open Source ist keine Sicherheitsgrenze

Die GDS-Leitlinien zu KI-gestützter Schwachstellensuche treffen den Kern von Open-Source-Sicherheit: standardmäßig wenig…

9 Min. Lesezeit

Der Ralph-Loop: Wie ich autonome KI-Agenten über Nacht betreibe

Ich habe ein autonomes Agentensystem mit Stop-Hooks, Spawn-Budgets und Dateisystem-Speicher gebaut. Hier sind die Fehlsc…

8 Min. Lesezeit