Offline Netzwerken auf Konferenzen

Conference Crowd just before the start of a session

Konferenzen laufen doch immer gleich ab:

Man trifft Altbekannte aus der Branche, man schwatzt über dies und das, evtl. über bereits gehörte/gesehene Vorträge, Trasch aus der Branche, hört/schaut sich die mehr oder weniger interessanten Vorträge an, und das war’s…

Man bringt wahrscheinlich noch viele einige gute Vorsätze mit, „ah ja, das aus dem Vortrag wollte ich eigentlich schon längst mal machen…“, „oh, das ist ein neuer Aspekt, mal schauen ob und wie das in meine Maßnahmen passt…“ usw. – aber dann holt einen der Alltag schneller wieder ein als man sich vorstellen kann und die Vorsätze sind mal wieder vergessen bis zur nächsten Konferenz.

Mach’s doch mal anders!

Setz‘ Dich nicht zu Deinen Altbekannten!

Sondern setz‘ Dich mal zwischen totale Fremde! Und bevor der Vortrag beginnt, stell‘ Dich kurz links und rechts vor (Deinen „Elevator-Pitch“ hast Du ja eh allzeit bereit, oder?) und bitte doch um einen Visitenkartentausch!

Denn vielleicht sitzt die nächste große Business-Chance direkt neben Dir.

Und wenn nicht, was hast Du verloren?

 

 

So Killst Du Referrer Spam in Google Analytics

referrer spam

Also, wen nervt Referrer Spam nicht? Ständig neue Domains in Google-Analytics (und auch anderen Analyse-Tools, wie z.B. eTracker, piwik, usw.) die angeblich Traffic auf die Website liefern. Bei großen, trafficstarken Websites mögen die hunderte bis tausende gefakten „Visitors“ im Monat das Bild nicht allzu sehr verfälschen, bei kleineren Websites ergibt sich hierzu aber leider oft eine derartige Schieflage, die kaum noch einen richtigen Blick auf die tatsächlichen Daten ermöglicht.

Wie kann man aber nun verhindern, dass dieser Referrer-Spam in den Analytics-Reports auftaucht?

Nun, hierzu muss man erst einmal verstehen, wie dieser Referrer-Spam überhaupt generiert wird. Dies geschieht nämlich auf zweierlei Art,

  1. durch tatsächliche „Bot“-Besuche und
  2. durch reines Aufrufen/Ausführen des Tracking-Codes

Referrer Spam durch tatsächliche Bot-Besuche

Hierzu muss man wissen, dass der „Referrer“ eine Information ist, die der Browser selbst gespeichert hat, und dann nur noch von der Analytics-Software ausgelesen wird. D.h. der Seitenaufruf muss gar nicht unbedingt von dieser URL her erfolgen, und natürlich kann man so etwas dann eben auch fälschen. Und genau das machen diese Bots. Hierbei handelt es sich nämlich schlicht um Programme, die so programmiert sind, dass sie Webseiten im Web aufrufen, und den entsprechenden Analytics-Code ausführen und den gewünschten „Referrer“ hinterlassen. Das ist natürlich nur sehr vereinfacht beschrieben, aber das hier soll ja auch keine Anleitung werden, wie man Referrer-Spam produziert ;).

Wie kann man aber nun diesem Treiben Einhalt gebieten?

No more... referrer spam reports!Also die einfachste Methode ist hier, allen „Besuchern“, die einen Referrer von einer bekannten Spam-Domain melden, schlichtweg den Zugriff auf die Website zu versagen.
Dies kann man zum einen, bei apache-Servern (und noch laufen die allermeisten Webserver mit apache), in der .htaccess-Datei tun (wie das genau geht, siehe unten). Für Websites, die auf Servern liegen, auf die man keinen Zugriff auf die zentralen Konfigurationsdateien des apache-Servers hat, ist dies leider auch die einzige Möglichkeit.
Hat man jedoch die Möglichkeit die apache-Konfigurationsdateien zu bearbeiten, so ist diese Methode zu empfehlen. Was man in diesem Fall machen kann und wie man hier auch recht einfach automatisieren kann, neu bekannt werdende Domains hinzuzufügen ist weiter unten genau beschrieben. Für nginx-betriebene Webserver gilt vom Prinzip her genau dasselbe, da aber nginx das Konstrukt der .htaccess-Datei nicht kennt, geht es hier tatsächlich nur über die zentralen Konfigurationsdateien des nginx-Servers. Hier geht’s zur nginx-Anleitung.

