Das Putzlowitsch Test- und SEO-Blog
Thema: Internet

Google „People also ask“ dynamisch – viele Antworten auf viele Fragen

Googles „People also ask“ – die PAA-Box

Google „People also ask“: Fourth of july

Seit einiger Zeit zeigt Google bei bestimmten Suchanfragen eine sogenannte PAA-Box an. Unter der Überschrift „People also ask“ werden bis zu vier Fragen und nach klick deren Antworten eingeblendet. Bei google.de in Deutschland habe ich das allerdings bisher noch nicht gesehen.

Da ich wegen der Google-Doodle hin und wieder bei google.com nachschaue, ist es mir dort besonders aufgefallen. So auch heute zum Unabhängigkeitstag der USA mit der Suchanfrage „Fourth of July“. Auch dazu werden vier Fragen (siehe Bild oben) eingeblendet. Meist klicke ich da aber nicht drauf, heute aber schon. Zunächst dachte ich, ich hätte micht verguckt, denn da waren auf einmal sechs und nicht vier Fragen zu sehen.

Noch mehr Fragen (und Antworten)

Sind da etwa zwei Fragen dynamisch dazu gekommen? Und tatsächlich, beim nächsten Klick waren es plötzlich acht Fragen. Ich habe das hier mal in einem Video dokumentiert:

Mit jedem Klick kommen zwei Fragen (und Antworten) dazu. Bei 100 Fragen habe ich dann aufgehört.

Interessant ist auch die thematische Entwicklung der Fragen. Man kommt z.B. von „What is celebrated on Independence Day?“ über „Is September 5 a Holiday?“ bis zu „Can you use superglue to close a wound?“. Es geht doch deutlich von der Ausgangsfrage bzw. Suchanfrage weg.

Google bewegt sich also immer mehr weg von einer Suchmaschine hin zu einer (Frage- und) Antwortmaschine. Ob es nun aber sinnvoll ist, die „People also ask“-Fragen praktisch „unendlich“ weiterzuspinnen, da habe ich so meine Zweifel.

Und in DE scheint es das auch noch nicht zu geben, oder hat das von Euch schon mal jemand bei google.de gesehen?

3 Kommentare »

Google-Bildersuche rankt PDF-Dokumente

Google findet Bilder mit Bildern in PDF-Dateien

Google – Bildersuche mit Bild (pdf)

Daß man Bilder in PDF-Dateien über die Bildersuche finden kann, war mir bereits im Oktober 2013 aufgefallen.

Allerdings war damals die PDF-Datei nicht die Referenz-Seite für ein Bild in der normalen Bildersuche, sondern ein Treffer als Ergebnis der Suche mit Bild (Seiten mit übereinstimmenden Bildern).

Diese Suchergebnisseiten sind keine Bildersuche-Ergebnisse, sondern entsprechen eher der Video-Suche.

Der Klick auf das Ergebnis führt zu der entsprechende Seite, also bei einem PDF-Treffer direkt zur PDF-Datei. Mit dem Klick auf das Thumbnail gelangt man wieder in die Inline-Ansicht der Bildersuche, allerdings nur für genau dieses eine Bild.

Echte PDF-Treffer in der Google-Bildersuche?

Heute ist mir nun das erste Mal ein echter Treffer in der Google-Bildersuche aufgefallen, der eine PDF-Datei, also keine Webseite als Bildreferenz verwendet.

Bei der Suche nach „Schule“ findet man recht weit vorn ein Ergebnis der Uni-Hildesheim:

Google-Bildersuche: PDF-Datei

In der Inline-Ansicht fehlen die Klickflächen [Seite besuchen], [Bild ansehen] und [Teilen], stattdessen gibt es nur den Button [PDF ansehen]. Klar, ein in einer PDF-Datei eingebettetes Bild hat keine eigene URL, mit der man sich das Bild einzeln ansehen könnte.

Aber das stimmt so nicht ganz, denn was hier Google in der Bildersuche als Treffer liefert, ist gar nicht das in der PDF-Datei enthaltene Bild. Es ist mal wieder nur die URL eines Bildes, die als Link oder sogar nur als Text in der PDF-Datei auftaucht:

Bilder-Text-URL in PDF-Datei

Ganz unten wurde als Bildquelle die URL des Bildes aufgeführt, als einfacher Text der URL. Genau das ist auch das Bild, das in der Bildersuche rankt (sichtbar mit dem Bilder-Liste Bookmarklet):

Google-Bildersuche: Text-URL im PDF

