Das Putzlowitsch Test- und SEO-Blog

Google Fehler 403 – da hat es den Bot zerlegt

Google Error 403 Seite

Twitter ist ja für seine lustigen Fehlerseiten bekannt. Das ist doch mal eine nette Fehlerseite von Google mit dem zerfallenden Roboter. :-)

Der kann einem fast ein bißchen Leid tun, der arme Bot. Eigentlich bekommt man als normaler Nutzer diese Seite nicht zu sehen. Ich habe mal mit unterschiedlichen Browser-Kennungen (Useragent) rumprobiert und auf libwww-perl reagiert Google mit dem Fehler 403 – Zugriff verweigert. Man soll halt nicht die SERPs mit irgendwelchen Perl-Skripten abfragen oder wenigstens einen vernünftigen Useragenten eintragen.

Ich bin da bei meinen PHP-Skripten ehrlich und schreibe auch keinen normalen Browser rein, der ich nicht bin. Im Moment melde ich mich als „123GoogleRank/0.42“. Allerdings gibt es in letzter Zeit einige Abweichungen zwischen den erfaßten und sichtbaren Rankings. Da muß ich mal forschen, woran das liegen könnte…

Weitere Artikel mit Bezug zu diesem:
Keine Kommentare »

Strato PowerPlus mit SpeedPlus – Fehler bei der Remote-Adresse (REMOTE_ADDR)

Nachtrag am 22.01.2010:

Seit heute scheint das weiter unten geschilderte Problem mit der Remote-Adresse nicht mehr zu bestehen. Die Einträge in der .htaccess-Datei oder sonstige Eingriffe sind daher möglicherweise nicht mehr erforderlich.
Bei mir ist das Problem verschwunden, aber offensichtlich noch nicht generell.

Nachtrag am 01.03.2011:

Nach aktuellen Informationen ist das Problem wohl nun doch endgültig behoben worden. Die Einträge in der .htaccess-Datei oder sonstige Eingriffe sind daher nicht mehr erforderlich.

Seit Anfang Dezember 2009 bin ich mit meiner Schnurpsel-Seite wieder zurück zu Strato umgezogen. Ganz weg war ich ja nicht, ich hatte nur den Hostnamen bei einem anderen Anbieter aufgeschaltet. Aber seit es nun SpeedPlus bei Strato gibt, bin ich nun doch wieder zurückgekehrt.

Die Geschwindigkeit ist wirklich gut. Antwortzeiten von ungefähr 0,5 Sekunden gegenüber 3 bis 4 Sekunden vorher sind für ein PHP-Schwergewicht wie WordPress eine merkliche Verbesserung. Zudem wurde auch gleich das ohne-www-Problem beseitigt, in der Umgebungsvariable HTTP_HOST steht nun der tatsächlich im HTTP-Request angegebene host drin.

Die Remote-IP-Adresse (REMOTE_ADDR)

Neben allerlei anderen interessanten Informationen wird bei jedem Webseitenaufruf auch die IP-Adresse des Aufrufers in einer Umgebungsvariablen vermerkt. Auf diese kann z.B. mit Skriptsprachen wie PHP oder Perl als Variable „REMOTE_ADDR“ zugegriffen werden. Diese Remote-Adresse ist z.B. für statistische Auswertungen interessant oder kann beim Aussperren unerwünschter Zugriffe (Spam-Bots) helfen.

Allerdings zählt diese IP-Adresse ja nach Auffassung und Auslegung der Gesetze zu den personenbezogenen Daten und dürften dann eigentlich nicht gespeichert werden. Bei Strato werden die IP-Adressen in den den Kunden zur Verfügung gestellten Serverlogdateien in anonymisierter Form gespeichert. Auch die im Kundenmenü anzeigbare Webseiten-Statistik greift auf diese Daten zurück.
So können die Zugriffe zwar unterschieden aber nicht einem konkreten Anschluß zugeordnet werden

Mehr Geschwindigkeit mit SpeedPlus

