Google und technisches SEO – Fragen und Tipps für 2013

von Henry Zeitler

Bewertet Google Bilder von CDNs anders in der Bildersuche? Wie behandelt Google mehrere h1-Elemente auf einer Page? Endgültige Aussagen über versteckten Text. pushState() vs. Hashbang und Escaped Fragments in AJAX. Die Wahrheit über inurl: und site: Diagnosen. Fetch like Googlebot außerhalb der WMTs. John Mueller, Webmaster Trends Analyst bei Google Zürich, hat zu diesen Themen auf Google+ Stellung genommen…

Dieser Artikel erschien am 24. Januar 2013 im Netzkern Maigrün-Blog.

Sprungmarker:
  1. Schadet die Verwendungen mehrerer h1-Überschriften auf einer Seite?
  2. Kann Google pushState() genauso interpretieren wie _escaped_fragment_?
  3. Gibt es eine Möglichkeit Fetch as Googlebot außerhalb der Google Webmaster Tools zu anzuwenden?
  4. Gibt es Unterschiede in der Indexierung von Bildern, die von einem Content Delivery Network (CDN) ausgeliefert werden?
  5. Wie behandelt Google Links von URL-Shortener und ab wie vielen Redirects wird es gefährlich?
  6. Wie verlässlich sind inurl: und insite: Abfragen wirklich?
  7. Wie behandelt Google heutzutage eigentlich offensichtlich versteckten Content?
Schadet die Verwendungen mehrerer h1-Überschriften auf einer Seite?

Kurz gesagt nein. Es können durchaus mehrere Überschriften der Kategorie h1 auf derselben Seite verwendet werden. Google wird den Inhalt der Elemente dadurch nicht mehr anders bewerten bzw. gewichten solange seine Information lesbar ist. Das war nicht immer so.
Ein Grund für den Sinneswandel von Google liegt sicherlich in der W3C Candidate Recommendation von HTML5 vom 17. Dezember 2012. Diese besagt nämlich, dass pro Section-Element auf einer Seite ein h1-Tag verwendet werden darf. Somit orientiert sich Google wohl auch maßgeblich an neuen Richtlinien dieser Art.

Kann Google pushState() genauso interpretieren wie _escaped_fragment_?

Kurze Erklärung: Crawler können eigentlich keinen über AJAX dynamisch generierten Inhalt einer Seite indizieren. Google hat aber einen Workaround veröffentlicht um AJAX-Applications crawlbar zu machen. Im Grunde ist es eine aufwändige Methode den dynamischen Content, der mittels eines AJAX-Requests in eine Seite geladen wird, einem Crawler über einen HTML-Snapshot auszuliefern und ihn dabei aber später eine saubere URL verwerten und anzeigen zu lassen. HTML-Snapshot bedeutet, dass für die Suchmaschinen ein zusätzliches Abbild des eigentlichen, nicht indizierbaren Contents in HTML erstellt und über die besagten Escaped Fragments in einer speziellen URL ausgeliefert wird. Klingt umständlich? Ist es auch!
Auf der anderen Seite kommt eine neue Technologie mit der HTML5 API ins Rennen, die den Zweck hat den Pfad der URL für den User in der Adresszeile des Browsers zu ändern und diesen dann in die Browser-Historie aufzunehmen. window.history.pushState(). Hier ein Demo (pushState funktioniert nur in modernen Browsern):

Klicke für ein pushState-Demo und beachte die Adresszeile deines Browsers

Und Google? Google unterstützt diese Technik und kann die manipulierten URLs scheinbar richtig verwerten. Allerdings wird ausdrücklich darauf hingewiesen, dass für ältere Browser immer an eine Fallback-Lösung gedacht werden soll. Auch hier ist das Stichwort wieder Progressive Enhancement.

Gibt es eine Möglichkeit Fetch as Googlebot außerhalb der Google Webmaster Tools zu anzuwenden?

