Hier findet Ihr das deutsche Transkript des Google Webmaster Hangout vom 30. Oktober 2018:
JavaScript
Zeit: 2:49
Frage: Wir redesignen unsere Seite, kann man client-side Rendering anwenden? Was ist das beste für SEO?
Antwort: Ansich ist client-side Rendering kein Problem, das Einzige was zu beachten ist, ist dass wenn Ihr schnell wechselnde Inhalte habt oder Eure Seite sehr groß ist oder beides, kann es zu Verzögerungen beim Indexen und Updaten kommen. Ein bisschen ist ok – wenn es mehr ist, dann solltet Ihr über das dynamische Rendering nachdenken, dazu haben wir seit drei Wochen eine Dokumentation verfügbar. Ihr solltet auch nicht vergessen, dass Client-Side-Rendering zu Problemen mit der Benutzererfahrung führen kann und mit Kosten für den Nutzer verbunden ist, besonders bei mobilen Nutzern. Was SEO angeht passt das alles, aber Ihr solltet auf jeden Fall gründlich testen, wie es auf der Benutzerseite aussieht. Es kommt drauf an was der Grund dafür ist, warum Ihr das macht. Wenn Ihr genug Infrastruktur habt und Ihr wollt das an der Stelle versuchen, dann ist das ein guter Grund, aber dann müsst Ihr auch hybrides oder Server-Side-Rendering beachten, weil Ihr dieselbe Technologie verwenden könnt, jedoch nicht vollständig auf der Client-Side gerendert, was Euch in eine angenehme Position bringt, weil Crawler, die kein JavaScript unterstützen, dies verwenden können und Benutzer den Inhalt schneller erhalten, was man ja im allgemeinen immer möchte, mehr Inhalt schneller zum Nutzer. JavaScript kann da im Weg stehen und das macht es zu einer Herausforderung, aber für Google sollte das kein Problem sein, bei anderen Crawlern eventuell schon. Bing zum Beispiel führt kein JavaScript aus, Facebook und Twitter ebenfalls nicht. Wenn Ihr Euch also auf das Open Graph-Markup oder diese netten kleinen Karten verlasst, die erscheinen, wenn Ihr einen Link bei Twitter postet, muss der Inhalt serverseitig oder dynamisch gerendert werden.
Dynamisches Rendering
Zeit: 07:14
Frage: Wir haben eine E-Commerce Seite und die Produkte wechseln schnell und sind lazy loaded mit JavaScript-Scroll-Events.
Antwort: Wir arbeiten an besserer Beratung für Lazy Loading. Wir haben die Dokumente noch nicht fertig, aber wollen sie so bald wie möglich veröffentlichen.
Im Allgemeinen solltet Ihr sehr vorsichtig sein und testen, aber wenn Euer Inhalt im Viewport sichtbar ist, sollte alles gut sein. Scroll Events alleine sind nie eine gute Strategie. Erstens: Es ist sehr teuer. Zweitens: Wenn Nutzer ihre Fenstergröße verändern, verpasst Ihr diese Momente, wenn Ihr Euch nur auf Scroll Events verlasst. Drittens: Wir unterstützen es nicht, wir scrollen nicht, wir machen etwas anderes, aber im Grunde weiß der Browser, dass Dinge sichtbar werden, und wenn sie sichtbar sind, solltet Ihr den Inhalt laden, den Ihr hinter dem Lazy Loading versteckt habt. Es gibt einige Wege das zu tun. Einer ist es, sicher zu stellen, dass Eure Bibliothek gut mit Fetch and Render funktioniert, eine andere Möglichkeit ist etwas wie einen Intersection Observer zu benutzen. Ein Intersection Observer ist dafür gemacht, mit dieser Art Szenario umzugehen. Oder Ihr könnt Links in NoScript-Tags zu Euren Inhalt erstellen.
Wenn sich Inhalt schnell verändert würde ich sagen, dass das dynamische Rendering aktuell der bessere Weg ist.
JavaScript
Zeit: 10:51
Frage: In unserem Fall kann es für uns Webmaster nützlich sein, über eine bestimmte Art von Director zu verfügen, wie etwa einen Zusatz zur Robots.txt-Datei oder die Möglichkeit, Daten in Meta-Tags oder einer Sitemap zu platzieren, in der Google ausdrücklich darauf hingewiesen wird, JavaScript nicht auf einer bestimmten Seite oder einem bestimmten Abschnitt einer Seite zu rendern, weil es nicht in das Ranking und den Inhalt einer Seite involviert ist, haben wir kein Interesse daran, dass Ihr unbedingt alles crawlt.
Antwort: Es gibt bereits eine Reihe von Heuristiken. Das Rendern im Allgemeinen ist ein interessanter Prozess, ich habe heute buchstäblich ein Diagramm gesehen, das ich noch bearbeite. Ich weiß nicht, ob da etwas passiert oder ob wir uns damit beschäftigen werden, wegen der Richtung in die sich das Netz aktuell bewegt. Es ist auch nicht notwendig, über JavaScript zu verfügen, durch welches das Rendern von JavaScript definitiv viel zu den Kosten beiträgt, aber nicht unbedingt alle Kosten trägt. Und wenn Eure Sachen gut bei den Nutzern funktionieren, wird es auch gut für das Rendern funktionieren. Das größere Problem kommt von dem großen Abstand zu dem was moderne Browser tun und was Googlebot macht, wir arbeiteten daran diesen Spalt nachhaltig zu schließen. Wir brauchen länger, um sicherzustellen, dass wir längerfristig auf dem neuesten Stand sind. Dies wird uns eine Reihe von Verbesserungen in Bezug auf Leistung und Rendering-Kosten bringen. Ihr müsst Euch darum also keine Sorgen machen, das ist unser Job und wir geben unser Bestes.
Dropdown-Menü für Links
Zeit: 21:05
Frage: Wenn wir eine Reihe von HTML-Links mit einem Selektor in ein Dropdown-Menü konvertieren und diesen Zustand so belassen, anstatt alle 50 auf dieser Seite aufzulisten, würde das kontraproduktiv für unsere SEO-Maßnahmen sein? Könnt Ihr diese Links weiterhin als normale Links zu den tieferen Seiten der Website analysieren? Würde es dem Ranking schaden?
Antwort: Wenn es ein Link sein soll und es keiner mehr ist, ist das nicht gut.
Es gibt einen Hack, den man machen kann. Im JavaScript habt Ihr die ganze URL und wenn wir den JavaScript-Code betrachten und eine ganze URLs erkennen, wissen wir, dass es wahrscheinlich eine URL ist, die verlinkt sein soll und wir würden versuchen, dieser zu folgen. Es ist nicht dasselbe wie ein normaler HTML-Link, weil wir ihn nicht wirklich crawlen können, aber wir können diese URLs entdecken und aufnehmen.
Cleanup
Zeit: 28:26
Frage: Es geht darum, mehrere Seiten mit Informationen unter Verwendung von Paginierung zu einem bestimmten Thema zu haben. Ein Teil der Bereinigungs- und Konsolidierungsanstrengungen wäre der Wunsch, alles über die erste Seite hinaus zu beseitigen. Wenn ein Benutzer also auf Seite zwei, drei, vier usw. landet, würde er im Wesentlichen auf Seite eins zurückgeleitet, da davon ausgegangen wurde, dass die erste Seite die Qualität und den relevantesten Inhalt zu diesem Thema enthält. Daher stellt sich die Frage, ob es besser wäre, eine 301-Weiterleitung von Seite zwei auf die erste Seite durchzuführen, oder ob es besser wäre, eine 410-Weiterleitung (eine Art Signal) durchzuführen um Googlebot mitzuteilen, dass alles, was über die erste Seite hinausgeht, nicht mehr dort bedient wird?
Antwort: Wenn Ihr alles von Seite 2 und folgend nicht mehr indexiert haben wollt, dann würde ich eher zu der 301-Weiterleitung tendieren, um wirklich alles in der Version zu konsolidieren, die Ihr tatsächlich indexiert haben möchtet. Ihr könnet auch eine 404 oder 410 verwenden, aber wir würden dann alle Signale fallen lassen und Ihr würdet sie komplett verlieren. Ich denke, die Schwierigkeit besteht darin, wenn Ihr die verschiedenen Seiten weiterhin indexiert und auf der Seite verfügbar haben wollt, dann bedeutet das, wenn Ihr das ändert, dass Ihr für diese neuen URLs separate URLs verwenden müsst, damit wir die anderen umleiten können. Dann ist die Situation erneut so, dass Ihr separate URLs für Seite zwei und Seite drei habt, und wir würden versuchen, diese auch separat zu crawlen und zu indexieren, sodass das gleiche Problem erneut auftritt.
Canonical
Frage: Wie wäre es Seite 2, 3 und 4 zu kanonisieren?
Antwort: Das kann man auch machen. Wir folgen jedoch dem Canonical nicht immer blind, wir wissen nicht, ob es wirklich die gleiche Seite ist oder ist es etwas was wir zusammenfalten sollten. Mehr Signale dazu würden uns sehr helfen. Dinge, wie interne Links, wenn sie auf Seite 1 in dieser Liste verweisen, Sitemaps, wenn man nur Seite 1 in der Sitemap-Datei hat, all dies hilft uns zu verstehen, ob dies wirklich die URL ist, aber es kann immer noch passieren, dass wir Seite 2 und 3 finden und diese crawlen und indexieren.
Der Inhalt der Seiten spielt auch oft eine Rolle, wenn es separater Inhalt ist, der sonst nirgends auf der Website zu finden ist, dann sollte man wirklich klarstellen, dass dieser auch indexierbar und crawlbar ist.
Signale einer URL
Zeit: 32:21
Frage: Wie lange behaltet Ihr die aktuellen Signale für eine URL, die weitergeleitet wurde? Ich bemerkte, dass Google nach einem Jahr Signale auf eine Seite gerichtet hat, die nicht wirklich mit der alten 303-Weiterleitung in Verbindung stand, aber sie wurde immer noch für ein bestimmtes Thema der alten Seite angezeigt. Ein gutes Beispiel wäre die Umleitung einer alten Firma, ein alter Name auf einen Neuen. Ich habe gesehen, dass Websites für den Namen des alten Unternehmens auftauchen, und zwar ein Jahr später nach der Umleitung. Wie lange behaltet Ihr das? Und was ist dann Eure Empfehlung das aufzuräumen?
Antwort: Die Frage für uns ist, indexieren wir das separat oder denken wir, dass das nur eine alternative URL für einen Teil des Inhaltes ist. Falls wir es separat indexieren, haben wir eine Weiterleitung übersehen oder wir verarbeiten sie nicht richtig, dann ist es eher ein technisches Problem. Was jedoch meistens der Fall ist, wenn Ihr eine Domain wechselt, dass wir die alte weiterhin zeigen, da diese einst sehr relevant war. Wir wollen Euch damit sozusagen einen Gefallen tun. Das ist sehr üblich. Ihr könnt eine Site-Abfrage für Eure alte Domain durchführen, der Inhalt wird jedoch noch Jahre später angezeigt. Es ist nicht so, dass wir diese URL noch indexieren, wir zeigen sie nur an, wenn Leute diese Suchanfrage haben.
URL übersetzen
Zeit: 37:03
Frage: Wir haben eine US-basierte Seite, die auch sechs weitere Sprachen bedient, wir haben mit Hreflang gearbeitet. Sollten wir auch die URLs übersetzen, anstatt nur den Inhalt?
Antwort: Aus unserer Sicht geht beides, ich sehe keinen Grund warum man die URL nicht übersetzen sollte, weil sonst sieht es für den Suchenden ja komisch aus, wenn die URL in einer anderen Sprache ist. Wir versuchen also die URLs zu lokalisieren, falls dies möglich ist, aber ich sehe nicht, dass das aus SEO-Sicht Dinge kaputt machen würde.
Verschmelzen von Seiten
Zeit: 45:13
Frage: Aus der Perspektive einer nicht vorhandenen Autoritätsmetrik für eine bestimmte Website beispielsweise hat man ein Ranking auf Position fünf und ein weiteres Ranking auf Position sechs. Wenn man sie zusammenführt und sie einige Signale ausgeben, die zu einem einzigen Inhalt des gleichen Themas verschmelzen, würde dies die Rangliste verbessern?
Antwort: Wahrscheinlich ja. Das sieht man, wenn man 2-4 schwächere Seiten hat und diese zu einer zusammenschmelzen, sogar innerhalb derselben Seite. Dann können wir nicht sagen, dass diese Seite stärker ist. Wir können sehen, dass sich mehr Teile der Site auf diesen einen einzigen Inhalt beziehen, also ist er wahrscheinlich relevanter ist als die einzelnen kleinen Teile, die Ihr zuvor hattet.
Archiv für alte Inhalte
Zeit: 48:09
Frage: Zum Thema Erstellen einer einzigen autoritativen Seite im Vergleich zu mehreren iterativen Seiten: Was ist mit abgelaufenen Produktinhalten, die möglicherweise noch relevant sein könnten, wie z. B. Beim Auto die Jahresmodelle, Jahr 2018, 2017,2016 vom Toyota Corolla beispielsweise. Ist es von Vorteil, all diese Seiten in einer Art Archivbereich zu haben oder vielleicht eine wirklich autorisierende Toyota Corolla-Seite, die möglicherweise den gesamten Archivinhalt darin enthält, vielleicht in gefalteten Akkordeons unten, während der obere Hauptkörper den Inhalt des aktuellen Modeljahres enthält.
Antwort: Eine gute Frage! Ich glaube nicht, dass es eine einheitliche Antwort dafür gibt. Ich würde das erstmal aus nutzerfreundlicher Sicht testen, um zu schauen, was für den Nutzer gut funktioniert. Ich kann mir gut vorstellen, eine Seite zu haben, die die älteren Versionen listet oder auch den älteren Inhalt in eine Archiv-Sektion zu verschieben, um ihn ein wenig abzuschwächen. Eine Idee könnte auch sein, dass man eine Mischung aus Beiden macht, indem man eine aktuelle Version hat und auf der Archivseite listet man alle Archivversionen auf. Aber es kommt immer drauf an, wie Nutzer sich mit dem Inhalt beschäftigen und wie sie danach suchen.
Daten aus der Search Console
Zeit: 55:55
Frage: Mir ist aufgefallen, dass der externe Backlink-Bereich in den letzten Monaten viel besser zu sein scheint. Glückwunsch dazu. Werden wir jemals eine API für diese Daten bekommen?
Antwort: Ich weiß es nicht, es gibt bislang keine Ankündigung dazu. Wir haben bereits darüber gesprochen, die API der Search Console im Allgemeinen zu erweitern. Vielleicht könnten wir das wirklich hinzufügen.
Daten aus der Search Console
Zeit: 57:14
Frage: Seit dem Update vom 19. August, werden die Diagramme geändert, wenn man den Filter im Leistungsbericht in der Search Console filtert. Es reduziert erheblich den Datenverkehr in der Grafik, wenn man anfängt die Keywords einzugeben. Ist das ein Bug? Wird das wieder zurückgeändert?
Antwort: Das wird sich wahrscheinlich nicht mehr ändern. Der Hintergrund dazu ist, dass wir Anfragen filtern bevor sie die Search Console oder Search Analytics erreichen. In der Vergangenheit haben wir die Anfragen in die Diagramme mit einbezogen, bei denen die Daten im Wesentlichen auf eine positive Art verzerrt waren. Jetzt entfernen wir all diese gefilterten Anfragen, welche sie negativ beeinflussen, denn wir wissen nicht, ob die Leute auch danach suchen. In der Vergangenheit sind wir einfach davon ausgegangen, dass es so ist. Wir werden dies nicht ändern, denn dies ist auch darauf zurückzuführen, wie wir diese Daten intern in der Search Console speichern.
Hreflang und Canonical Markup
Zeit: 59:46
Frage: Ich habe Euch beim letzten Gespräch bereits nach dynamische Einfügen von Hreflang- und Canonical-Markups unter dem Gebrauch von JavaScript gefragt. Ich habe es im Allgemeinen so gemacht und es scheint ok zu sein. Die Search Console sagt mir jedoch noch, dass ich kein Hreflang- und Canonical-Markup auf meiner Seite hätte. Kann ich das beheben, wenn ich JavaScript weiterhin implementieren werde?
Antwort: Wenn es richtig implementiert ist und wir es aufnehmen können, wird es in der Search Console angezeigt. Ich weiß, dass wir in letzter Zeit Probleme mit der Datenlatenz hatten. Wenn Ihr diese Änderungen in den letzten Wochen gemacht habt, ist es vielleicht noch nicht aktualisiert worden. Aus Rendering-Sicht müssen wir zuerst die indexierte Version rendern und erneut verarbeiten, und dann muss die Search Console das aufnehmen und alles durch ihre Pipelines verarbeiten, was auch ein paar Tage dauert.
[su_youtube url="https://www.youtube.com/watch?v=wI5O-lYLBCw"]
Constanze Bettendorf und Jochen Moschko 