Seiten über robots.txt sperren
Jürgen
- sonstiges
0 Christian Kruse0 beatovich2 Regina Schaukrug0 pl0 Jürgen
Hallo, was sperrt man sinnvollerweise mit disallow? Gehören dazu auch Bibliotheken mit CSS-Dateien oder php-Unterroutinen oder Ordner mit Bildern, die in den Seiten angeeigt werden?
Hallo Jürgen,
was sperrt man sinnvollerweise mit disallow?
Sachen, die über Suchmaschinen nicht gefunden werden sollen.
Gehören dazu auch Bibliotheken mit CSS-Dateien oder php-Unterroutinen oder Ordner mit Bildern, die in den Seiten angeeigt werden?
Wenn sie als Resourcen in Dokumenten verwendet werden, die gefunden werden sollen, halte ich es nicht für sinnvoll einer Suchmaschine den Zugriff zu verbieten. Diese Daten enthalten ja Informationen, die die Suchergebnisse besser machen können.
Ich bin mir auch nicht sicher, ob die Bots sich überhaupt daran halten würden. Denn das SEO mit verstecktem Inhalt ist ja durchaus eine Weile in Mode gewesen.
LG,
CK
hallo
Wenn sie als Resourcen in Dokumenten verwendet werden, die gefunden werden sollen, halte ich es nicht für sinnvoll einer Suchmaschine den Zugriff zu verbieten. Diese Daten enthalten ja Informationen, die die Suchergebnisse besser machen können.
Du verbietest nicht den Zugriff mit disallow. Du schlägst lediglich vor, diese Ressourcen nicht als separate Ressourcen zu indexieren.
Hallo beatovich,
Du verbietest nicht den Zugriff mit disallow. Du schlägst lediglich vor, diese Ressourcen nicht als separate Ressourcen zu indexieren.
Das ist eine Frage der Betrachtungsweise. Man könnte auch sagen: ich verbiete ich den Zugriff (hence the name „disallow“), aber ich erzwinge das Verbot nicht.
LG,
CK
hallo
Hallo beatovich,
Du verbietest nicht den Zugriff mit disallow. Du schlägst lediglich vor, diese Ressourcen nicht als separate Ressourcen zu indexieren.
Das ist eine Frage der Betrachtungsweise. Man könnte auch sagen: ich verbiete ich den Zugriff (hence the name „disallow“), aber ich erzwinge das Verbot nicht.
Worauf genau bezieht sich das disallow?
Das ist robots.txt, eine Steuerdatei mit Fokus Indexierung. Das ist nicht htaccess.
Hallo beatovich,
Das ist robots.txt, eine Steuerdatei mit Fokus Indexierung. Das ist nicht htaccess.
Hast du gelesen, was ich geschrieben habe? 😉
LG,
CK
hallo
was sperrt man sinnvollerweise mit disallow? Gehören dazu auch Bibliotheken mit CSS-Dateien oder php-Unterroutinen oder Ordner mit Bildern, die in den Seiten angeeigt werden?
disallow ist keine Sperre, sondern allenfalls eine Empfehlung, Inhalte nicht in einen öffentlichen Index aufzunehmen.
Hallo beatovich,
disallow ist keine Sperre, sondern allenfalls eine Empfehlung,
wobei sich seriöse Bots wohl daran halten.
Bis demnächst
Matthias
hallo
disallow ist keine Sperre, sondern allenfalls eine Empfehlung,
wobei sich seriöse Bots wohl daran halten.
Was sind seriöse Bots? Und woran genau sollen sie sich halten?
Tromsö: 11 Grad Plus
Hallo,
Tromsö: 11 Grad Plus
Hamburg: 11 Grad plus 23
Gruß
Kalk
Hallo, was sperrt man sinnvollerweise mit disallow?
Es handelt sich entgegen der Formulierung "disallow" nicht um ein echtes "Verbot" sondern eher um den zarten Hinweis an einen Robot, dass er bestimmte Ressourcen nicht abholen möge. Ein Robot soll sich daran halten. Tut er es nicht, dann ist ein richtiges Verbot, im Eskalationsfall das Blockieren jeglichen Netzverkehrs via Firewall die nächste Stufe.
Gehören dazu auch Bibliotheken mit CSS-Dateien oder php-Unterroutinen oder Ordner mit Bildern, die in den Seiten angeeigt werden?
Wenn Du nicht willst, dass Deine Grafiken z.B. in der Google-Bildersuche auftauchen - schreib sie rein. Dafür kann es gute Gründe geben.
CSS-Dateien wird kein Robot abrufen, der nicht die eigentliche Seite indexieren und dazu aufbereiten will. Es erscheint mir nicht sinnvoll, diese aufzunehmen. Das schließt nicht aus, dass es sinnvoll sein kann.
php-Unterroutinen sind eigentlich nirgends verlinkt. Es ist wohl sinnvoller, für diese Ordner (wie auch solche mit Grafiken, CSS-Dateien, das Generieren einer Index-Seite durch den Webserver zu unterbinden. Notfalls eine leere index.html anlegen.
Wenn es keinen sinnvollen Grund für den Zugriff unterhalb von /lib/
gibt, dann sperre besser den HTTP-Zugriff auf den Ordner. In vielen Fällen verraten die Namen existierender Ordner, dass bestimmte CMS verwendet werden. Achte darauf, dass solche Sperren wie ein 404er ('File not found') "aussehen" und auch dieser Header (statt 403 Forbidden) gesendet wird. Angreifer testen Websites durch solche Testzugriffe nämlich auf ausnutzbare Sicherheitsprobleme. Erzeugst Du die Vermutung, dass z.B. kein Wordpress da ist, dann startet er den Angriff auf Wordpress nicht.
Demnach wäre es natürlich kontraproduktiv /wp-admin/
in die robots.txt aufzunehmen. Der letzte Absatz beschreibt, wann es doch sinnvoll sein kann.
Du solltest auch bedenken, dass ein böswillig Handelnder die robots.txt auch (automatisiert) auslesen und sich die verbotenen Inhalte automatisiert abholen kann.
Verbiete also z.B. nicht den Zugriff auf die /kontakt.php
sondern auf /kont*
- das musst Du dann freilich im Auge behalten, weil sonst vielleicht auch /kontinuierlichesSEO.php
nicht indiziert wird.
Lustig und nicht sinnfrei aber sehr optional (macht Mühe und erfordert viel Sorgfalt) ist es übrigens, in der robots.txt den Zugriff auf gar nicht existierende bzw. benötigte Ressourcen zu verbieten und bei einem Zugriffsversuch (der ja eigentlich nur nach dem Lesen und Auswerten der robots.txt, also böswillig, stattfinden kann) die betreffende IP automatisch zu blocken. So was nennt man "Honigtopf".
- Verbiete also z.B. nicht den Zugriff auf die
/kontakt.php
sondern auf/kont*
Das Sternchen ist a) eine Google-eigene Erweiterung (vielleicht akzeptieren es mittlerweile auch andere, sollte aber IMHO trotzdem vermieden werden) und b) am Ende des Musters sowieso sinnlos, weil die Einträge in der robots.txt immer mit dem Anfang des betreffenden Pfades verglichen werden; der Eintrag /kont bedeutet "ein Pfad, der mit /kont beginnt".
Der Vergleich erfolgt zudem rein zeichenbasiert, Pfade werden nicht beachtet; /kont passt auf /kontakt genauso wie auf /kont/tra oder /kont.ur.
Und bei der Gelegenheit ein Punkt, den ebenfalls viele Leute an der robots.txt nicht verstanden haben: Sie wird eigentlich von oben nach unten abgearbeitet, der erste passende Eintrag bestimmt das weitere vorgehen. Wird "Disallow: /bla" von "Allow: bla/fasel" gefolgt, ist entsprechend letzteres wirkungslos, weil ein Pfad /bla/faseldidumm schon bei /bla passt.
Google ignoriert allerdings auch hier die ursprüngliche robots.txt-Definition und arbeitet IIRC erst die Allow-Zeilen ab, dann die Disallow-Zeilen.
Das Sternchen ist a) eine Google-eigene Erweiterung
hi,
sinnvoll ist es z.B., Seiten die ein Passwort erfordern da einzutragen.
MfG
sinnvoll ist es z.B., Seiten die ein Passwort erfordern da einzutragen.
Warum denn das?
sinnvoll ist es z.B., Seiten die ein Passwort erfordern da einzutragen.
Warum denn das?
Weil die ohne Passwort keinen Inhalt rausrücken der indexiert werden könnte.
robots.txt also:
- Seiten die nicht indexiert werden sollen
und
- Seiten die nicht indexiert werden können.
MfG
sinnvoll ist es z.B., Seiten die ein Passwort erfordern da einzutragen. Warum denn das? Weil die ohne Passwort keinen Inhalt rausrücken der indexiert werden könnte.
Verstehe ich nicht. Siehe unten.
robots.txt also: - Seiten die nicht indexiert werden sollen
Ja. Passt.
und - Seiten die nicht indexiert werden können.
Ist mir zu hoch. Warum sollte man Ressourcen, an die der Bot eh eh nicht rankommt, per robots.txt "verbieten" wollen? Klar, kann man machen. Aber wo liegt da der Sinn? Kannst natürlich auch sämtliche, nicht existierende Ressourcen in die robots.txt schreiben. LOL
Kannst natürlich auch sämtliche, nicht existierende Ressourcen in die robots.txt schreiben. LOL
Apropos:
http://rolfrost.de/gibt_es_noch_nicht
antwortet mit HTTP Status 410. Du willst aber mit 404 antworten.
Apropos, das ist noch was anderes kaputt:
hallo
Kannst natürlich auch sämtliche, nicht existierende Ressourcen in die robots.txt schreiben. LOL
Apropos:
http://rolfrost.de/gibt_es_noch_nicht
antwortet mit HTTP Status 410. Du willst aber mit 404 antworten.
Der wesentliche Unterschied ist, dass 410 sagt: die Seite existiert nicht, während 404 lediglich sagt, sie wurde nicht gefunden.
410 ist also die bessere Antwort wenn es darum geht, Referenzen auf diese URL aufzulösen.
Der wesentliche Unterschied ist, dass 410 sagt: die Seite existiert nicht, während 404 lediglich sagt, sie wurde nicht gefunden.
Besser und ausführlicher formuliert bei MDN. Der Caching-Hinweis ist auch wichtig.
hallo
Der wesentliche Unterschied ist, dass 410 sagt: die Seite existiert nicht, während 404 lediglich sagt, sie wurde nicht gefunden.
Auch in der Searchkonsole gibt es Unterschiede: Seiten die einen 410 verursachen, sind da nicht aufgelistet. D.h. daß sie aus dem Index raus sind.
MfG
Ist mir zu hoch. Warum sollte man Ressourcen, an die der Bot eh eh nicht rankommt,
Weil ja schon Deine Annahme falsch ist.
Ist mir zu hoch. Warum sollte man Ressourcen, an die der Bot eh eh nicht rankommt, Weil ja schon Deine Annahme falsch ist.
Meine Annahme basiert auf Deiner Aussage: "Seiten die nicht indexiert werden können, weil sie passwortgeschützt sind". Wenn also meine Annahme falsch ist, dann ist Deine Aussage ebenfalls falsch.
Ist mir zu hoch. Warum sollte man Ressourcen, an die der Bot eh eh nicht rankommt, Weil ja schon Deine Annahme falsch ist.
Meine Annahme basiert auf Deiner Aussage: "Seiten die nicht indexiert werden können, weil sie passwortgeschützt sind". Wenn also meine Annahme falsch ist, dann ist Deine Aussage ebenfalls falsch.
Du verstehst das eben nicht was ein Bot macht: Er folgt jedem URL, es sei denn, die Datei robots.txt verbietet es. Wenn Dir das zu hoch ist, an mir liegts nicht.
MfG
Hallo pl,
ein Bot macht: Er folgt jedem URL, es sei denn, die Datei robots.txt verbietet es.
… und der Bot respektiert dieses Verbot.
Bis demnächst
Matthias
hi
ein Bot macht: Er folgt jedem URL, es sei denn, die Datei robots.txt verbietet es.
… und der Bot respektiert dieses Verbot.
Wenn ein Bot den Status 401 bekommt wird er sich fragen, was das fürn Depp ist der ihm nicht gleich per robots.txt mitgeteilt hat, daß er den für ihn untauglichen Versuch der Indizierung gar nicht erst unternehmen soll.
Es ist also mitnichten von einem Verbot die Rede sondern von einem Entgegenkommen!
MfG
Hallo pl,
ein Bot macht: Er folgt jedem URL, es sei denn, die Datei robots.txt verbietet es.
… und der Bot respektiert dieses Verbot.
Es ist also mitnichten von einem Verbot die Rede sondern von einem Entgegenkommen!
die Formulierung "verbietet" war von dir 😉
Bis demnächst
Matthias
hi
ein Bot macht: Er folgt jedem URL, es sei denn, die Datei robots.txt verbietet es.
… und der Bot respektiert dieses Verbot.
Es ist also mitnichten von einem Verbot die Rede sondern von einem Entgegenkommen!
die Formulierung "verbietet" war von dir 😉
Ja und!? Der Begriff ist ja nicht falsch!
MfG
Ist mir zu hoch. Warum sollte man Ressourcen, an die der Bot eh eh nicht rankommt, Weil ja schon Deine Annahme falsch ist.
Meine Annahme basiert auf Deiner Aussage: "Seiten die nicht indexiert werden können, weil sie passwortgeschützt sind"". Wenn also meine Annahme falsch ist, dann ist Deine Aussage ebenfalls falsch.
Du verstehst das eben nicht was ein Bot macht: Er folgt jedem URL, es sei denn, die Datei robots.txt verbietet es. Wenn Dir das zu hoch ist, an mir liegts nicht.
Wie soll ein Bot eine Ressource aufrufen, deren Credentials er nicht kennt? Warum sollte man Ressourcen, die ein Bot nicht aufrufen kann , per robots.txt "verbieten"? Magst Du diese beiden Frage beantworten? Das wäre sehr lieb von Dir.
Ist mir zu hoch. Warum sollte man Ressourcen, an die der Bot eh eh nicht rankommt, Weil ja schon Deine Annahme falsch ist.
Meine Annahme basiert auf Deiner Aussage: "Seiten die nicht indexiert werden können, weil sie passwortgeschützt sind"". Wenn also meine Annahme falsch ist, dann ist Deine Aussage ebenfalls falsch.
Du verstehst das eben nicht was ein Bot macht: Er folgt jedem URL, es sei denn, die Datei robots.txt verbietet es. Wenn Dir das zu hoch ist, an mir liegts nicht.
Wie soll ein Bot eine Ressource aufrufen, deren Credentials er nicht kennt?
Weil das ein Bot macht: Er folgt dem Link.
Warum sollte man Ressourcen, die ein Bot nicht aufrufen kann ,
Genau das ist Deine Annahme die falsch ist: Selbstverständlich kann ein Bot auch passwortgeschützte Ressourcen aufrufen und er kann es nicht nur, er macht es auch! Jedoch kann er den Inhalt nicht indizieren, weil er ohne Credentials das nicht kann.
Ein Bot folgt also jedem Link, es sei denn die Datei robots.txt sieht das nicht vor, also auch Links zu Inhalten die er gar nicht indizieren kann weil sie ein Passwort brauchen. Letzteres kann er aber erst feststellen, wenn er die Seite aufgerufen hat. Im Übrigen stellt das ein Bot anhand des HTTP Status fest, allein der Status 401 heißt für den Bot, daß die Seite nicht indizierbar ist.
Die Credentials interessieren den Bot also gar nicht.
MfG
Ein Bot folgt also jedem Link, es sei denn die Datei robots.txt sieht das nicht vor, also auch Links zu Inhalten die er gar nicht indizieren kann weil sie ein Passwort brauchen. Letzteres kann er aber erst feststellen, wenn er die Seite aufgerufen hat. Im Übrigen stellt das ein Bot anhand des HTTP Status fest, allein der Status 401 heißt für den Bot, daß die Seite nicht indizierbar ist.
Warum sollte man dem Bot für Ressourcen die Indizierung via robots.txt untersagen, wenn die Antwort HTTP 401 lautet? Der Sinn hinter Deiner dahingehenden Empfehlung erschließt sich mir nicht.
Hallo Mitleser,
Warum sollte man dem Bot für Ressourcen die Indizierung via robots.txt untersagen, wenn die Antwort HTTP 401 lautet? Der Sinn hinter Deiner dahingehenden Empfehlung erschließt sich mir nicht.
Es geht wohl hauptsächlich darum, dass er gar nicht erst fragt. Macht ja auch Sinn, spart Traffic und verkürzt das Log.
LG,
CK
Warum sollte man dem Bot für Ressourcen die Indizierung via robots.txt untersagen, wenn die Antwort HTTP 401 lautet? Der Sinn hinter Deiner dahingehenden Empfehlung erschließt sich mir nicht.
Es geht wohl hauptsächlich darum, dass er gar nicht erst fragt. Macht ja auch Sinn, spart Traffic und verkürzt das Log.
Das sind zwei Argumente, ok. Kann man machen. Mit der pauschalen Empfehlung, das so zu machen, tue ich mich dennoch schwer. Das sind IMHO vernachlässigbarere Vorteile, erkauft zu dem Preis, sich mit einer eventuell defekten oder zwischenzeitlich überholten Robots-Direktive selbst ins Knie zu schießen.
Warum sollte man dem Bot für Ressourcen die Indizierung via robots.txt untersagen, wenn die Antwort HTTP 401 lautet? Der Sinn hinter Deiner dahingehenden Empfehlung erschließt sich mir nicht.
Es geht wohl hauptsächlich darum, dass er gar nicht erst fragt. Macht ja auch Sinn, spart Traffic und verkürzt das Log.
Das sind zwei Argumente, ok. Kann man machen. Mit der pauschalen Empfehlung, das so zu machen, tue ich mich dennoch schwer. Das sind IMHO vernachlässigbarere Vorteile, erkauft zu dem Preis, sich mit einer eventuell defekten oder zwischenzeitlich überholten Robots-Direktive selbst ins Knie zu schießen.
Idealerweise wird die robots.txt auch nicht von Hand bearbeitet sondern bei Abruf dynamisch erstellt anhand der aktuellen Konfiguration für die gesamte Site (Projektverwaltung). So wird ja in der Konfiguration festgelegt ob für den Abruf einer Seite Credentials erforderlich sind und nicht in der robots.txt
MfG
hallo
Idealerweise wird die robots.txt auch nicht von Hand bearbeitet sondern bei Abruf dynamisch erstellt anhand der aktuellen Konfiguration für die gesamte Site (Projektverwaltung). So wird ja in der Konfiguration festgelegt ob für den Abruf einer Seite Credentials erforderlich sind und nicht in der robots.txt
Idealer Weise sollte sich der robots.txt nicht alle paar Minuten ändern.
KISS
hallo
Idealerweise wird die robots.txt auch nicht von Hand bearbeitet sondern bei Abruf dynamisch erstellt anhand der aktuellen Konfiguration für die gesamte Site (Projektverwaltung). So wird ja in der Konfiguration festgelegt ob für den Abruf einer Seite Credentials erforderlich sind und nicht in der robots.txt
Idealer Weise sollte sich der robots.txt nicht alle paar Minuten ändern.
Befasse Dich mal mit SEO. Stichwort: Last-Modified.
MfG
Idealerweise wird die robots.txt auch nicht von Hand bearbeitet sondern bei Abruf dynamisch erstellt anhand der aktuellen Konfiguration für die gesamte Site (Projektverwaltung). So wird ja in der Konfiguration festgelegt ob für den Abruf einer Seite Credentials erforderlich sind und nicht in der robots.txt
Ganz schön viel Aufwand für m.E. sehr geringen Erlös. Außerdem zwingt man die URL-Struktur dann in ein bestimmtes Schema, damit man bei z.B. mehreren tauschend geschützten Ressourcen nicht eine sehr fette robots.txt erzeugen / ausliefern muss.
Idealerweise wird die robots.txt auch nicht von Hand bearbeitet sondern bei Abruf dynamisch erstellt anhand der aktuellen Konfiguration für die gesamte Site (Projektverwaltung). So wird ja in der Konfiguration festgelegt ob für den Abruf einer Seite Credentials erforderlich sind und nicht in der robots.txt
Ganz schön viel Aufwand für m.E. sehr geringen Erlös.
Das hat mit Aufwand nichts zu tun sondern mit Zweckmäßigkeit und Informationsfluß. Eine robots.txt ist zwar auch eine Konfigurationsdatei aber letztendlich auch das Resultat einer zentralen Konfiguration. Gerade wir von der IT sind ja dazu da, Prozesse und Abläufe so zu organisieren, daß eine Konfiguration möglichst zentral erfolgt um Inkonsistenzen zu vermeiden.
Und wenn eine robots.txt dynamisch erzeugt wird, heißt das noch lange nicht, daß sie sich alle paar Minuten ändert muss.
Der Gesamtaufwand schließlich, ergibt sich aus den Zielen die ein Projekt verfolgt. Sowas wird dokumentiert einschließlich einer Policy für die Zugänglichkeit. Ohne Projektverwaltung ist keine Revision möglich, keine Fehlerbehandlung, keine Wartung und auch keine Kontrolle ob die Ziele überhaupt erreicht wurde.
Wat mutt dat mutt.
Hallo Mitleser,
Das sind IMHO vernachlässigbarere Vorteile, erkauft zu dem Preis, sich mit einer eventuell defekten oder zwischenzeitlich überholten Robots-Direktive selbst ins Knie zu schießen.
Guter Einwand. Ja, da hast du wohl recht.
LG,
CK
Hi, ich habe aus den Beiträgen gelernt, dass ich gar kein disallow verwende. Der Aufwand, den Regina Schaukrug beschrieb, ist mir zu hoch, und den böswilligen bots möchte ich nicht auch noch Tipps geben, wie sie gezielt suchen könnten.
hallo
ich habe aus den Beiträgen gelernt, dass ich gar kein disallow verwende. Der Aufwand, den Regina Schaukrug beschrieb, ist mir zu hoch, und den böswilligen bots möchte ich nicht auch noch Tipps geben, wie sie gezielt suchen könnten.
Solange du KISS-konform keine konkreten Ressourcen sondern nur Ordner angibst, sehe ich da eigentlich kein Problem.
Hi,
ich habe aus den Beiträgen gelernt, dass ich gar kein disallow verwende. Der Aufwand, den Regina Schaukrug beschrieb, ist mir zu hoch, und den böswilligen bots möchte ich nicht auch noch Tipps geben, wie sie gezielt suchen könnten.
Die besseren Tipps kriegst Du von Google. Suche den Dialog mit denen und dann lernst Du auch den richtigen Umgang mit der robots.txt Datei.
MfG
Google ist bestimmt nicht der richtige Ansprechpartner, da wohl vor allem Eigeninteressen.
hallo
Die besseren Tipps kriegst Du von Google. Suche den Dialog mit denen und dann lernst Du auch den richtigen Umgang mit der robots.txt Datei.
Der relevante Tipp von Google lautet, dass Google den robots.txt nicht berücksichtigen wird, wenn die Ressource von einer 3rd-party genannt wird.
ich habe aus den Beiträgen gelernt, dass ich gar kein disallow verwende. den böswilligen bots möchte ich nicht auch noch Tipps geben, wie sie gezielt suchen könnten.
Meines Erachtens interessieren sich Bots eher nicht so für die robots.txt, das machen echte Menschen. In der robots.txt finden sich sehr individuelle Informationen, die für einen Bot, also einer Millionen von Webseiten verarbeitenden Software, kaum Nutzen haben, eben weil sie nicht allgemeingültig sind und somit kaum für die automatisierte Verarbeitung taugen.
Man möge sich mal selbst überlegen: Was soll ich als Bot mit der Information "Disallow: /badewanne" anfangen? Hui, da versteckt einer seine Badewanne? Welchen Wert hat diese Information? Sie sagt doch noch absolut nichts darüber aus, ob da eine veraltete Blog-Software hintersteckt oder E-Mail-Adressen, die man verkaufen könnte. Sich auf sowas zu verlassen ist doch nicht einmal die Nadel im Heuhaufen. Das machen bestenfalls Anfänger, Skript-Kiddies, nicht die tatsächlich gefährlichen Leute, diejenigen, die Geld verdienen wollen, für die Arbeitszeit aber Kosten sind, entgangener Verdienst, die mit entsprechendem willen und vor allem Ausdauer an die Sache rangehen.
Also: Bots suchen in aller Regel nach Sicherheitslücken bekannter Software oder aber nach Möglichkeiten, irgendwen mit Spam zuzumüllen. Das sind die Bereiche, die sich zu Geld machen lassen.
Diese Suche unternejmen sie aber, gerade bei Sicherheitslücken, entweder gezielt, denn warum in der robots.txt nach "Disallow: /wp-admin/" suchen, wenn man das Verzeichnis genauso gut direkt abrufen kann? Das Ergebnis ist dasselbe, gefunden oder nicht gefunden, aber der Direktabruf spart 50% der Arbeitslast.
Alternativ lassen sie die Sucherei auch ganz sein, denn warum den Aufwand einer eigenen Suche betreiben, wenn man viel einfacher Google & Co. nach Seiten mit typischen Mustern von Kontakt- und Forenseiten fragen kann? Erst diese quasi vorgefilterte Ergebnisliste wird dann selbst abgeklappert.
Ich habe seit mittlerweile weit über zehn Jahren meine Kontaktseiten mit klaren E-Mail-Adressen in der robots.txt mit Disallow eingetragen, darunter auch Honigtopf-Adressen. Die Kontaktseiten tauchen bei Google nicht auf und siehe da: An diese Honigtöpfe ist in all den Jahren noch keine einzige Spammail gegangen. An die anderswo über Project Honeypot ausgelegten hingegen regelmäßig.
ich habe aus den Beiträgen gelernt, dass ich gar kein disallow verwende. den böswilligen bots möchte ich nicht auch noch Tipps geben, wie sie gezielt suchen könnten.
Meines Erachtens interessieren sich Bots eher nicht so für die robots.txt, das machen echte Menschen.
Dein Erachten in allen Ehren aber es ist falsch. Ich habe an einer anderen Stelle nicht umsonst empfohlen, den Dialog mit Google zu suchen, das wäre auch mal was für Dich!
In den Webmastertools erfährst Du nämlich sehr viel über die Arbeitsweise einer Suchmaschine und selbstverständlich auch Einiges darüber wie eine Suchmaschine mit der robots.txt umgeht und wie sich das auf die Indizierung auswirkt.
Eine ordentlich konfigurierte robots.txt gehört ganz einfach zur Qualitätssicherung eines ordentlichen Webprojekts.
MfG
den böswilligen bots möchte ich nicht auch noch Tipps geben, wie sie gezielt suchen könnten.
Meines Erachtens interessieren sich Bots eher nicht so für die robots.txt, das machen echte Menschen.
Dein Erachten in allen Ehren aber es ist falsch. Ich habe an einer anderen Stelle nicht umsonst empfohlen, den Dialog mit Google zu suchen
Seit wann ist Google ein "böswilliger Bot"? Und seit wann informiert Google über die Verhaltensweisen böswilliger Bots?
Es ist ja schön, dass du sinngemäß zitierst, aber dann folge doch auch dem Sinn des Zitats. Um Googlebot & Co. geht es mir überhaupt nicht, die lassen sich wunderbar über die robots.txt steuern.
Davon mal abgesehen ist der "Dialog mit Google" einen Scheissdreck wert, sowas existiert schlichtweg nicht. Es gibt eine Reihe Anleitungen, aber ein Dialog findet da nicht statt. Zu einem Dialog gehören mindestens zwei aktive Teilnehmer - und nicht einer, der fragt, und einer, der nur Textbausteine zurückschickt.
Eine ordentlich konfigurierte robots.txt gehört ganz einfach zur Qualitätssicherung eines ordentlichen Webprojekts.
Ich habe nichts Gegenteiliges behauptet.
den böswilligen bots möchte ich nicht auch noch Tipps geben, wie sie gezielt suchen könnten.
Meines Erachtens interessieren sich Bots eher nicht so für die robots.txt, das machen echte Menschen.
Dein Erachten in allen Ehren aber es ist falsch. Ich habe an einer anderen Stelle nicht umsonst empfohlen, den Dialog mit Google zu suchen
Seit wann ist Google ein "böswilliger Bot"?
Ich würde ja sagen, PL hat sich erkennbar gar nicht auf böswillige Bots bezogen.
den böswilligen bots möchte ich nicht auch noch Tipps geben, wie sie gezielt suchen könnten.
Meines Erachtens interessieren sich Bots eher nicht so für die robots.txt, das machen echte Menschen.
Dein Erachten in allen Ehren aber es ist falsch. Ich habe an einer anderen Stelle nicht umsonst empfohlen, den Dialog mit Google zu suchen
Seit wann ist Google ein "böswilliger Bot"?
Ich würde ja sagen, PL hat sich erkennbar gar nicht auf böswillige Bots bezogen.
Hab ich auch nicht. Vielmehr hab ich mich auf das bezogen was schriftlich veräußert wurde. Aber wenn hier schon wieder versucht wird mir mit Seit wann ist Google ein "böswilliger Bot"?
die Worte im Mund herum zu drehen, macht eine weitere Diskussion sowieso keinen Sinn.
.
Meines Erachtens interessieren sich Bots eher nicht so für die robots.txt,
Dein "Erachten" lässt sich durch einen schnellen Einzeiler be- oder widerlegen:
`grep robots.txt code.fastix.org_access.log | grep '10/Aug/2018' | cut -d ' ' -f 12,13,14,15,16,17 | sort -u`
Hier also die sortierte Liste der Agenten, welche gestern code.fastix.org nach der robots.txt gefragt haben:
"Mozilla/5.0 (compatible; AhrefsBot/5.2; +http://ahrefs.com/robot/)"
"Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)"
"Mozilla/5.0 (compatible; BLEXBot/1.0; +http://webmeup-crawler.com/)"
"Mozilla/5.0 (compatible; DotBot/1.1; http://www.opensiteexplorer.org/dotbot, help@moz.com)"
"Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
"Mozilla/5.0 (compatible; MJ12bot/v1.4.8; http://mj12bot.com/)"
"Mozilla/5.0 (compatible; SemrushBot/2~bl; +http://www.semrush.com/bot.html)"
"Mozilla/5.0 (compatible; tracemyfile/1.0; +bot@tracemyfile.com)"
"Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)"
"panscient.com"
das machen echte Menschen.
Natürlich. Aber weil diese echten Menschen nicht diese langweiligen Textdateien lesen und parsen wollen, programmieren die "bots". Übrigen auch die böswilligen oder Spammer.
In der Liste findet sich z.B.
"panscient.com"
Auf deren Webseite finde ich (Ich war dabei sehr vorsichtig, denn auch die Angaben zum referrer und die URLs in den Angaben der Agenten können höchst böswillig sein!), was die verkaufen:
A collection of over 8.6 million US business names and contact information. Each record includes the website URL, the business name, business description, keywords, and at least a US address or US phone. Fax and email address are also provided where available.
warum in der robots.txt nach "Disallow: /wp-admin/" suchen, wenn man das Verzeichnis genauso gut direkt abrufen kann?
Böswillige Programmierer halten sich für raffiniert. Deren "Schriebs" holt also die robots.txt und schaut mal nach, was alles verboten ist.
Denn was lernen kleine Jungs und junge Hunde als Erstes?
Das beantwortet folgende Deiner Fragen:
Was soll ich als Bot mit der Information "Disallow: /badewanne" anfangen? Hui, da versteckt einer seine Badewanne? Welchen Wert hat diese Information?
Die Sache ist also klar: In der robots.txt genannte Ressourcen sind "Pfui", ergo "interessant".
Diese Suche unternejmen sie aber, gerade bei Sicherheitslücken, entweder gezielt, denn warum in der robots.txt nach "Disallow: /wp-admin/" suchen, wenn man das Verzeichnis genauso gut direkt abrufen kann? Das Ergebnis ist dasselbe, gefunden oder nicht gefunden, aber der Direktabruf spart 50% der Arbeitslast.
Das stimmt nur, wenn er nur auf '/wp-admin/' untersuchen will. Aber, was wenn sein Skript mehrere Lücken in einem dutzend CMS oder gar hunderten anderen Webanwendungen (angefangen vom Klassiker ("Matts Gästebuch"...) sucht? Dann kann er so, womöglich einige Requests sparen, wenn er mit einem Abruf die robots.txt abholt und dann befragt, ob sich darin Trigger-Einträge befinden, die auf ein bestimmtes CMS oder Skript hinweisen. Das spart dann verräterische Zugriffe. Es ist also nicht ganz dumm, sowas zu tun.
Das machen bestenfalls Anfänger, Skript-Kiddies, nicht die tatsächlich gefährlichen Leute,
Diese Aussage ist also einfach mal falsch.
Freilich muss es ein solcher Bot hinnehmen von so manch schnellem Typen dann eben daran erkannt zu werden.