Wenn ich die Grafik zu SpeedPlus bei Strato richtig deute, werden die Zugriffe nicht mehr direkt auf die Webserver geroutet, sondern von einem Loadbalancing-Cluster lastabhängig verteilt.
Diese Verteilung funktioniert vermutlich ähnlich wie bei einem nicht-transparenten Proxy, denn für den Webserver sieht es so aus, als würde der Strato-interne Server die Seite anfordern. Genau deshalb steht in der Remoteadresse nicht mehr die IP-Adresse des Aufrufers drin, sondern eine 81.169.145.xxx drin.

Komischerweise tritt der Effekt aber nicht bei allen Domains auf, nur die Hälfte meiner Domains (inkl. Subdomains) bei Strato ist davon betroffen.

Die richtige Remoteadresse ermitteln und setzen

Ich wäre ja nicht Schnurpsel, hätte ich nicht bereits eine Lösung für das Problem parat :-)
Die richtige IP-Adresse findet man im Request-Header-Feld X-Forwarded-For, daß heißt der Strato-Server trägt hier die Adresse ein, von der er die Anforderung erhalten hat.

In Skriptsprachen wie PHP oder Perl steht diese Variable als „HTTP_X_FORWARDED_FOR“ zur Verfügung. Hier könnte man sich die Remote-Adresse also einfach möglichst am Anfang (bei WP z.B. in der wp-config.php) der Abarbeitung in die REMOTE_ADDR eintragen, z.B. so:

if( isset( $_SERVER['HTTP_X_FORWARDED_FOR'] ) ) {
  $ip_addr = @trim( @end( @explode( ",", $_SERVER['HTTP_X_FORWARDED_FOR'] ) ) );
  if( '' != $ip_addr )
    $_SERVER['REMOTE_ADDR'] =  $ip_addr;
}

Hier kommen zwei wichtige Aspekte zum Tragen, denn in „X-Forwarded-For“ können mehrere durch Komma getrennte IP-Adressen stehen, sofern unterwegs mehrere Proxies durchlaufen wurden. Außerdem soll die Adresse nicht überschrieben werden, falls kein X-Forwarded-For-Feld existiert oder aus anderem Grund nicht ermittelt werden kann.

Für Perl könnte das etwa so aussehen:

if( $ENV{'HTTP_X_FORWARDED_FOR'} ne "" )
{
  my @ip_list = split(/,/, $ENV{'HTTP_X_FORWARDED_FOR'});
  $ENV{'REMOTE_ADDR'} = $ip_list[-1]; 
}

Nachteil ist hierbei natürlich, daß man alle Webapplikationen, die irgendwie die REMOTE_ADDR verwenden, entsprechend anpassen muß. Es geht aber auch noch einfacher und allgemeiner.

Umgebungsvariablen mit mod_setenvif setzen

Das Apache-Modul mod_rewrite kennen bestimmt viele WordPress-Nutzer, manch einer kennt vielleicht sogar mod_alias, aber vermutlich nur wenige haben schon mal etwas vom Modul mod_setenvif gehört. Es kommt auch ganz bescheiden und unspektakulär mit nur vier Anweiungen daher.

Mit dem Modul mod_setenvif hat man die Möglichkeit, Umgebungsvariablen abhängig von Request-Feldern zu setzen. Genau das brauchen wir hier. Wir haben das Request-Feld X-Forwarded-For und wollen abhängig davon die Umgebungsvariable REMOTE_ADDR setzen. Das Problem läßt sich mit ein bißchen Regular-Expression in einer Zeile in der .htacces erschlagen:

SetEnvIf X-Forwarded-For "(.+,)? *(.+)$" REMOTE_ADDR=$2

Optimalerweise steht diese Zeile ganz am Anfang einer .htaccess im Wurzelverzeichnis des Webpaketes. Dann wirkt sei auch auf alle Domains oder Subdomains, die ihr sichtbares Wurzelverzeichnis in einem Unterverzeichnis des Webspace haben.

Das schöne an diesem kleinen Eingriff ist, daß er auch auf das Serverlogfile und die Webstatistik wirkt. Im Logfile stehen nun wieder zwar anonymisierte, aber unterscheidbare Zugriffe und die Webstatistik zeigt nicht mehr 10000 Zugriffe von nur 5 Adressen an.

Ende gut, alles gut?

