Schnurpsel 

1 Million iPhone4Spiel-Seiten, ein voller Erfolg?

Hoch- und Abrechnung

Gut, ich habe da etwas übertrieben. Es sind noch keine Millionen iPhone4Spiel-Seiten, Google “spricht” von ungefähr 925 Tausend Treffern. Aber auch Google übertreibt mit den 925000 Ergebnissen maßlos, wie man schnell merkt, wenn man sich mal in den SERPs bis zum Ende durchklickt.

Da ist bereits auf “Seite 36 von 353 Ergebnissen” das Ende der Fahnenstange erreicht. Gut, da steht ja noch der bekannte Hinweis:

Um Ihnen nur die treffendsten Ergebnisse anzuzeigen, wurden einige Einträge ausgelassen, die den 353 bereits angezeigten Treffern sehr ähnlich sind.

Aber auch mit filter=0 kommt man nur bis zur Seite 59, mithin sind es also etwa 600 Treffer, die Google tatsächlich präsentiert.

Nun frage ich mich, nicht zum ersten Mal, wie Google auf solche utopisch hohen Zahlen kommt. Selbst wenn es nicht nur 600, sondern sagen wir mal 9000 Seiten sind, wäre das immer noch ein Mißverhältnis von 1:100.

Vermutlich wird die ungefähre Ergebniszahl irgendwie hochgerechnet, aber wirklich brauchbar ist diese Rechnung nicht. Man stelle sich vor, bei der nächsten Bundestagswahl gibt es erste Hochrechnungen für die FDP von 50% und tatsächlich sind es dann aber nur 0,5%. :-)

Erfolg und Mißerfolg

Ob der “SEO-Wettbewerb” zum iPhone4Spiel nun ein Erfolg oder Mißerfolg ist, mag ich nicht beurteilen. Die Frage ist ja immer auch, woran wird Erfolg gemessen und wer hat etwas davon.

Für mich gibt das iPhone4Spiel immerhin etwas Schreibstoff her, ich habe mal wieder an den Ranking-Charts gearbeitet (und einen Fehler bemerkt) und ein paar Beobachtungen machen können. Insofern ist das iPhone4Spiel für mich ganz persönlich sowas wie ein kleiner Erfolg.

iPhone4Spiel-Diagramm mit Lücke

Mut zur Lücke, könnte man sagen, aber das war so nicht beabsichtigt. Vielleicht hat es ja einer der vielen Beobachter beim iPhone4Spiel-Diagramm schon bemerkt. Seit etwa einer Woche stimmt da was nicht. Es gibt seit dem 13. Juli eine datentechnische Lücke für Plätze großer als 10 bei der normalen Suche bzw. größer Platz 20 bei der Bildersuche. Da ist gewissermaßen ein Daten-Sommerloch entstanden.

Solche “Aussetzer” können zwar auch entstehen, wenn sich die Platzierung jenseits der 100 befindet, denn dort endet die Darstellung des Diagramms (nicht aber die Datenerfassung), aber eine so auffällige Lücke erschien mir doch verdächtig. Es ist recht unwahrscheinlich, wenn auch nicht ausgeschlossen, daß z.B. geld-im-internet mit seinem iPhone4Spiel-Beitrag der in letzter Zeit immer in den Top-20 war, plötzlich auf Plätze über 100 abfällt.

Was war passiert? Ich hole mir die Daten dirket aus den SERPs, parse also die HTML-Seite und extrahiere die Links und Positionen. Zudem habe ich eine Next-Page-Erkennung eingebaut um festzustellen, ob es von der aktuellen Seite aus gesehen jeweils noch eine weitere Ergebnisseite gibt. Genau diese Erkennung hatte versagt und nach der ersten Seite das Einlesen abgebrochen.

Ich habe die Funktion nun etwas robuster ausgelegt und hoffe, daß sie in Zukunft die weiteren Ergebnisseiten zuverlässig erkennt. Verlassen kann ich mich darauf aber leider nicht, also muß ich immer die Daten nach Auffälligkeiten im Auge behalten.

Referertrick – Referer-Spam mit System

