Worin ich mich bei robots.txt geirrt habe

• Nach dem Versuch, über die robots.txt-Konfiguration alle Website-Crawler zu blockieren, traten unerwartete Nebenwirkungen auf
• Die LinkedIn-Beitragsvorschau verschwand, und auch die Reichweite der Beiträge nahm ab
• Die Ursache war, dass die robots.txt LinkedInBot den Seitenzugriff verweigerte und dadurch das Sammeln von Meta-Tags verhinderte
• Dadurch wurde mir neu bewusst, dass das Open Graph Protocol eine Schlüsselrolle bei der Erstellung von Vorschauen in sozialen Medien spielt
• Ich habe die robots.txt so angepasst, dass sie teilweise Zugriff erlaubt, und das Problem gelöst; künftig sind bei Funktionsänderungen ausreichende Tests nötig

---

Einleitung: robots.txt-Konfiguration und unbeabsichtigte Probleme

• Beim Lernen zur robots.txt-Konfiguration für meinen Blog habe ich über das Thema Datenrechte an meinen Inhalten nachgedacht
• Ich habe die robots.txt angepasst, um alle Crawler auf der Website zu blockieren
• Unerwartet führte das auf der Website zu unerwünschten Ergebnissen

Problem mit der LinkedIn-Beitragsvorschau

• Nachdem ich die robots.txt geändert hatte, erschien beim Posten meines Blog-Links auf LinkedIn keine Vorschau (Thumbnail, Kurzbeschreibung) mehr
• Zuvor wurde die Vorschau normal angezeigt, nach der Änderung gingen jedoch Sichtbarkeit und Reaktionen stark zurück
• Zunächst hielt ich es für ein vorübergehendes Problem, doch das Phänomen hielt mehr als zwei Wochen an
• Die Analyse mit dem LinkedIn Post Inspector zeigte, dass die robots.txt den Zugriff von LinkedInBot einschränkte, sodass keine Metainformationen gesammelt werden konnten
• Auf Social-Media-Plattformen sind Seitenabrufe und das Sammeln von Meta-Tags unverzichtbar, um Link-Vorschauen zu erzeugen

Einführung in das Open Graph Protocol

• Das Open Graph Protocol (OGP) ist ein von Facebook entwickeltes Standardprotokoll, das eine Webseite in ein Objekt des sozialen Graphen verwandelt
• OGP definiert mindestens die erforderlichen Meta-Tags
  • og:title: Titel des Beitrags
  • og:type: Objekttyp, zum Beispiel "video.movie"
  • og:image: URL des Thumbnail-Bildes
  • og:url: repräsentative URL des Objekts
• Dank dieses Protokolls können Inhalte auf verschiedenen sozialen Plattformen effektiv zusammengefasst und attraktiv dargestellt werden

Lösung durch teilweise Freigabe in robots.txt

• Zur Behebung des Problems habe ich die robots.txt so geändert, dass nur LinkedInBot zugelassen wird
• Wenn auch Vorschauen auf anderen sozialen Plattformen benötigt werden, müssen die jeweiligen Bots separat erlaubt werden
• Beispiel für die aktuell verwendete Konfiguration:

  User-agent: LinkedInBot
  Allow: /
  
  User-agent: *
  Disallow: /
  

Rückblick und Erkenntnisse

• Wenn man alle Crawler pauschal blockiert, kann das Probleme bei Sichtbarkeit und Präsentation von Inhalten verursachen
• Mir wurde klar, dass es ein Fehler war, die Änderung ohne ausreichende Tests ihrer Auswirkungen vorzunehmen
• Durch diese Erfahrung habe ich mehr über nützliche Tools und Webstandards wie das Open Graph Protocol und den LinkedIn Post Inspector gelernt
• Bei Funktionsergänzungen oder -änderungen ist ein ausreichendes Verständnis und eine gründliche Prüfung aller betroffenen Bereiche erforderlich
• Anfangs habe ich den Zusammenhang zwischen OGP und der Blockierung durch robots.txt nicht erkannt, aber durch diese Erfahrung die Bedeutung verstanden