Mit ein bißchen Handarbeit kann man wieder mal einen Strato-Konfigurationsfehler ausbügeln. Andereseits ist die SpeedPlus-Plattform noch recht neu, da können solche Fehler schon mal auftreten. Ich habe das Problem auch bereits vor 10 Tagen an den Strato-Support gemeldet, warte aber immer noch auf die Antwort zu meinem Ticket. Scheint etwas komplizierter zu sein. Bis zur Strato-Problemlösung kann mein kleiner „Trick“ zumindest über die Zeit helfen.

7 Kommentare »

Komischer Spam und der HTTP-Statuscode

Crawling-Fehler Google-Webmastertools

Komischer Link

Hin und wieder schaue ich mal in die Google-Webmastertools, wie es so um meine Seiten bestellt ist. Neben allerlei anderen, nützlichen Sachen gibt es auch eine Übersicht, welche Probleme es möglicherweise beim Abfragen der Seiten durch den Google-Bot in letzter Zeit gab. Und diese Übersicht zeigt mir im Moment dieses hier an.

Gut, die Fehler 1,2 und 4 sind klar, die kann ich nachvollziehen, aber was bitte ist Fehler 3?

/warning_this_is_english_domain_to_solve_this_problem_submit_site_in_atoall.com.html

Wenn ich irgend sowas Seltsames finde, suche ich erstmal bei Google, was das denn bedeuten könnte. Das Ergebnis hat mich dann doch überrascht. Diese komische, nichtexistierende Seite gibt es auf einigen Tausend Domains. Wenn man die Suche nur auf deutsche Seiten beschränkt, findet man sogar prominente Seiten wie www.ard.de oder www.wetter.de.

Aber wieso nimmt Google diese vermutlich nicht wirklich existierenden Seiten in den Index auf, die offensichtlich Ergebnis einer, wie auch immer gearteten Spamaktion sind?

HTTP-Statuscode

Hier kommt nun der HTTP-Statuscode ins Spiel, denn was im Fehlerfall dem Nutzer angezeigt wird, ist das eine. Viel wichtiger ist aber, mit welchem Antwortcode die Seite ihr Ergebnis zurückliefert. Bei einem „normalen“ Fehler, wie z.B. einer nichtexistierenden Seite, sollte das der Code 404 Not Found sein. Zu den Statuscodes hatte ich bereits vor einiger Zeit etwas geschrieben. Was machen aber alle die Seiten, die man in der Google-Suche zu der seltsamen URL findet. Sie geben einfach den Code 200 Ok zurück, damit geht der Google-Bot davon aus, daß die Seite existiert, und nimmt sie in den Index auf.

Manche Seiten zeigen zumindest dem Nutzer an, daß ein Fehler aufgetreten ist. Die zwei oben genannten Beispiele tun aber so, als sei alles in Ordnung und präsentieren dem Nutzer die Startseite. Das finde ich ohnehin immer ein Unding, weil der Nutzer überhaupt nicht mitbekommt, das etwas nicht stimmt. Gut, man muß nun den User auch nicht unbedingt mit einer spartanischen Fehlermeldung wie hier auf schnurpsel.de erschrecken, aber so zu tun, als sei nichts passiert, ist auch nicht der richtige Weg. Wenigstens sollte man den Statuscode 404 ausliefern, den sieht der Nutzer ja nicht.

Meine Deutung

Ich würde diese Sache mal als Webmaster-Spam verbuchen, denn die Treffer in der Google-Suche findet man nur mit der vollständigen URL. Hätte der „Spamerfinder“ es auf Google-Treffer abgesehen, hätte er die einzelnen Wörter mit Bindestrichen und nicht mit Unterstrichen trennen müssen.

Aber Webmaster, die sich entweder mit den Google-Webmaster-Tools oder einfach mit den Errorlogs des Webservers die Fehler hin und wieder ansehen, stoßen auf diese URL. Eventuell ist ja der eine oder andere Neugierig, zumal der gelesene URL-Text irgendwie nach einer Systemmeldeung klingt, und besucht die Seite am Ende der URL. Naja, und was er da dann findet…

Nachtrag (2.11.):
Der Sachverhalt mit den komischen URLs ist schon jemandem 10 Tage vor mir aufgefallen, wie ich hierrüber entdeckt habe. Ähmmm, stand ja auch schon im ersten Kommentar. Ich sollte die Kommentare mal ernst nehmen :-)

