Das Putzlowitsch Test- und SEO-Blog
Thema: Programmierung

Besucher aus der Bildersuche tracken – in der Server-Logdatei und mit Google-Analytics

Früher war alles besser

Bildersuche Referrer

Um zu erkennen, ob der Besucher einer Seite über die Bildersuche kommt, konnte man lange Zeit den Referrer auswerten. Dort fand man bestimmte Parameter (z.B. /imgres), die auf einen Treffer aus der Bildersuche schließen ließen.

Seit der Einführung der neuen Bildersuche bei google.de fehlen diese Parameter im Referrer und es steht bestenfalls noch „https://www.google.de/“ drin.

Bei vielen Websitebetreibern [1] [2] [3] führte das zu dem Schluß, daß nun von der Bildersuche praktisch gar keine Besucher mehr kommen. Es handelt sich aber um ein „Meßfehler“ in Google-Analytics, weil die alten Methoden zum tracken der Bildersuche nun nicht mehr funktionieren.

Die neue Bildersuche hat aber diesbezüglich einen positiven Aspekt, denn vor dem Besuch der Seite, wenn es denn dazu kommt, wird das Original-Bild vom Server abgerufen.

Tracking mit Keksen

Kekse – Cookies (Foto: ajt / 123RF)

Wie hilft uns das nun bei der Erkennung von Besuchern aus der Bildersuche?

Beim Abruf des Bildes kann ein Cookie gesetzt werden, das dann beim Aufruf der Seite ausgewertet wird. Gut, falls jemand Cookies deaktiviert hat, funktioniert das natürlich nicht, aber so viele Nutzer von Suchmaschinen werden das nicht sein.

Auch früher gabe es schon nutzerbedingte Meßfehler. Hat der Nutzer z.B. die Übertragung des Referrers ausgeschaltet, konnten die Zugriffe nicht zugeordnet werden. Hat der Nutzer gar JavaScript deaktiviert oder blockiert z.B. per DNS die Zugriffe auf www.google-analytics.com, wurden überhaupt keine Pageviews registriert.

Ich selbst bin ja eher ein Anhänger der Logfile-Analyse und verwende kein Google-Analytics oder andere Tools. Die Logfiles werden ohnehin erzeugt und da steht tatsächlich jeder Zugriff drin. Die richtige Interpretation der Daten ist dann allerdings auch schon eine Kunst für sich.

Zugriff!

Bildersuche-Tracking in der .htaccess

Fast alle Aktionen, die wir für das Tracking per Cookie benötigen, können in der .htaccess-Datei erledigt werden. Für das Tracking mit Google-Analytics wird ein angepaßter JavaScript-Code erzeugt.

Die technische Basis meiner Lösung ist ein Apache-Webserver mit den aktiven Modulen mod_rewrite und für das Tracking in der Server-Logatei mod_headers.

Der für das Tracking verantwortliche Teil meiner .htaccess sieht so aus:

<IfModule mod_headers.c>
RequestHeader merge Referer "bisutrk=%{BISU_TRK}e" env=BISU_TRK
</IfModule>

<IfModule mod_rewrite.c>
RewriteEngine On

# Aufruf eines existierenden Bildes
RewriteCond %{REQUEST_URI} \.(jpg|png|gif)$
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule . - [E=REQ_IMG:1]

# Aufruf einer normalen Seite
RewriteCond %{REQUEST_URI} !\.[^\.]+?$
RewriteRule . - [E=REQ_PAGE:1]

# Host-Domain
RewriteCond %{HTTP_HOST} (([^\.]+?\.)?[^\.]+?)$
RewriteRule . - [E=OWN_DOM:%1]

# Referrer-Domain
RewriteCond %{HTTP_REFERER} ^https?://(([^\.]+?\.)?([^\.]+?\.)?[^\.]+?)/
RewriteRule . - [E=REF_DOM:%1]

# Referrer Second-Level-Domain (SLD) ist google oder bing
RewriteCond %{ENV:REF_DOM} (google|bing)(\.(com|co))?\.[^\.]+?$ [NC]
RewriteRule . - [E=REQ_SLD:%1]

# Bild -> Cookie setzen
RewriteCond %{ENV:REQ_IMG} 1
RewriteCond %{ENV:REQ_SLD} ^(.+?)$
RewriteRule . - [CO=BiSuTrk:%1:.%{ENV:OWN_DOM}]

# Normale Seite und Cookie gesetzt -> Variable setzen und Cookie löschen
RewriteCond %{ENV:REQ_PAGE} 1
RewriteCond %{ENV:REQ_SLD} ^(.+?)$
RewriteCond %{HTTP_COOKIE} BiSuTrk=([^;]+?)(;|$) [NC]
RewriteRule . - [E=BISU_TRK:%1,CO=BiSuTrk:INVALID:.%{ENV:OWN_DOM}:-1]
</IfModule>

Das sieht vielleicht erstmal etwas kompliziert aus, ist es aber nicht. Es sind auch noch Vereinfachungen möglich.

Die Anweisungen bewirken kein Rewrite und dienen nur zum Setzen und Auswerten von Umgebungsvariablen und zum Setzen bzw. Löschen von Cookies. Der Block sollte vor allen anderen Rewrite-Regeln stehen.

# Aufruf eines existierenden Bildes

RewriteCond %{REQUEST_URI} \.(jpg|png|gif)$
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule . - [E=REQ_IMG:1]

An Hand der Dateierweiterung wird geprüft, ob ein Bild angefordert wird. Außerdem wird getestet, ob es das Bild als Datei gibt. Falls nicht, soll der Zugriff auch nicht getrackt werden. Treffen beide Bedingungen zu, wird das in der Umgebungsvariablen REQ_IMG vermerkt. Diese wird dann später ausgewertet.

# Aufruf einer normalen Seite

RewriteCond %{REQUEST_URI} !\.[^\.]+?$
RewriteRule . - [E=REQ_PAGE:1]

Das eigentliche Tracking soll nur beim Aufruf einer normalen Seite erfolgen. Naheliegend wäre, daß man die Bedingung „Ist ein Bild“ einfach umkehrt, also negiert. Das trifft aber nicht immer zu, denn je nach Webbrowser wird nach dem Bild zum Beispiel noch das Favoriten-Icon favicon.ico abgerufen. Dieser Aufruf würde dann bereits das Tracking auslösen, was nicht gewollt ist.

