Das Putzlowitsch Test- und SEO-Blog

Google Bildersuche – Anzeige des Originalbildes verhindern

Der Inhalt

  1. Problem
  2. Lösung
  3. Umsetzung
  4. Technik
  5. Ergebnis

Das Problem

Google-Bildersuche mit Originalbild

Google-Bildersuche mit Originalbild

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.

Um den Benutzer zu motivieren, dennoch die Originalseite zu besuchen, könnte man dem Nutzer innerhalb der Google-Bildersuche eine Bild in schlechter Qualität (unscharf/verpixel) mit einem zusätzlichen Hinweistext anzuzeigen. Das findet aber Google nicht so toll, es wird möglicherweise als Bilder-Cloaking gewertet. Das könnte wiederum eine manuellen Maßnahmen zur Folge haben.

Die Lösung

Seit einiger Zeit bietet Google im oben verlinkten Hinweis zum Bilder-Cloaking eine „legale“ Lösung für das Problem an

Bild in den Suchergebnissen minimieren oder blockieren

  • Sie können verhindern, dass das Bild auf der Google-Suchergebnisseite in Originalgröße angezeigt wird, indem Sie das Inline-Linking deaktivieren.

So deaktivieren Sie das Inline-Linking:

  • Wenn Ihr Bild angefordert wird, prüfen Sie den HTTP-Verweis-URL-Header in der Anfrage.
  • Falls die Anfrage von einer Google-Domain stammt, antworten Sie entweder mit HTTP 200 oder mit HTTP 204, „keine Inhalte“.

Google crawlt Ihre Seite und sieht das Bild weiterhin. In den Suchergebnissen wird jedoch nur das Miniaturbild angezeigt, das während des Crawlings generiert wurde. Die Funktion kann jederzeit deaktiviert werden. Die Bilder einer Website müssen dazu nicht noch einmal verarbeitet werden. Diese Methode wird nicht als Bild-Cloaking betrachtet und hat auch keine manuellen Maßnahmen zur Folge.

Wobei hier mit „Inline-Linking“ das gemeint ist, was allgemein als „Hotlinking“ bekannt ist. Und so ähnlich wie die berühmte Hotlink-Sperre funktioniert auch die Google-Bilder-Sperre.

Die Umsetzung

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	always	set    Cache-Control "no-cache, no-store, must-revalidate"	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

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

RewriteCond	%{ENV:DOM_REFERER}	google\.(com|de|at|ch)$ [NC,OR]
RewriteCond	%{ENV:DOM_REFERER}	bing\.com$ [NC]
RewriteRule	.*	/status-204.sta

RewriteRule	^status-204.sta$ -	[R=204,E=NO_CACHE:1,L]
</IfModule>

Die Technik

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.

Die Umgebung

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

Das Bild

RewriteCond	%{ENV:REQ_HTML} !1
RewriteCond	%{REQUEST_FILENAME} -f
RewriteRule	\.(jpg|png|gif|webp)$	-	[NC,C]

Mit den Rewrite-Regeln prüfe ich zunächst, ob es ein Bildaufruf (img src=…) ist, die Existenz der Datei (sonst soll die normale 404-Verarbeitung greifen) und über die Datei-Erweiterung, ob ein Bild aufgerufen wird. Falls nicht, wir der nächste Block der Rewrite-Regeln gar nicht erst ausgeführt.

Die Referrer

RewriteCond	%{ENV:DOM_REFERER}	google\.(com|de|at|ch)$ [NC,OR]
RewriteCond	%{ENV:DOM_REFERER}	bing\.com$ [NC]
RewriteRule	.*	/status-204.sta

Im zweiten Block wird eine Liste von Referrer-Domains abgearbeitet, für die die Weiterleitung erfolgen soll. In dem Fall sind es die vier Google-Domains, von denen die meisten meiner Besucher kommen und bing.com (ja, das funktioniert auch für Bing :-). Die Abfrage nach dem Referer kann man natürlich auch anders gestalten. Das hängt halt davon ab, was man damit erreichen will.

Die anschließende RewriteRule erzeugt eine internes Rewrite zur einer leeren Dummy-Datei (status-204.sta), die aber existieren muß. Das ist erforderlich, um den Cache-Header korrekt setzen zu können. Wenn der Browser die Daten cachen würde, wäre das Bild möglicherweise auch nicht auf der Webseite zu sehen.

Die Regel

RewriteRule	^status-204.sta$ -	[R=204,E=NO_CACHE:1,L]

