Für mich war das lange Zeit nichts Besonderes und eher Normalität. Wenn ich Bilder mit Wordpress hochlade, wird von der Medienverwaltung ein kleines Vorschaubild, ein Thumbnail erstellt. Das binde ich dann als sichtbares Bild in den Artikel ein und mit einem Klick auf dieses Bildchen wird dann direkt das große Bild angezeigt.

Bei der Bildersuche tauchten die Thumbnails normalerweise gar nicht auf. Wenn Google die Bilder des Artikels in den Index aufnahm, waren es fast immer die richtigen Originalbilder. Ein paar wenige Ausnahmen gab es zwar, über die machte ich mir allerdings keine weiteren Gedanken.

Beim TagSEOBlog gab es vor einigen Tagen eine kleine Umfrage zur Anzahl der Bilder in der Bildersuche. Am Ende schreibt Martin da folgendes:

Früher hat Google stets die Thumbnails bevorzugt

Und weiter unten in einem Kommantar:

Ich habe das jetzt noch mal genauer geprüft… Bei mir werden doch stets beide Versionen indexiert und bleiben auch dauerhaft im Google-Bilderindex.

Das machte mich stutzig, denn ich habe bisher eher Gegenteiliges beobachtet. Oft erscheinen meine kleinen Bilder gar nicht im Index, manchmal nur, wenn Google nicht schnell genug die großen Bilder verarbeiten kann. Kommt das große Bild in den Index, verschwindet das kleine und wird bestenfalls nur bei konkreter Suche nach der Thumbnail-Größe von t.B. 160×120 angezeigt.

Aktuell konnte ich das gut bei Putzlowitsch mit dem Penne-Bild beobachten. Vor ein paar Tagen kam das Thumbnail in den Index und vorgestern die großen Bilder. Zwischenzeitlich springt dann die Anzeige hin und her (siehe oben).

Dann habe ich mir gezielt die Thumbnails für putzlowitsch.de angesehen, die Google im Bilderindex hat. Dabei fiel mir auf, daß das überwiegend Bilder sind, bei denen ich ausnahmsweise nicht direkt auf das Bild, sondern auf eine extra Seite mit dem Bild verlinke.

Bei TagSEOBlog werden übrigens die Thumbnails normalerweise nie direkt auf ein Bild verlinkt. Entweder geht der Link zum Artikel, in die Bildergalerie oder es wird gar nicht verlinkt. Auch bei bahnbilder.de, wo ebenfalls sehr viele Thumbnails im Index sind, zeigen die Links von den Vorschaubildern nie direkt auf ein Bild, sondern immer auf eine Seite.

Daraus ergib sich für mich die Schlußfolgerung, daß Google immer dann das Thumbnail gar nicht erst in den Index aufnimmt oder später wieder entfernt, wenn das kleine Bild direkt auf ein größeres Bild zeigt. Google geht wohl davon aus, daß das kleine Bild nur ein Vorschaubild ist, auch ohne das inhaltlich zu bewerten oder abzugleichen.

Oder anderes herum gesagt, ein kleines Bildchen, was überhaupt nicht oder auf eine Webseite linkt, hat eine deutlich höhere Chance im Google-Bilderindex zu überleben.

Mein ursprüngliches Ziel mit diesem Schurpsel-Blog hier ist schnell benannt. Ich konnte das ewige Rumgenörgel im Wordpress-Deutschland-Forum bezüglich Wordpress und Starto nicht mehr hören (lesen). Also habe ich ein Hostingpaket bei Strato bestellt um selbst zu sehen, was an den ganzen Kritiken dran ist.

Probleme und Lösungen

Ja, die meisten Kritikpunkte am Stratohosting des Sommers 2007 waren durchaus berechtigt. Das für die Permalinks notwendige mod_rewrite war nicht verfügbar, der PHP-Speicher mit 8MB recht knapp bemessen, durch eine fehlerhafte Server-Konfiguration wurden Endlosschleifen produziert und die gesamte Performance der Webseiten war nicht gerade berauschend.

Im Großen und Ganzen habe ich mein Ziel erreicht. Durch Plugins, Konfigurationseinstellungen und Hacks habe ich Wordpress auch beim Strato-Webhosting zufriedenstellen zum Laufen bekommen, auch mit Permalinks und ohne Endlosschleife. Eigentlich wäre das der Zeitpunkt gewesen, die Blogaktivitäten hier bei schnurpsel.de einzustellen.