Hier muß also eine Regel formuliert werden, die einen normalen Seitenaufruf beschreibt. In meinem Fall sind es die Permalinks von WordPress, die sich dadurch von normalen Dateiaufrufen unterscheiden, daß sie keine Dateiwerweiterung wie z.B. .jpg, .ico oder .css haben.

Wenn normale Seiten immer auf .html enden, könnte die Regel z.B. so aussehen:

RewriteCond %{REQUEST_URI} \.html$
RewriteRule . - [E=REQ_PAGE:1]

# Host-Domain

RewriteCond %{HTTP_HOST} (([^\.]+?\.)?[^\.]+?)$
RewriteRule . - [E=OWN_DOM:%1]

Hier wird aus dem HTTP_HOST der Domainname ohne Subdomain bzw. vorangestelltem www extrahiert. Die Variable wird als Cookie-Domain verwendet. Man kann die Domain aber auch direkt bei den beiden Cookie-Aktion eintragen. Ich wollte das Ganze nur so weit wie möglich universell gestalten.

# Referrer-Domain

RewriteCond %{HTTP_REFERER} ^https?://(([^\.]+?\.)?([^\.]+?\.)?[^\.]+?)/
RewriteRule . - [E=REF_DOM:%1]

Hier wird aus dem HTTP_REFERER der Domainname der aufrufenden URL extrahiert. Da ich den Referrer-Domainnamen noch bei anderen Rewrite-Regeln benötige, ziehe ich mir den an einer Stelle raus und packe ihn in eine Umgebungsvariabel. Das kann man auch anders machen bzw. mit der nächsten Regel zusammenfassen.

# Referrer Second-Level-Domain (SLD) ist google oder bing

RewriteCond %{ENV:REF_DOM} (google|bing)(\.(com|co))?\.[^\.]+?$ [NC]
RewriteRule . - [E=REQ_SLD:%1]

Nun wird mit der eben extrahierten Referrerdomain geprüft, ob es sich um Google oder z.B. Bing handelt und der Treffer ggf. in einer Umgebungsvariablen abgelegt. Berücksichtigt wird auch, daß es in manchen Ländern noch die Ebene .com und .co vor der eigentlichen Second-Level-Domain (SLD) gibt (z.B. google.co.uk oder google.com.au).

# Bild -> Cookie setzen

RewriteCond %{ENV:REQ_IMG} 1
RewriteCond %{ENV:REQ_SLD} ^(.+?)$
RewriteRule . - [CO=BiSuTrk:%1:.%{ENV:OWN_DOM}]

Nach der ganzen Vorarbeit kommen wir nun endlich zum Kernpunkt, dem Setzen eines Tracking-Cookies. Ich habe ihm den Namen BiSuTrk (Bilder-Suche-Tracking) verpaßt.

Die Bedingungen und Regeln sind einfach erklärt. Haben wir es mit einem existierenden Bild zu tun (REQ_IMG) und kommt der Aufruf von Google oder Bing (REQ_SLD), dann wird ein Cookie mit dem Namen BiSuTrk und dem Wert google/bing für die eigene Domain (OWN_DOM) gesetzt.

Hier findet Ihr die Beschreibung zur Cookie-Funktion im Apache-Rewrite-Modul. Ich verwende nur die ersten drei Parameter Name, Wert und Domain. Interessant ist aber auch noch der nächste Parameter „Lifetime“, der die Lebenszeit des Cookies in Minuten festlegt. Wird er nicht verwendet oder ist 0, dann wird ein Session-Cookie gesetzt. Das heißt, es überlebt nur, solange der Webbrowser nicht geschlossen wurde.

Falls ein Bild von Google oder Bing aufgerufen wurde, sind wir hier fertig. Das Cookie ist gesetzt und wartet im Hintergund auf den ersten Seitenaufruf.

# Normale Seite und Cookie gesetzt -> Variable setzen und Cookie löschen

RewriteCond %{ENV:REQ_PAGE} 1
RewriteCond %{ENV:REQ_SLD} ^(.+?)$
RewriteCond %{HTTP_COOKIE} BiSuTrk=([^;]+?)(;|$) [NC]
RewriteRule . - [E=BISU_TRK:%1,CO=BiSuTrk:INVALID:.%{ENV:OWN_DOM}:-1]

Der Nutzer hat unser schönes Bild in der Bildersuche gesehen, interessiert sich nun doch für unsere Seite und klickt beherzt auf das Bild oder [Seite besuchen]. Jetzt schlägt die letzte Tracking-Regel zu.

Es ist ein normaler Seitenaufruf (REQ_PAGE) und er kommt von google/bing (REQ_SLD) und das Tracking-Cookie ist gesetzt (HTTP_COOKIE). Yeahhh, dann ist es mit hoher Wahrscheinlichkeit ein Besucher aus der Bildersuche. Das merken wird uns in der Umgebungsvariable BISU_TRK und löschen das Cookie. Wobei man ein Cookie nicht löschen, sondern nur für ungültig erklären kann. Das passiert über eine Verfallszeitpunkt in der Vergangenheit, hier konkret mit -1 Minute.

Ab in die Log-Datei

Da der Referrer uns nicht mehr wie früher die Informationen zur Bildersuche liefert, setzen wird die Trackinginformation einfach in den Referrer ein.

<IfModule mod_headers.c>
RequestHeader merge Referer "bisutrk=%{BISU_TRK}e" env=BISU_TRK
</IfModule>

Mit dem Headers-Modul des Apache-Webservers kann man auch die Request-Header verändern, also das was eigentlich vom Browser des Nutzers gesendet wird. Abhängig davon, ob die Umgebungsvariable TRK_VALUE gesetzt ist, wird der Wert dem Referer hinzugefügt und landet so im Server-Logfile.

... "GET /tomaten/ HTTP/1.1" 200 8061 "http://www.google.de, bisutrk=google"

So sieht das dann im Logfile aus. Der Parameter wird mit Komma und Leerzeichen an den vorhandenen Referrer angehängt.

Wie man das nun auswertet, hängt von der verwendeten Logfile-Analyse-Software ab. Bei meinen selbst geschriebenen PHP-Skripten war das natürlich kein Problem.

