robots.txt

[ErichM]

Mit der Installation von Contao 4.4.1 wird keine robots.txt mitgeliefert. Wird diese für Contao nicht mehr benötigt, oder kann/soll die bisherige weiter verwendet werden? Wer weiß hier Bescheid.

[Spooky]

Du kannst ohne weiteres eine eigene robots.txt im web/ Ordner benutzen.

[ErichM]

Du kannst ohne weiteres eine eigene robots.txt im web/ Ordner benutzen.

Danke für die schnelle Anwort. Ich gehe also davon aus, dass Contao keine speziellen Einträge in der robots.txt mehr benötigt.

[tab]

Ich denke, es hat eine robots.txt ungefähr genauso nötig wie Contao 3.5.

[Spooky]

Das ist der Inhalt der robots.txt von Contao 3.5.:

User-agent: *
Disallow: /check/
Disallow: /contao/
Disallow: /system/
Disallow: /templates/
Disallow: /vendor/
Disallow: /share/index.php
Disallow: /build.xml
Disallow: /composer.json
Disallow: /composer.lock
Disallow: /README.md
Allow: /system/cron/cron.txt
Allow: /system/modules/*/assets/
Allow: /system/modules/*/html/

Manche rules davon könnte man für Contao 4 übernehmen bzw. noch gebrauchen. Andere sind nicht mehr notwendig, da die jeweiligen Pfade von außen nicht (mehr) erreichbar sind.

[mandrake]

Und was sollen Ratsuchende wie Erich - und sicherlich auch diverse andere Anwender - nun genau mit Euren Kommentaren anfangen?

Die Frage, die sich mir in diesem Kontext zudem aufdrängt lautet: Warum liefert Contao 4 überhaupt keine robots.txt mehr in - von Contao 3 gewohnter Weise - mehr mit aus?

[lucina]

Weil ...

a) eine bisher mitgelieferte robots.txt nur ein Startpunkt für eigene Konfigurationen sein kann
b) alle bisher durch die robots.txt pseudo-geschützen Dateien ohnehin nicht mehr zugänglich sind
c) man nichts erlauben muss wenn man nichts verbietet

[mandrake]

a) eine bisher mitgelieferte robots.txt nur ein Startpunkt für eigene Konfigurationen sein kann

Ist dem normalen Anwender sicherlich so schnurz, wie bisher auch.

b) alle bisher durch die robots.txt pseudo-geschützen Dateien ohnehin nicht mehr zugänglich sind

Hilft dem normalen Anwender vielleicht tatsächlich etwas weiter - wenn er denn im Thema ist.

c) man nichts erlauben muss wenn man nichts verbietet

Eine klare Aussage, die den normalen Anwender hoffentlich zum nachdenken anregen wird.

[BugBuster]

Kurz, die ist einfach unnötig :-)
Wenn jemand manuell dran geschraubt hat zu Contao 3 Zeiten, z.B. um dort den Pfad zu einer sitemap Datei anzugeben, das könnte man natürlich dann übernehmen.
Oder um bestimmte Bots zu bitten von der Durchsuchung abzulassen.
Aber dann hatte man ja eh Ahnung was man da tut und weiß dann auch Bescheid ob das in Contao 4 noch nötig ist.

[lucina]

Oder um bestimmte Bots zu bitten von der Durchsuchung abzulassen.

You made my day.

[tab]

Ich würde mal so sagen: Wenn ein Bot bei einer 3.5 versucht, auf /system zuzugreifen abgesehen von den explizit erlaubten Unterverzeichnissen mit Ressourcen, die der Bot brauchen könnte um die Website komplett zu erfassen, dann frage ich mich, wieso er das eigentlich will. Es ist ja im HTML nichts verlinkt dahin, wozu versucht er es also überhaupt?
Da sehe ich eigentlich nur zwei Möglichkeiten:

1. Irgendjemand hat aus Unwisseneit oder Böswilligkeit einen entsprechenden Link dahin auf irgendeiner Website gesetzt, dem der Bot gefolgt ist.
2. Der Bot will rumschnüffeln in Verzeichnissen und Dateien, die er zum Verstehen der Website nicht braucht. Also sozusagen ein Spion, der alles runterlädt, was ihm zwischen die Finger kommt.