Referrer Spam durch reines Aufrufen/Ausführen des Tracking-Codes

Hier funktionieren diese Programme derart, dass sie die Tracking-IDs einfach erraten und, ohne jeden Besuch der eigentlichen Website, die entsprechenden Tracking-Informationen direkt an die Server der Tracking-Software senden. Hiergegen hilft die obige Methode natürlich nicht, da ja hier die eigene Website überhaupt nicht aufgerufen wird. Gegen diese Art des Referrer-Spams kann man dann nur direkt im Analytics Tool vorgehen, in dem man diesen Spam-„Traffic“ herausfiltert. Google Analytics hat hierzu inzwischen sogar eine eigene Option integriert, allerdings nimmt Google neue Referrer-Spam Domains und Bots nur sehr, sehr zurückhaltend in seine Blacklist auf, so dass leider nach wie vor ein großer Anteil von Referrer-Spam „durchgeht“.

Wie filtert man nun diesen Referrer-Spam aus?

Referrer Spam - wir kriegen euch alle!Zuerst einmal kann man sich hier zunutze machen, dass diese „Bots“ die eigentliche Domain gar nicht kennen und dementsprechend der Analytics-Software auch nicht mitteilen können, welche URL sie denn gerade behaupten aufgerufen zu haben. Also erstellt man zuerst einmal einen Filter, der verhindert, dass „Seitenaufrufe“, bei denen nicht die eigene Domain in der aufgerufen URL steht, registriert werden. Zur Anleitung
Leider filtert das aber auch noch nicht alle aus, so dass man nicht umhin kommt, auch noch Filter zu erstellen, die den ganzen „Traffic“ von Referrer-Spam-Domains ebenfalls herausfiltert. Da – zumindest bei Google-Analytics – die Zeichenlänge einer Filterdirektive auf 256 Zeichen begrenzt ist, es aber inzwischen sehr viele bekannte Spam-Domains gibt bedeutet dies, dass man hier inzwischen ca. 25 Filter anlegen (und pflegen) muss. Um dies etwas zu erleichtern gibt es hier jeweils einen aktuellen Satz von Filterregeln, sowie eine Liste von Filterregeln, die nur die pro Tag neu hinzugekommenen enthalten.

Anleitung .htaccess

Um den Referrer Spam in der .htaccess-Datei auszusperren trägst Du den Inhalt dieser Datei: htaccess.txt folgendermaßen in Deine .htaccess-Datei ein:

  1. Lade per FTP-Programm Deine .htaccess-Datei auf Deinen lokalen PC – solltest Du keine .htaccess-Datei in Deinem FTP-Programm sehen, so musst Du ggf. „verborgene Dateien anzeigen“ aktivieren – hast Du keine .htaccess-Datei (sehr unwahrscheinlich) dann lade die obige Datei per FTP-Programm ins Hauptverzeichnis auf Deinem Server und benenne die Datei anschließend in .htaccess (mit führendem Punkt und ohne Erweiterung!) um.
  2. Erstelle eine Sicherungskopie der gerade heruntergeladenen .htaccess-Datei
  3. Finde in Deiner .htaccess-Datei die Zeile
    RewriteEngine On

    und kopiere aus der htaccess.txt alle Zeilen genau darunter

    Solltest Du keine Zeile RewriteEngine On in Deiner .htaccess finden (wiederum sehr unwahrscheinlich), so füge die Zeile

    RewriteEngine On

    als allererstes ganz oben in Deine .htaccess-Datei ein und kopiere den gesamten Inhalt der Datei htaccess.txt darunter.

  4. Lade die neue, veränderte .htaccess-Datei wieder zurück auf Deinen Server
  5. Teste ausgiebig, ob alles weiterhin so funktioniert wie gewünscht – Falls nicht, kannst Du jederzeit die gesicherte Kopie wieder zurück auf den Server hochladen.