[GN⁺]

Hacker-News-Kommentare

• Früher bestand der Hauptzweck von robots.txt darin, Duplicate-Content-Penalties in Suchmaschinen zu vermeiden. Wenn man schwer zu verwaltende dynamische Websites betrieb, wurde durch Query-Parameter und Ähnliches dieselbe Seite unter mehreren URLs sichtbar, und Suchmaschinen verhängten dafür Abstrafungen. robots.txt diente dazu zu sagen: „Das hier ist die kanonische URL, den Rest bitte ignorieren.“ Außerdem half es dabei, dass sich „gute“ Crawler nicht in unendlichen Link-Strukturen verirrten. „Böse“ Crawler kümmerte das natürlich nie, und solche Bots blockierte man per IP-Sperre. Sperren auf Basis des User-Agent waren sinnlos. Zu glauben, dass bösartige Bots brav die Regeln einhalten, ist naiv. Der DNT-(Do Not Track)-Header war ähnlich: Man bittet damit Firmen, deren Geschäftsmodell Tracking ist, einfach darum, bitte nicht zu tracken. Oder es erinnert an die RFC-Idee des Evil Bit, bei der man hofft, dass bösartige Pakete im Header direkt angeben: „Ich bin schädlich“

  • Man sollte daran denken, dass der Evil-Bit-Vorschlag ein Aprilscherz-RFC war RFC 3514 ansehen

  • Am Ende kommt einem vielleicht der Gedanke, robots.txt habe eine ähnliche Rolle wie eine Sitemap, aber tatsächlich ist es das genaue Gegenteil. robots.txt zeigt Crawlern, wo sie nicht hin sollen, die Sitemap zeigt, was indexiert werden soll. Dass der ursprüngliche Zweck in der Verwaltung von Duplicate-Content-Penalties lag, wusste ich nicht; das gibt dem Blick auf SEO-Kontrolle einen neuen Kontext

  • Der Kernpunkt ist: Wenn man ein Verhalten als „verboten“ deklariert, wirkt das nur bei einigen ehrlichen Akteuren oder bei solchen, die versehentlich ihren User-Agent-Namen nicht ordentlich verschleiern. Darüber hinaus funktioniert es kaum, letztlich ist es also eher eine symbolische Maßnahme

  • Wie beim DNT-Header werden Versuche, die praktisch schwer durchsetzbar wirken, oft kritisiert. Tatsächlich war die DNT-Idee aber ein Versuch, das zusammen mit rechtlichen Instrumenten anzuwenden. Selbst wenn eine vollständige technische Blockade schwierig ist, muss man berücksichtigen, dass massenhafte Rechtsverstöße am Ende durch Whistleblower ans Licht kommen können

  • Es gibt Leute, die glauben, wenn man Regeln aufstellt, würden sich alle daran halten; da fragt man sich manchmal, ob dieser Glaube auf kulturelle Unterschiede zurückgeht