Aber wie das so ist, es tauchen neue Probleme auf und auch so ganz allgemein ist ein Zweitblog zum Testen und Probieren ganz praktisch.

Kurzfristige Nahziele

Wenn SEO-Wettbewerbe laufen, wie aktuell das iPhone4Spiel, dann möchte ich mit meinem Schnurpsel-Test-und-Probierblog natürlich so weit wie möglich nach vorne kommen, am besten auf Platz 1. Allerdings investiere ich nicht wirklich viel in solche Aktionen. Ich registriere keine Keyword-Domain, befülle nicht 100 Blogs mit automatischen Texten und kippe auch nicht täglich “Pressemeldungen” in News-Portalen ab. Insofern habe ich da auch kaum eine Chance, aber es gibt doch immer wieder Interessantes zu beobachten. Ich freue mich auch immer über nofollow-Links als Dankeschön oder Quellenangabe.

Außerdem will ich immer der Erste mit einer Meldung sein, wenn es wichtige Neuerungen bei Google und dort speziell bei der Bildersuche gibt. Manchmal schaffe ich das sogar, wie beim geheimen imagesite-Paramter. :-)

Langfristige Fernziele

Ich will auch in Zukunft den leidgeplagten Wordpress-bei-Strato (1&1, Host-Europe, All-Inkl) Nutzern mit Rat und Tat zur Seite stehen. Dazu muß ich natürlich mit den relevanten Suchbegriffen bei Google gefunden werden. Als kann das Fernziel nur lauten. Platz 1 bei Google. :-)

Durch Permalinks bekommen Artikel und Seiten lesbare URLs und auch Struktur. Alle Artikel in der Kategorie ‘Wordpess’ können mit schnurpsel.de/themen/wordpress/ aufgerufen werden, das Monatsarchiv für Juli 2010 mit schnurpsel.de/date/2010/07/.

Auf dem Webserver existiert aber kein Verzeichnis /themen/wordpress/ oder /date/2010/07/. Damit die Seiten trotzdem aufgerufen werden können, erstellt Wordpress eine einfache Regel für das Rewrite-Modul des Apache-Webservers:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

Diese drei Zeilen führen dazu, das alles, was nicht tatsächlich als Datei oder Verzeichnis auf dem Server existiert, einfach an die index.php von Wordpress durchgereicht wird. Wordpress kümmert sich nun darum, ob es z.B. eine Kategorie “Wordpress” gibt, stellt die Liste mit den passenden Artikeln zusammen un gibt sie aus.

Was es alles nicht gibt

Im Moment sind wohl mal wieder ein paar Bots oder Skriptkiddies unterwegs, die einfach versuchen, irgendwelche php-Skripte aufzurufen, um mögliche Sicherheitslücken ausnutzen zu können. Das sieht dann etwa so aus:

/scripts/setup.php
/pma/scripts/setup.php
/phpMyAdmin/scripts/setup.php
/phpmyadmin/scripts/setup.php
/myadmin/scripts/setup.php

Solche Dateien gibt es hier allerdings nicht. Auch andere Sachen können zu fehlerhaften Aufrufen führen, z.B. Standard-Icons wie favicon.ico oder apple-touch-icon.png, die manche Browser einfach aufrufen oder durch Nutzer aus der Bildersuche falsch kopierte BILd-URLs.

Durch die für die Permalinks notwendigen mod_rewrite-Regeln werden alle dies Aufrufe nun an Wordpress weitergeleitet. Wordpress wird geladen, stellt eine Datenbankverbingung her, klappert die internene Rewriteregeln ab um schließlich nur festzustellen, daß es mit dem Aufruf nichts anfangen kann. Dann gibt Wordpress schließlich auch nur eine Fehlerseite aus, die möglicherweise auch noch aufwändig gestaltet ist und unnötig viel Daten als Antwort zurücküberträgt.

Wordpress und den Webserver entlasten

Damit nun nicht Wordpress wegen jeder Kleinigkeit behelligt werden, kann man eine spezielle Regel der Wordpress-Regel vorschalten, die einfach gegebenfalls die Abarbeitung der Rewrite-Regeln beendet:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule \.[^\.]+$ - [L]
</IfModule>