Referer-Spam ist ja nichts Neues, dazu habe ich schon vor einiger Zeit etwas geschrieben.

Gefälschter Referer -> Spam

Der Referer wird normalerweise beim Aufruf einer Seite vom Web-Browser des Benutzers an den Webserver im sogenannten HTTP-Request mitgeschickt, kann aber ebenso fehlen oder sonst irgendwie verändert sein. Da diese Information beliebig gesetzt werden kann, ist nicht gewährleistet, das sie auch stimmt. Genau solche “gefälschten” Referer machen sich Spammer zu Nutze und setzen den Refefer auf eine Seite, von der gar kein Link auf die aufgerufene Seite zeigt.

Spamziel -> Neugierige Webmaster und öffentliche Statistik

Was hat ein Spammer nun von so einem auf eine “beworbene” Seite zeigenden, falschen Referer? Zwei Aspekte spielen dafür eine wichtige Rolle.

Zum einen die Neugier des Webmasters, der gerne wissen möchte, wer denn da und warum auf die eigene Seite verlinkt. Damit hat die bespammte Seite schonmal einen Besucher mehr. Ich gebe zu, ich gucke da auch manchmal nach, woher die Links kommen :-)

Zum anderen gibt es Webseiten, die ihre Zugriffsstatistik öffentlich einsehbar auf einer Seite bereitstellen. Meist gibt es da auch einen Bereich mit der Herkunft der Besucher, als der referenzierenden Webseite, die dann oft sagar als Link ausgegeben werden. Über die Bedeutung von Links im allgemeinen und für das Suchmaschinen-Ranking im besonderen brauche ich wohl keine großen Worte verlieren.

Referer-Spam mit System

Seit ein paar Tagen, konkret seit dem 18. März, befinden sich in meinen Log-Dateien Referer von der Seite referertrick.com (seit kurzem auch mit .de).
Die Zugriffe kommen bisher von den drei IP-Adressen 87.118.82.66, 87.118.82.104 und 87.118.116.23. Ich habe noch etwas “zurückgeblättert” und festgestellt, daß es bereits im Dezember 2009 ein paar Zugriffe von einem Bot namens “SourceSpider/2.1″ über die IP 87.118.82.66 gab. Im Januar wurde vermutlich eine Testlauf gestartet, da tauchte dieser Server mit “Kunden-Referer” auf.

Auf der referertrick-Webseite heißt es ganz unverblümt:

Wir senden HTTP-Pakete an alle Webseiten des Internets. Dabei wird Ihre Webseite als Referer aufgelistet.
Die Inhaber dieser vielen (teilweise Millionen) anderen Webseiten glauben daher, dass Sie auf diese Webseite verlinken würden, und besuchen Ihre Webseite aus Neugierde.
Jeder Besucher ist ein potentieller Kunde, ganz zu schweigen von der Suchmaschinen-Optimierung durch die vielen Statistik-Links!

Geld verdienen im Internet

Das Ganze klingt natürlich erstmal nach einer cleveren Geschäftsidee. Ich halte es allerdings für eine weitere Art von Spam, die irgendwann nur nervig ist.

Irgendwie paßt das auch ganz gut zum aktuellen Thema des Webmasterfridays “Was ist die richtige Linkbuilding-Strategie?” :-)
Allerdings denke ich, daß dieser Art gekauftes “Linkbuilding” über gefakte Referer auf Statistikseiten keine gut Strategie ist.

Google-Analytics und externe Statistik nicht betroffen

Wenn sich nun jemand wundert, daß bei ihm noch keine Referertricks angekommen sind, liegt es vielleicht daran, das die Statistik nicht über die Serverlogdatei funktioniert oder direkt auf dem Server läuft. Technisch bedingt sind keine Statistik-Tools betroffen, die extern per Javascript oder “Zählerpixel” eingebunden werden. Der Referertrick-Bot führt, davon gehe ich einfach mal aus, schließlich kein Javascript aus oder lädt per IMG-Tag eingebundene Grafiken nach. Somit sehen Statistik-Tools wie Google-Analytics, WordPress.com Stats oder auch Piwick diese falschen Referer erst gar nicht.

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.

