Das Putzlowitsch Test- und SEO-Blog

Alles Nichts oder nicht alles?

Google-Treffer mit Parameter

Wenn Besucher über Google auf die eigene Webseite kommen, ist das ja normalerweise eine schöne Sache. Allerdings nicht, wenn es über einen seltsamen Link, wie er oben zu sehen ist, passiert. Wie kommt aber soetwas überhaupt in den Index einer Suchmaschine?

Das gibts doch gar nicht

Bereits im Oktober letzen Jahres hatte ich etwas Ähnliches beobachtet. Da wurden Google massiv mit Links auf irgendwelche nicht existierende Seiten gefüttert. Wenn nun eine dieser nicht vorhandenen Seiten auf die Anfrage des Googlebots einen HTTP-Status „200 OK“ zurückliefert, geht Google davon aus, daß es die Seite gibt und nimmt sie in den Index auf. Korrekterweise sollte aber mit dem Fehlerstatus „404 Not found“ geantwortet werden, so daß die Seite nicht im Index landet. Genau das war damals bei mir der Fall, also ist eigentlich alles in Butter. Nur habe nicht mit der Großzügigkeit von WordPress gerechnet.

Die WordPress.presse.pressung

In manchen Dingen ist WordPress recht großzügig. Früher war es möglich, wenn in den Permalinks die Artikel ID verwendet wurde, einen Artikel über nahezu beliebig viele URLs aufzurufen. Sobald die ID erkannt wurde und existierte, wurde der Rest der URL nicht weiter überprüft. So hätte man diesen Beitrag hier auch noch mit /alles-quark-399/ oder /blafasel-399/ aufrufen können. Das geht mittlwerweile nicht mehr. Allerdings ist zur Zeit etwas Ähnliches immer noch möglich, wenn man in den Permalinks die Kategorie verwendet.

Wenn nun eine WordPress-Seite mit Parametern in der Form /?parameter=wert aufgerufen wird, ignoriert WordPress einfach unbekannte Patemeter oder ungültige Paremeterwerte und tut so, als würde es diese Parameter gar nicht geben. Somit führen folgende Aufrufe zu gültigen Seiten:

http://testblog.schnurpsel.de/?q=Diese Seite gibt es nicht
http://testblog.schnurpsel.de/?quark=Gesund und schmeckt lecker
http://testblog.schnurpsel.de/?p=Hier steht normalerweise die ID

Bei den ersten beiden Beispielen wir ein unbekannter Paremeter verwendet, im dritten Beispiel der gültige Parameter p= (Short-Link), der allerdings eine numerische Artikel-ID erwartet. In allen Fällen wird die Startseite mit dem Status „200 OK“ angezeigt. Es funktioniert aber ebenso mit Einzelseiten oder anderen Permalinks:

http://testblog.schnurpsel.de/...hallo-welt/?frage=was-soll-das
http://testblog.schnurpsel.de/2010/03/?jahreszeit=Frühling

Gut oder schlecht

Ob dieses Verhalten von WordPress nun gut oder schlecht, gewollt oder ein Fehler ist, mag ich nicht beurteilen. Ich finde es zumindest suboptimal, denn dadurch entstehet z.B. die oben gezeigte URL als Google-Treffer, und sowas möchte ich nicht haben. Dabei wäre es für WordPress kein größeres Problem, unbekannte Parameter oder ungültige Parameterwerte als Fehler zu behandeln. Das schöne an WordPress ist ja, daß es recht einfach erweitert und modifiziert werde kann.

Fehler bleibt Fehler

Deshalb habe ich mir diese Parameterprüfung hier nachgerüstet (aber nicht für den Testblog!), übrigens auch für die worpdresseigene Suchfunktion. Denn falls es keinen Suchtreffer gibt, finde ich, ist das auch einen „404 Not Found“ wert :-)
Nun sollte auch die ganz oben gezeigte, hier nicht existierende Seite nach einiger Zeit aus dem Suchindex verschwinden.

Nachtrag:
Weil es angefragt wurde, hier mein Code zur Parameterprüfung, der sich per Action-Hook in parse_request reinhängt:

<?php
 function plw123_parse_request( $data ) {
  // Liste der numerischen Parameter
  $num_para = array( 'p', 'page_id', 'attachment_id', 'tag_id',
          'page', 'paged',
          'year', 'monthnum', 'day', 'w', 'm',
          'hour', 'minute', 'second' );
  // Parameter übergeben, aber nicht gefunden
  foreach( $_GET as $key => $value )
   if( !array_key_exists( $key, $data->query_vars ) ) {
    $data->query_vars['error'] = '404';
    return;
   }
  // Numerische Parameter prüfen
  foreach( $data->query_vars as $key => $value ) {
   // Sonderbehandlung Kategorie-IDs
   if( 'cat' == $key ) {
    // darf eine Liste von kommaseparierten Integerwerten sein
    $test_value = preg_replace( '|[^0-9,-]|', '', $value );
    if( $test_value != $value ) {
     $data->query_vars['error'] = '404';
     return;
    }
   }
   // Numerische Werte
   if( in_array( $key, $num_para ) ) {
    $value = trim( $value );
    // Page bei Einzelansicht (Seite, Artikel) kann führenden Slash enthalten
    if( 'page' == $key )
      $value = ltrim( $value, '/' );
    $test_value = absint( $value );
    if( !$test_value ) {
     $data->query_vars['error'] = '404';
     return;
    }
   }
  }
 }
 add_action( 'parse_request', 'plw123_parse_request' );
?>

Habe das jetzt mal erweitert und in ein Plugin gepackt: 123 Prameter Check

4 Kommentare »

Burger mit Pommes – Experiment, vorläufiges Endergebnis

Vor etwa zwei Monaten hatte ich inspiriert durch und in Anlehnung an Mohakenox vom SEO-Handbuch ein ähnliches Experiment gestartet. Mittlerweile hat Dennis dort auch das amtliche Endergebnis vorgestellt. Wie ist es aber den Burgern mit Pommes bisher ergangen?

Der Versuchsaufbau

Im Ausgangsbeitrag „Burger mit Pommes“ habe ich sechs identische Bilder platziert, die sich nur durch ihren Dateinamen unterscheiden:

  • burger mit pommes.jpg (geschütztes Leerzeichen – Code: %A0)
  • burger mit pommes.jpg (normales Leerzeichen – Code: %20)
  • burger.mit.pommes.jpg (Punkt)
  • burger_mit_pommes.jpg (Unterstrich)
  • burgermitpommes.jpg (kein Trennzeichen)
  • burger-mit-pommes.jpg (Bindestrich)

Die Ziel-Suchphrase Burger mit Pommes ist kein künstliches und neu erfundenes Wort, sondern ein normaler Alltagsbegriff. Dafür gab es zum Versuchsbeginn bereits ca. 140 Tausend Treffer in der Bildersuche.

Burger mit PommesAlle meine Testbilder sind byte-identisch und sehen so wie das linksstehende „Burger mit Pommes“-Foto aus.
Da es sich um dieselben Bilder handelt, werden sie von Google auch nur unter einer Image-ID geführt und es wird pro Suchanfrage immer nur genau ein Bild angezeigt.

Die Google-Bildersuche muß sich also letzendlich für eine konkrete Bild-URL entscheiden. Da ich nun nicht ständig nachsehen will, wo welches Bild wann für bestimmte Suchabfrage zu finden ist, läuft eine automatische Überwachung der Suchergebnisseiten, die zweimal am Tag eine „Messung“ vornimmt. Die Probennahme erfolgte für site:schnurpsel.de, burger mit pommes und burger.

Ergebnisse für site:schnurpsel.de

Burger mit Pommes Google - Bildersuche für site:schnurpsel.de

Zum ersten Mal tauchte ein Bild am 20. Januar auf, also etwa zwei Wochen nach dem Veröffentlichen der Bilder (am 6. Januar). Überraschenderweise war es das Bild ohne Trennzeichen (burgermitpommes.jpg). In den darauf folgenden fünf Tagen war Google hin- und hergerissen. Mal wurde das Bindestrichbild, mal das in Zusammenschreibung gezeigt. Nach sechs Tagen hatte sich Google dann für die Datei ganz ohne Trennzeichen entschieden. So ist es bis heute geblieben.