Die Idee dabei ist, daß alle Permalink-URLs normalerweise keine Dateierweiterung wie .html, .jpg oder .php haben. Falls nun eine Datei nicht existiert (RewriteCond) und diese Datei mit einem Punkt und mindestens einem weiteren Zeichen endet, wird die Abarbeitung der Regeln an dieser Stelle beendet (RewriteRule). Diese Zeilen müssen vor den Wordpress-Regeln stehen.

Wordpress bekommt diese Aufrufe nicht mehr zu sehen, der Fehler wird einfach vom Webserver behandelt. Hier kommt dann auch eine konfigurierte und vorhanden benutzerdefinierte Fehlerseite zu Anwendung.

Ich weiß, es gibt auch Blogger, die aus welchen Gründen auch immer, die Permalinks mit einem abschließenden .html konfiguriert haben. Aber auch das ist kein Problem, es muß nur eine Zeile hinzugefügt werden, welche die Regel für die Endung .html (oder eine andere) ungültig macht:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI}	!\.html$
RewriteRule \.[^\.]+$ - [L]
</IfModule>

Optimierte Version

Mann kann die zusätzlichen Bedingungen auch direkt in die Wordpress-Rules einfügen. Nachteil hierbei ist aber, daß sie bei Änderungen an den Permalinkeinstellungen verloren gehen, weil Wordpress den Block zwischen # BEGIN WordPress und # END WordPress neu schreibt:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI}	!\.[^\.]+$
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Die Version mit Endung .html:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI}	!\.[^\.]+$ [OR]
RewriteCond %{REQUEST_URI}	\.html$
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Plugin-Version

Angeregt durch die Kommentare von Ralf habe ich nun eine Plugin-Version fertig gestellt.

Download: 123 Rewrite Error 0.10

Das Plugin schreibt die Regeln beim Aktivieren, Deaktivieren und bei Änderungen an der Permalinkstruktur wie bei der Optimierten Version beschrieben automtisch mit den Wordpress-RewriteRules in die .htaccess. Dabei wird auch gleich berücksichtigt, ob in der Permalinkstruktur eine Erweiterung wie .html angegeben wurde.

Fazit

Wieviel Serverlast oder Traffic durch diese Maßnahme eingespart wird, kann ich nicht sagen. Das hängt sicher auch vom Nutzungsprofil und der Konfiguration der Website ab. Aber warum sollte man solch eine einfache Möglichkeiten auslassen, um Wordpress und dem Webserver das Leben ein bißchen leichter zu machen.

“Wir finden Googles neue Bildersuche echt gelungen! Toll!!!” (reproscan)
“Die neue Bilder-Suche von Google fetzt ja voll. :P” (Maybach)
“Google hat die Bildersuche schöner gemacht…” (rjoerges)
“… cooler Ansatz, macht auf jeden Fall mehr Spaß” (visu)
“Woow…die neue Google Bilder suche ist cool. Sehr schick!” (thedrayman)
“mir gefällt die neue #google bildersuche” (mcnesium)

Klar, das ist natürlich immer alles sehr subjektiv und viele Neuerungen benötigen eine längere Eingewöhungsphase. Man hängt nun mal oft an den altebekannten Sachen.

Wenn ich da z.B. noch an den Wechsel bei Wordpess vom horizontalen Menü oben zum vertikalen Menü links denke.
Was ging damals für ein Aufschrei durch die Wordpress-Nutzerschaft, wie man denn nur sowas machen könne. Heute will wohl keiner mehr das alte “Design” zurückhaben.

Ich hoffe mal, daß Google bei der Bildersuche noch nachbessert und zumindest ein paar Darstellungsoptionen anbietet. Eventuell kann man sich auch mit einem älteren Browser oder deaktiviertem Javascript behelfen, um noch eine Weile die alte Ansicht zu bekommen.

Das funktioniert auch für Attachments wie Bilder, Sounds und sonstige Dateien, die über Wordpress hochgeladen und mit der Mediathek verwaltet werden. Allerdings wird hier nicht auf die Datei selbst, sondern auf die Attachment-Seite weitergeleitet (putzlowitsch.de/?p=1650).