Wenn Du nun die Regeln updaten willst, so lade einfach eine neue Kopie von htaccess.txt herunter und ersetze den Bereich zwischen

RewriteEngine On

und

RewriteRule .* - [F].

Anleitung automatischer Update der zentralen apache-Konfigurationsdateien

Voraussetzungen:

  1. Du hast root-Zugang zu Deinem Server
  2. Du hast git auf Deinem Server installiert.
  3. Du weißt wie Du einen cron-Job für root einrichtest

Vorgehen:

  1. Logge Dich per ssh (z.B. mit PuTTY) auf Deinem Server ein und verschaffe Dir – falls notwendig – mittels
    sudo

    root-Rechte.

  2. Wechsel in das Verzeichnis /root/ – oder ein anderes Verzeichnis, das nicht in Verzeichnisbaum eines Webauftritts liegt, und führe folgende Befehle aus:
    git clone https://github.com/piwik/referrer-spam-blacklist
    git clone https://github.com/mher30/referrer-spam
    
  3. rufe im Verzeichnis referrer-spam den Befehl
    ./cron.sh

    einmalig aus

  4. kopiere nun nur noch die apache-spamblock.conf in das Konfigurationsverzeichnis des apache-Webservers (meist /etc/apache2) und
  5. binde die apache-spamblock.conf  in Deine Virtual-Server-Konfigurationen ein (Beispiel-Code):
    <VirtualHost *:80>
    ServerName www.beispiel-domain.de
    ServerAlias beispiel-domain.de
    ServerAdmin admin@beispiel-domain.de
    
    Include apache-spamblock.conf
    ...
    </VirtualHost>
    
  6. um das Ganze zu automatisieren lege einen Cron-Job an (z.B. im Verzeichnis /etc/cron.daily), der dann
    1. in das obige referrer-spam Verzeichnis wechselt
    2. dort dann die Datei cron.sh aufruft
    3. anschließend die neue apache-spamblock.conf in das apache-Konfigurationsverzeichnis kopiert
    4. Überprüft ob die apache-Konfiguration immer noch korrekt ist – es kann ja durchaus mal passieren, dass sich irgendwo ein Fehler einschleicht 😉
    5. und im Erfolgsfalle die neue Konfiguration läd.

    Wenn Du nicht weißt, wie Du diese Schritte programmierst, dann bitte jemanden, der sich mit shell-Script-Programmierung auskennt, dies für Dich einzurichten. Hier gibt es so viele unsäglich verschiedene Installations- und Konfigurationsvarianten, dass man dies nicht generisch programmieren kann. – OK, zumindest ich nicht 😉

  7. Anschließend: Testen, testen, testen!!
  8. Fertig

Anleitung nginx Konfiguration

Lege die nginx-Konfigurationsdatei in das globale nginx-Konfigurationsverzeichnis (wahrscheinlich /etc/nginx/global) und binde sie in die Serverkonfiguration ein:

...
server {
listen 443;
server_name dein-server-name-hier.de;

include /etc/nginx/global/*;
...

Anleitung Google-Analytics Filter

Grundsätzlich gilt bei Google-Analytics: Filter schließen den Traffic schon vor der Erfassung aus, d.h. einmal ausgefilterter Traffic ist für Analytics für immer verloren. Deshalb gilt: Für Filter immer eine neue Datenansicht verwenden und die Standard-Datenansicht („Alle Websitedaten“) immer ohne Filter belassen!

So erstellst Du eine neue Datenansicht:

Wähle im Google Analytics Hauptmenü die Option „Verwalten“:
Google Analytics Menü Verwalten
Anschließend wähle in der rechten Spalte „DATENANSICHT“ die Option: „Neue Datenansicht erstellen“ aus:
Google Analytics Neue Datenansicht erstellen
Als nächstes musst Du nun der neuen Datenansicht einen Namen geben. Hier gibst Du entsprechend unserer geplanten Filterung: „Referrer Spam Filtered“ ein (die Vorauswahl, dass Du eine Website filtern willst lässt Du bestehen) und wählst noch die richtige Zeitzone (hier im Beispiel: „Deutschland“) aus:
Google Analytics Neue Datenansicht einrichten
Als nächstes nimmst Du noch eine Änderung an den „Einstellungen der Datenansicht“ vor:
Google Analytics - Einstellungen der Datenansicht
und zwar aktivierst Du, dass Google selbst schon Treffer von bekannten Bots und Spidern herausfiltert.
Google Analytics - Bots herausfiltern
Wie bereits oben erwähnt, ist ist Google bisher leider recht zurückhaltend damit neue Bots und Spider in seine „Blacklist“ aufzunehmen, so dass Du nicht drumherum kommst und selbst auch noch ein paar Filter definieren musst, also wähle „Filter“ aus:
Google Analytics Filter
und erstelle auch gleich Deinen ersten Filter:
Google Analytics Filter hinzufügen
Als erstes filterst Du all diese „Ghost-Visits“ heraus, bei denen der Bot nicht meldet, dass er Deine Domain besucht – was er ja auch meist gar nicht kann, da der Bot ja einfach nur „blind“ Deinen „Tracking-Code“ aufruft, ohne auch nur zu wissen, auf welcher Domain er eingebunden ist. Also nennst Du den Filter am besten auch dementsprechend: „Ghost Visits Filter“ – wählst „Benutzerdefiniert“ aus und stellst folgendes ein:
Einschließen: Du willst nur solche Treffer tracken, bei denen der vom Browser gemeldete „Hostname“ Deine Domain enthält:
Google Analytics - Ghost Visits Filter Einstellungen
(der \ vor dem . sollte nicht fehlen, da Google diesen Eintrag als Regulären Ausdruck interpretiert und der Punkt . bei regulären Ausdrücken für jedes beliebige Zeichen steht – also Punkte . hier immer als \. schreiben – dies bedeutet dann für Google: ein Punkt und nichts als ein Punkt sollte hier stehen!)
Wenn Deine Seite in den letzten 7 Tagen von Ghost-Visits geplagt wurde, kannst Du jetzt schon sehen, ob Dein Filter in der Zukunft auch greifen wird, in dem Du „Filter überprüfen“ anklickst:
Google Analytics - Filter überprüfen
Und dann erhältst Du ein Ergebnis ähnlich wie dieses (nur wahrscheinlich mit mehr Zeilen):
Google Analytics - Ergebnis Filter Überprüfung

Wenn Du auch auf Deinem Server die Bots mittels der oben beschriebenen Konfigurationsdateien ausgesperrt hast, solltest Du hiermit bereits rund 95% aller Referrer-Spam Treffer eleminiert haben. Die einzigen, die jetzt noch durchkommen, sind die Bots, die die beiden Methoden kombinieren, indem sie zwar Ghost-Visits produzieren, aber trotzdem den richtigen Hostnamen mitschicken. Derer kannst Du nur dadurch Herr werden, in dem Du sie auch noch bei Google Analytics explizit herausfilterst. Stand heute benötigst Du hierzu 25 weitere Filterregeln. Eine Datei mit den aktuellen Filterregeln kannst Du ebenfalls hier downloaden.
Für jede Zeile in dieser Datei musst Du einen Filter anlegen:
Diesmal willst Du aber Treffer ausschließen, und zwar alle bei denen die „Kampagnenquelle“ eine der im Filter genannten Domains entspricht:
Google Analytics Referrer Filter

Dies musst Du nun für alle Zeilen in der Datei filters.txt wiederholen… leider gibt es hierfür keinen Shortcut, und wenn Du mehrere Domains hast, musst Du dies leider für alle wiederholen, eine Export/Import Funktion für Filter existiert leider nicht. 🙁

Jetzt brauchst Du nur noch regelmäßig auf https://www.mher.de/referrer-spam nachschauen, ob es neue Spambot-Domains gibt, und falls ja, Deine Konfigurationsdateien entsprechend updaten…

und…

A ruah is jetz - zefix nuamoi

Viel Erfolg!

Microformat Fehlermeldungen in der Google Search Console vermeiden

microformats-hentry-fehlermeldung

Das Problem …

… kennen wahrscheinlich viele:

Die Google Search Console (ehemals Google Webmaster Tools) meldet Fehler unter „Darstellung der Suche >> Strukturierte Daten“. So wie z.B. hier:

microformats-hentry-fehlermeldung-2 hatom Fehlermeldung in der Google Search Console

Wo kommt das her?

Eigentlich alle modernen WordPress-Themes umschließen den eigentlichen Artikel/Blog-Post mit einem HTML-Tag (meist <article aber auch einfach mit <div und geben diesem via post_class(); standard CSS-Klassen mit. Eine davon ist hentry – hentry ist aber eine Mircoformat-Klasse die so definiert ist, dass sie auch bestimmte weitere Microformat-Attribute erwartet. Diese werden jedoch leider oft von den Themeerstellern nicht mit erstellt. Daher kommt es dann in der Search Console zu den erwähnten Fehlermeldungen.

Wie kann ich das beheben?

Nun, man könnte dies in den entsprechenden Theme-Dateien selbst einfügen – Schlechte Idee!! Denn sobald ein Theme-Update kommt sind ja meine Änderungen wieder weg 🙁

Dafür könnte man ein Child-Theme erstellen, die verwendeten php-Dateien des Themes dort hinein kopieren und daran die Änderungen vornehmen – leider IMHO auch nur die zweitbeste Lösung, denn sollte das Original-Theme Änderungen an diesen Dateien vornehmen, so werden sich diese nicht auf das Child-Theme (und somit meine Website) auswirken.

Was also tun?

Nun, WordPress hat hierfür einen passenden Filter bereit gestellt, mit dem wir recht einfach unabhängig vom Theme noch etwas an den Inhalt eines Posts (‚the_content‘ – hier gibt’s eine Liste aller möglichen Filter-Hooks) anhängen können. In unserem Falle eben die fehlenden Mircoformat Informationen:

//add hatom data
function add_mher_hatom_data($content) {
  if (is_home() || is_singular() || is_archive() ) {
    $content .= '<div class="hatom-extra" style="display:none;visibility:hidden;"><span class="entry-title">'.get_the_title().'</span> letzte Änderung: <span class="updated"> '.get_the_modified_time('F jS, Y').'</span> von <span class="author vcard"><span class="fn">'.get_the_author().'</span></span></div>';
  }
  return $content;
}
add_filter('the_content', 'add_mher_hatom_data');

Dieser Code muss nur ganz einfach in die functions.php des Themes (bzw. besser des Child-Themes) eingetragen werden, und schon sind die Fehlermeldungen der Search Console Vergangenheit.

Google Consumer Surveys – Neues Google Tool für Webmaster

Google-Consumer-Surveys

…erstmal nur für den amerikanischen Markt…

Google hat ein neues Tool vorgestellt: Google Consumer Surveys – ein Webseiten-Fragebogen bzgl. der wahrgenommenen Qualität der Website.

Mit einem kleinen JavaScript Snippet in der <head>-Sektion der Webseiten kann man, wie gesagt derzeit nur für US-Visitors, den Besuchern einen kleinen Fragebogen präsentieren, der dem Webmaster (und natürlich auch Google – was auch immer Google dann mit diesen Daten anfängt 😉 ) dann promptes Feedback bzgl. seiner Site gibt. Derzeit wird wohl nur eine Frage gestellt: Wie zufrieden sind sie mit dieser Website? und die, schon fast klassischen 5 möglichen Antworten „sehr zufrieden“, „etwas zufrieden“, „weder zufrieden noch unzufrieden“, „etwas unzufrieden“ und „sehr unzufrieden“. Für 1ct (US$) pro Antwort kann der geneigte (und finanziell potente 😉 ) Webmaster auch eigene Fragen definieren.

Weiterhin kann man noch (kostenfrei) für das Google Consumer Survey definieren wie viele Seiten ein Besucher aufgerufen haben soll, bevor er den Fragebogen präsentiert bekommt, sowie nach wie vielen Seiten er ihn erneut präsentiert bekommen soll, so er ihn nicht schon beim ersten Mal beantwortet hat. Dann kann man noch einstellen, wie viele Stunden vergehen sollen bevor der Besucher den Fragebogen erneut präsentiert bekommen soll (Standardeinstellung sind 168 Stunden = 7 Tage) – was nicht ganz klar ist, ist ob es dabei eine Rolle spielt, ob der Besucher den Fragebogen zuvor ausgefüllt hat oder nicht. Als letzte Einstellung ist es noch möglich zu begrenzen wie viele Fragebögen (gemeint ist wahrscheinlich wie oft) der Besucher maximal ausfüllen muss bevor er keine mehr angezeigt bekommt.

Was bedeutet das nun für den Webmaster?

Nun für den deutschen Webmaster, der keine Seiten für den US-Amerikanischen Markt betreibt, erst einmal gar nichts. Höchstens, dass er die Entwicklung in den USA beobachten sollte um gewappnet zu sein, sofern dieses Tool auch für den deutschen Markt verfügbar werden sollte.

Spannender ist jedoch eigentlich die Frage, was Google mit diesem Tool, das ja doch auch wieder einiges an Rechen-Ressourcen von Google verbrauchen wird, langfristig bezwecken will. Natürlich an erster Linie „ein besseres Web“, wie immer eigentlich.

Doch hier stellt sich die Frage wie?

Allein die Information, dass x% der Besucher nicht vollauf zufrieden mit Ihrem Besuch der Website waren, hilft dem Webmaster eigentlich herzlich wenig. Interessanter wäre es doch, auch zu wissen, warum der Besucher nicht zufrieden war. War es, weil er nicht die Informationen oder das Produkt gefunden hat, die/das er gesucht hat. Und in diesem Fall, ist er evtl. direkt auf die Website gegangen weil er sie kennt und geglaubt hat, dass er dort diese Informationen oder dieses bestimmte Produkt finden würde, oder ist er über die Suchmaschine (evtl. sogar Google) auf diese Website gelangt…    spannende Fragen…

Weiterhin: Auch wenn Google derzeit noch dementiert, dass es geplant ist, dass diese Daten Einfluss auf das Ranking von Websites nehmen können, so ist diese Möglichkeit sicherlich nicht auszuschließen. Es scheint fast, dass Google selbst nicht mehr glaubt, dass sie die Qualität von Websites rein algorithmisch bewerten können, und die Quality-Rater auch nicht beliebig vermehrt werden können, so versucht man sich anscheinend jetzt mit am – durch den Webmaster unterstützten – Crowd-Sourcing.

Aber was bedeutet das weiterhin?

Webmaster, die wissen, dass ihre Seite eh nicht so toll bewertet würde, oder auch einfach nur Angst davor haben, dass evtl. negative Bewertungen Ihnen schaden würden, werden dieses Tool wohl eher nicht einsetzen. Sollte/Kann/Darf Google dann solchen Websites zukünftig einen Malus verpassen? Das geht ja wohl eher kaum. Denen, die dieses Tool einen Bonus geben geht ebenso wenig, da dies ja defacto auf’s Gleiche hinausläuft. Also welchen Wert haben dann die zwangsläufig immer sehr unvollständigen Daten für Google? Hmmm, immerhin könnte Google damit seinen Algorithmus überprüfen wenn dieser ein signifikant anderes Ergebnis auswerfen würde als die Umfrage. Anscheinend glaubt Google auch, dass hierfür maximal 500 Antworten pro Monat ausreichen, da sie erst einmal nicht mehr Antworten pro Website und Monat erheben wollen. Es kann aber auch sein, dass dieses Limit in Zukunft heraufgesetzt wird, sollte sich das Tool entsprechend etablieren und Google kann  so auch den zukünftigen Ressourcen-Bedarf besser berechnen.

es bleibt spannend…

P.S.: Weitere Artikel über das neue Google Tool „Google Consumer Surveys“:

Der Original Artikel von Google… ist zusammen mit Google+ in die ewigen Jagdgründe eingegangen…

Die Jongo Webagentur berichtet ebenfalls

WordPress Seite als 404 Seite ausliefern

Es ist immer wieder ein Problem mit WordPress eine wirklich individuell gestaltete 404-Seite auszuliefern, die alle Features einer „normalen“ Seite (Page) von dem jeweiligen Theme hat. Umso komplexer das Theme ist, umso spartanischer wirkt die 404-Seite. Was man sich da dann oft wünscht, ist, warum kann ich nicht einfach eine Seite erstellen, und diese WordPress … WeiterlesenWordPress Seite als 404 Seite ausliefern