 OK. Herzlich willkommen beim heutigen Webmaster Essentials Sprechstunden 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 Sprechstunden. Ich fahre nicht mal vom Büro aus, aber immerhin live of YouTube für alle, die gerne mithören möchten. Die Hangouts sind speziell für Webmaster, SEOs, Publisher, jeder, der irgendwie Fragen um die Websuche hat und seine Website. Sind schon einige Fragen eingereicht worden auf YouTube, nicht allzu viel dieses Mal. Das ist eigentlich auch OK. Wenn ihr wollt, könnt ihr gerne schon mal loslegen mit einer Frage von euch. Wenn nicht, dann fange ich einfach mal an. Und vielleicht kommen ja noch weitere Fragen oder Erläuterungen, Kommentare noch dazu. OK. Die erste Frage ist zu Mobile First Indexing. Wir wurden im Februar von Search Console darüber informiert, dass aufgrund einer Asymmetrie zwischen Desktop und mobiler Version unsere Seite sehr groß, circa 800.000 indexierte Seiten für Mobile First Crawling nicht aktiviert werden kann. Die Fehlermeldung fehlendes Bild. Auf der mobilen Seite fehlen wichtige Bilder der Desktop-Seite. Wir haben im direkten Anschluss die Empfehlungen aus der verlinkten Google Best Practices Docum gesetzt und den Fehler behoben. Dazu unter anderem jetzt auch einen Very Hatter eingesetzt, sodass immer die korrekte Version der Seite in Abhängigkeit des User Agents ausgespielt wird. Wir sind nun leider noch immer nicht auf Mobile First Indexing umgestellt und werden langsam besorgt. Wir sind sicher, dass alles nun richtig ist. Können wir irgendetwas tun, um erneut geprüft zu werden? Gute Frage. An und für sich gibt es da nicht irgendeine Funktion, die man machen kann, um quasi die eigene Website testen zu lassen. Aber unsere Systeme kontrollieren jeweils einfach den aktuellen Zustand der Website und schalten dann entsprechend um, sobald wir sehen, dass alles soweit okay ist. Ich vermute, wenn das jetzt im Februar passiert ist, dass ihr da eine Meldung bekommen habt und seid ihr jetzt nichts mehr davon darüber gehört habt, ist es wahrscheinlich irgendwo im Zwischenschritt, dass es dann nach einer gewissen Zeit einfach noch mal kontrolliert wird und dass es dann umgestellt wird. Die Sache mit den fehlenden Bildern ist etwas, was manchmal ein bisschen Interpretationssache auch ist. Und an und für sich dazu führen kann, dass unsere Systeme vielleicht denken, dass da Bilder fehlen. Aber wenn ihr die Website quasi manuell anschaut, dann seid ihr vielleicht der Meinung, dass es soweit okay ist. Das kann zum Beispiel sein, wenn man verwandte Produkte oder verwandte Artikel hat auf einer Seite, die im Sidebar oder unten platziert sind, wo hier was ein thumbnail Bild dabei ist. Dann kann es natürlich sein, dass man auf der mobilen Version einfach weniger thumbnail Bilder dabei hat, weil man hat weniger von diesen verwandten Artikel dabei oder vielleicht zeigt man sie ohne thumbnail Bild eher. Und aus eurer Sicht ist das vielleicht total okay so, vielleicht sogar so gewollt. Und aus unserer Sicht, wenn wir die Seiten quasi automatisch kontrollieren lassen, dann sehen wir, ah, da fehlen einige der Bilder, die sonst indexiert wären. Und an und für sich ist das gleich mal ein Zustand, wo unsere Systeme vielleicht denken, dass ihr noch nicht bereit seid. Aber wenn ihr eigentlich damit zufrieden seid, dass das für euch so okay ist, dann könnt ihr das einfach sein lassen und dann im Laufe der Zeit werden unsere Systeme da diese Seiten dann trotzdem umschalten auf Mobile First Indexing. Das heißt, wenn ihr wirklich sicher seid, dass ihr die Empfehlungen umgesetzt habt, wenn alles soweit okay aussieht zwischen der mobilen und der Desktop Version, wenn ihr sie testen lässt, dann würde ich mir da jetzt eigentlich keine großen Sorgen mehr machen. Dann kommt das schon im Laufe der Zeit. Es ist auch so, dass mit Mobile First Indexing ist es nicht so, dass da ein Vorteil in der Suche entsteht. Das heißt, es ist nicht so, dass man besser in den Suchergebnissen platziert wird, dass man besser, sagen wir, mobilen Ergebnissen platziert wird, sondern es bezieht sich rein auf das technische Indexieren von den Inhalten auf den Seiten. Das heißt, wenn ihr noch nicht umgestellt seid und ihr soweit damit zufrieden seid, dann muss man einfach ein bisschen warten. Dann von Christian noch eine Frage über Twitter. Wie hast du das gemeint mit den T-Shirts und Travel? Muss ich selber erst mal überlegen. Gibt es eine Zeit? Jetzt müssen wir die Fragen nochmal anschauen. OK. Ich habe sie hier jetzt nur auf Englisch. Am I competing with a domain or with a website for a term? It's possible to rank for T-Shirts with one webpage when the domain's topic is travel. Let's say my website is the best webpage for T-Shirts. An und für sich geht das auf beide Varianten. Das heißt, es ist so, dass es eine Signale gibt, die wir eher auf Websitebene sammeln und andere Signale, die wir eher auf Seitebene sammeln. Und zusammen versuchen wir dann jeweils die Relevanz zu bestimmen. Das heißt, es kann durchaus eine Konkurrenzsituation entstehen zwischen einer Website, die alle möglichen Produkte anbietet und einer Website, die jetzt nur T-Shirts anbietet. Wenn ich für T-Shirts suche, sind T-Shirts auf beiden dieser Websites. Einerseits die T-Shirts spezifische Website, einerseits der allgemeine Onlinehandel, wo man unter anderem auch T-Shirts bekommen kann. Und es kann problemlos sein, dass diese beiden Seiten eigentlich relativ ähnlich kompetitiv in den Suchergebnissen erscheinen. Vielleicht erscheint mal die eine oben, vielleicht mal die andere oben, aber es ist nicht so, dass dadurch, dass ein Domain quasi einfach sehr stark ist oder sehr bekannt ist, dass dadurch einen Vorteil entsteht, dass man sagen würde, jetzt für T-Shirts müsste man unbedingt auf quasi die größere Website, wo andere Produkte dabei sind. Oder ist es auch nicht so, dass man sagen würde, für T-Shirts muss man unbedingt auf den spezialisierteren Website gehen. Meistens entstehen die Vorteile und Nachteile eher darin, sorry, welche Varianten man alles zur Verfügung hat. Das heißt, wenn ich eine T-Shirts spezifische Website habe, dann sinkt vielleicht für die allgemeinen Suchen, ist es halt eine Frage, je nachdem, die oder die andere Website. Bei spezielleren Suchen, wenn man eine spezielle T-Shirt-Variante sucht, dann finden wir das vielleicht ein bisschen besser auf einer T-Shirts spezifischen Website, einfach weil wir da die einzelnen Varianten viel schneller finden können, dass man, wo wir die auch besser einordnen können, wo man besser passende Landing-Pages für die Varianten indexieren kann. Aber an und für sich gibt es da keine, sag ich mal, absolute Antwort, wo man sagen würde, man muss alles zusammen in eine Website tun oder man muss irgendwie separate Websites für einzelne Themen machen. Meistens, wenn quasi die Frage da ist, allgemein von jemandem, der viele verschiedene Produkte hat und sich überlegt, soll ich jetzt einzelne Websites machen oder eine größere, meistens empfehle ich da eher eine einzelne Website zu machen, einfach weil das viel einfacher ist mit dem ganzen Tracking, weil es viel einfacher ist, die ganzen Sachen zu verwalten und entsprechend auch zu unterhalten auf einer einzelnen Website, als wenn man jetzt viele verschiedene Websites macht. Also mit Websites meinst du jetzt aber eine Domäne oder eine einzelne Seite, eine HTML-Seite oder so mal so schwierig in Deutsch, ne? Das ist immer kompliziert auf Deutsch. Genau, mit Websites meine ich ein Domäne quasi, unterschiedliche Domänes, sagen wir mal so auch. Okay, also meine Frage, hast du jetzt auch so weit beantwortet, ich hab halt ziemlich viel Duplicate-Content auf meinen Seiten. Das bedeutet zum Beispiel, ich schreibe für die Kunden kostenlose Rücksendung, also Informationen sind auf jeder Seite immer gleich, auf 5.000 verschiedenen Seiten. Aber dadurch, dass ich diese Informationen ja auf dieser Seite darauf habe, verstärkt sich ja die Seite dann auch praktisch im Ranking, also in der Konkurrenz mit den anderen Seiten. Also wenn ich jetzt mehr Informationen für den Kunden biete, dann ist ja meine Seite definitiv besser, als die von einem anderen Ordnungen, schon wo es diese Informationen wahrscheinlich nicht gibt. Und deswegen habe ich mal die Frage gestellt, ob ich jetzt mit einer Domäne konkurriere oder halt doch mit einer einzelnen Seite. Und so wie ich es jetzt verstanden habe, ist es doch tatsächlich nur die einzelne Seite. Es ist eher eine Mischung. Also es gibt sicher gewisse Faktoren, die wir von auf Domänebene sammeln, das kann auch auf Subdomänebene sein, aber auf diesen groben, quasi gesamthaften Webseitebene. Und es gibt andere Signale, die wir auf einer einzelnen Seitenebene sammeln. Das heißt, für eine Produktseite holen wir da vielleicht Informationen über die Relevanz von diesem Produkt, finden vielleicht Bilder dazu, all die speziellen Informationen da. Und diese Mischung bedeutet eigentlich, dass es immer, es spielt immer beides ein bisschen eine Rolle. Das heißt, wenn man eine insgesamt schlechte Webseite hat, aber eine gute Landingpage, dann ist das ein bisschen schwierig auszugleichen. Oder dann kann man nicht genau sagen, die Landingpage, die wird trotzdem gut platziert in den Suchergebnissen, weil wenn wir denken, dass der Domain insgesamt eher problematisch ist, dann sieht quasi der Domain das vielleicht ein bisschen runter und die Landingpage ein bisschen hoch. Und das wird dann irgendwo in der Mitte platziert. Okay, alles klar, danke schön. Ja, also ich weiß nicht, ob alles klar ist. Gerade bei solchen Fragen ist es ja dann eher so, dass es gibt keine einzelne klare Antwort, wo man sagen kann, so ist es und das muss man machen. Aber das muss natürlich auch ein bisschen spannen. Ich habe halt gedacht, durch diesen Duplicate Content wird das eigentlich doch ein bisschen schlechter wieder. Aber ich finde, es ist besser geworden. Also dadurch, dass ich gute Informationen auf jeder Seite gleich habe, also der Kunde steigt ein, auf die Seite sieht sofort alles, aha, kostenlose Rücksendung bieten wir jetzt nicht direkt an und so weiter. Also das war so mein Problem eigentlich. Aber ja, ja, also... Und ja, es macht ziemlich viel aus auf jeden Fall auch. Ja, also ich denke gerade, solche Informationen finde ich total unproblematisch, wenn man die auf den Seiten auch doch dazu hat. Es ist ja so, dass wir Duplicate Content einerseits auf einer Seitenebene versuchen, das heißt, wir versuchen zu erkennen, ob die Seite gesamthaft gleich ist oder fast gleich ist, wie die andere Seite. Und wir versuchen natürlich auch einzelne Elemente innerhalb der Seite zu erkennen, die vielleicht dupliziert sind. Und in der Hinsicht ist es ja nicht so, dass diese Elemente die Seite herunterziehen, sondern wir kennen einfach gut, als die, sag ich mal, die Geschäftsbedingungen oder die Telefonnummern, die Kontaktadressen sind, auf allen Seiten davor handen. Das heißt, wir müssen den vielleicht weniger Wert geben. Wir können uns auf die Hauptproduktelemente konzentrieren. Und wenn jemand gezielt nach der Telefonnummer sucht, dann wissen wir, das ist auf all diesen Seiten und davon ist jetzt die best passend zu halt, ich weiß nicht, eine Kontaktzeit oder so etwas. Von dem her macht man da eigentlich nicht viel Fall schon mal trotzdem diese gemeinsamen Informationen auf den Seiten dabei hat. OK, dann eine Frage zur Structure Data Markup auf FAQ-Seiten. Da wir für die Beantwortung unserer FAQ-Fragen viel Content benötigen, ist es für uns nicht möglich, alle Fragen auf einer Seite zu beantworten. Stattdessen beantworten wir jede Frage auf einer separaten Unterseite, welche auf der FAQ-Seite verlinkt ist. Ist es möglich für jede Frage Antwort, ein FAQ-Page Markup zu verwenden? An und für sich kann man das machen. Sehe ich da eigentlich keine Probleme darin. Was einfach passieren wird, ist, dass diese einzelnen Seiten quasi separat renten und separat in den Suchergebnissen erscheinen müssen. Das heißt, wenn man eine Frage hat, die sehr häufig vorkommt und die Seite, wo diese Frage platziert ist, wird selten in den Suchergebnissen gezeigt, dann wird dieser FAQ-Block natürlich nicht gezeigt. Das andere ist, dass gerade bei diesen FAQ-Blocks ist es, glaube ich, so, dass unsere Systeme versuchen, das eher dann zu zeigen, wenn wir wirklich verschiedene Fragen haben. Das heißt, wenn es, ich weiß nicht, wo die Grenze ist, wenn man mal drei oder vier Fragen hat, dass wir dann diesen FAQ-Block zeigen in den Suchergebnissen. Und wenn wirklich nur eine Frage auf einer Seite ist, dann sind das ja nicht verschiedene Fragen, sondern es ist eigentlich eher ein Teil vom Inhalt von dieser einzelnen Seite. Und dann macht es vielleicht weniger Sinn, dass man diesen FAQ-Block in den Suchergebnissen zeigt. Ich weiß nicht, wo die genaue Grenze ist. Ich nehme an, dass verändert sich wahrscheinlich auch im Laufe der Zeit, je nachdem, wie wir erkennen können, wie viel es jetzt gerade Sinn macht zu zeigen. Vielleicht hängt es auch vom Geräte-Typ ab, wo man jetzt gerade sucht. Aber das ist vielleicht etwas, wo man ein bisschen Rücksicht nehmen möchten müsste. Wenn man gezielt diesen FAQ-Block haben möchte und wirklich eher weniger Fragen pro Seite platzieren möchte, dann kann es natürlich sein, dass wir irgendwann sagen, das sind jetzt nicht einzelne Fragen, sondern das ist ein Teil vom Gesamtinhalt. Kurze Rückfrage dazu. Wir haben uns das gar nicht so vorgestellt, dass man dann pro separate Frage ein einzelnen FAQ-Block bekommt unter der Antwort. Sondern wenn wir uns das vorgestellt haben, aber es gibt bei Google manchmal oben diese Frage-Antwort-Box, wenn man deswegen eine Frage googelt, dann wird da oben die Frage angezeigt, plus die Antwort auf Platz 0. Und das würde ich gerne für jede einzelne Frage wünschen. Und dagegen, aus der Dokumentation 10-20, wirklich heraus, welches Markup man da am besten verwenden kann. Okay. Das ist bei uns der Featured Snippet, der oben gezeigt wird. Und der ist an und höhe sich nicht bezogen auf spezielle Structure-Data-Markups. Sondern da schauen wir die Seite, haben wir für sich an, die Inhalte auf der Seite und versuchen da zu erkennen, welche Teile der Seite diese Antwort am besten quasi präsentieren, wo man vielleicht eine kurze, prägnante Antwort hat, wo man dann vielleicht dann trotzdem noch auf die Website verweisen kann, all solche Sachen. Das heißt, es ist nicht eine Frage vom Structure-Data für solche Situation, sondern eher darum, wie man die Frage und Antwort präsentiert auf den einzelnen Seiten. Wir haben ursprünglich mal versucht, mit Structure-Data da etwas zu machen. Wir haben mit dem Team auch geschaut und gesagt, es wollen ja viele Leute diese quasi Darstellung haben, ob man das nicht auch bei Structure-Data machen kann. Und aus ihrer Sicht war es wirklich so, dass sie wirklich sich auf die Inhalte konzentrieren möchten und nicht mit Structure-Data arbeiten wollen. Bezüglich den Inhalten gibt es da verschiedene Präsentationen, die ich extern schon gesehen habe, wie man am besten Inhalte gestaltet, sodass sie gut funktionieren für diese Featured Snippets. Ich würde da einfach mal ein bisschen herumschauen, da gibt es noch, denke ich mal, spannende Ansätze, die man machen kann. Aus unserer Sicht sehen wir das eher an wie ein normaler Snippet und von dem her haben wir nicht spezielle, sag ich mal, Information, wie man sagen würde, so muss man das gestalten, damit das funktioniert. Aber ich würde mal die ganzen Präsentationen mal anschauen, da hat es relativ vieles dazu. Okay, vielen Dank. Vielleicht kurze Frage noch. Ist unsere neuen HEP-Center, das wir bauen. Bauen wir das aussehen, dass wir einen relativ großes FAQ haben, FAQ, und da gibt es verschiedene Unterkategorien, die wir verschiedene Fragen haben, so wie Rücksendung, Versand usw. Also wir haben einen großen FAQ, wo im Grunde genommen viele Heinzen FAQ sind. Und was wir ganz gerne gemacht hätten, wäre für jedes Kategoriesalte, also jedes Kategorie FAQ, ein Einzels FAQ-Markup zu verwenden. Das Problem ist, dass bei uns aus UX Sicht, Tieser, wir den Content nur ansprechen, wir haben wirklich nur die Fragen dastehen, und die Antworten findet man nur, wenn man auf die einzelnen Fragen klickt, ist halt dahingehend problematisch, dass wir gerne das FAQ-Markup benutzen würden. Der Content für die Antworten allerdings nur auf der Seite zu sehen ist. Wie würde man am besten mit dieser Sache umgehen, deiner Meinung nach? Aus unserer Sicht sollte Structuredata sichtbar sein auf den Seiten, damit wir es verwenden können. Beim FAQ-Markup ist es so, dass das an und für sich okay ist, aus unserer Sicht, wenn die Frage sichtbar ist, und wenn die Antwort, sag ich mal, hinter irgendwie ein CSS, irgendwie so zusammengeklappt ist. Wichtig ist einfach, dass die Antwort trotzdem im HTML ist. Nicht dass, wenn man auf die Frage klickt, dass erst die Antwort nachgeladen wird, weil in solchen Fällen können wir gar nicht kontrollieren, ob diese Inhalte wirklich auf der Seite sind. Aber wenn die Frage, sag ich mal, sichtbar ist auf der Seite, und wenn per CSS die Antwort einfach quasi zusammengeklappt ist, damit man mehr Fragen platzieren kann, oder damit das ein bisschen klarer ist im UX, dann ist das an und für sich machbar. Okay, vielen Dank. Okay, Stichwort Keyword Cannibalization ist es immer noch Best Practice, wenn ich zwei Seiten über ein Thema habe, die schwächere Seite mit weniger Content auf No-Index-Stelle und ein Canonical auf die größere Seite setze, soll man überhaupt Seiten, die mittels Canonical auf eine andere Seite verweisen auf No-Index-Stellen. Diese Content-Stücke werden für News oder Teilaspekte von bestehenden Themen erstellt, die für Blogs beziehungsweise Social Media aufbereitet werden. Ich denke, das ist immer ein komplizierter Situation, wo man nicht unbedingt eine Antwort hat, die das wirklich klar beantworten kann. Ich würde das eher in die Richtung auch überlegen, wie das in den Suchergebnissen präsentiert wird. Das heißt, wenn ich zwei Seiten habe, die eher damit kämpfen, dass sie überhaupt sichtbar sind, in den Suchergebnissen, dann würde ich vielleicht die zusammenklappen, damit ich ein bisschen eine stärkere Seite habe, die besser platziert werden kann in den Suchergebnissen. Wenn ich hingegen zwei Seiten habe, die eh schon an erster oder zweiter Stelle in den Suchergebnissen platziert werden, dann ist es ja nicht eine Frage davon, dass man eine stärkere Seite machen muss, damit die noch besser platziert werden kann, weil sie ist ja vielleicht schon an erster Stelle. Dann sehe ich da eigentlich kein Problem, dass man da zwei unterschiedliche Seiten hat, die leicht unterschiedliche Themen auch ansprechen. Ja, da würde ich das eher in die Richtung auch ein bisschen überlegen. Quasi, habe ich etwas zu gewinnen, wenn ich die Seiten zusammenklappe und ein bisschen eine stärkere Seite mache oder ist es an und für sich die gleiche Situation wie jetzt schon? Das denke ich mal, die eine Überlegung, die man da machen kann, das andere bezüglich Canonical und Noindex, an und für sich ist es so, dass wir erwarten, dass mit dem Canonical, dass die Seiten equivalent sind, dass wir wirklich erkennen können, das sind jetzt Seiten, die kann man als eine Version indexieren und nicht Seiten, die an und für sich stark unterschiedlich sind. Das heißt, wenn ich mit einer Seite auf einen Noindex stelle und die andere nicht auf Noindex stelle, dann wären das ja eigentlich schon recht unterschiedliche Seiten, die gar nicht wirklich kombiniert werden können, weil einmal ist ja gar nichts indexiert und einmal ist alles indexiert. Von dem her ist es immer ein bisschen kritisch, vielleicht mal vom theoretischen her, ob man jetzt Noindex und Canonical kombiniert oder nicht. Vom praktischen her sehe ich da aber keine Probleme. Das heißt, mit dem Canonical ist ja eigentlich eher ein Zeichen, dass man eher die andere Seite indexiert haben möchte, wenn man wirklich sicherstellen möchte, dass nur eine Seite indexiert wird, dann kann man mit dem Noindex das an und für sich forcieren. Von dem her ist das etwas, wo man sagen würde, aus dem theoretischen Sicht macht es vielleicht nicht unbedingt so Sinn, aber aus praktischer Sicht stört das auf jeden Fall nicht und das setzt, sag ich mal, euer Willen ein bisschen klarer durch bei den Suchmaschinen, dass ihr wirklich nur diese eine Seite indexiert haben möchtet. Viele Produktvarianten sind auf Noindex. Die Produktvarianten werden auf Übersichtseiten aufgelistet. Für eine übersichtliche Darstellung habe ich die Produktname geändert. Das Problem ist, dass nicht exakt so gesucht wird, wie der Produktname auf der Übersichtseite vorkommt. Ein französisches Beispiel gesucht wird nach Minidrapeau France. Auf der Übersichtseite kommt aber vor France, Minidrapeau. Hätte ich theoretisch einen Ranking-Vorteil, wenn die exakte Sucher auf der Übersichtseite vorkommt. Theoretisch schwierig zu sagen. Also ich denke, in so einer Situation sehe ich überhaupt kein Problem. Was normalerweise da passiert in den Suchmaschinen, ist, dass sie versuchen, die passenden Wörter an für sich zusammen zu suchen. Das heißt, bei den Suchen werden die Suchbegriffe quasi aufgeteilt in einzelne Wörter und dabei ist es nicht unbedingt so, dass wir sagen quasi alles mit einem Leerschlag getrennt und das sind einzelne Wörter, sondern wir versuchen da auch Begriffe zu erkennen. Das heißt, wenn ich zum Beispiel, ich weiß nicht, ein Bild von New York suche, dann ist es nicht so, dass das quasi Bild von New und York, dass alle separate Wörter an und für sich sind, sondern wir können erkennen, dass New York ist eigentlich ein Begriff, das muss quasi zusammengehalten werden. Und dementsprechend ist es so, dass wir dann diese einzelnen Begriffe dann auf den Sucherergebnis-Seiten dann entsprechend suchen und aufgrund von dem dann auch ein bisschen das Ranking machen, natürlich wird da viel mehr noch dazugenommen für die Relevanz von einzelnen Seiten, aber so quasi in der Sicht wird das Arme für sich gemacht. Das heißt, wenn ich Wörter nehme, die wirklich getrennt werden, jetzt, ich denke, in diesem Fall ist vielleicht Mini-Drapeau, könnte man sagen, das ist eine kleine Flagge, vielleicht ist das eher ein Begriff, vielleicht sind das einzelne Wörter, macht eigentlich nicht so ein großer Unterschied und Franz ist quasi ein Ort. Das können wir eigentlich auch erkennen. Ob jetzt die Wörter in dieser Reihenfolge vorhanden sind auf der Seite oder in der umgekehrten Reihenfolge spielt an und für sich keine Rolle. Das heißt, ich würde da eher auf die Begriffe achten, nicht auf die einzelnen Wörter. Und das andere, worauf ich achten würde, ist, dass die Wörter einigermaßen zusammenvorkommen. Das heißt, wenn jemand nach kleiner Tischflager für Frankreich sucht, nicht das Klein- und Tischflager- und Frankreich- irgendwo auf der Seite vorhanden sind, sondern dass sie auch ein bisschen zusammen an einem Ort sind, damit unsere Algorithmen erkennen können, das bezieht sich wirklich auf diese Kombination von Wörtern oder Kombination von Begriffen, sodass wir wirklich erkennen können, diese Seite wäre eigentlich relevant für dieses Suchbegriff. Und von dem her muss man nicht 100%ig eins zu eins die Suchbegriffe wirklich spiegeln, sondern es reicht, wenn wir erkennen können, das passt an und für sich so zusammen. Dazu kommen natürlich noch Synonyme und verschiedene Schreibweisen, die wir auch eher so Richtung Synonyme behandeln. Das heißt, ob jetzt damit umlaut oder ohne umlaut das geschrieben ist mit großem Kleinschreiben, vielleicht, wenn da noch ein Strich dabei ist oder so, das spielt in der Regel keine Rolle, weil wir können erkennen, das ist eigentlich noch das Gleiche und dementsprechend können wir eigentlich noch die gleichen Seiten dazu passend finden. Das heißt jetzt konkret, bei dir würde ich mir jetzt eigentlich nicht groß Sorgen machen, wenn ich eins zu eins in der gleichen Reihenfolge mit genau den gleichen Wörtern der Text vorhanden ist auf den Seiten, wie für das, was du ranken möchtest. Ich habe dazu noch was und zwar in der Suche erscheint, also ihr sucht euch ja dann die Meta Description zusammen, wenn diese Wörter nicht exakt in einer Reihenfolge stehen. Wenn die exakt, also im Deutschen habe ich jetzt die exakte Reihenfolge, so wie auch gesucht wird. Und was dann passiert, im Snippet erscheint dann der Suchbegriff oder der Suchterm am Anfang und danach kommt dann praktisch die Beschreibung zu dem Artikel und es sieht einfach besser aus. Also ich sage mal so, wenn jemand danach sucht, dann würde der eher auf dieses Ergebnis klicken. Im französischen könnte ich das ja auch machen, wenn ich jetzt die Wörter dann ändere und exakt die Suche dann darstelle. Inwieweit spielt das Klicken dann auf dieses Suchergebnis eine Rolle? Also es funktioniert so, wie du es gesagt hast, wenn die Wörter durcheinander stehen, das klappt. Aber inwieweit ist es denn jetzt besser, wenn jetzt noch diese Beschreibung dahinter kommt und es einfach besser aussieht? Da kann ich nicht wahnsinnig viel dazu sagen. Das hängt natürlich davon ab, wie die Benutzer darauf reagieren. Aus meiner Sicht, finde ich, da ist das etwas, was man ausprobieren kann, was man vielleicht ein bisschen testen kann. Ich weiß einigem machen das so, indem das sie zum Beispiel über AdWords einfach verschiedene Textvarianten so relativ schnell testen, weil mit AdWords kann man natürlich ein bisschen gezielter, sag ich mal, so Snippet-Varianten einfach testen. Da kann man genau sagen, diesen Text genau auf diese Weise darstellen und dann für gleiche mit diesen anderen Varianten. Und so kann man relativ schnell herausfinden, welche Variante wirklich am meisten vom Benutzer noch angeklickt wird. Und dann kann man das entsprechend auch auf der Webseite so platzieren. Man kann solche Tests natürlich auch auf der Webseite machen. Das Schwierige ist einfach, dass wir mit dem Snippet natürlich manchmal etwas algorithmisch erstellen. Und dann ist es schwierig, wirklich die Ergebnisse von den Tests zu vergleichen. Aber an und für sich, finde ich, ist, ist das etwas, ja, das macht eigentlich Sinn zu testen, so etwas, dass man da auch einfach mal ausprobiert, welche Variante trifft er, das, wonach der Benutzer sucht und wo der Benutzer dann eher auch durchklicken würde. Okay. Ich habe auch noch mal eine Frage zu meinem Aspekt, den du gerade angesprochen hast. Im Stichwort Begriffe, die umlauter, anders geschrieben sind, Synonyme, mit denen kommt ihr mittlerweile sehr gut klar und könnt das gut erkennen. Wie sieht das aus mit Begriffen, die umgangssprachlich eine andere Definition oder ein anderes Verständnis haben, die nicht unbedingt einen Synonym darstellen? Also ein schönes Beispiel ist, um mal in der Kleidungswelt zu bleiben mit T-Shirts Jeans und Jeanshosen. Jeans könnte rein theoretisch alles Mögliche sein. Das Suchergebnisbild in Google zeigt aber eindeutig, dass hier wirklich die Jeanshosen von Jeanshosen die Erwartung ausgerichtet ist. Aber rein theoretisch könnte es auch Jacken sein und sonstige Dinge sein. Also das übertragen auf alle möglichen Thematiken, also Taschentücher und Tempo, Nutella und Schokoladencreme. Das sind alles so, was es gibt da von deiner Seite? Ja, eine Umgangsempfehlung. Empfehlung ist schwierig zu sagen, weil was? Wir können es noch mal richtig unterbrechen. Bezogen, also die Antwort, die ich mir erhoffe, ist bezogen natürlich auch Umgang, zwei Extraseiten, alles auf eine Seite. Darauf hoffe ich, dass du uns Tipp geben könntest. Okay, wie man das quasi aufteilen kann. Weil normalerweise, was in solchen Fällen passiert, ist, dass wir einfach erkennen können, dass das ähnliche Begriffe sind oder dass das vielleicht sogar Synonyme sind. Intern ist es so, dass wir da, sagen wir mal, einzelne Gewichte für einzelne Synonyme oder Schreibweisen entsprechend haben, wo wir erkennen können, dass wenn jemand nach einem Begriff sucht, dann sind vielleicht diese anderen Begriffe auch einigermaßen relevant. Und wir können dann entsprechend auch ein bisschen zuordnen, dass wir sagen, wenn jemand nach Jeans sucht, dann würde das seit wann mit 80 Prozent der Wahrscheinlichkeit eher auf Jeans Hosen deuten und dann, sag ich mal, 20 Prozent Wahrscheinlichkeit auf Jeans Jacken noch dazu. Und dementsprechend versuchen wir dann, die Relevanz von den einzelnen Seiten zu herauszufinden. Und das ist nicht etwas, was bei uns manuell passiert, sondern wir machen das an für sich automatisch. Wenn wir erkennen können, dass Benutzer, sag ich mal, in ähnlicher in ähnlicher Art Suchen mit anderen Suchbegriffen, dann kommt es bei uns in das System an für sich vor, dass wir denken, gut, der Benutzer hat eigentlich das Gleiche gesucht und hat verschiedene Suchen eingegeben. Also sind diese Suchen vielleicht eher wie Synonyme. Und das ist etwas, was automatisch gelernt wird. Im Laufe der Zeit, das heißt, wenn irgendwann ein neuer Begriff für etwas Bestehendes quasi aufkommt, vielleicht mal umgangssprachlich, dann können wir das relativ schnell auch lernen. Und auch ohne, dass der der Webmaster diese Begriffe direkt auf die Webseite dazunehmen muss. Das heißt, ich verstehe dich gerade so. Oder ich habe diesen Aspekt jetzt auf deine Antwort entnommen. Wenn das Suchergebnis bildt, bleibe ich bei deinem Beispiel 80 Prozent zu Thema A zeigt und 20 Prozent zu Thema B zeigt. Wäre es gut, eine Seite anzubieten, die genau das eigentlich anbietet. Also 80 Prozent der Inhalte sollen an sich mit A beschäftigen und 20 mit B beschäftigen oder dahin führen. Muss nicht unbedingt sein. Ich denke gerade jetzt bei Jeans, Jacken und Jeans, Hosen ist es total okay, wenn man sagt, ich konzentriere mich auf Jeans, Jacken oder ich konzentriere mich auf Jeans, Hosen. Es ist nicht so, dass eine Seite dann besser platziert wäre, wenn sie beide Varianten von diesen, sag ich mal, Überbegriffen dazunehmen wird. Ja, die Schwierigkeit, die ich oder die in der Praxis ich immer gerne sehe, ist auch Online Shops. Also gerade jetzt E-Commerce haben ja auch Automatismen auf den Listen. Und wenn bestimmte Automatismen zeigen, dass ein Jeans, ganz Körper-Kreitungsstück gerade das beliebteste ist, dann und man hat da irgendwie mehrere Versionen dann in seinem Kosmos, also in seinem eigenen Online Shop. Dann ist die Seite zum Thema Jeans nun mal überlagert mit solchen Ganz-Körper-Kreitungsstücken. Das die Erwartungshaltung oder beziehungsweise eine gute Listenseite für Google, wäre ja sich dann ein Stück weit, wie soll ich das ausdrücken, eine gesunde Mitte anzubieten. Also sowohl Jacken als auch Hosen und als auch was auch immer. Ja, also ist eine bisschen Schwierigkeit, aber nicht, dass wir trotzdem vielen Dank an der Stelle. Ja, also ich denke, es ist allgemein schwierig, aber ich würde gerade bei solchen Sachen würde ich mich eher auf den Benutzer ausrichten als auf das, was die Suchmaschinen im Moment machen. Gerade jetzt mit Jeans Jacken und Jeans Hosen und wenn irgendwas Neues mit Jeans aufkommt, dann würde ich nicht versuchen, irgendwie eine vielleicht mal künstliche kombinierte Seite zu machen, die für den Benutzer ein bisschen wehr aussieht, sondern wirklich versuchen zu erkennen, was ist im Moment eben ein Trend, wonach suchen die Leute eher und dass man da sich eher auf das konzentriert und wirklich auch zeigt, wie haben die passenden Informationen zu diesem speziellen Thema, wonach man sucht, auch wenn quasi mit diesem Überbegriff verschiedene andere Sachen auch noch dazu gemeint werden können. Das heißt, ich würde eher, sag ich mal, Seiten versuchen zu machen, die wirklich sehr, sehr gut zu einem Teilaspekt passen, als Seiten, die mittelmäßig für alle möglichen Varianten passen würden. Gerade mit Synonym ist es, war, war mal das, ich glaube, Anfang Jahr haben wir ein Video veröffentlicht von der Webmaster Conference, die wir im Mountain View gehabt haben, letztes Jahr. Und da hat Paul Har eigentlich noch recht spannende Sachen dazu gesagt, wie wir Synonym erkennen und wann wir erkennen können, dass Sachen nicht Synonyme sind. Find ich ein bisschen interessant, das anzuschauen, weil da sieht man dann auch ein bisschen eher, wie die Systeme so etwas automatisch erkennen könnten und wie man da vielleicht als Webmaster darauf reagieren könnte oder halt vielleicht gar nichts Spezielles machen muss. Danke für den Tipp. Schauschnap. Cool. Okay, dann sehe ich dann noch eine Frage zu PageSpeed. Ich habe am November 2019 gelesen, dass Google Websites mit langsamer Ladezeit markieren will. Wir haben ein PageLoad Problem und planen einen Re-Launch mit Text-Doc-Wechsel. Zu wann ist diese Markierung der langsamen Seiten geplant? Haben wir Zeit uns auf den Re-Launch Ende 2021 erfolgen soll, zu konzentrieren? Oder sollten wir noch an der alten Seite weiterarbeiten? Ich weiß nicht, ob wir da ein spezielles Datum haben. Wann man die wirklich markieren würde? Normalerweise ist es auch so, dass wir da versuchen, das nicht allzu weit im Voraus bekannt zu geben. Das heißt, nicht im Voraus bekannt zu geben, was wir planen, außer auf solchen Blog-Posts natürlich. Von daher ist es ein bisschen schwierig. Ich weiß jetzt auch nicht genau, was da alles war. Ich glaube, das war ja speziell mit Chrome. Das war ja nicht eigentlich mit den Suchergebnissen, oder? Genau, das war eine Mitteilung aus dem Chrome-Team, die dann auch verwoben wurde in der Veröffentlichung mit Google-Bevorzug. Ja, eh schnellere Seiten. Und ich möchte halt vermeiden, dass wir da in eine Problematik reinlaufen. Also jetzt könnten wir noch entscheiden, wir ändern den alten Text-Stack. Das ist sehr, sehr aufwendig. Oder wir provisieren uns wirklich auf den neuen Text-Stack und sehen zu, dass wir unseren Re-Launch entsprechend hinbekommen. Wie setzen wir unsere Ressourcen strategisch beim Westen um? Weiß ich nicht, schwierig zu sagen. Ich weiß nicht, die die Sachen bezüglich Chrome ist auch schwierig. Ich weiß jetzt nicht mehr genau, ob da auch irgendwie ein Benchmark bekannt gegeben wurde, wo man gesagt hat, so schnell muss es sein mit solchen Metrics. Wurden nicht genannt. Okay. Es ist einfach nur, wie es auch früher mal war, dass Google gesagt hat, wir wollen unter, wir bevorzugen HTTPS und dann dauert es bis zur Zeit oder wir bevorzugen AMP und dann dauert es auch, bis so einen Sign gezeigt wurde. Das sind schnelle Seite. Und so ähnlich schätze ich das jetzt auch ein, dass Google nicht von heute auf morgen reagiert und als Webmaster auch Zeit haben, uns darauf einzustellen. Nur ich muss jetzt einfach planen, die Ressourcen für einen Fenster von anderthalb zwei Jahren. Ja. Ich vermute, anderthalb bis zwei Jahren vorauszeit können wir da schlecht geben, aber gerade bei solchen größeren Umstellungen, wo man wirklich auch ein gezielt Ziel angeben möchte, wo Websites landen wollten, da ist es schon so, dass wir versuchen, halbes Jahr oder so Vorlaufzeit zu geben. Ich weiß nicht genau, wie das auf der Chrome Seite gemacht wird, aber gerade bei Search ist es so, dass wenn wir größere Änderungen vorhaben in unseren Systemen, wo wir auch gezielt sagen können, das sind Sachen, worauf Webmasters reagieren sollten, dann probieren wir auf jeden Fall, ein halbes Jahr Zeit zu geben. Anderthalb Jahre ist ein bisschen schwierig in der Hinsicht, aber ein halbes Jahr, auf jeden Fall, bevor wir dann auch größere Änderungen in den Suchergebnissen machen, die an für sich vom Webmaster auch ein bisschen beeinflusst werden können. Ja, okay, danke. Ja. Ich vermute, gerade diese Änderung da in Chrome bezieht sich auch wirklich auf Seiten, die sehr, sehr langsam sind. Also nicht, wenn man jetzt so einigermaßen im normalen Rahmen ist, dass man da in ein paar Sekunden die Seite lädt, dann würde ich mir da jetzt keine Gedanken machen, aber wenn wirklich pro Klick dann fast eine Minute geht, bis das geladen wird, dann macht es natürlich Sinn, dass man da den Benutzer wenigstens sagt, wir haben deinen Klick nicht verloren, du musst mich jetzt noch zwei, drei Mal drauf klicken, damit die Seite entwickelt, sondern es geht halt ein bisschen länger. Wir liegen eher bei 25 Sekunden, aber wir sind ... Irgendwann am Mitte, ja, das ist immer der schwierige Bereich. Okay, mal schauen, ob da noch andere Sachen gekommen sind. Ich glaube, das ist ... Ah, da, okay. Ein Client hat Folgendes vorgeschlagen. E N Brandname.Market für Englisch, D E Brandname.Market für Deutsch, F R Brandname.Market für Französisch, und dann im Blog ist dann E N Brandname.Blog und entsprechend. Gründe, die Blogs müssen separat von der E-Com-Domain bleiben. Der Brandname ist nicht für lokale TLD-Endings verfügbar. Ist das okay? Hallen für sich ist das so weit okay. Also, zumindest vom hreflying her würde das funktionieren, von der Suche her kann man damit auch leben. Ich denke, wichtig ist einfach, dass die beiden Varianten gut miteinander verlinkt sind, dass wir kennen können, dass die klar zusammenhängen. Besser ist es natürlich immer, wenn wir eine klare Website haben, die wir in, wo wir die Signale irgendwie ein bisschen sammeln können. Das heißt, gerade die Hauptsprachen, könnte ich mir vorstellen, es ist da ein bisschen unproblematisch. Aber wenn man jetzt Sprachen hat, die nicht so bekannt sind, die nicht so populär sind, dann könnte ich mir schon vorstellen, dass sie da ein bisschen kämpfen in den Suchergebnissen. Einfach, weil wir das ansehen, wie eine separat der Insel statt, dass wir erkennen können, dass das eine gemeinsame Website, die da alles zusammen gehört. Aber handeln für sich, kann man das vom Technischen her, kann man das sicher so machen, gerade wenn die anderen Varianten nicht machbar sind. Vielen Dank, John. John, wenn wir die Cross-Domain ordentlich verlinken, das sollte ja helfen, dass ihr ein bisschen besser versteht, dass es sich hier nicht um singular Entities handelt, sondern um ein Ecosystem quasi dann. Also je besser wir verlinken und wenn wir jetzt Cross-Domain verlinken, kann ich auch No-Follow-Links dann wahrscheinlich benutzen, oder? Weil wir trauen ja unseren eigenen Partnern. Ja, ja, also nicht No-Follow-Links. Wenn wir uns nicht trauen würden. Ja, ja, also nicht No-Follow-Links, würde ich dir empfehlen. Einfach die normalen Links. Und auch wenn wir die Blocks untereinander verlinken, können wir das auch machen. Ja, auch total. Weil wir werden nicht regional IP fordern. Also wir wollen ja, dass die Leute regional dann auf dem regionalen Block oder die Website auch benutzen. Und wenn dann jemand zum Beispiel in Deutschland, aber das den englischen Block lesen will, können wir zum englischen Block natürlich von dem deutschen Block auch mit einem Futterlink verlinken? Ja, klar, kein Problem. Ich denke, gerade die Querverlänkung macht auf jeden Fall Sinn. Und da würde ich auf keinen Fall jetzt No-Follow verwenden, weil das ist ja ein Teil von der gleichen Entity an und für sich. Was auf jeden Fall uns hilft, gerade bei Sprachvarianten, ist, wenn wir eins zu eins die Verlänkung haben. Das heißt, wenn ich bei einem Artikel bin und es gibt die englische Variante von diesem Artikel, dann nicht eine Verlänkung auf die englische Homepage, sondern eine Verlänkung auf die englische Variante von diesem Artikel. Und entsprechend dann auch zurück. Ich habe mir überlegt, ob das vielleicht eine Sache wäre mit so einem Cross-Domain-Canonical, aber es ist ja nicht Canonical, es ist ja eine Übersetzung. Genau. Das heißt, wenn, ganz schnell, das heißt, auch in einem Futter dann von dem Block kann ich quasi schreiben, if you want to read this, ich sage jetzt nur mal, if you want to read this content in English, also nur als jetzt Beispiel, das würde man so nicht machen. Aber man würde die anderen Language-Varianten verlinken. Genau, ja. Das hilft uns auf jeden Fall. Wie es einem User helfen würde, weil ich würde es ja eigentlich erst mal für den User machen, nicht für die Suchmaschine. Aber du sagst gerade, euch würde das helfen, wenn wir das verlinken. Ja, ich denke, für den User macht das auch Sinn, wenn man jetzt zweimal auf einem Produkt landet und es gibt die englische Variante von diesem Produkt oder von dieser Produktseite, dann möchte ich ja nicht auf die englische Homepage gehen, sondern ich möchte ja die gleichen Inhalte auf Englisch sehen, dass da einfach wie im klaren Link zwischen den einzelnen Sprachvarianten gibt, weil dann können wir auch wirklich erkennen, diese Sprachvarianten gehören zusammen und wir sollen da einfach die beste Variante raussuchen aufgrund von diesem Satz von Varianten. Und nicht nur Produktpages, Learningpages, Categorypages, sondern auch Blogposts. Würdest du sehen von den Blogs, dass man die dann mit den anderen Language Assets verlinkt? Wenn man das machen kann, wenn es wirklich Übersetzungen gibt, würde ich das auf jeden Fall machen. Manchmal ist es ja so, dass man nicht für alles eine Übersetzung hat, dann hat man vielleicht als Fallback einfach die Homepage wieder. Aber an für sich, soweit man das machen kann, würde ich das schon machen. Okay, cool. Und das grundsätzlich dieses Environment mit .market, .blog, ich habe da gestern fast drüber gelacht, als es vorgeschlagen wurde, aber wahrscheinlich müssen wir es so machen. Also, ja. Also, aus unserer Sicht könnt ihr das machen, wie ihr wollt. Ich denke da, es gibt einzelne, die würden vielleicht mit .market, Bindestrich, blog.com oder so arbeiten, aber das, das kann man ja nicht machen. Das wollten wir nicht. Ja. Ja. Okay, cool. Dankeschön. Ich denke, die einzelne Frage, wo ich vielleicht noch überlegen würde, ist, ob man jetzt mit Subdomains oder Subdirectories arbeitet. Ja. Da gibt es starke Meinungen irgendwie in beide Richtungen. Aber normalerweise spielt das keine große Rolle. Ich könnte mir vorstellen, gerade mit so, sag ich mal, selteren Sprachvarianten, würde man wahrscheinlich besser mit Subdirectories arbeiten. Wenn das wirklich jetzt nur diese drei Sprachvarianten haben, sehen wir dann... Nur die drei geben vielleicht noch zwei mehr, aber es wird nicht mehr als fünf Sprachvarianten geben, in diesem Fall. Meine Überlegung war, ich würde mir gerne die Subdomains sparen und würde mit Folder arbeiten, weil ich dann weniger Sachen, weniger für die Data Analysis natürlich. Ja. Weil wenn ich es mehr zusammengepackt habe, habe ich einfache Möglichkeiten, glaube ich, den Überview da besser zu bewahren. Mit den Subdomains muss ich jedes einzeln, habe ich für jedes einzeln natürlich dann die Sachen. Ja. Aber gut. Aber gut. Ja. Manchmal ist es halt so, dass man nicht das nehmen kann, was einfacher ist für SEO oder einfacher für quasi Analytics nachher, sondern es gibt halt andere Überlegungen, die da im Vordergrund sind. Gut. Ich lag dann vielleicht noch mal die Subfolder-Variante vor. Mal gucken, ob das dann noch mal rauskommt. Vielen Dank. Gut. Glücklich. Könnte ich zu dem Link noch eine Frage stellen? Ja, klar. Ich habe jetzt von jeder unter, also wir haben auch so ein Setup mit fünf verschiedenen Sprachen, also auch Regionen, und jetzt habe ich aber auf jeder Seite auch diesen Homepage-Link. Also nicht nur in diese Produktvariante, sondern auch auf die Homepages. Weil ich mir dachte, okay, die Homepages wollen wir, möchte ich auch noch ein bisschen stärken. Mache ich dadurch irgendwas kaputt? Nein. Das sei nicht auch okay. Ja. Also die Homepages renken nicht unbedingt gut. Also die sind nicht so, wie ich es haben möchte eigentlich. Also mache ich damit irgendwas kaputt ein? Nein. Und die Unterseien da auf dieser anderen Sprachen-Linke? Also man kann das nicht, also man kann es auf beide Varianten machen. Ich denke, in der Praxis hat man das auch auf einzelnen Seiten in beiden Varianten, dass man dann vielleicht eher am Futter, dass man die Homepages von den einzelnen Varianten verlinkt hat und dann im Inhalt oder oberhalb vom Inhalt dann quasi diesen Sprachwechsel-Link hat. Ich sehe da kein Problem in beide Richtungen. Ich würde einfach wirklich sicherstellen, dass wenn möglich, dass man diesen Sprachwechsel-Link, das heißt die Varianten, den Link, dass man den auf jeden Fall hat. Und das mit den Homepages ist eher, sag ich mal, optional, dass man das, wenn möglich, noch dazu hat, aber es ist nicht das kritischste. Okay. Dann habe ich noch eine Frage. Ich würde gerne eine Website, also einen Domain, in die Cloud verschieben. Jetzt ist es so, dass diese IP-Adressen ja auch von anderen benutzt werden. Vorher, also man nimmt sich ein Server und dann bekommt man eine IP-Adresse. Kann es sein, dass so eine IP-Adresse in die Gebläckliste ist bei euch oder nur die Domain? An und für sich nicht. Also es gibt sehr, sehr seltene Situationen, wo wir sagen würden, eine IP-Adresse ist problematisch, aber das bezieht sich wirklich auf Situationen, wo wir erkennen können, das sind 50.000 Spam-Websites auf einer IP-Adresse und dann ist vielleicht noch eine andere Website auf dieser IP-Adresse. Dann kann es sein, dass unser Web-Spam-Team vielleicht eher sagt, gut, alles da ist problematisch, weil sie einfach diese anderen Sachen gar nicht mehr finden in der großen Menge. Bei all den normalen Cloud-Providers, wo man gemeinsam geteilte IP-Adressen hat, ist das aber nicht der Fall. Es ist ja nicht so, dass 99% der Websites auf dieser IP-Adresse Spam sind und dass dann ein kleiner Teil okay ist, sondern es ist ja einfach irgendeine Mischung von guten Websites, schlechten Websites, mittelmäßigen Websites und die wächst dann vielleicht je nach Standort, die IP-Adresse auch und das ist total unproblematisch. Es ist wirklich sehr, sehr, sehr selten, dass wir sagen würden, da mit dieser IP-Adresse ist da etwas problematisch. Okay, super. Cool, ich glaube, fragenmäßig sind wir da ziemlich am Ende bei den eingereichten Fragen. Wenn es noch irgendwas aus eurer Sicht gibt, seid ihr gerne dazu eingeladen und Zeit haben wir eigentlich auch gerade geschafft. Vielleicht wenn noch eine kurze Frage von einem von euch ist, legt nur los. Okay, wenn nicht, ist das auch super. Okay, gut. Dann machen wir vielleicht Pause hier. Morgen haben wir, glaube ich, auf Englisch noch ein Hangout, wenn ihr weitere Fragen noch dazu habt. Sonst richtig die nächsten wieder ein in zwei Wochen. Vielen Dank fürs Kommen. Vielen Dank für die vielen Fragen und dann wünsche ich euch noch ein gutes zwei Wochen. Bis zum nächsten Mal. Bleibt gesund. Bis dann. Winke winke.