Ergebnisse für burger mit pommes

Burger mit Pommes Google-Bildersuche für burger mit pommes

Einen interessanten Verlauf zeigt das eigentliche Suchziel burger mit pommes. Das Bild ohne Trennzeichen steigt, auch am 20.1., auf Platz 10 der Suchergebnisse ein, um sich aber schon eine Messung (12 Stunden) später mit Bindestrichtrennung auf den vierten Platz vorzuschieben. Dort bleibt es dann für ungefähr 5 Tage um sich schließlich ungetrennt auf dem achten Platz festzusetzen.

Erst vorgestern konnte sich das Bild dann um zwei Plätze auf den 6. Rang verbessern. Mit SafeSearch „strikt“ liegt es derzeit sogar auf der Top-Position, aber das nur nebenbei.

Ergebnisse für burger

Burger mit Pommes Google-Bildersuche für burger
Mit den Einzelbegriff burger gab es die erste Platzierung am 21.1. auf Position 159 für burger-mit-pommes.jpg. Von kleinen Bewegungen abgesehen tat sich nicht viel und das Bild verschwand nach 5 Tagen wieder ganz aus den Suchergebnissen.

Allerdings ist der Burger-Markt natürlich viel größer, mehr als 12 Millionen Bilder buhlen hier um die Gunst der Bildersucher und der Bildersuche und nicht nur 140000 wie bei „burger mit pommes“.

Hin und her, auf und ab

Die Bewegungen in den Suchergebnissen der drei Suchanfragen fallen zeitlich etwa zusammen. Da ich die „Messungen“ zur Lastverteilung etwas über den Tag verteile, ergeben sich gewisse Ungenauigkeiten, aber die Gesamttendenz ist gut sichtbar.

Der „Gewinner“ ist aus meiner Sicht das Bild mit Bindestrich-Trennung, auch wenn es seit geraumer Zeit nicht mehr angezeigt wird, sondern Google das Bild ohne Trennzeichen verwendet. Für die Suche zu konkreten Suchbegriffen hatte es die höchste Platzierung (burger mit pommes) bzw. überhaupt den Sprung in die Suchergebnisse (burger) geschafft. Die site- bzw. imagesite-Abfrage ist quasi inhaltsneutral, da spielt das Keyword im Dateinamen keine Rolle, weil es einfach gar keinen Suchbegriff gibt.

Trennung mit Hindernissen

Eine wichtige Rolle spielt meiner Meinung nach auch die Trennbarkeit des zusammengeschrieben Suchbegriffs durch Google. Man kann das einfach daran erkennen, ob Google „Meinten Sie: …“ anzeigt. Für burgermitpommes weiß Google, wie das in einzelne Wörter zu zerlegen ist, bei mohakenoxistsuper hingegen nicht. Der Unterstrich ist übrigens kein Trennzeichen, Leerzeichen, Bindestrich und Punkt hingegen schon.

Was für Suchanfragen funktioniert, geht natürlich auch für Dateinamen. So ist für Google vermutlich burger-mit-pommes und burgermitpommes erst einmal inhaltlich gleichwertig. Möglicherweise bevorzugt Google dann aber die Zusammenschreibung, weil sie kürzer ist. Vielleicht aber auch nicht, das läßt sich mit den wenigen Beispielen kaum verifizieren :-)

Die anderen Bilder

Burger mit PommesDurch die exakt identischen Bilder können z.B. die Dateigröße oder der Bildinhalt als Rankingfaktor ausgeschlossen werden.

Einen wesentlichen Nachteil hat das aber auch, man kann nicht sehen, ob und wo die anderen Bilder einsortiert worden sind.

Zumindest wurden alle Bilder vom Googlebot/Image erfaßt. Was aber aus den Bildern mit den anderen Trennzeichen geworden ist, kann ich nicht sagen. Außerdem habe ich das Bild mit der Punkt-Trennung erst etwa 10 Tage später nachgeschoben. Insofern ist es möglicherweise noch nicht ordentlich erfaßt. Andererseit ist es damit natürlich jünger, was sich wiederum positiv auswirken könnte.