Ab zu Google-Analytics

Da ich selbst kein Google-Analytics (GA) verwende, kann ich das nicht testen, theoretisch sollte es aber wie beschrieben funktionieren.

Man kann in GA benutzerdefinierte Parameter verwenden. Es gibt Dimensions und Metrics. Der normale Funktionsaufruf zum Tracking eines Seitenaufrufs sieht so aus.

ga( 'send', 'pageview' );

Mit einer benutzerdefinierten Dimension könnte das dann so aussehen:

ga( 'send', 'pageview', { 'dimension15': 'google' } );

Wie man das nun auf der Webseite ausgibt, hängt vom CMS ab. Als einfaches Beispiel habe ich das hier mal als PHP-Codeschnipsel implementiert:

$bisu_trk = trim( $_SERVER['BISU_TRK'] );
if( $bisu_trk )
	echo "ga( 'send', 'pageview', { 'dimension15': '$bisu_trk' } );";
else
	echo "ga( 'send', 'pageview' );";

Es wird die in der .htaccess-Datei gesetzte Variable (BISU_TRK) geprüft. Falls diese nicht leer ist, wir der ensprecheden Wert im der Dimension verwendet.

Fehler- und weitere Betrachtung

Ganz hundertprozentig sicher wird dieses Tracking der Bildersuche nicht funktionieren. Wie oben schon erwähnt, setzt es auf Cookies und falls der Nutzer keine Cookies erlaubt, guck man in die Röhre.

Außerdem ist nicht garantiert, daß der Nutzer tatsächlich mit dem Klick aus der Bildersuche kam. Vorstellbar ist, daß er zwar zunächst in der Bildersuche etwas gesucht hat, dann aber zur normalen Suche gewechselt ist und von dort Eure Seite besucht hat.

Selbst wenn der Nutzer Euer Bild in der Bildersuche gar nicht gesehen hat, wird möglicherweise trotzdem das Trackingcookie gesetzt. Das liegt daran, daß Google im Hintergrund bereits das vorhergehende und das nachfolgende Bild lädt.

Google-Bildersuche: Neues Layout (Preload)

Man könnte die Lebenszeit des Cookies verkürzen.

RewriteCond %{ENV:REQ_IMG} 1
RewriteCond %{ENV:REQ_SLD} ^(.+?)$
RewriteRule . - [CO=BiSuTrk:%1:.%{ENV:OWN_DOM}:5]

Falls der Nutzer nicht innerhalb von 5 Minuten, nachdem er das Bild gesehen hat, auf die Seite klickt, dann kommt er höchst wahrscheinlich doch nicht über die Bildersuche.

Für das Tracking in der Server-Logdatei benötigt man den ganzen Zauber mit Cookies eigentlich gar nicht, denn da steht ja sowohl der Aufruf des Bildes als auch der Seite drin. Die Frage ist nur, ob und wie man diese Einträge in der Logfileanalyse-Software zusammenbringen kann.

Ende im Gelände?

Auch in der neuen Bildersuche gibt es durchaus Möglichkeiten, die Nutzer der Bildersuche zu erkennen. Mit ein paar technischen „Tricks“ ist das Tracking im Logfile und in Google-Analytics möglich.

Falls jemand von Euch diese Trackingtechniken nutzt, würden mich Euere Erfahrungen damit, besonders bezüglich Google-Analytics, interessieren. Schreibt es in die Kommentare! :-)

0 Kommentare »

Heiße Links und kalter Kaffee, Bildersuche aufgewärmt (Teil 2) – Mein Vortrag auf der SEO-Campixx 2017

SEO-Campixx 2017

Schluß mit Lustig! Google hat vor einigen Wochen die „neue“ Bildersuche auch in Deutschland aktiviert. Damit ist Google selbst zur größten Bilder-Hotlinkfarm aufgestiegen.

Was bedeutet das für Nutzer und Webseitenbetreiber? Kann man sich die verlorengegangenen Besucher zurückholen?

Nach einem kurzen Rückblick auf die Entwicklung der Google-Bildersuche präsentiere ich einige Zahlen zur Besucherentwicklung und zeige meine Lösungsansätze für die Besucherrückgewinnung auf.

Letztes Wochenende war die SEO-Campixx 2017 und ich habe am Sonntag um 14:00 Uhr einen Vortrag mit dem Titel „Heiße Links und kalter Kaffee, Bildersuche aufgewärmt (Teil 2)“ gehalten.

Wie versprochen, gibt es hier nun die Folien als PDF und weitere Links zu den im Vortrag genannten Tools und Webseiten:

Falls mir noch etwas einfällt, wird die Liste ergänzt.

0 Kommentare »

Direkte Bild-Aufrufe auf Seite weiterleiten – so gehts

Das Problem

In den letzten Tagen ist die Aufregung ob der neuen Google-Bildersuche recht groß und viele versuchen, einen Ausweg aus den sinkenden Besucherzahlen zu finden.

In der neuen Bildersuche werden die Bilder direkt in Original-Auflösung auf der Ergebnisseite geladen. Der Nutzer hat also wenig Anlaß, die Ursprungsseite zu besuchen.

Google-Bildersuche: Links zu Seite/Bilder

Immerhin gibt es vier Links (grün), die den Benutzer auf die Ursprungsseite mit dem Bild führen. Dazu kommt ein Link direkt zum Bild [Bild ansehen] und indirekt die Möglichkeit, per Rechtsklick und „Grafik anzeigen“ nur das Bild aufzurufen.

Der direkte Link zum Bild bringt allerdings keine Besucher auf die Seite. Daher gibt es die Idee, den direkten Aufruf eines Bildes aus der Bildersuche auf eine Seite mit dem Bild umzuleiten.

Achtung!
Lest bitte vorher die Hinweise von Google zu „Bilder-Cloaking“ und überlegt Euch, ob Ihr das Riskio eingehen wollt.

So gehts

Um zu erkennen, ob jemand von der Bildersuche kommt, kann man den Referrer auswerten. Vereinfacht gesagt, könnte man folgende Regel formulieren:

„Ist die Referrer-Domain google.* und die angeforderte Datei ein Bild (jpeg,png,…), dann leite den Nutzer auf eine Seite mit dem Bild um.“

