So, das war wieder einer dieser vollen Tage. Wenn das suchradar rauskommt, kostet das immer Nerven. Danke auf jeden Fall an Martin und Richard, ohne die das so in diesem Umfang wohl nicht möglich wäre. (Richard hat beim Kickern gegen Martin und mich gestern knapp verloren, was mir Hoffnung macht, dass das ganze Training zu was führt…)

Auf jeden Fall ist es jetzt da, das neue suchradar Ausgabe 18. Folgende Themen haben wir diesmal im Gepäck:

Titelthema:
> Optimieren für Google Maps
> AdWords: Drei Wege zum Kunden vor Ort

Außerdem:
> Trennung von redaktionellem Inhalt und Werbung
> Internationales SEO: Ein Interview mit Marcell Sarközy
> Wolfram Alpha und Google Squared
> Rich Snippets: Vorhang auf für Microformats und RDFa
> PDFs für Suchmaschinen optimieren
> Google AdWords-Werkstatt: Display Ad Builder

Besser geht’s immer: Das ist auch das Motto von einem hübschen Google-Video. Auf der Seite dazu gibt’s noch ein paar mehr Infos, wie man weniger Geld verbrennen kann und die Cost per Conversion senkt. Nichts Neues, aber trotzdem hübsch in Szene gesetzt:

In vielen Beiträgen der letzten Tage (u.a. “Doppelte Inhalte nutzen“) scheinen SEOs wieder die Idee zu diskutieren, ungeliebte Inhalte – ob Text oder Links – in ein Iframe auszulagern. Wenn man die per Iframe eingebundene Datei dann noch per robots.txt und Robots-Tag (doppelt gemoppelt hält besser) sperrt, sollten diese Inhalte für Google & Co nicht sichtbar sein.

Ein Teil dieser Ideen stammt aus der verlorenen Schlacht um PageRank Sculpting. Wenn es also nicht mehr möglich, einzelne Links per Nofollow zu sperren und den dabei frei werdenden Link Juice für die “guten” Seiten zu behalten, könnte man aber die “schlechten” Links alle in ein Iframe auslagern und würde somit dann eben doch den Effekt erzielen, dass Google die Links nicht mehr sieht und rein rechnerisch mehr PageRank für die “guten” Seiten übrig bleibt. (Auch wenn Matt Cutts meinte, dass die Berechnung der internen Verlinkungen wesentlich komplexer sei)

Prinzipiell klingt das alles gut. Das wäre dann wohl “Page Sculpting” (he, habe ich hier ein neues Buzzword gefunden? PageSculpting.com ist noch frei…).

Ich erinnere mich in dem Zusammenhang aber auch noch an einen Forenbeitrag (URL natürlich vergessen), in dem der Fall diskutiert wurde, dass Google automatisiert Seiten mit großem Iframe als schlecht einstufte und das natürlich auch Seiten traf, die ein Iframe aus gutem Grund eingebunden hatten. Auch wenn dieses Verhalten so vielleicht nicht mehr existiert, wird das übliche passieren: Sobald zu viele Website “Page Sculpting” einsetzen und selektiv Seitenbestandteile vor Google verstecken, wird irgendwo in Mountain View wieder ein Schalter umgelegt und einige Webmaster haben einen verdammt schlechten Tag.

Die Jungs von SEOmoz waren beim letzten Whiteboard Friday von der Iframe-Idee auch nicht gerade begeistert. Ich schließ mich dem erstmal an. Die Idee finde ich gut, aber der Spielverderber Google würde irgendwann gegensteuern. Und dann macht es keinen Sinn. (Zumindest nicht für unsere regulären Kunden… bei den eigenen Portalen könnte man’s ja mal ausprobieren )

Ich hab mich schon immer gefragt, wie wichtig eigentlich das Google-Feature “Safe Browsing” ist. Dabei überprüft Google Websites, ob diese schädliche Software (Malware/Spyware/…) auf dem Computer des Website-Besuchers installieren können.

Wenn Google eine Website für gefährlich hält, erfährt man das in den Suchergebnissen vor allem durch den zusätzlichen Link “Diese Website kann Ihren Computer beschädigen”:

Wer diese Warnung ignoriert und trotzdem auf das Suchergebnis klickt, kommt allerdings auch nicht sehr weit:

Wer wissen will, wie die eigene Website von Google beurteilt wird, kann das über die folgende URL machen (Domain einfügen). Gegen die Internetkapitaene.de liegt zur Zeit zum Glück nichts vor:

http://www.google.com/safebrowsing/diagnostic?site=internetkapitaene.de

Wir wollten mal wissen, wie viele Websites eigentlich aktuell von Google als gefährlich eingestuft werden und haben verschiedene URL-Mengen (jeweils 25.000 URLs aus dem DMOZ, aus unserer Host-Datenbank, …) genommen und jede URL bei Google geprüft. Das Ergebnis:

1. Die Anteile schwanken abhängig von der Testmenge. Je nach Qualität der getesteten URLs liegt die Chance auf einen Treffer bei ca. 1:1000 – 1:5000.
2. Die meisten Websites, die als gefährlich eingestuft werden, sind offenbar gehackt worden. Viele der Websites waren schon gar nicht mehr erreichbar und wiesen auf “Technische Probleme” (o.Ä.) hin.

Wir empfehlen Website-Betreibern auf jeden Fall, ihre eigenen Websites regelmäßig bei Google zu testen, weil auch ein Hack nicht unbedingt sofort auffällt. Die eigene Website könnte also als gefährlich eingestuft werden, ohne dass man selber daran eine direkte Schuld trägt.

Seit einigen Tagen kürzt Google URLs bei der Darstellung anders als bisher – ein Schritt, den ich nicht gerade positiv finde, weil die angezeigten URLs nun oft durch “..” verschandelt werden und man z.B. nicht mehr den vollen URL-Pfad auf einmal sehen kann. Google hat auch früher schon gekürzt, aber die neuen Regeln gehen doch insgesamt sehr weit.

Bei der Analyse von Google-Ergebnissen sind mir vor allem die folgenden Regeln aufgefallen:

(1) Es werden “Ordner” aus dem URL-Pfad entfernt.
Angezeigt: www.mydearvalentine.com/…/hochzeitstorte.html
Reale URL: http://www.mydearvalentine.com/valentinstag/hochzeitstorte.html

(2) CGI-Parameter werden gestrichen.
Angezeigt: shop.strato.de/epages/61741519.sf/de_DE/?…
Reale URL: http://shop.strato.de/epages/61741519.sf/de_DE/?ObjectPath=/Shops/61741519/Products/PD-2-8-0005

(3) Parameter-Werte können gekürzt werden.
Angezeigt: sport.rtl.de/vips/vips_46012.php?media…set…
Reale URL: http://sport.rtl.de/vips/vips_46012.php?media=video3&set_id=22614

(4) URLs, die nicht unter diese Regeln fallen (z.B. weil Sie keine Ordner beinhalten), werden klassisch mit Punkten am Ende gekürzt.
Angezeigt: berlin.kijiji.de/c-Dienstleistungen-Event-Veranstaltungsservice-Hochzeitstorte -Geburtstagstorte-Torten-Kuchen-vom-Profi-W0Q…
Reale URL: http://berlin.kijiji.de/c-Dienstleistungen-Event-Veranstaltungsservice-Hochzeitstorte-Geburtstagstorte-Torten-Kuchen-vom-Profi-W0QQAdIdZ134465674

Was folgt daraus? Wie gesagt: Mir gefallen die Kürzungen nicht, weil es – zumindest für mich – so aussieht, als sei die URL wesentlich länger. Zum Glück ist es zumindest so, dass nicht wahllos gekürzt wird, sondern dass versucht wird, die Bestandteile sichtbar zu halten, in denen die Suchbegriffe vorkommen.

Das Ganze könnte Website-Betreiber motivieren, möglichst kurze URLs zu generieren und auf Ordner-Strukturen zu verzichten, also z.B. eher www.site.de/hochzeitstorte-bremen/ anstelle von www.site.de/hochzeitstorte/bremen/.

Wer vorher Ordner-Strukturen wie /a-z/krankheiten/diabetes/ hatte, würde eher auf eine flache Ordner-Struktur ausweichen (also /diabetes/), bei der es nur noch einen Ordner gibt.

Kurze URLs waren ja auch vorher schon empfehlenswert, aber mit diesen Änderungen werden sie es noch mehr. Wenn das Website-Betreiber davon abhält, Ordner-Strukturen in URLs abzubilden, ist das meiner Meinung nach schon ein Rückschritt. Aber wenn Google das so will…

Wir haben soeben von unserem Grafiker Sascha Jaeck den neuesten Comic-Strip “Neulich aus der Agentur” bekommen:

Wie immer: Das hat natürlich alles nichts mit unserer Agentur zu tun (Wir würden nie Kunden raten, alles auf Twitter zu setzen… vielleicht eher auf Mister Wong?)

Ich habe den Testlauf noch ein wenig ausgedehnt, um aussagekräftige Zahlen zu bekommen. Zur Erinnerung: Es geht um die Frage, inwieweit Websites bereits Microformats oder RDFa nutzen, um so u.a. “Rich Snippets” zu bekommen. Dafür haben wir viele Suchanfragen an Google geschickt und die Seiten analysiert.

Als Keywords wurden viele verschiedene Keywords rund um Test/Testberichte/Bewertung/Review jeweils in Kombination mit einer Produktkategorie oder einem konkreten Produkt gewählt. Für diese Suchbegriffe wurden jeweils die ersten 100 Suchergebnisse ausgewertet.

Englischsprachige Suchbegriffe:
14.205 URLs geprüft
Bei 690 URLs setzten die Seiten auf Microformats oder RDFa (=4,86%)
232 unterschiedliche Domains gefunden, die Microformats nutzen
6 unterschiedliche Domains gefunden, die RDFa nutzen

