Das Putzlowitsch Test- und SEO-Blog
Stichwort: Bildersuche

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 Geä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, beosonders bezüglich Google-Analytics, interessieren. Schreibt es in die Kommentare! :-)

0 Kommentare »

Auswirkung der neuen Google Bildersuche auf die Universal-Search Bilderbox

Die Google Universal-Search Bilderbox

Schon seit längerer Zeit zeigt Google innerhalb der organischen Suche (Textsuche) auch ausgewählte Ergebnisse der speziellen „Suchmaschinen“, wie Bilder, Videos, Nachrichten (Schlagzeilen) und lokale Suchtreffer aus Google Maps an.

Die eingeblendeten Spezialergebnisse dieser „Universal Search“ werden in kleinen Fenstern (Onebox) angezeigt.

Welche Bilder mit welchem Linkziel in der Bilderbox erscheinenn, ist nicht wirklich nachvollziehbar. Es sind nicht unbedingt die ersten Treffer aus der Bildersuche. Es kann sogar passieren, das ein Bild in der Universal-Search-Box nicht unter den ersten 100 Treffern in der Bildersuche zu finden ist.

Selbst wenn das gleiche Bild in der Bilder-Box und in der Bildersuche angezeigt wird, kann das Linkziel unterschiedlich sein.

Das Beispiel Geld

Google-Suche Bilder-Box: Geld

Der Screenshot (von gestern) zeigt die Bilderbox für die Suche nach Geld.

Vor der Einführung des neuen Layouts der Google-Bildersuche führte der Klick auf ein Ergebnis, wie in der Bildersuche auch, in einem Frameset zur Zielseite. Mit einem „Framebreaker“ konnt das Frameset entfernen werden, so daß nur noch die eigene Seite angezeigt wurde.

Der mittlere Treffer hat als Linkziel lt. Tooltip eine Hotlink-Bilderspam-Seite bei dyndns-wiki.com, die es mittlerweile aber schon nicht mehr gibt. In der alten Bildersuche wäre man beim Klick auf das Bild genau auf dieser Seite gelandet.

Durch die neuen Bildersuche wird man nun aber zur Suchergebnisseite mit der großen Darstellung des Original-Bildes weitergeleitet. So weit, so gut.

Doch was passiert nun beim Klick z.B. auf [Seite besuchen]?
Ich habe das mal in einem Video aufgezeichnet und hoffe, man kann es erkennen:

Der Klick führt nicht etwa zur Hotlink-Farm, sondern zur Ursprungsseite des Bildes.

Das liegt aber nicht daran, daß Google etwas Grundlegendes gegen den Hotlink-Spam unternommen hätte, sondern daran, daß zu dem Zeitpunkt für dieses Bild in der Bildersuche eine andere Seite als Linkziel verknüpft war.

Es hätte also auch anderes herum sein können. Das Bild hat in der Bilderbox als Linkziel die Ursprungsseite, in der Bildersuche aber eine andere Seite. Dann würde man entprechend auf der Seite landen, die in der Bildersuche rankt.

Das geht sogar soweit, daß man ggf. aus der Bilderbox wieder direkt zur Zielseite geführt wird, nämlich dann, wenn das Bild in der Bildersuche nicht unter den ersten 100 Treffern zu finden ist. Die ersten 100 Treffer deshalb, weil diese in der Bildersuche dirket geladen werden. Alles weiteren Ergebnisse werden erst beim Scrollen per Javascript nachgeladen.

Bei meinen Tests ist das einmal passiert und ich dachte schon an ein besonders trickreiches Weiterleitungs-Script, zumal die Zielseite eine der üblchen .tk-Hotlink-Farmen war. Bei einem zweiten Bild mit dem selben Linkziel landete ich aber ganz normal auf der Ergebnisseit der Bildersuche. Ich hab dann mal geschaut, ob das erste Bild dort zu sehen ist. War es nicht, das zweite aber schon.

Was mir sonst noch so in der Bildersuche aufgefallen ist

Bilder werden wieder schneller von Google in den Index aufgenommen. Ich seh mir das gelegentlich mit der site-Abfrage und dem Parameter tbs=qdr:w2 (Ergbnisse der letzten zwei Wochen) an.