Der Januar 2010 in Zahlen

Den letzten Monatsrückblick gab es für Oktober 2009, es wird also mal wieder Zeit, ein paar Zahlen zu präsentieren. Andernorts wird sowas ja auch gemacht. Allerdings habe ich hier keine hübschen Diagramm zu bieten, nur nüchternes Zahlenmaterial und ein paar Tabellen. Die Werte sind bis auf die AdSense-Daten alle aus der Serverlogdatei ermittelt worden.

Die Kennzahlen vom Januar 2010

• Webzugriffe: 109794 von 11261 IP-Adressen (9,75 Req/IP)
• Seitenzugriffe: 4031 (ca. 130/Tag)
• Einnahmen: 2,99 EUR (Google-AdSense)

Webzugriffe sind alle Zugriffe oder Zugriffsversuche auf irgendwelche Resourcen der Website, also sowohl Seiten, Bilder und Feeds, als auch CSS-Dateien, die robots.txt und sonstige (auch fehlerhafte 403/404-Zugriffe). Dabei erfolgten die Zugriffe von 11261 unterschiedlichen IP-Adressen. Also wurden von jeder IP-Adresse durchschnittlich knapp 10 Zugriffe getätigt.

Die Seitenzugriffe sind Zugriffe auf sichtbare Webseiten durch normale Benutzer, also z.B. keine Zugriffe auf Bilder oder durch Bots. Der von AdSense angezeigte Wert liegt da etwas höher bei 4277 Page Impressions, warum das so ist, weiß ich nicht. Ich hätte es eher anders herum erwartet.

Die € 2,99 Einnahmen wurden durch 9 Klicks erzeugt, was einer CTR von 0,21% entspricht und einen eCMP von € 0,70 ergibt. Keine Ahnung, was das nun konkret bedeutet. Zumindest betrugen die täglichen Einnahmen durchschnittlich 0,10 Euro.

Besucher von Suchmaschinen

Im Januar kamen 2752 Besucher von Google zu Schnurpsel (Oktober: 1555), die übergroße Mehrheit über die normale Websuche, nämlich 2446 (Okt. 1427) und 222 (Okt. 43) über die Bildersuche (fünf davon per Universal-Search). Von Bing gab es 7 Besucher, via T-Online ganze drei.

Die meisten Suchanfragen sind Suchphrasen aus zwei oder mehr Wörtern. Ich habe diese Gruppen mal in 9394 Einzelwörter zerlegt und so erhält man einen Überblick über die gefragtesten Themen meiner Webseite:

Typ: S – normale Suche, B – Bildersuche

Die beliebtesten Kombinationen sind unter anderem ‘wordpress strato’ bzw. ’strato wordpress’, ‘ähnliche bilder suchen’, ’strato mod_rewrite’, ‘wordpress strato langsam’ und ‘wordpress home link’. Mit Mohakenox kamen übrigens 11 Besucher von der Bildersuche und 8 von der normeln Suche hierher.

Andere Besucher-Quellen

Die Anzahl der Besucher von anderen Seiten ist überschaubar, die meisten (534) kamen vom Wordpress-Deutschland-Forum. Dort sind folgende Artikel die Spitzenreiter:
- Wordpress läd langsam. Hoster oder Skript Ursache? (39)
- strato; (28)
- Neuinstallation 2.9.1 bei 1und...nternal Server Error bei Step2 (25)
- Neuinstallation bei 1und1 (25)
- Fehler: Umleitungsfehler (21)
- Blog nicht mehr erreichbar (19)
- 1und1 mit Wordpress (18)
- Post via Email sofort publizieren (18)

Ein paar Besucher kamen z.B. auch von Twitter (69), vom SEO-Hanbuch (42), vom der Standard (34), vom Zonebuttler (29) und vom TagSeoBlog (24).

Blog-Statistik

Zum Schluß noch schnell die Blog-Statistik. Hier bei Schnurpsel gibt es derzeit 16 Seiten sowie 125 Artikel in 11 Kategorien und mit 143 Stichworten. Dazu kommen 586 genehmigte 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.

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.