In der .htaccess könnte das so aussehen:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /

RewriteCond	%{REQUEST_FILENAME} -f
RewriteCond	%{HTTP_REFERER}	^http(s)?://(www\.)?google [NC]
RewriteRule	\.(jpg|png|gif)$	/redirect.php	[L]
</IfModule>

Zunächst wird Rewrite eingeschaltet und die Basis festgelgt.
Dann wird geprüft, ob es die angeforderte Datei überhaupt gibt und ob der Referrer Google ist. Falls ja und die Datei ein Bild ist, wird das PHP-Skript zur Weiterleitung aufgerufen.

So weit, so gut, nur gibt es noch einige Probleme zu lösen.

Leider wird der Referrer auch gesendet, wenn das Bild als Bild auf der Google-Seite geladen wird. Da soll natürlich keine Weiterleitung erfolgen, weil das im Kontext eines Bilder zu einem Fehler führt. Kann man also unterscheiden, ob das Bild geladen wird oder ein Link auf das Bild aufgerufen wird? Ja, mann kann. Zumindest meistens.

Außerdem wird ein bereits geladenes Bild vom Browser im Cache vorgehalten, was zu unvorhergesehenen Ergebnissen bei der Weiterleitung führen kann. Kann man das verhindern? Ja, man kann.

Meine Problemlösungen

Als technische Basis setze ich einen Apache-Server mit den aktiven Modulen mod_rewrite, mod_headers und mod_setenvif voraus. Wobei das Modul mod_setenvif nicht zwingend erforderlich ist, es macht die Sache aber übersichtlicher:

<IFModule mod_headers.c>
Header	set	 Cache-Control "no-cache, no-store, must-revalidate"	env=NO_CACHE
Header	unset	 Expires	env=NO_CACHE
Header	unset	 Last-Modified	env=NO_CACHE
Header	unset	 ETag	env=NO_CACHE
</IfModule>

<IfModule mod_setenvif.c>
SetEnvIf Accept "text/html"	REQ_HTML=1
SetEnvIf Referer "^https?://(([^\.]+?\.)?([^\.]+?\.)?[^\.]+?)/"	DOM_REFERER=$1
</IfModule>

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /bilder

RewriteCond	%{REQUEST_FILENAME} -f
RewriteRule	\.(jpg|gif|png)$	-	[NC,C]

RewriteCond	%{ENV:DOM_REFERER}	google\.de$ [NC,OR]
RewriteCond	%{ENV:DOM_REFERER}	google\.at$ [NC,OR]
RewriteCond	%{ENV:DOM_REFERER}	google\.ch$ [NC,OR]
RewriteCond	%{ENV:DOM_REFERER}	example\.com
RewriteRule	.*	-	[E=DO_RDR:1,E=NO_CACHE:1]

RewriteCond	%{ENV:REQ_HTML} 1
RewriteCond	%{ENV:DO_RDR} 1
RewriteRule	([^-]+)-([0-9]+)\.(jpg|gif|png)$	/bild-$1-$2.html	[R=302,L]
</IfModule>

Zur Unterscheidung von Bildaufruf (img src=…) und Link verwende ich den Wert von „Accept“ im HTTP-Request-Header. Nach meiner Beobachtung enthält dieses Header-Feld bei Bild-Aufrufen nicht den Typ „text/html“, beim Aufruf von Links, auch zu Bildern, aber schon. Wenn also „text/html“ im Accept-Header zu finden ist, dürfte es sich um den Link zum Bild und nicht um das Laden des Bildes in der Google-Ansicht handeln.

<IfModule mod_setenvif.c>
SetEnvIf Accept "text/html"	REQ_HTML=1
SetEnvIf Referer "^https?://(([^\.]+?\.)?([^\.]+?\.)?[^\.]+?)/"	DOM_REFERER=$1
</IfModule>

Den Accept-Header werte ich in einer SetEnvIf Anweisung aus und setze eine entsprechende Variable, die ich später in den Rewrite-Regeln auswerten kann. Zudem extrahiere ich in dem Block den Domain-Namen aus dem Referer, da ich diesen auch in anderen Rewrite-Regeln benötige.

RewriteCond	%{REQUEST_FILENAME} -f
RewriteRule	\.(jpg|gif|png)$	-	[NC,C]

Mit den Rewrite-Regeln prüfe ich zunächst die Existenz der Datei und über die Datei-Erweiterung, ob ein Bild aufgerufen wird. Falls nicht, wir der zweite Block der Rewrite-Regeln gar nicht erst ausgeführt.

RewriteCond	%{ENV:DOM_REFERER}	google\.de$ [NC,OR]
RewriteCond	%{ENV:DOM_REFERER}	google\.at$ [NC,OR]
RewriteCond	%{ENV:DOM_REFERER}	google\.ch$ [NC,OR]
RewriteCond	%{ENV:DOM_REFERER}	example\.com
RewriteRule	.*	-	[E=DO_RDR:1,E=NO_CACHE:1]

Im zweiten Block wird eine Liste von Referrer-Domains abgearbeitet, für die die Weiterleitung erfolgen soll. In dem Fall sind es die drei Google-Domains, von denen die meisten meiner Besucher kommen (exemple.com ist nur ein Platzhalter). Die Abfrage nach dem Referer kann man natürlich auch anders gestalten. Das hängt halt davon ab, was man damit erreichen will. Hier setze ich mir wieder ein Flag (DO_RDR), das ich später für die Weiterleitung auswerte.

<IFModule mod_headers.c>
Header	set	 Cache-Control "no-cache, no-store, must-revalidate"	env=NO_CACHE
Header	unset	 Expires	env=NO_CACHE
Header	unset	 Last-Modified	env=NO_CACHE
Header	unset	 ETag	env=NO_CACHE
</IfModule>

Außerdem setze ich einen Wert (NO_CACHE), mit dem am Ende geprüft wird, ob das Caching deaktiviert werden soll. Der Block mod_headers steht zwar am Anfang, der Webserver führt diese Anweisungen aber erst ganz zum Schluß aus, kurz bevor die Antwort an den Client gesendet wir. Damit wird das Caching des von Google direkt geladenen Bildes verhinert.