• 2003 habe ich selbst eine Suchmaschine gebaut und das Web gecrawlt. Weil ich meine Kontaktadresse in den User-Agent geschrieben hatte, bekam ich unglaublich viele Beschwerde-Mails. Obwohl ich versucht hatte, den Crawler so gewissenhaft und höflich wie möglich zu bauen, hatte ich den Eindruck, dass die Leute alles außer Google nicht wollten. Genau diese Haltung verhindert das Entstehen von Konkurrenz zu Google. Das ist nicht nur auf LinkedIn-Preview-Probleme beschränkt; man sollte bedenken, dass das Web offen für verschiedenste Bots und Nutzer sein sollte. Natürlich muss man bösartige Crawler blockieren, aber grundsätzlich jeden Bot als feindselig zu behandeln, ist nicht wünschenswert

  • Die nervigste Erfahrung aus der Perspektive eines gutartig betriebenen Bots war, dass jemand mit dem User-Agent meines Bots einen bösartigen Bot gebaut und damit Angriffe gefahren hat, woraufhin die Beschwerden bei mir landeten

  • Jeder will vielleicht seinen eigenen Bot schützen, aber in Wirklichkeit geht es nicht nur um den eigenen Bot; das Problem ist, dass 9000 gleiche Bots herumlaufen und übermäßig Server-Ressourcen verbrauchen. Solche Bots bringen in der Praxis auch keinen Referral-Traffic

  • Ich habe anfangs ebenfalls den Ansatz verfolgt, alles zu blockieren, aber dann die Vernetztheit und Komplexität des Webs erkannt. Es ist wichtig, Kontrolle über die eigenen Ressourcen zu haben. Wenn man aber entscheidet, welchen Traffic man erlaubt oder blockiert, sollte man sich selbst fragen: „Warum?“ und wissen, was jeder Bot konkret macht. Dieser Prozess kostet Zeit und Aufwand. Auf robots.txt aufmerksam geworden bin ich ursprünglich durch die Praxis von AI-Firmen, wahllos für Trainingsdaten zu crawlen. Ich möchte selbst entscheiden, was ich erlaube und was nicht. Nicht alle Bots halten sich an robots.txt, aber viele tun es. Eine Möglichkeit zum direkten Test ist, über ein browsendes Modell das Scraping eines bestimmten Links anzufordern. Grundsätzlich ist wichtiger, wie ein Unternehmen die Daten nutzt und wie ich das bewerte, als ob ein Bot „bösartig“ ist

  • Auf das Argument „Nicht alle Bots sind bösartig, also sollte man nicht pauschal blockieren“ würde ich sagen, dass Zugriffe ohne Vertrauensgrundlage grundsätzlich eine riskante Strategie sind

  • Es ist ganz natürlich, unbekannten Crawlern zu misstrauen. Die meisten Crawler sind bösartig, und man kann im Voraus nicht erkennen, welche gut oder schlecht sind; deshalb ist es vernünftig, unbekannte Bots standardmäßig vorläufig als bösartig zu behandeln

• Ich bemühe mich, harsche Kritik zu vermeiden, aber bei diesem Text erstaunt mich, wie sehr der Autor so tut, als habe er die Folgen seines Handelns tiefgreifend erkannt. Eine persönliche Wachstumsgeschichte kann zwar sinnvoll sein, aber dieser Text wirkt eher wie ein Geständnis von Unwissen als wie ein Beitrag mit Einsicht. Am Ende fühlt es sich an, als sei er vor allem geschrieben worden, um Aufmerksamkeit zu bekommen

  • Der Autor hatte einen Page-Preview-Fetcher nicht als Crawler erkannt und deshalb nicht daran gedacht, ihn per robots.txt zu blockieren. Auch wenn das nicht gerade revolutionär ist, gab es für ihn zumindest etwas Neues zu lernen. Ein tatsächlich von Menschen geschriebener Blogpost kann die durchschnittliche Qualität des Webs erhöhen

  • Weil der Text bei Google nicht sichtbar ist, wurde er hier (Hacker News) gepostet

  • Für mich gab es ebenfalls Teile, die sich ganz praktisch neu anfühlten. Ich hatte dadurch einen Anlass, mehr über das Open Graph Protocol und das Robots Exclusion Protocol zu lernen. Dinge, die ich selbst lerne oder interessant finde, halte ich gern fest und teile sie, weil sie auch für andere interessant sein könnten

  • Ich frage mich, wie dieser Text auf die Frontpage gekommen ist. Es scheint ein lang ausgewalzter Beitrag über die völlig offensichtliche Aussage zu sein: „Wenn man Wasser absperrt, weichen die Guten aus und die Schlechten ignorieren es.“ Dass robots.txt letztlich nur ein höfliches „Bitte nicht“ und keine Firewall ist, liegt doch auf der Hand