Diese einzelne Regel setzt letzendlich den HTTP-Statuscode „204 No Content“ und triggert die Ausgabe des NoCache-Headers.

Der Cache

<IFModule mod_headers.c>
Header	always	set    Cache-Control "no-cache, no-store, must-revalidate"	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 verhindert.

Das Ergebnis

Im Ergebnis lädt Google unser Bild nicht in der ausgklappten Ansicht innerhalb der Bildersuche. Stattdessen wird das vergrößerte Thumbnail des Bildes angezeigt, das Google als Vorschaubild gespeichert hat und das in der Übersicht zu sehen ist.

Das Bild ist entsprechend unscharf und verpixelt. Der Nutzer kann unser Bild auch nicht einfach per Rechtsklick und „Grafik anzeigen“ oder „Grafik speichern unter…“ ansehen oder speichern- Wenn er das Originalbild sehen oder speichern will, muß er also unsere Webseite besuchen und schon haben wir wieder einen Besucher mehr. :-)

Keine Kommentare »

Stockfoto-Anbieter Alamy startet in Google-Bildersuche bei google.de durch

alamy.de – Bidox-Aufsteiger der letzten Wochen

bidox: alamy.de (Google-Bildersuche)

bidox: alamy.de (Google-Bildersuche)

Die Website alamy.de gehört in den letzten Wochen kontinuierlich zu den Gewinnern im Bilder-Domain-Index Bidox. Mittlerweile hat sie Platz 64 in der Top-100 erreicht. Wenn eine Seite derartig schnell aus dem Nichts die Google-Bildersuche stürmt, werde ich stutzig, denn das geht normalerweise nur mit bereits vorhandenen, gut rankenden Bildern.

Üblicherweise stecken hinter solchen Erfolgen Hotlinkfarmen oder Bildkopierer, die sich schamlos an fremdem Bildern bedienen und Bilderspam-Seiten mit Hotlinks oder Bildkopien aufziehen.

Im ersten Moment dachte ich auch bei alamy.de an eine Hotlinkfarm, nur eben nicht mit einer üblichen .tk- oder .xyz-Domains. Die Bilderspammer setzen zunehmend auch auf expired Domains mit „normalen“ TLDs wie .de oder .com.

Ein Blick auf die Seite hat mich dann eines Besseren belehrt, denn hinter alamy.de steckt die Stockfoto-Agentur „Alamy Limited“ aus England. Die Seite ist schon länger auch im Bidox mit ihrer .com-Domain vertreten, sie war mir nur bisher nicht aufgefallen.

Erfolgreich mit neuer Domain

Genau genommen habe wir es hier mit Hotlinks zu tun, allerdings ganz legalen. Die neuen DE-Seiten verwenden die selben Bilder wie die alamy.com-Seite. Diese werde nun in einer neuen, frischen Umgebung präsentiert und sind damit für Google gute Rankings wert. Zudem befinden sie sich nun in einer deutschsprachigen Umgebung, was dem Ranking in der Bildersuche bei google.de durchaus auch zuträglich ist.

Viele Bilder ranken zu Namen von Prominenten, zu Eigennamen wie Marken, Sehenswürdigkeiten und Städten. Diese Suchbegriffe unterscheiden sich im Englischen und Deutschen nicht und so hat Alamy viele der guten Rankings auf die DE-Seite übertragen können.

Durch die Übersetzung der Bildbeschreibungen und Stichwörter ins Deutsche konnten auch viele neue Rankings in der Bildersuche dazugewonnen werden.

Es kann sich also durchaus lohnen, neue Rankings in der Bildersuche mit länderspezifischen Seiten und Domains zu erobern. Auch Pinterest ist kürzlich diesen Weg erfolgreich gegangen, wenngleich hier die com-Domain zunächst deutliche Verluste einstecken mußte.

Bidox: pinterest-Domains im Vergleich

Bidox: pinterest-Domains im Vergleich

Bei Alamy gab es auch einen kurzen Einbruch, aber die com-Seite hat sich schnell erholt und einen neuen Höchststand im bidox erreicht.

Bidox: alamy-Domains im Vergleich

Bidox: alamy-Domains im Vergleich

Alles richtig gemacht, würde ich sagen.

Keine 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

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.

14 Kommentare »

Google Bildersuche Wochenrückblick 2016/21

Die Bidox-Aufsteiger der Woche

Bidox-Gewinner 21. KW 2016

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

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

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

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

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)

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

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

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

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

Bewegung in der Bildersuche 2016/05/29

Keine Kommentare »

Google Bildersuche Wochenrückblick 2016/13

Herzlichen Glückwunsch