Um nun auch direkt auf Dateien shortlinken zu können, sind nur ein paar Zeilen PHP-Code notwendig. Ich habe dafür als Alternative zum Parameter p wie Post den neuen Parameter a wie Attachment eingeführt. Der Aufruf erfolgt dann mit putzlowitsch.de/?a=1650. Die Funktionen habe ich in ein kleines Plugin gepackt, wem zu viele Plugins nicht gefallen, kann auch einfach den Quelltext in der Datei functions.php seines Themes einfügen:

function plw123as_redirect_canonical( $redirect_url, $requested_url ) {
	global $wp_query;

	if( isset($wp_query->query_vars['a']) ) {
		$id = intval( $wp_query->query_vars['a'] );
		$url = wp_get_attachment_url( $id );
		if( '' == $url ) {
			$wp_query->set_404();
			status_header( 404 );
			$redirect_url = false;
		}
		else
			$redirect_url = $url;
	}
	return $redirect_url;
}

function plw123as_init() {
 global $wp;

 // Variable bekannt machen
 $wp->add_query_var( 'a' );
 add_filter( 'redirect_canonical', 'plw123as_redirect_canonical', 10, 2 );
}
add_action( 'init', 'plw123as_init' );

 
Download: 123 Attachment Shortlink 0.10

Ich wurde übrigens so ein bißchen von der Statusupdate mit Bildern-Sache zu diesem kleinen PHP-Code angeregt. Kann ja nicht sein, das ich für direkte Links auf Bilder elendig lange URLs verwenden muß. :-)

Nachtrag 16:30 Uhr

Leider wertet die Googlesuche nach Statusupdates eine Weiterleitung auf ein Bild nicht als Bild selbst. Die Bild-URL wird zwar aufgelöst, das Bild aber nicht angezeigt. Schade! Vielleicht ändert sich das ja noch…

Nachtrag 17:45 Uhr
Hmmm, scheint doch mit den weitergeleiteten Bildern bei Google-Statusupdates zu funktionieren, aber nicht immer oder nur manchmal, keine Ahnung…

Eine verweis-sensitive Grafik (Image Map) ermöglicht es dem Webdesigner nicht nur ein komplettes Bild mit einem Link zu verknüpfen, sondern Teilbereiche des Bildes anklickbar zu machen und mit unterschiedlichen Links zu hinterlegen. Damit bringt es ihm und den Seitenbesuchern schon mal einen Mehrwert an Gestaltungs- bzw. Auswahlmöglichkeiten.

Links im Map für Suchmaschinen interessant?

Es stellt sich mir jedoch die Frage, und diese möchte ich hiermit an Kundige weitergeben, ob die Suchmaschinen diese Links in Maps überhaupt erfassen, berücksichtigen und werten. Ich weiß es ehrlich gesagt nicht. Man könnte nun mal wieder ein Experiment starten, aber vielleicht kennt sich damit ja einer meiner Leser aus und es ist kein großes Geheimnis.

Interessant ist auch die Frage, wie Image-Map und Image aus Sicht der Suchmaschine zusammenwirken. Werden die Alt- bzw. Titeltexte vom Map an das Bild und umgekehrt “vererbt”? Was passiert, wenn ein map quasi unbenutzt in der Luft hängt, also gar nicht von einem Bild mit usemap referenziert wird? Falls das keine Rolle spielt, könnte man damit ja schöne, unsichtbare Linklisten erzeugen. :-)

iPhone4Spiel Top-Ten jetzt anklickbar

Die iPhone4Spiel Top-10-Grafiken sind jetzt per Image-Map anklickbar geworden. Bei der normalen Top-Ten führt der Klick natürlich zur Seite selbst. Bei der Bilder-Top-Ten werden aber nicht die Bilder selbst verlinkt, sondern die Zielseiten, von denen sie referenziert, also wo sie angezeigt werde.

Was bringt das nun? Nicht wirklich viel, aber ich wollte einfach die “programmtechnische Herausforderung” meistern, zu einem dynamisch generierten Bild auch eine dynamisch generierte Image-Map zu erstellen. :-)

Brötchen mit WP 3.0 RC als Test

Seit ein paar Wochen habe ich die RC-Versionen von Wordpress 3.0 bereits für meine Brötchen-Bilder im Testbetrieb zu laufen. Dabei gab es keine Probleme.

Für meine “Produktions-Systeme” Putzlowitsch und Schnurpsel will ich aber nicht gleich auf WP 3.0 umsteigen, das ist mir zu heikel. Da stehen zunächst lokale Tests an.

