Das Putzlowitsch Test- und SEO-Blog

Niedergang der Bloghoster in der Google-Bildersuche

BiDoX Verlierer der Woche

BiDoX 19/2019 Verlierer 4 Wochen

Seit einiger Zeit gehören die Domains der großen Bloghoster Blogspot (Blogger) und WordPress.com zu den Verlierern der Woche. Dazu muß man wissen, daß nicht die Domains selbst in der Bildersuche ranken, sondern die vielen Subdomains, die Nutzer for free als eigenes Blog oder eigene Website betreiben können. Im Bidox werden die Subdomains allerdings unter der Hauptdomain subsummiert.

Innerhalb eines Jahres haben Blogspot und WordPress massiv in der Google-Bildersuche an Sichtbarkeit verloren.

BiDoX – Abstieg der Bloghoster (1 Jahr)

Von gut über 110 Bidox-Punkten sind aktuell nur noch 35 bzw. 44 übrig geblieben.

Bildersuche Schwergewichte

BiDoX 22/2014

Noch vor fünf Jahren zählten Blogspot und WordPress nach der Wikipedia zur Top-3 in der Google-Bildersuche. Bei vielen Suchanfragen in der Bildersuche fand man Bilder diese Websites auf vorderen Plätzen.

BiDoX 22/2014 -Ranking: nähen anleitung

BiDoX 22/2014 -Ranking: lernen

Aber bereits in den Wochen bis Anfang/Mitte 2015 begann der steile Abstieg, für Blogspot noch deutlicher als für WordPress.

BiDoX – Abstieg der Bloghoster (5 Jahre)

Bis auf kleinere Zwischenhochs ging es seitdem kontinuierlich bergab. Aktuell liegt WordPress mit 44,1 BiDoX-Punkten auf Platz 53 und Blogspot mit 35,6 auf 67, Tendenz fallend.

Ursachen?

Zu den Ursachen kann ich nur spekulieren. WordPress und besonders Blogspot waren als Freehoster schon immer eine beliebte Option, um Spamseiten aufzubauen. Zu WordPress kann ich da aus eigenem Erleben nicht viel sagen, bei Blogspot ist mir das ganz besonders in Bezug auf die Bildersuche aufgefallen. Viele meiner Bilder waren davon betroffen.

Die Spammer haben sowohl Hotlink-Farmen aufgebaut, als auch Bilder geklaut und kopiert. Die Seiten haben dann z.B. meine mühsam erarbeiteten Rankings zum Thema Weihnachten und Neujahr übernommen. Beliebte Themem waren auch Sprüche aller Art, Mode, Frisuren und Lifestyle. Die Bilder werden Seitenweise verlinkt/kopiert und mit sinnlos zusammengestellten Texten garniert (Beispiel).

Google hat wohl mittlerweile das Vertrauen in den eigenen Blog-Service verloren, denn die Rankings fallen und fallen. Auch mit Spamseiten kommt man nicht so schnell wie früher zum Zuge, so das die Blogspot-Seiten dafür nicht mehr so attraktiv sind. Da kommt vielleicht eins zum anderen.

Es bleibt abzuwarten, wie lange die Talfahrt noch weitergeht…

Keine Kommentare »

Das Siebtlingsgeburt-Ranking im Blog mit meinem Plugin einbinden

Gestern hatte ich ja bereits die maschinenlesbaren Daten von ranking-123.de vorgestellt. Ihr könnt diese Daten selbst nutzen und auswerten (wenn Ihr es könnt :-). Oder Ihr benutzt einfach mein WordPress-Plugin, das ich hier kurz vorstellen will.

Siebtlingsgeburt Top-100

123 Top-100 Plugin

Das Plugin besteht im wesentlichen aus zwei Funktionen.

Die erste Funktion agn_top100_read_data ist für das Abholen der Daten im JSON-Format zuständig. Hier habe ich etwas mehr Aufwand betrieben, um unnötige Requests und Datenübertragungen zu vermeiden. Die Daten werden lokal auf dem Server der WordPress-Installation im Verzeichnis wp-content/uploads gespeichert. Dieses muß daher von WordPress beschreibbar sein, damit das Caching funktioniert.

Die zweite Funktion agn_top100_shortcode implementiert einen WordPress-Shortcode, mit dem man sich die gewünschten Daten im Artikel oder auf der Seite ausgeben lassen kann.

Im einfachsten Fall sieht das dann so aus:
...
Hier findet ihr die aktuelle Siebtlingsgeburt Top-100:
<table class='chart-list'>[agn_top100 nam='siebtlingsgeburt']</table>
...

