Das Putzlowitsch Test- und SEO-Blog

Google-Bildersuche dynamisch und schnell wie nie zuvor

Schnell wie der Wind

Google-Bildersuche: Laufschuhe schnell im IndexEines muß man Google ja lassen, die Bildersuche ist so dynamisch und schnell wie nie zuvor.

Das gestern veröffentlichte Bild meiner neuen Asics-Treter ist schon heute in der Bildersuche zu finden, zur Suchphrase GT-2150 G-TX sogar auf der ersten Seite.

Googlebot-Image im Weihnachtsurlaub?

Allerdings war ich in den letzen Tagen schon etwas beunruhigt, weil seit etwa zwei Wochen der Googlebot-Image, welcher für die Bilder zuständig ist, hier bei Schnurpsel überhaupt nicht mehr zugange war.

Ein Blick auf die Bot-Statistik zeigt aber, daß wohl der normale Googlebot die Aufgaben des Image-Bots mit übernommen hat. Dieser hat in den letzten zwei Wochen 33 mal Bilder von schnurpsel.de abgerufen. Das ist nicht gerade viel, aber besser als gar nichts.

Auch bei Putzlowitsch sind die Bilderabfragen durch den Google-Bot eher bescheiden. Der Image-Bot war gut 60 mal da, der normale Bot hat reichlich 140 Bilder abgefragt. Das sind gerade mal ca. 15 Bilder am Tag, da gab es schon bessere Zeiten mit 50 bis 80 Bildern täglich. Aber gut, da will ich mal vom Bot über die Feiertage nicht zu viel verlangen. :-)

Viel und noch mehr, alt wie neu

Seit Anfang März zeichne für meine Hauptblogs die Ergebnisse der imagesite-Abfragen (seit August simuliert durch eine inurl-Abfrage) täglich auf. Die Lücken in den Kurven des Diagramms sind durch „Meßfehler“ bedingt.

Google-Bildersuche: Anzahl der Treffer für site-Abfrage

Kleinere Aufwärtsbewegungen sind Anfang April, Anfang Mai und Ende Juli zu erkennen. Einige Bewegung gab es Anfang/Mitte September, bis dann im Oktober die Zahlen deutlich zurück gingen. Der Verlust wurde im November und Anfang Dezember wieder ausgeglichen. Die Bewegungen passen zeitlich recht gut zu den Image-Updates, welche Martin vom TagSEOBlog sehr schön visualisiert hat.

Ab Mitte Dezember stieg die Anzahl der Bilder abermals deutlich an. Das sind bei Schnurpsel und Putzlowitsch jeweils mehr als 100 Bilder. Da ich in diesem Zeitraum bei weitem keine hundert neuen Bilder veröffentlicht habe, wurde hier offensichtlich ein größerer Teil älterer Bilder in den Index übernommen. Das sind teilweise auch Bilder, die früher schon im Index waren und wieder rausgeflogen sind (warum auch immer).

Ente gut, alles gut

Ich war es nicht

In den letzten Tagen zeigt die Kurve zwar wieder etwas nach unten aber insgesamt hat die Google-Bildersuche richtig gut Fahrt aufgenommen. Da will ich mal hoffen, daß es keinen Rückfall in die schnarchigen 3-Monats-Image-Updates gibt.

3 Kommentare »

Plug and Play

Plugin 123 HTTP TransportDas mit den Plugins für WordPress ist ja wirklich eine feine Sache. Es gibt deren viele und sie leisten teilweise Dinge, von denen man gar nicht wußte, das man sie jemals gebrauchen könnte.

Ja, auch ich verwende Plugins. :-)

Das aktuelle Thema des Wabmasterfridays lautet „Welche WordPress-Plugins habt ihr aktiv im Einsatz?“ und so habe ich hier im Blog-Adminbereich einfach mal nachgeschaut. Es sind derzeit ganze 27 aktive Plugins, die ich jetzt aber nicht alle ausführlich vorstellen werde.

Der Grund ist einfach. Das hier ist mein Test- und Entwicklungsblog und so laufen da viele Sachen zu Testzwecken. Von den 27 Plúgins sind bis auf eines alles Eigenentwicklungen. Man erkennt sie an dem „123 Irgendwas“-Namen.

Fremde Plugins

Das einzige fremde Plugin ist DoFollow. Damit wird des nofollow-Attribut bei Links in Kommentaren entfernt. Das stellt aber keinen Freifahrtschein für jeden Mist dar. Erstkommentare werden moderiert und gegebenfalls Entlinkt oder Entfollowt.

Eigene Plugins

Viele Plugins sind nur kleine Helferlein, teilweise sogar ohne Optionenseite, manche bügeln nur Fehlkonfigurationen der Webhoster aus.