Automatisches Update bei 1&1 erfolgreich

Mit einer Wordpress 2.9.1 Testinstallation bei 1&1 habe ich hingegen gleich mal ein automatisches Update angestoßen. Das hat einwandfrei funktioniert. Allerdings habe ich dort nur eine handvoll einfacher Plugins aus eigenem Hause installiert. Insofern ist das kein echter Produktionstest.

Der (angezeigte) Speicherbedarf ist von 11,5 auf 13,5 MB im Frontend und von 14 auf 16,5 MB im Backend angestiegen, mithin also um 2 bzw. 2,5 MB. Insgesamt kommt man mit den 32 MB, die bei 1&1 zur Verfügung stehen, noch ganz gut über die Runden. Eng kann es bei gleichzeitigen Einsatz vieler Plugin oder bei Upload großer Bilder werde.

Generell sollte man für Wordpress bei 1&1 (Shared Webhosting) einige Dinge beachten.

Das scheint aber nicht der Fall zu sein, denn in WP 3.0 RC1 wird die my-hacks.php weiterhin geladen, sofern sie aktiviert ist. Damit ist gewährleistet, daß nicht plötzlich nach dem Update wichtige Funktionen ausgesperrt werden, die möglicherweise in der my-hacks.php stehen.

Allerdings kann man nach einer Neuinstalltion die my-hacks-Erweiterung nicht mehr im Backend aktivieren. Dafür müßte man direkt in der Datenbank rumfummeln oder man verwendet das “123 Hackfile Option”-Plugin:

Download: Plugin 123 Hackfile Option 0.12

Die Option dafür erscheint nun allerdings nicht mehr bei Einstellungen->Verschiedenes (gibt es nicht mehr), sondern ganz am Ende von Einstellungen->Allgemein.

Sie sind zwar nur noch selten anzutreffen, halten sich aber hartnäckig, die Javascript-Rechtsklicksperren. Dabei sind sie praktisch wirkungslos, nur noch absolute Computerlaien lassen sich damit verblüffen. Und dann will da jemand auch noch Sachen damit “schützen”, die er selbst nur von einer anderen Seite “geklaut” hat. *tststs*

Eine neue Wordpressinstallation enthält üblicherweise bereits ein paar Beispieldaten. So sind schon eine Seite und ein Artikel mit einem Kommentar vorhanden, etwa wie dieser hier. Die Blogrolle ist auch schon mit ein paar Links gefüllt.

Wenn man das nicht möchte, weil man beispielsweise einen Wordpress-Export (per WP-Export als xml) importieren möchte und die IDs der Artikel und Seiten erhalten bleiben sollen, kann man eine benutzerdefinierte Installation verwenden.

Wordpress lädt am Anfang der Installation die Datei wp-content/install.php, falls sie vorhanden ist. In dieser kann man einige Installationsfunktionen “überschreiben”. Das funktioniert so wie bei den Funktionen aus der pluggable.php im Verzeichnis wp-includes. Wordpress prüft, ob eine Funktion bereits vorhanden ist:

if ( !function_exists('wp_install') ) :
 ...
endif;

Falls nicht, wird die Wordpress-Funktion “installiert”, andernfalls wird die bereits vorhandene verwendet. Die wordpresseigenen Installationsfunktionen findet man in wp-admin/includes/upgrade.php, diese kann man sich als Vorlage für eigene Modifikationen hernehmen.

Wordpress ohne “Hallo Welt”

Um nun eine leere Wordpress-Installation zu erhalten, wird die Funktion wp_install_defaults in der Datei wp-content/install.php neu definiert:

<?php
function wp_install_defaults($user_id) {
}
?>

