Beiträge zum Thema 2010 April

Ich bin eben über den Blog-Post “Praxistipps: Conversion Optimierung mit Mega Drop-downs” gestolpert. Guter Beitrag. Aber wie verhalten sich solche Fly-Out-Navigationen in Bezug auf SEO?

Prinzipiell halte ich viele dieser Navigationen für nicht so optimal, weil es hier eben so ist, dass jede Seite auf extrem viele Seiten intern verlinkt. Das sorgt nicht gerade dafür, dass wichtige Seiten betont werden und so mehr internes Linkgewicht erhalten.

Ich habe auch getestet, ob Google nicht vielleicht in der Lage ist, diese Elemente “auszublenden”. Wahrscheinlich schafft Google es, diese Elemente mittels Page Segmentation zu erkennen und entsprechend internabzuwerten. Aber das sorgt eben trotzdem nicht dafür, dass Oberseiten mehr Linkgewicht als verlinkte Unterseiten bekommen.

In jedem Fall sind die ausgeklappten Navigationselemente aber im Google-Index zu finden. Beispiel: REI.com. Ich habe mir dort den Baustein “Caving and Canyoneering” ausgesucht, der in der “Climbing”-Navigation zu finden ist:

Wenn man diesen als Phrase bei Google sucht, sieht man, dass Google diesen auch in jeder Seite erkennt. Auch am Snippet kann man sehen, dass Google hier aus der Fly-Out-Navigation zitiert:

Analog habe ich mir auch einige andere Sites aus dem Artikel angeschaut. Die Texte sind immer drin, so dass ich derzeit davon ausgehe, dass Google auch die Links erkennt und wertet.

Wie immer kann man hier nie sicher sein, wie Google das alles intern verdaut, aber ich bin recht skeptisch. Ich denke, dass es besser wäre, die Fly-Out-Navigation so aufzubauen, dass Google diese nicht erkennen kann (über JavaScript mit externen und geblockten Dateien). Dann könnte man gezielter Linkgewicht auf die relevanten Seiten leiten und würde nicht mit der Gießkanne Link-Juice verteilen.

Das Thema drängt mich schon seit einigen Tagen, aber ich hatte einfach noch keine Zeit, drüber zu schreiben. (Streng genommen muss jetzt auch gerade ein Kundenprojekt für morgen fertig werden, aber so spannend ist das nicht…)

Matt Cutts hat in seinem Interview mit Eric Enge ja schon mal das Thema “Crawl Budget” aufgegriffen. In kurzen Worten geht es dabei um die Frage, ob man dadurch, dass man für den Spider sinnlose Seiten sperrt, die “Energie” des Crawlers für sinnvolle Seiten nutzen kann. Matt Cutts hat da schon mal darauf hingewiesen, dass dem nicht unbedingt so sei.

Und dann bot der Vortrag “Technische Rahmenbedingungen und Indexierbarkeit für große Webseiten” von Johannes Müller (Webmaster Trends Analyst, Google) auf der SMX einige interessante Einblicke. Er hat seine Folien leider nicht online gestellt, so dass ich den entscheidenden Teil hier nachmalen muss:

Der Scheduler ist der Teil der Google-Software, die eine bestimmte Menge an URLs zusammengestellt, die dann vom Crawler abgeholt werden müssen. Der Scheduler stellt also eine Menge an URLs zusammen und sorgt dafür, dass einige für Google wichtige Rahmenbedingungen eingehalten werden. So werden pro Tag pro IP-Adresse nur eine bestimmte Anzahl an URLs abgeholt.

Diese URLs werden dann dem Crawler zugeschickt, der die Seiten abholen soll. Dieser prüft aber vorab die robots.txt. In dem Schaubild ist es auch so, dass der Scheduler die robots.txt anscheinend gar nicht kennt. Es könnte also laut Schaubild passieren, dass der Scheduler 10.000 URLs an den Crawler geschickt, die allesamt gesperrt sind. Dann könnte es theoretisch passieren, dass an diesem Tag überhaupt keine Seiten abgeholt werden.