Beste Grüße nach Görlitz :-)

Weitere Artikel mit Bezug zu diesem:
4 Kommentare »

410 Gone – der SEO-technische Supergau

Strato DNS - 410 GoneLange Zeit habe ich ja die Strato-Fahne hochgehalten. Als es früher noch viele Schwierigkeiten mit wenig PHP-Speicher und Safemode, nicht vorhandenem mod_rewrite, falscher Artikelreihenfolge oder ominösen Endlosweiterleitungen gab (zum Teil auch noch gibt), habe ich stets nach Lösungsmöglichkeiten gesucht, diese meist gefunden und auch anderen, leidgeplagten Strato-Nutzern zur Verfügung gestellt.

Selbst über das fehlerhafte Datenbank-Backup konnte ich noch hinwegsehen, hat mich zwar geärgert, aber letztendlich war ich an der Sache ja selbst nicht ganz unschuldig. Schon länger stört mich allerdings die schlechte Gesamtperformance von WordPress auf meinem Strato-Sharedwebhosting-Paket. Nun hab ich zwar herausgefunden, daß es wohl nicht an einer langsamen Datenbank liegt, wie meist angenommen wird, aber wirklich helfen tut diese Erkenntnis auch nicht.

Hier kommt zunächst ein kleiner Exkurs in die HTTP-Statuscodes. Jeder Aufruf einer Webseite (Request) wird vom Server mindestens mit einem Statuscode beantwortet (Respond), Wenn z.B. alles in Ordnung ist, kommt ein Status 200 OK zurück. Bei Fehlern gibt es mehrere Möglichkeiten, normale Fehler werden mit einem 4xx-Code beantwortet, zwei davon will ich kurz erläutern.

404 Not found

Der wohl am häufigsten auftretende Fehlercode dürfte 404 Not Found sein:

404 Not Found
The requested URL /blafasel was not found on this server.

Das dürfte wohl in der oder anderer Form jeder schon mal gesehen haben. Dieser 404 ist ein sehr allgemeiner Fehlercode. Der Server hat zwar einen technisch gesehen einwandfreien Request erhalten, kann aber das Gewünschte aus nicht näher bekannten Gründen nicht finden. Möglicherweise hat der Nutzer nur eine falsche URL in der Adresszeile der Browsers eingetippt oder der Webmaster der Seite versehentlich eine Datei gelöscht.
Der Aufrufende darf aber gern später noch mal probieren, ob der Fehler vielleicht nicht mehr auftritt.

410 Gone

Ganz ähnlich, aber von der Bedeutung her anders ist der Fehler 410:

410 Gone
The requested resource /blafasel is no longer available on this server and there is no forwarding address. Please remove all references to this resource.

Auch hier ist der Request technisch OK. Das Gewünschte gab es zwar mal, es ist aber absichtlich entfernt worden. Spätere Anfragen sind zwecklos, das Gesuchte wird es hier nicht mer geben.
Diesen Fehlercode 410 sendet der Webserver nicht einfach so, das muß vom Webmaster schon explizit und bewußt so konfiguriert sein.

Es kann durchaus sinnvoll sein, den Code 410 zu übermitteln, z.B. dann, wenn man nicht möchte, das eine Seite oder ein Bild weiterhin in den Suchergebnissen der Suchmaschinen erscheint. Und man teilt dem interaktiven Nutzer einfach mit, daß er sich keine Hoffnungen machen braucht, die Seite irgendwann mal wieder zu Gesicht zu bekommen.

DNS-Umleitung bei Strato

Weil die Seite hier nun immer so langsam ist, dachte ich mir, sie einfach per DNS auf einen schnelleren Webserver aufzuschalten. Das geht im Strato Kundenmenü auch ganz einfach mit Einstellungen->Domainverwaltung->DNS-Verwaltung. Eine andere IP-Adresse für den A-Record eintragen, fertig. Der folgende Hinweis wird angezeigt:

Hinweis: Bitte beachten Sie, dass Änderungen an diesen Einstellungen auf Grund der dezentralen Struktur von DNS, erst spätestens 24 h nach Aktivierung vollständig aktiv sein werden.