In beiden Fällen konnte der Bot ohnehin nur runterladen, was nicht durch eine .htaccess geschützt war. Und das waren doch im Wesentlichen sinngemäß die selben Dateien und Verzeichnisse wie bei Contao 4, hier funktioniert nur der Schutz anders. Er funktioniert aber nicht besser oder schlechter als bei Contao 3, nur anders. Besser allenfalls für nginx Webserver, weil bei Contao 4 der Schutz für Apache und nginx gleich funktioniert und man nicht mehr aktiv notwendige Schutzmaßnahmen selbst "nachrüsten" muss. Und im Fall des Spions hilft die robots.txt sowieso nicht, weil er sie ja einfach ignorieren kann und wird.

Und wenn man einfach den Inhalt bestimmter öffentlich zugänglicher Seiten nicht im Google-Index finden will, dann unterscheidet sich auch in dieser Hinsicht Contao 3 nicht von Contao 4.

[Spooky]

Es ist ja im HTML nichts verlinkt dahin, wozu versucht er es also überhaupt?

Doch, Extensions können ja eigene Assets und Einstiegspunkte mitbringen. Daher auch die Ausnahme in der default robots.txt von Contao 3:

Allow: /system/modules/*/assets/
Allow: /system/modules/*/html/

[tab]

Genau, hab ich doch geschrieben

abgesehen von den explizit erlaubten Unterverzeichnissen mit Ressourcen, die der Bot brauchen könnte um die Website komplett zu erfassen

Edit: Eine system/config/localconfig.php ist ja z.B. nirgends im HTML verlinkt, eben nur die assets.

[ihkwdiopk]

Als ob es einen Bot interessiert, was in der robots.txt steht. Im Gegenteil, genau dort findet er wichtige Infos zum System; also warum diese öffentlich machen?
Diverse Vul-Scanner suchen genau danach um ihre Infos zu bekommen und dort anzusetzen.

Was soll auch sinnvolles bis auf einen Verweis zur Sitemap drin stehen?

[Samson1964]

Die guten Bots halten sich an die Anweisungen in der robots.txt, weil sonst viel zu viel Unsinn im Index landet. Die bösen Bots interessiert die robots.txt nicht. Die greifen sich eh alles, was nicht geschützt ist.

Gesendet von meinem L52 mit Tapatalk

[BugBuster]

Und dann gibt es die Hacker, die dort einen Disallow reinstellen für eine Datei was nichts mit Contao zu tun hat.
Geht ein Bot dort drauf ist er als böse markiert und wird per IP für einige Zeit/immer gesperrt :-)

[Samuell]

Auf die Idee wär ich nicht mal gekommen.
Danke für diesen Denkanstoß. Ich bin einfach zu "arglos" :-)

[swinde]

Hallo,
der Fred ist zwar schon etwas älter aber ich bin gerade in den Logs über diese Meldung gestolpert.

[2018-07-24 12:40:18] request.INFO: Matched route  "contao_catch_all".  {"route":"contao_catch_all","route_parameters":{"_scope":"frontend","_token_check":true,"_controller":"Contao\\CoreBundle\\Controller\\FrontendController::indexAction","_url_fragment":"robots.txt","_route":"contao_catch_all"},"request_uri":"https://www.domain.de/robots.txt","method":"GET"}  []
[2018-07-24 12:40:18] security.INFO: Attempting SimplePreAuthentication.   {"key":"frontend","authenticator":"Contao\\CoreBundle\\Security\\ContaoAuthenticator"}  []
[2018-07-24 12:40:18] request.ERROR: Uncaught PHP Exception  Symfony\Component\HttpKernel\Exception\NotFoundHttpException: "Page not  found: https://www.domain.de/robots.txt" at  /var/virtual/xxx/public/vendor/contao/core-bundle/src/EventListener/ExceptionConverterListener.php  line 112 {"exception":"[object]  (Symfony\\Component\\HttpKernel\\Exception\\NotFoundHttpException(code:  0): Page not found: https://www.domain.de/robots.txt at  /var/virtual/xxx/public/vendor/contao/core-bundle/src/EventListener/ExceptionConverterListener.php:112,  Contao\\CoreBundle\\Exception\\PageNotFoundException(code: 0): Page not  found: https://www.domain.de/robots.txt at  /var/virtual/xxx/public/vendor/contao/core-bundle/src/Resources/contao/controllers/FrontendIndex.php:64)"}  []