Ein paar haben aber schon einen etwas größeren Umfang und Nutzwert.

  • 123 IntLink
    IntLink zählt zu meinen ältesten Plugins und hat sogar Editor-Buttons. Mit dem Plugin kann man mit der Artikel-ID (bzw. Kommentar-ID) einfach auf bloginterne Artikel, Seiten oder auch Kommentar verlinken. Die Links werden erst zur Laufzeit generiert. Damit passen sie immer, egal ob man mal die Permalinks ändert oder mit dem ganzen Blog umzieht.
  • 123 Shrink Link
    Wer kennt das nicht, im Kommentar hinterläßt jemand einen monstermäßig langen Link, der dann weit nach rechts über den Rand hinausragt und das in mühsamer Arbeit erstellte Design zerstört. Mit Shrink-Link werden solche Links für die Anzeige gekürzt. Mit ein paar Optionen kann man das Kürzungsverhalten steuern.
  • 123 Homelink
    Lange Zeit war es in WordPress nur möglich einen Menüeintrag mit einem Link zur Startseite im Theme zu programmieren. Das Plugin ermöglicht das Hinzufügen des Startseiten Links im Backend, außerdem das Ein- und Ausblenden von Seiten aus dem Menü un das ändern der Menütexte.
    Seit WP 3.0 ist das alles mit den Benutzermenüs ja bereits fest eingebaut.
  • 123 Tools
    Das Plugin ist eine Art Sammelplugin für kleinere Funktionen, für die sich kein eigenes Plugin lohnen würde. Ein Werkzeugkasten halt. :-)

Dann gibt es noch mehrere nicht öffentliche Plugins, die ganz unterschiedliche Funktionen haben. Mit dem „123 Character Mixer“ kann man Buchstaben vertauschen, so daß eigenartig fremdsprachig anmutende Texte entstehen. Sehr wichtig ist mir das „123 Shortlink“-Plugin, damit kann ich per Artikel- oder Attachment-ID eine Weiterleitung auf den Artikel oder direkt auf ein Bild generieren. Das brauche ich z.B., wenn ich die Artikel oder Bilder in Twitter abkippen will. :-)

Apropos in Twitter abkippen, das werde ich jetzt auch gleich tun… :-)

2 Kommentare »

WordPress mit Permalinks – den Webserver entlasten

Wie WordPress Permalinks verarbeitet

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 und 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 /
RewriteRule ^index\.php$ - [L]
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 /
RewriteRule ^index\.php$ - [L]
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.

8 Kommentare »

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 »

Kabelsalat im Tarifdschungel

Kabel-Deutschland InternetSo richtig glücklich bin ich ja mit meinem DSL-6000-Anschluß (mit 3000er Geschwindigkeit) nicht. Das ist halt nicht besonders schnell, gerade im Upload sind 384 kBit/s mal eben kein Renner. Das schiele ich schon mal zu anderen, schnelleren Angeboten. Hin und wieder haben wird so eine Infopost von Kabel-Deutschland im Briefkasten, Kabelanschluß fürs Fernsehen haben wir hier sowieso schon.

Das Angebot „Paket Comfort“ liest sich gar nicht mal schlecht. Geboten werden bis zu 32 MBits/s im Down- und bis zu 2 MBit/s im Upstream als Internetflatrate, dazu noch eine Telefonflatrate ins deutsche Festnetzt (2 Leitungen, 2 Rufnummern). Die Mindestvertragslaufzeit beträgt 12 Monate und alles zusammen kostet 29,90 Euro im Monat, im ersten Jahr sogar nur € 22,90. So weit, so gut, nur brauche ich eigentlich keinen Telefonanschluß.

Aber es gibt ja noch das Paket „Flat Comfort“, praktisch die gleichen Parameter was die Geschwindigkeit angeht, allerdings ohne Telefonanschluß. Genau das richtige für einen Nur-Internet-Anschluß. Die Sache hat aber einen kleinen Haken, man spart damit keinen Cent. Der monatliche Preis beträgt genauso € 29,90 (im ersten Jahr nur 22,90), dafür ist aber die Mindestvertragslaufzeit 24 Monate.

Ein Super Angebot, weniger Leistung bei längerer Vertragslaufzeit zum selben Preis. Ich kenne mich ja so mit Verkauf und Marketing nicht aus, aber vielleicht hat ja so eine Angebots- und Preisgestaltung einen tieferen Sinn. Mir will sich das zumindest nicht erschließen.

Andererseits hoffe ich ja, das vielleicht doch irgendwann auch hier das DSL schneller wird, schließlich wohne ich nicht auf dem Lande, sondern in einer, wenn auch eher kleinen Landeshauptstadt. :-)

Keine Kommentare »