Also: Das Blockieren irrelevanter Seiten sorgt nicht zwangsweise dafür, dass Crawl Budget eingespart wird.

Ich denke aber trotzdem, dass das Blocken irrelevanter Seiten sinnvoll ist, weil:

1. Ich habe immer die Angst, dass Google zu dem Schluss kommt, dass meine Website nicht “gut” ist, weil es eben zuviele Dubletten und/oder Seiten ohne relevanten Content gibt. Das ist mehr eine gefühlte Gefahr, die sich aber auf einen Kommentar von Adam Lasnik (Google) stützt.
2. Ich kann und will nicht glauben, dass der Scheduler dennoch immer wieder Tag für Tag geblockte Seiten an den Crawler schickt. Ebenso, wie sich die Crawl-Frequenz absenkt, wenn sich eine Seite nur selten ändert, sollte der Scheduler auch geblockte Seiten nicht permanent wieder an den Crawler schicken. Das macht einfach keinen Sinn. Mit der Zeit sollte der Scheduler meiner Meinung nach immer öfter ungeblockte Seiten auswählen, so dass man mittelfristig eben schon Crawl Budget einsparen kann.
3. Ich kann mir auch gut vorstellen, dass der Scheduler die Seiten aus den ihm vorliegenden URL-Listen halbwegs zufällig verteilt oder nach einer Heuristik auswählt. Wenn ich also URLs in einem Verzeichnis A (nicht geblockt) und in einem Verzeichnis B (geblockt) habe, glaube ich einfach nicht, dass der Scheduler nur URLs aus dem Verzeichnis A oder nur aus B auswählt. Der Crawler hat also auch bei vielen geblockten URLs genug zu tun.

Eine Sache habe ich auf jeden Fall aus dem Vortrag mitgenommen: Wenn das Crawl-Budget auf IP-Basis festgelegt wird, kann eine eigene IP schon helfen, die Seiten schneller in den Index zu bekommen (im Vergleich zu Shared Hosting).

Der Maik hat’s gerade retweetet: Ein sehr interessanter Test von Mark Lavoritano:
301 Redirect Test: How Much Link Juice are YOU Losing?

Dabei geht es um die Frage, ob ein Link auch dann noch Link-Juice weitergibt, wenn er per 301-Umleitung auf ein anderes Ziel umgeleitet wird. Insgesamt wird davon ausgegangen, dass das funktioniert – dass man hier aber auch ein bisschen Link-Juice verliert. Mark hat dabei versucht, dieses “ein bisschen” zu quantifizieren.

Interessant ist auf jeden Fall, dass Yahoo! und Bing anscheinend nicht annähernd so gut mit der Umleitung klarkommen, wie man das bei Google sehen kann.

Wie gesagt: Ich halte den Test für interessant – aber er passt meiner Meinung nach nicht perfekt zur Fragestellung. Der Test beantwortet ja nur die Frage, ob eine Domain-Umleitung von A (alte Domain) nach B (neue Domain) über 301-Umleitungen funktioniert. Wenn man dem Test glaubt, funktioniert das bei Google perfekt – sogar so perfekt, dass die neue Domain noch bessere Rankings als die alte zu haben scheint. (Das motiviert einen ja fast, unseren Kunden einen Domain-Umzug nahezulegen 🙂 )

Ob dieses Verhalten aber auch für einen x-beliebigen Link gilt, zeigt der Test nicht unbedingt. Ich kann mir sehr gut vorstellen, dass Google für das Testproblem (Domain A zieht nach B um) eine besondere Behandlung vorsieht. Algorithmisch würde das auch Sinn machen, weil das wohl nicht selten passiert.

In jedem Fall: Danke an Mark Lavoritano für den Test. Ich denke, dass sich das jeder in Ruhe zu Gemüte führen kann, der einen Domain-Wechsel plant.