wenn in Contao 4 keine robots.txt mehr vorhanden und notwendig ist, warum prüft Contao dann ob diese vorhanden ist!?

Oder wird diese Meldung durch das Pagespeed-Modul verursacht, welches auf dem Server (Hostingwerk) läuft?

Steffen Winde

[Spooky]

Contao prüft das nicht. Dieser Log Eintrag erscheint immer dann, wenn irgendjemand diese URL aufruft.

[Skipman]

Contao prüft das nicht. Dieser Log Eintrag erscheint immer dann, wenn irgendjemand diese URL aufruft.

Nach meinem bisherigen Verständnis ist die Log-Datei dazu da, Fehler (welche auch immer) aufzuzeigen. Wenn jetzt bei JEDEM Aufruf der Webseite ein Eintrag ins Log erstellt wird, weil keine robots.txt da ist, dann müllt mir diese eine Fehlermeldung das Log so zu, dass mögliche wirkliche Fehler nurmehr schwer auffindbar sind

Jedenfalls: Seit ich eine robots.txt ins \web Verzeichnis gestellt hab, bleibt das Log-File leer, was ich wesentlich besser finde als täglich mehrere hundert oder 10.000e Einträge (ist ja besucherabhängig) pro Tag zu produzieren.

Kann man diese eine Fehlermeldung nicht unterdrücken? Und wenn nein: Wäre unter diesem Gesichtspunkt eine einfache robots.txt nicht sinnvoll?

[Spooky]

Du kannst ja hier dazu ein Ticket aufmachen: https://github.com/contao/contao/issues

Du solltest es aber nicht auf die robots.txt beziehen, denn seit Contao 4.6 gibt es eine default robots.txt

[Sares]

Die Logs werden z.B. auch bei einem fehlenden favicon.ico File gefüllt, das fragen die meisten Browser auch immer automatisch mit ab.
Eventuell würde es ja Sinn machen, hier einzelne Files vom Logging ausschließen zu können. Das könntest Du bei der Gelegenheit ja beim Erstellen des Tickets vielleicht gleich mal mit "anregen"

[Spooky]

Ich würde generell hinterfragen, ob 404 überhaupt geloggt werden müssen. Wenn man das braucht, hat man ja meistens das Access Log des Web Servers. Wozu soll die Web Applikation selbst das also auch noch loggen.

[WorkerBeeEu]

Ich würde generell hinterfragen, ob 404 überhaupt geloggt werden müssen. Wenn man das braucht, hat man ja meistens das Access Log des Web Servers. Wozu soll die Web Applikation selbst das also auch noch loggen.

Ich finde das super. Ich logge z.B. in einigen Projekten spezielle Anfragen (an WordPress, Joomla usw.) um Bots zu erkenne und um de IP's dann mit Fail2Ban für eine gewisse Zeit zu blockieren.

Du darfst auch nicht vergessen, dass du nicht bei allen Hostern Zugriff auf das Access-Log hast UND dass diese Logs teils nur ein paar Tage rotieren. Da reicht es dann nicht alle Woche mal das Logfile zu checken. Insofern ist das schon gut, wenn man ein brauchbares 404-Log im CMS hat.

Btt.: Eine robots.txt versteht sich als guter Ton, den hier werden Infos für die Crawler hinterlegt - darum wird das auch beim PageSpeed usw. mit erwähnt. Leg einfach eine Datei an, schreib rein, welche URL die Sitemap der Seite hat und eventuell fällt dir noch mehr ein btw. bietet es sich hier an die Seite Impressum, Datenschutz, AGB usw. direkt für die großen Suchmaschinen zu verbieten.