Daß nicht das Bild selbst rankt sieht man auch daran, daß das bunte Bilder der Schule gar nicht im PDF-Dokument verwendet wird, sondern eine aufgehellte Graustufenversion als Hintergrundbild.

Ich habe mir noch ein paar weitere PDF-Treffer in der Bildersuche angesehen. Bei allen verhält es sich wie bei der „Schule“ oben. Das Ranking in der Bildersuche erfolgt nicht für das Bild in der PDF-Datei, sondern für eine Bild-URL darin, die einfach z.B. als Bildquelle im Text aufgeführt wird.

Ein weiteres Beispiel ist „Thermometer„:

Google-Bildersuche: PDF-Datei (Thermometer)

Sie sieht das in der PDF-Datei aus:

Bilder-Text-URL in PDF-Datei (Thermometer)

Auch hier ist wieder gut zu sehen, daß das Bild in der PDF-Datei nicht das ist, welches in der Bildersuche rankt. Im PDF-Dokument wird nur das mittlere, grüne von den drei Thermometern im Originalbild verwendet.

Nur der Link- bzw. Text-URL-Effekt

Bilder aus PDF-Dokumenten ranken nicht wirklich in der Bildersuche. Wenn dort ein PDF-Dokument als Referenz für das Bild verwendet wird, ist es nur eine weitere „Ausprägung“ des Link- bzw. Text-URL-Effekts. Dieser besagt, daß eine Seite in der Google-Bildersuche ranken kann, die nur eine Link zu einem Bild gesetzt hat oder sogar nur die Bild-URL als Text auf der Seite zu stehen hat.

Ich habe bei meiner Recherche entdeckt, daß es angeblich bereits seit August 2015 möglich ist, Bilder in PDF-Dateien mit Google zu finden. Mir war das zumindest bisher nicht aufgefallen. Möglicherweise gab es die Funktion auch zunächst nur bei google.com. Ob damals wirklich die Bilder aus PDF-Dokumenten gefunden wurden, oder doch nur enthaltene Bild-URLs, kann ich nicht sagen.

Im Moment scheint es aber so zu sein, daß nur die Bild-URLs zum Ranking führen.

Google-Bildersuche in PDF-Dateien? Nicht wirklich!

0 Kommentare »

So ein Mist, voll gegen die Wand gefahren!

Eine Wand ist eine Wand, oder?

Google-Suche: Wand

Das es wand auch als englisches Wort gibt, was soviel wie Zauberstab heißt, ist sicher eine interessante Information. Wenn ich bei google.de mit der Sprache „Deutsche“ nach Wand suche, will ich aber bestimmt keine Bilder von Zauberstäben sehen, sondern von Wänden. Oder geht das nur mir so?

In der Bildersuche selbst wird meine Erwartung durchaus befriedigt:

Google-Bildersuche: Wand

Gut, auch hier sind ein paar Zauberstäbe zu finden, im Großen und Ganzen aber doch die erwarteten Wände. Die Zauberstäbe sind allerdings größtenteils andere, als in der organischen Suche. Keine Ahnung, wo Google die in der Bilderbox angezeigten Zauberstäbe herzaubert.

So ein Mist

Also ich finde schon, daß das Mist ist, was Google da in der Suche mit den Bildern macht.

Google-Suche: Mist (Bilder-Box)

Google-Suche: Hut (Bilder-Box)

Google-Suche: Gaul (Bilder-Box)

Da muß man schon auf der Hut sein, bei diesen teils seltsamen Bilder-Suchergebnissen. Aber andererseits ist die Google-Suche ja umsonst, dann gilt hier wohl das Sprichwort „Einem geschenkten Gaul schaut man nicht ins Maul“.

Ist das nun gut oder bad, ähhmmm schlecht, was Google da macht?

Google-Suche: bad (Bilder-Box)

Zweifel kommen spätestens dann auf, wenn man sich das entsprechende Ergebnisse der Bildersuche ansieht.

Google-Bildersuche: Bad

Oder ist es nur ein Fehler?

Google-Suche: Rock

Na wenigstens lassen sich die Google-Shopping-Ergebnisse durch die Übersetzung aus dem Englischen nicht auf eine falsche Fährte locken.

Fehler oder Absicht?

Handelt es sich hier nur um Fehler, oder weiß Google einfach mehr über die Suchintention der Nutzer, als man selbst annimmt?

Es ist ja durchaus denkbar, daß viele Nutzer bei der Suche nach Wand eigentlich einen Zauberstab meinen oder nicht auf der Suche nach einem neuen Rock, sondern nach hübschen Steinen sind.