Es ist einfach eine leere Funktion, dadurch wird aber auch keine Default-Kategorie für Artikel und Links erstellt. Möchte man die Standardkategorien trotzdem haben, nimmt man den oberen Teil aus der originalen WP-Funktion (bis // Now drop in some default links) in die eigene Funktion mit rein. Dabei das global $wpdb nicht vergessen.

Wie man auf diese Weise bereits Plugins bei der Installation aktivieren kann, hatte ich früher schon mal beschrieben.

Nachdem die Anpassungen in der install.php vorgenommen wurden und diese in das Wordpress-Content-Verzeichnis kopiert wurde, kann man die Wordpressinstallation wie gewohnt starten.

xyz.amazonaws.com  /2007/01/09/spam-spammiger-am-spammigsten
xyz.amazonaws.com  /2007/01/09/spam-spammiger-am-spammigsten/
xyz.amazonaws.com  /wp-comments-post.php
xyz.casema.nl      /wp-comments-post.php
xyz.slicehost.net  /wp-comments-post.php

Erst kommt so ein Hansel vorbei und ruft eine Seite mit der falschen URL (ohne abschließendem Slash) auf. Dann wird er auf die richtige URL weitergeleitet und versucht einen “Kommentar” abzusetzen. Gleich danach kommen noch zwei Spam-Bot-Kollegen und versuchen dasselbe. Als User-Agent steht immer “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)” drin.

Inhaltlich habe die nicht wirklich was zu bieten, es scheint eher nur ein Test zu sein, ob die Kommentare entgegengenommen werden und wie Links eingefügt werden können. So in etwa sehen die Kommentare aus:

