Hier findet Ihr das deutsche Transkript des Google Webmaster Hangout vom 21. September 2018:
Features in verschieden Sprachen
Zeit: 2:27
Frage: Was berücksichtigt Google bei der Implementierung von Inhaltsfeatures in verschiedenen Sprachen? Müsst Ihr die Anfrage verstehen oder müsst ihr die Sprache gut verstehen, müsst Ihr genügend Inhalte in dieser Sprache haben oder ist es die Mischung aus allem?
Antwort: Ich denke da kommt alles zusammen. Normalerweise versuchen wir einen Platz als Start zu finden. Das kommt manchmal darauf an, welche Art von Feature wir haben und welche spezielle Situation in einer speziellen Region, manchmal kommt es darauf an, wo das Team sich befindet. Oft beginnen es in den USA und dann ist es in Englisch verfügbar, weil das Team Englisch spricht und sie können es leicht testen und Schritt für Schritt experimentieren. Dafür müssen sie die Anfrage und den Inhalt richtig erkennen. Aus politischer Sicht gibt es bei der Einführung in andere Länder nichts problematisches, daher gibt es manchmal Merkmale, bei denen wir sagen, dass wir das auf Englisch ausprobieren können, aber vielleicht gibt es auf Französisch besondere Befindlichkeiten rund um das Thema, woran sie arbeiten, also sind wir ein bisschen langsamer in Europa bzw. ein bisschen langsamer in Frankreich, bevor wir es dort ausprobieren oder wir müssen einige Änderungen vornehmen. Oft gibt es auch spezielle Regionen, wo es etwas anders läuft. In Indien zum Beispiel: Die Inder haben eine sehr eigenes Web Ökosystem, sie interagieren mit dem Web auf eine einzigartige Weise, demnach macht es Sinn für sie spezielle Features zu haben.
Mobile First Indexing
Zeit: 12:24
Frage: Was passiert mit den Seiten, die noch zu 80-90% Traffic über Desktops erhalten, die noch die Desktop-Version benutzen?
Antwort: Wir versuchen es langsam anzugehen und keine Seiten zu zwingen, zu Mobile First Indexing zu wechseln. Aktuell schalten viele dahin um oder viele warten drauf, wir möchten das tun, wenn die Seiten auch dafür bereit sind und einige sind es noch nicht. Aber in einigen Jahren wollen wir alles umgestellt haben, damit es ein stabiler Zustand ist und alle in der gleichen Situation sind. Dies basiert nicht auf dem Traffic – sobald eine Seite dafür fertig ist, wird sie umgestellt. Das passiert dann Schritt für Schritt.
Site-Migration
Zeit: 14:34
Frage: Wenn man Seiten migriert und man die Domain gewechselt hat, ist es gut auch die URL zu verbessern, oder versteht Google es besser, wenn man nur die Domain wechselt anstatt die ganze URL?
Antwort: Ich würde versuchen, erst die Domain zu wechseln. Erst wenn alles niedergelassen ist, alles Weitere Schritt für Schritt danach. Wenn wir erkennen, dass es ein reiner Domainumzug ist, können wir alle Signale transferieren. Das geht weitaus schneller und man hat eine geringere Fluktuation. Und später, wenn Ihr größere Änderungen machen wollt auf dem Rest Eurer Website, passiert das innerhalb der Domain. Wenn es möglich ist, würde ich es also in Phasen machen.
Screenreader
Zeit: 17:30
Frage: Wir führen gerade ein massives Redesign-Projekt durch und konzentrieren uns auf Barrierefreiheit für behinderte Menschen. Daher beabsichtigen wir einige der Seitenüberschriften nur für die Screenreader zu behalten, da der visuelle Inhalt für die nicht behinderten Kunden selbstverständlich ist. Jetzt versuchen wir auch, Semantic Web-Best Practices wie korrekte Abschnitte, korrekte Überschriften, korrekte Artikel zu verwenden, so dass es HTML5 ist, und wir validieren es auch, wenn wir diese Überschriften verwenden. Was ist der beste Weg aus Eurer Perspektive diese Überschriften zu verbergen, damit wir nicht dafür bestraft werden, was eigentlich richtig ist? Weil wir diese Überschriften so zeigen wollen, dass die Screenreader sie tatsächlich für die nicht behinderten Kunden unserer Webseiten lesen können.
Antwort: Ihr müsst nichts Besonderes machen. Es gibt keine Strafe für solch versteckte Texte. Wir betrachten hier auch die Absicht, die dahintersteckt. Wir überprüfen diese Websites aus Sicht des Webspams manuell, um zu sehen, ob es eine Absicht gibt, Suchmaschinen zu täuschen. Und wenn es im Wesentlichen derselbe Text ist wie an anderer Stelle auf der Seite oder ein Bild beschreibt oder einen Abschnitt der Seite beschreibt, dann gibt es hier keine schlechte Absicht. Das ist also nichts, worüber sich jemand vom Web-Spam-Team beschweren würde. Von einem algorithmischen Standpunkt aus gesehen ist es auch vollkommen in Ordnung, wenn es im Grunde dasselbe ist, wie ihr es sonst auf diesen Seiten habt.
Client-Side-Rendering
Zeit: 24:47
Frage: Ich habe eine E-Commerce Seite aufgebaut, welche im Backend mit Ruby on Rails aufgebaut ist und im Frontend benutzen wir React ESC. Vor ca. Einem Jahr haben wir an einem Projekt gearbeitete, welches erfolgreich von Google gecrawlt worden ist. Das kann man in den Screenshots in der alten Search Console noch sehen. Bei einem neuen Projekt migrieren wir von einem Ruby on Rails mit HTML-Templates in das neue React-Framework und wir haben ernsthafte Probleme es zu indizieren, es zu crawlen und es von der Suchkonsole zu rendern. Wir liefern tatsächlich statische HTML-Dateien, die identisch mit der für den Benutzer sichtbaren tatsächlichen Seite sind, wenn ein Produkt aktualisiert oder eine Seite aktualisiert wird. Wir pre-rendern oder generieren nur eine neue statische Datei und stellen sie dem Googlebot oder dem open Graph zur Verfügung. Ist das eine gute Sache oder werden wir bestraft oder auf die schwarze Liste gesetzt?
Antwort: Wenn Ihr es auf Eurer Seite rendern könnt, speziell für Google vielleicht auch für andere Suchmaschinen und Social-Media-Sites, dann müsst Ihr Euch keine Sorgen machen, dass wir versuchen, diese Seite für Euch zu rendern. Ihr könnt das selber kontrollieren. Besonders bei großen E-Commerce Seiten sollte man daran denken, dass wenn wir die Seiten rendern müssen, dann ist es zeitlich immer etwas versetzt. Wenn Ihr zum Beispiel ein neues Produkt zu Eurer Seite hinzufügt, kann es vielleicht 1-2 Wochen dauern, bis wir die Seite dann tatsächlich rendern und die Seite zum Index hinzufügen können. Wenn Ihr ein statisches HTML bereitstellt, dann können wir das so aufnehmen und innerhalb von Minuten in den Index einfügen.
Single-Page-Applications
Zeit: 28:34
Frage: Gibt es Pläne für die Zukunft, um JavaScript-Single-Page-Applications schneller zu rendern?
Antwort: Wir haben Pläne das zu verbessern, aber es ist schwierig. Für einzelne Seiten ist das kein Problem, aber wenn man jeden Tag Millionen von Seiten hat, die man täglich rendern muss, wird es wahrscheinlich noch etwas dauern, bis wir es mit der gleichen Geschwindigkeit wie bei dem normalen Crawlen schaffen.
Abfall in den Rankings
Zeit: 30:00
Frage: Warum sind wir so stark im Ranking abgefallen? Wir haben wirklich alles gemacht, wir sind einen Schritt zurückgegangen, haben uns unseren Wettbewerb angeschaut, haben neue originelle Inhalte formuliert, wir verbessern unser Produkt jeden Tag. Wir hatten acht Jahre lang wirklich gute Rankings, sind Googles Best Practices gefolgt, haben alles gemacht, was Google von einer guten Seite abverlangt. Dieses Jahr hat uns ein großer Schlag getroffen und der organische Search Traffic ist komplett abgestürzt und das hat bereits unser Unternehmen stark getroffen. Wir finden das ein bisschen unfair und nicht gerechtfertigt und wir hoffen, dass wir vielleicht irgendeine Art von einer manuellen Überprüfung von Eurer Seite bekommen können. Wir sind im Ranking über 2/3 gefallen und machen uns wirklich große Sorgen, dass wir aus dem Geschäft fliegen. Ich hoffe Ihr könnt uns einen Rat geben, wie wir zu unseren Rankings zurückkommen, wo wir so lange waren.
Antwort: Wir haben uns die Seite bereits mit Ranking-Ingenieuren angeschaut und es gibt nichts Spezifisches was Ihr falsch macht und wo man sagen kann, Ihr müsst exakt dies oder jenes anders machen. Es hat eher etwas mit den Änderungen im generellen Ökosystem zu tun und in der Art wie wir Sachen ranken. Es ist im Wesentlichen eine Art Verschiebung, die über eine längere Zeitperiode eintritt. Aber ich werde mir das definitiv nochmal mit den Ingenieuren genauer anschauen um zu sehen, ob es etwas von unserer Seite gibt, auf das wir hinweisen könnten oder Euch eine Richtung geben können. Es ist immer sehr schwierig mit Nachrichten-Websites, weil die Art des Rankings sehr davon abhängt, wie die aktuelle Situation ist. Man kann nicht sagen, dass dieser Artikel immer die Nummer eins sein sollte, weil nächste Woche ein neuer Artikel über dieses Thema herauskommt und vielleicht ist das die Nummer eins und das macht es wirklich schwierig, diese Art von neuen Nachrichten-Websites zu analysieren. Aber es ist etwas, was wir untersuchen und es hat eine Menge Diskussionen auf unserer Seite ausgelöst, was wir tun können, um Verschiebungen in unserer Ranking-Seite für die Webseiten weniger problematisch zu machen. Änderungen im Ranking werden immer vorkommen, aber vielleicht gibt es Wege, dass es für im Wesentlichen legitime Webseiten, weniger schmerzhaft ist.
Außerdem ist zu erwähnen, dass die Google News-Rankings sich von den normalen Ranking-Rankings im Web unterscheiden. Daher gibt es manchmal auch normale Unterschiede, die auch dort auftreten.
Mobile First Indexing
Zeit: 44:00
Frage: Habe ich richtig angenommen, dass Google jetzt unsere Desktop-Seiten so rankt, wie gut Google unsere mobilen Seiten wahrnimmt?
Können wir jetzt Fluktuationen im Ranking sehen, wenn Google unsere mobile Version als weniger günstig empfindet als zuvor?
Sollten wir uns jetzt mehr auf die mobile Benutzerfreundlichkeit und den Inhalt über die der der Desktop-Version konzentrieren, da die Einstellungen jetzt synchronisiert werden?
Antwort: Ja, das ist korrekt, Google rankt Desktop Seiten nach dem Ranking der mobilen Seiten. Theoretisch kann man eine Fluktuation erkennen, aber ich habe auch schon Seiten gesehen, bei denen die mobile Version besser rankt. Das kann also auch passieren.
Ich glaube für die meisten Seiten wird der mobile Traffic größer sein, als der Desktop-Traffic, demnach macht es mehr Sinn sich auf die mobile Version zu fokussieren.
blockierte URLs
Zeit: 45:29
Frage: Wir haben in unserer Suchkonsole einige URLs, die indexiert sind, aber von der robots.txt blockiert werden, ist das Verschwendung von Crawl-Budget?
Antwort: Nein, wenn wir sie nicht craweln können, weil sie von der robots.txt blockiert sind, heißt es ja, dass wir sie nicht crawlen müssen.
Index
Zeit: 45:44
Frage: Ich habe bemerkt, dass Google plötzlich 25% unserer How-to Artikel von unserer DIY-Seite aus dem Index fallen ließ. Was ist hier passiert und warum?
Antwort: Ich weiß es nicht, wir versprechen nicht, alles zu indexieren. Vielleicht indexieren wir weniger. Es kann auch sein, dass es hier technische Probleme gibt. In der Search Console solltet Ihr Informationen dazu erhalten, warum wir URLs aus dem Index fallen lassen.
interne Suche
Zeit: 46:31
Frage: Verwendet der Googlebot die interne Suchfunktion einer Website zum Auffinden von Seiten und hilft die Qualität der internen Suche bei Rankings?
Antwort: In den meisten Fällen nutzen wir keine interne Suche, denn der Googlebot weiß nicht wirklich, wonach er suchen muss. Es gibt einige Websites, die wir überhaupt nicht crawlen können, außer durch die Nutzung der internen Suche. Das kann passieren, ist aber eher selten und man sollte idealerweise darauf abzielen, dass wir Eure Website normal crawlen können.
Lazy Loading
Zeit: 49:24
Frage: Ich habe "Lazy Loading" auf meiner Site implementiert. Wenn ich "Fetch as Google" verwende, werden die Bilder nicht in der Googlebot-Version geladen, aber sie werden für die Besucherversion geladen. Ist das ein Anlass zur Besorgnis? Ich sehe eine leere Box mit dem Ankertext, wo das Bild sein sollte.
Antwort: Vielleicht. Als erstes solltet Ihr überlegen, ob Ihr die Bilder überhaupt indexiert haben müsst. Braucht Ihr sie für die Bildersuche, da Ihr dort Traffic erwartet. Oft sind Bilder auf einer Seite eher Dekoration als alles andere. Und wenn sie mehr als Dekoration oder für Layout oder als Logo dienen, die nicht in der Bildersuche indexiert werden müssen, dann ist es vollkommen ok, wenn sie für Lazy Loading nicht geladen werden können. Wenn die Bilder in der Bildersuche gefunden werden sollen, müsst Ihr sicherstellen, dass wir sie überhaupt laden können. Wir veröffentlichen bald eine Dokumentation über Lazy Loading und wie man es am besten anwendet. Der generelle Ansatz, den ich immer mitgebe, ist ein „NoScript“-Tag mit einem normalen Bild-Tag zu benutzen. Ich weiß nicht, ob Ihr es dann sofort in „Fetch as Google“ sehen könnt, aber wir können es aufnehmen und es als Bild mit Lazy Loading erkennen und es laden, wenn wir es brauchen.
Fetch as Google
Zeit: 51:40
Frage: „Fetch as Google“ und die Search Console laden nicht die volle Länge einer meiner Seiten. Die Seite ist die längste Seite auf meiner Website. Das Laden der Seite stoppt ungefähr bei 3/4 oder weit drunter. Wenn ich den Google Cache überprüfe ist die ganze Seite darin zu finden. Gibt es ein Größen- oder Längen-Limit, wenn Google crawlt?
Antwort: Ja, es gibt ein Limit beim Crawlen durch Google. Aber es ist mehrere 100 MB HTML groß, was für die meisten Seiten genug sein sollte. Das "Fetch as Google"-Tool hat meistens ein engeres Limit, so dass wir euch eine Antwort ziemlich schnell zurückbringen können, so dass wir nicht auf den Download von allem warten müssen. Wenn Ihr den gesamten Inhalt im Cache seht, wenn Ihr auf der Seite in Google nach Teilen des Textes suchen könnt, die niedriger auf der Seite in Google stehen, dann solltet Ihr alles richtig eingestellt haben.
Webspam-Team
Zeit: 54:46
Frage: Wie berarbeitet das Webspam-Team eine manuelle Aktion? Gibt es Spezialisten oder sind es „normale Leute“? Das Problem ist, dass ich einige DMCA-Anfragen gesendet habe und sie haben die Bilder auf den Seiten der anderen Websites nicht gesehen und sie haben mir immer zurückgegeben, dass dort kein Bild ist und daher denke ich nicht, dass dort Spezialisten sitzen.
Antwort: Für die DMCA-Beschwerde wird das in der Regel von einem anderen Team bearbeitet, also nicht vom Webspam-Team, sondern von Leuten, die diese rechtlichen Anfragen prüfen und das sind Leute, die sich mit rechtlichen Anfragen im Wesentlichen die ganze Zeit beschäftigen ein ziemlich gutes Verständnis des Internets und der Art von Anfragen haben, die eingehen.
Webspam-Team
Zeit: 56:24
Frage: Wieviel Zeit hat das Webspam-Team, um Anfragen zu bearbeiten? Haben sie genug Zeit oder haben sie nur 2 Minuten um eine Anfrage zu beantworten?
Antwort: Soweit ich weiß, haben sie genug Zeit, diese zu überprüfen. Wir bekommen eine Menge Anfragen, insbesondere DMCA-Beschwerden. Wir benutzen Werkzeuge, um herauszufinden, was wir automatisch lösen können und dann überprüfen wir manuell die Dinge, die sonst noch hereinkommen. Aber wie bei jeder manuellen Überprüfung kann es sein, dass eine Person sie betrachtet und das große Problem nicht bemerkt, jemand anderes würde es aber bemerken, also macht es manchmal Sinn es erneut zu versuchen oder in der Beschreibung der eingereichten Anfrage ausführlicher zu sein.
Wenn Ihr regelmäßig Dinge seht, bei denen es offensichtlich ist, dass ihr das Original seid und das andere die Kopie und ihr könnt das nicht verarbeiten, dann könnt Ihr das auch an mich senden und ich kann das an das Team weitergeben, damit sie dort detaillierter reinschauen. Ich weiß nicht, wie die DMCA-Beschwerden beurteilt werden. Wir versuchen das auf rechtlicher Grundlage und das könnte ein bisschen anders sein als die Art und Weise, wie ein Webspam-Team auf eine Website schaut und sag: gut das ist ähnlich oder nicht.
Header auf mobilen Seiten
Zeit: 63:13
Frage: Im Header der mobilen Seite nutzen wir eine Umleitung mithilfe des User-Agents. Im Browser benutzen wir keine Umleitung. Wenn man also versucht über Chrome oder Firefox auf die mobile Website zuzugreifen, wird sie nicht angezeigt. Ist das ok?
Antwort: Es sollte gleichgehalten werden, also sollte es auf der Art des Geräts basieren, wenn Ihr so etwas macht. Ich denke, das ist im Allgemeinen eine gute Übung, wenn Ihr erkennt, dass der mobile Benutzer auf die Desktop-Seite wechselt, um sie auf die mobile Seite umzuleiten. Es ist eine Art wie „Responsive Design“ auch funktionieren kann. Das sollte auch in unseren Richtlinien für mobile-friendly Websites stehen.
[su_youtube url="https://www.youtube.com/watch?v=NYAup40MeTM"]
Constanze Bettendorf und Jochen Moschko 