Beim Überprüfen der Backlinks anderer Portale ist mir ein ganz interessanter Fall aufgefallen. Ausgangspunkt ist die folgende Seite:

http://www.service-bw.de/zfinder-bw-web/lifesituations.do?llid=1298794&llmid=0

Die Inhalte dieser Seite werden auf zig Websites von Kommunen kopiert, z.B.

• http://www.ulm.de/start.3076.htm?_druck=1&id=54559
• http://www.ulm.de/sixcms/detail.php?id=54559
• http://www.erolzheim.de/data/lebenslagen.php?servicebwId=Studium%7C1.+Studium+in+Baden-W%FCrttemberg%7CSonderformen+der+Hochschulbildung
• http://www.rems-murr-kreis.de/2320_DEU_WWW.php?&publish%5BservicebwId%5D=Studium%7C9.+Weiterf%FChrende+Informationen+und+Links%7CFernstudium
• http://www.gemeinde-rosenberg.de/data/lebenslagen.php?servicebwId=Studium%7C9.+Weiterf%FChrende+Informationen+und+Links%7CFernstudium
• …

Mein erster Gedank: Praktisch. Wer in der Liste drin ist, bekommt natürlich viele viele Links. Und das auch noch von Kommunen, die sonst nicht gerade als linkfreudig eingestuft werden.

Mein zweiter Gedank: Wie unpraktisch. Wenn ich soviele Links auf einmal bekomme, kann ich dafür auch abgestraft werden.

Mein dritter Gedanke: Keine Ahnung, wie Google wohl damit umgeht. Ich habe mir bei SISTRIX die Kurven aller dort verlinkten Sites übereinandergelegt, um einen Trend zu erkennen – nur um zu sehen, dass es keinen solchen gibt. Zumindest in den letzten Monaten ist da nichts dramatisch nach oben oder unten gegangen.

Es scheint auch so, dass Google viele der Seiten gar nicht im Index hat. Das mag noch nicht einmal an den z.T. etwas kryptischen URLs liegen, sondern wohl eher daran, dass Google die Seiten alle als Dubletten erkannt. Wir haben mit ähnlichen Sachen schon mal Tests gemacht, aber in dieser “Härte” hatte ich das noch nicht gesehen. Und ich unterstelle dem Land BW einfach mal, dass es sich nicht um bezahlte Links der Fernschulen handelt (auch, wenn damit sicherlich einiges an Geld zu verdienen wäre).

Also: Würde ich mich darum bemühen, bei www.service-bw.de einen Link zu ergattern, um dann auf hunderten von kommunalen Portalen zu erscheinen? Ja – für den direkten Traffic auf jeden Fall. In Bezug auf Linkaufbau wäre ich da aber etwas zurückhaltender. Da hätte ich immer Angst, dass Google sich auf einmal an den ganzen Links verschluckt – auch wenn ich mir recht sicher bin, dass Google die ganzen Dubletten recht gut rausfiltern kann.

Hat hier jemand noch eine andere Meinung?

Google hat jetzt bestätigt (Blog-Post “Using site speed in web search ranking“), dass die Ladegeschwindigkeit einer Website als Ranking-Faktor einbezogen wird. Aber:

“Currently, fewer than 1% of search queries are affected by the site speed signal”

Und:

“[…] the signal for site speed only applies for visitors searching in English on Google.com at this point.”

Also: Derzeit ist das Ganze noch mit sehr geringen Auswirkungen und in Deutschland ohnehin noch nicht zu spüren.

Der Vollständigkeit halber: Es gibt auch einen guten Post von Matt Cutts zu dem Thema (“Google incorporating site speed in search rankings“).

Seit März diesen Jahres gibt es bei Bloofusion Unterstützung im Bereich Content. Janis Dotschkis möchte Content zum King machen und sich hier einmal kurz vorstellen:

„Seit gut einem Monat darf ich nun in diesem wirklich hervorragendem und gut zugänglichem Team arbeiten und ja, ich fühlte mich wirklich gleich gut aufgehoben.