EBuBBk
<a href=\"http://swdjxdiycbec.com/\">swdjxdiycbec</a>,
[url=http://ndnoaqhxujvg.com/]ndnoaqhxujvg[/url],
[link=http://krperquplewf.com/]krperquplewf[/link], 

http://keejyaqvdysc.com/

Angefangen hat es kurz nach 9 Uhr. Bisher sind gut 300 Spam-Versuche aufgeschlagen, also etwa 100 Zugriffe des obigen Verhaltensmusters. Nur gut, daß dieser Spam-Quark schon an der Türe abgewiesen wird und erst gar nicht in die Spam- oder Moderationsliste von Wordpress gelangt.

Ich befürchte, die Bots geben erst Ruhe, wenn sie alle ca. 750 Artikel bei Putzlowitsch abgegrast haben. Und dann komme sie womöglich noch hierher zu Schnurpsel. Hoffentlich merken die bald mal, daß sie dort wie auch hier keine Chance haben, ihren Spam loszuwerden.

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' );
?>

Pro Tag gecrawlte Seiten

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

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)

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.

Die Diskussion taucht immer wieder mal auf, wie sieht optimalerweise ein Permalink, also die Struktur der URL aus. Sollten das Datum oder die Artikel-ID enthalten sein, ist es sinnvoll Kategorien oder Tags mit aufzunehmen?

Eine allgemeingültige und endgültige Empfehlung kann es nicht geben, wenn man die unterschiedlichen Sichtweisen dazu berücksichtigt, die dann zu eher widersprüchliche Aussagen führen.

Betreibt man ein Blog im Sinne eines Tagebuches, ist sicher das Datum oder Bestandteile davon eine gute Wahl. Aus SEO-Gesichtspunkten bzw. für eine eher thematische Ausrichtung wird oft die Kategorie mit in die Permalinkstruktur aufgenommen. Für eine Webseite mit vielen Schreibern könnte auch der Autorenname eine geeignete Option sein.

Ich habe mir einfach mal die Permalink-Struktur der 33 deutschen Top-Blogs angesehen. Vielleicht läßt sich ja daraus eine Empfehlung ableiten.

Die Permalink-Struktur der 33 deutschen Top-Blogs

Zunächst stellt sich natürlich die Frage, welche sind denn die Top-Blogs in Deutschland? Auch hier kann man sich endlos streiten, wenn man will. Ich habe als erste Näherung einfach die aktuell zusammengerechnete Liste von heute, dem 24.02.2010, genommen. Die Permalinkstruktur habe ich in Gruppen zusammengefaßt, vor dem jeweiligen Blog steht der aktuelle Platz in der Top-33-Liste :

• Jahr, Monat, Tag und Artikelname (13)
  • 2. netzwertig.com
  • 3. Nerdcore
  • 4. Basic Thinking Blog
  • 10. Spreeblick
  • 12. Werbeblogger
  • 13. GoogleWatchBlog
  • 18. Die Fünf Filmfreunde
  • 19. Netzökonom (vorangstelltes ‘archive’)
  • 22. WordPress Deutschland Blog
  • 23. Lummaland
  • 25. MACNOTES.DE
  • 29. law blog (vorangstelltes ‘archives’)
  • 32. allesaussersport (vorangstelltes ‘archiv’)
• Jahr, Monat und Artikelname (5)
  • 11. Internet-Law
  • 15. Les Mads
  • 17. fscklog
  • 24. Indiskretion Ehrensache
  • 27. Alles Schall und Rauch
• Jahr und Artikelname (1)
  • 6. netzpolitik.org
• Artikelname (6)
  • 1. Stefan Niggemeier
  • 8. Caschys Blog
  • 16. Ruhrbarone
  • 30. 1x umrühren bitte (vorangstelltes ’stories’)
  • 31. Design Tagebuch
  • 33. Druckerei Blog
• Nummer und Artikelname (3)
  • 7. CARTA
  • 9. BILDblog
  • 20. UPLOAD Blog
• Artikelname und Nummer (1)
  • 5. StyleSpion
• Sonderformen (1)
  • 28. Elektrischer Reporter Kategorie (video) ? und Nummer
• Keine Permalink, Nummer als URL-Parameter (3)
  • 14. NachDenkSeiten
  • 21. MC Winkels weBlog
  • 26. Fefes Blog

Mehr als die Hälfte (57,6%) der Top-33-Blogs verwendet neben dem Artikelnamen das Datum oder einen Bestandteil davon in der URL. Bei allein fast 40% findet man das komplette Datum mit Jahr, Monat und Tag im Permalink. Gut 18% benutzen nur den Namen des Artikels als Permalink und weitere etwa 12% kombinieren dazu noch eine Nummer (Artikel-ID). Immerhin knapp 10% der Top-Blogs verwenden keine Permalinks, sondern setzen auf die Artikelnummer als URL-Parameter (?id=1234).

Erste Ableitung des Permalink-Aufbaus

Wenn man Permalinks verwendet, ist der Artikelname (in seiner Umwandlung zu einem URL-Pfad) gewissermaßen eine feste Größe. Die Einbeziehung des Datums oder von Teilen kann so schlecht nicht sein, diese Verwendet ein Großteil der Top-Blogs. Auch ganz auf Permalinks zu verzichten, hat gewisse Vorteile. Die URLs sind kurz und bleiben immer gültig, auch wenn man mal was am Artikel-Titel, dem Datum oder sonstigen Einflußfaktoren ändert.

Ich habe mir stichprobenartig noch weitere Blogs der Top-100 angesehen und zumindest keine Seite entdeckt, die etwa die Kategorie oder gar Tags in der URL verwendet. Mal davon abgesehen, daß Tags bei Wordpress bis zur Version 2.9.x nicht als Bestandteil der Permalinks funktionieren (obwohl in der Dokumentation genannt), gibt es auch noch andere Probleme.

Kategorie oder Tag im Permalink

In Wordpress kann man Artikel in mehreren Kategorien ablegen. Einem Artikel können zudem auch mehrere Tags zugeordnet werden. Verwendet man Kategorien oder Tags in Permalinks, erstellt Wordpress die die URL aus der Kategorie oder dem Tag mit der kleinsten ID. Ändert man nun die Kategoriezuordnung oder die Tags, kann sich möglicherweise auch die URL ändern.

Das ist aber erstmal nicht weiter schlimm, denn der Artikel wird auch weiterhin mit der alten Kategorie gefunden und angezeigt. Wordpress geht sogar soweit, einfach die Kategorie beim Auflösen der Permalinks zu ignorieren. Damit ergeben sich dann theoretisch beliebig viele URLs für einen Artikel.

Als Beispiel ist das auf meinem Testblog zu sehen. Die Permalink-Struktur sieht so aus:

/%category%/%postname%/

Der Artikel ist in der Kategorie “Allgemein” einsortiert, die URL sieht so aus:
http://testblog.schnurpsel.de/allgemein/hallo-welt/

Er ist aber auch mit der Kategorie “Blafasel”, “Hundekuchen” oder “Gibtesnicht” aufrufbar:
http://testblog.schnurpsel.de/blafasel/hallo-welt/
http://testblog.schnurpsel.de/hundekuchen/hallo-welt/
http://testblog.schnurpsel.de/gibtesnicht/hallo-welt/
Genau, diese Kategorien gibt es gar nicht.

Man hat damit potentiell also ganz viel bösen “Duplicate content” (DC). Da sage noch einer, die Kategorie im Permalink sei unter SEO-Gesichtspunkten empfehlenswert. ;-)