RewriteCond	%{ENV:REQ_HTML} 1
RewriteCond	%{ENV:DO_RDR} 1
RewriteRule	([^-]+)-([0-9]+)\.(jpg|gif|png)$	/bild-$1-$2.html	[R=302,L]

Im dritten Rewrite-Block erfolgt dann die Weiterleitung, falls es sich um einen Link-Request (REQ_HTML) handelt und eine Weiterleitung überhaupt ausgeführt werden soll (DO_RDR).

Wohin weiterleiten?

Ein weiteres Problem kann die eigentliche Weiterleitung sein. Wohin soll die Reise gehen?

Im Beispiel ist das relativ einfach. Die Bilder liegen in einem Unterverzeichnis /bilder/ und der Dateinamen besteht aus Bezeichnung und laufender Nummer. Die Zielseiten mit den Bildern bestehen auch aus Bezeichnung und laufender Nummer. Damit läßt sich schon in der .htaccess Datei die Weiterleitungsregel unmittelbar formulieren.

/bilder/tomaten-7.jpg -> /bild-tomaten-7.html
/bilder/banane-23.jpg -> /bild-banane-23.html
...

Schön, wenn man so eine klare Struktur für seine Bilder hat. Ich habe die leider nicht. :-)

RewriteCond	%{ENV:REQ_HTML} 1
RewriteCond	%{ENV:DO_RDR} 1
RewriteRule	.*	/rdr.php	[L]

Also muß die Weiterleitung z.B. von einem PHP-Skript erledigt werden, in dem man dann praktisch beliebige Weiterleitunsziele adressieren kann.

In WordPress gibt es für die über die Mediathek hochgeladenen Bilder jeweils eine Attachment-Seite. Nun könnte man sich die Informationen zum Weiterleitungsziel aus der WP-Datenbank holen. Aus Performance-Gründen habe ich da einen etwas anderen Weg gewählt.

Für WordPress, wie z.B. hier bei schnurpsel.de, sieht das rdr.php-Skript so aus:

<?php
define( 'THISPATH', dirname(__FILE__) . '/' );
@include( THISPATH.'redir.php' );

function set_404() {
	header( "HTTP/1.0 404 Not Found", true, 404 );
	echo <<<EOT
<!DOCTYPE html>
<html>
<head><title>404 Not Found</title></head>
<body>
<h1>Not Found</h1>
<p>The requested URL was not found on this server.</p>
</body></html>
EOT;
	exit;
}

function set_header( $ctype ) {
	@header( "Content-type: $ctype" );
	@header( 'Cache-Control: no-cache' );
	@header( 'Cache-Control: max-age=0', false ); 
	@header( 'Expires:'.gmdate('D, d M Y H:i:s', 0 ).' GMT' );
}

function redirect( $url, $status = 302 ) {
	@header( 'Cache-Control: no-cache, no-store, must-revalidate' );
	@header( "Location: $url", true, $status );
	exit();
}

$img_uri = urldecode( $_SERVER['REQUEST_URI'] );
$redir_url = $redir_b[$img_uri];

if( !$redir_url && @preg_match( '~(.+?)-(1600|1200)\.(jpg|png|gif)$~', $img_uri, $treffer ) ) {
	$redir_url = $redir_b[$treffer[1].'.'.$treffer[3]];
}

if( $redir_url )
	redirect( $redir_url );
else {
	$img_file = THISPATH.$img_uri;
	$img_size = @getimagesize( $img_file );
	if( $img_size ) {
		set_header( $img_size['mime'] );
		@readfile( $img_file );
		exit;
	}
}
set_404();
?>

Download: rdr.zip

In meinem rdr-Skript includiere ich eine weitere PHP-Datei (redir.php), die nur ein Array mit den Weiterleitungszielen für die Bilder enthält. Falls kein Weiterleitungsziel gefunden wird, gebe ich einfach das Bild selbst aus.

Die redir.php PHP-Datei lasse ich mir von einem Skript durch WordPress erstellen:

<?php
define( 'THISPATH', dirname(__FILE__) . '/' );
define( 'WP_USE_THEMES', false );
define( 'USE_ATTACHMENT_URL', true );

@include( THISPATH.'redir.php' );

require('./wp-blog-header.php');

echo '<pre>';

$args = array( 'post_type' => 'attachment', 'posts_per_page' => -1, 'post_mime_type' => 'image', 'post_parent' => null ); 
$attachments = get_posts( $args );
if ( $attachments ) {
	foreach ( $attachments as $post ) {
		$attachment_url = wp_get_attachment_url( $post->ID );
		$attachment_uri = @parse_url( $attachment_url, PHP_URL_PATH );
		if( USE_ATTACHMENT_URL )
			$page = get_attachment_link( $post->ID );
		else
			$page = get_permalink( $post->post_parent );
		if( $page && $attachment_uri && !$redir_b[$attachment_uri] ) {
			if( strpos( $page, 'attachment_id' ) === false ) {
				$redir_b[$attachment_uri] = $page;
				echo "+ $attachment_uri -> $page\r\n";
			}
			else
				echo "- $attachment_uri -> $page\r\n";
		}
		else
			echo "* $attachment_uri -> $page\r\n";
	}
}

$export_data = "<?php\r\n\$redir_b = ";
$export_data .= var_export( $redir_b, true );
$export_data .= ";\r\n\r\n?>";
file_put_contents( THISPATH.'new_redir.php', $export_data );
echo '</pre>';
?>

Download: get-redir.zip

Mit der Konstante ‚USE_ATTACHMENT_URL‘ wird festgelegt, ob die Weiterleitung auf die Attachment-Seite (true) oder zur Artikel-Seite mit dem Bild (false) erfolgen soll.

Zum Anfang wird die bestehende ‚redir.php‘ geladen. Es werden dann nur Einträge hinzugefügt, die es noch nicht gibt.

Außerdem prüfe ich, ob es die Attachment-Seite wirklich gibt, denn für Bilder ohne Eltern-Seite bzw. Bilder in nicht veröffentlichten Artikeln wird kein Permalink zurückgeliefert, sonder nur die URL mit dem ‚attachment_id‘-Parameter.

Am Ende wird eine neue Datei ’new_redir.php‘ geschrieben, mit der man dann die alte ‚redir.php‘ ersetzen kann.

Folgende Dateien sind an der Methode beteiligt:
/rdr.php
/redir.php
/wp-content/uploads/.htaccess