Sehr gesund, die theoriebeladene Welt meines Wirtschaftsinformatik-Studiums zu verlassen und bei Bloofusion in den doch sehr spezialisierten Bereich SEO einzusteigen. Artikel für Kunden zu recherchieren und redaktionellen Content zu verfassen kann schon eine Herausforderung sein, wenn man sich in den letzten Jahren hauptsächlich mit Optimierung unterschiedlicher Algorithmen beschäftigt hat. Es war aber auch kein völliges Neuland für mich, da ich vor meinem Studium bereits ein Jahr in der Öffentlichkeitsarbeit des Sportgartens in Bremen tätig war.

Das tatsächlich Interessante an dieser Arbeit hier ist es, sich jedes mal wieder völlig neu einzudenken in die sehr unterschiedlichen Themengebiete der Kunden.
Wenn ich mir also nicht gerade den Kopf zerbreche, wie man die Porzellan-Trends 2010 möglichst interessant aufarbeiten kann oder beim Beschreiben der Vorzüge eines Golf-Schloss-Hotels selber ins Schwelgen gerate, steckt erst einmal eine Menge Recherche hinter meiner Arbeit.

Langweilig wird es auf jeden Fall nicht – das kann ich jetzt schon mit ziemlicher Sicherheit sagen. Auch deswegen kann ich mich auf eine nächste gute Zeit mit netten Kollegen (die ich leider wegen meiner überwiegenden Heimarbeit selten sehe) freuen.“

Manchmal muss man auch etwas schreiben, was für die breite Masse überhaupt nicht interessant ist. Heute ist so ein Tag 🙂

Also: Für verschiedene Linkanalysen nutzen wir eine Mischung aus verschiedenen Quellen. In der Vergangenheit war das vor allem die Linkdaten, die man über die Yahoo!-API abfragen kann. Seit etwas mehr als einem Monat nutzen wir aber auch parallel die kostenpflichtigen SEOmoz Site Intelligence APIs.

Für uns stellt sich also die Frage: Lohnt es sich, kostenpflichtige Linkdaten zu beziehen? Es lohnt sich auf jeden Fall, weil wir über die API auch Zugriff auf interessante Werte wie mozTrust und mozRank haben. Aber liefert SEOmoz auch wirklich mehr Linkdaten?

Nach unserer monatlichen Aktualisierung haben wir insgesamt Daten aus der Abfrage von 1.003 Domains vorliegen – statistisch relevant sollten die Daten also sein.

Hier die Zusammenfassung (sorry, alle Daten kann ich leider nicht offenlegen):

Yahoo! lieferte im Schnitt: 441 Backlinks pro Domain
SEOmoz lieferte im Schnitt: 663 Backlinks pro Domain

Yahoo! hat im Schnitt 167 URLs geliefert, die von SEOmoz nicht geliefert wurden
SEOmoz hat im Schnitt 528 URLs geliefert, die von Yahoo! nicht geliefert wurden

44,03% der von Yahoo gelieferten URLs wurden von SEOmoz nicht geliefert
75,59% der von SEOmoz gelieferten URLs wurden von Yahoo! nicht geliefert

Man müsste die Daten eigentlich noch auf Domain-Ebene runterbrechen, aber auch so war das für mich schon aussagekräftig genug. SEOmoz liefert schon wirklich gute Daten, aber keine Linkdatenbank ist eben vollständig. Es macht also durchaus Sinn, die Ergebnisse verschiedener Datenbanken zu mischen.

Das “schlechte” Abschneiden von Yahoo liegt zu einem geringen Teil auch darin begründet, dass Yahoo! nur mit Tricks mehr als 1.000 Backlinks liefert. In der Praxis ist das aber keine große Einschränkung, weil wir bei den Analysen nur selten an die Grenze stoßen.