• Das Problem von robots.txt ist letztlich, dass nicht nach dem Zweck eines Crawlers gefiltert wird, sondern nach seiner „Identität“. Auch der Autor hat zum Blockieren von AI-Sammlern erst alle Bots gesperrt und dann OpenGraph-Preview-Crawler (wie von LinkedIn) wieder zugelassen. Aber was ist, wenn jemand auf Twitter oder Mastodon oder anderen Plattformen teilt? Dann muss man die UAs sämtlicher Social-Media-Dienste einzeln erlauben, und das begünstigt letztlich nur einige wenige große Plattformen. Eigentlich braucht man ein Mittel, um „AI-Training blockieren, aber Suchindexierung, Previews, Archivierung usw. erlauben“ ausdrücken zu können. Um das praktisch durchzusetzen, wäre wohl ein rechtlicher Rahmen nötig, aber auch das ist nicht einfach

  • Es gab schon immer Diskussionen über den grundlegenden Zweck von robots.txt. Meiner Ansicht nach war es ursprünglich – und ist es meist bis heute – für Crawler gedacht, also für Software, die Links folgt und Neues entdeckt. Suchmaschinen sind das typische Beispiel. Wenn aber ein Nutzer gezielt eine bestimmte URL anfordert, etwa im Browser oder per iCal-Abo, muss robots.txt nicht beachtet werden. Tatsächlich gab es Fälle, in denen Dienste wie Google Calendar wegen robots.txt-Sperren keine Abos anlegen konnten, was ich für ein Fehlverhalten halte. Bei URL-Previews gilt: Wenn ein Nutzer nur einen einzelnen Link anfordert, ist das eher eine gezielte Anfrage als Crawling. Wenn jedoch in einer langen Nachricht viele Links stehen, kommt das wiederum einer Art Crawling nahe. Deshalb finde ich die Frage weiterhin offen, ob URL-Preview-Funktionen sozialer Medien robots.txt folgen sollten

  • Daten wie Common Crawl können sowohl für Suchmaschinen als auch für AI-Training und andere Zwecke wiederverwendet werden. Eine Trennung nach Verwendungszweck ist nicht einfach

  • Man könnte das lösen, indem man die Informationsweitergabe nicht in-band, sondern out-of-band trennt. Wenn Open-Graph-Metadaten über einen separaten Pfad oder Header bereitgestellt würden, könnte man genau diesen Pfad – mit den wenig nützlichen Daten – erlauben und den eigentlichen Inhalt strikt verweigern. Ein rechtlicher Rahmen ist dafür nicht zwingend erforderlich

  • Mir gefällt die Idee eines Standards, mit dem man nach Funktion bzw. Zweck klassifiziert erlauben oder blockieren kann. Entscheidend wären dann aber die Verifikation der Funktion und der Schutz vor Spoofing, und am Ende hängt es doch wieder mit rechtlichen Fragen zusammen. Wahrscheinlich müsste man verschiedene Plattformen wie Social-Media-Previews erneut freischalten, und ich lerne viel dabei, sorgfältig auszuwählen, was ich erlauben oder blockieren will. Gerade das Einholen verschiedener Meinungen ist dabei sehr hilfreich

• An den OP: 1) Du hattest nur LinkedIn im Blick, aber tatsächlich können meine Links auch auf anderen sozialen Plattformen wie Facebook oder Bluesky geteilt werden. Ich habe erlebt, dass man mit der ai.robots.txt von Facebook sogar die FB-Preview-Crawler mit blockieren kann (Beispiel für ai.robots.txt).

