 Okay, herzlich willkommen beim heutigen Google Webmaster Essentials Sprechstunden-Hangout. Ich bin Johannes Müller, Webmaster Trans Analyst bei Google in der Schweiz. Okay, willkommen beim Google Webmaster Essentials Sprechstunden-Hangout. Da haben wir ein Echo. Und Teil von dem, was wir machen, sind natürlich solche Webmaster-Hangouts, zusammen mit Webmaster, SEO, Publisher und irgendwelchen Fragen bezüglich Websuche, die eventuell aufkommen. Wie immer, wenn einer von euch loslegen möchte mit den ersten Fragen, könnt ihr gerne jetzt einsteigen. Hallo, hört ihr mich? Ja. Ah, super. Ja, schön, dass es geklappt hat heute mit dem Hangout. Also Christian Kunst, mein Name. Und ja, ich hatte ja schon einige Posten in der letzten Zeit geschickt rund um das Thema Datenschutz-Grundverordnung. Jetzt fahren wir gleich mit einem blöden Thema an für dich, John. Aber du hattest ja gesagt, da ist jetzt wahrscheinlich von Information noch nicht so wahnsinnig viel, was du uns mitteilen kannst. Dennoch versuche ich es mal. Mein Hauptthema ist im Moment tatsächlich der ganze Komplex AMP und die Datenschutz-Grundverordnung. Also, ich erkläre es ganz kurz. Es geht darum, AMP läuft ja auf Google-Infrastruktur. Wenn der Nutzer auf den Suchergebnis klickt, bei Google zieht er zwar die Domain der Website, landet aber dann bei Google ohne es zu merken. Also, normalerweise merkt er es nicht. Zwei Fragen stellen sich dadurch für mich erstens. Ist es irgendwie angedacht, dass Google da eine Art Vereinbarungs- und Auftragsdatenverarbeitung anbietet für Website-Betreiber? Und zweitens, ist es irgendwie angedacht, da eine Kennzeichnung einzuführen oder irgendwie ein Hinweis für die User, dass sie quasi nicht auf die Domain springen der Website, sondern auf Google-Service. Weiß ich nicht. Weiß ich zu beiden Fragen. Jetzt weiß ich nicht unbedingt, was da geplant ist von der AMP-Seite. Irgendjemand anders hat auch gefragt wegen Analytics und Assents, glaube ich. Und da weiß ich auch nicht, was geplant ist. Ich glaube, von der AMP-Seite hat Malte auf Twitter gesagt, dass sie da an einer Post noch arbeiten mit weiteren Informationen. Aber was da genau kommt, weiß ich jetzt nicht voraus. Okay, dann warten wir mal. Malte, da wollte ich irgendwie ein Post schreiben oder irgendwas veröffentlichen dazu. Genau. Okay, dann warten wir das einfach mal ab. Ja. Nein, da habe ich da auch nicht viel mehr dazu. Okay, alles klar. Danke. Trotzdem. Okay, sonst legen wir doch mal los mit den Fragen, die schon angereicht worden sind, wenn zwischendurch noch weitere Fragen aufkommen oder Bund-Klarheiten sind zu den Fragen oder Antworten, einfach losleben. Okay, die erste Frage ist zum Mobile First Index. In einem Projekt sind m.example.com und www.example.com und der m.punkt sind noch keine Texte interlekt und der www sind alle dabei. Wenn die Seiten in den Mobile Index kommen, müssen wir mit Verlusten rechnen. Ja. Wenn wir eine solche Website umschalten auf Mobile First Indexing, dann nehmen wir nur die mobile Version für das Index und nicht etwa ein Mix aus der Desktop und der mobilen Version, sondern wir nehmen wirklich nur die mobile Version. Allerdings würden wir so etwas wahrscheinlich nicht auf Mobile First Indexing umschalten, da wir sehen, dass da unterschiedliche Inhalte vorhanden sind oder dass da immer keine Inhalte auf der mobilen Version vorhanden sind. Ich denke, für Benutzer ist das natürlich auch ein bisschen ärgerlich, wenn die mobile Version gar keine Inhalte hat. Bewertet oder gewichtige Google Inhalte, Texte hyperlinks im Viewport höher als Texte below the fold, meines Wissens nicht. Meines Wissens sind die eigentlich alle mehr oder weniger gleich. Wie sieht es mit sichtbaren Links und Texten im Viewport gegenüber nicht sichtbaren Texten oder Links, zum Beispiel mit der Hamburger Navigation. Im Moment mit dem Desktop Index ist es so, dass wenn Inhalte nicht sichtbar sind, wenn sie geladen sind, aber nicht standardmäßig sichtbar sind, dann werden sie ein bisschen weniger stark bewertet. Das sieht man meistens, wenn man zum Beispiel die Snippets anschaut für den Suchergebnissen, dass wir da solche unsichtbaren Texte eher nicht als Snippet zeigen, weil der Benutzer sieht sie ja dann auch nicht standardmäßig. Mit dem Mobile First Index ändern wir das aber, dass diese Texte eigentlich ganz normal gezählt werden, weil gerade auf mobilen Geräten kann man natürlich nicht genau so viel hineinnehmen wie beim Desktop Navigation. Bezüglich Links selber ist es eigentlich in beiden Fällen so, dass wir die normal zählen. Also wenn etwas im Menü drinnen ist, auch wenn das eingeklappt ist, ist das aus unserer Sicht ganz okay. Dann eine Frage zu Links in Skripten, also gerade bezüglich JavaScript, wo der Link nicht als html geschrieben wird, ob das auch befolgt wird. Ja, also es sind glaube ich da drei Varianten, die er aufgezählt hat. Einerseits mit Onclick, wo dann der Location href gesetzt wird oder mit einer separaten Funktion oder dass das quasi per Ajax irgendwie weitergeleitet wird. An und für sich, wenn wir eine URL erkennen können, die gesetzt wird, entweder mit html push state oder mit dieser Location.href Navigation, dann nehmen wir das als normalen Link auf, beziehungsweise als redirect, wenn das standardmäßig schon aufgerufen wird. Wenn wir den Link nur im Text von der JavaScript-Datei finden können, dann nehmen wir das auf wie ein Link, den wir sonst im Text von der Seite finden. Also es wird dann nicht Pagerank und andere Signale weitergegeben. Aber wenn wir das normal erkennen können mit html push state, dann ist das an und für sich kein Problem. Ich würde auf jeden Fall, aber trotzdem, die als Fallback immerhin die normalen A-Links auf dabei haben. Also wenn man mit JavaScript navigiert zu einer anderen Seite, dass man da trotzdem diesen A, href und die URL angibt und dass man dann einfach den JavaScript obendrauf noch dazunehnt. Das heißt, dass man das per JavaScript quasi ausführt, aber dass jeder, der diese Seite öffnet, anfühlt sich diesen html Link auch sehen kann. Dann eine Frage zu Produktvarianten und Canonicals. Google zeigt leider nicht immer die Hauptprodukt-Zeiten an. Bei einem Canonical würden zu viele Details aus dem Produktvarianten verschwinden. Ich probiere im Moment Folgendes aus. Ich stärke die Hauptprodukt-Zeiten mit guten Content. In der Signale-Datei sind auch nur die Hauptprodukt-Zeiten gelistet. Alle Varianten können über die Hauptprodukt-Zeiten erreicht werden. Sind die Signale so deutlich genug für Google? In der Regel sollte das eigentlich schon relativ deutlich so sein, wenn wir sehen, dass diese Seiten quasi nur zusätzlich noch verlinkt sind, auch vorhanden sind. Allerdings ist das nie eine Garantie, dass wir die Seiten so ranken, wie du das haben willst. Das heißt, es gibt Situationen, wo wir sehen, dass Benutzer vielleicht eher nach einer Kategorienseite suchen, auch wenn sie gezielt nach einem Produktnamen suchen. Manchmal gibt es auch Situationen, wo sie sehen, dass Benutzer wirklich gezielt nach einer Variante von einem Produkt suchen, auch wenn der Suchbegriff eher mehrdeutig sein könnte. Es ist nicht garantiert, dass wir immer das nehmen, was du quasi davor gibst. Allerdings hilft es sehr, wenn wir wirklich eine klare Struktur innerhalb der Website erkennen können. Wenn wir sehen können, wie das verknüpft ist, wie der Kontext von diesen Seiten ist, dass diese Varianten mit den Produkten zusammenhängen, dass die Produkte in eine Kategorie gehören, dass sie vielleicht über Kategorien vorhanden sind, dass wir wirklich eine klare Struktur erkennen können. Aber dann können wir am ehesten aufgrund von unserer Analyse von den Suchanfragen den Benutzer dahin schicken, wo das eher Sinn machen würde. Manchmal sind das halt die Detailseiten, manchmal sind das eher die Kategorienseiten. John, eine Zwischenfrage. Sollen wir denn die Produkte trotzdem in die Seit-Map aufnehmen oder wirklich so, wie ich es jetzt praktisch in der Frage formuliert habe? Ich würde möglichst alle Seiten in der Seit-Map aufnehmen, weil die Seit-Map-Datei dient in erster Linie dazu da, dass wir diese Seiten sauber crawlen können. Und das Ranking ist eigentlich dann eine Frage von der internen Struktur der Website, also wie sie innerhalb der Website verlinkt ist. Aber ich würde, wenn möglich, eigentlich immer alles in der Seit-Map-Datei aufnehmen, was alles, was indexiert werden sollte. Und Google sucht sich dann praktisch selber die URL, die dann angezeigt, die am besten passt dann praktisch. Genau, genau. Aufgrund von der Struktur innerhalb der Website versuchen wir da herauszufinden, wie das zusammenhängt. Also die Seit-Map-Datei hilft uns mit dem Crawling. Für das Crawling ist es aber auch sehr wichtig, dass wir einen Kontext der Website erkennen können. Das heißt, dass die internen Links da entsprechend vorhanden sind. Okay, alles klar, danke schön. Okay, da noch eine Frage im Chat. Eine offizielle Version für die doppelte XML-Seit-Maps. Wie groß ist das Problem, wenn überhaupt, also wenn gleiche URLs mehr in Seit-Maps vorhanden sind. Aus unserer Sicht ist das unproblematisch. Es ist höchstens ein bisschen schwierig, wenn wir unterschiedliche Informationen zu diesen URLs finden in verschiedenen Seit-Maps, vor allem wenn das Änderungsdatum zum Beispiel unterschiedlich ist in den einzelnen Seit-Maps. Weil dann wissen wir nicht genau, was es da eigentlich gemeint. Wenn die URL in mehreren Seit-Maps vorhanden ist, ist einem für sich sonst egal. Manchmal ist es ja auch so, dass man eine hrefleng-Seit-Map hat und eine, sagen wir, Standard-Seit-Map hat und so etwas ist für uns unproblematisch, weil dann können wir die hrefleng-Information aus der einen Seit-Map nehmen und die Änderungsdatum zum Beispiel aus der anderen Seit-Map und das kann man trotzdem kombinieren. Okay, danke. Okay, dann eine Frage zum Re-Launch und gleichzeitiger Umstellung auf HTTPS. Welche Variante man da am besten macht? Also zuerst von HTTPS auf HTTPS wechseln und dann Weiterleitung machen oder B zuerst die einzelnen URLs weiterleiten und dann standardmäßig von HTTPS auf HTTPS. Ich denke, beide von diesen Varianten sind schlussendlich etwa gleich. Ich würde bei einem Re-Launch, wenn man jetzt neue URLs dazu nimmt und eine Gesamtumstellung der Website macht, würde ich möglichst das in einem Schritt machen. Es gibt dann zwar, sagen wir mal, ein bisschen Schwankungen, bis das alles wieder sauber eintendelt, aber dann hat man diese Schwankungen hinter sich, dann hat man nicht einmal Schwankungen und dann ein Monat später nochmal Schwankungen, sondern hat man einfach einmal ein Monat lang Schwankungen. Ich weiß jetzt nicht, wie die Landesse bei den einzelnen Websites dann in Wirklichkeit dauert, aber man hat dann nur einmal diesen Lock von Schwankungen, die da dazukommen. Ich denke, bei einem Re-Launch ist es immer ein bisschen kritisch, weil oft ändert man ja verschiedene Sachen auf einer Website und da würde ich einfach wirklich ein bisschen Zeit einplanen, dass man das einerseits sauber technisch auch überprüft, bevor man diesen Re-Launch macht, dass man nicht die einzelnen Seiten vergisst, weiterzuleiten und andererseits, dass man es auf die Zeit einberechnet, wo diese Schwankungen stattfinden werden, damit man nicht unbedingt die Hauptzeit von der Website irgendwie beeinträchtigt. Also dann, wenn man wirklich den Suchtraffic braucht, sondern dass man eher vielleicht irgendwie die Sommerferien, wenn es weniger los ist im Sommer oder andere Zeiten im Jahr, nimmt für einen solchen Re-Launch, dass man diese Zeit mit weniger Suchtraffic gut überstehen kann. Das kürzlich in einem Hangout folgendes gesagt, bevor wir eine Website vom Desktop auf den Mobile First umstellen, vergleichen wir die Desktop-Links mit den Mobile-Links. Wenn die Links im Content und im Code nicht gleichwertig genug sind, wird die Website vermutlich noch nicht umgestellt. Und die Frage dazu, falls eine solche Website langfristig nicht anpasst, wie lange kann es dauern, bis sie schlussendlich trotzdem umgestellt werden? Gute Frage. Aus unserer Sicht ist die Umstellung auf Mobile First Indexing etwas längerfristig. Das heißt, wir nehmen an, dass das vielleicht ein Jahr oder länger, vielleicht zwei Jahre, drei Jahre dauert, bis wir wirklich alles umstellen können. Und wir stellen im ersten Schritt die Websites um, die eher unproblematisch sind, wo wir sehen können, dass wirklich alles zusammenpasst, wo wir sehen können, dass eine solche Umstellung keine Probleme verursacht. Und dann Schritt für Schritt versuchen wir da entsprechende Informationen für die Webmaster bereitzustellen, dass wir vielleicht auch Meldungen an die Webmaster schicken und wir einzelne Probleme erkennen können, die Webmaster auch beheben können. Und dann Schritt für Schritt versuchen wir da möglichst, dass alle wirklich auch bereit sind, dass wir die umstellen können. Das heißt, es ist nicht so, dass wir jetzt irgendwie ein Countdown gestartet haben und in sechs Monaten müssen alle umgestellt werden oder ansonsten stellen wir sie einfach trotzdem um. Sondern wir versuchen da, die Zeit zu nehmen, um das richtig zu machen und auch mit Webmastern das zusammen entsprechende Anpacken. Und wenn wir sehen, dass immer noch Probleme da sind, dann versuchen wir auch wirklich auf die Webmaster zu informieren, bevor wir da jetzt grob einiges umstellen. Ich denke, das macht für beide Seiten Sinn. Für uns ist natürlich auch wichtig, dass Inhalte nicht einfach verloren gehen. Nicht, dass wir sagen, wir stellen jetzt einfach um, weil wir denken, das ist die beste Lösung und deswegen verlieren wir, ich weiß nicht, wichtige Inhalte aus dem Index, weil sie nicht auf der mobilen Seite sind. Das wäre für beide Seiten eigentlich nicht optimal. Es sind Videos oder Bildergaralereien als Artikelbilden negativ für das Ranking bei Google News. Oder gibt es andere Nachteile. Für Google News weiß ich nicht, wie da das Ranking zusammengestellt wird. Das wird an und für sich separat gemacht. Das sind ein bisschen andere Algorithmen. Grundsätzlich für die Websuche ist das an und für sich egal. Es ist an und für sich euch überlassen, wie ihr das machen möchtet. Manche Seiten arbeiten viel mit Bildergaralereien. Manche Seiten arbeiten wenig mit Bildergaralereien. Das hängt ein bisschen von den Inhalten ab, was man dazu Verfügung hat. Wir redirecten bei einer Seite die User auf die Route URL anhand der IP-Adresse auf die jeweilige Country-Variante. Also von Domain-EN oder auf Domain-EN die Route Domain an sich ist für den User also nicht zu erreichen. Sollte man diesen redirect-Metals 301 oder 302 ausführen. Wir würden für so etwas ein 302 redirect empfehlen, weil der 302 redirect in der Regel nicht gekascht wird. 301 redirect kann gekascht werden. Das heißt, wenn jetzt Benutzer aus England zum Beispiel auf die Seite zugreifen, auf die englische Version weitergeleitet werden und die deutschen Benutzer auf die deutsche Seite weitergeleitet werden, dann wird mich dieser redirect irgendwo zwischengespeichert auf irgendeinem System bei euch oder sonst wo und immer wieder zurückgespielt für die nächsten Benutzer. Von dem her würden wir da eher ein 302 empfehlen. Aus unserer Sicht für SEO-Sicht ist es an für sich egal, wie ihr das ausführt. Was ich ja auf jeden Fall machen würde, ist diesen root URL auch in der hreflying-Datei aufnehmen als xdefault. Damit wir auch ganz klar wissen, dass das so eine automatisch weiterleitende Seite ist, die unter Umständen Benutzer auf verschiedene Varianten weiterleiten kann. Ansonsten, wenn kein xdefault dort angegeben ist, sehen wir wahrscheinlich nur den redirect auf die englische Version und dann denken wir, dass die root-Seite die englische Seite ist. Was in diesem Fall ja eigentlich nicht der Fall ist. Hat das noarchive tag ein Einfluss auf das Ranking? Nein. Das könnt ihr verwenden, wie ihr wollt. Manche Websites verwenden das überall. Manche Websites verwenden das überhaupt nicht. An und für sich betrifft das nur die digitärschte Ansicht. Von dem her könnt ihr das machen, wie ihr wollt. Ich habe eine Frage zu PWAs. Wir überlegen unsere Webseiten in PWAs umzuwandeln. PWAs sind progressive Web Apps. Das sind an und für sich so JavaScript-Applikationen, die relativ schnell laufen, die entsprechend auch recht brauchbar sind auf mobilen Geräten, unter Umständen, vielleicht auch Offline-Funktionalität haben. Die Frage geht weiter. Allerdings haben wir bei News-Webseiten das Problem, dass wir für mobile bis jetzt recht viel AMP-Traffic bekommen. Ich würde das jetzt nicht unbedingt als Problem nennen. Da PWAs ebenfalls sehr schnell laden sollten, gibt es zukünftig Pläne, die PWAs in den mobile AMP-Karousel aufzunehmen. Ich weiß nicht, was da die konkreten Pläne sind. Ich weiß von der AMP-Seite auf jeden Fall Pläne vorhanden, um andere schnelle, mobile Seiten entsprechend auch in solche Elemente aufzunehmen. Ich weiß nicht, was da der aktuelle Zustand ist, wie weit sie da vorwärts gemacht haben, aber das ist auf jeden Fall so die grobe Idee. Mit PWAs weiß ich nicht, ob das jetzt gezielt mit dem auch funktionieren wird. Es gibt verschiedene Arten von Webseiten, die einfach verschiedene Merkmale entsprechend wieder festgelegt worden sind für PWAs. Von dem her wird das wahrscheinlich nicht einfach für alle PWAs möglich sein. Was es aber auch gibt, ist die Möglichkeit, AMP plus PWAs zu kombinieren, so dass man die AMP-Seiten an und für sich indexieren lässt und dann runter um diesen AMP nur aufbaut. Das wäre vielleicht eine Variante hier, das würde ich vielleicht mal anschauen. Nächste Woche bei Google Iow bin ich ich glaube ziemlich sicher, dass da in diese Richtung auch irgendwelche Session da vorhanden sein werden. Also auf jeden Fall mehr zu AMP. Würde ich mal anschauen. Und da glaube ich wieder, dass ähnlich ist, wie vorher können Kinderartikel trotz Canonical Tag ranken. Bisschen anders. Also hier quasi ein Detail-Seite, die ein Canonical Tag hat auf eine Kategorien-Seite. Der Content ist 99% identisch, lediglich die Überschriften, natürlich der Preis sind unterschiedlich. Was wäre, wenn man die Canonical Tags weglassen würde? Wenn ich richtig verstehe, dann handelt es sich hier bei undukalter Content und die jeweilige Werte oder schlechter bewertet. Wergt sich duplicate Content nur auf die jeweilige Seite aus oder hat es einen Einfluss auf das Ranking anderer Seiten bzw. der kompletten Domain? Für uns in einer solchen Situation, ich habe jetzt nicht die Seiten genau angeschaut, aber wenn die Seiten ähnlich, aber nicht vollkommen identisch sind, würden wir wahrscheinlich beide Seiten indexieren. Also wenn jetzt kein Canonical Tag da wäre und würden versuchen, einfach die Seiten entsprechend zu ranken, je nachdem was gezeigt wird. Das heißt, wenn jemand nach etwas sucht, was auf beiden dieser Seiten vorhanden ist, also vielleicht in der Artikelbeschreibung und nicht jetzt in dieser Variante speziell, dann würden wir ein von diesen Seiten zeigen und wahrscheinlich die anderen entsprechend in den Suchergebnissen, weil wir wissen, das ist ja eigentlich das Gleiche, die gleichen Informationen, die da vorhanden sind. Und von dem her ist es nicht so, dass wir diese Seiten als duplicate Content abwerten würden oder schlechter behandeln würden. Wir würden einfach versuchen zu erkennen, welche Teile dupliziert sind und entsprechend die best passende Variante in den Suchergebnissen zu zeigen. Und anfühle sich ist das nicht Schlimmes. Also ich würde das jetzt nicht unbedingt beachten. Gerade wenn man Varianten hat, die man vielleicht einzelnen indexiert haben möchte. Jetzt in diesem Fall sieht das aus, dass es eigentlich so Plexiglasscheiben sind. Und dann gibt es natürlich schon fertige Plexiglasscheiben in einem speziellen Dicke und Größe. Wenn man natürlich sieht, dass der Benutzer gezielt, sag ich mal nach 3 mm Plexiglasscheiben sucht, dann könnte ich mir vorstellen, dass eine solche Variante, Produktvarianten Seite auch im Suchergebnissen Sinn machen würde. Wenn man hingegen sieht, dass niemand nach dieser Variante sucht, sondern eher nach Plexiglasscheiben im Allgemeinen, dann macht es wahrscheinlich weniger Sinn, dass man diese Varianten in den Suchergebnissen hat. Und von dem her muss man das wirklich auch einzeln, je nach Webseite auch anschauen und überlegen, wo macht es Sinn, dass man diese Varianten indexiert hat und wo macht es weniger Sinn, dass man diese Varianten indexiert hat. Und das kann innerhalb einer Webseite auch unterschiedlich sein. Dass man sagt, ich weiß nicht, für Plexiglasscheiben ist die Dicke sehr relevant für Holztraten, ist sie vielleicht weniger relevant. Weiß ich nicht. Würden denn diese Varianten praktisch diese, also die gesamten Produkte runterziehen? Also wenn man einfach, man hat jetzt 100 verschiedene Plexiglasscheiben in einer unterschiedlichen dicke und Google sieht das dann und würde das dann komplett die Seite auch ein bisschen abwerten oder nicht unbedingt abwerten, aber was natürlich passiert, wenn wir mehrere solche Seiten haben, die müssen für sich selber quasi ranken. Das heißt, wenn ich eine Seite nur für Plexiglasscheiben habe, dann ist die meistens ein bisschen stärker, als wenn ich diese Inhalte an für sich auf, vielleicht mal 100 verschiedene Variantenseiten aufteile. Also es ist nicht so, dass es abgewertet wird, sondern einfach dieser Inhaltewert entsprechend verteilt auf mehrere Seiten. Okay. Das heißt, da muss man sich schon ein bisschen überlegen, macht es wirklich Sinn, dass sie das aufteile? Da habe ich irgendein Mehrwert davon, wenn ich das aufteile und wenn kein eigentlicher Mehrwert besteht, dann würde ich schon eher versuchen, dass man das kombiniert und eine starke Hauptseite macht, oder sich vielleicht überlegt, kann man das kombinieren oder kopieren, dass ich vielleicht dünne Plexiglasscheiben und dicke Plexiglasscheiben separiere und dass man das so irgendwie macht, muss man halt wirklich von Fall zu Fall anschauen. Okay. Während einer Umstellung ist die Domain unter Entwicklungsumgebung kurzzeitig in den Index gekommen. Es handelt sich um eine exakte Kopie mit gleichen Inhalten wie die Live-Seite. Die Entwicklungsumgebung liegt auf einer Subdomain. Ich denke, das haben wir nicht die einzigen, die das schon gemacht haben. Das haben wahrscheinlich fast alle schon mal so geschafft. Seit einigen Wochen haben wir Ranking Verluste. Liegt ihr vermutlich nahe, dass die Entwicklungs-Web-Seite Dupletten erzeugt hat, welche mit der Live-Seite konkurrizieren und diese gar abwerten können? Eigentlich hätte ich das nicht geglaubt, da ich dachte, dass der Inhalt der Seiten, die zuerst indexiert oder entsprechend ein Vorrecht auf das Ranking haben. Noch zu wen parallel waren die Canonical-Tags der Kinderartikel auf der Live-Version falsch, also auf sich selbst statt auf die Vaterartikel gerichtet. In der Regel, wenn wir so eine Entwicklungsumgebung irgendwie finden und anfangen zu crawlen und indexieren, dann ist das weniger kritisch, weil wir haben sie zwar gefunden, aber sie hat ja eigentlich nicht die Signale von der Haupt-Web-Seite. Das heißt, wenn ich eine Seitabfrage mache, dann sieht man die vielleicht in den Suchergebnissen, aber meistens ist es nicht so, dass sie für die normalen Suchbegriffe irgendwo im Ranking auch erscheint. Trotzdem kann das natürlich immer irgendwie im Zwischenspiel geben, dass wir da auf einmal zwei Varianten finden und dass wir da nicht genau wissen, wie sollen wir diese Seiten ranken, wie gehören die zusammen und dass es da zumindest kurzfristig irgendwie vielleicht Schwierigkeiten gibt mit dem Erkennen von den relevanten Seiten. Und wenn dazu dann noch mit dem CanonicalTags irgendetwas grundsätzlich verändert wurde, dann kann ich mir schon vorstellen, dass da irgendwie ein paar Wochen lang Schwankungen geben würde in den Suchergebnissen. Ich habe vor einiger Zeit mal ein Google-Plus-Post gemacht über wie man so eine Entwicklungsumgebung am besten rausnehmen kann aus den Suchergebnissen. Wenn das jetzt kurz vorher bei euch passiert ist, würde ich das vielleicht mal raus suchen und mal schauen, ob man da irgendetwas noch machen muss. Ansonsten, wenn das schon länger her ist, dann habt ihr das wahrscheinlich berufen und dann ist es jetzt nur eine Frage der Zeit, bis sich alles wieder sauber einpendelt. Das andere ist aber natürlich auch, dass wir regelmäßig Änderungen machen in der Suche und es gibt regelmäßig Änderungen in unseren Algorithmen, in den Daten, die wir verwenden, auch in dem, was Benutzer erwarten von der Websuche. Das heißt, es können eigentlich immer Veränderungen im Ranking stattfinden. Das heißt, nur weil ihr etwas, sag ich mal, dann gemacht habt mit der Entwicklungsumgebung oder dann gesehen habt, heißt nicht unbedingt, dass es wegen dem auch ist, dass sie das Ranking der Website haben. Ich würde auf jeden Fall diese technischen Probleme mal sauber beseitigen, damit ich wenigstens sicher sei, dass es nicht mit diesen technischen Problemen zusammenhält. Dann eine Zwischenfrage zur Mobile Index Umstellung. Bekommt die Websites, die bereits jetzt umgestellt werden, ein Ranking Boost? Nein. Die Mobile First Indexing ist nicht eine Frage vom Ranking, sondern wirklich nur eine Frage vom Indexing. Das heißt, wo und wie wir die Inhalte der Website herausholen. Für Ranking ist dann eher, sag ich mal, der Mobile Friendly Algorithmus entsprechend dafür zuständig. Das heißt, wenn die Seite auch Mobile Friendly ist, dann können wir das in den Mobile-Suche-Ergebnissen ein bisschen besser ranken. Oder die Umstellung mit Mobile Speed, die jetzt in Juni kommt, kommt natürlich auch beim Ranking dazu. Aber nur die Umstellung selber auf Mobile First Index hat nichts mit dem Ranking zu tun. Da noch einige Fragen. Wenn eine Property gelöscht wird, dann irgendwann wieder neu erstellt hat, würde man wie bereits alte eingereichte Liste sehen. Ich weiß nicht genau, welche Liste. Du meinst, ah, die Dissevaliste wahrscheinlich. Ich glaube schon, es ist alte eingereichte Liste sehen. Irgendwo ist es ein Echo. Ja, ich glaube schon, wenn eine Dissevalliste eingereicht worden ist, dann kann die jeder Besitzer der Website über Search Console entsprechend einsehen. Wenn die Property gelöscht wird, werden auch die bereits für ungültige Erklärten links gelöscht. Nein. Angenommen einer Person verlässt das Unternehmen und hat eine Property angelegt und seinen Google Content gleichzeitig wurde dieses Konto eine Liste hochgeladen. Nun erstellt die neue Person die gleiche Property, bekommt er die bereits eingereichte Liste zu sehen. Ja, wenn man Zugriff hat auf Search Console, wenn die Seite verifiziert ist, dann hat man Einsicht auf die Liste der eingereichte Dissevalliste. Dann eine konkrete Frage zu verschiedenen Fachportalen und Ratgeber in denen wir User Feedback sammeln, also Bewertung der Content Qualität durch Abgabe der Sterne-Bewertung und diese dann als Rich Snippets auszeichnen. Unser Meinung nach zeichnen wir diese korrekt aus. Die Auszeichnung ist nun seit mehr als einem halben Jahr sein und wird leider in keinem unserer Fachportale in den Suchergebnissen gezeigt. Was machen wir da falsch? Wir hatten zu Beginn auch mal Auszeichnungen mit EachReview Aggregate drin, weil es bei den anderen Portalen so funktioniert hat. Wurde aber auch nicht mit Sternen angezeigt. Okay, grundsätzlich bei der Frage, wann wir Rich Snippets zeigen, gibt es eigentlich drei Faktoren, auf die wir hauptsächlich achten. Einerseits, ob das technisch sauber implementiert ist, also mit dem Test und passend zu unseren Vorlagen, ob das zusammenpasst, ob das wirklich aufgenommen wird. Andererseits, ob das auch sauber von der Art von Inhalt zusammenpasst. Das heißt, dass man nicht, sag ich mal, irgendein Buch mit Rezeptomarkup versieht, sondern dass das sauber gemäß unseren Richtlingen gemacht wird. Und drittens muss die Qualität der Website entsprechend einen gewissen Niveau erreicht haben. Und ich vermute jetzt hier, es klingt so, als ob ihr da technisch das sauber eingebaut habt. Ob das, sag ich mal, korrekt integriert ist, dass ihr die richtigen Sachen bewertet, weiß ich auf Anhieb jetzt nicht genau, sondern vielleicht anschauen. Also wichtig ist, dass man gerade bei Bewertungen, dass man quasi das Thema der Seite bewertet und nicht etwa den Inhalt der Seite, also nicht den Text, dass der bewertet wird, sondern dass wenn ich jetzt zum Beispiel eine Seite habe über irgendeinen speziellen Zahnarzt, dass man diesen Zahnarzt, dass man dafür die Bewertungen sammelt und nicht etwa für diesen Text auf dieser Seite. Man sieht man das zum Beispiel auf Blogpost so, dass der Blogpost eigentlich bewertet wird, aber sollte eigentlich betreffen dem Hauptthema von dieser Seite, sollte diese Bewertung eigentlich sein. Ich weiß, es ist jetzt ein bisschen unklar, wie das bei euch gemacht wird. Ich vermute, ihr macht da schon in dieser Insicht, dass ihr da, wenn ihr einen Steuerberater habt oder ein Zahnarzt, dass die Bewertungen für dieses Thema von der Seite gesammelt werden. Aber beziehungsweise der Qualität, das ist natürlich ein bisschen schwieriger zu bewerten. Manchmal sieht man das, wenn man eine Seitabfrage macht für ein Domain, dass wenn man da die Sternenbewertung sieht und in den normalen Suchergebnissen nicht sieht, ist das oft ein Zeichen dafür, dass unsere Qualitätsalgorithmen nicht ganz zufrieden sind mit der Website. Und ihr habt einige Themen, Portale quasi, erwähnt mit Eins und Domänen. Ich könnte mir schon vorstellen, dass da vielleicht das fast in Richtung, ich weiß nicht, Doorways-Sites ein bisschen geht, dass man da möglichst viele Varianten von Fairbank auf verschiedenen Domänen sammelt und da könnte ich mir schon vorstellen, dass unsere Qualitätsalgorithmen ein bisschen mühe haben mit solchen Arten von Zeiten. Aber ich würde das auf jeden Fall mit einer Seitabfrage mal anschauen und wirklich vielleicht auch mal überlegen, ob das vielleicht Sinn oder Erhebtes die Qualität von diesen Websites, wenn man die eher ein bisschen zusammenfügt. Das heißt, dass man weniger einzelne Websites hat über viele verschiedenen Themen, sondern wirklich eine starke Website, die insgesamt all diese Inhalte zusammen hat. Oder ob man das irgendwie anders kopieren kann oder ob es vielleicht andere Gründe geben könnte, warum unsere Qualitätsalgorithmen nicht ganz zufrieden sind mit diesen Inhalten auf diesen Seiten. Eine Frage zu ungewollten Video-Thumbnails in Snippets für Produkte-Seiten. Auf einigen unserer Produkte-Seiten sind Videos eingebunden, einerseits Hintergrund-Videos, die sofort abgespült werden, also Video mit Autoplay-Loop, andererseits Videos, die erst nach einem Click abgespült werden. Seit einigen Wochen sehen wir die Snippets für diese Produkte-Seiten ein Video-Thumbnail. Der Click-to-Rate hat sich hier durch ziemlich verschlechter. Wie kann man das unterdrücken? Ich würde gerne solche Beispiele URL sehen und Suchanfragen. Wenn du mir solche Sachen zuschicken kannst, dann kann ich die gerne an das Team weiterleiten. Ich habe das von zwei, drei anderen Personen auch neulich gehört. Beispiele sind auf jeden Fall da sehr hilfreich. Es gibt da verschiedene Sachen, die man machen könnte in so einer Situation. An und für sich versuchen, unsere Algorithmen festzustellen, dass Videos ein großer Teil von dieser Seite bilden und dass wir die entsprechend als Videos nicht darauf darstellen sollten. Das macht ja eigentlich in den meisten Fällen auch Sinn. Manchmal will man das aber trotzdem einfach nicht als Webmaster. Was man machen kann, ist entweder die Videoinhalte oder den Thumbnail, den man angibt, entsprechend per Robots Text zu lockieren, das Google, die diese Seiten nicht crawlen kann. Wenn wir die Inhalte nicht lockieren, also der Video Thumbnail oder die Video Datei selbst, dann können wir natürlich auch nicht das als Video einbinden mit dem Snippet. Das ist an für sich die beste Variante. Wichtig ist auch, dass man nicht eine Video Sidemap gleichzeitig erstellt. Wenn wir eine Video Sidemap sehen, denken wir automatisch, ja, gut, ihr wollt diese Videos im Vordergrund haben, also zeigt mir die auch im Vordergrund. Wenn ihr so etwas habt, würde ich das auch entsprechend vielleicht ausschalten für diese Seiten oder je nachdem wie ihr das eingebunden habt, dass man da zumindest die Seiten, die kein Thumbnail haben sollten, dass die entsprechend auch keine Video Sidemap dabei haben. Das sind an für sich die Hauptwege, die man da eingehen kann, um das ein bisschen zu selber in den Griff zu kriegen. Schwierig ist natürlich, wenn man jetzt zum Beispiel von YouTube oder Vimeo ein Video in Bad hat, dann sind solche natürlich nicht einfach per Robots Text zu blockieren, weil ihr könnt ja dann schlecht bei Vimeo oder so die Robots Text Datei verändern. Manchmal kann man das aber so machen, dass dieses Video zum Beispiel per JavaScript eingebunden wird und entsprechend die JavaScript Datei dann per Robots Text blockiert wird. Aber wie gesagt, man kann solche Beispiele auch mal sehen, damit wir in Zukunft das ein bisschen besser schon bei unseren Algorithmen in den Griff kriegen können und vielleicht, dass man da auch ein bisschen bessere Informationen für Webmaster bereitstellen kann für solche Situationen, damit wir das besser verstehen. Gibt es ein Crowd-Budget-Best-Practice für Rezension-Seiten oder viele Produktkategorien seit, wenn man sehr viele URLs hat, also 50.000 oder mehr. Also wir haben 10.000 Produktzeiten und ebenfalls 10.000 Rezension- Seiten und dann auch User Generated Content dazu. Wichtig ist, dass alle Seiten gekraut werden. Das Crowd-Budget soll natürlich nicht für Fragen oder Rezension aufgebraucht werden. Wie wäre in diesem Fall eine sinnvolle Sitemap-Craw- Budget? Ich würde behaupten, bei dieser Größenordnung von Seiten habt ihr kein Problem mit Crowd-Budget. Die meisten Web-Server, die meisten Hosting-Umgebungen sollten problemlos mit mehr als 100.000 URLs eigentlich gekraut werden können, ohne dass wir irgendwelche Probleme haben, dass wir uns einschränken müssen oder auf gewisse Seiten konzentrieren. Wenn wir uns trotzdem einschränken müssen, versuchen wir uns schon auf die Seiten zu konzentrieren, die entsprechend wichtiger erscheinen für eure Website aufgrund von diversen Kriterien, die wir intern zusammenstellen. Zum großen Teil hängt das damit zusammen, wie die Website intern verlinkt ist. Wenn zum Beispiel die Produkte Seiten eher höher an den Detail-Zeiten angeheftet sind, dann ist ja automatisch schon eine Struktur da, wo wir erkennen können, dass jetzt die Hauptzeiten, die Kapurien- Seiten, von dort aus sind die Hauptprodukte direkt sichtbar, und von dort aus können wir dann entsprechend weiter crowden, wenn wir noch mehr crowden möchten. Das heißt, an und für sich muss man in den meisten Fällen nichts gezielt machen, um auf Crowd-Budget Rücksicht zu nehmen. Einfach darauf achten würde, ist, dass ihr gerade bei einem Shop oder bei einem solchen System wirklich mit sauberen URLs arbeitet. Nicht, dass es dann noch 2-3 Varianten von jeder Rezension-Seite als URL gibt, die man auch irgendwie crowden könnte, dass das wirklich dann noch mehr explodiert. Oft sehen wir, dass wir vielleicht 5-20 Mal so viel crowden, wir effektiv indexieren von einer Webseite und das hängt in vielen Fällen einfach damit zusammen, dass keine saubere URL-Struktur vorhanden ist, dass wir da mit verschiedenen Parameter und Varianten entsprechend uns quasi bis uns unendliche crowden könnten und davon eigentlich nur ein klein Teil wirklich indexieren. Aber eben wenn ihr, sag ich mal, Micro 50.000 Seiten habt, 100.000 Seiten und eine einigermaßen saubere URL-Struktur habt, würde ich mir einen Crowd-Budget keine Sorgen machen. Wir werden nach 18 Jahren von Google bei den wichtigsten Suchbegriffen gerade Schritt für Schritt aus dem Index geworfen. Wir verfolgen jede gleichbare Richtlinie, sind Themenrelevant und die angefragten SEO Leute verstehen es nicht. Wir hatten für 4 Jahre ein Manual Penalty, den wir nach Vorschrift entfernt bekommen haben. Danach hat sich die Startseite nicht mehr im Index und seit dem 22. März trifft es die gesamte Website. Weiß ich nicht, was man da am besten machen müsste. Ich würde am 1. Mal im Webmaster-Hilfeforum nachfragen, dass da diejenigen, die im Hilfenforum sind, das auch mal anschauen können. Meistens ist es auch so, dass wenn Probleme dort erwähnt werden, die nicht irgendwie gelöst werden können, wo man nicht irgendwie eine Richtung finden kann, da werden die auch an Google Mitarbeiter weitergegeben, sodass wir das ein bisschen genauer anschauen können. In der Regel, wenn ihr vor 4 Jahren ein Manual Action hattet und das sauber aufgeräumt habt, sollte das keine Folgen von dem her haben. Das habt ihr aufgeräumt. Es ist nicht so, dass unsere Algorithmen da irgendwie, sag ich mal, ein Gefühl haben, dass da war vor 4 Jahren mal etwas falsch, dann müssen wir jetzt immer aufgeräumt sein, sondern wenn das aufgeräumt ist, ist es aufgeräumt. Was mir ein bisschen komisch erscheint ist, dass die Startseite danach nicht mehr in den Suche geben müssen war. Das würde aus meiner Sicht eher darauf hindeuten, dass irgendetwas technisches mit der Startseite vielleicht nicht ganz in Ordnung ist. Da würde ich vielleicht gezielt wirklich mal nachschauen, was mit dieser Startseite sein könnte, dass sie nicht in den Suche geben müssen erscheinen. Bezüglich dem Ranking allgemein von einer Webseite kann sich das natürlich verändern im Laufe der Zeit. Auch wenn technisch alles gleich bleibt, kann sich das auf jeden Fall verändern. Aber ich würde gerade aufgrund von diesem Problem mit der Startseite würde ich auch mal vom technischen Herd das mal gezielt anschauen und überlegen, ob da vielleicht irgendetwas verändert wurde in dieser Zeit, was dazu führt, dass einfach aus technischen Gründen diese Seiten indexiert werden. Was man auch machen kann ist, wenn man die älteren Daten hat in Search Console, dass man schaut, welche Seiten früher gerankt haben für einzelne Suchbegriffe und einfach kontrollieren, ob sie immer noch crawlbar sind, ob die immer noch vorhanden sind, ob die anfühlt sich sauber indexiert werden können. Eine Frage zu hreflang. Der Kunde hat mehrere ähnliche hreflang Anweisungen im Code, DEE Beide zeigen auf die gleiche URL. Ist das ein Problem oder geht das trotzdem? Aus unserer Sicht ist das vollkommen okay. Ihr könnt verschiedene Varianten auf die gleichen Seiten zeigen. Ihr könnt auch ein X-Default haben, welche auf die gleiche Seite zeigt. Das ist vollkommen okay. Das könnt ihr so machen. Eine Frage zur Priorisierung von Überschriften. Wenn die hreflang mehrere h1-Header vorhanden sind, gibt es dann irgendwie eine Priorisierung, haben beispielsweise die erste h1 ein höherer Stellungswert aus der 2. oder 3. Oder kommt es ausschließlich auf den Kontext an? Ja, kommt an für sich wirklich nur auf den Kontext an. Es ist nicht so, dass wir innerhalb einer html-Datei einzelne Elemente sind, weil gerade wenn sie es erst, kann man natürlich die Sichtbarkeit von diesen Elementen stark verändern. Das heißt, obwohl ein Element an erster Stelle in der html drin ist, heißt nicht unbedingt, dass das überhaupt sichtbar ist. Es könnte auch weiter unten auf der Seite sein, es könnte auch ganz unsichtbar sein auf einer Seite. Und von dem her versuchen wir da einfach den Kontext herauszufinden, wofür diese Überschrift gilt. Bei einem Kunden ist ein Dokument indexiert, welches Kategorie-Dockname als Fahrt besitzt. Dokument hat MetaRobots index Follow. In der Robots Text steht, dass die Kategorie blockiert ist. MetaRobots Robots Text widersprechen sich also, kann in manchen Situationen die direktive im Dokument die Anweisung der Robots Text außer Kraft setzen. Nein. Wenn etwas per Robots Text blockiert ist, dann crawlen wir die Seite gar nicht, dann sehen wir gar nicht, welche MetaTags auf dieser Seite sind. Und von dem her kann das dann auch entsprechend auch gar nichts außer Kraft setzen. Betrachtet Google das Title Attribut bei links, wir zählen, glaube ich, den Title als Teil vom Text der Seite zusammen. Man sieht das oft auch im Snippet, wenn ich es noch einmal versuche, dass da auch der Title entsprechend erwähnt wird. Wichtig ist der Title natürlich, vor allem auch in Situationen, wenn jemand mit einem Screenreader arbeitet, also wenn man den Inhalt der Seite nicht direkt sehen kann, sondern wenn der vorgelesen werden muss, dann hilft ein Title natürlich eher zu erkennen, wo muss man jetzt klicken, quasi damit man vorwärts kommt. Werden Textanzeigen als relevante Content bewertet? Ja, wenn Textanzeigen als Teil vom Inhalt erkannt werden, also wenn die vorhanden sind, wenn wir diese Seite crawlen und renderen, dann sehen wir das natürlich als Teil vom Inhalt an. Entsprechend auch, wenn links in diesen Textanzeigen sind, erwarten wir eigentlich, dass da auch mit dem Realm of Movalo gearbeitet wird, wenn wir dann anzeigen. Bezüglich der Relevanz dieser Inhalte sollte natürlich auch relevant sein, denke ich, aber wir unterscheiden da eigentlich nicht grob bezüglich wo diese Texte herkommen. Das heißt, wenn ein Text über eine Anzeige erscheint und so gerendert und indexiert werden kann oder wenn der Text einfach auf der Seite selbst ist, das ist aus unserer Sicht dann im Ende an für sich gleich. In vielen Fällen ist es natürlich so, dass diese Werbeblocks per Robots Text blockiert werden oder der JavaScript, der diese Werbeblocks erstellt werden, per Robots Text blockiert werden, damit man da vielleicht mal vom Clickthrough Rate für die Werbung besser bezahlen hat, also wenn man jetzt jeden Crawl auch noch dazu zählen würde. In manchen Fällen sind diese Werbeblocks aber nicht per Robots Text blockiert und dann könnten wir sie unter Umständen auch indexieren. Wären wir noch links verfolgt, also bei uns passiert das so, wir benutzen Google AdWords und da kann man in Google AdWords eine URL angeben und meistens ist das jetzt so bei uns, dass es diese URL gar nicht gibt, sondern es ist einfach nur so ein Click-Anreiz. Jetzt haben wir manchmal in den Webmaster-Tool eine 404-Seite also dann folgt Google praktisch diesen Link. Wenn wir diesen Link sehen, dann können wir ihn zufolgen. Aber wenn der natürlich auf eine 404-Seite führt, ist das auch okay. Es gibt ja dann nichts Neues, was wir da indexieren können, sondern wir sehen ja dann sofort, dass dieser Link führt nirgendwo hin, können wir ignorieren. Okay, weiter geht es mit Etraflank. Zur Situation, es besteht ein gleichlautender spanischer redaktioneller Inhalt auf zwei verschiedenen Domains, also .com, .es und .es und dann auch Artikelname zum Beispiel. Domainausrichtung in Search Console ist auf Spanien. Etraflank Auszeichnende beiden URLs deutet auch darauf hin, dass auf Span, also nur es, also nur spanisch, ist .com, .es und es Binde, .es, also für Spanien ist auf .es Domain. Ich weiß jetzt nicht, ob das irgendwie verständlich ist, wenn man das so vorliest. .com Also ich weiß es ist leider ein ziemlich kompliziertes komplizierter Aufbau, das ist sehr schlecht, ohne das zu sehen zu erkennen, aber mach es mal weiter bitte, danke schön. Okay, .com ist die stärkere Domain, mehr Backlinks, mehr Bekanntheit. Die erwartete Variante wäre laut Etraflank das Nutzer aus Spanien de .es Variante sehen werden und andere Nutzer auf Spanisch quasi die .com. In der Realität erscheinen für Nutzer in Spanien beide Domains Suchergebnisse .com, aber vor.es Übersteuere hier andere Algorithmusanteile die Etraflank Steuerung oder mach ich da lediglich ein Denkfehler an und für sich wäre das so korrekt ich bin jetzt nicht ganz sicher ob es wirklich der Code ist für Spanien oder ob etwas anders verwendet wird, aber was was mir eine meiner nach ein bisschen auf ein Problem hindeutet ist, dass wenn beide Seiten effektiv erscheinen in den Suchergebnissen dann würde das darauf hindeuten, dass wir diesen Etraflank Code nicht sauber verarbeiten können. Das kann sein, dass wir ihn auf der Seite nicht sauber einlesen können, also wichtig ist, gerade beim hreflank, dass er im Heldbereich ist der Seite nach dem Rendern dieser Seite oder dass wir aus irgendeinem anderen Grund das nicht sauber verarbeiten können. So gibt es keine Hinweise darauf, dass irgendwelche Fehler oder sowas vorliegen würden, das muss dann aber in dem Fall auch nicht immer sein. Ja, wenn wir zum Beispiel den Etraflank bei beiden dieser Seiten nicht sauber erkennen können, dann ist es aus unserer Sicht kein Fehler, sondern es ist quasi wie kein Etraflank ist da vorhanden. Wenn wir ihn auf einer Seite sehen können und nicht auf der anderen Seite zurück bestätigt sehen würden, dann wäre das etwas, was wir in Search Console entsprechend erwähnen könnten, weil dann sehen wir, da ist es vorhanden und da ist dieser Link zurück, nicht vorhanden. Wenn man auf einer anderen Seite nicht erkannt wird, dann würden wir das auch nicht als Fehler zeigen. Was ich manchmal gesehen habe ist, dass man mit anderen JavaScript auch arbeitet auf der Seite, der unter Umständen im Held vor dem Etraflank weitere Elemente einfügt. Und das würde aus unserer Sicht dann bedeuten, dass wir dieser Etraflank Link dann nicht mehr relevant ist, weil er nicht im richtigen Ort ist von der Seite. Und dementsprechend würden wir den ignorieren. Man kann das testen mit dem Rich Results Test, der eigentlich dafür gedacht ist, dass man zum Beispiel Sternbewertung oder Rezeptkarten testet. Dort kann man diese URLs einfügen und dann den HTML Source anschauen. Das ist der Source, der nach dem Rendern erstellt wurde, den wir auch verwenden für das Indexing. Und dort sieht man dann meistens ist das relativ klar, ob da jetzt noch weitere Inhalte oberhalb vom Etraflank vorhanden sind oder nicht. Okay. Also wenn, dann sollte der Etraflank wirklich leicht nach dem öffnen Headhack in einer Weise da sein, damit ihr das besser verarbeiten könnt. Genau. Und probieren wir es mal so. Vielen Dank. Ich habe irgendwo ein Beispiel habe ich noch eine Frage. Okay. Vielleicht habe ich nachher noch kurz Zeit. Alles gut. Danke. Ich versuche das nachher vielleicht noch bei Google Cloud einfach separat noch dazu rein pausen. Vielen Dank. Ja, ich sehe gerade, wir sind schon bei 2 Uhr und wahrscheinlich kommt jetzt gleich jemand um das Zimmer zu nehmen. Von dem her müssen wir jetzt an für sich mal kommen. Ich bedanke mich bei euch für die vielen Fragen fürs KOM und hoffe wir sehen uns in einem der nächsten Hangouts wieder. Tschüss allerseits. Tschüss. Tschüss.