Henry-Zeitler
Web Entwickler Frontend

Google und technisches SEO – wichtige Fragen und Antworten für 2013


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…


Schadet die Verwendung 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 einen Abruf "Fetch as Googlebot" außerhalb der Google Webmaster Tools zu starten?

Screenshot: Abruf wie durch Googlebot

Ja, in der Tat. 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.


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 werden, 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 ignoriert 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 Graceful Degradation und ist ein Teil von Progressive Enhancement und Google findet es gut.

 

Kommentare
1

Heiko Stiegert

In Bezug auf HTML5 und die semantische Strukturierung von Inhalten, ist die Frage doch die, wie Google dann eine h1 aus einem Bereich "article", mit einer Überschrift h1 aus dem Bereich "footer" vergleicht und vor allem bewertet. Ob man sich dann noch einen Gefallen damit tut, dürfte interessant werden. Auf wenn jeder einzelne HTML5 Bereich eine h1 beinhalten darf, ergibt alles zusammen immer noch ein Dokument und dieses sollte (zumindest meiner Meinung nach) auch nur eine Hauptüberschrift besitzen.

am 25.01.2013

2

Sebastian Socha

@Heiko:

"... und dieses sollte (zumindest meiner Meinung nach) auch nur eine Hauptüberschrift besitzen."

Im Grunde hat Dein Dokument am Ende auch bei mehreren H1-Überschriften eine Hauptüberschrift: Und zwar den Seiten-Titel.

Gruß,
Sebastian

am 05.02.2014

Kommentar hinzufügen
Vor und Zuname
E-Mail
E-Mail bei weiteren Kommentaren
Mein Kommentar