Per Voreinstellung wird die Liste als Tabelle ausgegeben, allerdings ohne Table-Tags. Die müßt Ihr selbst drumrum packen. Das hat den Vorteil, daß Ihr der Tabelle einfach eine CSS-Klasse oder sonstige Formatierungen mitgeben könnt.

In der Voreinstellung ergibt sich damit eine Tabelle wie auf dieser Beispielseite (ohne Grafik). Die Platzierung wird einfach durchnummeriert, vor der URL steht ggf. ein Symbol für den Ergebnistyp, hinter der URL folgt ein Link-Symbol mit einem (nofollow!) Link zur Seite. URLs, die Länger als 70 Zeichen sind, werden am Ende mit … verkürzt.

Über Shortcode-Parameter kann die Ausgabe angepaßt werden. Folgende Einstellungen sind möglich:

  • nam – Name der Daten
    Vorgabe: ‚xovilichter‚, hier also siebtlingsgeburt eintragen :-)
  • ret – Was soll der Shortcode zurückgeben?
    Vorgabe: ‚rnk‚, mögliche Werte

    • rnk – Ranking Tabelle/Liste (siehe lit)
    • upd – Datum und Zeit des letzten Updates (siehe dtf)
    • cnt – Anzahl der gefundenen Treffer insgesamt
  • max – Maximal Anzahl auszugebender Treffer
    Vorgabe: ‚100‚, eine Zahl zwischen 1 und 123
  • dtf – Ausgabeformat des letzten Updates (siehe ret:upd)
    Vorgabe: ‚‚d.m.Y H:i‘‚, Format entsprechend PHP-Date-Funktion
  • lit – Listentyp: Tabelle oder Liste?
    Vorgabe: ‚tab‚, mögliche Werte

    • tab – Tabelle (table)
    • lst – Liste (ol)
  • cut – Anzahl Zeichen, ab der eine URL verkürzt wird
    Vorgabe: ‚70‚, eine Zahl zwischen 0 (keine Verkürzung) und größer
  • sym – Typ-Symbol vor der URL anzeigen
    Vorgabe: ‚1‚, zum ausschalten ‚0‘ verwenden
  • lnk – Link am Ende der URL ausgeben
    Vorgabe: ‚1‚, zum ausschalten ‚0‘ verwenden

Hier ein paar Beispiele:
...
<ol>[agn_top100 nam='siebtlingsgeburt' max='33' lit='lst' sym='0']</ol>
...

Gibt maximal 33 Einträge als HTML-Liste (OL) ohne vorangestelltem Typ-Symbol aus.

...
Top-100 vom [agn_top100 nam='siebtlingsgeburt' ret='upd' dtf='l, d.m.Y H:i'] Uhr
...

Gibt den Zeitpunkt des letzten Updates formatiert aus.

Technische Voraussetzungen und Download

Technische Voraussetzungen:

  • WordPress 3.8 oder höher
  • PHP 5.2 oder höher mit curl-Funktion
  • Verzeichnis wp-content/uploads muß von WordPress beschreibbar sein

Download Version 0.18: 123 Top-100 Plugin

Falls es Unklarheiten oder Fragen gibt, einfach fragen. :-)

Ein Kommentar »

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.

14 Kommentare »

Vergeßt die Bildersuche, Google ist überfordert

Die Hotlinkfarmen boomen

bidox – Gewinner der Woche 40/2015

Vorbemerkung: Es geht hier um die Google-Bildersuche bei google.de. Allerdings ist die englische Bildersuche bei google.com auch betroffen.

Das sind die Gewinner der letzten Woche im Bilder-Domain-Index (Bidox). Alle Domains habe ihren bidox-Wert aus den Nichts erreicht, wobei in der Liste nur Seiten angezeigt werden, die mindestens einen Wert von 10 erreicht haben. Für fotomega.xyz ging es sogar von 0 auf über 100, aber diese Website ist bereits Geschichte.

So einen steilen Aufstieg in der Google-Bildersuche erreicht man in der Regel nur mit vielen Hotlinks auf topplatzierte Bilder. Diese Hotlink-Farmen sind nicht neu, sie haben nun aber das System perfektioniert.

Nur die Top-Bilder zählen

Für die Hotlink-Spammer sind natürlich nur die Top-Bilder lukrativ, weil man mit diesen nich nur in der Bildersuche selbst, sondern auch in der Bilderbox der organischen Suche oder im Knowledge-Graph mitmischen kann. So sieht dann das Ergbnis aus:

Google-Bilderbox: Blumen

Im ersten Beispiel „Blumen“ zeigen alle vier Bilder der Bilder-Box auf die Hotlinkfarm geburtstag5.tk.

Google-Knowledge-Graph: Pasta

