 Hallo allerseits, ich bin Johannes Müller, Webmaster Trends Analyst hier bei Google in der Schweiz und Teil von dem, was wir machen, hier sind die Webmaster Sprechstunden Hangouts, wie jetzt hier, wo Webmasters, SEOs, Publishers allgemein dazustoßen können und ihre Fragen und Feedback für uns jeweils geben können. Ich hoffe, ihr hattet einen guten Start ins neue Jahr und wünsche euch ein frohes neues Jahr. Ich hoffe, da läuft alles positiv bei euch dieses Jahr. Wie immer sind da schon einige Fragen eingereicht worden, aber wenn ihr wollt, könnt ihr gerne schon mal loslegen und die ersten Fragen hier direkt stellen. Wenn nicht, ist das auch okay. Dann fange ich mal an mit den Fragen, die eingereicht worden sind. Beide Rezeptzuche, z.B. Silvesteressen oder Fondue oder Mittagessen-Ideen, zeigt Google Rezeptkarussells mit Rich Cards an. Die Rich Cards enthalten URLs, die keine einzelnen Rezepte enthalten, sondern Rezept-Sammlungen und Tipps. Und es geht, glaube ich, ein bisschen weiter in Richtung, also das sind ja dann keine Seiten, die nicht nur ein Rezept haben, sondern verschiedene, ist das problematisch oder nicht. Grundsätzlich ist es so, mit den Rich Results Types wollen wir, dass ein Hauptelement auf dieser Seite existiert und, dass ihr das entsprechend markiert, mit dem entsprechenden Searcher Data Markup. Das heißt, wenn da verschiedene Rezepte drauf sind, auf einer Seite sollte das nicht mit einem Rezept vermerkt sein, sondern es gibt eine spezielle Art, das anzugeben mit dem Karussell Markup. Das heißt, wenn man z.B. nach Rezeptkarussell sucht, auf der Search Developer-Seite gibt es da einige Informationen, wie man das machen kann, dass man da, sagen wir, eine Seite mit verschiedenen Rezepten zu einem Thema oder verschiedenen Arten von Gegenständen, die zusammengefasst werden können in einem Karussell, dass man das so angeben kann. Und da würde ich, wenn möglich, schon schauen, dass man da das Richtige verwendet. Es kann sein, dass unsere Systeme das trotzdem verwenden, wenn man das falsch angibt. Aber möglicherweise werden dann unsere Kollegen beim Web Spam Team entsprechend da einspringen und dann sagen, das ist eigentlich nicht so, wie es gedacht ist und das wird dann unter Umständen als Spam markiert. Wenn es das Spam markiert wird, ist es nicht so, dass wir die Website dann abstufen würden oder dass wir da irgendwie größere Abstrafungen oder so etwas machen würden, sondern für uns bedeutet das einfach, dass diese Art von Structured data auf diesen Seiten ist für uns problematisch, wie das angegeben ist, also ignorieren wir das. Das heißt, die Inhalte der Website werden weiterhin in der Suche dargestellt. Wir schicken euch eine Nachricht über Search Console und weisen euch darauf hin, dass ihr das irgendwie falsch markiert habt in den Seiten und wenn das korrigiert ist, wird das entsprechend wieder freigeschaltet, dass wir diesen Rich Results-Tippen wieder darstellen können in den Suchegebnissen. Von dem her würde ich schon empfehlen, dass wenn man das macht, dass man das richtig macht, es ist allerdings nicht, sei ich mal, super problematisch, wenn man das falsch macht und vielleicht nicht genau weiß, wie man das machen sollte und das dann einfach falsch markiert hat, dann kann das unter dem Ständen einfach über das Webspam-Team so zurückgemeldet werden und so quasi an euch zurückgegeben werden. Das könnt ihr eigentlich verbessern und wenn ihr das verbessert habt, können wir das wieder normal in den Suchegebnissen zeigen. Eine Frage dazu. Ja. Was für eine E-Mail kommt denn dann, steht dann explizit Spam-Meldung dort drin? Also bei mir kommt häufiger Probleme mit Structured Data, zum Beispiel in Navigationspfade gefunden. Ist das dann sowas oder kommt dann explizit Spam-Meldung? Da kommt explizit eine Meldung über die manuellen Maßnahmen in Search Console, kommt dann effektiv so. Ich glaube, die Meldung, die du kriegst, ist vom Search Console selber, wenn wir einfach technische Probleme mit dem Markup finden. Das heißt, wenn technische Probleme da sind, das können wir relativ gut automatisiert testen. Wenn das einfach logisch falsch eingerichtet ist auf der Seite, dass die falschen Chippen verwendet werden. Technisch ist es schon okay, also korrekt markiert, aber ihr habt quasi das falsche markiert. Dann sind das Sachen, die man eher manuell anschauen muss und dass man dann da eine manuelle Maßnahme dann so bekommt. Im Text ist es manchmal ein bisschen streng geschrieben, gerade bei den Rich Results-Tippen, weil in den meisten Fällen ist es ja nicht so, dass man da wirklich versucht Spam zu machen. Es läuft einfach über unser Spam-System. Oft ist es ja einfach so, dass man nicht genau weiß, wie man das richtig machen soll und dann macht man das halt mal falsch und irgendwann merkt jemand, das ist falsch implementiert dort, technisch schon korrekt, aber einfach die falschen Sachen markiert. Wir haben das Problem, dass Googlebot einige Suchseiten, welche kein Inhalt zurückliefern gekraut hat und dieses Duplicate Content deklariert. Dieses ist erstmal kein Problem, da wir sie auch nicht auf Google haben wollen. Der Googlebot geht jedoch nun seit Monaten immer wieder auf diese zurück und versucht sie zu crawl. Wir haben überlegt die Seiten per Metatag, no index, no follow. Jedoch ist die Frage, ob Googlebot das akzeptieren würde, wenn wir es im Nachhinein mittels JavaScript setzen. Ja, ich denke, da kommen verschiedene Sachen zusammen. Wahrscheinlich ist es nicht so, dass wir sagen, dass das Duplicate Content ist, sondern eher, dass wir sagen, das ist eine Soft 404-Seite. Eine Soft 404-Seite ist an und für sich eine Seite, die einen normalen Statuscode zurückgibt, wo aber im Inhalt der Seite dann steht, wir haben eigentlich keine Informationen für euch. Das kann zum Beispiel eine richtige Fehlermeldung sein, dass wir sagen, es ist effektiv, diese Seite existiert nicht oder es kann so eine Art Suchseite sein, wo ihr dann einfach sagt, grundsätzlich ist das schon eine korrekte URL, aber zu diesem Thema haben wir jetzt keine Inhalte, die wir darstellen können. Und dann würden wir das als Soft 404 melden. Es kann auch sein, dass in einigen Fällen, dass wir sagen, wir haben viele von diesen Seiten gefunden, wir sehen das dann an, dass wir ein anderer URL als Canonical gewählt haben, das anfühlt sich auch okay. Grundsätzlich wäre es technisch schon besser, wenn man einen klaren 404-Statuscode zurückgeben kann oder wenn man zumindest ein Noindex zurückgeben kann, dann lässt es für uns ein bisschen einfacher erkennen, dass wir diese Seiten so nicht indexieren müssen. Grundsätzlich kann man das aber nicht immer in allen Fällen so einfach machen. Gerade bei Suchseiten ist es ja so, dass man da erstmal diese Suche machen muss und dann merkt man erst im Nachhinein, ah, eigentlich haben wir zu diesem Thema keine Inhalte, die wir darstellen können. Und von dem her ist es haben für sich nicht so problematisch, wenn man sagt, wir lassen das als Soft 404, dass Google die Seiten zwar crawlen kann, dass die aber dann eigentlich als 404-Seiten behandelt werden. Längerfristig, was dann passiert, ist, dass wir solche Seiten einfach weniger auf crawlen. Das heißt, wir crawlen sie immer noch. Es ist nicht so, dass das Crawlen ganz verschwinden wird, aber wir machen es einfach weniger häufig, weil wenn wir regelmäßig sehen, dass unter diesen URLs da keine effektiven Inhalte vorhanden sind, dann müssen wir die ja nicht so häufig anschauen. Das heißt, je nachdem, wie du das in Search Console anschaust oder in euren Serverlots, wird es wahrscheinlich weiterhin so sein, dass wir die Seiten ab und zu anschauen. Problematisch ist das aber nicht. Ich hätte dazu noch eine Frage. Ja, also es geht folgendermaßen. Wir können kein direktes 404 oder sowas senden, weil wir haben eine reine JavaScript-Set. Das hatten wir ja auch vor Weihnachten schon mal, deswegen hatten wir da jetzt schon mal was geändert. Und jetzt ist es halt so, ja gut, prinzipiell mag es vielleicht nicht schlimm sein, aber ich konnte feststellen in das Search Console, dass er dieselben Seiten immer und wieder aufruft, die effektiv keine Inhaltszeit zurückkartiv hat. So, jetzt sagtest du, 404 wäre gut. Wäre es denn sinnig, wenn ich sage okay, wenn der Googlebot kommt, die Seite gibt kein Ergebnis zurück. Und ich kann ja feststellen anhand vom User-Edge, dass der Googlebot ist, dass ich ihn dann redirecte auf den 404, oder ist das dann cloaking schon? Das ist auch okay, ja. Das wäre okay. Ja. Oder wäre nur folder und index besser, wenn ich das als Metatext nachländen würde. Das ist halt ja die effektive Frage. Ich denke, beide Varianten würden gehen. Von dem her würde ich das nehmen, was für euch am einfachsten ist. Normalerweise ist es, also optimal wäre es natürlich schon, wenn wir direkt 404 zurückkriegen könnten, aber bei JavaScript-Sites geht das ja nicht. Oder zumindest nicht so einfach. Und da gibt es eigentlich die beiden Varianten, dass man sagt, wir setzen die Seite auf noindex und haben quasi die Fehlermeldungen da für den Benutzer auch. Wir haben jetzt nichts zu diesem Thema. Oder dass man ein redirect per JavaScript macht auf eine wirkliche 404-Seite. Und dass das dann da nach diesem redirect Googlebot wirklich auch klar an 404 sieht. Anführs sind beide Varianten okay. Ich denke, in beiden Fällen müssen wir auf jeden Fall den JavaScript ausführen, damit wir das sehen, also den noindex oder den 404. Von dem her würde ich das dir überlassen, wie du das am ehesten machen würdest. Ja, also für den Users ist ja schon ersichtlich, dass es halt keine Inhalte zurückliefert, nur für den Googlebot halt nicht. Weil der interessiert sich ja dann nicht für den Text, der angezeigt wird. Ja, gut, aber dann weiß ich Bescheid. Perfekt, danke. Super. Dann eine Frage zu sprechenden URLs. Sind sprechende URLs für gutes Ranking noch relevant? Wir prüfen derzeit, ob wir im CMS die sprechenden URLs durch URLs mit IDs ersetzen und stattdessen die sprechenden URLs nur noch im Canonical Tag der jeweiligen Seite platzieren. Macht das Sinn? Oder würdest du davon abraten? Grundsätzlich ist es so, dass die Wörter in einer URL eine sehr, sehr kleine Rolle spielen. Das heißt, wenn wir Inhalte auf den Seiten finden, dann sind die auf jeden Fall viel stärker für uns bewertet als irgendwas in der URL. Von dem her ist es nicht kritisch, dass man sprechende URLs hat oder URLs, wo die Keywords quasi drin erwähnt werden. Von dem her, wenn man eine neue Website aufbaut, ist das an und für sich euch überlassen, wie man das machen möchte. Bei vielen CMS ist es so, dass man automatisch schon sprechende URLs hat oder URLs mit Wörtern zumindest drin. Das ist aus unserer Sicht auch okay. Es ist nicht so, dass man das eine oder andere machen muss. Das Einzige, wo ich ein bisschen vorsichtig wäre oder vielleicht zwei Sachen, gerade bei dieser Frage, ist einerseits eine Umstellung der URLs von sprechenden URLs auf IDs. Eine solche Umstellung ist für uns gesehen eine relativ große Umstellung, weil alle URLs auf der Website auf einmal anders sind. Das heißt, wir müssen dann die gesamte Website erstmal neu crawlen, die ganzen neuen URLs erkennen, die internen Links entsprechend den allen folgen und anfühlen sich ein neues Bild der Website aufbauen mit den neuen URLs. Das heißt, egal wie man die URL-Struktur verändert, ob man auch von ID auf Text geht oder von Text auf einen anderen Text oder von HTM auf HTML am Ende geht, solche größeren Umstellungen innerhalb von einer Website brauchen einfach eine gewisse Zeit, bis wir die sauber verarbeiten können. Von dem her ist es etwas, was ich nicht unbedingt quasi einfach so mal angehen würde und umstellen würde, sondern wo ich wirklich überlegen würde, was ist längerfristig das, was ihr haben wollt und wie kann ich möglichst schnell zu dieser längerfristigen Struktur wechseln, damit ich nicht zwischendurch immer wieder wechseln muss. Das heißt, möglichst einmal umstellen und das beibehalten und nicht quasi einfach mal die ganze URL-Struktur einer Website mal kurz ausprobieren, wie das wäre, wenn wir das anders hätten. Das ist mal das eine, also nicht einfach beliebig die URL-Struktur verändern, das andere mit dem Canonical. Wenn ihr die Situation habt, wo quasi durch das Crawling der Website eine URL-Struktur kommt und per REL Canonical eine andere URL-Struktur angegeben wird, dann haben wir immer ein bisschen Konflikt. Das heißt, wir sehen da einige Signale, die uns sagen, diese URL-Struktur, also mit dem E-Days, wenn das zum Beispiel so verlinkt ist, ist relevant und mit dem REL Canonical und eigentlich hätten wir lieber diese Text-URL-Struktur. Und was dann praktisch gesehen bei uns passiert, ist, dass wir pro Seite diese beiden Varianten abwägen müssen und dann jeweils pro Inhaltsstück entscheiden müssen, sollen wir das mit ID indexieren oder sollen wir das mit dieser sprechenden URL indexieren. Und aus meiner Sicht finde ich das ein bisschen problematisch, weil ihr habt wahrscheinlich Vorstellungen, wie ihr diese Seiten indexiert haben wollt und ihr möchtet wahrscheinlich das so haben, dass es möglichst effizient vorgeht. Und gerade für diese beiden Situationen würde ich dann schon schauen, dass man möglichst gezielt auf die Variante verweist, die man wirklich indexiert haben möchte. Das heißt, wenn ihr mit IDs arbeiten möchtet, dann würde ich wirklich alles umstellen auf die IDs. Das heißt, auch den REL Canonical, auch hreflang, wenn ihr das verwendet, auch andere interne Verweise, zum Beispiel im Structuredata, das ist wirklich alles auf die neuen URLs wechselt. Wenn ihr hingegen sprechende URLs beibehalten wollt, dann würde ich schauen, dass wirklich auch intern alle Verlinkungen, alle Verweise jeweils auf die sprechenden URLs gehen, das anfühlt sich so weit wie möglich, gar kein Vermerk von diesen IDs überhaupt auf der Website vorhanden ist, dass man wirklich nur das finden, was ihr eigentlich indexiert haben möchtet. Und eben der Vorteil ist zweifältig. Einerseits ist es so, dass es für uns effizienter ist zum Crawling und Indexing. Wir sehen nur eine Variante. Wir folgen diese Variante und können die sauber indexieren. Anderseits ist es für euch dann viel klarer, was wir auch effektiv machen, weil wenn wir eine Variante sehen, dann müssen wir nicht entscheiden, welche Variante wir jetzt indexieren. Dann ist es für euch in den Statistiken, in den Log-Files, überall an und für sich viel klarer, das ist die Variante, die ihr wollt. Wir übernehmen das so und zeigen das dann so auch an in den Suchergebnissen. Also je klarer ihr uns die Signale geben könnt, umso besser. Das heißt, wenn ich die Frage jetzt gesamthaft nochmal anschaue, einerseits quasi die Umstellung auf die IDs, ich würde eine solche Umstellung nur machen, wenn ihr wirklich große Vorteile seht, intern oder sonst wie innerhalb der Website für die neue URL-Struktur, weil wie gesagt, das dauert eine gewisse Weile, bis das umgestellt wird. Und zweitens würde ich schauen, dass wenn ihr eine Umstellung macht, dass ihr das möglichst durchspannt auf der ganzen Website mit allen URLs macht. Kann ich dazu noch eine Frage stellen? Ja. Wenn ich eine URL in den strukturierten Daten, zum Beispiel in einem Produkt drin habe, also es gibt ja, da kann man halt diese URL angeben und auf der Seite gibt es keinen Link zu dem Produkt. Was macht ihr damit mit den strukturierten Daten und der URL? Also gilt die nur zum Auffinden von Produkten oder wird da irgendwas weitergegeben? Irgenden Signal? Ich weiß jetzt nicht genau, wie das bei dem Produkt Markup gemacht wird. Aber oft ist es ja so, dass man da eine URL angebt, die quasi der Verweis ist, innerhalb der Website, wo dieses Element aufzufinden ist. Und da ist es so, dass wir in solchen Fällen versuchen, wir die URL zusammenzuführen, mit dem, was wir effektiv indexiert haben. Ich weiß jetzt nicht ganz genau, wie das bei einem Produkt Daten ist, aber ich nehme an, dass man da zum Beispiel im Markup hat, das ist jetzt dieses Produkt und das ist die URL zu diesem Produkt. Und wenn das so der Fall ist, dann versuchen wir natürlich, diesen Verweis in den strukturierten Daten mit unserem Index abzugleichen, dass wir effektiv sehen, ah, da ist dieser Verweis auf diese Seite, auf diese Produktseite, diese Seite haben wir auch so indexiert. Und dann kann man das relativ gut zusammenführen. Wenn hingegen der Verweis wirklich nur in den strukturierten Daten ist und nicht verlinkt wird innerhalb der Website, dann vermute ich, dass wir dem nicht folgen würden und nicht dann losgehen würden und diese Seiten versuchen zu crawlen. Sondern dass es effektiv, nur wenn wir schon diese Seiten indexiert haben, dann kann man über die strukturierten Daten, die ein bisschen sauber verknüpfen. Macht das Sinn? Ich vermute, ich müsste mal die Produktstrukturierten Daten ein bisschen genauer anschauen. Ich hätte auch noch eine Frage zu den URL. Okay. Und zwar galt früher ja mal als Best Practice die URLs möglichst kurz zu halten. Also vielleicht ein Keyword slash das nächste Keyword, also je nachdem, welche Navigationstiefel man geht, ist das heute immer noch so? Das wäre Teil 1 der Frage und Teil 2 macht die Navigationstiefe für euch ein Unterschied. Ähm, die Länge der URLs spielt bei uns eigentlich nur eine Rolle, wenn es darum geht, ein Canonical auszusuchen. Das heißt, vom Ranking her ist das total egal, man kann lange oder kurze URLs haben, aber wenn wir verschiedene URLs haben, die die gleichen Inhalte zurückgeben, wenn wir quasi so eine Gruppe von URLs haben, von denen wir einen Canonical aussuchen müssen, dann ist es so, dass wir eher zu den kürzeren URLs greifen würden. Das heißt, wir haben ja verschiedene Signale, die in Canonical und die uns helfen, einen Canonical auszuwählen, mit dem REL Canonical und internen Verlinkung, externen Verlinkung, Sitemaps, all das und die Länge der URL spielt da auch eine kleine Rolle. Das heißt, wenn ich zum Beispiel eine URL habe mit einem Parameter hinten dran und eine URL habe ohne Parameter, dann nehmen wir an, wenn wir einen REL Canonical haben, dann würden wir eher die als Canonical nehmen. Aber vom Ranking her spielt das überhaupt keine Rolle. Also mit Ranking meinst du jetzt den Wettbewerb extern, ja? Also was du jetzt vorher gesagt hast, war ja der interne Wettbewerb auf der eigenen Seite und das andere wäre der externe. Genau. Alles klar, vielen Dank. Und bezüglich der Tiefe der Verlinkung die Unterverzeichnisse zählen würden, sondern da spielt eigentlich eher einfach eine Rolle, wie diese Seite innerhalb der Webseite verlinkt ist. Das heißt, bei den meisten Webseiten ist es ja so, dass die Startseite eher die stärkste Seite ist innerhalb der Webseite. Die meisten Links gehen irgendwie dahin. Das ist oft die am bekanntesten Seite und von dort aus folgen wir natürlich dann den Links und die Sachen, die dann einfach näher verlinkt sind von der Startseite aus. Sind in vielen Fällen dann Seiten, die eher auch relevanter sind ein bisschen wichtiger für uns und den verfolgen wir an und für sich dann ein bisschen stärker. Das heißt, wir crawlen die vielleicht ein bisschen häufiger. Wir schauen, dass wir die bei der Indexierung ein bisschen berücksichtigen können. Und da spielt wenig eine Rolle, wie viele Unterverzeichnisse quasi dabei sind, sondern einfach wie das verlinkt ist von quasi einem Hauptelement der Webseite, ob das jetzt nahverlinkt ist oder ob das einfach über verschiedene Zwischenschritte verlinkt ist. Da hätte ich auch noch eine Frage zu. Die Struktur einer Webseite bei uns sind es Flaggen. Also Flaggen ist bei uns praktisch die Homepage. Dann geht es weiter Europa, Asien, Afrika. Wenn man jetzt in Europa Links setzt zu den einzelnen Ländern, zum Beispiel Deutschland, Italien und so weiter, ist das dann für Google eine Struktur her besser zu erkennen. Also, dass man dann nicht so viele Querlinks macht. Spielt das da noch eine Rolle beim Ranking? Besser zu erkennen. Schwierig zu sagen. Uns hilft an und für sich schon eine gute Struktur auf einer Webseite. Hilft uns ein bisschen besser die einzelnen Seiten im Kontext der Gesamtwebsite zu sehen. Das heißt, wenn wir einzelne Flaggen zum Beispiel in deinem Fall einfach nur unter Europa verlinkt sehen, nehmen wir an, dass diese Europa-Seite wie eine Art Überbegriff ist für diese Unterprodukte, die da alle vorhanden sind. Dann ist es nicht so, dass wir da einen großen Ranking-Vorteil dazu bringen können. Aber es ist dann ein bisschen einfacher für uns zum Beispiel, ich weiß nicht, spanische Flaggen in Europa sucht oder irgendeine Kombination. Dann ist es für uns ein bisschen einfacher, diese Seiten entsprechend darzustellen in den Suchergebnissen. Das heißt, Besser ist es schon, wenn man eine saubere Struktur auf der Webseite hat. Das hilft uns den Kontext der Seiten ein bisschen besser zu erkennen. Aber wahrscheinlich vom Praktischen her ist es nicht so, dass man auf einmal einen großen Ranking-Vorteil hat. Sondern es ist eher so, dass wir eher die richtigen Suchanfragen an die richtigen Seiten bringen können. Und profitieren die Unterseiten davon, wenn eine Hauptkategorie verlinkt. Ja, an und für sich schon. Das ist eigentlich ähnlich wie mit dem anderen Fall. Das heißt, wenn etwas von einer starken Kategorien- Seite verlinkt wird, dann nehmen wir an, dass von dieser stärkeren Seite das die Verweise da auch eher relevanter sind, als wenn diese Produkte von weniger starken Seiten verlinkt werden. Also sollte man dann sehr gute Kategories Seiten machen? In vielen Fällen macht das Sinn. Ich denke, da muss man natürlich auch ein bisschen abwägen. Einerseits ist es ja so, dass vom Ranking her, dass wir versuchen würden, die starken Seiten zu erkennen. Andererseits ist es aus deiner Sicht vielleicht auch interessant, ein bisschen klarer darzustellen, welche Seiten du effektiv indexiert haben möchtest. Und es kann durchaus sein, dass diese Seiten eigentlich gar nicht indexiert haben, weil ich möchte, dass Leute direkt auf Unterkategorien gehen oder vielleicht direkt zu den Produktzeiten gehen. Und dann hat man halt die Situation, dass man sagt, theoretisch könnte diese Kategorien- Seite gut in den Suchergebnissen erscheinen, aber ich möchte sie doch nicht erscheinen lassen. Deswegen setze ich halt ein New Index drauf oder irgendwas anderes. Mit der internen Verlinkung und dass man das so ein bisschen zurückstuft. Aber in den meisten Fällen ist es schon so, dass man sagt, die Oberkategorien sind auch relativ relevant. Okay, danke schön. Wenn ich dann nochmal ganz kurz einhaken darf in der Verlinkung von der Startseite auf die Kategorieseiten. Ich spiele mit dem Gedanken auf einer Startseite, die Kategorieseiten mit zwei Möglichkeiten anzugehen. Das erste ist im oberen Bereich irgendwelche Kacheln. Und im unteren dann etwas Text und der erklärt, worum geht es dann auf der Kategorieseite, die darunter verlinkt ist. Und dann geht es dann nachher, erfahren Sie mehr wenn Sie hier klicken beispielsweise. Also würde jede Kategorieseite von der Startseite aus zweimal angelinkt werden. Macht es Sinn oder ist es schon wieder das Bämme? Das ist ganz okay. Ja, überhaupt kein Problem. Okay, super, danke. Okay, dann viele vielen Suchergebnissen mit mehreren Suchwörtern unter Anführungszeichen findet man in den letzten Monaten unzählige Spam-Einträge. Und da zum Beispiel einige Beispiele, warum unternehmt Google nichts dagegen. Ja, Google müsste das mal alles aufräumen. Anführe sich was, was ich einfach sehe oft in solchen Situationen ist es, dass wir einfach nicht unendlich viel Inhalte haben für einige Suchanfragen. Und wenn man gezielt nach solchen Sachen sucht, gerade in Anführungsstrichen, dann gibt es halt einfach eine begrenzte Menge von Möglichkeiten, die man da bringen kann. Und wenn dann dabei noch einige Seiten sind, die diese Begriffe auch drauf haben, die einfach minderwertig sind, vielleicht Spam-Eik, vielleicht nicht, dann kann es durchaus sein, dass wir die trotzdem in den Suchergebnissen zeigen. Aus unserer Sicht ist das etwas, was schon einigermaßen unerwünscht ist. Aber andererseits ist es natürlich auch so, dass fast niemand nach diesen Arten von Begriffen sucht, gerade in Anführungsstrichen. Von dem her ist es dann für uns dann oft auch einfach eine Frage vom Aufwand lohnt es sich, für uns Sachen aufzuräumen, die niemand in den Suchergebnissen sieht. Die sind vielleicht Spam-Eik, die sind vielleicht Low Quality, aber wenn so gut wie niemand die in den Suchergebnissen sieht, weil fast niemand so danach sucht, macht es überhaupt Sinn, dass man da manuell noch eingreift und das auch noch aufräumt. In vielen Fällen sagt man dann einfach, gut, es ist halt nicht optimal, aber es ist auch nicht etwas, das müssen wir dann jetzt nicht manuell noch eingreifen und das quasi herausholen. Manchmal ist es ein bisschen schwierig, weil vielleicht doch noch gute Inhalte weiter hinten sind, aber das ist gerade bei solchen Suchbegriffen, die sehr, sehr selten verwendet werden, ist es natürlich schwierig für uns zu sagen, wie stark lohnt es sich, dass wir da manuell eingreifen und manuell den Spam oder den minderwertigen Inhalte quasi auch ganz aus dem Index herausholen. Wie wichtig ist das Modified Date für Google News? Es gab vor einigen Monaten ein Blog- Beitrag zur Newsoptimierung, allerdings sieht man immer mehr, dass die meisten Publisher in den News das Published Date einfach überschreiben und somit nicht das Modified Date nutzen, sondern das Published Date aktuell halten. Meist in Kombination mit einer URL-Änderung fällt vor allem auf, wenn man aus User den exakt gleichen Artikel in kurzen Abständen zu Gesicht bekommt. Ich finde das auch ein bisschen problematisch, wenn man da einfach einen bestehenden Artikel abendert und auf einmal eine andere URL verwendet ist, glaube ich, aus Google News sieht auch etwas, was in den Richtigen jeweils steht, dass man das nicht machen sollte. Allerdings weiß ich nicht genau, wie und was da genau bei Google News gemacht wird. Das ist ein bisschen eine andere Gruppe intern bei Google. Grundsätzlich ist es aber schon so, dass wir gerade bei News Inhalten hilft und sein Datum sehr nicht speziell für Google News. Da weiß ich jetzt nicht genau, wie das gemacht wird dort, aber gerade in der normalen Suche. Und was man da auch machen kann, ist, das Datum per Structure Data auch angeben, dass man wirklich auch gezielt angeben kann. Diese Seite wurde an dem Tag geschrieben oder hat dieses Datum entsprechend passend dazu. Weil das ist auch etwas, was in Vergangenheit manchmal so hundertprozentig geklappt hat, dass wir da vielleicht das falsche Datum herausgezogen haben aus einer Seite, wenn zum Beispiel in Sidebar auch noch ein Datumsangaben von anderen Artikeln vorhanden ist, dann ist es manchmal für uns schwierig gewesen, das Richtige herauszuholen. Mit Structure Data kann man das ein bisschen genauer angeben. Der andere Ort, wo das Datum wichtig ist, ist, wenn man mit einer Sign-up-Datei arbeitet, da kann man ja auch das letzte Datum angeben. Und dort ist es dann so, dass wir beim Verarbeiten das Sidemap, wenn wir diesen Änderungsdatum trauen können, versuchen wir das ein bisschen schneller dann zu crawlen und indexieren. Das hat aber eigentlich jetzt nicht speziell für Google News, sondern eher einfach allgemein für Seiten die Neuigkeiten veröffentlichen. Ich betreue Website und bin gerade dabei, unsere AMP-Seiten zu vervollständigen und zu optimieren. Für unsere Meetered-Article benutze ich AMP Access. Seit einiger Weile haben wir auch Paid-Content. Gibt es bereits eine weitgehende manipulationsfeste Lieferung von Paid-Content auf AMP-Seiten. Da muss ich gestehen, weiß ich nicht, was der aktuelle Stand ist, bezüglich AMP Access und wie das funktioniert. Da müsste ich beim AMP-Team mal nachfragen, wie das vom Praktischen her jetzt aussehen würde. Ich glaube da weiß ich jetzt nicht auf Anhieb, wie das funktioniert. Meine Seite rankt zwar seit einigen Wochen, nach einem Update der Seite, bei den Begriffen Limone Sulgarita und Limone Garotase deutlich besser als vorher, beim Begriff Limone Rankt sie jedoch seit kurz nach meinem Update nicht mehr. Haste eine Idee, was ich in Bezug auf den alleinigen Begriff Limone falsch gemacht haben könnte, die Seite rankt ja nur bei diesem Single Keyword nicht mehr in Kombination mit anderen Begriffen rankt sie ja noch. Schwierig zu sagen, bei einzelnen Begriffen, aber was ich mir hier vorstellen könnte, ist, dass unsere Algorithmen einfach die Suchanfrage Limone jetzt vielleicht ein bisschen anders betrachten und ein bisschen anders einkategorisieren. Das heißt, dass wir da vielleicht dann eher, sag mal, nach der Zitrusfrucht suchen oder dass wir eher annehmen, dass wir das in, ich weiß nicht, mit diesem Wort im Allgemeinen suchen und dass wir deswegen eine Seite zu einem speziellen Ort wo dieses Wort auch dabei ist, dann halt weniger stark berücksichtigen. Und solche Veränderungen gibt es immer wieder. Das sind an und für sich Veränderungen, die an unseren Systemen kommen, die einerseits die Suchanfragen versuchen, besser zu verstehen. Das heißt, das gilt einerseits für die Suchbegriffe, die eingegeben werden und andererseits auch für die Seiten selber. Wo wir die Texte auf diesen Seiten versuchen, ein bisschen besser zu verstehen und ein bisschen besser zu versuchen, zu verstehen, und ein bisschen besser zu verstehen, und ein bisschen besser zu verstehen, und ein bisschen besser zu verstehen, und ein bisschen besser versuchen, herauszufinden, welche Entities sind auf diesen Seiten beschrieben, worum geht es auf diesen Seiten und entsprechend versuchen wir dann auch die Suchanfragen ein bisschen besser zu diesen Seiten zusammenzuführen. Und ich könnte mir vorstellen, dass gerade in einer solchen Situation wie bei dir, wo man ein Wort hat, was verschiedene Bedeutungen haben könnte, dass unsere Systeme im Laufe der Zeit versuchen herauszufinden, was könnten Benutzer eigentlich meinen, wenn sie jetzt nur nach Limone suchen. Weil es ist doch recht mehr deutig. Und da könnte ich mir schon vorstellen, dass es für eine gewisse Zeit vielleicht unsere Systeme gesagt haben, gut, dieses Wort haben wir auch auf deiner Website gefunden, also zeigen wir das, weil 1 zu 1 passt das Jahr von den Wörtern her. Aber dass unsere Systeme dann vielleicht auch später merken, das passt das vom Wort her schon, aber der Benutzer meint das und deine Website ist über ein Ort und das passt dir dann doch nicht mehr zusammen. Und so kann es schon sein, dass solche Rankingänderungen kommen können. Ich denke, das ist jetzt nicht unbedingt etwas, was du falsch gemacht hast, sondern eher etwas, was unsere Algorithmen versuchen, ein bisschen anders einzustufen. Ob das jetzt besser ist oder schlechter ist, weiß ich nicht. Ich habe jetzt da nicht gezielt nach diesen Suchbegriffen da recherchiert, was da effektiv gemeint werden könnte. Ich könnte mir vorstellen, dass es einfach so mehrdeutig ist, dass zumindest für uns nicht immer 100 % klar ist, was da gemeint ist und dass wir dann vielleicht mal eher die Frucht benehmen, vielleicht eher einfach dieses Wort wie man das auf Italienisch sagen würde oder den italienischen Begriff dazu nehmen würden und dann vielleicht zwischen euch auch mal denken ja gut, es könnte auch sein, dass jemand eher nach diesem Ort sucht, wenn wir sehen, dass zum Beispiel mehrere nach diesem Ort suchen, mit nur diesen Namen. Von dem her habe ich jetzt nicht gezielte Lösung für dich, etwas Spezielles, was du machen könntest. Was ich eher machen würde in einem solchen Fall ist, mit strukturierten Daten versuchen zu arbeiten und wirklich genau angeben, was bei dir auf dieser Seite gemeint ist. Das heißt, dass wenn wir diese Wörter bei dir auf der Website finden, dass es nicht für uns quasi wir wissen nicht, worum es hier geht zurückkommt, sondern dass wir wirklich dann auch über die strukturierten Daten erkennen können, das geht über diesen speziellen Ort mit diesen speziellen Namen und somit wenn wir erkennen können, dass jemand eher nach dem Namen von diesem Ort sucht, dann können wir das eher zusammenfügen und dann können wir er wirklich auch Besucher zu dir schicken, die nach dem suchen, wofür du Informationen hast. Bei der Bildersuche wie kann ich Hochauflösende Bilder auf Kategorienzeiten unterbringen, die der Google Board auch findet. Für den User würde ich irgendetwas mit JavaScript und ein Mousovervent einbauen, damit die Geschwindigkeit nicht leidet, links möchte ich vermeiden. Ich denke, also die allgemeine Lösung für so etwas ist, dass man zum Beispiel mit ein Picture Element arbeitet und mit Source Set dort kann man einerseits ein Image Tag angeben mit dem Standardbild, das wird dann auch für die Indexierung für die Bildersuche nehmen würden und die verschiedenen Bildauflösungen kann man dort angeben und dementsprechend wird das dann automatisch ausgetauscht. Das ist an für sich die technische Lösung wie man das angehen könnte. Vom Praktischen her weiß ich allerdings nicht, ob das effektiv so viel Sinn macht, weil wir möchten ja an für sich klare Landing Pages für die einzelnen Bilder haben. Das heißt, wenn jemand nach einem bestimmten Produkt sucht und wir das in der Bildersuche zeigen können, dann möchten wir eigentlich eher eine Produkt-Landing Page haben, wo wir sagen können, dieses Bild ist prominent auf dieser Seite, ist relativ groß auf dieser Seite. Wir können erkennen, dass wenn wir den Benutzer nach der Bildersuche auf diese Seite schicken, dass der Benutzer dann eigentlich das findet wonach der Benutzer gesucht hat. Und bei Kategorien Seiten, wenn das jetzt einzelne Produkte sind, die auf der Kategorien Seite sind, dann ist es ja da nicht unbedingt der Fall. Das heißt, das sind ja dann verschiedene Produkte auf dieser Seite und wenn wir eins von diesen Produkten in der Bildersuche zeigen würden und den Benutzer dann auf die Kategorien könnten, dann ist es ja ein bisschen fast ein bisschen verwehren für den Benutzer, weil da sind ja so viel verschiedene andere Bilder auf dieser Seite auch dabei. Von dem her könnte ich mir vorstellen, dass gerade bei Kategorien Seiten, dass es da nicht unbedingt so wichtig ist, dass man da mit der Bildersuche quasi direkt die hoch auflösenden Bilder immer dazu ordnet, sondern dass man das eher wirklich gezielt auf der Produkt-Landing Page macht, wo es dann für uns relativ klar ist, dieses Bild ist wirklich wichtig auf dieser Seite. Wenn wir das Bild in der Bildersuche zeigen würden, dann müssten wir auf diese Landing Page verlinken und nicht auf die Kategorien Seite. Von dem her würde ich das mit den verschiedenen Auflösungen auf der Produkt-Landing Page machen und eher nicht unbedingt auf der Kategorien Seite. Wenn man es trotzdem auf der Kategorien Seite macht, ist das für sich kein großes Problem. Aber ich könnte mir vorstellen, dass für die Bildersuche wäre eher die Produkt-Landing Page eher relevant als die Kategorien Seite. Jetzt habe ich aber das Problem, dass ich ja jetzt nicht, also wir haben 2000 verschiedene Tischflaggen, jetzt können wir die aber nicht alle als einzelne Produktseite listen. Also ich habe begonnen mit einer Tischlang zu konsolidieren auf einer einzigen Seite und die Web-Suche performt natürlich dadurch besser. Dann ist die eigentlich für dich eigentlich klar, oder? Ja, aber wenn jetzt einer, ich sehe ja zum Beispiel auch, wenn jetzt einer über Google Ads sucht, die tippen ja viel mehr ein und dann kommt unsere Seite meistens viel weiter unten als jetzt von der Konkurrenz und die Konkurrenz hat da noch ein schönes Bild. Also meine Idee wäre jetzt zum Beispiel, eine andere Domain zu nehmen und vielleicht dort das irgendwie alles zu erstellen. Also dann hat man dann halt auf der anderen Domain 20.000 Produkte mit den Bildern. Was hältst du denn davon? Also die Domains trennen praktisch. Ich würde eher, wenn man die Wahl hat, würde ich eher mit einem Domain arbeiten als mit verschiedenen Domains und wenn dann wirklich die Frage ist, ich möchte einzelne Landing Pages für diese einzelnen Tischflaggen haben, dann würde ich das einfach gezielt auf einem Domain machen statt, dass man das dann einfach nochmal auslagert auf dem anderen Domain und dass man die da an für sich stehen können. Von dem her würde ich da eher einfach entscheiden, willst du einzelne Landing Pages für diese Produkte haben oder willst du quasi eine Kategorie Seite haben und dann aufgrund von dem jeweils entscheiden und das auf deiner Haupt-Website dann auch machen. Also müsste ich jetzt wieder so wie du oft sagst, die Balance finden zwischen einzelner Produktseite und einer Kategorie Seite, ne? Ja. Okay, okay, alles klar, Dankeschön. Ich denke, es hängt auch ein bisschen davon ab, wie viel danach effektiv gesucht wird und wie quasi wie das dargestellt werden in Suchergebnissen. Es kann sein, dass einzelne vielleicht besser ranken für solche Suchern fragen, aber wenn du siehst, dass das für dich nicht unbedingt lohnt, darauf zu konzentrieren, dann ist das ja auch für sich schon mal hilfreich für dich zu entscheiden, sagen, gut, theoretisch könnte ich da besser werden, aber wahrscheinlich wir betreiben ein internationaler Online-Shop mit jeweiliger Top-Level-Domain für jedes Land. Zudem hat jedes Land eine unabhängige Mobile- und Desktop-Version. Also m.untershop.de und www.untershop.de und ch und at. Nach der Implementation von HF-Lank and Nonical Mobile Alternate haben wir für sich mal kurz schauen, wie das da weitergeht. Ja. Also so wie das aussieht ist quasi diese Implementation mit dem HF-Lank und der Mobile Alternate hat jeweils funktioniert und jetzt seit der Umstellung von einigen Domains auf Mobile First Indexing haben für sich etwas, was längerfristig kommt das dann schon zusammen. Weil das Problem ist ja, wenn ich jetzt m.domains habe, dann habe ich die HF-Lank-Links zwischen diesen anderen m.dot-Versionen und wenn einzelne mit m.dot quasi indexiert sind auf Mobile Indexing und andere mit www, dann ist es so, dass diese Sachen anführlich separat sind. Uch, irgendwie alles mal verschwunden. Okay, jetzt ist alles wieder da. Okay. Immer irgendwas Neues. An und für sich die optimale Lösung ist, dass diese Mobile First Indexierung einfach durchgeführt wird für all diese Domains und dass wir das irgendwann mal durchgenommen haben. Optimaler ist natürlich auch, wenn man keine separate m..Version hat, dann hat man diese ganzen Probleme nicht. Ich denke, es ist wahrscheinlich eine Umstellung von alles auf ein responsive Design. Es ist wahrscheinlich nicht so einfach. Von dem her weiß ich nicht, ob es da eine saubere Lösung gibt, wie man das am besten machen könnte. Was man auch machen kann um ein bisschen diese Problematik zu umgehen, ist einfach ein Banner zu zeigen auf den Seiten. Wenn jemand zur falschen Version kommt, der Banner zeigt und sagt, es sieht aus als ob du aus Deutschland kommst, wir haben die deutsche Version hier. Und so kann man dann eher die Benutzer auch zur richtigen Version weitergeben. Das heißt, im Moment würde ich einfach davon ausgehen, dass gerade bei einer solchen Struktur mit verschiedenen Domains auf verschiedenen top level Domains mit der m. mit separaten mobile URLs das ist da denke ich mal für eine Weile mal ein bisschen eher Schwankungen gibt, eher Schwierigkeiten in der Suche, dass da immer die richtige dargestellt wird und da würde ich das so weit wie möglich ein bisschen auch in die eigene Hand nehmen und sagen ich kann den Benutzer eher zur richtigen Version weiterhelfen und dann versuche ich das ein bisschen klarer zu machen auf den Seiten, wenn die Benutzer zu denen dort landen. Das heißt, nicht unbedingt optimal, aber ich denke da lässt sich da nicht groß einen anderen Weg finden, zumindest kurzfristig. Rank Google eigentlich Websites mit den gleichen Algorithmen in allen Ländern oder gibt es dann nationale Unterschiede, können Anpassungen beziehungsweise Einstellungen in einzelnen Ländern von Google Teams gemacht werden. Im Großen und Ganzen versuchen wir die gleichen Algorithmen überall zu verwenden. Es gibt dann ein paar Situationen, die manchmal ein bisschen schwierig sind. Einerseits je nach Sprachversion kann es sein, dass wir in einzelnen Ländern die Sprachen ein bisschen besser verstehen können und da vielleicht die neueren Algorithmen besser verwenden können und in anderen Ländern eher noch mit den einfacheren Algorithmen arbeiten. Das war zum Beispiel mit diesen BERT Algorithmus der Fall für eine gewisse Zeit war das erstmal auf Englisch haben wir da die Suchbegriffe ein bisschen besser verstanden und dann haben wir das jetzt, ich weiß nicht auf 10, 50 verschiedene Länder, haben wir das jetzt auch ausgeweitet, um andere Sprachvarianten besser zu verstehen. Das ist einmal mit den Sprachvarianten. Die andere Variante wo es auch Unterschiede gibt ist teilweise mit den Suchkomponenten, die in den Suchergebnissen gezeigt werden. Oft sind das ja basierend auf strukturierten Daten und in vielen Fällen sind wir einfach nicht ganz 100% ich sicher, wie wir das darstellen wollen und dann kann es sein, dass wir da auch auf Englisch erstmal etwas ausprobieren gewisse Suchelemente mal versuchen darzustellen und dann im Laufe der Zeit wird das auf andere Sprachen oder auf andere Länder entsprechend ausgeweitet. Wenn wir sehen, dass es so weit klappt. Ich glaube, das sind eigentlich die größten Unterschiede bezüglich Sprache und den Länderversion. Im Großen und Ganzen versuchen wir natürlich die gleichen Algorithmen überall zu verwenden, weil das macht alles einfach viel einfacher, als wenn wir da in jedem Land, in jeder Sprache noch einzelne Algorithmen haben müssen, dann müssen wir die natürlich auch immer wieder kontrollieren und überwachten in all diesen Varianten und das ist dann relativ aufwendig. Wir verwenden JSON-LD-Markup zum Ausweisen der Search-Action auf unserer Seite. Das Target haben wir vor einigen Wochen angepasst. Bei der Suchbox in den Suchegebnissen wird aber weiterhin die alte Suchseite geschickt. Die gibt es auch noch. Können wir das beeinflussen? Das ist, glaube ich, die ich weiß nicht mal, wie der Name hieß, aber ich glaube es wird das markiert. Das Schwierige, was ich da jeweils gesehen habe bei dieser Art von Markup, ist, dass es relativ lange braucht, bis wir das darstellen können. Das heißt, viele Arten von Structuredata können wir direkt so darstellen, sobald wir das einmal indexiert haben. Bei diesem speziellen Art von Markup geht das manchmal ein Monat oder auch ein bisschen länger, bis wir das effektiv auch umgesetzt haben in den Suchergebnissen. Von dem her, wenn das jetzt seit einigen Wochen gemacht wird, dann könnte ich mir vorstellen, dass das vielleicht noch nicht lang genug ist, bis das effektiv alles umgestellt wurde. Und da würde ich eher noch ein bisschen warten. Und wenn du das nach weiterhin einigen Wochen später immer noch nicht siehst, dann wäre ich froh, wenn du mir ein Beispiel zuschicken könntest, dann kann ich das mit dem Team direkt auch mal anschauen. Uch, gerade noch 2 Fragen, vielleicht schaffen wir das. Wird es für das URL-Inspection-Tool auch ein bulk-Export-Tool geben? Das heißt, wenn ich ganz viele Sachen korrigiere, kann man das ein bisschen schneller kontrollieren. Weiß ich nicht, was es geben wird, ist immer ein bisschen schwierig voraus zu sagen. Meines Wissens ist da nicht spezielles geplant, aber ich kann das mal so als Feedback geben, dass Sie das überdenken können. Ich beschäftige mich im Moment mit dem FAQ-Page Markup meinen Kunden fragen oft nach der Lieferzeit, deshalb habe ich mir überlegt, auf ca. 500 High-Traffic-Produkt-Zeiten jedes Mal die gleiche Fragen eine Antwort einzubauen. Geht das in Richtung Spam oder ist das okay? Aus meiner Sicht klingt es eigentlich okay. Das heißt, wenn das wirklich Fragen sind, die du auf deinen Seiten beantworten kannst und wenn die effektiv häufig kommen von Kunden, dann denke ich, ist das eigentlich schon eine okay Sache. Ich würde das mal austesten. Einfach mal ein Handvollseiten nehmen, wo du wirklich auch weißt, dass da die Impressions und Clicks und der Click-To-Rate einigermaßen messbar ist und dann einfach mal überwachen, ob das effektiv dir hilft in den Suchergebnissen oder nicht. Es ist ja nicht unbedingt so, dass wir ein Click-Through-Rate als Ranking-Faktor verwenden, aber für dich ist das natürlich relevant, wenn wir deine Seiten in den Suchergebnissen zeigen und du siehst, dass weniger Leute zu deinen Seiten durchklicken, ist das natürlich für dich etwas, was vielleicht nicht so optimal ist. Aber ich würde das mal ausprobieren. Auf jeden Fall sehe ich das nicht als problematisch, wenn die gleichen Fragen und Antworten auf verschiedenen Produkten sind. Es ist ja nicht so, dass all diese Produktzeiten gleichzeitig in den Suchergebnissen erscheinen, sondern jemand sucht nach einem bestimmten Produkt und dann für diesen Eintrag in den Suchergebnissen, wenn da die Fragen und Antworten dargestellt werden, hilft das ja, ein bisschen Information zu diesem Produkt zu geben. Wie viele Fragen braucht man denn, um angezeigt zu werden? Also eine Frage habe ich ausprobiert, genügt nicht. Ich weiß nicht, ob wir da eine offizielle Begrenzung haben. Ich glaube, irgendjemand hat ein Blog-Post gemacht und gesagt bei zwei oder drei Fragen ab dann wird es dargestellt. Aber ich weiß nicht, ob da offizielle Limite ist auf unserer Seite oder ob das einfach so ein Bereich ist, wo unsere Algorithmen das versuchen, herauszufinden. Also meistens habe ich gesehen vier Fragen, die werden angezeigt. Wenn es fünf Fragen gibt, dann werden drei Fragen angezeigt und dann darunter ein Link mit mehr anzeigen. Ja gut, dann probiere ich mal drei oder vier aus, alles klar. Ja, ich würde es mal ausprobieren. Also es ist auf jeden Fall nicht so, dass wir das als Spam sehen würden, weil das sind ja dann auch effektive Fragen, die auf deiner Seite beantwortet sind, die zu diesem Produkt haben. Von dem her würde ich mir da jetzt nicht Gedanken wegen Spam machen, sondern eher einfach Gedanken, wie möchtest du dargestellt werden in Suchergebnissen. Und manchmal ist das ja ganz okay, wenn man ein bisschen mehr Platz in den Suchergebnissen hat mit ein bisschen mehr Information. Ja. Okay. Zeitlich haben wir das gerade geschafft. Das ging ja perfekt. Ich richt auf jeden Fall noch die nächsten Hangouts, so gegen Ende 1. Freitag kann man ja noch ein Hangout auf Englisch, wenn ihr dazustößen möcht. Wenn weiterhin Fragen kommt, könnt ihr natürlich auch gerne im Hilfeforum posten oder dann halt ein von den nächsten Hangouts vorbeischauen. Vielen Dank fürs kommen. Wünsche euch, wie gesagt, noch einen guten Start ins neue Jahr. Hoffentlich klappt alles, so wie ihr das haben wollt. Und vielleicht sehen wir uns ein ein von den nächsten Hangouts wieder. Tschüss allerseits.