In der .htaccess-Datei muß die RewriteBase entsprechend angepaßt werden:

RewriteBase /wp-content/upload

Für meine Putzlowitscher Zeitung enthält das Array etwas mehr als 2000 Einträge. Das ergibt eine Dateigröße von ca. 350k. Wer deutlich mehr Bilder in WP verwaltet, muß sich ggf. etwas anderes einfallen lasse.

So ein Array hat aber den Vorteil, daß ich darin auch beliebige, andere Weiterleitungsziele definieren kann.

Noch ein paar Tips und Hinweise

Falls sich alle Eure Bilder in einem Unterverzechnis befinden, bei WordPress z.B. /wp-content/uploads/, dann packt die .htaccess-Datei genau dort rein. Für alle anderen, normalen Seitenaufrufe wird sie dann gar nicht erst abgearbeitet.

Was irgendwie möglich ist, sollte schon in der .htaccess-Datei erledigt werden. Der Aufruf eines Skriptes, eventuell sogar mit Datenbankabfragen, kostet mehr Server-Leistung und verschlechtert die Performance.

Ihr könnt sogar unterscheiden, ob jemand den Button [Bild ansehen] angeklickt oder per Rechtsklick das Bild aufgerufen hat. Beim Rechtsklick wird ggf. vom Browser als Referer die komplette Google-Such-URL übermittelt. Das kann man zur Unterscheidung auswerten, z.B. ob der Parameter tbm=isch im Referer enthalten ist.

Das Speichern mit Rechtsklick auf das Original-Bild in der Bildersuche funktioniert nicht. Es wird die HTML-Seite des Weiterleitungs-Ziels gespeichert. :-)

Ich habe bisher nur mit wenigen Browsern getestet. Bei denen hat es aber funktionert, wie es soll.

Ich übernehme keine Haftung für Schäden, die möglicherweise durch die Umsetzung der hier vorgestellten Methoden entstehen.

13 Kommentare »

Für bestimmte Domains ein Ersatzbild anzeigen – meine Lösung

Die „neue“ Google-Bildersuche

Google-Bildersuche: Neues Layout in DE

In der „neuen“ Google-Bildersuche wird beim Klick auf ein Ergebnis das Bild direkt in der Bildersuche in voller Auflösung geladen und angezeigt. Das dürfte viele Nutzer davon abhalten, die Ursprungsseite zu besuchen.

Die Idee ist es, dem Nutzer innerhalb der Google-Bildersuche eine Bild in schlechter Qualität (unscharf/verpixel) mit einem zusätzlichen Hinweistext anzuzeigen.

Achtung!
Lest bitte vorher die Hinweise von Google zu „Bilder-Cloaking“ und überlegt Euch, ob Ihr das Riskio eingehen wollt.

Technische Basis

Um zu erkennen, ob das Bilder in der Google-Bildersuche angezeigt wird, muß der HTTP_REFERER ausgewertet werden. Das funktioniert aber nur, wenn die eigene Seite mit https läuf. Von einer Seite mit SSL (Google-Suche) wird kein Referrer zu einer Seite ohne SSL übermittelt.

Das Erstellen der veränderten Bilder erfolgt On-The-Fly per PHP-Skript. Die so erstellten Bilder werden zwischengespeichert und beim nächsten Aufruf dann ggf. direkt ausgeliefert. Damit fällt die nicht gerade ressourcenschonende Bildbearbeitung nur beim ersten Aufruf des Bildes an.

Die Umsetzung

In der .htaccess-Datei habe ich folgende Verzweigung eingebaut:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /

RewriteCond	%{HTTP_REFERER}	^https?://(([^\.]+?\.)?([^\.]+?\.)?[^\.]+?)/ [NC]
RewriteRule	.* - [E=DOM_REFERER:%1]

# Für bestimmte Ref-Domains verändertes Bild ausliefern
RewriteCond	%{REQUEST_FILENAME} -f
RewriteRule	\.(jpg|png)$	-	[NC,C]
RewriteCond	%{ENV:DOM_REFERER}	google\.de$ [NC,OR]
RewriteCond	%{ENV:DOM_REFERER}	google\.at$ [NC,OR]
RewriteCond	%{ENV:DOM_REFERER}	google\.ch$ [NC,OR]
RewriteCond	%{ENV:DOM_REFERER}	example\.com
RewriteRule	.	/geb/index.php	[L]
</IfModule>

Im ersten Block wird Rewrite eingeschaltet und die Basis festgelgt.

Im zweiten Block extrahiere ich den den Domainnamen aus dem Referrer und speichere ihn in einer Umgebungs-Variablen ab. Das vereinfacht die Bedingungen im nächsten Block.

Die eigentliche Verzweigung erfolgt im nächsten Block. Hier prüfe ich zunächst, ob es die angforderte Datei überhaupt gibt und ob es sich um ein Bild handelt. Falls nicht, werden die nachfolgenden Bedingungen gar nicht erst abgearbeitet.
In der folgenden Liste (Black-List) wird geprüft, ob für die Referrer-Domain ein verändertes Bild ausgeliefert werden soll. Falls ja, wird das PHP-Skript aufgerufen.

Das PHP-Skript befindet sich im Unterverzeichnis /geb/ als Index-Datei. Außerdem ist hier das Cache-Verzeichnis und der True-Type-Font für die Textausgabe mit GD enthalten:

/geb/
/geb/index.php
/geb/font.ttf
/geb/cache/
/geb/cache/.htaccess

Das Cache-Verzeichnis muß vom Webserver/PHP beschreibbar sein. Es wird mit einer .htaccess-Datei vor dirketen Zugriffen geschütz:

<Files *>
order deny,allow
deny from all
</Files>

Das PHP-Skript

Index.php

Im PHP-Skript habe ich z.Z. zwei Funktionen implementiert, die die Bilder verändern.

Eine Funktion (proc_gd) benutzt die GD-Erweiterung und erzeugt ein verpixeltes Bild. Für die Textausgabe wird unbedingt eine Font-Datei (font.ttf) benötigt.

Die andere Funktion (proc_imagick) benutzt die Imagick-Erweiterung, die bei vielen Webhostern aber nicht zum Standard gehört. Hier wird das Bild unscharf gemacht. Für die Textausgabe wird ein interner Font benutzt.

