Gepatchte robots.txt blockiert immer noch js + CSS-Dateien?

Hallo,

versuch doch mal die folgenden Verzeichnisse auszukommentieren, welche anscheinend blockiert werden:

Probiere es danach nochmal.

MfG

Robert

Hi Robert,
das war mein erster Versuch, bevor ich die gepatchte Version genommen habe.

Hi,
es kann natürlich sein, dass erst der Google Bot vorbeikommen muss
um die robots.txt aufzunehmen und die Seiten neu zu indexieren.
Das kann gut 2 Wochen oder mehr dauern.
Im access.log sollte man sehen können, wann der Bot vorbeigekommen ist (User Agent: Googlebot).

Grüsse

Robert

Ich habe mich an den Angaben in den Webmaster-Tools orientiert.
Wenn da für den 27.06. geblockte Seiten angegeben sind (also nach meinen Änderungen), dann gehe ich davon aus, daß der Robot auch am 27. da war.
Aber evt. ist das ja ein Trugschluss.

JEtzt habe ich mal in der access.log Datei nachgeschaut und z.B. diese Zeile gefunden:
66.249.67.127 - - [29/Jun/2015:13:03:18 +0200] "GET /modules/field/theme/field.css?nqjcub HTTP/1.1" 200 550 "http://www.sobio.de/produkte/bauck-bio-schnellbrot-glutenfrei" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" "www.sobio.de"

Daraus ziehe ich den Schluss, daß der Bot vor ner guten Stunde die betreffende css-Datei besuchen konnte und die müßte dann aus den blockierten Seiten raus fliegen.

Mal sehen, das dauert ja immer etwas, bis es in den Webmaster-Tools angezeigt wird.

ABer jedenfalls ein guter Tipp, sich mal in den eigenen Logs umzuschauen.
Auf die Idee bin ich noch nicht gekommen.

Inzwischen habe ich gelernt, daß Google die robots.txt im Cache hält.
Normalerweise für einen Tag, in manchen Fällen auch länger.

Ich vermute, daß dies bei der Seite der Fall ist, wo nach wie vor so viele blockierte CSS+JS-Seiten angezeigt werden.

Bei anderen Projekten wurden nach oben beschriebenen Änderungen nur noch Fehler für misc/fedd.png und misc/grippie.png angezeigt.
Also habe ich den Bereich Allowed noch um Angaben für png erweitert und hoffe, daß dann demnächst alle Blockierungen verschwunden sind.

Hallo,

hatte / habe auch das Problem. Mit Hilfe von diesen Thread hier dann die robots.txt angepasst und die meisten Einträge waren verschwunden - nur einer war da, das durch einen Fehler im Theme zustande kam, der nun auch behoben ist. Müsste also passen, doch die Prüfung gerade zeigte, dass diese Datei als blockiert eingestuft wird:

http://www.domain.com/modules/user/user.css?nr1ywk

Ich bin mir sicher, dass vor der Anpassung der robots.txt noch weitere Dateien aus dem modules-Ordner bemängelt wurden, die jetzt nicht mehr aufgeführt sind. Wie kann es sein, dass diese Datei nun neu dazu kam, wo doch die Anpassung alle anderen wieder erreichbar machte?

