 OK, herzlich willkommen beim heutigen Google Webmaster Central Sprechstunden-Hangout. Mein Name ist Johannes Müller. Ich bin Webmaster Trends Analyst hier bei Google in der Schweiz. Und Teil von dem, was wir machen, sind natürlich solche Webmaster Hangouts, wo Webmasters zu uns kommen können und Fragen direkt stellen können. Wie immer, wenn einer von euch loslegen möchte mit den ersten Fragen, könnt ihr gerne jetzt anfangen. Nicht. Ja, hallo, dann würde ich mal anfangen. OK, sehr close. Servus. Und zwar geht darum, ich habe die Frage, wenn wir mehr sprachige Webseiten haben und quasi verschiedene Teaserbilder für dann Details, Details, Seiten, die ein spezifisches Thema behandelt haben, die aber auf allen Sprachen quasi wird dasselbe Bild verwendet. Sollen wir das dasselbe Bild dann quasi immer der Hauptsprache benennen, zum Beispiel Deutsch oder Englisch. Und auf jeder detailierten Ländersprache einbinden oder macht das sindes Bild dann zu kopieren und quasi einmal auf Deutsch zu benennen, einmal auf Englisch zu benennen, einmal auf Spanisch, Französisch, Italienisch. Der Dateinamen bei Bildern hilft uns ein bisschen zu verstehen, worum es geht bei dem Bild. Aber normalerweise holen wir genug Informationen auch aus dem Kontext von den Seiten heraus. Das heißt, wenn das gleiche Bild auf mehreren sprachlichen Versionen verwendet wird, ist das auch total okay. Ich denke, gerade bei Teaserbilder ist natürlich auch immer die Frage, was will man erreichen mit einem Ranking in der Bildersuche. Sind das wirklich Bilder, wonach gesucht wird oder wo die Besucher helfen, eure Inhalte zu finden oder was ist quasi das Ziel von diesen Bildern in der Bildersuche. Das heißt, ich würde nicht einfach blind sagen, das sind Bilder auf meinen Seiten, deshalb muss ich alles machen, was da für Bilder es hier auch gemacht werden muss, was hier gemacht werden kann, sondern wirklich gezielt darüber legen, was will ich erreichen. Macht das Sinn, dass diese Bilder in der Bildersuche erscheinen, kommen Besucher zu meinen Seiten und dann gezielt irgendwie das zu machen, was man halt bei mir machen kann oder wollen die eigentlich nur die Bilder finden und weiter verwenden. Und wenn die Bilder eher dafür da sind, dass das andere, die weiter verwenden, können dann bringen, die Besucher ja nicht wahnsinnig viel für euch. Das stimmt, okay, ich dachte nur vielleicht von der inhaltlichen Relevanz auf der Seite, ob das da wirklich relevant wäre, dass dann die gesamte Seite in derselben Sprache ist und demnach halt auch diese Bildarteien eben, weil es, wie Sie gerade gesagt haben, ja stellenweise dann wirklich für ein inhaltlich unrelevantes Bild auch zutrifft, dass einfach nur quasi den grafischen Effekt hat oder den optischen Effekt und ob das da einfach relevant wäre. Aber okay, das heißt, wenn man wirklich mehr Wert in den Bildern selbst hat, da macht das natürlich Sinn. Und falls nicht, dann ist es halt optional. Ja, also ich würde jetzt nicht gezielt die Bilder optimieren für die Websuche. Das heißt, innerhalb der Websuche, wenn man nach Text sucht, dann kommen erst einen Moment eigentlich nur die textlichen Inhalte in Frage für uns. Und die Bilder helfen uns ein bisschen zu verstehen, wie wir diese Seite platzieren können. Aber die sind ja nicht der Hauptelement. Und für die Bildersuche ist es natürlich eine andere Frage. Wenn man gezielt will, dass Informationen auf der Website über die Bildersuche auffindbar sind. Wenn man, sag ich mal, Produkte hat, die sehr optisch relevant sind, wo Besucher dann eher nach den optischen Eigenschaften auch suchen, die dann über die Bildersuche kommen können, dann macht das sicher auch Sinn, dass man das entsprechend aufmacht. Okay, perfekt. Vielen Dank. Super. Kann ich dazu eine Frage stellen, John? Ja. Wird denn Ranking weitergegeben, wenn man gut ist in der Bildersuche? Wie meinst du? Also wird, wenn man jetzt oft oben erscheint, also wir haben sehr viele Flaggenfotos und die erscheinen halt alle oben, ja, diese Forschung von Google. Und wenn man oben erscheint, dann landet man praktisch in einem Produkt und wird da Ranking weitergegeben auf das Produkt. Also irgendwie eine gewisse Kraft. Nein, das sind eigentlich ganz, ganz unabhängige Elemente. Das heißt, dass das Ranking in der Bildersuche und das Ranking in der Websuche die sind nicht voneinander abhängig. Also diese Links, die bringen nichts ein. Also wenn jetzt einer drückt, dann sieht das... Ja, okay. Eigentlich bringen nichts. Man kommt natürlich so auf eure Seite, dass man das macht, macht ja vielleicht auch sehen. Aber es ist nicht so, dass man quasi, wenn man gut ist in der Bildersuche, dann besser dasteht in der Websuche. Okay, danke. Ja, dann würde ich direkt mal die nächste Frage nehmen. Und zwar, es geht es darum, wenn ich quasi den Page-Titletake-Meter-Description-Meter abstract und by structured data auch nochmal headline und description überliefer. Wie hoch ist die Wahrscheinlichkeit in der organischen Suche, dass Google sich trotzdem in Random-Piece-Element für Description und Headline raussucht? Das geht nämlich darum, für ärzte Webseiten ist es in manchen Ländern nicht erlaubt, Molecularname oder Brandname in Headline oder Description zu überliefern. Das heißt, da könnte ich ja theoretisch hingehen und mit den zuvor genannten Texts die Inhalte zu überliefern. Jedoch muss ich dann halt verhindern oder wie verhindere ich, dass sich Google quasi trotzdem in Random-Piece-Element raussucht und das dann als Meta-Description oder Headline-Anzeigenlist. Das lässt sich nicht ganz verhindern. Das heißt, es gibt da nicht irgendwie eine Wahrscheinlichkeit, dass wenn man das so macht oder so macht, sondern wir versuchen, das auch wirklich gezielt der Suche anzupassen. Das heißt, es ist nicht so, dass wir quasi einfach pro Seite ein Titel und ein Description haben, sondern das kann verändern, je nachdem, was der Besucher halt sucht. Und so einen prozentualen Anteil kannst du jetzt quasi nicht nennen. Das, wenn ich jetzt sage, ich habe das jetzt alles gesetzt und so und so vier Prozent wird Google quasi meine gesetzten Titeltext oder Meta-Description ausspielen. Nein, es gibt es eigentlich nicht, dass wir da irgendwie prozent zahlen. Weil in dem Sinne arbeiten wir nicht so, dass wir da eine Wahrscheinlichkeitsrechnung haben. Und wenn die Zahl dann so ist, dann zeigen wir unseren eigenen Titel an, sondern wir versuchen, das anzupassen, auf das, wo nach die Besucher wirklich auch suchen. Damit die Besucher eher wissen, was ist jetzt relevant auf dieser Seite bezüglich der Suche, die ich jetzt gerade gegeben habe. Ja, und was ist, wenn ich quasi nur den Headbereich indexierbar mache oder Crawler mache für den Google-Bord und quasi den Body-Bereich nicht? Das heißt, dann könnte ich ja quasi per JSON-LD oder per Meta-Tech Headline und Description vorgeben im Headbereich und der Body-Bereich ist quasi nur für den User sichtbar, nachdem er sich dann eingeloggt hat oder einen Disclaimer akzeptiert hat. Gibt das Negatives oder wird das dann überhaupt noch indexiert, wenn ich den Body-Bereich nicht indexierbar mache? Ich vermute, wenn der Body-Bereich gar nicht dabei ist, dann würden wir die Seite als eine leere Seite einstufen und die dann auch nicht indexieren. Ich denke, was man vielleicht ausprobieren könnte, ist, dass man einfach einen Art Playsolder oder eine Standardtexte im Body-Bereich drin hat, damit wenigstens eine Seite irgendwie gecrawled und indexiert werden kann. Aber ich denke ganz verhindern kann man das nicht, dass da andere Titel auch verwendet werden, weil wir nehmen jetzt im Teil auch Links von anderen Websites dazu. Man wird sehen, dass jetzt bestimmte Wörter sehr relevant sind für diese Seite und die auch nicht auf diese Seite selber sehen kann es sein, dass wir dann das auch wirklich von anderen Seiten dazu nehmen. Das ist besonders dann, wenn zum Beispiel eine Seite per Robots Text blockiert ist, dann müssen wir ja die Anchors von anderen Seiten nehmen, wenn wir diese URL in den Suchergebnissen zeigen wollen. Okay, thanks. Ich denke, das ist wahrscheinlich nicht ganz eine einfache Situation für euch, aber ich würde mal in verschiedenen Varianten ausprobieren, Garantien, dass wir das so oder so machen, können wir da eigentlich nicht wählen. Ja, okay. Okay, dann schauen wir mal die Fragen an, die eingeweicht worden sind. Eine Frage zu M. Manche Websites haben den M-Content in einem Subdomain von mproject.com. Wie kommt das und wie kann man das kriegen? Das ist an für sich der CDN von mproject oder von der Google Suche, die automatisch erstellt wird, wenn wir Seiten von einem Website gecached haben für AMP. An für sich muss man da nichts Spezielles machen, sondern man muss valide AMP-Zeiten haben, die dann in unserem System, das heißt bei uns in der Google Suche, gezeigt werden, dann nehmen wir die in den Cache dazu und verwenden die Gespräche so. Das heißt, es ist nicht gezielt etwas, was man manuell machen muss, sondern das passiert automatisch. Ich glaube, es gibt auch andere AMP-Caches, die ähnlich funktionieren. An für sich ist das nur eine Cached-Version, es ist ja dann nicht die effektive AMP-Seite, die bei euch gehostet wird. Okay, danke sehr. Eine Frage zu duplicate content, das heißt, der gleiche Inhalt auf zwei unterschiedlichen Plattformen. Die Frage ist relativ lang, aber ich glaube, das geht daraufhin, dass man die gleichen Inhalte verwendet, das heißt ein Artikel und in zwei unterschiedlichen Orten das platziert für unterschiedliche Nutzer effektiv mit unterschiedlichen Kriterien, wie man dahin kommt. Und ein bisschen die Frage, was muss man da machen, ob man damit Canonical arbeiten soll oder nicht. An und für sich sehe ich da kein Problem, wenn man das so macht, wenn man da die Seiten an zwei verschiedenen Orten hostet, besonders dann, wenn man wirklich auch unterschiedliche Kundengruppen ansprechen möchte. Das ist ja oft auch der Fall mit Produkten, dass man vielleicht eine Website hat für Endverbraucher und eine Website hat eher für Wiederverkäufer zum Beispiel und das ist eigentlich die gleichen Produkte dabei. Vielleicht sind die Preise dann irgendwie nicht sichtbar oder ein bisschen anders, aber anfühle sich sind die gleichen Produkte da. Grundsätzlich ist aus unserer Sicht total okay. Aus eurer Sicht ist es einfach so, dass die beiden Artikel natürlich miteinander konkurrenzieren. Das heißt, wenn jemand gezielt nach irgendeinem Text sucht, der in einem dieser Artikel ist, dann kann es sein, dass beide dieser Varianten in den Suchergebnissen erscheinen. Und dann hat man natürlich ein bisschen so die Konkurrenzsituation, dass man nicht weiß, welches von beiden jetzt an erster Stelle steht. Und natürlich man hat auch ein bisschen die extra Schwierigkeit, wenn andere Konkurrenten in diesem Bereich auch tätig sind, dann hat man natürlich den Wert von diesem Inhalt aufgeteilt auf zwei Einzelzeiten. Das heißt, ein bisschen verdünnt im Vergleich zu der Situation, wenn man das jetzt alles nur auf einer Seite hätte. Aber das ist etwas, das könnte ich abwägen und sagen, aus unserer Sicht ist es wichtiger, dass wir die Inhalte für zwei unterschiedliche Kundengruppen erreichbar haben. Dann macht ihr das so, wenn ihr wirklich sicher sein wollt, dass diese Inhalte so gut wie möglich in den Suchergebnissen erscheinen. Besonders wenn das ein stark umkämpfter Umgebung ist, dann würde ich mir vielleicht eher überlegen, per Canonical ein von diesen Varianten auszusuchen. Es muss nicht immer die gleiche Variante sein. Das heißt, ihr könnt pro Artikel auswählen, ob wir jetzt diese Plattform aus Canonical haben oder die andere. Das ist euch einem für sich überlassen. Wie steht Google zu einem solchen Fall? Ein Hersteller, eine Bohrmaschine, bietet auf seine Website einen Bohrmaschinenvergleich an. Und seine eigenen Produkte kommen natürlich bei diesem Vergleich immer als Beste heraus. Was sagt Google dazu? Kann man das irgendwie melden? Ist das problematisch? Aus unserer Sicht ist das nicht unbedingt etwas, wo wir direkt involviert werden. Das heißt, wir wären an für sich nicht in der Lage oder ist nicht unbedingt unser Ziel, dass wir die Echtheit von Produkttests überprüfen, dass wir da genauer anschauen, was wirklich geschrieben wird, ob das stimmt oder nicht stimmt, oder ob da irgendwelche Hintergedanken dabei sind. Das heißt, aus unserer Sicht nehmen wir die Inhalte, die auf dem Web erscheinen so wie sie sind. Wenn es problematisch ist, dann würde ich empfehlen, dass man das direkt mit dieser Website anschaut. Oder wenn das wirklich sehr problematisch ist, gibt es vielleicht irgendwie auch eine rechtliche Situation, die da zustande kommen kann. Aber das ist nicht unbedingt unsere Aufgabe. Unsere Aufgabe ist, die Inhalte zu indexieren, die so auf dem öffentlichen Web halt sind. Und von dem her ist es nicht unbedingt etwas, was man uns melden muss, sondern das ist eigentlich einfach das, was auf dem Web ist. Wie stehst du zu Single-Page-Applications, ähnlich und ähnlichem auf SEO gezogen, das heißt, die Problematik, dass es keine keyword-spezifischen Landing-Pages gibt. Ich glaube, das sind zwei unterschiedliche Themen haben natürlich. Single-Page-Applications sind Seiten, die an und für sich JavaScript-Applikationen, die unter einer URL laufen, aber die verschiedene Inhalte halt haben und mit denen man an und für sich auch verschiedene URLs generieren kann. Das heißt, theoretisch gesehen kann man eine URL aus einem Single-Page-Application nehmen, die in ein Browser kopieren. Und da sieht man die gleichen Inhalte. Das heißt, es ist eigentlich eher wie eine Website, oder ein Web-App, wenn man so will. Und das andere bezüglich keyword-spezifischen Landing-Pages klingt eher so, als ob man eine lange HTML-Seite hat, wo einfach verschiedene Bereiche da vorhanden sind, die zu einzelnen Keywords an und für sich relevant sein können. Und das sind an und für sich ganz unterschiedliche Sachen, aber beide sind aus unserer Sicht durchaus denkbar. Mit Single-Page-Applications, wenn man jetzt mit JavaScript-Frameworks arbeitet, kann man durchaus Websites machen, die gut in der Google-Zuche funktionieren. Wichtig ist einfach, dass man wirklich auch sich bewusst ist, dass durch diese JavaScript-Frameworks hat man eine ganze Extra-Schicht an Komplexität dabei. Das heißt, alles, was gebraucht wird, um diese Seiten sichtbar zu machen, muss natürlich auch ausgeführt werden. Der ganze JavaScript muss laufen, muss vom Server gegebenenfalls weitere Inhalte holen. Und dadurch ist es so, dass wir einerseits vielleicht die Schwierigkeit haben, die diese Seite überhaupt zu random, die Inhalt überhaupt zu kriegen. Das ist etwas, was man testen muss. Andererseits ist es so, dass wir erst mal diesen Extraaufwand machen müssen, um diese Inhalte effektiv zu kriegen. Das heißt, es geht in vielen Fällen einfach ein bisschen länger, bis wir die Inhalte sauber crawlen und indexieren können. Das heißt, wenn ich eine normale Website habe, wo die Inhalte nicht so häufig sich verändern, dann funktioniert das eigentlich sehr gut mit einem Single-Page-App in Einrichtung. Wenn ich hingegen eine Website habe, wo die Inhalte sehr schnell wechseln, wenn ich einen News-Bereich habe oder wenn ich Produkte in einem Shop habe, die ständig kommen und gehen, dann ist mit einem reinen JavaScript-Framework es ein bisschen schwieriger, weil es immer diese Verzögerung gibt, bis die Inhalte wirklich gewendert werden und indexiert werden. Da gibt es auch Möglichkeiten, wie man das ein bisschen umgehen kann mit Server-Site-Rendering, dass man auf der Server-Seite anfühlt sich statische HTML-Seiten generiert und die dann ausliefert. Aber es ist alles natürlich viel komplizierter, als wenn man jetzt nur mit einer Standard-HTML-Seite arbeitet. Ich würde, wenn man als SEO tätig ist und Technische ein bisschen mit JavaScript umgehen kann, würde ich auf jeden Fall solche Probleme mal angehen und mal genauer untersuchen, wie das hinmacht, weil ich denke, gerade solche Single-Page-Apps kommen mehr und mehr und früher oder später kommt dann jemand zu euch und braucht wirklich Hilfe mit SEO und einem Single-Page-App. Und wenn das ist gut, wenn man da schon ein bisschen Erfahrung gemacht hat. Unsere Seite ist auf einmal von den Top-Positionen bei Google verschwunden und zwar nur in einem Land, in einer Sprache und für ein einziges Keyword. Allerdings unser wichtigstes. Wir haben unser off-page-Profil analysiert und festgestellt, dass die Enkeltexte lieber optimiert waren. Wir vermuten daher, wir wurden von Penguin bestraft. Daher haben wir die entsprechenden links in Disavow-Tool gesperrt und langsam neue natürliche Links gewonnen. Wie lange kann das dauern, bis sich das wieder eintendelt? Es ist schwierig zu sagen. Also ich weiß jetzt nicht, ob das effektiv nur wegen diesen Links natürlich das Problem ist. Es klingt so, als ob du da ein bisschen Ahnung hast und vielleicht auch ein bisschen weißt, was da alles passiert ist mit den Links und vielleicht habt ihr da wirklich auch ein bisschen zu viel gemacht. Aber grundsätzlich würde ich nicht ausschließen, dass es vielleicht auch andere Ursachen haben kann. Also ich würde das auf jeden Fall ein bisschen weiter anschauen. Wenn es wirklich nur wegen den Links ist oder hauptsächlich wegen diesen Links ist, ist es so, dass per Disavow werden die Links aus unserem System genommen, sobald wir diese Seiten neu gecrawled und geindexiert haben. Das heißt, es geht einfach eine gewisse Zeit, Minimum bis wir diese Veränderung überhaupt in unserem System dabei haben. Und dann vermute ich, dass es mit diesem Penguin Update oder mit allgemein mit dem Linkverarbeitung auf unserer Seite gibt es natürlich auch immer ein bisschen Verzögerung, bis wir das neue Gesamtbild haben. Ich könnte mir schon vorstellen, dass es da, sage ich mal, mehrere Monate vielleicht geht, bis sich das alles wieder eintendelt. Wenn ihr effektiv das Problem jetzt so beruhen habt. Was natürlich auch sein kann, gerade bei Links, ist, dass wenn die Website aufgrund von diesen unnatürlichen Links vorher überhaupt so gut gerankt hat und ihr diese Links jetzt rausgenommen habt aus dem System, dann wird die Website natürlich anders ranken nachher, auch wenn ihr das aufgeräumt habt. OK, eine Frage zur Kundenbewertung über JSON-LD versus quasi, wenn es im HTML direkt vorliegt. In diesem Fall ist da durch einem Burg waren nur die Hälfte der Kommentare in JSON-LD und die anderen quasi auf der HTML-Seite. Kann das problematisch sein? Wir versuchen den ganzen Structured Data aus verschiedenen Quellen herauszulesen von der Seite und versuchen das zu kombinieren, wenn wir das haben. Das heißt, wenn gewisse Teile nur über JSON-LD und andere Teile über Microdata oder anderswie eingebunden wurden, dann kombinieren wir das trotzdem und versuchen das Gesamtbild von diesem Structured Data anzuschauen. Das heißt, in einem solchen Fall, wenn man ein Teil da hat und ein Teil da hat, ist das trotzdem kombiniert und kann man das trotzdem herauslesen. Da sehe ich an und für sich kein Problem. Ich würde längerfristig, würde ich versuchen, mich auf ein von diesen Methoden zu beschränken, einfach damit man auch die ganze Verhaftung ein bisschen vereinfacht hat. Nicht, dass man da verschiedene Systeme hat, die Structured Data herausgeben, die unter Umständen dann nicht ganz synchronisiert sind. Dann kann man JSON-LD als Source einbinden, also quasi als eine externen JavaScript-Datei. Ich glaube, im Moment ist das nicht möglich. Müsste da mal nachfragen, aber ich glaube, man kann das nicht direkt als externe JavaScript-Datei einbinden, aber man kann natürlich per JavaScript weitere JSON-LD-Elemente einbauen lassen in einer Seite. Das heißt, über einen eigenen JavaScript kann man natürlich weitere JSON-LD-Elemente auf der Seite quasi generieren und die werden dann nach dem Rendering werden, die auch für Google sichtbar und fürs Indexing bereitgestellt. Optimal finde ich das nicht hundertprozentig, weil dafür müssen die Seiten dann jeweils auch renderen und dann hat man wieder diese Verzögerung, bis die Seiten effektiv auch für die Indexierung bereit stehen. Canonical oder Alternate-HR-Flang oder umschließt ein Alternate-HR-Flang auch ein... umfasst ein Alternate-HR-Flang auch die Funktion von Canonical. Nein, das sind an und für sich unterschiedliche Konzepte. Das heißt, mit dem Canonical werden verschiedene Versionen zusammengefasst und als eine URL indexiert und mit dem HR-Flang leiden die URLs separatenindexiert und die URLs werden einfach ausgetauscht in den Suchergebnissen. Das heißt, mit dem Canonical stärkt man an und für sich die Canonical-Ural mit den verschiedenen Varianten. Mit dem Alternate-HR-Flang ist quasi diese Konkurrenzsituation zwischen den verschiedenen Sprachen-Länder-Versionen und dann die Beste wird dann natürlich angepasst an die entsprechende Benutzer passende Version, die in HR-Flang Set angegeben ist. Ich habe einen Kunden-Kauftauch-Tab. Der Tab soll erst nachgeladen werden, sobald ein Kunde auf den Button drückt. Ajax, On-Page-Wert, der geladen bei Rendering, drückt Googlebot auch auf die Buttons. Nein, an und für sich nicht. Das heißt, wenn ihr Elemente auf der Seite habt, die wirklich nur dann sichtbar sind, wenn jemand etwas gezielt es macht auf einer Seite, dann sieht das Sachen, die wir für die Rendering nicht berücksichtigen, die wir nicht finden. Aber wir wissen ja nicht, wo man überall klicken kann, was man überall machen kann und wo vielleicht neue Inhalte geladen werden bezüglich wo vielleicht auch eine andere URL weitergeleitet wird, all solche Sachen kennen wir voraus nicht. Das heißt, wenn das Elemente sind, die für euch kritisch sind für die Indexierung, würde ich den sichtbar machen auf der Seite oder zumindest laden beim Aufstab von der Seite und vielleicht dann erst sichtbar machen durch den Knopfbrück, das geht an für sich auch. Ich denke, so Elemente wie Kunden kauften auch, könnten hilfreich sein oder wie eine Art Querverlinkung hat innerhalb der Webseite, aber sind vielleicht auch nicht kritisch für die einzelnen Seiten. John, ich habe das jetzt so gelöst, dass ich einen Link für die NoJavascript-Kleins praktisch gesetzt habe auf einem neue Seite. Dort sind dann die ganzen Kundenkauften auch Artikel aufgeführt, aber für den Kunden selbst, wenn er jetzt drückt, wird es nachgeladen im Tab. Mein Problem war einfach, dass zu viele Links auf der Seite waren. Aber jetzt kommt natürlich auch Googlebot auch wiederum weiter auf die neue Seite und kann dann auch weiter. Also ist da auch in Ordnung so. Das sollte eigentlich auch gehen. Okay. Ich würde das vielleicht mit einem Tool wie ScreamingFrag mal durchtesten, einfach damit man sicher ist, dass da wirklich die Linkung auch wirklich schon funktioniert. Nicht, dass man irgendwo gebrochene Links noch dabei hat. Okay, danke. Kurze Frage auch dazu. Wenn wir jetzt gar nicht drum herumkommen, dass wir irgendwie aufgrund Reusability Texte verstecken müssen und erst wenn der Nutzer irgendwo interagiert die Texte wieder darstellen, macht es dann mehr Sinn, die Texte beim Pageload komplett darstellen zu lassen und erst nach dem DOM Ready quasi auszublenden oder wird es dann von Google eher negativ bewertet? Ich denke, das kann man auf beide Arten machen. Also ich würde da eher darauf achten, wie das für den Benutzer funktioniert, weil je nachdem, wie man das gestartet, kann es natürlich sein, dass wenn man das erst später ausblendet, dass es dann wie quasi so einfach visuelle Effekte gibt, dass die Seiteninhalte irgendwie ein bisschen herumspringen beim Laden. Genau. Anführe sich euch überlassen, ja. Okay, aber der Text wird dann, weil Sie, oder weil du gerade meintest, dass der Text ansonsten eventuell nicht erkannt wird, wird der Text dann erkannt, wenn ich ihn standardmäßig dargestellt lasse und dann halt auf Kosten von der Optik, dass es dann halt eventuell noch umspringen, sobald dann JavaScript die Texte ausblendet oder erkennt Google standardmäßig eigentlich schon den Text, den ich nachlade und per JavaScript erst einblende. Sollte eigentlich automatisch erkannt werden, ja. Ich würde das testen mit enter the mobile friendly tool oder den rich cards test. Dort kannst du den gerenderten HTML auch anschauen. Und das siehst du dann gezielt, sind diese Texte wirklich im gerenderten HTML dabei? Oder hat Google Wort das irgendwie übersprungen, dass diese Sachen nachgeladen wurden? Ich habe das eben nicht geklappt aus eigenem Grund. Okay, perfekt, danke. Okay, in der aktualisierten Google Hilfe für hreflangt steht der reservierte Wert, xdefault wird verwendet, wenn keine andere Sprache beziehungsweise Region mit der Browser-Einstellung des Nutzers übereinstimmt. Bedeutet dies, dass die Browser-Einstellung des Nutzers zur Sprache oder Region entscheidend dafür ist, sind welche Seiten aus dem passenden hreflangset angezeigt werden. Grundsätzlich, ja, an und für sich ist das ein bisschen vereinfacht. Was normalerweise passiert ist, dass wir die Google-Version versuchen, anzupassen auf das, was wir denken für den Benutzern am praktischsten ist. Je nachdem, wie das Angestellt ist beim Benutzern-Browser, kann es sein, dass wir da die Sprachversionen anpassen oder dass wir da die Länder-Version entsprechend zeigen. Je nachdem, wo der Benutzer halt gerade moment ist und wie das Angestellt ist beim Benutzer. Das heißt, es ist nicht so, dass wir für den hreflang gezielt dann nochmal schauen, wie der Browser eingestellt ist, sondern eher, dass wir Google erst mal anpassen auf den Benutzern, auf die Einstellungen vom Benutzer. Und dann im zweiten Moment nehmen wir diese Einstellungen, die wir für die Google-Suche verwendet haben und suchen dementsprechend den passenden hreflang-Variante dazu. Das heißt, es ist nicht so, dass da quasi die Browser-Einstellung noch mal als separatem Element dazukommt. Wenn ein Deutscher Benutzer in Deutschland mit deutschen Browser-Einstellungen eine spanische Query verpasst, für eine Seite mit hreflang de e, d e oder mit einer Seite b, mit dem hreflang es, stich es, welche von beiden Seiten wird er wahrscheinlich in den Suchergebnissen angezeigt bekommen. Ich, also soweit ich weiß, ist das nicht effektiv definiert. Das heißt, es kann ein von beiden passieren. Das heißt, es kann sein, dass wir denken, eher die deutschen Einstellungen sind jetzt hier relevant, also zeigen wir die d e d e Version oder es kann sein, dass wir eher denken, gut, die spanische Version ist jetzt eher dominant. Hier zeigen wir eher die e s, e s Version. Das heißt, beide von diesen Seiten passen ja nicht wirklich auf diesen Benutzer. Das heißt, wir haben da nicht eigentlich ein System mit dem wir gezielt sagen würden, wenn keine Seiten passen, dann mache es nach diesem Schema, sondern dann müssen halt selber algorithmisch irgendwie entscheiden, welches von beiden würden. Ändert sich das Ergebnis für den deutschen Benutzer? Wenn stattdessen nur d e oder e s steht, also jemand in Deutschland, der auf spanisch sucht, ist anfühlt sich das gleiche, weil mit dem hreflang sagt er ja da, dass, was ist das? Ah, nee, das ist ja die Sprachversion. Das heißt, wenn jemand auf spanisch sucht, könnte ich mir vorstellen, dass vielleicht die spanische Version kommt. Aber eben, wenn natürlich Google auf Deutsch eingestellt ist, man sucht auf spanisch, dann ist es wieder da die Situation, dass man Signale hat, die nicht zusammen passen und dann kann es mal so oder mal so gehen. Das heißt, wenn ihr gezielt solche Situationen habt auf eurer Website, dass ihr denkt, dass jemand in einem anderen Land mit einer anderen Sprache sucht, dann würde ich eher mit dem Xdefault noch arbeiten, dass man das einfach irgendwie sauber selber abfangen kann, dass ihr selber auch entscheiden könnt. Ich habe eine genaue Vorstellung, wie das ablaufen soll auf meiner Website, also möchte ich, dass es nötigst nach diesem Schema bei mir abläuft, dann kann das ja gezielt auch angehen. Noch eine Frage zum mehrsprachigen Websites. Die war schon von mir, und das hat man gemacht. Das haben wir gemacht, super. Okay, dann die Frage zum Domain Flackenplatz DE, welches seit April fast 80% an Sichtbarkeit verloren hat. Ich habe da ein bisschen nachgeschaut. Ich weiß nicht genau, was sich da alles verändert hat seit Anfang Jahr. Was ich einfach gesehen habe, ist, dass unsere Qualitätsalgorithmen nicht wahnsinnig zufrieden sind mit der Website. Ich weiß nicht, ob da gezielt etwas ist auf euren Seiten, was man da verbessern könnte, aber ich würde da vielleicht mal das Ganze im großen Rahmen mal wieder mal anschauen, überlegen, was könnte man machen, um das zu verbessern. Eine Sache, die mir so einfach auf Anhieb aufgefallen ist, als ich die einzelnen Seiten angeschaut habe, ist, dass da zum Teil halbe Wikipedia-Information zu den einzelnen Ländern noch dabei sind. Und ich weiß nicht, wie relevant das wirklich für eine e-Commerce-Website ist. Aber das kennst du wahrscheinlich am ehesten, weil du weißt ja, wonach deine Benutzer suchen, wie sie zu deinen Seiten kommen. Und dann kann man dann vielleicht auch ein bisschen gezielt da anpassen und sagen, gut, die kommen wegen dieser Suche. Und dafür habe ich jetzt wirklich Information oder Produkte halt zur Verfügung. Und vielleicht kommen sie auch wegen anderen Suchen, aber da habe ich eigentlich nichts, was ich anbieten kann. Dann ist nicht unbedingt die Idee, dass man diese Information noch zusätzlich auf eure Seiten nimmt, sondern da muss man halt sagen, gut, ich habe halt nichts für die, das ist auch okay. Das heißt, wenn jemand, sag ich mal, nach der Bevölkerung von Koacien fragt, dann muss er nicht unbedingt auf eure Flacken-Website kommen, um diese Information zu kriegen. Macht es vielleicht eher Sinn, dass die halt voran das hingehen. Und da müsst ihr nicht noch zusätzlich, sag ich mal, Bevölkerungszahlen und Hauptstädte und solche Sachen dazu nehmen. Aber das ist ein bisschen schwierig für mich zu sagen, wenn ich da jetzt einfach ein paar Minuten in die Website hineinschaue, da kennst du die wahrscheinlich viel besser als ich. Also ich habe halt versucht, ein Thema abzuarbeiten. Also wenn jetzt einer, was weiß ich, Mexikoflage hat und dann soll halt noch ein bisschen was dazukommen. Ich meine, die Leute, die kaufen interessieren sich ja wahrscheinlich auch ein bisschen dafür. Also ist das jetzt so das Problem eigentlich, dass da so Informationen drin sind, die nichts dann mit der Suche zu tun haben eigentlich? Oder würdest du sagen, dass da jetzt irgendwie der... Also die Links sind es nicht, ne? Also die Links nicht. Also unsere Qualitätsalgorithmen sind allgemein einfach nicht ganz zufrieden mit der Website. Das heißt, ich habe jetzt da nicht gezielt weiter nachgeforscht, was genau sie nicht so wahnsinnig toll finden. Aber so etwas kommt manchmal vor, dass sie da einfach so viele Informationen finden und denken, gut, diese Website ist eine Website, die verkauft Flakken, die muss nicht relevant sein für die Bevölkerungszahlen von den einzelnen Ländern. Also müssen wir da vielleicht sagen, von der Qualität her, wie soll man das einstufen für Bevölkerungszahlen? Ist sie wahrscheinlich nicht wirklich ein guter Resultat für Flakken schon eher und irgendwo müssen wir das dann irgendwie einreihen. Und da würde ich sagen, dass würde ich eher an der einen Stelle vielleicht mit dem Benutzer auch mal anschauen, vielleicht ein User-Study-Markt oder eine Umfrage, ob diese Informationen wirklich relevant sind und ob diese Informationen dazu beigetragen haben, dass Besucher überhaupt auf deine Website gekommen sind, die dann schlussendlich auch etwas von dir gekauft haben. Weil Traffic Align hilft ja eigentlich nicht viel, wenn sie nicht bereit sind, etwas zu kaufen. Wenn sie nichts suchen, was sie kaufen können, kaufen wollen auf deiner Website, dann hilft es nicht, wenn sie auf deiner Website waren. Okay, alles klar. Danke. Ja. John, da hätte ich mal kurz eine Frage zu den Qualitäts-Argorithmen. Und zwar, vielleicht könntest du das einmal erklären, was Google unter der Suchintention genau versteht, sagen wir mal zu einer Keyword-Kombination wie Restaurant und Ort, um da oben zu ranken, bei einer Restaurant-Website. Ah, wo soll ich da anfangen? Und ja, ich denke, da kommt viel dazu. Also, ich habe, was war es, diese Woche noch ein Training gemacht mit anderen intern hier, und da haben wir so einzelne Suchanfragen mal ein bisschen auseinandergenommen. Und das sind wirklich, sagen wir, Tausende von Faktoren, die dazukommen, bis wir effektiv aus irgendeiner Suche, die Suchanfrage so umgeschrieben haben, wie wir sie bearbeiten können und dann auch wirklich Resultate dazu gefunden haben, wie wir zeigen können. Also, das ist nicht wahnsinnig einfach. Und ich denke, das Wichtige, was vielleicht im ersten Schritt auch passiert ist, dass wir erstmal die Suchanfrage auseinandernehmen und wir uns überlegen, was könnte wirklich damit gemeint werden, welche Synionöme könnten dazu passen, welche Entities sind da in diesen Suchanfragen dabei. Das heißt, gerade, wenn ich einen Ort dabei habe, heißt das jetzt genau im Mittelpunkt von diesem Ort oder um diese Umgebung, wie soll das beurteilt werden. Und das sind extrem komplizierte Algorithmen, die da zusammenkommen. Und von dem her ist das schwierig, das so zu vereinfachen und dann sagen, ja, gut, das gibt quasi diese Linearprozess, bis wir da zu den Suchergebnissen kommen. Es kommt da wirklich sehr viel von allen möglichen Seiten zusammen. Und manchmal wird das eine mehr bewertet, als das andere, wenn etwas eher in den Nachrichten ist, dann müssen wir vielleicht eher auf Neuigkeiten achten. All das kann ein bisschen dazukommen. Ich dachte es eigentlich anders. Vielleicht zum Beispiel, was man erwartet, wenn man auf einer Restaurant-Webseite geht, dass man da Öffnungszeitenpreise, Bilder von innen, von außen sieht, die Spreisekarte aufgeteilt, Nachstoffpräferenzen wie Fleischgerichte, Vegetarische. Also das, was Leute wissen wollen. Ich möchte eigentlich noch wissen, ob Google das je nach Branche, um was für eine Website das sich handelt, von was wir am Anbieter, da Einstufungen macht. Je nachdem, was vielleicht über Google My Business als Branche für eine Website hinterlegt wurde. Teilweise kommt das schon dazu. Gerade wenn wir gewisse Elemente von einer Website herausholen können. Das heißt, es ist nicht unbedingt so, dass wir, sagen wir mal, ein Menü genau untersuchen. Aber wenn wir feststellen können, dass da ein Menü vorhanden ist, dass der Preise vorhanden sind, dass da ein Standort klar angegeben ist auf der Website, dann hilft uns das schon eher zu erkennen. Ah, das ist eine Restaurant-Webseite, die an diesem Standort ist, mit dieser Telefonnummer. All das passt zusammen, und dann können wir das eher auch in den Suchergebnissen zahlen. Aber es ist nicht so, dass wir das Menü auseinandernehmen und sagen, das sind Fleischgerichte und der guitarische Gerichte dabei. Das ist ein ausgewogenes Verhältnis, deshalb ist das jetzt ein besonders gutes Restaurant. Wir versuchen da im ersten Moment eigentlich grob, das ein bisschen einzuteilen. Passt das zu dieser Suchanfrage, oder ist das ein Metzger, der einfach verschiedene Sachen auf seiner Website hat, aber eigentlich kein Restaurants? Dann hätte ich noch kurz eine Frage zur Qualität, und zwar den Lighthouse-Test, da habe ich mich jetzt sehr viel mit beschäftigt. Da gibt es auch einen Punkt Accessibility. Also quasi, wie können die Inhalte wahrgenommen werden? Schriftgrößen und Kontrastverhältnisse auf der Website. Ich glaube, ich habe früher auch Leute, die gerne mal weiße Schrift auf weißen Grund und schwarze Schrift aus schwarzen Grund benutzt haben. Ist das auch relevant für das Ranking? Accessibility ist meines Erachtens nicht direkt beim Ranking dabei. Das ist etwas, was wir zwischendurch immer wieder mal angeschaut haben, ob man da vielleicht mehr auch, wie mit Mobile-Friendliness, auch Accessibility-Friendliness sozusagen als Faktor dazu nehmen kann. Meines Erachtens ist das nicht direkt als Faktor dabei. Das kommt zum Teil beim Mobile-Friendliness natürlich auch dazu. Das heißt, ob die Schriftgröße passt, ob die Links irgendwie so sind, dass man die irgendwie einzeln anklicken kann. Ein bisschen kommt ja da schon dazu, aber es ist nicht so, dass wir gezielt Accessibility-Tests machen und sagen, das wäre jetzt ein Ranking-Faktor. Okay, weil man hat ja auch manche Website, also nicht nur auf mobilen Endgeräten, sondern auch auf Desktops. Oft hat das Problem jemand einen grauen Hintergrund und eine weiße Schrift drauf. Und es ist einfach sehr schwer zu lesen. Ja, solche Sachen versuchen wir ein bisschen zu erkennen und ein bisschen dann entsprechend, als wird mal Hiddentext entsprechend in unseren Systemen aufzunehmen. Es ist manchmal ein bisschen schwierig, genau zu erkennen, wie das gedacht ist, weil je nachdem hat man da verschiedene CSS-Style-Streets und der eine macht, dass man den Text weiß und der andere macht dann ein Hintergrundsbild dazu und das Hintergrundsbild ist vielleicht für Robots Text blockiert. Und dann können wir das hoherprozentig nicht kontrollieren. Aber teilweise versuchen wir da schon zu erkennen, ob das eher Richtung Hiddentext ist oder nicht. In vielen Fällen funktioniert das relativ gut und allgemein, die diese ganzen, vielleicht mal versteckten Links und versteckte Worlds auf Seiten, hatten wir es hier nachgelassen, meines Erachtens, weil wir auch gerade mit Keywords da fingen, eigentlich sehr gut inzwischen zu standen, zu wegkommen. Hiddentext heißt dann, das ist negativ? Es heißt aus unserer Sicht einfach, dass es jetzt nicht zum Hauptteil von dieser Seite gehört. Das heißt, wenn jemand gezielt danach sucht und wir wissen, dass es versteckt auf der Seite, dann nehmen wir ja gut. Das ist vielleicht jetzt nicht gerade die passende Seite oder wir müssen diesen Text jetzt nicht unbedingt im Snipet dazu bringen, weil vielleicht sieht das der Benutzer gar. Und eine allerletzte. Du hast das neulich mal irgendwo gesagt, dass für den Mobile First Index Accordions werden okay, also auch zugeklappte Accordions. Die Frage, sollte man jetzt anfangen und viele Accordions in den Blasterfold-Bereich packen, um möglichst viele Suchbegriffe abzudecken oder geht es schon darum, was tatsächlich sichtbar ist? Ich würde das weiterhin einfach so machen, was es für den Benutzer klappt. Weil, ich meine, man kann natürlich schon die Keywords dazu nehmen, aber was in den meisten Fällen passiert, ist, dass wir das einfach was Keywords anfangen, dann anschauen. Und wir sehen dann schon diese Elemente da und die sind halt zugeklappt und aus unserer Sicht ist das auch okay. Aber wir sehen dann einfach, dass da quasi Keywords reingestopft werden und dann denkt man gut, so relevant kann das nicht sein, wenn man diese Keywords so oft wiederholen muss, damit die Seite überhaupt ein Suchergebnis erscheint. Und dann zeigt man die ein bisschen weniger relevant. Und das passiert mit Accordions. Andere haben das einfach unten quasi auf einer Kathorien-Seite, irgendwie zwei, drei Wikipedia-Artikel sozusagen reinkopiert. Das ist immer noch sehr häufig der Fall. Und in vielen Fällen können wir das einfach ignorieren und die Seite rankt ganz normal. Und das ist eigentlich aus meiner Sicht der optimale Ansatz, weil wir müssen ja nicht erwarten, dass die Webmeister alle böswillig das machen, sondern man hat vielleicht irgendwie das mal gehört, man hat das dann gemacht und dann hat man das gelassen für zehn Jahre. Und dann hat man das aber auf der Webseite. Und solange unsere Systeme damit einigermaßen umgehen können, ist das aus meiner Sicht eigentlich okay. Okay, danke. Ich hätte noch eine Frage zu den Accordions. Wie weit wird denn praktisch etwas gerendert? Also, wie breit ist der Viewport eigentlich? Weil mir ist aufgefallen, ich habe umgestellt diese horizontalen Slider bei uns und zwar auf diese Vorgaben, die es von Google vorgegeben wird mit OverflowX, also, dass man die praktisch durchskrollen kann. Jetzt gibt es ein Google-Weblight.com, das ist so eine Art für schlechte Verbindung, damit kann man dann einfach die Seite rendern und sich die anschauen. Und jetzt ist mir aufgefallen, bei den OverflowX werden viel mehr Bilder in einer Reihe gerendert und angezeigt. Also, vorher hatte ich ans Slider gehabt auf Javascript-Basis und da wurden nur zwei Bilder angezeigt und es ist auf einmal sieben. Also, ich habe mir dann so gedacht, okay, der Viewport wird wahrscheinlich anders gerendert. Weblight ist ein bisschen speziell, weil was andere Algorithmen verwendet, als eine normalen Websuche, Weblight ist ja als System, an und für sich da, dass man da eher langsamer oder größere Webseiten trotzdem auf weniger leistungsstarken Mobilgeräten irgendwie sicher machen kann, wie vielleicht ganz am Anfang, als es diese WAP Proxies gab, dass man normale Websites auch auf den alten Mobilgeräten irgendwie anschauen konnte. Ähnlich ist das jetzt mit Weblight gedacht. Also, es ist nicht unbedingt ein Zeichen, dass das in der Suche so verwendet wird, sondern wirklich halt etwas gezieltes für diese Art von Benutzer. Für die Viewport Breite und Höhe beim Rendering selber weiß ich nicht, was da genau im Moment der Wert ist. Man kann das allerdings relativ gut testen. Das heißt, per JavaScript kann man ja die Größe abfragen und die kann man dann sicher machen auf eine Seite und dann mit Fetch and Render oder mit dem Mobile Friendly Test kann man das sehr schnell kontrollieren. Da sieht man, welcher Viewport auch sicher war. Aber wir haben auch die Größe, die Breite und die Höhe nicht genau definiert in unseren Dokumenten, weil das kann sich im Laufe der Zeit auch ändern. Ähnlich haben wir das, gerade beim Smartphone Crawler gemacht vor einigen Jahren, dass wir gesagt haben, diese Art von Browser und diese Art von Einstellung ist jetzt nicht mehr den, was der normale Benutzer sehen würde. Also müssen wir das entsprechend anpassen. Ähnlich kann das auch passieren, gerade beim Viewport, mit der Breite oder Höhe, dass wir sagen, das entspricht jetzt nicht unbedingt was normaler Desktop oder Mobile Benutzer sehen würde. Wir müssen das ein bisschen anpassen. Und je weiter hinten, also je weiter nach rechts Inhalte sind, desto unrelevanter werden die wahrscheinlich und je weiter unten dann auch. Weiter nach rechts, weiß ich jetzt nicht. Es ist immer schwierig bei großen Webseiten zu sagen, wo die relevanten Inhalte sind. Das heißt, wenn eine Seite eher klein ist und eher im Above the Fold-Bereich gerendet werden kann, dann können wir eher davon ausgehen, dass das jetzt die relevanten Informationen sind. Wenn eine Seite sehr lang ist, dann ist es schwierig zu erkennen, wo jetzt die wichtigsten Informationen dabei sind oder wie wir diese Seite insgesamt einstufen sollen. Das ist sehr häufig der Fall, gerade bei PDF-Dateien, wenn man 50 Seiten PDF hat, kann das trotzdem noch relevant sein für etwas, was auf Seite 40 steht. Es ist ein bisschen schwierig abzuwägen, wie man das beurteilen soll. Ähnlich geht das auch mit Sachen, die zur Seite rausgehen oder Sachen, die nach unten gehen. Theoretisch kann das immer noch relevant sein, aber es ist vielleicht schwieriger für uns zu erkennen, wenn etwas wirklich das Wichtigste ist auf einer Seite war, warum ist es dann soweit weg? Weiß ich nicht. Also, ich würde solche Sachen einerseits für Benutzer auch mal testen. Das heißt, dass ihr da a usability study vielleicht macht, auch wenn man nur ein kleines A-B-Testing macht, mit Analytics zum Beispiel, andererseits auch in der Suche einfach mal ausprobieren. Vielleicht, wenn ihr eine Website habt mit verschiedenen Seiten, mal eine Seite breit oder eine Seite hochmachen und Informationen sprechen verteilen und dann schauen, wie diese Seiten auch wirklich performen in der Suche. Okay, danke schön. Leider keine absolute Antwort da. Dann schon. Okay. Mal schauen, was wir sonst noch da haben. Es sind noch einige Sachen dabei. Eine Frage mit einem CDN, in welches über gewisse Zeiten 4.0.3 zurückgegeben hat, bezüglich dem Crawling und Google Crawl jetzt nur noch 30% der URLs im Vergleich zu vorher. Grundsätzlich ist es so, dass wir die Crawl-Geschwindigkeit automatisch anpassen an den Server und an die Infrastruktur und das wird normalerweise im Bereich vielleicht mal einigen Tagen vielleicht eine Woche oder zwei angepasst. Das heißt, wenn der CDN etwas schlechtes zurückgegeben hat für eine gewisse Zeit, mit dem Crawling bis ins Rückgang sind und ihr das behoben habt seit mehr als einer Woche oder zwei, dann sollte eigentlich das Crawling wieder normal schnell sein. Wenn wir trotzdem weniger Crawling kann es sein, dass wir einfach weniger zu Crawling haben von eurer Website, oder? Nicht ganz sicher sind, ob es so viel Sinn macht, so tief oder so viel zu Crawling von einer Website. Mal schauen. Ich glaube, ja. Ich vermute, dass das geht in diese Richtung. Ja, bitte. Ich habe noch ganz kurz eine Frage zur Structured Data Markup. Wenn ich jetzt ein Unternehmen habe, weil es mehrere Locations hat, macht es einen Unterschied, wenn ich jetzt quasi die einzelnen Adressen per Array einbinde, quasi bei dem Type Restaurant zum Beispiel und dann Array auf die Locations rein, Array zu. Oder soll ich die quasi jeweils mit einem neuen Kontext und neuen Type einbinden. Habe ich quasi auf der rechten Seite dann alles in einer Zeile drin stehen, beziehungsweise unter dem Type Restaurant, wo ich dann alle Adressen untereinander habe, oder quasi, ich sage mal, dann 13 Restauranttypen in einem Structured Data Markup habe. Also macht es einen Unterschied, ob ich die jetzt manuell einbinde per Application, JSON, LD, Kontext und Type, oder einfach per Array? Meines Erachtens macht es keinen Unterschied. Das heißt, kann man machen, wie man will, wenn das gleiche Restaurant ist, wenn das eine Kette ist von verschiedenen Standorten vom gleichen Restaurant, kann man das natürlich so oder so machen. Wenn es unterschiedliche Restaurants sind, dann macht man das natürlich separat. Wie inwiefern beachtet Google für Voice Search Structured Data? Da gibt es diese Speakables und dergleichen oder Questions. Also die von Schema.org und SlashSpeakable, die ist ja noch in der Pending Phase und dann gibt es aber noch diese Questions und so weiter. Das heißt, beachtet das Google für Voice Search, wenn ich hier sage, das ist die Headline per Longtail Keyboard Research Recover zum Beispiel und das wäre dann die Antwort oder nennt sich dann Google irgendwann auch dann Random Peace? Ich weiß, dass da im Moment dran gearbeitet wird, aber ich weiß jetzt nicht, was der aktuelle Stand ist. Das heißt, ich müsste da mal genauer nachfragen beim Team, wie das jetzt gehandhabt wird. Aber man hat immer die Situation, dass unsere Algorithmen einerseits die Information von der Seite haben, andererseits vom JSON-AD, vom Markupair. Das heißt, man kann sich eigentlich nie hundertprozentig drauf verlassen, nur das eine oder nur das andere. Aber wie das genau jetzt bei Speak-Rolls gehandhabt wird, weiß ich nicht, was ich momentan möchte. Okay, danke. Muss ich mal abklären. John, ich bin derjenige mit dem CDN. Okay. Meine Frage wäre jetzt, das Wichtigste wäre jetzt tatsächlich, diese gefunden zuzeit nicht indexiert. Kann das an den CDN-Problemen gelegen haben, dass wir denn immer wieder rausgeklickt haben, um das zu bekommen, das zu den Wells? Das könnte sein, aber wenn ihr das, sag ich mal, schon mehr seine Woche her behoben habt, dann sollte das eigentlich sich wieder einpendeln. Das heißt, gerade 403 Fehler sind eigentlich Fehler, die wir automatisch wiederholen, die nicht unbedingt die Crawl-Geschwindigkeit beeinflussen. 500er Fehler, also alles, was Server seitigen Fehler ist, das wäre eher etwas, wo wir dann mit dem Crawl zurückgehen würden. Aber mit 403 gerade auch, wenn das halt keine Zeit behoben ist, sollte das eigentlich nicht von dem her kommen. Ich vermute, dass es wirklich eher so, dass wir all these URLs gefunden haben und denken gut, wir wissen nicht, ob es sich lohnt, dafür zu investieren und all these URLs noch zu crawlen. Also weniger, dass es ein technisches Problem ist, sondern eher einfach ein Problem der Überzeugung von Googlebot, dass man da wirklich jetzt das alles crawlen soll. Okay, und wenn jetzt diese falsche CDN-Konfiguration, die hat jetzt mehrere Jahre wahrscheinlich existiert, die ist jetzt seit 4 Wochen gehoben, kann das dann jetzt alles noch so ein bisschen dauern, oder soll ich mich schon auch für die Besuche nach anderen Problemen machen? Das sollte eigentlich innerhalb von 4 Wochen sich das sicher einpendeln. Was man auch machen kann, ist im Search Console, ich glaube im Hilfe Center gibt es einen Link zu einem Forum, wo man Probleme mit Googlebot melden kann und das geht direkt an das Googlebot-Team, welches da kontrollieren kann, ob da vielleicht irgendwelche manuellen Einstellungen noch vorhanden sind, die das zusätzlich ein bisschen abgebremst haben. Aber die kann an für sich auch nur, die technischen Beschränkungen lösen, wenn da irgendwas noch vorhanden ist, die würden das nicht einstellen, dass wir quasi jetzt mehr Crawlen wollen, weil wenn wir weniger Crawlen wollen, dann hilft es uns auch nicht viel, wenn man die die da nicht mehr machen, weil die schauen sich dann so so. Alles klar, vielen Dank John. Ja, bitte. Okay, ich glaube, wir haben noch eine Minute Zeit. Gibt es von aus eurer Sicht irgendwie noch Fragen, die wir unbedingt heute noch behandeln müssen? Ja, ich hätte noch eine Frage an dich. Okay. Und zwar, würde es so empfehlen, abgelaufene Inserate, also Produkt ist nicht mehr vorhanden, der 301 zu den Kategories Seiten umzuleiten, um so mit Page Authority weiter zu verderben. Grundsätzlich würde ich da eher eine 404-Seite zurückgeben, weil was da in der Regel passiert, wenn wir das im großen Rahmen sehen, wie bei einer Webseite dann denken wir eher, dass dieser Redrag wie ein Soft 404 ist und wir behandeln das sowieso dann als 404. Das heißt, es wird eigentlich dann sowieso nichts weitergegeben, weil wir genau wissen, diese Kategoriesseite ersetzt ja eigentlich nicht diese Produktseite, sondern es ist eigentlich etwas anders, sondern eher wie eine 404-Seite, die zu diesem Produkt halt passen würde. Das heißt aber auch, wenn ihr das aus praktischen Gründen machen wollt, oder wenn ihr vielleicht aus einfachen Gründen sagt, gut, wir möchten da jetzt nicht noch ein zusätzlicher 404-Seite erstellen, die dann zu ähnlichen Produkten vielleicht verlinkt, dann das war sonst, das heißt, wir behandeln einige dieser Links wahrscheinlich dann als Soft 404, aber andere werden wir dann trotzdem für den Redrag weiterverwenden. Das heißt, ihr verursacht keine Probleme, wenn ihr das so umagt. Okay, alles klar, danke. Okay, cool. Kann ich noch eine Frage ganz schnell zum Speed Update stellen. Da war ein Blockpost, dass das jetzt ausgerollt ist, also auf Twitter kam was, wie lange dauert das, bis das Ranking verarbeitet wurde? Normalerweise geht das relativ schnell. Manchmal gibt es da einfach einen Zeitrahmen, vielleicht von einer Woche oder so, bis sich das überall angependelt hat. In vielen Fällen ist das einfach relativ schnell überall drin. Okay, danke. Cool, okay. Dann machen wir doch hier eine Pause. Ich richte die nächsten Hänge noch ein. Anfang Augusten Ferien. Ich weiß nicht, ob das noch vorher war. Wahrscheinlich schon. Ansonsten könnt ihr natürlich auch weiterhin Fragen auf Twitter posten oder im Hilfeforum eindringen. Das sind auch die, die relativ gut werk sind und vielleicht helfen. Okay. Dann wünsche ich euch einen schönen Tag noch und bis zum nächsten Mal. Tschüss allerseits. Tschüss. Ciao.