Gut denke ich, das ist auch kein Problem, schließlich liegen auf dem alten und neuen Server identische Kopien des Blogs. Dann wird halt erstmal noch die Seite bei Strato aufgerufen, ist auch kein Beinbruch.

Aber denkste! Als ich nach fünf Minuten probieren will, ob die DNS-Server vielleicht schon aktualisiert sind, das geht eigentlich meist recht schnell, sehe ich nur das:

410 Gone
The requested resource / is no longer available on this server and there is no forwarding address. Please remove all references to this resource.

Schock! Was soll das denn bitte? Warum wird nicht allen noch bei Strato eingehenden Requests für schnurpsel einfach alles wie bisher angezeigt, ich habe da doch nichts gelöscht.
Nö, stattdessen wird den Nutzern und Suchmaschinen-Bots mitgeteilt:

„Ja, hier bei Schnurpsel gab es mal was, das ist aber alles auf nimmer Wiedersehen verschwunden, hat sich aufgelöst, ist ins Web-Nirwana entfleucht. Kommt am Besten gar nicht mehr wieder, hier ist eh nichts mehr zu holen.“

Super, nicht auszudenken, wenn die DNS-Server tatsächlich erst nach 24 Stunden aktualisiert worden wären. Glücklicherweise hat es nur eine halbe Stunde gedauert, aber ein Ding ist es schon, was Strato da einfach macht. Bei meiner Testseite hier ist das kein Drama, wer aber eine richtige, wichtige Webseite bei Strato hostet, kann schon Probleme bekommen.

21 Kommentare »

Eingehende Links von /map.html

Eingehende Links sind ja was feines. Da hat also jemand anderes die Seite verlinkt, vielleicht weil sie ihm besonders gut gefällt, er sie irgendwie nützlich findet oder warum auch immer. Manche Seiten veröffentlichen sogar Statistiken mit diesen eingehenden Links, inklusive des Links als Link, womit er dann ein ausgehender Link wird, der wiederum einen eingehenden Link aus Sicht der verlinkenden Seite darstellt. Wie wichtig Links sind, ist ja nicht erst seit Google bekannt.

Woher weiß man nun aber, woher die Links kommen? Man kann es unter anderem in der Webserver-Logdatei sehen, dort wird der soganannte Referer möglicherweise mit gespeichert und das ist genau die Information um zu erkennen, wie der Besucher auf die Seite gelangt ist. Wenn er z.B. über eine Suche von Google gekommen ist, kann man sogar herausfinden, wonach der Benutzer bei Google gesucht hatte.

Der Referer wird normalerweise vom Web-Browser des Nutzers an den Webserver beim Aufruf einer Seite im sogenannten HTTP-Request mitgeschickt, kann aber ebenso fehlen oder sonst irgendwie verändert sein. Er kann auch auf irgendeine beliebige andere Webseite verweisen, auf der überhaupt kein Link zur eigenen Seite existiert. Genau das machen sich Spammer zunutze, man spricht dann von „Referer-Spam“, eine Technik, die es schon seit einiger Zeit gibt.

In letzter Zeit habe ich hier häufiger eingehende Links von Seiten, die als /map.html erscheinen. Immer von irgendwelchen .com-Hosts mit so interessanten Namen wie facsimile-prints, trollcollective oder yachting-swap, in den letzten 30 Tagen ungefähr 20 unterschiedliche Seiten mit jeweils vier bis sieben Aufrufen.
Auf den Seiten selbst findet man dann lange Listen mit Links, die alle nach pharmazeutischen Produkten klingen, so Sachen wie adipex, didrex, medrol, prozac und xanax. Diese Links sind aber wiederum nur Weiterleitungen auf andere Seiten die allerdings meist nicht funktionieren. Also weiß ich nicht, wo man dann wirklich landet, interessiert mich aber auch nicht. Es ist halt Spam, Referer-Spam.

Falls also jemand vermehrt eingehenden Links von *.com/map.html hat, nicht zu früh freuen, es wir mit hoher Wahrscheinlichkeit Spam sein.

Weitere Artikel mit Bezug zu diesem:
Keine Kommentare »