Ich bleibe bei der Trennung mit Bindestrich

Nun kann drüben beim SEO-Handbuch oder hier jeder selber seine Schlüsse ziehen, ich bleibe erstmal bei der Trennung mit Bindestrich (oder korrekt: dem Minus-Zeichen) für die Dateinamen meiner Bilder.

Eine Überlegegung wert ist auch die Zusammenschreibung, allerdings sollte vorher kurz überprüft werden, ob Google die Wörter korrekt trenne kann („Meinten Sie:…“). Wenn das der Fall ist, könnte auch der Verzicht auf Trennzeichen in Frage kommen, der Übersichtlichkeit und Lesbarkeit ist das aber nicht wirklich zuträglich.

Vielleicht starte ich demnächst mal ein Experiment zur Zusammenschreibung…

Weitere Artikel mit Bezug zu diesem:
5 Kommentare »

Der Februar 2010 in Zahlen

Den letzten Monatsrückblick gab es im Januar 2010. Wenn man nicht so recht weiß, was man sonst schreiben soll, stürzt man sich halt auf die Statistik :-). Die Werte sind alle aus der Serverlogdatei ermittelt worden.

Die Kennzahlen vom Februar 2010

  • Webzugriffe: 141450 von 12946 IP-Adressen (10,93 Req/IP)
  • Seitenzugriffe: 5659 (ca. 202/Tag)
  • Besucher: 3411 (ca. 122/Tag)
  • Einnahmen: 0,00 EUR (keine)

Was ich unter Web- bzw. Seitenzugriffen verstehe, habe ich bereits im letzten Monat erklärt. Neu sind die Besucher, hier verwende ich eine Kombination aus anonymisierter IP-Adresse und User-Agent, um Besucher zu unterscheiden.

Aus den Seitenzugriffen und der Besucherzahl ergibt sich der Seiten/Besucher-Quotient, hier liegt der Wert bei 1,66 Seiten je Besucher. Oder anders gesagt, durchschnittlich nur etwas mehr als jeder dritte Besucher guckt sich mehr als eine Seite an. Die globale Absprungrate liegt bei ungefähr 61 Prozent.

Die Einnahmen betrugen im Februar 0 Euro und 0 Cent, kein Wunder, habe ich doch den Google-Adsense-Block wie angekündigt wieder entfernt.

Am häufigsten aufgerufene Seiten

Die am häufigsten aufgerufene Seite ist die Startseite mit 432 Zugriffen (etwa 7,6 %). Es folgen diese Seiten:

  1. WordPress bei Strato (414 → 7,3 %)
  2. WordPress beim 1&1 Webhosting (1&1 Homepage) (357 → 6,3 %)
  3. WordPress 2.3 – Problem ohne www bei Strato (325 → 5,7 %)
  4. WordPress Permalinks (290 → 5,1 %)
  5. Warum WordPress bei Strato so langsam ist (272 → 4,8 %)
  6. SpeedPlus – Strato macht PHP-Anwendungen schneller (236 → 4,2 %)
  7. Mit WordPress per E-Mail bloggen (217 → 3,8 %)
  8. Strato wird vernünfig, mod_rewrite funktioniert (185 → 3,3 %)
  9. Home/Startseite im WordPress-Menü (176 → 3,1 %)
  10. Google-Bildersuche mit neuem imagesite-Parameter (168 → 3,0 %)

Die Artikel passen logischerweise recht gut zu den häufigsten Suchwörtern wie wordpress, strato, permalinks, mod_rewrite, 1und1 u.Ä. Eine kleine Ausnahme stellt der Artikel auf Platz 10 dar, hier kamen die Besucher kaum über eine Suchmaschine, sondern über Twitter und andere, referenzierende Seiten.

Blog-Statistik

Zum Schluß noch schnell die Blog-Statistik. Hier bei Schnurpsel gibt es derzeit 16 Seiten sowie 137 Artikel in 12 Kategorien und mit 156 Stichworten. Dazu kommen 684 genehmigte Kommentare, Trackbacks und Pingbacks.

Ein Kommentar »

Höher, schneller, weiter