Es gibt weniger Universal-Search Bilderboxen auf der ersten Trefferseite. Das ist aber nur so ein Gefühl. Seit SEOlytics von Sistrix übernommen wurde, steht mir kein SEO-Tool mehr mit entsptrechenden Daten zur Verfügung.

Google-Bilder-Box: Geld (sehr dynamisch)

Die Bilder in der Bilderbox sind recht dynamisch geworden. Vom gestrigen Screenshot sind aktuell nur noch zwei Bilder übrig geblieben. Auch heute gab es schon fröhliche Wechsel der Bilder und Positionen.

Was habt Ihr so für interessante Beobachtungen in der Bildersuche gemacht?

4 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.

12 Kommentare »

Google-Bildersuche: Neues Galerie-Layout nun auch in DE

Google-Bildersuche: Neues Layout in DE

Nun ist es also passiert. Das „neue“ Google-Layout wird auch bei der Bildersuche in Deutschland (google.de) angezeigt. Wirklich neu ist das Galerie-Layout nicht, denn in praktisch allen anderen Ländern einschließlich AT und CH ist es schon seit 2013 aktiv. Für DE gab es praktisch noch eine Schonfrist, die nun abgelaufen zu sein scheint.

Hier das Ganze nochmal als Video:

Mal sehen, wie sich das nun auf meinen Bilder-Traffic auswirken wird…

Und außerdem darf ich jetzt wieder diverse Skripte anpassen, die die Bildersuche auswerten. Na schönen Danke, Google! :-)

Update 08.02.2017
Die Skripte sind soweit angepaßt. Mein Bildersuche-Bookmarklet funktioniert wieder wie es soll. Auch die Datenerfassung für bidox und bibeo sind auf dem neuesten Stand.

Was mir noch aufgefallen ist. Durch die neue Ergebnisanzeige in der Bildersuche werden auch Bilder in Originalgröße geladen, die möglicherweise gar nicht angezeigt werden.

Google-Bildersuche: Neues Layout (Preload)

Wie man in der Debug-Console sieht (rot hervorgehoben), wird zunächst mein Bild geladen (tomate.bilderu.de). Direkt danach werden noch zwei Bilder geladen. Das sind jeweils das nach (marions-kochbuch.de) und vor (berliner-behindertenzeitung.de) meinem platzierte Bild.

Aus Sicht des Nutzers ist das natürlich eine feine Sache. Sofern er sich mit den Navigations-Buttons weiter bewegt, wird das nächste Bild ohne Verzögerung angezeigt. Falls nicht, wurden die Bilder allerdings unnützerweise geladen, verbrauchen Bandbreite und verfälschen die Aufrufstatistik. Aber das ist Google natürlich auch egal.

Weitere Berichte zum Thema:

5 Kommentare »

Google Bildersuche: Bunte Filter-Buttons ersetzen „Verwandte Suchanfragen“

Verwandte Suchanfragen in der Google-Bildersuche

Google-Bildersuche: Verwandte Suchanfragen für Tomaten

Wie in der normalen Textsuche bei Google gibt es auch in der Bildersuche „Verwandte Suchanfragen“. Im Unterschied zur Textsuche werden diese aber nicht am Ende als einfache Textliste angezeigt, sondern ganz oben mit einem Vorschaubild. Dadurch kann man bereits sehen, was einen bei der entsprechenden Suchanfrage für Bilder erwarten.

Google-Bildersuche: Verwandte Suchanfragen für Tomaten Clipart

Beim Klick auf das Vorschaubild oder den Suchtext landet man in der entsprechenden Bildersuche, die ggf. weitere „Verwandte Suchanfragen“ anbietet. Eine schöne Sache, wie ich finde.

Bunte Filter-Buttons in der Google-Bildersuche

Google-Bildersuche: bunte Filter-Buttons für Tomaten

Seit einigen Tagen wir mir in der Bildersuche immer öfter ganz oben anstelle der verwandte Suchanfragen etwas anderes angezeigt. Eine lange Liste mit bunten Flächen, die einzelne Wörter enthalten. Der Klick auf so eine Fläche (Button) setzt ein Filter zusätzlich zum eigentlichen Suchbegriff.

Google-Bildersuche: bunte Filter-Button Tomaten Mozzarella

Auch hier gibt es ggf. wieder eine Liste mit weiteren Filter-Suchbgeriffen. Ein Klick darauf fügt ein neues Filterwort hinzu.