Ich kann mir das ehrlich gesagt nicht vorstellen. Zumindest ich würde bei der Suche nach den oben gezeigten Beispielen etwas anderes erwarten. Aber ich bin ja nur ein ganz kleines Körnchen in Googles riesigem Datenschatz.

2 Kommentare »

Suchergebnisse in Suchergebnissen von Suchergebnissen

Suchergebnisse in Suchergebnissen

Bidox: AOL

Seit einigen Wochen erlebt AOL in der Google-Bildersuche wahre Höhenflüge. Im Bilder-Domain-Index ist aol.de mit einem Bidox-Wert von knapp 55 bereits auf Platz 36 angekommen.

Gut, AOL.de ist zunächst mal ein normales Nachrichten-Portal. Das kann natürlich bei Google, wie andere Portale auch, in der Suche auftauchen. Aber die AOL-Rankings in der Bildersuche beziehen sich nicht auf den redaktionellen Teil, sondern auf die Suchergebnisse der AOL-Suche (die von Bing bereitgestellt wird):

Google-Bildersuche: Julia Engelmann – suche.aol.de

Was passiert nun, wenn man von Google kommend die Seite aufruft? Man landet auf der Suchergebnisseite bei AOL!
Prima. Suchergebnisse in Suchergebnissen, das ist genau das, was der Nutzer will. :-)

Was da seit einigen Wochen genau schief läuft, ist schwer zu sagen.

Wie verhindert Google normlarweise, daß Suchergebnisse anderer Suchmaschinen in den eigenen Suchergebnissen auftauchen? Gibt es da eine Art Black-List?

Oder hatte AOL bisher die Suchergebnisse mit noindex markiert und das nun entfernt, so daß jetzt die AOL-Suchergebnisseiten die Google-SERPs fluten?

Und wundert Euch nicht, wenn Ihr in der Google-Search-Console plötzlich ganz viele Links von aol.de angezeigt bekommt. Das ist keine Link-Spam-Attacke, sondern kommt von suche.aol.de bzw. o2suche.aol.de und ist nichs Böses.

Aol-Suchergebnisse: Fireball

Ist aber alles nicht so schlimm, denn bei AOL (Bing) findet man dafür dann in den Suchergebnissen die Suchergebnisse von Fireball. :-)

1 Kommentar »

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

Früher war alles besser

Bildersuche Referrer

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

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

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

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

Tracking mit Keksen

Kekse – Cookies (Foto: ajt / 123RF)

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

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

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

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

Zugriff!

Bildersuche-Tracking in der .htaccess

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

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

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

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

<IfModule mod_rewrite.c>
RewriteEngine On

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

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

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

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

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

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

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

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

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

# Aufruf eines existierenden Bildes

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

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

# Aufruf einer normalen Seite

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

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

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

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

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

# Host-Domain

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

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

# Referrer-Domain

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

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

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

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

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

# Bild -> Cookie setzen

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

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

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

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

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

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

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

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

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

Ab in die Log-Datei

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

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

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

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

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

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

Ab zu Google-Analytics

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

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

ga( 'send', 'pageview' );

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

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

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

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

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

Fehler- und weitere Betrachtung

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

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

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

Google-Bildersuche: Neues Layout (Preload)

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

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

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

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

Ende im Gelände?

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

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

0 Kommentare »

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

SEO-Campixx 2017

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

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

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

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

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

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

0 Kommentare »

Internationaler Frauentag mit neuem Google-Feature

Internationaler Frauentag – Google-Suche

Heute ist „Internationaler Frauentag“ und es gibt ein weltweites Google-Doodle.

Wenn dann beim letzten Klick oder dem Klick auf die Lupe die Google-Suche mit der Suchfrage Internationaler Frauentag erscheint, gibt es eine kleine Überraschung.

Ganz oben, noch vor den Suchergebnissen, erscheint ein „Karussell“ mit 13 Bildern und den Namen von mehr oder weniger berühmten und bekannten Frauen. Beim Klick auf eine der Info-Karten wird die entsprechdende Such nach dem Namen ausgeführt.

Für diese 13 Frauen gab es schon mal ein Google-Doodle und sie tauchen im heutigen Doodle in irgendeiner Form auf.

Nur für zwei der 13 Frauen gab es das Doodle auch in Deutschland:

Die anderen 11 Frauen sind:

So, und hier gibt es nun meine Internationaler Frauentag Video:

0 Kommentare »