Google-Bildersuche: birthday (04.04.2016)

Google-Bildersuche: birthday (04.04.2016)

So sieht das Ergebnis der Google-Bildersuche nach birthday im Moment aus. Stolze sieben der ersten acht Bilder sind von Hotlink-Farmen verspammt worden.

Gut zu erkennen ist, daß sich der der Trend der letzten Woche fortgesetzt hat. Die .tk-Domains sind bei den Spammern out, .win und .xyz-Domains sind in. Eine Frage, die mich schon länger beschäftigt: Wofür steht dieses .win eigentlich?

Ich hatte da immer win -> Windows im Hinterkopf, aber laut .win-Registrar geht es um Spiele, vorzugsweise Online-Games und das win steht für gewinnen.

Insofern bekommt die Sache durch Hotlink-Spamseiten eine weitere Bedeutung, die weniger mit Spielen, sondern vielmehr mit den finanziellen Gewinnen zu tun hat, die diese Websites wohl einstreichen dürften.

Die .tk-Domains gibt es zwar für lau, aber auch .win, .xyz und weitere, neue TLDs kann man für weniger als einen Dollar z.B. bei Namecheap registrieren. Mit dem im Preis enthaltenen WhoisGuard bleibt man selbst unerkannt im Hinteregrund, ideal für jede Art von Spam-Aktivität.

Irgendwie hatte ich gehofft und es sah zwischenzeitlich fast so aus, daß Google den Bilder-Hotlink-Spam etwas besser in den Griff bekommen würde. Zur Zeit sieht es aber eher nicht danach aus und so muß ich weiter meine täglichen Spam-Reports verschicken.

Update des Keyword-Sets im bidox

Google-Trends am 4. April 2016

Google-Trends am 4. April 2016 – DE, 12 Monate, Bildersuche

Da ein neues Quartal begonnen hat, wurde das Keywordset für den Bilder-Domain-Index Bidox angepaßt. Das Keywordset wird aus den als CSV-Datei pro Kategorie verfügbaren beliebtesten Suchanfragen bei Google-Trends für die Bildersuche in Deutschland der letzten 12 Monate erstellt.

In den letzten Quartalen hatte sich die Anzahl der Keywords im Bereich von 4000 bis 6000 bewegt. Mit dem jüngsten Update ist die Anzahl auf über 11000 gestiegen.

Der Bidox-Wert wird zwar auf die Anzahl der Keywords normiert, so daß die Werte zu denen der vorhergehenden Wochen auch nach der Anapssung vergleichbar bleiben. Es könne aber doch anpassungsbedingte Verschiebungen auftreten.

bidox KW 13/2016: zimbio.com und listal.com

bidox KW 13/2016: zimbio.com und listal.com

Im aktuellen Bidox zählen zwei Seiten (zimbio.com und listal.com) zu den Gewinnern, die mit vielen Bildern von prominenten Personen Ranken. Mit dem Update des Keyword-Sets sind scheinbar viele Namen von Promis hinzu gekommen. Nach dem ersten Überfliegen der neuen Keywords sind mir auch einige Suchbegriffe zu militärische Dingen wie Flugzeuge (f 16, f 22, f 35, f-16, f-22, f-35, f14, f15, f150 raptor, f18, f22 raptor) aufgefallen.

So etwas führt zu einer veränderten, inhaltlichen Gewichtung und damit zu größeren Rankingverschiebungen im Bidox.

Mehr Bewegung

Bewegung in der Bildersuche 2016/04/03

Bewegung in der Bildersuche 2016/04/03

Am Wochenende gab es etwas mehr Bewegung in der Bildersuche als im Verlauf der eher ruhigen Woche von Montag bis Donnerstag. Allerdings läßt sich nicht wirklich sagen, was der Grund dafür sein könnte. Dazu wäre eine tiefergehende Untersuchung der Ranking-Veränderungen notwendig. Hat jemand von Euch etwas bei den Bilderzugriffen und Besuchern über die Bildersuche bemerkt?

Google Bildersuche Wochenrückblick 2016/13

Die klassischen Hotlink-Farmen sind weiter gut im Rennen, besonder die Billig-Domains .xyz und .win sind sehr beliebt und funktionieren immer noch bestens. Gehackten Seiten sind weiterhin ein Problem, auch wenn ich das oben nicht extra erwähnt habe. Es hat sich daran ja nichts beändert.

Die aktuellen Bidox-Werte sind mit einer gewissen Vorsicht zu betrachten, da sich das Keyword-Set erheblich verändert hat.

Keine Kommentare »