Mit den Google-Webmastertools bekommt man einen guten Überblick, wie oft der Googlebot vorbeischaut und wieviele Daten er in welcher Zeit Abfragt.

Pro Tag gecrawlte Seiten

Google - Crawling Anzahl der Seiten pro Tag Februar 2010
Auf dem Diagramm ist noch das Ende vom November, der ganze Dezember und Januar und der Anfang vom Februar zu sehen. Scheinbar tritt der Googlebot auch über den Jahreswechsel etwas kürzer, feiert Weihnachten und Silvester und legt dann erst Mitte Januar wieder richtig los.

Pro Tag heruntergeladene Kilobyte

Google - Crawling Datenmenge in kByte pro Tag Februar 2010
In etwa parallel dazu verläuft normlerweise die Kurve zu den täglich heruntergeladenen Datenmengen. Klar, je mehr Seiten angefragt werden, um so mehr Daten fallen da durchschnittlich an.

Eines fällt aber auf, denn obwohl die Anzahl der pro Tag abgefragten Seiten ab Mitte Januar und im Februar höher liegen als noch im November, ist die Datenmenge nicht in gleichem Maße angestiegen. Der Grund ist recht einfach. Ich hatte Anfang/Mitte Dezember die gzip-Komprimierung für die Seiten aktiviert.

Dauer des Herunterladens einer Seite (in Millisekunden)

Google - Crawling Zeit in Millisekunden pro Seite Februar 2010
Die Geschwindigkeit der Seitenauslieferung ist die für den normalen Nutzer, also den Besucher einer Website der wohl wichtigste, technische Wert. Wenn erstmal ein paar Sekunden nach dem Aufrufen einer Seite oder länger nichts passiert, ist das aus Anwendersicht eher unerfreulich.

Der Wert lag im November bei etwa 1,5 Sekunden und schließt damit an die Zahlen vom Oktober an. Anfang Dezember bin ich dann Dank SpeedPlus wieder zu Strato zurückgekehrt und seitdem liegen die Ladezeiten fast immer bei erfreulichen 0,8 Sekunden. Aber eben nur fast. Wie man im Diagramm sieht, gab es schon im Dezember und Anfang Januar Ladezeitspitzen, die dann im Februar nochmal deutlich zunahmen. Allerdings ist das eher darin zu sehen, daß durch die größere Anzahl der pro Tag abgefragten Seiten auch die Wahrscheinlichkeit für den Googlebots auf eine Lastspitze zu treffen, größer war.

Ungeachtet dessen gibt es aber diese Lastspitzen, die nicht nur der Googlebot „sieht“, sondern auch der normale Nutzer bemerkt. Wenn man Pech hat, dauert das Laden einer Seite wieder 4 bis 6 Sekunden, ganz so wie vor der SpeedPlus-Zeit bei Strato. Diesmal ist es aber meiner Meinung nach nicht die schlechte PHP-Performance, sondern eher die Datenbank. Die Datenbankserver sind zwar grundsätzlich nicht wirklich lahm, legen aber ab und zu ein paar Gedenkminuten ein, wie mir scheint. Und genau dann dauert der Seitenaufruf wieder mehrere Sekunden. Kürzlich gab es auch wieder mal einen Totalausfall, der dann zu einem 500er Fehler führt.

Hin und weg

Nun sind zwar PHP und Webserver bei Strato schnell, aber die Datenbank klemmt mitunter. Deshalb bin ich vorerst wieder zu meiner externen Datenbank zurückgekehrt. Das eigentlich langsame ist hierbei die Datenübertragung über das Internet zwischen Strato (Karlsruhe/Berlin) und Host-Europe (Köln). Um das etwas abzudämpfen, habe ich zusätzlich ein Datenbank-Cache-Plugin installiert, welches häufig benötigte Daten auf dem Webspace bei Strato im Dateisystem ablegt, um diese nicht jedesmal neu übertragen zu müssen. Zumal sich viele Daten, z.B. die Artikel und Seiten normalerweise eh nicht ändern.

Nun werde ich das Alles mal weiter beobachten, wie das mit den Ladezeiten so aussieht und hoffe aber trotzdem, das Strato die Datenbankaussetzer in den Griff bekommt.

Keine Kommentare »