0 Kommentare »

Google Bilder-Liste – ein neues Bookmarklet für die Google Bildersuche

Bookmarklets

Die Bookmarklets sind feine Sachen, denn man kann tolle Dinge damit machen. :-)

Ein Bookmarklet ist ein Browser-Lesezeichen, welches aber nicht die URL einer Webseite speichert, sondern Javascript-Code. Dieser kann dann auf eine gerade im Browserfenster angezeigte Webseite losgelassen werden.

Das Bookmarklet hat Zugriff auf den kompletten Seiteninhalt, kann diesen verändern oder Daten extrahieren und z.B. in einem neuen Fenster darstellen.

Vor einiger Zeit hatte ich bereits mal ein Bookmarklet angepaßt, war nur aber nun nicht mehr ganz damit zufrieden. Besonders die Konfiguration über einen einfachen Eingabedialog waren mir zu wenig komfortabel.

So habe ich eine neue Version des Bookmarklets entwickelt, mit anderere Darstellung, mehr Optionen und einer Exportfunktion.

Google Bilder-Liste

Bookmarklet – Google Bilder-Liste (1.3)

So sieht die Trefferliste der Google-Bildersuche für Brötchen nach Aufruf des Bookmarklets aus. Die Ausgabe ist gefiltert, Google findet natürlich mehr Brötchen-Bilder als nur drei. :-)

Die Liste

Die Tabelle zeigt in der ersten Spalte das Thumbnail und die Bildgröße, in der zweiten die Position in der Bildersuche an. In der dritten Spalte findet man untereinander Bild-Id, Bild-URL und Seiten-URL (Referenz). Die Kästchen davor geben durch verschieden Farben Auskunft über den Status.

Für Bild-ID, Bild-URL und Seiten-URL bedeutet grün, daß es sich um ein eigenes Bild bzw. eine eigene Seite handelt. Ist das Kästchen vor der Seiten-URL gelb, kommt der Treffer von einer erlaubten Domain, die aber keine eigene ist.

Das rote Kästchen zeigt einen Hotlink bzw. eine Bildkopie an. Das Bild ist also ein eigenes Bild (ID oder Bild-URL), die Seite ist jedoch nicht in der Liste der eigenen oder erlaubten Domains zu finden.

Ein Klick auf eines der Kästchen zeigt folgendes an:

Bild-Id: Google Suche mit weiteren Seiten, die das Bild verwenden
Bild-URL: das Bild
Seiten-URL: die Seite mit dem Bild

Die Links hinter der Bild ID rufen die jeweilige Google-Suche für das Bild auf.

Die Optionen

Im oberen Berich kann man Ausgabe-Filter festlegen. Folgende Optionen sind für die Anzeige möglich:

(●) Alle Bilder
alle Bilder, die in der Google-Trefferliste vorhanden sind
(●) Eigene Bilder
Bilder, die in der Liste der eigenen Domains oder bei den gespeicherten Bild-IDs zu finden sind
(●) Eigene Seiten
Seiten, die in der Liste der eigenen Domains zu finden sind
(●) Hotlinks/Kopien
Eigene Bilder, bei denen die Seite nicht in der Liste der eigenen oder erlaubten Domains zu finden ist
(●) Gefilterte Seiten
Seite, die in der Domain-Filter Liste zu finden sind

Die Option [x] Filter negieren dreht die Logik um. Das beutet z.B. für die Option Eigene Seiten, daß nun alle Seiten angezeigt werden, die nicht in der Liste der eigenen Domains zu finden sind.

Mit der Option [x] Nur ein Treffer pro Domain wird nur der jeweils erste Treffer einer Domain angezeigt.

Die Aktionen

Einzige Aktion ist im Moment der Download der Bilderliste als CSV-Datei mit CSV Download. Die Liste wird so ausgegeben, wie sie gerade angezeigt wird. Die Felder sind mit Semikoln getrennt. Damit können die Daten einfach z.B. in Excel weiterverarbeitet werde.

Google Bilder-Liste Konfiguration

Bookmarklet – Google Bilder-Liste Konfiguration

Mit dem Konfigurations-Bookmarklet können die Domainlisten und Optionen verwaltet werden.

Welche Liste wofür benutzt wird, geht aus Beschreibung oben zu den Filtern hervor.

Der Text im Eingabefeld wird mit [Hinzufügen] der Liste hinzugefügt. Dabei wird nicht geprüft, ob es sich syntaktisch um eine Domain handelt. Die Text ist ohne http:// und / am Ende einzugeben, also nur der Domainname. Es konnen auch mehrere Namen mit Leerzeichen, Komma oder Semikolon getrennt eingegeben/eingefügt werden.

Mit [Löschen] werden Einträge aus der Liste gelöscht. Eine Mehrfachauswahl ist möglich. Die aktuelle Liste kann mit Download als Textdatei heruntergeladen werden. Die Einträge sind mit Semikolon getrennt.

Mit Optionen kann die Voreinstellung für das Anzeigefilter festgelegt werden.

Zu guter Letzt und gaaanz wichtig, mit [Einstellungen speichern] werden die Einstellungen übernommen.

Die Listen der Domains und die Optionen werden im localStorage gespeichert, was bei sehr alten Browsern nicht funktioniert. Zudem müssen Cookies für die Google-Domain erlaubt sein.

Die Bookmarklets

Aktuelle Version: 1.4

Google Bilder Liste Google Bilder Konfig Google Bilder IDs

Die Bookmarklets sind zwar Links, es macht aber wenig Sinn, diese hier direkt anzuklicken. Vielmehr müßt Ihr sie als Lesezeichen im Browser speichern, also z.B. einfach in die Bookmarkleiste ziehen.

Hinweise zur Benutzung

Dann ruft Ihr die Google-Bildersuche mit dem gewünschten Suchbegriff auf und startet das Bookmarklet durch Anklicken des Lesezeichens (Buttons in der Lesezeichenleiste).

Bookmarklet – Google Bilder-Liste Anwendung