Ja, in der Tat, denn sonst würde ich diese Frage gar nicht stellen. Es gibt zumindest einen sehr guten Trick dieses Tool zu simulieren. Google Translate basiert auf der gleichen Technik, die Fetch as Googlebot auch benutzt um den Content einer Seite zu erfassen mit dem positiven Nebeneffekt, dass es nicht auf den Cache von Google zurückgreift, sondern die Seite in Echtzeit fetched. Somit können auch Seiten, auf die der SEO Manager nicht über die WTs zugreifen kann, auf ihren indexierbaren Content überprüft werden.

Screenshot: Abruf wie durch Googlebot

Gibt es Unterschiede in der Indexierung von Bildern, die von einem Content Delivery Network (CDN) ausgeliefert werden?

Grundsätzlich gibt es keine Probleme beim crawlen der Bilder, wenn für diese eine andere Domain oder Subdomain benutzt wird, meint John Mueller. Allerdings sollte darauf geachtet werden, dass die Adresse der Bilder-Domain sich nicht ändert. Im Falle einer Verschiebung der Dateien oder einer Änderung der URL wird auch bei Bildern ein 301-Redirect empfohlen.

Sollte die Möglichkeit bestehen kann es durchaus nicht schaden die Bilder-Domain entsprechend der eigentlichen Domain zu benennen. Z. B. www.meinedomain.de könnte dann www.meinedomain-bilder.de heißen, einen nennenswerten Vorteil in der Indexierung durch den Google-Bot gibt es dafür jedoch noch nicht, die Zuordnung zur Seite (z. B. bei der Bildersuche) wird jedoch erheblich erleichtert.

Wie behandelt Google Links von URL-Shortener und ab wie vielen Redirects wird es gefährlich?

Kurz zur Erklärung: URL-Shortener wie bit.ly oder goo.gl benutzen einen 301 Redirect um die Umleitung auf den ursprünglichen Link zu bewerkstelligen. Das bedeutet, dass pro Umleitung lediglich 90-99% des Linkjuice weitergegeben wird, aber das Linkziel sonst ganz normal gecrawled wird. Allerdings sollte darauf geachtet werden, dass drei bis maximal fünf Redirects nicht überschritten wird, wobei fünf das Limit der HTML 1.0 Spezifikation darstellt. Webstandards spielen also auch hier eine Rolle.
Matt Cuts hat zum Thema URL-Shortener am 01.06.2009 ein Video veröffentlicht:

Wie verlässlich sind inurl: und insite: Abfragen wirklich?

inurl: und insite: Abfragen sind bei den SEO Managern sehr beliebt. Diese schnellen Abfragen können einfach in der Adressleiste des Browsers getätigt werden ohne sich vorher in ein Tool einloggen zu müssen.
John Mueller allerdings weist ausdrücklich darauf hin, dass diese Abfragen nicht für Diagnose-Zwecke geeignet sind. Sie wurden auch nicht für solche Maßnahmen entwickelt und die ausgelieferten Zahlen für die Suchtreffer spiegeln nur eine grobe Schätzung wieder. Um verlässliche Werte zu bekommen eignen sich die einschlägigen Diagnose-Tools dann doch wesentlich besser.

Wie behandelt Google heutzutage eigentlich offensichtlich versteckten Content?

Nach wie vor gilt die Regel, dass Content, der während des Rendervorgangs einer Seite über display: none oder visibility: hidden mittels CSS ausgeblendet wird, auch von Google keine Beachtung finden wird. Das ist offensichtlich versteckter Inhalt und Google geht davon aus, dass dieser allen Besuchern absichtlich vorenthalten werden soll.
Auf der anderen Seite gibt es Fälle, in denen Content aus technischen Gründen verborgen werden muss. Z. B. bei manchen Varianten von Tab- oder Akkordeon-Boxen. In diesen Fällen bietet es sich eher an die Elemente über Javascript zu verbergen, damit für User mit wiederum deaktiviertem Javascript aber auch für Screenreader der Content sichtbar bleibt. Das Prinzip nennt sich Progressive Enhancement und Google findet es gut.

comments powered by Disqus