Liegt es vielleicht an dem Zusatz "?nr1ywk" dahinter? So dass der Eintrag in robots.txt vielleicht so sein müsste: Allow: /modules/*.css*
Allerdings hatten die vorherigen Einträge alle so einen Zusatz und da hat es ja funktioniert...

Hi Trwawi,
genau vor der Frage stehe ich heute morgen auch und bin froh, daß es mir nicht alleine so geht.
Die meisten Einträge sind inzwischen verschwunden, die Einträge mit Parameter am Ende stehen noch da.
Ich denke, man sollte das mal Testen mit dem Stern am Ende.
Ich wäre zwar immer davon ausgegangen, daß der Parameter ignoriert wird, aber wer weiß das schon.
Ich werde das an einem Projekt testen und zwar vorsichtshalber mit
Allow: /modules/*.css
und
Allow: /modules/*.css*
Möchtest Du das evt. auch mal testen und Deine Erfahrungen mit teilen?

Ich nehme das gelöst oben noch mal raus.
Gruß, Regina

Hi Regina,

ich habe das gerade auch so gemacht
Allow: /modules/*.css
und
Allow: /modules/*.css*

Da ich erst vor 2 Tagen einen Relaunch durchgeführt hatte, ist bei mir sowieso noch alles gemischt, bis sich alles aktualisiert (WMT etc.). D.h. die Angaben unter "Google Index - Blockierte Ressourcen" sind im Moment eher nichts aussagend. Das, was zu passen scheint und wo man die blockierten Ressourcen auch sieht, ist der "Abruf wie durch Google". Dort ist der Eintrag aus dem vorherigen Beitrag verschwunden, aber es kamen 4 neue hinzu:

/modules/system/system.theme.css?nr1ywk
/sites/all/modules/views/css/views.css?nr1ywk
/sites/all/modules/md_slider/css/md-slider.css?nr1ywk
/sites/all/themes/Porto/vendor/owl-carousel/owl.theme.default.css?nr1ywk

Alle mit "Vorübergehend nicht erreichbar" als Grund und dem gleichen Parameter dahinter (wie auch der Eintrag aus dem vorherigen Beitrag).

Der erste Eintrag betrifft auch das modules-Verzeichnis, also scheint das Sternchen am Ende doch keine Auswirkung zu haben oder das Ergebnis ist jedes Mal anders und mal werden die Dateien gefunden, mal als blockiert erkannt aus irgendeinem Grund...

Ja, diesen Abruf wie bei Google mit Rendern habe ich auch gemacht, weil das ja den Vorgang beschleunigen soll, daß Google die geänderte Version der robots.txt erkennt.
Da kommt auch bei manchen Seiten "Vorübergehend nicht erreichbar".
Wenn ich sie via Browser aufrufe, dann sind sie ganz normal da.
Auch das Access-Logs zeigt für den Aufruf dieser Seiten via Google-Bot Status 200.
Ich habe wirklich keine Ahnung, was mir das sagen soll.

Vermutlich sollte man das Thema nicht ganz so heiß sehen.
Ich habe meine Seiten ja auch bei BING angemeldet und in der dortigen Übersicht ist keine Rede von geblockten Seiten.

Ich habe auch eine Anfrage an das Forum von Google gestellt, bislang ohne Antwort.

Zu der Meldung "vorrübergehend nicht erreichbar" noch zwei Posts mit evt. Ursachen.

https://productforums.google.com/forum/#!topic/webmaster-de/ugCOuh8UfDs
https://productforums.google.com/forum/#!topic/webmaster-de/AIPbashfklE

Bei mir ist z.B. dieses Image betroffen, wenn ich es mit Abruf wie durch Google aufrufe:
/misc/feed.png

Natürlich ist das Bild plitzschnell da, wenn ich es im Browser aufrufe.

Weiß jemand, was man da an den Einstellungen in der .htaccess ändern könnte, um das Keep-Alive-Problem speziell für den Google-Bot zu lösen?

So wie es aussieht, kann man via .htaccess höchstens den Verbindungsmodus von "close" auf "keep alive" ändern, aber nicht die Timeout-Einstellung bestimmen. Es sei denn man hat Zugriff auf die Apache Konfiguration, was aber in den meisten Fällen nur der Hoster hat.

In Apache 1 war der Standardwert wohl 15 Sekunden, in Apache 2 sind es 5 und laut vielen Aussagen sollte das reichen. Da es hierbei um Zugriffs- / Ladezeiten geht, wird häufiger das Thema "Komprimierung" erwähnt.

Sollte man unter admin/config/development/performance vielleicht die Optionen "CSS-Dateien aggregieren und komprimieren." und " JavaScript-Dateien aggregieren." aktivieren? Das ist bei mir derzeit nicht der Fall.

Unter diesen Umständen könnte es sein, dass das mit dem Sternchen dahinter gar nicht nötig ist (es sei denn solche Einträge werden auch unter "Blockierte Ressourcen" aufgelistet und nicht nur beim Abruf wie durch Google), sondern dass die Ladezeiten jedes mal variieren und jedes Mal andere Dateien nicht erreichbar sind, wenn die 5 Sekunden (oder was auch immer eingestellt ist) nicht ausreichen.

Hallo Leute,

hier steht warum dieser Fehler ausgerufen wird: https://support.google.com/webmasters/answer/6066472?hl=de
Google schreibt auch, dass dieser Fehler auch nur beim Simulationstool auftreten kann.
Es ist viel verlässlicher, wenn Ihr im access.log nachseht ob der Bot alle nötigen Ressourcen aufgegriffen hat.
Ich glaube auch nicht, dass es am keep-alive Header liegt, sondern eher am Host, besonders wenn der Server in einer Shared Hosting Umgebung läuft.
Viele hoster haben Ihre Firewall so eingestellt, dass zuviele Requests innert kurzer Zeit geblockt werden um DOS Attacken vorzubeugen.
Verlasst Euch nicht aussschliesslich auf dieses Simulationstool von Google.

Grüsse

Robert

Wenn man viele Seiten betreut, dann wird es schon sehr mühsame, es jeweils aus dem access-log zu pfriemeln.
Aber insgesamt hast Du natürlich schon recht, Robert, daß man sich nicht alleine auf das Tool verlassen soll.

Ja, das mit den Requests habe ich inzwischen auch so raus gefunden.

Interessant ist in dem Zusammenhang auch die Analyse der Page Speed:
https://developers.google.com/speed/pagespeed/insights/

Und in dem Zusammenhang wieder der Hinweis von weiter oben, daß die ganze Problematik eigentlich nur relevant ist, wenn JavaScript und CSS-Komprimierung ausgeschaltet ist.

Jedenfalls kristallisiert sich raus, daß man sich wegen der robots.txt nicht weiter verkopfen muß, wenn die allowes-Anweisungen drinnen sind.

Danke für den Link, kannte ich noch nicht. Sieht bei mir nicht optimal aus... Verstehe ich das richtig, dass Du, Regina, JavaScript und CSS-Komprimierung in Drupal nicht aktiviert hast? Wie sieht es bei Dir aus, Robert? Und alle anderen können natürlich Ihre Erfahrung auch gerne teilen.

Habe dazu Hinweise gelesen, dass wenn man die Komprimierung in Drupal aktiviert, man sie in Apache deaktivieren, was vermutlich wieder nur der Hoster kann, oder?

Das driftet allerdings ein wenig vom Thema ab. Ansonsten scheint es in der Tat so zu sein, dass die obigen Anpassungen der robots.txt so in Ordnung sind.

Ich habe bei den meisten Projekten die Komprimierung angeschaltet.
Aber eben noch nicht bei allen.
Und da sieht man deutliche Unterschiede in der Anzahl der blockierten Dateien.
Daraus hatte ich den Schluss gezogen, daß es an der Robots.txt liegt, weil ja das Verzeichnis sites/default/...*** nicht blockiert ist und dort werden die komprimierten Dateien abgelegt.
Mit den Anpassungen konnte ich einige Fehler beheben, aber nicht alle.
Mein Denkfehler lag daran, zu glauben, in diesem Bereich würden nur Fehler angezeigt, die durch blockierungen in der robots.txt zustande kommen.
Das ist eben nicht so.

Bei mir funktioniert das Zu- oder Abschalten der Komprimierung via Konfiguration->Entwicklung->Leistung völlig problemlos.
Vermutlich gibt es Ärger, wenn man das zusätzlich in der .htaccess Datei eingerichtet hat, was bei mir nicht der Fall ist.

Du kannst das ja mal probieren und gleichzeitig im Firebug via Netzwerk beobachten, was passiert.