Google-Bildersuche: bunte Filter-Button Tomaten Mozzarella Lasagne

Mit dem kleinen (x) können die Filtrer auch wieder einzeln entfernt werden.

Google-Bildersuche: bunte Filter-Button Tomaten Lasagne

Die bunten Flächen sind farblich nach Begriffskategorien gruppiert, im Fall der Tomaten z.B. nach Farben, weiteren Zutaten, Gerichten und Regionen. Bei der Lasagne ist die Unterteilung noch etwas feiner, z.B. als weitere Zutaten nach Gemüse, Milchprodukten und Fisch/Fleisch.

Besser oder schlechter? Und noch nicht mal wirklich neu!

Ob ich das nun gut oder schlecht finde, kann ich noch nicht wirklich sagen. Im Moment finde ich die alten „Verwandten Suchanfragen“ besser, insbesondere wegen der Vorschaubilder. Man sieht schon vorher so ein bißchen, was man bekommt.

Die bunten Filter-Buttons bieten hingegen viel mehr Optionen und Filtermöglichkeiten. Und sie sind so schon bunt. :-)

Ganz neu sind die bunten Filter-Labels wiederum auch nicht. Bei Google in den USA (und anderen Ländern?) gibt es das bereits seit Mitte März letzten Jahres. Nun wird es scheinbar nach und nach auch hier in Deutschland aktiviert, oder ist es noch eine Art Testphase bei goolge.de?

Habt Ihr die neuen Filter-Buttons auch schon bei google.de in der Bildersuche gesehen?

0 Kommentare »

Frohes neues Jahr 2017 Bilder

Frohes neues jahr 2017 bilder kostenlos, frohes neues jahr 2017 lustige bilder, frohes neues jahr 2017 whatsapp bilder: Wir sind hier mit einigen der beseten Bilder für Neujahr 2017. Alle Menschen auf der Welt verwenden Sie Bilder, um neues Jahr zu wünschen und immer versuchen, einige beste Bilder verwenden, um Familie, Freunde oder Verwandten wünschen.

So dass wir einige beste Neujahr 2017 Bilder anbieten, hatten wir auf der ganzen Welt gereist, um einige beste Bilder für Neujahr 2017 erhalten. Nun, gehen Sie wir um sie aufzudecken. Seien Sie bereit, sie zu ergreifen:

Frohes Neues Jahr 2017 Bilder

Frohes neues Jahr 2017

Frohes neues Jahr 2017

Frohes neues Jahr 2017

Frohes neues Jahr 2017

Frohes neues Jahr 2017

Frohes neues Jahr 2017

Neujahrswünsche 2017: Hallo Freunde, Willkommen auf der Webseite. ich hoffe du machst es gut. Neues Jahr 2017 ist zu beginnen und die meisten von uns sind begeistert, neues Jahr mit neuen Anfang zu beginnen. Wünschen Sie Ihre Freunde und Familie ein glückliches neues Jahr 2017 und mit ihnen Freude teilen.

Wenn Sie für das neue Jahr suchen möchte, sind Sie an der richtigen Stelle. Hier werden wir 2017 Neujahrswünsche in diesem Beitrag zu teilen.

Frohes neues Jahr 2017

Frohes neues Jahr 2017

So haben wir einige eins der besten Bilder für Neujahr 2017 gemeinsam.

Neujahrswünsche 2017

Hier gibt es noch ein Video :-)

Frohes neues Jahr 2017! - Neujahr 2017 - Happy New Year 2017 - Bonne année - Feliz año nuevo

Neue Jahr-Wünsche nehmen Ihre schönen Wörter zu Ihrer Familie, zu Freunden, zu Verwandten, zu Kollegen, zu den Bekannten in der kurzen jeder, das Sie kennen. Aber natürlich verändert sich das Wesen der Glückwünsche mit der Veränderung des Empfängers. Neujahrswünsche Grüße könnten so innig oder so formell sein, wie Sie sie haben wollen.

Sie könnten eine inspirierend glückliche neue Jahr-Grüße 2017 senden, die Grundstein für die Liebe Ihres geliebten Neujahrs legen könnte. Oder Sie könnten eine urkomische paar Zeilen senden, um das neue Jahr der Person mit einem Ring des Lachens zu beginnen.