2. Was Google-Ranking und robots.txt-Blockierung betrifft: Selbst wenn robots.txt die Suchsichtbarkeit einschränkt und andere Faktoren wie indirekte Links ebenfalls eine Rolle spielen, ist es für Naver-/Google-SEO grundsätzlich deutlich besser, direktes Crawling zu erlauben. Wenn man blockiert, erscheinen in Suchergebnissen keine Thumbnails oder Beschreibungen, wodurch die Qualität sinkt. Wenn Traffic über Suchmaschinen wichtig ist, sollte man eine vollständige Sperre per robots.txt gut überdenken

• Danke für das Feedback! 1) Ich hatte ebenfalls nur an LinkedIn und HN gedacht. Dass andere Leute meinen Blog-Link auf verschiedensten Plattformen teilen könnten, hatte ich nicht bedacht. Möglicherweise muss ich überdenken, verschiedenen Plattformen den Zugriff zu erlauben. 2) Wenn ich sehe, dass Suchmaschinen-Trends immer stärker in Richtung AI-Zusammenfassungen gehen, glaube ich, dass der organische Traffic auf die eigentliche Website künftig sinken wird. Deshalb bedaure ich rückläufigen Google-Suchtraffic nicht besonders. Das kann sich noch ändern, aber momentan glaube ich, dass HN und Mundpropaganda über Social Sharing für meinen Blog wertvolleren Traffic bringen. Ich will noch weiter prüfen, ob meine Entscheidung mir nicht am Ende selbst schadet. Die unterschiedlichen Meinungen helfen mir bei der Entscheidungsfindung sehr

• Es gibt noch einen weiteren Nebeneffekt, der aus der Verwechslung von „Crawling“ und „Indexierung“ bei robots.txt entsteht.
  Um neue Seiten grundsätzlich aus dem Google-Index fernzuhalten, kann eine robots.txt-Sperre wirksam sein.
  Wenn man aber bereits indexierte Seiten entfernen möchte und sie nur in robots.txt einträgt, ist das ein Fehler. Google kann sie dann nicht mehr crawlen, zeigt sie aber ohne Metadaten weiter in den Suchergebnissen an, und weil das noindex-Meta-Tag nicht geprüft werden kann, können sie am Ende noch lange in der Suche verbleiben. Google entfernt die Seite irgendwann vollständig, aber dieser Prozess kann sehr frustrierend sein

  • Google kann URLs, die durch robots.txt blockiert sind, über externe Links und Ähnliches trotzdem kennen; in solchen Fällen kann trotz fehlendem Crawling ein indexierter Eintrag in den Suchergebnissen verbleiben (Warnung siehe: offizielle Google-Dokumentation). Um eine Seite vollständig aus den Suchergebnissen zu entfernen, muss unbedingt ein noindex-Tag im Code stehen; bei einer robots.txt-Sperre kann dieses Tag aber nicht gelesen werden, daher ist Vorsicht geboten

  • In meinem Fall will ich gar nicht unbedingt, dass Google die Seite aus dem Index entfernt. Die Indexierung ist mir gleichgültig; mich stören nur Crawling und Scraping. Ich gebe zu, die Begriffe manchmal verwechselt zu haben

• Dieser Text wirkt so, als würde er eine Sache, die in ein oder zwei Sätzen gesagt wäre, unnötig in die Länge ziehen. Fast wie das künstliche Aufblähen einer Schulaufgabe

  • Das Problem hätte man in einem Absatz erklären können. Der Zweck meines Textes war aber, meinen Weg von der Erfahrung über das Problem und die Recherche bis hin zur Lösung festzuhalten. Ich habe bewusst so ausführlich geschrieben, dass auch technisch weniger versierte Leser folgen können