Deutschsprachige Suchbegriffe:
12.153 URLs geprüft
Bei 98 URLs setzten die Seiten auf Microformats oder RDFa (=0,81%)
36 unterschiedliche Domains gefunden, die Microformats nutzen (die meisten davon waren aber Sub-Domains von softonic.de)
0 unterschiedliche Domains gefunden, die RDFa nutzen

Unter den deutschsprachigen Sites, die Microformats einsetzen, findet man u.a.

• Kelkoo.de
• Autotest.de
• Testeo.de
• Pricerunner.de

Bei den englischsprachigen Sites haben wir u.a. die folgenden Sites gefunden:

• About.com
• CNET.com
• store.apple.com
• Gamespot.com
• Cars.com
• Amazon.com (aber nur auf wenigen Seiten)

Man sieht also insgesamt schon ein klares Gefälle (4,86% im Vergleich zu 0,81%). Die Amerikaner sind uns also online mal wieder voraus…

Ich bin ja von den Möglichkeiten, die Microformats und RDFa bieten, begeistert. Vor allem, weil man dadurch halt in der Zukunft mal erweiterte Snippets (Rich Snippets) bekommen könnte.

Ich schreibe darüber auch gerade einen Artikel fürs suchradar und wollte den Artikel eigentlich noch gerne mit einem Positivbeispiel schmücken – z.B. einen Online-Shop, der seine Bewertungen bereits gemäß hReview formatiert. Also: Python angeschmissen, Spider geschrieben, tausende von Suchergebnissen abgeprüft und – NULL. Unter den tausenden Seiten, die überprüft, gab es nicht eine einzige, die hReviev implementiert (dito für RDFa).

Irgendwie hätte ich erwartet, dass sich zumindest einige Preisportale schnell an das Thema gewagt hätten. Dann muss ich wohl mal unter US-Websites nach einem Beispiel suchen…

Meine Güte. Es gab viele Beiträge in den letzten Tagen zum Thema PageRank Sculpting.

Jetzt hat zumindest Matt Cutts auch noch was dazu geschrieben: “PageRank sculpting“. Ich habe irgendwie nicht den Eindruck, dass das der letzte Beitrag zum Thema ist, weil wieder viele Fragen offen bleiben, z.B.

> Schadet massives PageRank Sculpting oder werden die Nofollows dann einfach ignoriert?
> Hat gefühlvolles PageRank Sculpting nun gar keinen Wert? Oder nur einen geringen?

In jedem Fall kann ich langsam nicht mehr hören, wie wichtig toller Content ist und wie wichtig eine gute Site-Architektur ist. Natürlich ist es das. Die meisten Unternehmen nutzen diese Feinheiten ja für’s Finetuning und nicht, um Defizite in der Struktur zu beheben. (Zumindest nicht bei unseren Kunden)

Ich hoffe, dass das der letzte Post zum Thema war.

P.S.: Und jetzt geht’s nach Hause. Rückflug vom iico-Kongress, auf dem ich einen Vortrag gehalten habe. Ich hoffe, dass die Jungs von Air Berlin uns nicht wieder im Bus kurz vorm Flugzeug zurückschicken, um noch schnell ein paar Teile zu wechseln. Warum gibt mir das irgendwie kein gutes Gefühl?

Yahoo hat jetzt angekündigt, dass sie ab sofort auch Common Tags unterstützen – ein Tagging-Standard, der für mehr Ordnung auf dem Weg zum Semantic Web sorgen soll.

Es gibt zwar bereits über Microformats die Möglichkeit, Tags als solche zu markieren, aber über die Common Tags erreicht man zumindest den Vorteil, dass ein Tag eindeutig ist.

So könnte man bei herkömmlichem Tagging die Stadt New York als “new york”, “new york city”, “nyc” oder “ny city” taggen. Man erreicht also keine Eindeutigkeit.

Mit den Common Tags kommt nun die Eindeutigkeit. Für fast jedes “Ding” gibt es ein offizielles Tag. Zudem gibt es zu diesem Tag jeweils verschiedene Attribute. Für Luke Skywalker gibt es also das Tag “Luke Skywalker”, dessen Attribute sich hier finden: http://dbpedia.org/page/Luke_Skywalker

Ich möchte hier gar nicht allzusehr in die Tiefe gehen, weil es meiner Meinung nach für die breite Masse derzeit nicht interessant ist. Interessant ist das Ganze prinzipiell schon, aber ich rechne dem keine großen Chancen ein – auch, weil Branchen-Primus das derzeit nicht unterstützt.

Wer mehr zum Thema erfahren möchte, sei auf die folgenden Seiten verwiesen:

Search Engine Land:
Yahoo! Announces Common Tag: Like The Meta Keywords Tag, But Even Better

Yahoo! Search Blog:
New Common Tag Format

Common Tag Website:
www.commontag.org