Für Menschen in Ihrer Nähe sentimental frohes neues jahr 2017 Wünsche würden sicherlich ihr Herz berühren. Es gibt Zillionen von Optionen online und offline, von wo aus Sie eine Idee bekommen können, um Ihre frohes neues jahr 2017 Grüße Rahmen. Aber denken Sie immer daran, Ihre eigene persönliche Note hinzuzufügen, um Ihre Wünsche für neues Jahr ein von einer Art zu machen

Frohes Neues Jahr 2017!

2 Kommentare »

Google Bildersuche Wochenrückblick 2016/21

Die Bidox-Aufsteiger der Woche

Bidox-Gewinner 21. KW 2016

Der letzte Google Bildersuche Wochenrückblick liegt schon ein paar Wochen zurück. Das liegt einfach daran, daß in dieser Zeit nicht wirklich etwas Gravierendes in der Bildersuche passiert ist. In der letzten Woche gab es aber doch ein paar wesentliche Änderungen, die einen ersten Schritt von Google gegen den massiven Spam mit Bilder-Hotlink-Farmen darstellen.

Das Ende der Hotlink-Farmen?

Seit einigen Monaten habe ich eine Hotlink-Erkennung am Laufen, die für etwas mehr als 20 Keywords stündlich die Top-100 der Bildersuche untersucht und Hotlinkfarmen aufspürt. Im April sah das Ergebnis z.B. noch so aus:

Hotlink-Farmen am 18.04.2016

Besonders Websites mit den TLDs .tk, .xyx, und .top waren bei den Hotlink-Spammern sehr beliebt. Die tauchten dann auch regelmäßig bei den Wochengewinnern im Bidox auf [1, 2]. Wie dreist die Spammer teilweise dabei vorgehene, hatte ich hier beschrieben.

Seit Mitte letzter Woche hat sich das Bild verändert. In meinem Hotlink-Finder (HLF) tauchen diese Seiten nicht mehr auf und auch im Bidox sind sie nicht bei den Wochengewinnern zu finden (siehe oben).

Hotlink-Farmen am 30.05.2016

Neben den stündlich aktualisierten Daten aus dem Hotlink-Finder habe ich die Hotlink-Erkennung zusätzlich über die täglich für den BiBeo erhobenen Daten laufen lassen. Auch hier werden mir seit einigen Tagen keine klassischen Hotlink-Seiten mehr abgezeigt.

Außerdem habe ich zu Testzwecken selbst mal ein paar .tk-Domains registriert und mit Bilder-Hotlink-Seiten versehen. Diese habe ich in der Google-Search-Console angemeldet um zu sehen, was mit ihnen passiert. Eine manuelle Maßnahme hat es bisher nicht gegeben, allerdings sind die Klicks seit dem 24. Mai deutlich zurückgegangen.

Klicks für die .tk Testseite

Waren es bisher so zwischen 50 und 100 Klicks am Tag, sind es jetzt nur noch 1 bis 2. Den größten „Erfolg“ für die Spamseite gab es übrigens am Muttertag (8. Mai 2016) mit gut 5000 Klicks. :-)

Die üblichen Verdächtigen (.tk, .xyz, .top …) habe also scheinbar mit Hotlink-Farmen keinen Erfolg mehr in der Bildersuche. Aber…

Umstieg auf Free-Hoster und Subdomains

Wie man im Bidox und auch im HLF sieht, feiert dafür nun eine andere Domain große Erfolge. Die Domain hol.es gehört zum Free-Hoster Hostinger, unter der man als Kunde beliebige Subdomains anlegen kann. Das wird nun von den Hotlinkern neuerdings genutzt, um dem Hotlink-Update zu entkommen. Die Subdomains und Websites, die man dort findet, sehen praktisch genau so aus, wie die bisher unter den TLDs .tk und .xyz zu findenden Hotlink-Farmen.

Insofern wundert es mich ein wenig, daß diese Websites nicht vom Google-Hotlink-Update erkannt werden.

Gehackte Seiten mit Hotlinks weiter ein Problem

Der Gewinner der Woche ist mal wieder eine gehackte Seite, über die der Nutzer zu dubiosen Webshops für Schuhe umgeleitet wird (ich berichtetet). Die Website „Festungsflimmern“ ist dafür nur ein Beispiel. Es tummeln sich viel mehr gehackte Seiten bei der Suche nach Nike- oder Adidas-Schuhen in der Google-Bildersuche:

Google Bildersuche: adidas schuhe

Und wenn jetzt wer sagt, daß ja wohl kaum jemand zum Schuhkauf über die Google-Bildersuche geht, dann mag das durchaus sein. Aber auch die Bilderbox in der normalen Google-Suche ist natürlich Spam-verseucht und da werden sicher so einige Schuhsuchende mal auf ein Bild klicken.

Googlesuche: adidas schuhe (Bilderbox)

Leider scheint das Hotlink-Update nicht für gehackte Seiten zu greifen. Aber vielleicht gibt es ja noch ein Update zum Update und alles wird gut.

Bildkopien weiter ein Problem

Die Nummer 3 bei den Wochengewinnern (science-all.com) ist keine Hotlinkfarm, sondern eine Bildkopie-Farm. Unter dem Deckmantel der Traumdeutung und dem Titel „Science for all“ werden dort zu vielen Suchbegriffen die Top-Bilder aus der Bildersuche auf die eigenen Seiten kopiert. Auch dazu hatte ich bereits etwas geschrieben.

Nachdem die Seite in den letzten Woche etwas schwächelte, feiert sie nun wieder fröhlich Erfolg:

Bidox 21/2016: science-all.com

Das dürfte unter anderem daran liegen, daß die Hotlinker aus den Rankings verschwunden sind und nun die Bild-Kopierer deren Plätze in der Bildersuche einnehmen.

Überhaupt werden wohl die Bildkopie-Farmen in nächster Zeit zunehmen. Die technische Umsetzung ist zwar etwas aufwändiger, aber das Konzept insgesamt zukunftssicherer, denn Kopien werden natürlich nicht als Hotlinks erkannt, weil es keine sind. Zudem ist die Einordnung von Bildkopien als Spam oder Nicht-Spam schwieriger, weil der Ursprung der Bilder nicht nachvollziehbar ist.

Für mich ist ein Verdachtsmoment immer der plötzlich hohe Bidox-Wert praktisch aus dem Nichts, aber ob Gooolge auch etwas derartiges erkennen, auswerten und vor allem bewerten kann und will, ist fraglich. Einfach ist es zumindest nicht.

Die Bidox-Verlierer der Woche

Bidox-Verlierer 21. KW 2016

Wo Gewinner sind, gibt es auch Verlierer. Dabei hat es letzte Woche gleich fünf Seiten mit Bildkopien erwischt.

Bildkopien findet man üblicherweise bei Wallpaper-Sites, die nach eigenem bekunden kostenlose und natürlich frei Bilder als Hintergrundbilder zum Download anbieten (1fotonin.com, esciencelog.com, lemerg.com).

Beliebt sind kopierte Bilder auch bei Promi-Seiten (artcreationforever.com) und eine Traumdeutungs-Seite (weknowyourdreamz.com) hat es auch erlegt. Wobei ich hier davon ausgehe, das diese Seiten „Opfer“ von manuellen Maßnahmen wurden.

Die Hotlink-Farm einebinsenweisheit.com mit einem etwas anderen Konzept (Affiliate-Seite), die Besucher über die Bildersuche gezogen hat, dürfte direkt vom Hotlink-Update betroffen sein.

Zwei gehackte Seiten (stover-rennen.de, autogrund.de) gehören auch zu den Verlierern, aber warum die Süddeutschen starke Verluste in der Bildersuche hat, kann ich nicht sagen. Die haben praktisch die Hälft ihrer Sichtbarkeit in der Bildersuche eingebüßt. Was da wohl passiert ist?

Bidox 2016/12: sueddeutsche.de

Google Bildersuche Wochenrückblick 2016/21

Den klassische Hotlink-Farmen wurde wohl der Todesstoß versetzt, wobei das Update aus welchen Gründen auch immer, nicht für alle Seiten zu wirken scheint. Gehackten Seiten mit Bilder-Hotlinks sind weiterhin ein großes Problem. Auch ist mit der Zunahme von Bildkopie-Farmen zu rechnen. Ob und wann Google das dann in den Griff bekommt, wird man sehen.

Und hier noch der Blick auf das Bildersuche-Wetter :-)

Bewegung in der Bildersuche 2016/05/29

0 Kommentare »