Beim Knowledge-Graph für „Pasta“ wurden zwar nicht alle Bilder von den Hotlinkern gekapert, aber man sieht schon das neue Konzept der wechselnden Sub-Domains. Zwei Bilder zeigen auf un.fotosg.xyz, ein anderes auf tres.fotosg.xyz. Jetzt, wo ich diesen Artikel hier schreibe, werden bereits alle Seiten auf die neue Domain fotoweb.xyz umgeleitet.

Domain wechsle dich

Um gar nicht erst von möglichen Antispam-Maßnahmen behelligt zu werden, wird praktisch täglich die Subdomain und nach ein paar Tagen auch die Hauptdomain gewechselt. Sollte jemand bei Google einen Spam-Report oder gar eine DMCA-Beschwerde einreichen, ist die Hotlink-Farm längst auf eine neue Domain umgezogen und kann ungestört weitermachen, bevor da überhaupt etwas bearbeitet wurde.

Die Seiten laufen, soweit ich das gesehen habe, mit WordPress. Da ist so ein Sub-/Domainwechsel sehr einfach zu bewerkstelligen.

Wordpress-Einstellungen: URL

Nachdem man die neue Domain registriert und auf den Webspace aufgeschaltet hat, muß man nur noch in den Allgemeinen Einstelluneg die gewünschte Domain oder Subdomain bei WordPress-Adresse und Website-Adresse eintragen. Fertig ist die Laube, um alles andere inklusive Weiterleitung der Zugriffe auf die alte Domain zur neuen Domain kümmert sich WordPress.

Geld verdienen leicht gemacht

Die Hotlinkfarmen werden selbstverständlich nicht nur zum Spaß aufgebaut oder um Bilder-Menschen wie mich zu ärgern. Man kann mit den Hotlinks prima Geld über Werbung verdienen.

So sieht eine der .xyz-Seiten aus, wenn man sie besucht. Es gibt ein bißchen schlecht (automatisch) vom Türkischen ins Deutsche übersetzten Text und natürlich die per Hotlink eingebundenen Bilder, teilweise per display:none versteckt.

Dazu kommen für die interne Verlinkung „Related posts“, „Recent Posts“, „Archives“, „Categories“ und „Zufällige Bilder“. Im Archiv kann man übrigens sehen, wann die Hotlink-Farm an den Start gegangen ist. Der erste „Artikel“ ist vom 3. August 2015.

Zum Geldverdienen dürfen auch Werbveblöcke nicht fehlen, davon findet man bescheidene drei auf der Seite.

Ich weiß zwar nicht, wieviel so eine .tk- oder .xyz-Domain in der Türkei kostet, aber selbst wenn die Domain nach wenigen Tagen verbrannt ist, dürfte sie in dieser Zeit locker das Geld plus einen guten Gewinn eingespielt haben.

Ist Google machtlos?

Es ist ja wirklich toll, wie rührig sich Google bemüht, Spam aus den organischen Suchergebnissen fernzuhalten. Da gibt es immer wieder neue Updates mit putzigen Tiernamen und die Spammer bekommen das große Zittern.

Wer sich allerdings auf Bilder-Spam mit Hotlink-Farmen spezialisiert hat, kann sich schon seit Jahren entspannt zurücklehnen. Im Bereich der Bildersuche muß man da nichts befürchten.

Google-Bilderbox: Enduro

Im Gegenteil, ich habe sogar den Eindruck, daß es seit einiger Zeit viel schneller als früher möglich ist, ein Bild per Hotlink in den Suchergebnissen zu übernehmen. Gerade bei Bildern in der Bilder-Box oder im Knowledge-Graph passiert das fast in Echtzeit.

Dabei wäre die Spamerkennung bei den großen Hotlink-Farmen denkbar einfach. Wenn eine Website in kurzer Zeit Bilder von vielen unterschiedlichen Domains einbindet, dann sollte bei Google eine rote Spam-Warn-Lampe angehen.

Und warum muß ein Bild immer sofort auf eine neue Seite in den Suchergebnissen verweisen, wenn es irgendwo auf einer neuen Seite auftaucht? Stellt eine Seite, nur weil sie neu ist, einen größeren Mehrwert für den Besucher dar?

Ich denke nicht, daß Google bei dem Problem des Bildersuche-Spams machtlos ist, zumal es aus meiner Sicht recht starke Signale für Bilderspam gibt.

Google kümmert sich einfach nicht um die Bildersuche und dreht lieber im 127. Panda-Update an Stellschraube 68, so daß möglicherweise 0,03% weniger Spam bei den organischen Suchergebnissen zu finde ist.

8 Kommentare »

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 »