Google stellt in der Bildersuche direkt nach dem Aufruf zunächst die Liste der ersten 100 Treffer bereit. Falls Ihr mehr Ergebnisses in der Liste haben wollt, müßt Ihr mit dem Scrollbalken rechts ganz nach unten Scrollen. Dann werden ggf. weitere 300 Suchergbnisses nachgeladen. Die Liste ist somit 400 Treffer. Gibt es noch mehr Treffer, ist ganz unten eine Schaltfläche [] zu sehen. Damit werden die nächsten 100 Treffer geladen. Und auch hier gilt, wollt Ihr die komplete Liste haben, müßt Ihr ganz nach unten scrollen.

Das Bookmarklet funktioniert mit der Google-Bildersuche und auch mit den speziellen Funktionen wie „Weitere Größen“ und „Optisch ähnkich“.

Suche mit Bild

Bei der „Suche mit Bild“ ist eine Besonderheit zu beachten.

Hier wird von Google eine andere Darstellung als in der Bildersuche verwendet. Sie entspricht eher der normalen Such und ist entsprechend seitenweise (je 10 Treffer) strukturiert. Um alle Treffer zu erfassen, öffnet und schließt das Bookmarklet die jeweiligen Trefferseiten.

Da hier der Browser zunächst das Öffnen neuer Fenster anmeckert, müßt Ihr das erlauben, damit das Erstellen der List klappt. Ansonsten bleibt der Prozeß einfach stehen. Und es dauert je nach Seitenzahl etwas länger, bis alle Daten erfaßt sind.

Getestet habe ich die Bookmarklets bisher mit Firefox 44.0.2 und Google Chrome 49.0.2623.87, damit funktioniert es. Mit dem Internet Explorer 9.0 funktioniert es nicht, dem sind die URLs zu lang.

Viel Spaß beim finden Eurer Bilder! :-)

1 Kommentar »

Das Problem mit WordPress und den ungültigen URL-Parametern

WordPress hat ein Problem mit ungültigen URL-Parametern. Wenn jemand an die Blogadresse einfach einen Parameter mit einem Wert anhängt, wird das von WP klaglos akzeptiert, obwohl es völlig unsinnige Werte sein können.

Ein Beispiel:
http://vierzehnfuffzig.de/?url=http://www.heise.de
oder
http://vierzehnfuffzig.de/?blafasel=trallalla
oder was auch immer.

In allen Fällen gibt WordPress brav die Startseite meines Test- und Probierblogs aus. Das ist aus SEO-Sicht natürlich schlecht, denn es kann dadurch ganz viel DC enstehen.

Die Abhilfe ist recht simpel, die URL-Parameter müssen einfach gegen die in WordPress bekannten Parameter getestet werden. Das sind nur ein paar Zeilen PHP-Code.

Ich habe das mal in eine kleines Plugin verpackt, welches ich hier zum Download anbiete: 123 Check URL Para Version 0.11

Das war’s, mehr wird nicht benötigt. Probleme könnte es nur geben, falls Plugins oder Themes URL-Parameter verwenden, die nicht in WordPress registriert wurden. Das ist dann aber schlecht programmiert. E sgibt jetzt im Plugin-Quelltext weitere erlaubte Parameter einzutragen:

$para = array( 'p1', 'p2', 'p3' );  // zusätzlich erlaubte URL-Parameter

Einfach die erlaubten Parameter im array wie im Beispiel oben eintragen.

5 Kommentare »

Ein Bookmarklet für die Google Bildersuche

Bookmarklets

Die Bookmarklets sind feine Sachen, denn man kann tolle Dinge damit machen. :-)

Ein Bookmarklet ist ein Browser-Lesezeichen, welches aber nicht die URL einer Webseite speichert, sondern Javascript-Code. Dieser kann dann auf eine gerade im Browserfenster angezeigte Webseite losgelassen werden.

Das Bookmarklet hat Zugriff auf den kompletten Seiteninhalt, kann diesen verändern oder Daten extrahieren und z.B. in einem neuen Fenster darstellen.

Genau Letzteres war der Anlaß, aß ich mich nun mit Bookmarklets beschäftige. Bisher wußte ich noch nicht mal etwas von deren Existenz.

Ein Bookmarklet für die Google Bildersuche

Bei Facebook fragte David Radicke vor einigen Tagen, ob nicht jemand ein Tool/Addon/Bookmarket kennt, mit welchem man in der Google Bildersuche nur die URLs anzeigen kann.

Daraufhin bekam er eine Lösung programmiert. Dieses Bookmarklet von Chris Ainsworth ist schon eine feine Sache. Es extrahiert aus der Ergebnisseite der Google-Bildersuche die URLs der Bilder und der referenzierenden Seiten und zeigt sie in einer übersichtlichen Tabelle an.

Aber zur Bildersuche gehören irgendwie auch die Bilder. Also habe ich das Javascript etwas angepaßt und erweitert:

  • in der ersten Spalte werden die Thumbnails und die Bildgröße angezeigt
  • das Bookmarklet funktioniert ohne Änderung für alle Google-Länderdomains
  • man kann sich eigene Bilder und ggf. fremde Hotlinks farblich hervorheben lassen

Das Ergebnis sieht dann in etwa so aus:

Google Image Extractor with Thumbnails

Hier findet Ihr das Bookmarklet, welches die Tabelle erzeugt:

Google Img Extractor

Quellcode: img-extractor-tbn.js

Google Image-Extractor Domains-Config

Hier findet Ihr das Bookmarklet, mit welchem ihr die Liste der eigenen Domains befüllen könnt:

Google Img Domains

Quellcode: img-extractor-para.js

Die Bookmarklets sind zwar Links, es macht aber wenig Sinn, diese hier direkt anzuklicken. Vielmehr müßt Ihr sie als Lesezeichen im Browser speichern, also z.B. einfach in die Bookmarkleiste ziehen.

Dann ruft Ihr die Google-Bildersuche mit dem gewünschten Suchbegriff auf und startet das Bookmarklet durch Anklicken des Lesezeichens (Buttons in der Lesezeichenleiste).

Die Liste der eigenen Domains wird im localStorage gespeichert, der aber nur bei neueren Browsern funktioniert. Zudem müssen Cookies für die Google-Domain erlaubt sein.

Getestet habe ich die Bookmarklets bisher mit Firefox 35.0.1 und Google Chrome 40.0.2214.94, damit funktioniert es.
Die Tests mit anderen Browsern überlasse ich Euch. :-)

4 Kommentare »