 OK, herzlich willkommen beim heutigen Webmaster Essentials Brechstunden Hangout. Mein Name ist Johannes Müller. Ich bin Webmaster Trends Analyst bei Google in der Schweiz. Und Teil von dem, was wir machen, sind solche Webmaster Hangouts, wo jeder dazustoßen kann und seine Fragen rund um seine Website und um die Google suchen stellen kann. Es sind da schon einige Sachen, die eingereicht worden sind auf YouTube, aber wenn wir schon so viele hier haben, vielleicht hat einer von euch irgendwas, womit ihr anfangen möchtet. Ich hatte tatsächlich direkt das. OK, ich mache zuerst. Ich mache zuerst die Fragen. Genau, ich habe eine Frage. Und zwar geht es um Anzahl ULs. Wir sind ein Online-Shop mit ca. 1 Million Produkten. Und die sind auch für Google noch mal zugänglich. Und die Produktvarianten davon aber. Also zum Beispiel ein Shirt in blau und größe M. Die sind über ein UL-Fragment gelöst. So dass die Inhalte eigentlich als kleinseitig nachgeladen werden. Und das heißt, die einzelnen Varianten, die sind eben, was dann auch viel mehr wären, das wären nicht eine Million, sondern eher so 3 bis 5 Millionen, also für 5 Facht. Die sind dann nicht als eigen UL für Google zugänglich. Und jetzt kam die Idee auf, die Varianten über ein Parameterzugänglich zu machen. Und das würde ja aus Google sich bedeuten. Man hätte viel mehr ULs, die gecrawled werden müssen, die auch zugänglich wären. Wovon wir aber jetzt schon aus unserer Perspektive eigentlich 90 bis 95% das nicht relevant klassifizieren würden. Und wir sind jetzt der Meinung, wir würden eigentlich damit das effiziente Crawling und vor allem auch das Verhältnis von relevanten zu irrelevanten Seiten stark verschlechtern damit. Siehst du das Risiko auch oder hast du noch Gründe, die für eine Umstellung auf dem Parameter sprechen würden? Ja, ich denke bei der Größenordnung macht es schon Sinn, dass man sich darüber gedanken macht. Quasi wie Google die Seiten crawlen kann, wie schnell die auch aktualisiert werden können. Das heißt, wenn ihr jetzt ein Produkt der Änderung macht, müssen wir die Seiten dann alle neu crawlen, müssen wir das alles neu finden. Und je mehr Varianten ihr habt von den gleichen Produkten, umso mehr separate URLs müssen wir crawlen. Das heißt, von der Crawl-Geschwindigkeit her, denke ich, so sage ich mal, ab eine Million, 10 Millionen Größenordnung macht Sinn, dass man sich da ein bisschen Gedanken macht, wie kann man das effizient machen und wie kann man das so steuern, dass Google quasi die relevanten Sachen trotzdem noch findet. Es kann durchaus sein, dass bei euch genug gecrawled wird, dass es trotzdem funktioniert. Das seht ihr einigermaßen bei den Crawl-Statistiken, auch in den Server-Logs. Das hängt ein bisschen von der Website ab. Das heißt, wir versuchen ja zu steuern, wie viel wir crawlen, einerseits von dem, wovon wir erwarten würden, was der Server verträgt. Das heißt, ob einigermaßen noch schneller reagiert, ob Server-Fehler zurückgibt, wenn wir mehr crawlen. Wenn das alles soweit okay ist, dann wenn wir einen Bedarf haben für mehr URLs, dann versuchen wir die auch mehr zu crawlen. Das heißt, da kann man wahrscheinlich, wenn sich da schon einigermaßen eingependelt hat bei so vielen URLs, kann man da ein bisschen abschätzen, hätten wir die Möglichkeit, noch mehr URLs crawlen zu lassen oder sind wir da eh schon quasi am unteren LinkedIn, dass Google, ich weiß nicht, jetzt 10% der Website im Monat crawlt und dann, wenn wir das Ganze verzehnfachen, dann stehen wir dann noch schlechter da. Für mich wäre auch so die Frage der Qualität. Wenn wir jetzt von diesen einigen Produkten auf den Verdreifahrung gehen von URLs, das was dazu käme, würden wir also wirklich nicht indexieren, weil es halt den Nähwert einfach nicht hat. Da ist so die Frage für mich, Domain-Qualität. Man gibt viel mehr dann sozusagen frei, was Google sich anguckt, ist aber auf noindex, bringt man ja dann auch nichts, ob das eventuell einen negativen Effekt hätte. Wenn es auf noindex ist, ist das kein Problem. Dann spielt das wirklich nicht in die Qualitätsbeurteilung, weil das sind ja dann Sachen, die würden, wenn ich in den Suchergebnissen zeige und von dem her spielt das da eigentlich keine Rolle. Wo man vielleicht auch noch einen Einfluss hat oder wo vielleicht noch etwas dazu kommen würde, ist in Richtung Product Search. Ich weiß nicht, ob ihr da irgendwas macht mit dem Merchant Center, solche Sachen. Ich weiß nicht, wie es da gehandhabt ist, wenn man in verschiedenen Produktvarianten hat, ob man die über eigene URLs haben muss oder nicht. Je nachdem macht es vielleicht Sinn, dass man das auch mal anschaut und überlegt, spielt das eine Rolle für uns oder können wir das ganz ignorieren? Ja, das weiß ich nicht. Okay, aber eher Fokus auf das Crawling und lasse sich noch mal anzugucken. Okay, super, danke dir. Ja, bitte. Ich hätte dann noch eine Frage. Okay. Die hatte ich auch schon eingereicht, aber es ist ein dringlicheres Thema. Wir sitzen da schon seit Wochen dran oder seit Monaten dran, einen Haufen URLs reinzubekommen. Wir hatten erst eine Schwierigkeit mit den Sidemaps. Jetzt haben wir das mit den Sidemaps eingereicht. Google sagt auch, dass sie rund 800.000 Links über die Sidemaps erfasst haben. Die sind aber alle auf Discovered Currently Not Index. Und der Punkt ist halt, dass dann halt 20 bis 100 Links pro Woche dann mal überhaupt gekrawlt werden. Und das ist halt ein bisschen schwierig, weil wenn das dann so weitergeht, brauchen wir halt 21 Jahre, nur um die aktuellen Links zu crawlen. Das sollte so nicht sein. Das sollte kein Zustand sein. Was können wir machen, um das irgendwie zu verbessern? Ja. Ich habe euch deiner Seite vorhin kurz angeschaut, dass die 3D-Finded Genau, 3D-Finded.com, genau. So was ich da gesehen habe, ist es nicht so, dass es aus technischen Gründen irgendwie langsamer ist, sondern es ist effektiv einfach so, dass unsere Systeme noch nicht 100%ig überzeugt sind, dass es sich lohnt so vieler, so eine Menge von URLs noch dazu zu crawlen. Und da macht es manchmal Sinn, dass man erst mal mit einer kleineren Menge anfängt und dass man quasi von einem wirklich sehr guten Stamm aus anfängt und das dann lange Schritt für Schritt erweitert. Man kann das natürlich auch so machen, wie ihr da habt, dass wir da quasi erst mal 800.000 URLs finden und dann im Laufe der Zeit merken wir, das ist eigentlich ein sehr toller Website, die müssen wir ein bisschen besser indexieren, ein bisschen besser in den Suchergebnissen präsentieren. Aber das ist quasi so der Moment, wo unsere Systeme einfach ein bisschen eher zurückhaltender sind und sagen, wir sehen, das sind sehr viele URLs, wir könnten die crawlen. Es ist nicht so, dass wir da aus technischen Gründen beschränkt sind, sondern wir sind einfach noch nicht 100%ig sicher, um diese URLs zu indexieren. Gerade bei einer so großen Menge kann es natürlich sein, dass unsere Systeme auch ein bisschen abwägen, ja, wo würden wir das überhaupt zeigen in den Suchergebnissen. Und wenn sie indexiert werden und gar nicht gezeigt werden, dann bringt das ja eigentlich auch nicht wahnsinnig viel. John, hallo, ich gehöre da dazu, deswegen auf meine Frage, das heißt, wir sollten erst mal hochwertigen Content reintun und dann kriegen wir natürlich wahrscheinlich Clicks von Google und dann sagt Google, die Seite ist mehr wert und es ist quasi wie so ein Atonado, der sich nach oben schraubt oder wenn ich die richtig verstehe. Ja, also ich würde jetzt nicht unbedingt auf Clicks von Google achten, aber einfach allgemein, wenn ich eure Website angeschaut habe, ich weiß nicht, ob das stimmt, ihr habt größtendurch im Januar angefangen, stimmt das? Ja, gut, wir haben die Domäne nochmal umbenannt. Wir hatten so ein Wortspiel mit IT und viele haben es für eine italienische Seite gehalten, deswegen haben wir sie dann internationalisiert und haben dann vor ein paar Wochen eigentlich nochmal den neuen Domänen quasi gestattet, deswegen ist, sag ich mal, die Domäne seit Januar online. Okay, weil was ich da einfach machen würde in einem solchen Fall ist wirklich schauen, dass man das vielleicht auch über andere Wege außerhalb einer Google-Suche ein bisschen bekannter machen kann, so dass ihr irgendwie die ganzen Signale rund um eure Website ein bisschen besser aufbauen könnt. Dass es mehr Leute gibt, die die Website weiter empfehlen, dass es vielleicht einige Links mehr gibt zu eurer Website. Einfach, dass wir insgesamt einfach ein Bild von eurer Website haben, wo wir wirklich denken, Mensch, da müssen wir einfach viel mehr indexieren von dieser Website. Also, wenn ich dich gerade richtig verstanden habe, damit ich auch da nochmal gerade, also wir hatten ja auch schon mal mit kleineren Content versucht, nur so 10.000 Seiten da, also 10.000 Links da hat es ja auch leider nicht richtig funktioniert. Deswegen, aber wenn wir jetzt zum Beispiel sagen, okay, wir würden nochmal runtergehen auf 10.000 Links, erst mal, die sind aber dafür sehr, sehr high quality und sind vielleicht auch Links, die in irgendwelchen News-Portalen vielleicht vorkommen oder in irgendwelchen Forum vorkommen oder ähnliches, das würde erst mal das Ganze steigern, damit wir da schneller vorankommen mit den Coren. Ich denke quasi, die Seiten einfach zu entfernen oder auf Nouindex setzen, bringt wahrscheinlich jetzt in dem Moment nichts. Ich würde da einfach quasi vorwärts arbeiten und denken jetzt mit euren 800.000 Seiten, die ihr quasi habt, in der Seitenapp, dass ihr einfach mit denen anfängt weiter zu arbeiten. Hast du vielleicht gezielt einzelne Inhaltsstücke noch dazu nehmen, wo ihr wisst, ihr habt technisches Wissen über dieses Thema, ihr könnt euch wirklich gut aus, das sind Themen, die vielleicht von anderen auch angesprochen werden, wo sie vielleicht auf eure Seiten dann auch verlinken würden und dann einfach Schritt für Schritt das, was ihr habt, einfach ein bisschen verstärken. Das heißt nicht unbedingt zurückschrauben erst einmal, sondern wirklich einfach halt vorwärts. Noch zwei kurze Fragen. Das eine ist, wir haben es natürlich jetzt mobil optimiert, sag ich mal mehr Informationen mobil drinnen, das heißt, es wird aber auch schon diese mobile Optimierung schon eigentlich auch wahrgenommen. Oder sagst du, wir sollten eher auf die Desktop-Variante mehr Informationen reinbringen. Ich habe jetzt nicht nachgeschaut, ob ihr mit Mobile First Indexing schon indexiert wird, aber ich denke, insgesamt sind ja sehr viele Leute mit Mobilgeräten unterwegs. Das würde ich jetzt nicht auf Desktop zurückstellen. Das ist die erste Frage, die zweite Frage, die AR-Thema. Google möchte ja auch AR stärker reinbringen. Wir hätten natürlich fast für allen Content ein schönes AR-Modell. Wie weit wird Google, sag ich mal, das jetzt so in den nächsten Wochen pushen? Also diese 3D-Modelle in den Suchergebnissen? Ja, augmented reality, ja. Ich weiß nicht, wie weit das jetzt in den nächsten Wochen quasi vermehrt gepusht wird. Das ist auch etwas, wo aus unseren Systemen her, wenn wir anfangen würden, eure Inhalte zu zeigen in dieser 3D-Modus in Suchergebnissen, dann ist es nicht unbedingt der Fall, dass wir dann mehr indexieren würden, sondern wir würden quasi den indexierten Bestand nehmen und da die Modelle herausnehmen, die wir als Vorschaubild quasi so zeigen könnten. Ich weiß auch nicht, wie moment der Zustand ist von diesen Modellen in den Suchergebnissen. Ich weiß, die sind am Arbeiten dran, aber wie bald das kommen wird, dass dann auch europäische und deutsche Websites so dargestellt werden, das ist immer ein bisschen kritisch. Ja, das hatte ich ja schon mal, dass die 3D-Modelle werden, ja, da muss man sich registrieren für bei Google. Das hatten wir auch gemacht. Wir haben bisher nur keine Rückmeldung bekommen, also weder abgelehnt noch zugestimmt. Da stehen wir ein bisschen in der Schweibe. Das ist so unser Punkt dabei, weil das wäre natürlich halt auch im Zuge dessen natürlich noch praktisch, wenn man das auch gleich mit anbieten kann. Ja, das ist gerade mit den speziellen Darstellungsarten in den Suchergebnissen, ist manchmal ein bisschen kritischer mit europäischen Websites. Aber was ich da wirklich machen würde, ist einfach überlegen, wie könnt ihr euch ein bisschen besser positionieren, sodass andere quasi eure Website insgesamt anschauen würden und sagen, da sind jetzt super tolle Artikel dabei, das sind super tolle Inhaltsstücke dabei. Das ist nicht nur eine Sammlung von irgendwelchen 3D-Modellen, sondern da ist wirklich etwas gezielt, was man weiter empfehlen könnte. Hier, alles klar? Dann darf ich mal fragen, habt ihr alle Modelle drin? Also, wollt ihr wirklich alle Modelle rein in den Index bekommen? Wir wollen so viele wie möglich auf jeden Fall in den Index bekommen, weil wir sehr speziell Scherkattmodelle anbieten, also 3D-Modelle für Cut-Bau-Systeme. Und ist das nicht wieder so ein Problem mit diesen Produktvarianten wie im Online-Shop eigentlich? Die Produktvarianten sind dann noch nicht bei, also das sind jetzt wirklich nur die Basisstücke. Okay, alles klar. Also keine Konfigurationen? Genau. Das ist immer ein bisschen schwierig, wenn man so am Aufbauen ist von so einem großen Inhaltssammlung. Ihr habt auch wenig Fließtext auf den Seiten, kann das sein? Nein, kein Text, sondern nur so Datentabellen und so, also so einen richtigen Text. Habt ihr nicht dazu, wie viel man da mehr sehen kann oder was das genauer ist oder ich weiß nicht, ob man so was dafür machen kann, um sich das anbietet. Ja, gut, in den technischen Parametern wird natürlich gesucht. Die technischen Parameter sind das Wichtigste. Wir könnten ein bisschen Fließtext natürlich reinmachen, was wir begonnen haben ist, wir haben natürlich, zum Beispiel kannst du jetzt das Steckdose und dann gibt es verschiedene Anbieter, dann kommen natürlich viele verschiedene Brands und viele Informationen. Das haben wir anfangs eigentlich versucht zu indexieren, so quasi als hochwertigen Content, weil da unheimlich viele Texte dabei sind, sind aber dann eben auf diese 800.000 Seiten gegangen und in den 800.000 Seiten ist natürlich, wenn einer XYZ123 sucht, dann braucht er das auch dringend, aber diese Suche kommt natürlich alle fünf Jahre mal irgendwo vor. Ja, das heißt, die Einzelteile, die gesucht werden, sind schon sehr, sehr nischig eher, sehr langtäglich. Die sind sehr nischig, aber wir haben natürlich bestimmt sagen wir 20, 30, 40.000 Schlagwörter, die dann multipliziert mit zehn Sprachen, die dann schon gängig sind, wie ein Stecker in 3D oder ein Steckdose in 3D sucht, jetzt vielleicht einer der, der sogar irgendwo 3D Printing hat, aber natürlich auch im B2B-Bereich. Ja, vielleicht macht es dann Sinn, noch mehr zu clustern, die noch mehr zu gruppen zusammenzufassen. Ihr weiß es nicht. Das war eben die Frage. Das hatte ich unter hochwertigen Content und hat mein Kollege auch gemeint. Ich glaube, das ist an dieser Stelle, dass wir eher wieder auf hochwertiger gehen und dann kriegen wir wahrscheinlich mehr Clicks, dann sieht Google das auch als interessanter an und dann sehen Sie vielleicht auch die nächsten 10.000 oder 20.000 Seiten. Ja, also ich denke, gerade mit so Kategorien und Gruppierungen könnte man wahrscheinlich schon einiges machen, dass man da auch ein bisschen diese Kategorie-Seiten oder ich weiß nicht, die Marken oder die verschiedenen Gruppierungen, die ihr habt, dass man die ein bisschen besser hervorheben könnte, zum Beispiel auf der Homepage, dass das direkt verlinkt wird dort so, dass man ein bisschen wenigstens die Teile auch ein bisschen besser präsentieren kann in der Suche. Wo man auch einigermaßen vielleicht nachschauen kann, dass sind Sachen, wo nach Leute suchen. Das heißt, wenn ich das gut präsentieren kann innerhalb von einer Website, dann bin ich schon mal ein bisschen dabei. Auch wenn dann nicht die einzelnen Produkte oder die einzelnen Modelle quasi direkt in Suchergebnisse sind, ist dann doch diese Sammlung an, ich weiß nicht, Fenster von dieser Marke oder was auch immer, ist das einigermaßen auffindbar. Ich könnte mir auch vorstellen mit den ganzen Sprachvarianten, dass man es sich da auch noch ein bisschen schwieriger macht. Wenn ihr quasi so viele Sprachvarianten habt und nicht alle Varianten wirklich gebraucht werden von Benutzern, dann multipliziert sich natürlich die Anzahlseiten automatisch. Da lohnt es sich manchmal auch zu sagen, wir konzentrieren uns auf eine Sprache und bauen das erstmal gut auf. Und wenn wir sehen, dass wir Benutzer aus anderen Ländern haben, die oft genug kommen, dann nehmen wir noch die anderen Sprachvarianten dazu. Eine andere Sache, die man auch machen könnte, wahrscheinlich gerade in Richtung Text auf den einzelnen Seiten, dass man da vielleicht auch mehr Richtung User Generated Content vielleicht auf den einzelnen Kategorien Seiten oder auf den einzelnen Modellseiten, dann weiß ich Bewertungen oder Kommentare oder solche Sachen noch dazu nehmen könnte, sodass ihr nicht all die Inhaltsstücke aufbauen müsst, sondern dass die Benutzer, die im Laufe der Zeit halt zu euch kommen, dass die, dass er dann für euch oder mit euch zusammen helfen, das Ganze aufzubauen. Ja, das klingt auf jeden Fall durchaus sinnig. Dann muss man gucken, eine Frage habe ich da jetzt noch im Anschluss, weil das ist passend grad dazu, weil du gesagt hast, Sprachen. Also es ist so, wir bringen jetzt nicht zum Beispiel, wir gehen jetzt googeln nicht zum Beispiel, sagen wir eine Schraube und sagen, okay, das ist die Schraube und dann haben wir jetzt noch 50 Varianten, also nicht 50, 10 Varianten an Sprachlings, die haben wir dann auch aufgelistet, sondern wir sagen, okay, das ist die Schraube und es gibt halt dieses Language-Kanonica-Mannich. Das haben wir halt eingebunden. Es ist also sinnig, auf zu sagen, okay, vielleicht wir nehmen jetzt davon was raus und sagen, okay, also von den Language-Kanonicas raus und sagen, okay, Google soll erstmal nur die normalen Seiten, zum Beispiel nur die deutsche und die englische oder sowas crawlen und schauen, das es passt und dann können wir wieder die Sprachen dazu nehmen, Google findet die dann oder... Wie habt ihr das eingebunden mit dem Sprachen im Moment? Ist es mit Edge of Lang oder sind das... Edge of Lang, genau. So haben wir das eingebunden. Also, wir geben Google nicht jeden Link einzeln, sondern wir geben zum Beispiel Google ein Link von einer Schraube und da steht halt im Edge of Lang Kanonica drin, zum Beispiel Chinesisch, Englisch, Französisch, Italienisch. Okay. Wahrscheinlich sehen wir da auch die einzelnen Sprach-Version dort auch und versuchen die dann auch zu crawlen und zu indexieren. Und da würde es sich wahrscheinlich auch lohnen, dass man sagt, gut, wir konzentrieren uns eher jetzt mal auf eine Sprache, oder vielleicht auf zwei, je nachdem, wo ihr halt seht, wo die meisten Benutzer auf eurer Website kommen und dass man das dann erstmal so wirklich stark aufbaut und dann man hier sieht, dass ein Großteil der Seiten indexiert sind, dann noch die weiteren Sprachvarianten dazu nehmen. Oder dass man halt sagt, für die wichtigeren Seiten habe ich Sprachvarianten, zum Beispiel für die Homepage, die Kategorien, die größeren Gruppierungen und für die einzelnen Produkte habe ich einfach, sag ich mal, die englische Variante oder irgendeine Variante indexiert. Das heißt, wenn jemand gezielt nach einem einzelnen Produkt sucht, dann kommt man halt auf eine Sprachvariante, aber man kann da immer noch umstellen, wenn man will, aber die, sag ich mal, die wichtigeren Seiten, wo wahrscheinlich mehr Leute nachsuchen würden, die sind dann in den verschiedenen Sprachen vorhanden. Okay. John, mal noch eine Abschlussregel von meinerseits. Gebt dir auch Tipps weiter, sag ich mal, vielleicht einfach so ein externen Berater, dass wir mal einfach dazu holen oder vielleicht ist hier einer, der darf mich gerne unter LinkedIn oder Jürgen Heimbach gerne kontaktieren und wenn er einfach Tipps hat und wo man einfach externe Beratung kaufen könnte. Da gibt es so viele Leute, die das wahrscheinlich gerne machen würden. Von unsererseits haben wir keine Empfehlungen, dass wir sagen, die sind besonders gut oder die sind besonders gut. Es gibt aber wahrscheinlich werden sich da jetzt schon einige bei euch melden. Es gibt viele, die gerade mit größeren Websites, mit E-Commerce vielleicht oder die in Richtung internationaler Websites arbeiten. Da ist manchmal einfach auch eine kleine Zeit nötig, um wirklich viel Information weiterzugeben. Aber kann ich natürlich nicht für die einzelnen Personen sprechen. Okay, also der Aufruf, wenn einer eine Idee hat, kann er uns gerne kontaktieren. Ihr findet mich unter meinem Namen Jürgen Heimbach unter LinkedIn. Danke, John. Ja, bitte. Vielen Dank. Ich hätte eine Frage, John. Die bezieht sich auch auf eine YouTube-Frage von Franz Wetter. Und zwar haben wir in der Google Search-Konsol das Problem in den Leistungsberichten. Wir haben zwei Properties hinterlegt. Einmal die WWW-Variante und einmal die M-Punkt-Variante, da wir noch nicht komplett mobile responsive sind. Aber die gesamten Daten, es sieht so aus, als würden sie nur in die WWW-Property einfließen. Und GA36, die zeigt aber, wir haben 70% reinen Traffic mobile. Gibt es da ein Grund beziehungsweise wie kann ich das verargumentieren, warum die Daten nur in die WWW-Property fließen und nicht in die M-Punkt? Wahrscheinlich ist die Webseite noch nicht auf Mobile First Indexing umgestellt. Leider ja. Ja, das heißt, was passiert in Search-Konsol ist, wir versuchen den Canonical von den einzelnen URLs zu finden und versuchen da die Daten abzulegen. Das heißt, im Moment wird das wahrscheinlich die WWW-Variante sein, als Canonical. Und selbst wenn jemand auf Mobile sucht und den M-Punkt URL sieht in den Suchergebnissen draufklickt, wird das unter der WWW-Variante abgespeichert. Es ist nicht ganz hundertprozentig immer der Fall, es gibt da einzelne Ausnahmen, wo wir das dann trotzdem unter der M-Punkt-Variante abspeichern. Aber für den Großteil wird das so sein, dass es unter WWW ist. Und dann wenn das Indexing passiert, dann wird das auf die M-Punkt-Variante wechseln. Was ich da empfehlen würde, ist, dass man die Domain-Property verifiziert in Search-Konsol. Dann hat man nämlich dieses Problem nicht mehr, weil dann haben wir die ganzen Daten vom gesamten Domain einfach direkt in Search-Konsol. Das heißt, für den Performance-Report, für die Indexierung ist dann in beiden Fällen, zusammennehmen und dann hat man eine Grafik und wenn das umstellt auf Mobile First Indexing irgendwann, dann ist es nicht so, dass alles bei einem auf Null ist und beim anderen dann auf einmal auf hundertprozent, sondern das geht dann eher fließend weiter. Perfekt, danke, da gibt alles komplett Sinn. Dankeschön. Super. Okay, ich gehe mal ein paar von den Fragen noch durch, die eingereicht worden sind. Und wenn ihr zwischen euch Kommentare oder weitere Fragen habt, einfach 0 zu. Wir zeichnen im Shop das Product Markup mit JSON-LD seit einiger Zeit auf Produktlisten für die einzelnen Produkte aus. Wir können nun Beispiel sehen, wo auch die Produktliste Kategorien mit Sternen in den Suchergebnissen auftauchte, das ja eigentlich nicht gewollt und wir sehen das Risiko, dass Google diese Rezension snippet für die gesamte Domain entfernen könnte. Ist unsere Sorge berechtigt, was wäre dein Empfehlung für eine saubere Auszeichnung der Produkte auf Produktlisten Kategorienseiten? Ja, theoretisch ist es schon so, dass auf Kategorienseiten sollten die Bewertungen eigentlich nicht vorhanden sein, weil die Bewertungen sollten sich auf das gleiche Produkt jeweils beziehen. Das heißt, wenn ich verschiedene Produkte habe auf eine Kategorienseite und die haben jeweils diese Sternbewertung, dann ist es ja so, dass diese Bewertung sich nicht auf ein Produkt bezieht, sondern auch verschiedene Produkte. Und deswegen haben wir das in unseren Richtlinien eigentlich so drin, dass man das nicht machen sollte. Bezüglich Risiko und Sorgen und so, ist natürlich schon so, dass wenn unser Webspam-Team das so sehen würde, könnten sie dann kommen und sagen, gut, das ist falsch implementiert und wir müssen jetzt erstmal die quasi die Review-Sterne ausschalten für diese Domain, bis das sauber behoben ist, bis man diese Manual-Action dann sauber wieder quasi bereinigt hat. Ich würde in einem solchen Fall würde versuchen, das vorher schon in Ordnung zu bringen, das heißt, den Review-Markup oder den Produkte-Markup auf den Kategorienseiten irgendwie unterdrücken, wenn ihr das irgendwie könnt, so dass es dann wirklich nur auf den einzelnen Produktzeiten ist. Weil das wäre ja eigentlich auch das dann, was man sowieso dann machen müsste, wenn vom Webspam-Team her diese manuelle Maßnahme kommen würde. Inwiefern man erwarten muss, dass eine manuelle Maßnahme kommt, kann ich nicht sagen. Das hängt immer ein bisschen von verschiedenen Faktoren ab. Einerseits ob wir sehen, dass da eigentlich Webspam-Reports da sind, andererseits vielleicht auch ob unser Webspam-Team aktuell an diesem Problem arbeitet und gezielt solche Fälle heraussuchen muss. Von dem her lässt sich schwer sagen, wie groß das Risiko ist oder wie klein das Risiko ist. Aber ich würde mal sagen, wenn ihr das Problem eh schon kennt, würde ich das im Laufe der Zeit mal zu beheben. Was vielleicht noch zu sagen ist, mit diesen manuellen Maßnahmen für die verschiedenen Rich-Results-Arten ist es so, dass es an und für sich nur die Darstellungen in den Suchergebnissen unterdrückt. Das heißt, es ist nicht so, dass euer Website dann weniger gut in den Suchergebnissen ranken würde. Von dem her gibt es einige, die sagen, gut, wir nehmen das Risiko erstmal auf und wenn es jemand merkt, versuchen wir das zu prioritisieren, dass wir das ein bisschen schneller beheben können und ansonsten lassen wir das erstmal so weiterlaufen. Da kann ich euch schlecht irgendwie eine Empfehlung in die Richtung geben, aber es machen einige Suchen. Seit ein paar Monaten werden alle meine Homepage-Suche-Ergebnisse falsch angezeigt. Momentan zeigen sie Prozent-Prozent-Zeitname, Prozent-Prozent-Titel, obwohl das Prozent-Prozent-Titel und dann Zeitname sein sollte. Das gilt auch nicht nur die Homepage, alle anderen Pages werden richtig angezeigt. Ich glaube, das ist quasi der Website-Name und der Titel, wenn die vertauscht werden. Es ist so, dass unsere Systeme versuchen in eigentlich allen Fällen festzustellen, was der Website-Titel ist und was der Seitentitel ist für die einzelnen Seiten und versuchen, die unterschiedlich in den Suchergebnissen darzustellen. Meines Wissens gibt es da keine Fixereinfolge, dass wir das in quasi Seitentitel und Website-Titel, dass wir das quasi so machen oder umgekehrt machen würden. Es ist so, dass man unbedingt selber steuern kann. Das heißt, wir schauen uns die Titel an, die auf den Seiten sind und unsere Systeme versuchen natürlich festzustellen, welche Komponenten da sind und versuchen festzustellen, welche Variante, wie man das am besten in den Suchergebnissen präsentieren könnte. Wenn an und für sich die gleichen Elemente nicht wahnsinnig viel machen, um das umzudrehen, wenn die Titel ganz anders dargestellt werden in den Suchergebnissen, dann ist es oft ein Zeichen dafür, dass wir oder dass unsere Systeme halt vermuten, dass es sich lohnt, einen eigenen Titel dafür zu erstellen. Manchmal ist das der Fall, wenn man sehr viel Keyword-Stuffing in den Titel macht oder wenn wir sehen, dass ein Titel auf einer großen Anzahl von Seiten innerhalb der gleichen Webseite verwendet wird, dann schalten unsere Systeme eher noch ein und sagen, gut, wir müssen einen Titel selber erstellen für diese Seite, damit Benutzer wirklich wissen, worum es sich handelt auf dieser Seite. Aber wenn effektiv die Elemente gleich sind, die dargestellt werden und die Reihenfolge nur ein bisschen anders ist, dann ist das eigentlich nicht ein Zeichen, dass man irgendwie etwas gezielt falsch macht, sondern einfach nur, dass unsere Systeme das halt anders dargestellt haben. Das kann man eigentlich nicht wahnsinnig viel machen. Eine Frage bezüglich Cookie-Consent-Overlays, wenn wir ein Cookie-Overlay eines Anbieters einbauen, können wir mittels cloaking die Crawler-Bots von diesem Overlay ausschließen, sodass nur User es angezeigt bekommen oder muss der Crawler das Overlay auch sehen, bezüglich Guidelines, wie Crawlability. Es gibt verschiedene Arten, wie man diese Cookie-Consent-Overlays machen kann. Die meisten Arten, die wir sehen, die wir mal auch überprüft haben, die können wir ganz normal crawlen und indexieren. Unsere Systeme sind an und für sich darauf vorbereitet, solche Overlays zu erkennen und die Flexierung in Speichen zu unterdrücken. Das haben wir auch schon getestet. Die Frage ist, ob es ein Vorteil macht, weil wenn man das Cookie-Overlay theoretisch ja nicht zeigen würde, dem Google-Bot, weil er zum Beispiel mit einer IP-Adresse aus USA kommt und kein europäisches DSGVO-Komplenter braucht, würde man ja vielleicht ein bisschen Page-Load auch einsparen. Und man müsste die ganzen Tracking-Tools, diese Third-Party-Code dann für den Google-Bot implementieren. Aber das ist natürlich schon ein sehr weiter Schritt in eine vielleicht dunkelgraue Richtung von Klo-Arking. Ich, ja, also ich würde, wenn möglich, würde ich versuchen, die gleiche Version für alle Benutzer darzustellen und unseren Richtlinien her wäre es aber auch okay, wenn ihr sagt, alle Benutzer aus Amerika sehen die Variante ohne Overlay, Benutzer aus Europa sehen die Variante mit Overlay, weil Google-Bot hauptsächlich aus Amerika ihre Website crawled, würde Google-Bot das nie sehen. Einfach richtingemäßig wäre das total okay, wenn ihr das so machen wollt. Aus praktischen Gründen würde ich versuchen, wenn ihr das so macht, einfach wegen dem ganzen Debugging und Monitoring und solche Sachen. Das heißt, wenn ihr Google-Bot oder Benutzer in den USA eine andere Version ausliefert und ihr testet eure Seiten nur in Europa oder eurer Benutzer sehen sie hauptsächlich in Europa, wenn irgendetwas schiefgeht mit dieser US-Variante von eurer Website, dann geht das ja lange, bis ihr das merkt. Wenn es für Google-Bot diese Variante so da ist, dann müsst ihr wirklich gezielt darauf achten, dass Google-Bot immer die richtige Variante sieht, dass die intern links sauber vorhanden sind, dass die Seiten trotzdem noch gerendert werden können, all diese Sachen. Das heißt, aus praktischen Gründen würde ich versuchen, eine Version zu machen, wenn ihr euch entscheidet, das anders zu machen, weil es wäre auch sein, dass der Google-Bot vielleicht gibt es auch einen europäischen Crawler, der dann auf die Seite käme. Der würde dann natürlich den Unterschied dann halt sehen. Meines Wissens crawlen wir zur Zeit nicht aus Europa. Wir haben vor einigen Jahren versucht aus einigen Ländern zu crawlen, damit wir einfach sicher sind, dass wir in verschiedenen länder-spezifischen Varianten auch alle finden können. Das hat sich herausgestellt, dass das einfach ein sehr großer Aufwand ist. Für Website-Betreiber natürlich auch. Wir müssen auf einmal 5-mal so viel crawlen. Wenn man schon Probleme hat mit einmal crawlen, dann ist das Ganze für 5-fachen wieder schwieriger. Jetzt, im Moment, ist es so, dass wir vielleicht aus 2, 3 Ländern die wirklich gezielt andere Länder blockieren von ihren Internetseiten und das ist meines Wissens nicht der Fall innerhalb von Europa. Vielleicht die andere Sache bezüglich Speed ist es so, dass wir für Speed verwenden wir hauptsächlich die Daten vom Chrome Usability Report. Das heißt, das sind Daten, die Benutzer effektiv gesehen haben. Das heißt, Google-Bot, ist viel testet mit PageSpeed Insights oder mit Search Console direkt. Dann ist natürlich die Speed-Zahlen, die ihr da seht, sind natürlich quasi für die Variante, die Benutzer in den USA sehen würden. Aber wenn die Mehrheit eure Benutzer aus Europa kommen, dann sind ja die Mehrheit der Speed-Daten, die über Chrome gesammelt werden, sind dann wirklich aus Europa. Das heißt, vom Overlay wenn das für Amerika angezeigt wird, spielt das für die Speed an für sich keine Rolle. Okay. Danke. Okay. Dann noch mal Indexierungsprobleme. Bei der Indexierung Issues vom 2.6. bei mir sind 1400 Zeiten deindexiert worden. Ich warte seit 8 Monaten auf die Deindexierung von eidigen No-Index-Seiten. Das heißt, auf einmal zusammen mit den Indexing-Issues passiert es. Kannst du trotzdem mal nachschauen, ob alles in Ordnung ist. Ich habe bei deiner Seite noch nicht nachgeschaut, aber ich schau danach einmal nach, ob da irgendetwas speziell ist, ob wir vom Crawling her sonst normal arbeiten. Die Indexierungs-Issues von, ich weiß nicht, ob das vom 2.6. war dann, das war effektiv wirklich nur für einen Tag und dann er hat es eher Sachen betroffen, die jetzt neu indexiert wurden. Das heißt, es ist nicht so, dass wir auf einmal Sachen herausgenommen haben, die schon vorher indexiert waren, sondern wirklich eher die Situation, wo eine Website sehr viele neue Inhalte hat, dass wir diese neuen Inhalte einfach nicht rechtzeitig bearbeiten konnten. Mit deiner Website sollte das eigentlich keinen Zusammenhang haben. Aber ich schau da trotzdem mal mit dem Team nach, weil manchmal sind solche Fehlermeldungen dann doch irgendwie Zeichen, dass wir irgendetwas übersehen haben, wo wir noch etwas verbessern können. Bei mir ist das ganze Netzwerk betroffen, Flangenplatz DEATCH aber ich sehe jetzt nicht, dass es irgendwie schlechter ist in der Suche. Also es ist nichts passiert, wenn ich mir jetzt die Tools angucke, die ich hier habe, dann sehe ich jetzt keinen Sichtbarkeitsverlust. Nur komisch halt, weil ich hatte sehr viele Seiten noch nur index, hatte ich ja schon mal in den letzten Wochen mal gefragt, wann die denn abgearbeitet werden. Komischerweise ist es jetzt am 2.6. so gewesen und gleichzeitig habe ich dann auch bei euch gelesen, dass es da irgendwelche Probleme gibt. Aber gut, ja, dann schauen wir einfach nach. Oder sind das die Seiten, die auf Noindex waren, die jetzt indexiert sind? Ja, also das weiß ich ja jetzt nicht, weil die Seiten sind ja schon seit November 2019 noch Noindex, sind aber immer noch irgendwie im Index drin gewesen. Es kann sein, dass die jetzt raus sind. Wenn ich jetzt mit Screamingfrock drüber gehe, dann zeigt er mir schon jetzt für Flangenplatz DE 1.500 Seiten an und 1.500 Seiten sind jetzt auch im Index drin. Es kann gut sein, dass die Noindex-S Seiten dann auch letztendlich raus sind. Vielleicht können wir uns noch einmal schauen, weil es ist schon komisch, dass es genau mit diesen Issus dann auf einen Tag gefallen ist. Ja, okay, schaue ich mal nach. Okay, super. Ich benötige einige Stunden Downtime für eine größere Wartung, ohne etwas für Googlebot zu beschädigen. Ich würde dieselbe HTML-Seite für Benutzer mit HTTP startaus503 für alle URLs anzeigen. Ist das okay? Total okay. 503-Statuscode sagt uns an und für sich, dass wir die Inhalte nicht berücksichtigen sollen. Das ist ein temporärer Fehler. Dass wir dann auch nach einiger Zeit dann wieder probieren sollen, diese URLs zu crawlen. Wichtig beim 503 ist einfach, dass es weniger, als, sag ich mal, 2 Tage dauert. Weil wenn das länger-Fastik 503 ist, dann ist es für uns eher ein Zeichen, dass die Website wirklich ein größeres Problem hat. Dass sie vielleicht jetzt nicht mehr existiert oder nicht mehr sauber aufgeschaltet ist oder das Seiten entfernt worden sind so etwas. Wenn das einige Stunden sind, vielleicht bis zu einem Tag, wenn irgendwo mal was schief geht, sehe ich da überhaupt keine Probleme. Wird das denn Best Practice von eurer Seite aus? Ja, doch. Das ist perfekt. 503 ist das richtige Ort. Und dann für alle, also jetzt keine Umleitung machen, auf eine Seite kein Redirect, sondern für die, die im Index sind, 503 zeigen und eine andere Seite dann praktisch für den Benutzer. Ja, genau. Okay, gut. Wir haben die Befürchtung, dass unser Search Console nicht die richtigen Daten anzeigt. Das haben wir gleich vorher angeschaut mit m. und www. Dann eine Frage bezüglich der alte URL-Parameter in einem Shop-System. Aufgrund von Altlasten hat sich auf einer Shop-Domain eine URL-Lust von 1,3 Millionen alten Parameter-URALs angeheucht, die aktuell teilweise noch gecrawlt, aber nicht indexiert werden. Wenn wir diese URLs beziehungsweise das Parameter-Muster schnellstmöglichst möchten, sollten wir die entsprechenden Parameter auf die Original-URAL weiterleiten oder die überflüssigen Parameter auf 4.04 setzen. Leider ist das URL-Parameter-Tool noch fehlerhaft und keine Hilfe. Die Original-URALs haben alle gültige Self-Canonicals. Quasi weiterleiten oder 4.04 zurückgeben. Vermutlich ist das etwa gleich schnell. Ich denke weil das etwa gleich schnell ist würde ich da eher in Richtung Weiterleitung gehen, damit diese URLs wirklich auch konzentriert werden. Damit falls irgendwo jemand zum Beispiel auf diese alten URLs noch verlinkt hat, dass diese Links nicht verloren gehen sondern dass sie wirklich auf die Haupt-URALs weitergeleitet werden. Wenn ihr 4.04 zurückgibt für diese URLs dann fallen sie zwar auch aus dem Index heraus dann fallen aber auch alle Signale weg die wir für diese URLs gesammelt haben. Wenn wir 3.01 zurückgeben ist es dann so, dass sie immer wieder und immer wieder gecrawlt werden oder würden die dann nach wegen der 3. oder 4. Schleife nachdem der Crawler nochmal drüber gelaufen das würde das dann irgendwann abbrechen und sagen, nee, da passiert da nichts mehr raus. Wir würden sie wahrscheinlich schon ab und zu weitercrawlen aber wenn man diese Weiterleitung sage ich mal, ja mal dort implementiert hat dann wird das wahrscheinlich sehr selten sein dass wir die alten URLs crawlen und wir würden sie wahrscheinlich eher dann auch crawlen, wenn wir einfach neue Signale finden zu diesen alten URLs was wahrscheinlich eher selten passieren würde. Weil das Problem ist bei diesen Parametern, dass es halt viele Möglichkeiten gibt, wie sie an die aktuell gültigen URLs angehängt werden könnten. Also das ist ein Shop, der hat vielleicht 25.000 URLs, 25.000 Seiten und dazu könnten die natürlich in verschiedenen Kombinationen sinnhaft oder nicht sinnhaft angehängt werden und ich verstehe das Muster nicht und wir haben auch bei uns technischer Seite keinen Tricker gefunden auf dem die entstehen könnten und unsere Befürchtung war einfach weil wir die in diesem URL Parametertool in der Google Search Konsole mal drin hatten und das Tool eben aktuell fehlerhaft ist also das zählt ja auch nicht mehr die Parameter URLs wie viele da jetzt betroffen sind oder nicht, haben wir einfach die Befürchtung, dass der Google bot sich die da selber irgendwie zusammenbaut quasi also neue URL und alte Parameter einfach in der Google Search dran zu hängen und wir möchten das einfach unterbinden wir möchten einfach hier sagen, ne, ist nicht mehr also wir könnten auch ein 410 ausspielen, aber das macht man ja eigentlich nur für alte Produkte. Ja, 404 410 ist ziemlich gleich in solchen Fällen. Ja, ich denke optimal, weil wahrscheinlich schon 301 aber wenn das Sachen sind, die wirklich sehr selten gekraut werden die sich quasi angehäuft haben und das ist 4104 eigentlich auch kein Problem. Bezüglich dem Parameter Tool, es ist so dass wir das durchaus weiterhin benutzen einfach, dass die Zahlen und die Beispiel URLs seit einiger Zeit quasi rausgefallen sind. Ich soweit ich gesehen habe, sollten die Sachen, die Zahlen und die Beispiel URLs bald wieder kommen aber unser Plan ist an und für sich schon, dass wir dieses Tool weiter verwenden, das heißt wenn ihr dort die Einstellungen vornehmt und das Ganze auf 4104 setzt, dann sollte das eigentlich auch relativ gut klappen. Okay. Ja, wir werden mal schauen. Ich denke, wir werden uns für die Weiterleitung dann entscheiden. Da sollte man ja innerhalb von dem nächsten halben Jahr dann schon eine Änderung sehen, dass das weniger wird an Daten, die dann noch gekraut werden müssen. Ja. Es ist so, dass wenn das URLs sind die wirklich sehr selten quasi erreicht werden in den Suchergebnissen, sehr selten auch quasi interexiert sind, dann kann es euch aus dem halben Jahr gehen zwischen einzelnen Crawls von diesen URLs. Das heißt, innerhalb von einem halben Jahr sieht man wahrscheinlich schon, dass es weniger wird, aber es wird noch nicht ganz weg sein nach einem halben Jahr. Okay, sehr gut. Und es würde jetzt im Vergleich dazu auch keinen Sinn machen, die mit der Robots.txt auszuschließen, weil er sie ja dann immer wieder finden würde, sie dürfte sie nicht crawlen. Genau. Das ist eigentlich Quatsch. Ja, also wenn würde ich sie auf 404 setzen, nicht mit Robots.txt, weil mit Robots.txt wissen wir dann einfach nicht, was wir damit machen sollen und dann geht das ganz verloren dort. Okay, perfekt. Danke. Okay, da sehe ich noch eine Frage, die eingereicht worden ist. In letzter Zeit liest man über ein neue Ranking Factor, der Usability, eine Website beurteilen und meine Frage ist etwas daran. Wie würdet ihr das umsetzen, zieht ihr Faktoren wie Speed, Schriftgröße, Navigation zusammen und macht daraus einen neuen Parameter? Oder ist das etwas Neues? Ja, wir haben eine Blogpost dazu. Ich glaube sogar auf Deutsch auch übersetzt über das Page Experience Benchmark, den wir zusammenstellen dort und da sind die Core Web Vitals dabei, das sind die quasi drei neuen Speed Faktoren, die wir anschauen. Ich weiß jetzt die Namen nicht auswendig, einerseits die Ladegeschwindigkeit, andererseits wie stabil die Seite ist, wenn sie geladen ist, also ob sie quasi herumschiebt, während sie geladen wird und drittens die Interaktionsseite. Das heißt, wie schnell die Seite reagiert, wenn er Benutze etwas macht auf der Webseite. Das sind mal die drei Faktoren. Dazu kommen noch andere Faktoren wie Mobile Friendliness, Safe Browsing und zwei andere Sachen, die ich jetzt gerade vergessen habe. Aber das sind quasi verschiedene Faktoren, die wir in den Page Experience mehr wert quasi zusammenfassen und aufgrund von dem wollen wir das Ganze dann im Ranking System einbauen. Das heißt, im Moment ist es noch nicht aktiv, es ist nicht so, dass jetzt von einen Tag auf den anderen die Websites neu beurteilt werden, sondern wir haben die Core Web Vitals erstmal ein Search Console eingebaut. Man kann das dort testen, man kann das über verschiedene andere Speed Tests anschauen. Und wenn wir so weit das alles eingerichtet haben und sauber testen konnten, dass wir das im Ranking Factor einsetzen können, dann geben wir euch ein halbes Jahr vorher noch Bescheid und dann sechs Monate später wird das dann als Ranking Factor eingebunden sein. Die Frage, die meistens noch dazu kommt, ist quasi, wie stark ist dieser Ranking Factor, müssen wir befürchten, dass unsere Website vom Internet verschwindet, weil sie ein bisschen langsamer ist. Da ist einfach einerseits schon die Idee da, dass wenn wir ähnliche Websites haben und wirklich auch starke Unterschiede feststellen können bezüglich diesen neuen Metriken, dass wir das dann einsetzen würden, aber wenn jemand natürlich gezielt nach eurer Website sucht, dann würde es ja eigentlich keinen Sinn machen, eine andere Website zu zeigen, nur weil sie ein bisschen schneller ist. Das heißt, wir müssen immer eine Balance da haben zwischen einerseits Relevanz für den Benutzer, dass die Ergebnisse für den Benutzer relevant sind und andererseits, dass die Ergebnisse auch gut brauchbar sind für den Benutzer. Es ist nicht so, dass wir dann nur auf Geschwindigkeit achten können, weil wenn wir nur auf Geschwindigkeit achten, dann wäre ja eigentlich eine leere HTML-Seite das schnellste, aber das bringt den meisten Benutzer ja eigentlich nicht wahnsinnig viel. Passend dazu, hallo erstmal, passend dazu hätte ich eine Frage war, ist es möglich, dass im Zuge des Core Updates vom Mai eine Website eingebrochen ist im Punkt der Sichtbarkeit Rankings nur aufgrund von User Experience Faktoren ist das denkbar oder müssen da verschiedene Sachen zusammenkommen? Also, gerade die ganzen neuen Core Web Vitals sind ja Sachen, die sind im Moment noch nicht verwendet für das Ranking überhaupt. Das heißt, wenn man jetzt im Core Update Änderungen gesehen habe, gerade, dass wir bei beiden Core dabei haben im Namen, deswegen ist es vielleicht auch ein bisschen verwirrend. Aber wenn jetzt eine Website im Mai eine Veränderung gesehen hat, dann wird das nicht aufgrund von den Core Web Vital Sign, sondern aufgrund von anderen Faktoren, die wir da halt berücksichtigen. Wie weit wird da die Availability schon berücksichtigen würden? Weiß ich nicht. Ich vermute, das sind in den meisten Fällen bei diesen Core Updates ist es so, dass wir da wirklich stark auf einfach Relevanz achten und versuchen unsere Relevanz Algorithmen entsprechend zu verbessern. Das heißt also, wenn man man hat ja viel darüber gelesen, dass zum Beispiel der User Intent an eine große Rolle spielt, dass eine Website zum Beispiel möglichst gut zu den Bedürfnissen und den Absichten der Nutzer passen sollte. Also so etwas kann dann schon eine Rolle gespielt haben bei der ganzen Geschichte auch. Kann sein, mir ist jetzt anfühlt sich nichts Spezielles bewusst. Das heißt, von dem her kann ich sagen, wäre durchaus denkbar, dass an diesen quasi User Intent Algorithmen das da gearbeitet wird, dass wir einerseits die Websites versuchen, ein bisschen besser einzuschätzen und einerseits die Queries ein bisschen besser einzuschätzen. Ob das jetzt da speziell im Mai der Fall war oder nicht, kann ich jetzt nicht sagen. Okay, Dankeschön. Okay. Paar Minuten haben wir noch übrig. Vielleicht gibt es von euch noch irgendeine Frage. Ja, tatsächlich. Ladies first. Sorry, I know this is a German Hangout but is there any chance I can ask a question in English, is that okay? Sure, or otherwise we have one tomorrow in English, if you'd like. Yeah, so out of my times are in the moment because it's too early for me. Is it okay if I can ask a question? Sure, sure. Okay, we have a U.S. site and we've noticed that in the search, we've noticed that some of the pages are bringing up international some of our international metadata through and we're not sure what's causing that. It's the URLs, correct, but the type of description and structure data is pointing through is wrong. I probably need to look at some examples. So maybe if you can drop some example URLs and example queries into the chat here, I can pull that out afterwards and take a look. Yeah, pop some in there. Okay. We tried checking changes to because it's pulling like, one of the examples was where it was pulling in finish from our finish site and we changed it to English to hope that you would pull it the English through, but for some reason it changed it to German. So it was a bit of a strange one, we don't know, we've checked that Reflangs, everything looks correct. We've made no changes so we don't know what's causing that. Okay. I don't know, that sounds kind of strange. Usually when I see these kind of problems it's with different countries that have the same language but switching from English to finish to German feels a bit weird. Yeah. Okay, thank you. Put the examples in there. Alright, thank you. Okay, Marc, du hattest, glaube ich, noch eine Frage. Ja, genau, danke. Wir haben eine Seite auf die, wir haben Inhalte via ARP von verschiedenen Partnern eingespielt und der zu verschiedenen Bord kommt rüber und checkt, dass er verursacht hat, ziemlich viel Traffic und scheint alles vorzubringen an, also alle möglichen Links zu klicken, alle Filter zu klicken und das gibt einem Partner. Gibt es die Möglichkeit den Bord ein bisschen einzubremmen, sodass auf der einen Seite schon verstehen kann, ja, die Seite ist da und das ist die Inhalte und es funktioniert auch alles, dass er nicht so unglaublich viel Bord-Traffic-Vorsache gibt es da irgendwas? Ähm, man kannte das auf einer, sage ich mal, Hostname-Ebene einschrellen mit den wie heißt es, die Crawl Rate Einstellung in Search Console ähm, wenn die API zum Beispiel über einen anderen Domain oder anderen Hostname rausgeliefert wird, könnte man das da auf diesem Domain entsprechend auch einstellen. Wenn das jetzt nur ein kleiner Teil der Website ist, man möchte das Google-Bord quasi vermehrt den anderen Teil der Website crawled und nicht diesen Teil der Website, dann ist das ein bisschen schwieriger. Könnte man unter Umständen mit so Sachen arbeiten wie mit einem No-Follow für die Links, wenn das alles quasi einfach verschiedene Varianten sind, die einfach gecrawled werden, ohne dass gezielt interne Links da sind, dann ist das ein bisschen schwieriger. Wenn das wirklich ein großer Menge ist und wirklich extreme Probleme bei euch verursacht, dann auch das direkt mit dem Team mal anschauen, wenn du mir zum Beispiel Beispiele schicken könntest oder im Search Console Hilfe Center gibt es, wenn man bei, ich glaube den Crawl Rate Einstellungen danach sucht, gibt es ein Formular, das man verwenden kann, welches auch direkt an das Google-Bord-Team geht und da kann man auch angeben quasi ich sehe einfach starken Bord-Traffic auf diesem Teil meiner Website und ich wäre froh, wenn ihr das ein bisschen interessiert und das Google-Bord-Team geht in der Regel einfach manual durch und schaut, wo man einerseits vielleicht Einstellungen bei uns vornehmen müsste, dass wir ein Teil der Website einfach weniger häufig crawlen oder wo wir insgesamt vielleicht in unseren Algorithmen ein bisschen etwas verbessern können, dass wir gar nicht so viel von diesen Links überhaupt finden und die entsprechend überhaupt vielleicht versuchen weniger zu crawlen insgesamt. Super, herzlichen Dank dafür. Okay, cool. Okay, ich glaube zeitlich sind wir so ziemlich am Ende. Ich sehe gerade noch eine kurze Frage zu Emojis in den Titeln oder Suchergebnissen. Emojis aus unserer Sicht ist an und für sich kein Problem. Man kann das durchaus verwenden beim Titel und Beschreibung. In manchen Fällen ist das okay, funktioniert das vielleicht gut in anderen Fällen sieht das ein bisschen unprofessionell aus, das ist aber an und für sich euch überlassen. Wir filtern solche Emojis raus, die verwirrend sind für Benutzer. Das heißt, wenn wir etwas sehen, das aussieht wie Sternebewertung und das sind nicht die normalen Rich Snippets, dann sind das vielleicht Sachen, die wir herausfiltern würden. Wenn ihr einfach irgendwelche anderen Emojis verwenden möchtet in Suchergebnissen ist das an und für sich euch überlassen. Bezüglich Google My Business bei Google Maps weiß ich nicht, ob da andere Richtlinien da sind. Okay, machen wir vielleicht hier eine Pause. Vielen Dank für die vielen Fragen und Kommentare. Und ich richte auf jeden Fall mal die nächsten Hangouts wieder ein und wenn noch weitere Sachen da sind eben morgen auf Englisch und ansonsten das nächste Mal mal wieder auf Deutsch. Bis dann. Danke schön. Tschüss. Tschüss. Danke. Tschüss.