Meine persönliche Meinung: Ich bin begeistert von SEOmoz. Die API ist sehr gut gemacht & die Daten, die geliefert werden, sind auch hervorragend. Das Vorfiltern von Linkdaten (z.B. Nofollow-Links ausschließen) ist sehr sinnvoll, da man eben für jeden gelieferten Link (bzw. jede Datenzeile) einen nicht unerheblichen Beitrag an SEOmoz bezahlt – und das wiegt umso schwerer, wenn man wie in unserem Fall mehr als Tausend Abfragen stellt.

Laut Google ist es ab sofort möglich, in Sitemap-Dateien nicht die URLs von HTML-Seiten, sondern auch von Bildern abzulegen. Die Spezifikationen gibt’s wie immer bei Google.

Wichtig dabei ist, dass Bilder nicht losgelöst von HTML-Seiten existieren. Man kann also nicht einfach eine Sitemap anlegen, in der alle Bilder vorkommen. Vielmehr muss man die Bilder einer HTML-Seite zuordnen.

Hier ein Code-Schnipsel:

<?xml version=”1.0″ encoding=”UTF-8″?>
<urlset xmlns=”http://www.sitemaps.org/schemas/sitemap/0.9″ xmlns:image=”http://www.google.com/schemas/sitemap-image/1.1″>

<url>
<loc>[URL der Seite]</loc>
<image:image>
<image:loc>[URL des Bildes]</image:loc>
<image:caption>[Bildunterschrift]</image:caption>
<image:geo_location>[Ort, z.B. “Hamburg, Deutschland”]</image:geo_location>
<image:title>[Titel des Bildes]</image:title>
<image:license>[URL mit Lizenzinformationen]</image:license>
</image:image>
</url>

</urlset>

Als “required” wird innerhalb der Bildinformationen nur das loc-Attribute definiert; alle anderen Attribute sind optional.

Auf der SMX hat mich Joachim Glaubrecht nach meiner Präsentation recht kontrovers gefragt, ob Tag-Seiten nicht eigentlich schon tot sind. Grund genug für mich, mir das Thema nochmal anzuschauen. Da kann man theoretisch drüber reden – oder eben einfach einen Test machen.

Für den Test habe ich mir insgesamt 991 Tag-Seiten von Erdbeerlounge.de vorgenommen, die ich über das site-Kommando ermittelt habe. Man kann jetzt argumentieren, dass ich damit das Ergebnis schon ein wenig verfälscht habe, weil das site-Kommando ja auch ein wenig nach interner Gewichtung auflistet. Meine Testmenge entspricht hinsichtlich der internen Relevanz nicht unbedingt einer rein zufällig gewählten Beispielmenge. Ich glaube aber, dass man diesen Effekt für diesen Test vernachlässigen kann, weil es das Ergebnis kaum ändern wird.