• Die grundlegende Grenze von robots.txt ist, dass nicht die Bots das Problem sind, die robots.txt befolgen, sondern die, die es nicht tun. robots.txt kann die meisten Bots, die heute Traffic-Probleme verursachen, nicht kontrollieren. Gerade die wirklich schädlichen Bots, die Server belasten oder beschädigen, kümmern sich überhaupt nicht um robots.txt

  • Um solche Bots zu erwischen, kann ein „Honeypot“ nützlich sein. Man blockiert in robots.txt explizit den Pfad /honeypot und fügt in index.html einen per display:none versteckten Link <a href="/honeypot">ban me</a> hinzu. Jede IP, die diesen Pfad aufruft, kann man sofort blockieren

  • Ich weiß nicht, warum das Downvotes bekommen hat. Es gibt keinen belastbaren Grund, darauf zu vertrauen, dass große Unternehmen wie OpenAI oder Anthropic robots.txt wirklich gut einhalten. Diese Firmen verschleiern die Erkennung zusätzlich, indem sie Traffic über IPs von Residential-ISPs umleiten, und verteilen Verantwortung, indem sie sich der direkten Nachverfolgung durch „Drittanbieter-Werbung“ entziehen

• Was mich am meisten schockiert: Es gibt kaum gut aufbereitete Parser-Bibliotheken dafür, robots.txt und Meta-Robots-Tags gemeinsam auszuwerten und bei Konflikten eine klare Priorität von Erlauben/Blockieren zu bestimmen. Der offizielle Google-Referenzparser ist ein seltener C++11-Fall, und bei verbreiteten Python- oder JS-Bibliotheken müssen Entwickler solche Dinge oft selbst umsetzen. Bei Meta-Robots steckt die Information zudem nicht einmal in robots.txt, sondern in index.html. Selbst für Bot-Autoren mit guten Absichten ist die Implementierung dadurch unnötig schwer

  • In der Python-Standardbibliothek gibt es urllib.robotparser (offizielle Dokumentation). rel=nofollow verfolgt hingegen einen völlig anderen Zweck als robots.txt. Dieses Attribut bedeutet, dass Suchmaschinen diesem Link nicht „vertrauen“ bzw. ihm keinen Linkwert zuweisen sollen; es heißt nicht „folge diesem Link nicht“ (Details). Ursprünglich sollte es verhindern, dass in Spam-Communities massenhaft Links zur eigenen Website hinterlassen werden

  • Ein „gutartiger“ Bot-Entwickler mit knappen Ressourcen bombardiert Server ohnehin nicht wahllos; insofern ist eine fehlende Bibliothek in der Praxis oft kein großes Problem

  • Wenn man in guter Absicht einen vernünftigen Bot bauen will, könnte man einen Parser auch einfach selbst in eine andere Sprache portieren, als Open Source veröffentlichen und bereitstellen. Das ist durchaus machbar

• Interessanterweise geht Apple dieses Problem anders an. Wenn man in iMessage einen Link teilt, holt sich der Client auf der sendenden Seite die Daten für die Vorschau direkt selbst. Dienste wie LinkedIn scrapen Link-Daten serverseitig aus bestimmten Gründen – etwa zur Spam- oder Phishing-Abwehr –, aber es ist auf jeden Fall ein anderer Ansatz

  • Ich fand es auch naheliegend, dass der Client nach Erhalt einer Nachricht mit Links die Vorschau selbst erzeugen könnte, und hatte gehofft, dass das bereits jemand anspricht. Gleichzeitig verstehe ich die verschiedenen Gründe für serverseitiges Scraping. 1) Vorbereitung auf eine Zukunft, in der alle Seiten gecrawlt und genutzt werden; 2) selbst wenn sich Seiten ändern, 404 liefern oder die Client-Datenbank verloren geht, kann der Server weiterhin bereits extrahierte Vorschauinformationen liefern; 3) der Client muss die Vorschau nicht selbst erzeugen, und man kann zusammen mit der Nachricht schnell einen Ausblick anzeigen. Wenn am Ende wie bei iMessage der „Absender“ die Vorschau erzeugt, bleiben davon im Grunde nur „1“ und ein Teil von „2“ übrig, und für die Zuverlässigkeit kann es die bessere Wahl sein, wenn der Server selbst weitere Retry-Versuche unternimmt