 Okay, herzlich willkommen beim heutigen Webmaster Central Sprechstunden Hangout. Mein Name ist Johannes Müller, ich bin Webmaster Trends Analyst hier bei Google in der Schweiz. Und Teil von dem, was wir machen, sind solche Webmaster Hangouts, wo jeder dazukommen kann und seine Fragen rund um seine Website und um die Websuche stellen kann. Sind da schon einige Fragen eingereicht worden? Die können wir nachher durchgehen, aber wenn einer von euch möchte, können wir gerne mit euren Fragen anfangen. Ja, ich hätte vielleicht gleich mal zu Beginn eine kurze Frage, wahrscheinlich relativ einfach zu klären. Es geht um folgendes Szenario. Auf unserer Webseite haben wir das so, dass per Parameter in der URL die Webseite gesteuert wird. Jetzt ist es so, dass je nachdem, wie der User durch die Webseite sich klickt, die Anordnung der Parameter in der URL anders sein kann. Und die Frage dazu ist, spielt das am Ende für den Google bot eine Rolle, weil wir hatten es ausprobiert in der Google Search-Konsole, dieselbe URL nur die Parameter getauscht. Die hat da beides als unterschiedliche URLs angenommen. Aber am Ende ist die Frage, ob es eine Relevanz spielt und ob es sinnig wäre, das mit Text, nicht Text, wie heißen die Canonics zu regeln, dass wir sagen, okay, das ist aber eigentlich immer die Canonics mit deren Reihenfolge. Ja, gute Frage. Normalerweise würden wir sowas erkennen, weil gerade wenn man normale Parameter und Wert-Elemente in der URL hat, also mit dem Fragezeichen und dem Parametername und dem gleichen Wert, dann sind das Sachen, die wir relativ gut auseinandernehmen können. Von dem her können wir das schon verarbeiten, aber je klarer du an und für sich eine URL direkt und korrekt angeben kannst, umso eher kann man der auch direkt verfolgen. Das heißt, soweit wie möglich, würde ich versuchen, dass da die Reihenfolge immer ähnlich ist oder immer gleich ist oder dass man zumindest mit dem Canonical da entsprechend nachhilft. Okay, perfekt, dann denke ich schon. Perfekt. Weitere Fragen, bevor wir loslegen von irgendjemandem. Nichts. Okay, vielleicht kommt ja noch was auf. Könnt gerne zwischen euch unterbrechen und weiter fragen. Ich fange mal an mit den Fragen, die da eingereicht worden sind. Was ist der Unterschied zwischen Indexierung beantragen und Live-urail-Tests in Search Console und den normalen Crawling? Die Funktionen Indexieren beantragen halt den Recipe-Bug innerhalb kurzer Zeit. Die anderen Crawling-Methoden nicht. Was ist beim Prozess Indexierung beantragen anders? An und für sich sind das ziemlich die gleichen Prozesse, außer dass beim Indexieren beantragen in Search Console wird natürlich quasi ein bisschen schnellerer Weg eingeschlagen. Das heißt, für das normale Verarbeiten von URLs braucht es meistens einfach in eine gewisse Zeit, dass wir alles sauber erkannt haben und alles sauber auseinandergenommen haben, die Informationen sauber rausgeholt haben und mit dem Indexierungsbeantragen kann man für eine begrenzte Anzahl URLs das ein bisschen quasi beschleunigen und dann funktionieren da einige der Prozesse ein bisschen anders auf unserer Seite. Im Grunde genommen ist das aber eigentlich das Gleiche. Und was längerfristig passiert ist, dass wir versuchen quasi mit diesem schnelleren Weg diese URL erst mal wieder zu indexieren. Und dann wird die Torzsystem für das normale Crawling und Indexing eingereitet. Das heißt, nach einem Tag oder zwei passiert der normale Prozess dann auch durch und dann sollte sich das eigentlich so wieder einstufen, wie das durchs normale Crawling passiert. Es kann sein in einigen Situationen, dass unsere Indexierungssysteme zum Beispiel erkennen, dass irgendetwas mit den Inhalten von einer URL doch nicht so wahnsinnig gut klappt und dass wir deshalb dann nach einigen Tagen dann quasi entweder die URL gar nicht mehr indexieren oder dass wir sie halt ein bisschen anders indexieren. Ich weiß jetzt nicht genau mit dem Recipe Bug, ob das damit zusammenhängt. Aber zum Beispiel, wenn wir sehen, dass auf einer URL ein Canonical ist oder wenn wir sehen, dass genau die gleichen Inhalte auf einer URL sind, wie auf anderen URLs, die wir schon haben, dann passiert quasi im längerfristigen Prozess die ganze Canonicalization und da versuchen wir festzustellen, welches diese URLs wir kennen, wie eigentlich separat indexieren sollten. Und so kann es natürlich Unterschiede geben zwischen dem quasi Schnelldurchgang und dem quasi längerfristigen stabileren Indexieren. Bezüglich Recipe weiß ich jetzt nicht genau, was da gemeint ist. Ich habe gesehen, du hast auch eine weitere Frage weiter unten wegen den Bildern im Recipes. Ich weiß nicht, inwieweit da quasi dieser Schnelldurchgang anders wäre für das Bearbeiten von Recipes im Allgemeinen. Sollte eigentlich ziemlich ähnlich sein. Darf ich da direkt kurz was zu sagen, John? Ja. Habt ihr die Frage gestellt? Also es ist so, dass bei uns viele Rankings eigentlich im Rezept-Kausel sein müssten. Ist auch der erste blaue Link unter dem Kausel. Und wir waren halt letzte Woche da bei mehreren Tausend Keywords aus dem Kausel rausgeflogen. Nachdem sich die Bild URL geändert hat, aber eigentlich das gleiche Bild noch da ist nur ein anderes Format 16 zu 9 und statt 1 zu 1. Und wie gesagt 100.000 Beispiele. Und wenn man eine einzelne URL nimmt, die in der Google Search Console manuell neu indexieren lässt, dann nach einer Minute ist die wieder in dem Kausel drin. Beim normalen Calling passiert das allerdings nicht. Oder wenn wir die SideMap noch einmal calling lassen und so was, also irgendwas, das da durch anders. Irgendwas wird ausgelöst. Irgendwie der Backhalt geheilt. Also ihr habt quasi die Bilder URLs geändert? Ja. Okay. Das müsste ich vielleicht mal separat anschauen. Aber normalerweise, wenn man die Bilder URLs verändert, dann geht das meistens ein bisschen länger, bis sich das wieder neu einpendelt, weil unsere quasi die Indexierungssysteme für Bilder sind ein bisschen anders. Und die rechnen eigentlich damit, dass Bilder URLs längerfristig stabil sind. Und wenn man jetzt im großen Rahmen die Bilder URLs verändert, dann könnte ich mir schon vorstellen, dass im ersten Moment die Bilder, sag ich mal, nicht mehr bei der Bildersuche direkt indexiert werden, weil sie nicht mehr auf den Seiten quasi vorhanden sind. Also die alte Bilder URLs. Und dass es dann erst quasi noch weitere Schritte braucht, bis diese Bilder dann neu indexiert werden. Da kann es natürlich schon sein, dass das mit diesem Schnelldurchlaufen mit dem Indexieren, dass es im ersten Moment dann wieder so zurück kommt. Gibt es da eine Grenze, wie viel man pro Tag händisch so eingeben kann? Ich weiß nicht, wo die Grenze ist. Es gibt auf jeden Fall schon eine Grenze, weil die Idee ist ja eigentlich, dass es über das normale Indexierung auch funktionieren sollte und dass es da eigentlich so der normale Durchgang ist. Ich weiß, irgendjemand hat ein Script, glaube ich, erstellt, womit man die quasi direkt über den Script so einreichen kann. Bis zu dieser Grenze hin finde ich das eigentlich okay. Ich denke, das ist nicht etwas, was man quasi längerfristig machen müsste. Das sollte eigentlich nicht der Fall sein. Aber wenn das jetzt so eine einmalige Umstellung ist auf eurer Seite, dass ihr die Bilder URLs verändert habt und ihr vielleicht mal die hundertwichtigsten Bilder oder die hundertwichtigsten Rezepte quasi so neu einreichen wollt, dann finde ich das eigentlich okay. In der alten Search Console war es da möglich mit der Funktion Fetch like Google, dass man eine HTML-Site-Map gefetcht hat und Google dann praktisch auch die verlinkten URLs auch noch gequält hat. Das ist in der neuen Search Console nicht mehr möglich, oder? Das ist nicht mehr möglich, genau. Das wäre da wahrscheinlich jetzt praktisch. Aber ja, ich muss mit dem Team mal nachschauen, weil ich glaube, das hat mir auch einige Beispiele mal geschickt. Dann kann ich mal ein bisschen genauer schauen, was da jetzt passiert ist. Weil gerade wenn man die URLs von Bildern verändert, dann braucht das meistens ein bisschen Zeit, bis es neu verarbeitet ist. Habt ihr die alten Bilder URLs auch weitergeleitet oder sind das einfach neue Bilder URLs? Also das waren nur die Bild-URLs in den strukturierten Daten nicht auf der Seite selbst. Also für den Nutzer sieht die Seite exakt gleich aus. Und wir hatten vorher drei Bildformate angeboten, was Google ja eigentlich auch empfiehlt. 16 zu 9, 4 zu 3, 1 zu 1. Nur Google hat immer das 1 zu 1 Bild genommen, 16 zu 9 gekroppt, was sehr ungünstig aushabe 0,11 war. Und praktisch um zu erzwingen, dass das 16 zu 9 Bild genommen wird, haben wir die beiden anderen Links rausgenommen. Also, so gesehen hat sich nicht mal die URL geändert. Wir haben nur Google dazu gebracht, eine von den 3 zu nehmen und vor hat Google immer einen anderen genommen. Okay, aber dann habt ihr nicht die 16 zu 9 URLs geändert, sondern einfach nur die drin gelassen, die anderen rausgenommen? Genau, genau. Okay, man sollte das eigentlich schon ein bisschen schneller gehen. Da müsste man nachfragen, ob man da irgendwas machen kann oder ob da irgendwas auf unserer Seite klemmt. Wenn die Bilder URLs sich nicht verändern, dann sollte das eigentlich ja schon indexiert sein und sollte man eigentlich einfach umgeschalten können. Ja, das wäre super, wenn ihr da nachfragen könnt, voll unterwegs aus sehr vielen Boxen geradeaus. Okay, danke. Ja, ich habe eine hreflang Verständnisfrage. Ich habe drei international ausgerichtete Websites, Beispiel AT, Beispiel DE und Beispiel CH. Hreflang habe ich folgendermaßen gesetzt, DE strich DE auf Beispiel DE, DE strich AT auf Beispiel AT und DECH auf Beispiel CH und dann XDVD auf Beispiel DE. Benötige ich einen regional unabhängigen Link oder ist durch den XDVD Redulant und ist es ein Problem, sowohl DE, DE als XDVD auf Beispiel DE zeigt. Man braucht nicht unbedingt ein separater Seite für quasi alles andere. Man kann problemlos mehrere Regionen oder mehrere Einstellungen auf die gleiche Seite stellen. Das heißt, man könnte auch eine allgemeine DE Seite haben und das könnte vielleicht die gleiche sein wie DE strich DE und ebenso auch XDVD kann genauso gut auf die Seite für DE, DE zeigen. Das ist anfühlig unproblematisch. Was einfach mit gerade dieser Konstellation immer ein bisschen schwierig ist oder ein bisschen verwirrend ist, ist, wenn man die gleichen Inhalte auf diesen Seiten hat für Deutschland, Österreich und die Schweiz, dann kann es sein, dass unsere Systeme das anschauen und sagen, das sind ja die gleichen Inhalte. Wir indexieren nur eine Version davon und machen das quasi für den Webmaster ein bisschen einfacher, indem wir einfach alles konzentrieren auf, sagen wir mal die DE, DE Version, wenn das erkannt wird aus eurer Hauptversion. Im Grunde genommen ist das soweit eigentlich okay, weil beim Indexieren ist das eigentlich okay, wir können ja die gleichen Inhalte zusammenklappen so. Mit dem hreflang können wir die richtige URL trotzdem in den Suchergebnissen zeigen, aber in Search Console wird ja nur auf die Canonical URLs entsprechend oder werden die Canonical URLs in den Reports verwendet. Das heißt, sowohl für den Indexierungstatus und auch den Performance Report in Search Console wird man dann nur Informationen für diese indexierte Variante sehen. Das heißt, vom praktischen her wird das möglicherweise dann so sein bei euch, dass wir die richtigen Länder URLs zeigen in einzelnen Ländern, aber in Search Console, wenn man reingeht, dann sieht man einfach, dass alles nur auf der deutschen oder DE, DE Variante quasi verwiesen wird. Und das ist natürlich ein bisschen verwehrend, nicht unbedingt falsch von dem her, dass ihr da einen Vorteil hättet, wenn das anderes wäre, aber vom ganzen Reporting her und verfolgen von den Daten in Search Console sieht man da eigentlich nicht so recht, welche Varianten jetzt erkannt wurden und welche Varianten in den Suchergebnissen gezeigt werden. In Performance Report kann man das ein bisschen auseinandernehmen, indem man die einzelnen Ländern quasi einzeln anschaut in Search Console und dann zeigen wir euch quasi so oft wurde das in der Schweiz gezeigt, so oft in Österreich und dann kann man das ein bisschen so zusammenstecken. Beim Indexierung Support sieht man das allerdings nicht, da sieht man dann nur die zum Beispiel die DE, DE Variante ist indexiert und die anderen Varianten sind nicht indexiert und das kann da ein bisschen verwehrend sein. Das heißt, wenn das für euch okay ist, dass quasi die Indexierung so funktioniert, müsst ihr da eigentlich nichts machen, müsst ihr nur bei den Reports dran denken, dass da alles ein bisschen zusammengeklappt ist. Wenn das für euch problematisch ist, würde ich einfach sicherstellen, dass die Inhalte dieser drei deutschen Varianten entsprechend unterschiedlich genug sind, dass unsere Systeme das anschauen und sagen, das sind unterschiedliche Seiten, die müssen wir separat indexieren. Und wenn wir sie separat indexieren, dann sind sie auch separat in Search Console bei allen Varianten dabei. Kann ich dazu eine Frage stellen? Ja. Und zwar habe ich seit drei Monaten jetzt ein Edge Web Flank über die Sidemap und drei Domains eingerichtet. Sehr viele Seiten wurden auch, also nicht zusammengeklappt, sondern die Overheads ausgetauscht auch. Jetzt sind immer noch ein paar übrig, zum Beispiel in Österreich. Woran kann das liegen? Also die werden einfach nicht, da erkennt Google das anfangs nicht. Wie erkennst du, dass es nicht erkannt wird? Ja, ich suche und sehe dann die deutsche Domain in den österreichischen Ergebnissen, weil die deutsche Domain einfach wahrscheinlich ein bisschen besser ist gegenüber der österreichischen Domain. Normalerweise sollte er ja die URLs austauschen. Ja. Schwierig zu sagen. Wenn du mir ein Beispiel vielleicht in den Chat reinkopieren könntest, kann ich das mal nachschauen. In den meisten Fällen ist es so, dass wir die Verwendung von Edge Web Flank bei den einzelnen Seiten entweder noch nicht verarbeitet haben oder dass wir es aus irgendeinem Grund nicht sauber verarbeiten können, wenn die URLs zum Beispiel leicht unterschiedlich sind. Aber wenn das jetzt seit, seit längerer Zeit in den Sidemaps dabei ist und bei den anderen Seiten funktioniert das, dann ist es wahrscheinlich sauber eingebunden in der Sidemap Datei und vermutlich haben wir diese Seiten inzwischen schon neu indexiert und da würde es mir ein bisschen komisch erscheinen, dass wir das bei einzelnen Seiten nicht sauber verwenden und bei den anderen eigentlich schon. Aber wenn du mir vielleicht ein paar Beispiele geben kannst, dann kann ich da versuchen hier Intel mal nachzuforschen. Okay, per Email? Kannst du machen. Ja. Okay, danke. Super. Okay, und dann von Hans noch eine Frage wegen dem Recipe Bug. Ich glaube, dass was ihr seht, ist nicht das Gleiche, was da in diesem Bug war, weil so weit ich erkennen konnte, ist das von diesem Bug eigentlich behoben und ich sehe auch da keine großen Beschwerden mehr auf Twitter, die darauf hinweisen, dass es irgendwie allgemein bei den Bildern, bei Recipes jetzt immer noch ein Problem besteht. Ich vermute, das hängt wirklich einfach mit den unterschiedlichen URLs zusammen. Aber ich schau das mal bei euch noch mal an. Ich habe eine Website mit 40.000 URLs über die letzten 15 Jahre gewachsen. Die URLs habe ich auf drei Sidemaps aufgeteilt. In der Search Console werden diese auch erfolgreich verarbeitet. Sidemap indexiert ohne Fehler verarbeitet. Nun habe ich aber 1000 URLs, die von Google nicht aufgenommen werden, obwohl diese relevanten Content haben. In der URL-Prüfung steht dann ab Bankum URL ist Google nicht bekannt und bei Auffindbarkeit Sidemaps nicht zutreffend, obwohl die URL definitiv seit Monaten bereits ein Sidemap vorhanden ist. Was kann der Grund sein, dass Google viele Seiten nicht indexiert? Ja, schwierig zu sagen, einerseits ohne die Website zu kennen, andererseits ist es natürlich im Allgemeinen so, dass wir nie alle Seiten von einer Website indexieren. Das heißt, unsere Systeme versuchen zu erkennen, was wichtig ist, bei einer einzelnen Website zu indexieren und versuchen sich auf das zu konzentrieren. Und da kann es durchaus sein, dass wir sagen, bei einer größeren Website, dass es mehrere Tausend oder mehrere Hunderttausend URLs gibt, von denen wir etwas wissen, weil wir vielleicht in einer Sidemap-Datei sind, aber von denen wir sagen, gut, wir konzentrieren uns moment nicht auf die. Vielleicht haben wir die einmal gekrawlt, aber wir haben sie jetzt halt nicht indexiert. Und das ist eigentlich einigermaßen normaler Zustand im Allgemeinen mit Websites, dass wir viele Seiten kennen, aber dass wir sie einfach nicht indexieren, weil wir das Gefühl haben, wir haben eigentlich schon mal das Wichtigste von dieser Website gefunden und können das in den Suchergebnissen zeigen. Was ich da vielleicht machen würde, ist einfach sicherstellen, dass im Allgemeinen, dass die Website einfach ein bisschen besser dasteht. Das heißt, dass wir, wenn wir diese Website crawl und indexieren, dass wir wirklich erkennen können, da sind sehr wichtige Inhalte dabei. Alle Seiten, die wir crawl und indexieren, sind sehr wichtig für uns. Und dementsprechend sollten unsere Systeme daran forschen, weitere Seiten von dieser Website zu finden, damit sie auch indexiert werden können. Und das kann man einerseits machen, indem man natürlich die Qualität der Website signifikant verbessert. Andererseits, dass man vielleicht auch mal durchgeht und überlegt, welches dieser der URLs, die ich im Moment indexiert habe, sind vielleicht doch nicht so gut, dass man sie separat indexieren müsste und die dann entweder verbessern. Das ist eigentlich immer quasi aus unserer Sicht die beste Idee. Oder dass man halt sagt, gut, das sind wirklich URLs, die müssten gar nie indexiert werden. Ich wäre froh, wenn Google sich eher auf die anderen URLs konzentriert, die auch auf meiner Website sind. Eine andere Sache, die da auch manchmal eine Rolle spielt, ist, dass wir manchmal einfach ein Duplicat von einer URL schon indexiert haben. Was wir einfach auch oft sehen, ist, dass in den Sidemap-Dateien URLs angegeben werden, die nicht genau dementsprechend, was wir finden, durch das Crawling von einer Website. Und dann sind wir ein bisschen in Konflikt. Dann sehen wir einerseits URLs, die in der Website quasi verlinkt sind. Und andererseits die gleichen Inhalte mit anderen URLs in der Sidemap-Datei. Und da müssen unsere Systeme dann überlegen, welches diese URLs sollten wir eigentlich indexieren. Und dann kann es schon sein, dass wir eine URL indexieren, die verlinkt ist innerhalb der Website, die aber nicht in der Sidemap ist, obwohl die Inhalte an für sich gleich sind. Das heißt, vom praktischen Her, was ich da machen würde, ist einfach mal stichprobenweise kontrollieren, die URLs, die indexiert sind, sind das genau die gleichen URLs, wie sie in der Sidemap-Datei sind. Man kann das auch ein bisschen kontrollieren mit einem lokalen Crawler, wenn man irgendwie so etwas wie Screaming Frog oder Deep Crawl verwendet, um die eigene Website zu crawlen. Und dann die URLs, die dabei herauskommen, die dann einfach vergleichen mit dem, was in der Sidemap-Datei an und für sich angegeben ist. Und wenn da größere Unterschiede sind, dann kann das natürlich schon sein, dass wir dann diese Situation gekommen sind, dass wir andere URLs indexiert haben, als die in der Sidemap-Datei angegeben sind. Und dann sieht man das in den berichtenden Search Console, dass man da URLs aus der Sidemap-Datei sind, halt nicht indexiert. Und URLs, die indexiert sind, sind vielleicht nicht in der Sidemap-Datei was angegeben. Aber eben das ist mal die Situation, wenn wir viele Sachen schon indexiert haben, die nicht in der Sidemap-Datei sind, in den meisten Fällen, die ich angeschaut habe, die so grob da in diese Kategorie passen, ist es wirklich so, dass unsere Systeme einfach sagen, wir müssen nicht alles indexieren von dieser Website, wir haben eigentlich schon die relevanten Inhalte schon gefunden. Ich habe da noch eine Frage zu. Und zwar seit November 2019 habe ich sehr viel die indexiert und jetzt sind immer noch sehr viele URLs übrig. Die wurden teilweise gekreut Mitte 2019. Die erscheinen jetzt in der Search Console unter indexiert, aber nicht übermittelt in der Sidemap. Dort sind dann diese Beispiele aufgeführt bis zu 1000 Stück. Und jetzt würde ich die gerne auch bereinigen wollen. Könnte ich die URLs aus dieser Ausgabe, also indexiert und nicht im Sidemap übermittelt, dann nehmen und dann praktisch als Sidemap wiederum einreichen, damit der Crawler dort drüber geht. Und die haben irgendwie No Index oder 404 Startungs? Die haben jetzt No Index, genau. Also die haben jetzt schon seit November 2019 No Index, wurden das letzte Mal aber gekreut vor acht Monaten ungefähr. Okay, ja, kann man durchaus machen mit vielleicht neueren Änderungsdatum, damit wir auch wirklich wissen, dass die seitdem jetzt auch verändert worden sind. Kann man das durchaus machen. Ich würde einfach längerfristig schauen, dass die Sidemap die Sachen enthält, die für euch indexiert werden sollen, nicht die Sachen, die quasi entfernt werden sollten. Genau, das habe ich ja jetzt seit gut vier Monaten ungefähr, also seit November 2019. Aber wie gesagt, also der Crawler geht einfach nicht über diese URLs, drüber, die jetzt noch irgendwie drin hängen im System. Und ja, da würde ich Ihnen einfach nochmal sagen, komm, schauen wir nochmal vorbei vielleicht. Also das würde aber auf jeden Fall gehen jetzt. Schon, da schon gehen. Hello. Die nächsten Nachbarn, muss das Besprechungszimmer abschließen. Ja, also an und für sich würde das gehen. Was ich da vielleicht machen würde, ist einfach ein anderes Sidemap-Dateinnamen noch nähen, damit, damit du auch wirklich dran denkst, die quasi die entfernten Sachen irgendwie längerfristig auch wieder rauszuschmeißen. Ja, okay. Okay. Bei vielen Suchbegriffen wie Online-Kreditvergleich, Online-Kreditvergleich, Online-Broker-Vergleich oder auch Router-Vergleich erscheinen unter den ersten Ergebnissen, Stern.de und SZ-Seiten, die anzeigen einer Affiliate-Agentur aus breiten Vorbesind. Erkennt Google nicht, dass es sich hier schlicht um Werbung handelt im Voraus. Vielen Dank für die Antwort. Wir indexieren an und für sich die Inhalte, wie sie so bereitgestellt werden. Und unsere Systeme sind eigentlich nicht darauf ausgerichtet, diese Sachen quasi separat rauszufiltern. Das heißt, Werbung ist ja in vielen Formen auf vielen verschiedenen Websites und das ist aus unserer Sicht an für sich auch okay. Was einfach ist, gerade mit solchen Inhalten ist es natürlich so, dass wenn man die auf seine Webseite so hinein nimmt, dann nehmen wir das an. Das sind Inhalte von eurer Webseite. Dann nehmen wir an, dass das dem Qualitätsstandard entspricht, wofür ihr stehen wollt. Und wenn man natürlich eine ansonsten gute Webseite nimmt und die quasi mit, sag ich mal, minderwertigen Inhalten vermischt, ich habe jetzt diese Seiten nicht angeschaut. Ich nehme jetzt mal an, das sind einfach nur Werbe-Seiten. Dann wird natürlich die Qualität der Webseite insgesamt auch ein bisschen anders angesehen von unseren Systemen. Aber wenn man das so machen möchte, dann ist das natürlich euch überlassen. Es ist nicht so, dass unsere Systeme da hingehen würden und sagen würden, da auf dieser Seite sind jetzt mehrheitlich Werbe-Elemente auf dieser Seite. Deswegen würden wir sie gar nicht indexieren. Wir würden vielleicht erkennen, dass da Werbe-Inhalte da dabei sind und sie vielleicht vom Ranking her entsprechend ein bisschen anpassen. Aber es ist nicht so, dass wir die Seiten dann gar nicht indexieren würden. Und als Webseitenbetreiber, wenn man solche Werbe-Inhalte auf der eigenen Seite haben möchte und wenn man die nicht indexiert haben möchte, wenn man denkt, dass es jetzt eigentlich nicht das, wofür ich als Webseite stehen würde, dann würde ich da einfach ein New Index auf dieser Seite nehmen. Dann kann man die immer noch als Landing-Pages innerhalb der Webseite verwenden. Aber dann sind sie nicht gesehen als ein Teil der Inhalte von dieser Webseite. Ich weiß, da gibt es alle möglichen Abstufungen zwischen quasi nur ein klein Element Werbung auf einer Seite und den Hauptinhalt der Seite ist Werbung. Aber unsere Systeme versuchen da eigentlich nicht, Seiten aus diesen Gründen ganz aus dem Index rauszunehmen. Im Zuge unseres eigenen Anspruchs sowie Google's Prinzipien habe im Oktober einen umfassenden Content Audit durchgeführt. Das Resultat 1100, der insgesamt 2.100 EUR haben wir als redundant oder qualitativ schlecht gekennzeichnet. Wir haben uns dabei den schlechten Inhalt EUR sowie keine bis kaum organischen Clicks an Google Analytics Pageviews fokussiert. Die genannten 1.900 EUR wurden innerhalb zwei Tagen ab dem 7. November weitergeleitet, per 301. Ein Tag darauf haben sich unsere organischen Clicks und Impressions um 36% reduziert. Seit der Arbeit haben wir ständig an der qualitativen Weiterentwicklung der Webseite, Zeitmaps sind aktualisiert und so weiter. Zwischenzeitlich haben wir es sogar für uns wichtiger EUR als Manuell Cron lassen. Leider haben wir uns seit vier Monaten nicht erholt. Was kann man da tun? Ich denke, das sind wahrscheinlich zwei oder mehrere Sachen, die da zusammenkommen. Einerseits ist es sicher eine gute Sache, wenn man die Qualität einer Webseite insgesamt verbessert und eben wie gesagt am besten natürlich, wenn man die Qualität der vorhandenen EUR verbessert. Wenn man das nicht machen kann, wenn das quasi im Rahmen sprengen würde bezüglich der Arbeit, die da vorhanden ist, dann kann es natürlich Sinn machen, dass man sagt, ich nehme einfach einen großen Teil der EUR, die wir haben und entferne die ganz von der Webseite. Man kann die auf verschiedenen Arten entfernen lassen. Einerseits mit einem No-Index-Metatank, dann werden sie noch auf der Webseite vorhanden. Wenn jemand innerhalb der Webseite dorthin navigieren möchte, manchmal macht das ja Sinn. Man kann auch einen 404 zurückgeben, dann sind sie natürlich auf der Webseite nicht wirklich mehr vorhanden, dann fahren sie auch raus. Man kann auch per 301 Weiterleitung auf eine neue Seite, die quasi die alte Seite ersetzt, kann man eine Weiterleitung machen. Was wir nicht empfehlen würden, ist eine Weiterleitung zum Beispiel grundsätzlich auf die Homepage oder auf dem Kategorienseite. Das heißt, wenn ich jetzt einige URLs entferne von meiner Webseite, dann sollte nicht ein Redirect auf die Homepage da sein, sondern sollte wirklich ein klares Zeichen sein, dass diese URLs jetzt nicht mehr existieren, dass wir sie nicht mehr indexieren sollten. Wenn man einzelne URLs hat, die ersetzt werden durch andere URLs auf der Webseite, dann würde ich das seitenweise machen. Das heißt, die alte Seite auf die neue Seite oder wenn ich verschiedene Unterseiten habe und ich möchte die kombinieren in eine bessere Seite, dass man halt diese einzelnen Seiten in die bessere Seite weiterleitet, das ist an für sich okay. Die Weiterleitung auf die Homepage würden wir hingegen als Soft 404 sehen und das ist weniger ein qualitatives Problem auf unserer Seite, dass wir sagen würden, die Webseite ist schlechter deswegen, sondern eher einfach ein technisches Problem. Das heißt, wir sehen diese Weiterleitung und wir würden der eigentlich verfolgen, aber gleichzeitig müssten wir eigentlich erkennen, dass es nicht eine Weiterleitung ist, sondern dass die Inhalte jetzt ganz entfernt werden und das macht die ganze Verarbeitung einfach ein bisschen langsamer und kann dazu führen, dass wir die alten URLs ein bisschen länger crawlen. Das heißt, dass wir länger immer wieder diesen 301 sehen und dass wir dann erst mal später merken, eigentlich müssen wir den gar nicht mehr nachgehen. Das heißt, dieses Soft 404 ist mal etwas, was man vermeiden sollte, aber es ist nicht so, dass wir dann sagen würden, das ist schlecht für die Webseite insgesamt. Von dem her würde ich mal sagen, diese Kombination quasi die Veränderung, die ihr gemacht habt mit der Veränderung in Clicks and Impressions hängt wahrscheinlich nicht zusammen. Das heißt, gerade wenn ihr auch sicherstellen könnt, dass die Seiten, die ihr entfernt habt, nicht 36% der Clicks and Impressions ausmachen, dann ist es ja eher einfach eine technische Veränderung, die ihr gemacht habt und insgesamt eine qualitative Verbesserung der Webseite und das ist eigentlich eine gute Sache. Wenn das zusammenhängen würde aus technischen Gründen, dann wäre da auch nicht von einem Tag auf dem anderen eine Veränderung, sondern dann würde man quasi diesen typischen quasi exponentiellen Verlauf sehen, dass viele Seiten am Anfang quasi entfernt werden und dass sich das langsam abflacht. Das heißt, ihr würdet da, sag ich, vermute ich mal eine Veränderung im Laufe von einer Woche oder zwei Wochen oder so in diesem Rahmen sehen, nicht von einem Tag auf den anderen. Von dem her denke ich, diese Veränderung, die ihr da sieht, die hängt nicht mit dieser technischen Veränderung an der Webseite zusammen, sondern das ist wahrscheinlich etwas, wo unsere Qualitätssysteme, unsere Qualitätsalgeritmen vielleicht insgesamt entschieden haben. Wir müssen diese Webseite ein bisschen anders einstufen und das sind dann eher Sachen, die von einem Tag auf den anderen gehen können, wo wenn wir unsere Algorithmen anpassen und die quasi dann den neuen Zustand der Webseite bestimmen können, dann kann das von einem Tag zum anderen passieren und dann kann es schon sein, dass man da eine relativ starke Veränderung in manchen Fällen halt sieht. In einigen Fällen geht das nach oben, in anderen Fällen natürlich nach unten, je nachdem wie unsere Algorithmen die Webseite jetzt neu einstufen. Und wenn man vermutet, dass es so in Richtung Qualitätsalgorithmen geht, dann würde ich sagen, lohnt es sich, besonders auf die Qualität der Webseite insgesamt zu achten. Das heißt, nicht unbedingt auf Sidemap-Dateien konzentrieren oder auf einzelnen Crawlen von einzelnen URL konzentrieren, sondern wirklich einen Schritt mal zurücknehmen und die Webseite insgesamt anschauen und überlegen, was könnte man da machen, um die Qualität der gesamten Webseite signifikant zu verbessern. Und das sind dann nicht kleine Veränderungen, dass man einzelne Seiten herausnimmt oder dass man einzelne Redirects verbessert oder einzelne Crawling-Fehler verbessert, sondern da muss man dann wirklich überlegen, was kann man insgesamt machen. Und das sind meistens nicht so einfache Sachen und das braucht einerseits ein bisschen Zeit, bis man da das Richtige findet. Oft kann man da zusammen mit User Studies schon ein bisschen herausholen und wenn man dann solche Veränderungen gemacht hat, dann geht das meistens auch eine gewisse Zeit auf Google-Seite bis unsere Algorithmen erkannt haben, dass die Webseite jetzt wirklich signifikant anders ist und entsprechend viel besser ist als vorher. Und dann wird sich das im Laufe der Zeit eigentlich dann auch wieder ein bisschen verbessern. Aber das, denke ich, sind mal die einzelnen Teile davon. Ich vermute, also einerseits ist diese Konzentration von euren Inhalten, finde ich eigentlich eine gute Sache. Das zeigt eigentlich, dass ihr da schon das mal angepackt habt, die Webseite ein bisschen zu verbessern. Diese Veränderung hat höchstwahrscheinlich nichts damit zu tun mit dieser Veränderung, die ihr mit Clicks and Impressions seht in der Suche. Und ich würde eher auf, sag ich mal, gröberer Qualitätsmerkmale da achten, statt auf kleine technischen Einheiten, Beinheiten, die zwar kleine Optimierungen bringen, aber die das Gesamtbild der Webseite nicht signifikant verbessern. Hi, John. Ja, ich kann es auch noch kurz kommentieren, weil die Frage kam auch von mir. Viel, viel nice für die Antwort hier schon mal. Das dort ist jetzt relativ viele, viele Tipps gegeben. Zum Ersten, Redirect of the Homepage, das ist im Endeffekt auch passiert. Würdest du empfehlen, die Sachen wieder rückgängig zu machen? Und als, ja, als, ja, da gibt es eigentlich nicht viel zu sagen, weil die UALs ja alle nicht mehr gepublished sind. Also ich würde es jetzt nicht mehr rückgängig machen. Ich denke, das sollte eigentlich jetzt so verarbeitet sein. In Search Consoles sieht man da einfach, dass die Soft 404-Fähle angegeben werden, aber das, ja, es ist nicht, es ist nicht optimal vom technischen her, aber es ist auch nicht tragisch. Okay, also das heißt quasi, weiterarbeiten, eine Qualität der Seite, feiern und messen und so nach. Okay, vielen, vielen Dank. Super. Eine generelle Frage zum Schema Microdata Implementierung ist es beziehungsweise, währt es in Zukunft ein Problem für den Googlebot, wenn Schema links ohne HTTPS, also nur mit HTTPS angegeben werden. Also HTTPS Schema.org, Streichprodukt oder HTTPS Schema.org, Streichprodukt, beziehungsweise Contodies von Chrome als unsecure Content eingestuft werden. Das macht anfühle ich überhaupt nichts aus. Das heißt, bei Structured Data ist ja, dass das Schema URL eigentlich nur als Kennzeichnung verwendet, also eigentlich wie ein, ja, ich weiß nicht, wie ein Name, einfach für die Art von Structured Data. Und es ist nicht so, dass der Browser auf diese URLs geht und versucht, diese Inhalte aufzurufen, sondern das ist quasi einfach eine Kennzeichnung, dass ihr sagt, Mine Structured Data entspricht diesem Namen und dieser Name ist halt eine URL und aus unserer Sicht, ob ihr HTTPS oder HTTPS verwendet ist, ist total egal. Ich denke, längerfristig macht es wahrscheinlich Sinn, dass man das alles auf HTTPS umstellt, einfach damit man sich da nicht selber verwirrt. Aber grundsätzlich ist das total egal, welches Protokoll ihr für diese Sachen nimmt, weil das ist wirklich nur eine Kennzeichnung. Das sind nicht URLs, die effektiv geladen werden im Browser. Eine Frage zu Search Console. Seit kurzem gibt es den neuen Bericht Rezension Snippets. Dort haben wir bei ein paar Kunden den Fehlerfeld Item Review fehlt. Kannst du da zu etwas sagen? Kann man sich auf diesen neuen Bericht schon verlassen oder sollte man noch darauf verzichten, noch nicht zu sehr darauf versteifen, dass eventuell noch nicht ganz verlässlich ist? Grundsätzlich ist es eigentlich schon so, dass die Sachen, die in Search Console dargestellt werden, gerade bei diesen Rich Results Berichten, entspricht dem, was unsere Systeme gefunden haben. Das heißt, Search Console untersucht die Seiten nicht selber, sondern nimmt eigentlich die Fehlermeldung, die unsere internen Systeme verwenden oder herausgeben und zeigt die dann entsprechend an. Das heißt, wenn bei gerade bei diesen ganzen Rich Results Arten irgendwelche Warnungen oder Fehler da herauskommen in diesen Berichten, dann ist das effektiv so, weil unsere internen sich Systeme da diese Warnungen und Fehler dann entsprechend gegeben haben beim Verarbeiten von den Structuredaten. Von dem her würde ich mich schon darauf verlassen, dass das so entsprechend ist. Ich weiß nicht, wie das mit diesem Item Review konkret geht, aber grundsätzlich ist das schon so. Bei Search Console, was da ein bisschen verwirrend vielleicht ist, bei Search Console gibt es ja einerseits Warnungen und andererseits Fehler und bei den Warnungen ist es natürlich so, wie verarbeiten die Structuredata trotzdem, aber es ist einfach als Information dabei, dass wenn man diese Funktionalität voll ausnutzen möchte oder wenn man das Optimale machen möchte mit diesen Structuredaten, dann sollte man diese Warnungen quasi berücksichtigen und das auch quasi so entsprechend einsetzen. Und ich glaube, eine der Verwirrungen da ist auch, dass wir quasi Empfehlungen haben und Warnungen und ich meines Erachtens werde das in Search Console alles ein bisschen kombiniert. Das heißt, manchmal sind die, bei den Warnungen sind da quasi auch Empfehlungen dabei. Aber wenn das als Fehler angegeben wird, dann ist es effektiv so, dass wir da diese Structuredaten für diesen Nutzungszweck nicht sauber verwenden konnten. Aber ich kann da auch mal Nachfragen beim Team, ob mit dem Item Review irgendwas Spezielles vielleicht noch zusammenkommt. Thema PageSpeed, wie lange dauert es, bis man auf seiner Website Auswirkungen eines wesentlich höheren PageSpeeds erkennt? In welchen Größenordnungen wird es da zu sehen sein? Habe seitdem 3., 2. alle Web Descripts entfernt, bisher keine große Veränderung festgestellt. Da ich auf die Werbung angewiesen bin, werde ich sie wieder einbauen müssen. Sollte ich wegen des PageSpeeds nach alternativen Einnahmenquellen suchen oder was empfiehlt es mir? Habe sämtliche Web Descripts der Agentur und alle weiteren Unnutzen JavaScripts entfernt und warte auf eine Belohnung durch Mehrsichtbarkeit und Benutzer. Welchen Zeitraum muss man da einplanen? Ja, ich glaube, wir haben eigentlich nicht einen konkreten Zeitrahmen für solche Sachen und wahrscheinlich sind das auch eher, sag ich mal, kleinere Veränderungen im Moment, gerade bezüglich Speed. Wenn man größere, sag ich mal, eine Veränderung der das Seite macht, ist es nicht so, dass man automatisch da viel besser in den Suchergebnissen erscheint, sondern das sind da eher, sag ich mal, flexibler Übergänge. Und gerade wenn man einigermaßen im Normalbereich steht, dann ist es nicht so, dass man da durch das Einsparen von sag ich mal, 10 Millisekunden auf einmal viel besser eingestuft wird. Von dem her muss man da in vielen Fällen muss man irgendwie eine Balance finden zwischen quasi den Elementen, die man braucht für eine Webseite zum Überleben. Wenn man natürlich auch Werbung angewiesen ist, muss man ja irgendwie die Werbung auch platzieren und andererseits mit der Geschwindigkeit, die man für den Benutzer bereitstellt. Das hängt natürlich auch einerseits in der Google Suche, kommt das ein bisschen zusammen, aber es spielt meistens eine viel stärkere Rolle bei den Benutzern selber. Das heißt, wenn man die Webseite signifikant langsamer macht, dann bleiben die Benutzer viel weniger lang auf der eigenen Seite und flicken viel weniger herum und da ist der Einfluss dann meistens viel stärker als in der Suche direkt. Und das ist vielleicht etwas, was ihr in Analytics auch sehen könnt. Wenn ihr jetzt diesen Versuch gemacht habt und die Seiten signifikant verbessert habt, dann seht ihr vielleicht in Analytics die Besucher, die auf eure Webseite kommen, bleiben die vielleicht länger, schauen die mehr Seiten an und dann aufgrund von dem kann man natürlich auch entscheiden, wie geht man jetzt vorwärts, wie viel Werbung will man einbauen auf die Seiten, wie will man die Werbung einbinden, wie macht man das so, dass Benutzer quasi trotzdem länger auf euren Seiten bleiben und dass ihr trotzdem auch davon irgendwie profitieren könnt. Und da muss man meistens schon irgendwie im Mittelweg finden und ich denke gerade, also einerseits mit den Page Speed Scores allgemein muss man ein bisschen vorsichtig sein, aber quasi dieser Unterschied zwischen 89 und 94 oder 99, das sind meistens minimale Veränderungen und das wird selbst dann, wenn Google Systeme das erkannt haben und verarbeitet haben, wird das minim nur in der Suche irgendetwas auswirken. Also es nicht sicher nicht so sein, dass ihr auf einmal vom fünften Platz zum ersten Platz hoch springt, nur weil ihr diese Veränderung gemacht habt. Das andere, wie ich schon gesagt habe, die Page Speed Scores muss man ein bisschen mit vorsichtig genießen, weil das ist natürlich ein theoretischer Test und das ist nicht unbedingt etwas, was 100%ig dem entspricht, was Benutzer sehen würden. Von dem her lohnt es sich da die verschiedenen Testmethoden mal auch anzuschauen zu überlegen, welches diese Tests sind jetzt für meine Seiten relevant. Wo kann ich vielleicht etwas verbessern, ohne dass ich da Großkompromisse bezüglich Werbung oder anderen Einnahmen machen muss. Gibt es eine URL Struktur für AMP, welches Seiten Google empfohlen wird, beispielsweise amp.example.com oder example.com-amp? Nein. Meines Erachtens gibt es überhaupt keine Empfehlungen, dies bezüglich. Das einzige, was ich vom AMP Team her weiß, ist, dass Sie das so gerne haben, dass das auf einem gleichen Domain ist. Das heißt nicht, dass Ihr example, bindestrich amp.com macht, sondern dass Ihr example.com für die normalen Webseiten verwendet und in einem Stich amp oder ein AMP Subdomain oder mit einem Parameter amp oder was auch immer, dass Ihr da die AMP Version macht, dass der Domainname aber ansonsten der gleiche ist. Der Grund dafür ist, dass der Domainnahre oft für das Caching verwendet wird, nicht glaube auch im Titel von den AMP-Seiten, wenn sie im Browser über den Cache dargestellt werden. Weiß nicht, ob das noch der Fall ist, aber zumindest war das am Anfang mal der Fall. Wir haben unsere Kategorien-Seiten immer mit entsprechenden Content, also Text, der das Produkt beschreibt, ausgestattet. Diese Texte haben wir bis ins Detail ausgearbeitet und sollen entstanden Kategorien-Texte von 600 bis 900 Wörtern, die wir dann zumindest nach unten gesetzt haben und für den User von oben verlinkt haben, wenn es ihn interessiert. Nun beobachten wir natürlich auch aufkommende Konkurrenten und sehen überall, dass diese Seiten uns überholen bzw. sehr gefährlich werden. Und deren Kategorien-Seiten sind lediglich, die Produkte zu finden mit Herstellerbeschreibung durch Copy-Paste. Macht es Sinn, Text aus Kategorien-Seiten bei Online-Shops komplett zu entfernen, da eigentlich beim Shop auch nur das Kaufinteresse an Produkte interessiert. Ich würde sagen, das ist unterschiedlich, aber wahrscheinlich macht es schon Sinn, dass man zumindest diese Seiten so gestaltet, dass es ganz klar ist, dass das wirklich e-commerce-Kategorien-Seiten sind und nicht etwa informative Produkt, sozusagen mal allgemeine Themen-Seiten sind. Weil wenn wir erkennen können, dass jemand daran interessiert ist, etwas zu kaufen, dann versuchen wir dem Benutzer natürlich eher zu e-commerce-Sites auch zu schicken. Und wenn wir nicht sicher sind, dass eine solche Seite da relevant ist, dann kann es schon sein, dass wir dann eher Wonders hinschicken. Anderseits ist es natürlich so, dass uns Texte auf Seiten extrem helfen, die Seiten besser zu erkennen und besser zu verstehen, worum es geht bei diesen Seiten. Das heißt, eine gewisse Menge an Text ist durchaus wichtig und relevant. Wir haben das sehr stark gesehen beim Mobile First Indexing, als wir da auf die Mobilversion umgeschaltet haben zum Indexieren. Und gerade bei einigen e-commerce-Shops, die separate Mobilversion haben, wo sie auf der Mobilversion fast nur das Produktbild und ein Link zum Produkt dabei haben, da war es für uns dann sehr schwierig zu erkennen, wofür wir diese Kategorien-Seiten eigentlich benken sollen, weil es sehr, sehr wenig Text auf diesen Seiten ist. Das heißt, irgendein Mittelweg sollte man da schon finden. Und das kann, also ich habe da jetzt keine Wortgrenzer, wo ich sagen würde, so viele Wörter sind relevant und so viele sind zu viel. Aber ich denke, da muss man irgendwie das Sohnweg finden, das zumindest beschrieben wird, worum es sich handelt auf diesen Seiten, damit unsere Systeme erkennen können. Das geht um dieses Thema, um diese Art von Produkten. Und für diese Texte können wir die Seite quasi ranken. Eine Idee, die man da machen kann, ist, dass man sich auch überlegt, was würden Benutzer effektiv auch lesen wollen. Und wenn ihr jetzt schon diese Texte auf unten auf eine Kategorien-Seite nehmt, dann sind das ja meistens Texte, die Benutzer gar nie sehen würden. Und von dem her wisst ihr ja schon fast selber, dass ihr diese Texte eigentlich nur für die Suchmaschinen schreibt. Und da würde ich dann schauen, wie könnte man vielleicht ein Mittelweg gehen, dass man Text erstellt, die für Benutzer relevant sind, die dann trotzdem genug Informationen auch übergeben an die Suchmaschinen, damit die Suchmaschinen damit arbeiten können. Kann ich noch eine Frage stellen, bitte? Ja, klar. Wenn man jetzt einen Text auszeichnet mit Data No Snippet, würdet ihr das dann qualitativ bewerten oder fällt das dann aus dieser Qualitätsbewertung raus? Das gehört zur Seite. Es wird trotzdem so indexiert. Es wird da einfach nicht im Snippet dann dargestellt. Okay, danke. Das heißt... Von meiner Seite dazu auch immer eine Frage, gerade weil der Userintent sich ja... Der ist ja so divers. Die Frage ist eben, wann macht es Sinn? Also, macht ihr eine Unterscheidung zwischen dem verschiedenen Userintent und der Text? Ich sage mal, add a ratio oder der Textpositionierung weiter oben, weiter unten, das ist ja dann aber okay, weil wenn bei meiner Meinung nach, wenn der User auf der Seite, wenn der, das Ziel jeder URL sollte sein, den Userintent so schnell wie möglich zu befriedigen. Und dann ist es wiederum schwierig zu sagen, okay, wir müssen Texte, die gelesen werden möchten, weiter oben positionieren, wenn der Userintent gar kein Text ist, sondern von mir aus eine Liste, eine Funktion, ein Tool, ein Rechner, wie auch immer. Ja, das, ich denke, das macht euch aussehen. Das heißt, wenn ihr, sag ich mal, die Inhalt gehabt, die für den User relevant sind und wenn ihr die oben platziert, dann macht das eigentlich schon Sinn. Bei uns ist die Positionierung auf der Seite spielt ein bisschen eine Rolle, gerade bei Bilder und bei Videos. Das heißt, für die Bilder und Videos suchen, möchten wir natürlich Seiten haben, die als Bild- und Videolanding-Pages irgendwie geeignet sind. Und da ist es wichtig, dass diese Bilder und Videos quasi groß und oben platziert werden. In der normalen Websuche ist das weniger der Fall, dann können wir da schon ein bisschen mehr mit der gesamten Seite dann auch arbeiten. Und wenn Teil der Texte weiter unten sind, ist das eigentlich total okay. Und wenn ein Teil der Inhalte wirklich Tabellen und Listen sind, dann ist das eigentlich auch okay. Das sind ja eigentlich auch Informationen, die für den Benutzer relevant sind. Das andere, was ein bisschen eine Rolle spielt, ist quasi, wo die Werbung platziert ist auf der Seite. Das heißt, wenn wir erkennen können, dass im oberen Bereich der Seite die sichtbar wäre für den Benutzer, wenn das alles nur Werbung ist, dann haben wir da schon Algorithmen, die dann sagen, gut, das ist jetzt schlecht geeignet als Landing-Page, weil der Benutzer erkennt gar nicht, worum es sich hier handelt. Das ist jetzt alles nur Werbung. Aber wenn man das, sag ich mal, in einen gewissen Maß dann verwendet auf der Seite, ist das viel weniger problematisch. Und wenn oben Tabellen und Listen sind, und das entspricht den Benutzerbedürfnis, das ist total okay. Ich hatte einige Feature Snippets gehabt, wo der Text tatsächlich ganz unten war auf der Seite. Also sogar im Futter drin. Was passiert denn da bei Google eigentlich? Also, wieso erachtet ihr das denn als sinnvoll? Das kann schon sein, dass wir das als sinnvoll sehen. Also, es ist nicht, gerade bei der Textsuche ist es schon so, dass wir da versuchen, die gesamte Seite damit einzubeziehen. Okay. Das ist vielleicht auch ein Zeichen, dass einfach die anderen Seiten, die wir sonst haben in diesem Suchergebnis, dass die da noch weniger geeignet sind. Aber an und für sich kann das schon so passieren. Okay. Okay. Ich muss leider ein bisschen früher Pause machen. Aber wenn ihr noch weitere Fragen habt, könnt ihr die gerne noch reinkopieren bei YouTube oder in den nächsten Hangout. Ich versuche das noch diese Woche einzurichten. Oder natürlich auf Twitter fragen oder in den Hilferforum natürlich auch. Vielen Dank fürs Bebeikommen. Vielen Dank für die vielen Fragen. Und für die Hausarbeit, die ich da noch nachforschen kann. Eine Frage habe ich noch. Ja, okay. Bei Hausarbeiten, da beschäftigst du dich ja nochmal mit den technischen Dingen, die du gerade nicht beantworten konntest. Geht ihr denn nochmal selbst auf uns zu? Oder wie können wir Kontakt mit euch aufnehmen, damit die Fragen geklärt werden? Normalerweise versuchen wir die Sachen auf unserer Seite einfach zu beheben, sodass man da eigentlich nichts mehr machen muss. Und manchmal kommen dann einige auch im nächsten Hangout einfach wieder zurück und fragen nochmal nach. Aber es ist manchmal ein bisschen schwierig, weil wir geben die Information weiter an die Teams und wie sie das prioritisieren, das ist dann ein bisschen außerhalb unserer Kontrolle. Okay, alles klar. Super, vielen Dank. Bis zum nächsten Mal. Ja, tschüss allerseits. Tschüss. Ciao. Ciao.