Für jedes Tag-Seite (z.B. http://www.erdbeerlounge.de/beliebtes-thema/schubkarre) habe ich also das zugehörige Keyword (in diesem Fall “schubkarre”) ermittelt und über unsere Tools überprüft, wie die Rankings sind. Außerdem habe ich jeweils ermittelt, aus wie vielen Wörtern die jeweilige Suchanfrage besteht. Hier die Übersicht:

1 Wort: 678 Suchanfragen
2 Wörter: 243 Suchanfragen
3 Wörter: 44 Suchanfragen
> 3 Wörter: 26 Suchanfragen

Nach dem Überprüfen der Rankings habe ich dann gesehen, dass es zwar viele Rankings gibt, aber die meisten nicht relevant sind. Für die folgende Statistik habe ich also nur noch die Rankings überprüft, für die es eine Tag-Seite auf die erste Suchergebnisseite geschafft hat (also Position zwischen 1 und 10).

Ergebnis: Von den 991 Tag-Seiten gibt es nur 73, die es auch in die Top 10 schaffen (=7,37%). Auf die Suchanfragen verteilte sich das wie folgt:

1 Wort: 29 Top-10-Rankings (=4,28% der 1-Wort-Suchanfragen)
2 Wörter: 30 Top-10-Rankings (=12,35% der 2-Wort-Suchanfragen)
3 Wörter: 10 Top-10-Rankings (=22,73% der 3-Wort-Suchanfragen)
>3 Wörter: 4 Top-10-Rankings (=15,38% der >3-Wort-Suchanfragen)

Wie man insgesamt sieht (wenn man die >3-Wort-Suchanfragen herausnimmt), steigt die Wahrscheinlichkeit, mit einer Tag-Seite gefunden zu werden, deutlich an, wenn man auf mehrere Wörter abzielt. Viele Suchbegriffe (vor allem die Ein-Wörter) sind einfach zu konkurrenzstark, um dort mit einer automatisiert generierten Seite nach oben (oder überhaupt in die Top 100) zu kommen.

Zurück zur Ausgangsfrage: Lohnen sich Tag-Seiten? Hier im konkreten Beispiel schaffen es immerhin 7,37% der Seiten in die Top 10. Ich halte das für ein gutes Ergebnis, wenn man zweierlei beachtet:

1. Es gibt eben nicht nur 1.000 dieser Tag-Seiten, sondern in der Regel deutlich mehr (bei Erdbeerlounge.de ca. 40.000, laut site-Kommando).
2. Die Seiten werden über einen Mechanismus generiert, d.h. dass man mit einmaligem geringem Entwicklungsaufwand meiner Meinung nach schon einen guten Wert generieren kann.

Der Grund, warum ich Tag-Seiten auf der SMX kurz erwähnt hatte, war übrigens nicht nur unter dem Aspekten, dass man damit direkte Rankings erzielen kann. Ich finde Tag-Seiten auch unter dem Blickwinkel der internen Verlinkung interessant, weil man so “interne Hubs” erzeugen kann, die eine interne thematische Verlinkung erzeugen.

Mein Fazit: Tag-Seiten haben immer noch ihre Berechtigung, wenn man sie denn auch richtig einsetzt. Also: Nicht nur Tag-Seiten für Ein-Wörter, sondern vor allem für Zwei- und Drei-Wort-Suchanfragen. Und: Bei allem sollte man immer Googles inoffizielles Mantra beachten, dass Seiten einen Mehrwert für den Nutzer haben müssen.

Wer glaubt, dass Google aufhört, innovative Produkte auf den Markt zu bringen, irrt. In den Google Labs sind jetzt zwei neue Tools im Beta-Test angelaufen, die auf den Fast-Food-Markt abzielen: Google MeatView und Google FatWords.

Für beide Programme hat Google bereits eine sehr stattliche Anzahl an Partnern gewonnen – darunter alle bekannten Burger-Ketten, aber auch viele kleinere Partner. Die Tools sollen zwei Herausforderungen meistern:

• Das Vertrauen in die Fast-Food-Industrie steigern
• Das enorme Marketing-Potenzial der Fast-Food-Käufer heben

Wir hatten Gelegenheit, die beiden neuen Dienste ausführlich zu testen. Auch wenn es wohl noch einige Monate dauern wird, bis diese überall verfügbar sind, sind diese Programme wohl für viele interessant, die mal schnell zwischendurch was essen wollen.

Google MeatView

Auch Google ist wohl klar, dass Fleisch nicht gleich Fleisch ist. Gerade die zahlreichen Gammelfleischskandale der letzten Monate und Jahre haben die Strategen aus Mountain View wohl aufhorchen lassen.

So bietet der neue Dienst Google MeatView Einblicke in deutsche Ställe und auf Weiden. Wer demnächst einen Burger kauft, sieht auf der Verpackung einen so genannte QR-Code, den man auslesen und dann bei MeatView nachschauen kann, woher das Fleisch stammt. Man kann aber auch den umgekehrten Weg gehen und sich aus dem großen Fundus eine bestimmte Kuh aussuchen und sich dann z. B. über Schlachttermine informieren. In Zukunft wird es dann über Partner-Shops möglich sein, Fleischprodukte eines ausgewählten Nutztiers direkt zu kaufen.

Interessant sind hier vor allem die zahlreichen Informationen und Optionen. So kann man z. B. nur nach “glücklichen Kühen” suchen oder Gammelfleisch direkt ausschließen. Definitiv fehlt hier noch die Auswahl von Bio-Fleisch, aber wie man aus Mountain View bereits hörte, wird auch diese Option bald nachfolgen.

Ungemach droht dem innovativen Dienst aber bereits von unerwarteter Seite, denn auch Tiere haben ein Recht auf Datenschutz. So meldete sich der oberste Tierdatenschützer der Nation, Peter Chaar, direkt zu Wort und beklagte die mangelnde Privatsphäre der Tiere. “Auch eine Kuh hat ein Recht auf ein anonymes Leben. Es ist schlicht nicht rechtens, dass man den Weg des Produktes zur Quelle zurückverfolgen kann. Hier geht mir die Datensammelwut Googles mal wieder deutlich zu weit.”

Ob das wirklich so ist, müssen wohl die Gerichte klären, denn Datenschutz für Nutztiere ist – vielleicht zu Recht – noch eine rechtliche Grauzone. Ein von uns befragter Bauer, der an dem Google-Programm teilnimmt, meinte hierzu: “Das geht doch echt zu weit. Bald hat auch noch ein Gänseblümchen Recht auf Datenschutz!”

Google FatWords

Auch wenn Fast Food nach wie vor ein recht schlechtes Image hat, glaubt Google hier vieles besser machen zu können – und vor allem attraktive, bisher nicht genutzte Werbeflächen erschließen zu können.

So hat Google ein neues Programm namens Google FatWords gestartet (derzeit ebenfalls noch im Beta-Status). Über eine einzigartige Technologie werden dem Kunden Werbebotschaften direkt auf den Burger gebrannt. Und das, ohne den Geschmack zu verändern.

Dabei nutzt Google auch kontextsensitive Targeting-Maßnahmen. So sehen Familien durchaus andere Werbung als Teenies, die gerade von der Disko nach Hause fahren.

Auch die neue Funktion des Remarketing wurde direkt in FatWords integriert – wie man im Bild sieht. Unser Tester hatte sich vor einigen Tagen noch über eine neue SEO-Agentur informiert – und schon sah er dafür auch Werbung auf seinem Burger.

Derzeit sind FatWords leider nur auf Burgern erhältlich. Wer also bei bekannten Burger-Ketten einen Salat bestellt oder auch ein Frühstücksangebot wahrnimmt, erhält derzeit noch keine Werbung. Noch – denn: Das FatWords-Team arbeitet bereits an weiteren Werbeträgern. Dass das nicht so einfach ist, erklärte uns ein Mitarbeiter: “Versuchen Sie mal, mit einem Laser Werbebotschaften in Rührei zu brennen. Das geht gar nicht.”

Hier gibt es also noch viel Forschungsbedarf, der aber sicherlich angesichts der Attraktivität der Zielgruppe gerechtfertigt ist.

Fazit

Google betritt mit den beiden neuen Diensten MeatView und FatWords Neuland. Interessant sind die neuen Dienste auf jeden Fall, auch wenn es noch kleine Detailprobleme gibt und natürlich auch noch rechtliche Bedenken.

Schlussendlich muss sich natürlich jeder fragen, ob er zumindest MeatView überhaupt nutzen möchte, denn Fleischkonsum lebt wohl gerade davon, dass man der Kuh vorab nicht in die Augen (bzw. bei MeatView auf den Hintern) gucken muss. Es könnte also durchaus sein, dass Google der Branche hier einen Bärendienst erweist und so für sinkenden Konsum von Fleisch sorgt. FatWords ist aber definitiv ein interessantes Tool, das die Offline- und die Online-Welten perfekt miteinander verbinden kann.