Hier findet Ihr das deutsche Transkript des Google Webmaster Hangout vom 05. Oktober 2018:
Noindex
Zeit: 00:43
Frage: Wir wurden darauf aufmerksam gemacht, dass unsere Website möglicherweise nicht vollständig mit der Datenschutz-Grundversorgung übereinstimmt, da wir unsere Nutzer nicht auf bestimmte Funktionen wie die Veröffentlichung ihrer Profile beschränken. Um mit dem Datenschutz konform zu werden, denken wir darüber nach bestimmte Seiten von der Suche auszuschließen, sie zur Robots.txt hinzuzufügen usw. Uns interessiert nun, ob es eine Möglichkeit gibt, Google zu sagen einfach bestimmte Seiten zu löschen, also sie aus dem Index auszuschließen. Ich habe gehört, dass es eine recht Aktuelle Version von der "Google Index API" gibt. Ich habe mich also gefragt, ob die Google-Suche Webmastern erlauben kann, Seiten einfach zu löschen und nicht nur eine Seite nach der anderen, sondern eine große Anzahl von Seiten?
Antwort: Wir haben keine Art von Lösch-API, die öffentlich für Masseneinträge wie diese verfügbar ist. Wenn es ein klarer Teil Eurer Seite ist, wie Unterverzeichnis oder ein bestimmter Dateiname oder Ähnliches, könnt Ihr aber das URL-Removal-Tool benutzen. Sagt uns also in der Search Console, dass z. B alles, was mit PHP anfängt, wir aus der Google Suche rausfallen lassen können. Das wäre ein erster schneller Schritt, um dies zu lösen. Wenn Ihr es nicht individuell machen wollt, könnt Ihr ein Robots-"Noindex" auf die Seiten setzen. Wenn Ihr diese etwas schneller aktualisieren möchtet, könnt Ihr uns per Sitemap-Datei sagen, dass diese Seite kürzlich geändert wurde und wir werden uns diese Seite ansehen und wenn es ein "Noindex" auf dieser Seite gibt, werden wir es aus unserem Index entfernen. Aber eine spezifische Liste von Dateien, die Ihr uns übermitteln könnt und die Seiten sofort alle rausnehmen, ist aktuell nicht verfügbar.
Dynamic Rendering
Zeit: 9:54
Frage: Eine Teil der Seite hat JavaScript. Wann soll ich Dynamic Rendering anwenden?
Antwort: Zuallererst solltet Ihr erwägen, Hilfe von Euren Entwicklern zu erfragen oder Euch mit den Einzelheiten beschäftigen, wie JavaScript genau funktioniert. Ihr solltet zuerst checken, welche Art von Inhalte mit JavaScript kreiert werden. Ist JavaScript also hauptsächlich erforderlich, um für die Seite wichtigen Inhalt anzuzeigen oder ist JavaScript im Wesentlichen nur eine Erweiterung der Seite? Wenn Ihr beispielsweise zusätzliche Funktionen wie z. B. phantasievolle Übergänge zwischen verschiedenen Zuständen mit Hilfe von JavaScript hinzufügt, ist möglicherweise Euer primärer Inhalt im normalen HTML verfügbar und Ihr müsst Euch nicht wirklich um JavaScript sorgen. Eine andere Typische Situation ist auch, dass Ihr Euren Hauptinhalt in HTML habt und JavaScript für Werbung benutzt, auch hier ist ist der hauptsächliche Inhalt vorhanden und JavaScript ist nur zusätzliche Arbeit ihn erscheinen zu lassen. Wenn Ihr mehr auf die JavaScript-basierte Website verschiebt und wenn Ihr JavaScript in Euren Browser ausschaltet, dann seht Ihr keinen Inhalt, vielleicht seht Ihr eine Art Struktur der Seite, aber nichts von dem Inhalt. Das ist die Situation, in der diese Seite JavaScript benötigt, um den kritischen Inhalt auf der Seite anzuzeigen. In diesem Stadium solltet Ihr darüber nachdenken was ihr tun müsst, damit diese Seite für Suchmaschinen funktioniert.
Der Googlebot kann inzwischen sehr gut JavaScript ausführen und es kann sein, dass das JavaScript, welches Ihr für Eure Seite benutzt, im Googlebot sehr gut aussieht. Eine einfache Möglichkeit dies zu testen besteht also darin nach einem Teil des Textes zu suchen und festzustellen, ob Google diese Seiten hervorbringen kann. Wenn diese Seiten auftauchen, dann funktionieren die Dinge wahrscheinlich gut, wenn diese Seiten nicht in der Suche erscheinen, könnte es sein, dass wir Schwierigkeiten haben JavaScript auszuführen. Ein Ansatz wäre nun, die "Dynamic Rendering Route" entlang zu gehen um herauszufinden, was den Googlebot blockiert, vielleicht ist es was simples, wie z. B. eine Blockierung durch die Robots.txt-Datei. Dies sollte man beheben, damit der Googlebot diese Seiten rendern kann.
Wenn der Googlebot eine Seite rendern muss, brauchen wir in der Regel etwas länger, um diese in unseren Index aufzunehmen. Zuerst rendern wir das statische HTML und im zweiten Schritt rendern wird die Seite und schauen auf all ihre Links mit JavaScript und verarbeiten die Seite so. Für die meisten Webseiten läuft das ohne Probleme ab. Wenn Ihr jedoch eine Website habt, die sich schnell verändert und immer schnell indexiert werden muss, wie z. B. bei News-Websites, kann es etwas problematisch sein, wenn der Googlebot eine Woche oder einige Tage braucht, um die Seite zu rendern. Das ist dann nicht optimal. Das wäre dann eine Situation, in der Ihr das Dynamic Rendering anwendet. Mit dem Dynamic Rendering macht Ihr die Sache sehr komplex, denn ihr müsst selber rendern. Es ist keine triviale Sache, die man mal eben an und ausstellen kann. Ihr müsst Euch wirklich überlegen: Wo spielt es in meine Website rein? Ist es für meine Website überhaupt erforderlich und wenn ja, wie stelle ich es ein? Und wie überwache es? Das ist eine sehr technische Angelegenheit, wenn ihr also SEO macht und nicht ganz so sicher mit JavaScript seid, würde ich auf jeden Fall einen Entwickler zu Rate ziehen.
Hreflang
Zeit: 20:55
Frage: Sind Hreflang und Indexing wie ein Canonical? Ist es ein Problem, wenn alle Hreflang-Seiten ein Noindex haben? Dies passiert, wenn unsere Produkte ausverkauft sind und wir für die nächsten 6-8 Wochen nichts auf Lager haben.
Antwort: Wir nutzen Hreflang als kleines Signal, wenn es dazu kommt ein Canonical zu wählen, denn wir brauchen einen Hreflang-Link zwischen kanonischen Seiten. Ihr müsst dies jedoch unbedingt mit all Euren anderen üblichen Canonicalization-Signalen unterstützen so wie rel-canoniocal, internes linking, Sitemap-Dateien und externes linking. All diese Dinge müssen idealerweise aufeinander abgestimmt werden und dann werden wir diese URLs eher als Canonical auswählen und die Hreflang Link-Verbindung zwischen ihnen herstellen können. Bezüglich Noindex: Wenn eine Seite auf "Noindex" gesetzt ist, wählen wir sie nicht als Canonical und würden sie nicht für Hreflang verwenden. In dem Falle, wenn bei mehreren Seiten einige auf Noindex stehen und andere indexierbar sind, arbeiten wir nur mit denen, die funktionieren. Das bedeutet aber nicht, dass wir die Seite als weniger qualitativ ansehen oder wir alle Hreflang-Links von dieser Gruppe entfernen. Wenn also in Eurem Fall ein Produkt ausverkauft ist und diese Seiten einen Noindex und Hreflang Links haben, werden wir die Seite aus unserem Index streichen, wir werden sie nicht in den Suchergebnissen zeigen und wenn wir sie in den Suchergebnissen nicht anzeigen, müssen wir uns nicht um die Hreflang-Verbindungen kümmern. Das sollte also kein Problem sein.
Google Images
Zeit: 23:06
Frage: Gibt es einen Unterschied zwischen dem optimalen Seitenverhältnis bei Mobile vs. Desktop Suche. Was ist das optimale Seitenverhältnis?
Antwort: Für beides habe ich kein optimales Seitenverhältnis. Ich denke, das kommt auf Eure Bilder an und was Ihr versucht, zu präsentieren. Beim Thema "Google Bilder" achten wir auf viele verschiedene Dinge, wir haben ein Dokument mit Bildveröffentlichungs-Richtlinien, das in der Zwischenzeit ziemlich umfangreich geworden ist und viele der involvierten Bereiche abdeckt. Das würde ich mir definitiv mal anschauen. Was ich bemerkt habe, als wir zu "Mobile-first-Indexing" übergegangen sind, wo wir Seiten indexieren wie auf einem Smartphone-Display, dass einige Seiten einen anderen Inhalt für Smartphones haben und nicht den Alt-Text für ihre Bilder nutzen. Und das ist ein Problem für uns, denn wir nutzen den Alt-Text als wirklich starkes Signal, um das Bild besser verstehen zu können. Hier würde ich also empfehlen zu überprüfen, dass in der Smartphone-Version auf jeden Fall auch der Alt-Text genutzt wird.
Eine Stelle, an der das Seitenverhältnis ins Spiel kommt, sind bestimmte Arten von strukturierten Daten, je nachdem wie Eure Bilder angezeigt werden sollen. Wenn es zum Beispiel ein Teil eines Rezepts oder ein Teil von vielleicht einem AMP-Artikel ist, den Ihr auf Eurer Seite habt, dann gibt es für einige Arten von strukturierten Daten und Rich Results Vorschläge in Bezug auf das optimale Seitenverhältnis, das dort gut funktionieren würde, auch bezogen auf die minimale Größe und Anzahl an Pixel Eures Bildes. Das gilt aber nicht für "Google Images", sondern nur für die Rich Results in der normalen Websuche.
503 und 200
Zeit: 26:55
Frage: Können wir den Response-Code 503 für den Googlebot und 200 für den Benutzer für einen Tag zurückgeben, um sicherzustellen, dass im Falle einer Migration oder Änderung einer Seiten-Struktur alles in Ordnung ist?
Antwort: Man kann es machen, aber ich würde es nicht empfehlen, da es eher ein Verstecken eines Problems hinter einem 503 ist. Wenn Ihr mal einen Tag wegen technischen Problemen oder wegen einer Migration des Servers eine 503 wiedergeben müsst, ist das vollkommen ok, denn wir werden versuchen diese URLs etwas später erneut zu crawlen. Wir behandeln dies nicht als einen permanenten Fehler. Wenn wir 503 jedoch für eine längerer Periode sehen, werden wir das als einen dauerhaften Fehler einstufen und wir könnten anfangen, diese Seiten aus unserem Index zu werfen. Eine längere Periode ist in der Regel einige Tage oder ungefähr eine Woche, es kommt immer auf die Website an sich an. Dem Googlebot Code 503 wiederzugeben und dem Nutzer 200 ist auch vollkommen ok. Das würde ich aber ebenfalls nur für eine begrenzte Zeit machen.
Mehrere Seiten auf der gleichen Plattform
Zeit: 29:12
Frage: Ist es schädlich für SEO mehrere Seiten auf der gleichen Plattform zu haben? Könnte dies zu einer manuellen Aktion oder zu einer algorithmischen Strafe führen?
Antwort: Das ist vollkommen ok und kommt häufig vor. Wenn Ihr zum Beispiel "Blogger" benutzt, dann nutzen offensichtlich all diese Blogs dieselbe Plattform und selbst wenn einige der Blogs auf der Plattform spammy sind oder mit geringeren Qualität, heisst dies noch lange nicht, dass das dann alle sind. Ähnlich wie bei WordPress, es gibt Unmengen von WordPress-Sites, die die gleichen Vorlagen oder Hosts auf einem Shared-Hosting verwenden, und das bedeutet nicht, dass diese Sites alle problematisch sind oder eine geringere Qualität aufweisen, nur weil sie eine gemeinsam genutzte Infrastruktur verwenden.
404
Zeit: 30:09
Frage: In meiner Search Console sehe ich viele Links, die Soft 404 sind und vom Crawlen ausgeschlossen sind, aber das sind eigentlich echte Seiten. Meine Website hat ein Archiv von Dingen, die nicht mehr existieren. Meine Website katalogisiert Dinge in der realen Welt. Es sieht so aus, dass alles im Archiv vom Crawling ausgeschlossen wird. Wie kann ich diese Seiten vom Googlebot indexieren lassen?
Antwort: Ich habe mir das angeschaut und kann mit vorstellen, dass unsere Algorithmen das als ein Art “Nicht auf Lager”-Nachricht ansehen. Ihr teilt uns mit uns, dass dieser Inhalt nicht mehr existiert, also lassen unsere Algorithmen das aus dem Index fallen. Hier sind unsere Systeme etwas verwirrt. Das ist etwas wo wir unsere Arbeit intern etwas verbessern können, aber das ist auch etwas, was Ihr auch von eurer Seite aus etwas anders handhaben könntet.
Ich weiß nicht, wieviel von Eurem Inhalt so aufgebaut ist, aber vielleicht gibt es eine Möglichkeit ihn so zu gestalten, dass er nicht wie eine “Nicht mehr auf Lager”-Nachricht rüber kommt. Ich gebe das auch an unser Team weiter.
Boilerplate I
Zeit: 35:14
Frage: Wir haben eine Nachrichten-Website mit einer Multifunktionsleiste “above the fold”, welche die neuesten Artikel enthält. Da diese Artikel immer nach einigen Stunden ersetzt werden, werden alle unsere Seiten mit dem Inhalt der Multifunktionsleiste indexiert. Infolgedessen enden unsere Seiten für diese Suchanfragen, die sich auf Keywords beziehen, die nicht auf dem Inhalt der Seiten gefunden werden können. Was würdest Du empfehlen?
Antwort: Ich sehe hier zwei Aspekte. Zum einen könnt Ihr technische Mittel anwenden, um zu verhindern, dass die Multifunktionsleiste gecrawlt und indexiert wird. Ihr könntet JavaScript benutzen, das von der Robots.txt-Datei geblockt wird, einen iFrame u. v. m., theoretisch ist das möglich, aber eigentlich müsst Ihr das nicht tun. Im Allgemeinen sollte Eure Seite den primären Inhalt auf der Seite erkennen indem sie erkennt, dass diese Menüleiste ein Teil des Boilerplates Eurer Seite ist und wir sollten dazu fähig sein, das zu ignorieren. Wenn wir also Eure normalen Artikel nicht für die primären Keywords auf diesen Seiten zeigen, dann klingt das eher so, als hätten wir Probleme diese Artikel zu lesen und den normalen Inhalt zu erkennen. Wenn wir für die normale Suche nach Euren Inhalten die richtigen Seiten zeigen, dann ist das vollkommen in Ordnung, ich würde mir keine Sorgen machen, dass auch andere Seiten ranken. Wenn auf der anderen Seite Eure normalen Seiten überhaupt nicht ranken und nur zufällige andere Seiten aufgrund dieser Art von gemeinsam genutzten dynamischen Elementen auf der Seite ranken, dann hört sich das eher nach einem technischen Problem an. Das würde ich versuchen zu differenzieren.
Boilerplate II
Zeit: 38:14
Frage: Wenn Google versucht einen Canonical zu bestimmen, berücksichtigt Google auch den Boilerplate mit der Navigation und alle Links sind nur der Inhalt ohne den Boilerplate. Ich frage, denn wir hatten eine Navigation mit mehr Worten auf der Navigation als auf den inhaltlichen Seiten. Nachdem wir die Navigation verkleinert haben, haben wir viele Canonicals verloren.
Antwort: Wir berücksichtigen eine Reihe von Dingen, wenn wir herausfinden wollen, ob die Seiten in Bezug auf Canonicalization identisch sind oder nicht. Oft gibt es dynamische Inhalte auf diesen Seiten, manchmal ist das ein Menü und Navigation oder eine Seitenleiste und Fußzeile, daher versuchen wir uns auf den primären Inhalt einer Seite zu konzentrieren und wir versuchen dies zu nutzen, um zu erkennen, welche dieser Seiten als gleichwertig betrachtet werden sollten. Wenn ihr das Boilerplate oder die Seitennavigation ändert, kann es etwas dauern, bis wir das aufnehmen und erkennen, dass das, was dort passiert, ein Teil der Boilerplate ist und kein Teil des Hauptinhaltes. Dass Eure Canonicals alle verloren gegangen sind, nachdem ihr die Navigation verändert habt, hört sich jedoch nach einem anderen Problem an. Ich glaube nicht, dass das an dem Boilerplate liegt oder der Canonicalization generell.
Tag-Seiten
Zeit: 45:26
Frage: Wenn ich zum ersten Mal eine Seite erstelle und sie an den Google-Index sende, sehe ich sie manchmal in den Suchergebnissen und dort steht dort "Archive" nach dem Tag-Namen und es geht nicht wirklich auf die direkte Seite, auf der die Informationen stehen, sondern geht einfach zum Tag-Archive. Ich lege den Tag mit dem Thema auf die Seite, man kann sie anklicken und es geht auf die Seite, aber nicht direkt, da Google das Archiv und nicht die tatsächliche Seite abholt. Ist es besser keinen Tag zu verwenden, damit das Archiv nicht gezeigt wird oder findet Google die richtige Seite nach einer Weile?
Antwort: Ich glaube es liegt daran, dass wir einige Seiten schneller annehmen, als andere. Bei einigen dauert es etwas länger bis wir sie crawlen. Diese Tag-Seiten bzw. Kategorieseiten sind welche, die wir häufiger crawlen, weil sich der Inhalt dort ziemlich schnell ändert und wir müssen damit Schritt halten. Und die Seiten wiederum, die von diesen Kategorie Seiten verlinkt sind, kommen im zweiten Schritt. Also aktualisieren wir zuerst die Kategorie Seite und wenn wir sehen, dass es einen Link zu einem neuen Artikel gibt, folgen wir diesem und versuchen ihm im zweiten Schritt zu crawlen und zu indexen. Das ist der normale Ansatz wie Dinge aktualisiert werden. Für viele Websites ist es auch sinnvoll die neueren Inhalte ein wenig besser innerhalb der Website zu verlinken, anstatt nur die Kategorie Seiten prominent zu verlinken, also auch den neuen Inhalt hervorheben, den Ihr für wichtig haltet. Wie zum Beispiel in der Seitenleiste einen Link beennen wie “aktuellste Artikel” oder “wichtige Produkte”, um Neuerungen offensichtlicher zu machen.
Canonical
Zeit: 48:30
Frage: Wenn wir eine deutsche, österreichische und schweizer E-Commerce Seite zu einer deutschen Domain kanonikalisieren, sollten wir damit aufhören Sitemaps für die AT und die CH Domain zu senden?
Antwort: Höchstwahrscheinlich. Für die Kanonikalisierung benutzen wir rel-canonical, internes Linking und Sitemaps. Wenn Ihr uns also sagt, dass die schweizer Seite durch die deutsche kanonikalisiert werden soll, aber andererseits die schweizer Seite in eine Sitemap-File sendet, wäre das für uns eher verwirrend. Wir sehen das rel-canonical, aber wir sehen auch, dass Ihr auch die Schweizer Seite direkt einreicht. Sollen wir also beides indexieren? Sollen wir sie zusammenfalten? Je klarer ihr uns also mitteilt, was ihr von uns wollt, desto besser verstehen wir es.
Latenz bei JavaScript
Zeit: 49:39
Frage: Wir haben ein Projekt, das auf Magento aufbaut, aber wir haben dynamischen Inhalt in JavaScript, aber wir wissen, dass es Latenz gibt. Wie sollen wir damit umgehen? Wir arbeiten mit diesem Latenzproblem, aber gibt es eine Möglichkeit, das JavaScript vom Rendern zu trennen, das Google crawlt?
Antwort: Man sollte darüber nachdenken, was wirklich der kritsiche Inhalt auf diesen Seiten ist. Wenn der kritische Inhalt normales statische HTML ist und Ihr verwendet JavaScript um zusätzliche Verbesserungen hinzuzufügen, um vielleicht zusätzlichen Geschmack dazu zu geben und in einer Seitenleiste habt Ihr etwas, was unkritisch ist, aber nützlich für den Benutzer, dann ist es nicht wirklich wichtig, wenn es eine Zeitverschiebung zwischen dem Aufnehmen des Teils mit JavaScript und dem Rest der Seite gibt. So indexieren wir trotzdem die normale HTML Seite so schnell wie wir sie crawlen können. Wenn da etwas Kritisches drin ist, werden wir es gleich beheben. Wenn es im JavaScript etwas gibt, das zusätzlichen Inhalt generiert, kann es einige Tage dauern, bis wir es generieren und dies auch im Index sehen. Aber das JavaScript verlangsamt nicht die Indexierung der Rest der Seite.
[su_youtube url="https://www.youtube.com/watch?v=gC7aVygbMIk"]
Constanze Bettendorf und Jochen Moschko 