Permalink, so oder so

Letztendlich muß jeder selbst entscheiden, ob und wie er seine Permalinks gestaltet. Bei Putzlowitsch habe ich mich für das Datum entschieden, da ich dort eher im Sinne eines Tagebuchs schreibe. Hier verwende ich eine Kombination aus Artikelname und Artikel-ID, weil die sichtbare ID schnelle interne Links mit dem 123 IntLink-Plugin ermöglicht. Bei Twitter verwende ich übrigens gerne die WP-Shortlinks mit der ID als URL-Parameter, die sind schön kurz und funktionieren auch ohne Shortlink-Dienst.

Mit jeder neuen Wordpress-Version gab es meist neue Funktionen, manchmal war eine neue Ausgabe aber auch nur ein Sicherheits-Release, um bekannt gewordene Sicherheitslöcher zu stopfen. Damit sind Sicherheitslücken und deren Ausnutzbarkeit immer von der Wordpress-Version abhängig, wodurch die Versions-Information für einen Angreifer durchaus interessant ist.

Die Wordpress-Versionsnummer anzeigen

Wordpress liefert in der Standardinstallation die Versionsinformationen gleich an drei Stellen mit. Zwar sind diese für den normalen Besucher üblicherweise nicht sichtbar, aber in der Seite vorhanden.

Im Header der Seite
Wen man sich den HTML-Quelltext einer Seite ansieht, findet man dort möglicherweise im Header einen Eintrag wie <meta name=”generator” content=”WordPress 2.9.1″ />

Im Feed
Wen man sich den XML-Quelltext eines Feeds (RSS, Atom) ansieht, findet man dort möglicherweise am Anfang (channel) einen Eintrag wie <generator>http://wordpress.org/?v=2.9.1</generator>

In der readme.html
Mit jeder Wordpress-Version wird eine Datei readme.html und in der deutschen Version auch liesmich.html mitgeliefert bzw. installiert. Diese findet man im Wordpress-Wurzelverzeichnis. Da steht die Wordpress-Version ebenso drin:

Wordpress-Version verbergen

Man mag darüber streiten, ob es sinnvoll ist, die Versionsnummer vor Bots oder wem auch immer zu verbergen. Für die Unterdrückung der Ausgabe in den Seiten und Feeds gibt es diverse Lösungen. Wenn man nun aber so großen Wert darauf legt, die WP-Version zu verstecken, sollte man unbedingt auch die readme.html (liesmich.html) löschen. Aber Achtung, beim nächtens (automatischen) Update ist sie wieder da.

Da kommt mir so ein Experiment mit Bilderdateinamen wie Mohakenox gerade recht. Denn oder gerade weil noch keine Testbilder in der Bildersuche zu finden sind, bleibt genug Spielraum für die Betrachtung anderer Bilder. Wurden vor einigen Tagen noch vorwiegend hunderte Bilder von prometeo gefunden, sind diese fast alle wieder verschwunden.

Dafür machen sich jetzt Schnurpsel-Bilder breit, wie z.B. auf der zweiten Trefferseite. Dort findet man auch ein Brötchen. Das ist allerdings kein Schnurpsel-Brötchen, sondern ein Putzlowitsch-Brötchen, welches derzeit auf Platz 4 der Bildersuche zum Stichwort Brötchen zu finden ist. Auf dem ersten Platz liegt immer noch das häßliche MKB-Brötchen, aber bereits auf Platz 2 folgt ein SEO-Brötchen.

Es gibt aber nicht nur Brötchenfotos, sondern auch Brötchen-Grafiken. Die findet man aber erst auf der zweiten Trefferseite. Bisher haben allerdings alle Brötchen-SEO-Maßnahmen noch nicht ausgereicht, um den begehrten 1. Platz zu erreichen. Auf die erste Trefferseite zu kommen, ist nicht besonders schwer. Aber am ersten Platz beißen sich bisher alle die Zähne aus, das Brötchen da ist einfach zu hart und vertrocknet.

Es gab zwar mal zeitweise einige Verschiebungen auch mit der Top-Position, die aber leider nicht von großer Nachhaltigkeit geprägt waren. So muß ich resümieren, daß Brötchen-SEO auch mit einem SEO-Brötchen derzeit noch brotlose Kunst ist.

Bananen und Orange