 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 Webmaster kommen können und Fragen stellen können rund um die Websuche. Wie immer sind da schon einige Fragen eingereicht worden, aber wenn einer von euch loslegen möchte mit den ersten Fragen, seid ihr gerne dazu eingeladen oder auch nicht? Geht auch. Der Anfang ist immer schwierig. John, also ich springe gerne mal rein, ich hatte ein, zwei Sachen ja vor zwei Wochen schon mit dir besprochen. Das eine ist der Bug oder ich halte es für den Bug in der Search Console mit Abdeckung gecrawlt zurzeit nicht indexiert. Habt ihr da mal reinschauen können? Ja, wir haben das mal mit dem Team hier angeschaut und an und für sich sind da verschiedene Sachen, die da zusammenkommen. Aus unserer Sicht ist das etwas, was wahrscheinlich im Laufe der Zeit verbessert wird, aber es ist nicht so, dass wir das von einem Tag auf den anderen verändern können. Teil davon ist einfach, dass es da Zeitverzögerung gibt bezüglich diesen aggregierten Daten und Teil davon ist einfach, dass in Search Console ein Auszug aus den indexierten URLs dabei ist und nicht die vollständige Liste. Da kommt das dann manchmal so zusammen. Ist aber jetzt zum Beispiel für diese Seite, die ich euch geschickt hat, das war die Abendzeitung, würde ich Ihnen ein massives Problem, weil einfach diese Ansage ist nicht indexiert, also für mich komplett nutzlos, weil tatsächlich getestet 70, 80 Prozent der Tausenden von URLs hier drin waren, sind tatsächlich alle indexiert. Das heißt, dieses extrem verwirrende Ansage. Dann würde ich Sie bei der Webseite einfach ignorieren. Okay. Das ist das bei allen Webseiten so? Denke ich eigentlich nicht. Also, der kleineren Webseite vielleicht nicht. Zumindest habe ich das von anderen Webseiten, auch von größeren Webseiten nicht so gemeldet gekriegt und dem her denke ich. Schade, ich habe dies einfach schon ignoriert. Weiß ich nicht, kann sein. Okay. Dazu gleich die nachfolgende Frage, um das zu testen, ob die Sachen indexiert sind oder nicht, was ist da euer Zählerrat, weil da ist ja diese Meldung ist nicht indexiert, kriegt man natürlich erstmal einen Schock, so um 100.000 URLs nicht indexiert. Wie, was ratet ihr? Wie sollte man das prüfen, ob das tatsächlich im Index ist oder nicht? Man kann das mit dem Inspekt-Urall-Tool prüfen oder man kann das mit einer Side-Up-Frage prüfen und letztlich ist es aber so, dass aus unserer Sicht ist es ja nicht garantiert, dass wir alle URLs indexieren. Von dem her ist es eigentlich aus unserer Sicht normal, dass je nach Webseite da größere oder kleinerer Teile der Webseite nicht indexiert sind. Ich meine, die Search Console ist ja da, um festzustellen, ob irgendwelche bösen Bugs in meiner Webseite sind. Das heißt, wenn da so eine Meldung ist, da ist ein 10.000, 20.000, 50.000 URLs nicht indexiert, interessiert es natürlich schon. Ist es vielleicht so oder ist es gar nicht drin? Aber es gibt von eurer Seite also die Abfragen, was du eben gesagt hast, ist ja händisch, manuell eine URL nach der anderen. Das geht natürlich nicht, wenn ich 10.000 prüfen will. Das heißt, von eurer Seite gibt es da keinen offiziellen Weg, wie man das feststellen könnte. Da gibt es keine IPI. Das heißt, ich müsste also tatsächlich die Google Serbs crawlen und scrapen. Das ist gegen unsere Sichtlinien. Natürlich, es ist klar, aber was soll ich denn tun? Also ich meine, ich kann das ignorieren. Es bringt ja auch nicht viel, wenn du 10.000 URLs prüfst und schaust, ob die indexiert sind oder nicht. Du kannst das ja nicht irgendwie forcieren, dass die auf einmal indexiert werden. Nö, aber ich kann jetzt feststellen, zum Beispiel, ich konnte dadurch feststellen, dass ich es gemacht habe, dass das ist eben die Meldung totaler Quatsch war in diesem Fall und dass ich es tatsächlich ignorieren muss. Sonst hätte ich es ja nicht gewusst. Ich hätte ja eines, jede URL einzeln prüfen müssen, mit dem Zeitbefehl oder mit der Abfragen, das geht natürlich nicht. Okay, gut. Vielen Dank. Okay. Schauen wir mal die weiteren Fragen an. Wir benutzen auf unserer Website Parameter URLs wie Domain.de, Rubrik und dann frage ich mit Parameter, Parameter Detail, um Ergebnisse zu filtern und setzen diese per MetaRobots auf Noindex. Der Canonical Tag zeigt auf die Parameter URL, nicht auf die original URL, also nicht auf Strich Rubrik und wird auch nicht durch die robots. Sex blockiert ist es sinnvoll in euren Augen. Ein Hinblick auf Crawling Budget, Logik und Ranking Signale soll mir zusätzlich auch das Canonical auf die original URL leiten oder kann das vernachlässigt werden. Ich denke, grundsätzlich muss man überlegen, wie diese Parameter URLs gebraucht werden, das heißt, ob die für das Crawling der Website überhaupt relevant sind oder nicht. Und wenn sie nicht relevant sind für das Crawling der Website, dann kann man die durchaus so ausschließen. Wenn die wichtig sind für das Crawling der Website, dann würde ich schauen, dass man die normal crawlen kann, dass man von dort aus zu den einzelnen Unterseiten jeweils auch kommen kann. Aber wenn das wirklich nur ein Filtering ist oder wenn das Änderung der Sortierreinfolge ist, dann ist das an und für sich so okay. Bezüglich Canonical ist das an und für sich auch okay so. Man könnte auch auf die Rubrik URL, auf die höhere Ebene quasi zurückverweisen. Das könnte man auch machen. Es ist ein bisschen verwirrend, wenn man ein No-Index hat und zusätzlich ein Canonical auf eine andere Seite, aber in der Regel kommen wir damit eigentlich auch zurecht. Was ich da einfach probieren würde, ist zum Beispiel mit einem Crawler Tool, die Website mal durchgehen oder ein Teil der Website durchgehen, wirklich damit man einfach sicher ist, dass diese Seiten nicht wichtig sind für das Crawling der Rest der Website, dass man wirklich zu allen einzelnen Produkten jeweils trotzdem noch durchkommt. Und wenn das der Fall ist, dann kann man die durchaus so ausschließen. Dann eine Frage bezüglich der Beschränkung der Anzahl der ausgehenden Links pro URL, kann man zum Beispiel 5000 Links auf Produkte von einer URL statt 50 pagenierten Seiten mit je 100 Links, kann man das machen. Auch wenn so viele Links pagerend mathematisch keinen Sinn machen, ist es vielleicht trotzdem besser, auf diese Art zu verlinken als überduzende pagenierten Seiten. Man kann das durchaus machen. Ich glaube, bei uns ist die Beschränkung der Anzahl Links relativ hoch. Das heißt, mit 5000 Links kommt man da trotzdem noch gut durch. Wie weit das Sinn macht für das Crawling der Website, weiß ich nicht. Ich denke, das kann man wahrscheinlich ein bisschen auch ausprobieren. Es hängt auch ein bisschen davon ab, wie das eingebunden ist in der Website. Das heißt, wenn diese quasi fast Seitenapp-Seiten sehr schlecht verlinkt sind innerhalb der Website, dann bringen die an und für sich auch nicht wahnsinnig viel, egal ob die pageniert sind oder ob man einfach so viele Links auf eine Seite hinein nimmt. Wenn die gut erreichbar sind, wenn die auch für den Benutzer Sinn machen, dann kann man das durchaus so machen. Dann kann man da wahrscheinlich schon mehr von diesen Seiten auch durchcrawlen. Kannst du sagen, welcher Website besser ist? Also eine Seite mit 5000 Links oder 50 Pagenierseiten mit jeder als 100 Links angenommen, dass ich z.B. diese eine lange Side-Map-Artige, wie diese genannt hast, z.B. die Side-Wide im Vorderverlinke? Ich denke, das lässt sich nicht so allgemein sagen. Also, was ich da machen würde, ist das einfach mal testen. Wenn du irgendwo zugepfabte Server-Logs hast, dann siehst du ja, wie diese Seiten gekraut werden, wie die verlinkten Seiten gekraut werden. Und dann für diese Konstellation, die du da hast, siehst du dann relativ gut, ob das mit 5000 Links klappt oder mit 1000 oder mit 100 Links wieder am besten funktioniert. OK. Aktuell können wir über die Search Console keine Android-Apps als Property hinzufügen. Kommt das wieder? Oder wird das irgendwann möglich sein? Ich glaube, die haben wir jetzt im Moment alle rausgenommen. Aus Search Console meines Wissens wird das nicht groß da wieder eingebaut, sondern man macht das an für sich jetzt gerade für App-Indexing über Firebase. Das heißt, gar nicht mehr über Search Console. Ich weiß nicht, wie da die zukünftige Pläne sind, ob es da vielleicht wieder mehr Funktionen gibt, wie Android-Apps oder iPhone-Apps eingebunden werden können. Aber zumindest ist das der aktuelle Zustand. Ist es ein Problem für Google bzw. Google News, wenn in den strukturierten Daten für die Entität Image ein anderer Domain als Quelle des Bildes steht? Ich weiß nicht, wie das bei Google News ist, aber zumindest in der normalen Google-Suche ist das überhaupt kein Problem. Da können die Bilder durchaus auf einem anderen Domain sein, egal, ob das in den strukturierten Daten angegeben ist oder ob das direkt so eingebunden ist auf der Seite. Manchmal ist das ja auch aus praktischen oder Performance-Grunden gemacht, dass man mit einem CDN arbeitet, gerade weil die Bilder sich sehr wenig verändern. Dann kann man die gut cashen auf ein CDN nehmen und dann separate rausnehmen und dann so mit meinem separaten Domain oder zumindest separaten Subdomain entsprechend arbeiten. Und zumindest in der normalen Google-Websuche ist das überhaupt kein Problem. Bei Google News weiß ich nicht, ob da irgendwas speziell gemacht wird. Meines Wissens sollte das da auch kein Problem sein. Den Content ist ja schlecht und sollte gelöscht, weitergeleitet oder zumindest auf No Index gesetzt werden. Nun ist das natürlich für größere News-Websites die dutzende Inhalte am Tag veröffentlichen schwieriger als für ein Blog. Macht Google da Unterschiede bei der Bewertung oder sollten selbst große Websites regelmäßig alten Content und den Content überprüfen. Wir haben beispielsweise hunderte News, die einfach veraltet und heutzutage nicht mehr relevant sind. Ich denke, da kommen verschiedene Sachen zusammen. Grundsätzlich, wenn wir die Qualität einer Website anschauen, schauen wir da schon gesamthafte an für die Website und da machen wir keinen Unterschied über die Art der Website. Das heißt, egal, ob das eine News-Website ist, irgendein persönlicher Blog oder eine Firmen-Website ist oder irgendeine andere Art von Website, wir schauen die Website gesamthaft an und versuchen dann algorithmisch festzustellen, ob entsprechend die relevanten Teile dieser Website in Ordnung sind, ob die von der Qualität her dementsprechend was wir erwarten, was unsere Benutzer auch entsprechend erwarten. Und bei einer News-Website ist das natürlich so, wenn wir da die relevanten Teile der Website anschauen, dann sind das meistens eher die aktuellen Sachen, vielleicht die Kategorien, vielleicht die länger stehenden Rubriken, die da sind. Dann sind das wahrscheinlich eher die Inhalte, die längerfristig relevant sind für die Website, die da vielleicht auch ein bisschen stärker bewertet werden. Und der ganze Rest ist natürlich etwas, was zwar auch vorhanden ist, aber das wechselt sich regelmäßig aus und ist im Laufe der Zeit immer weniger relevant und von dem her auch entsprechend ein bisschen weniger stark bewertet für unsere gesamthaften Qualitätsalgorithmen. Das heißt, wir schauen da nicht nur die Anzahlseiten an und bewerten an jede Seite einzeln, sondern wir versuchen wirklich festzustellen, die relevanten Inhalte von dieser Website sind die jetzt von hoher Qualität oder sind die eher von niedriger Qualität? Dann eine lange Frage zu den strukturierten Daten, bezüglich gerade Produkt-Microdata auf Kategorienseiten. Und da ein bisschen der Frage, quasi, welche Variante ist jetzt nun korrekt oder nicht, gerade bei Kategorienseiten. Ich denke, das sind verschiedene Sachen ein bisschen vermischt, natürlich auch in der Dokumentation wahrscheinlich ein bisschen unklar. Grundsätzlich ist an und für sich die Grundidee, dass die strukturierten Daten sollten, den Haupt-Element dieser Seite entsprechen. Wenn man eine Kategorienseite hat, sind das natürlich unterschiedliche Produkte auf dieser Seite. Dann kann man durchaus die unterschiedlichen Produkten markieren mit Produkt-Microdata oder Produktmarkup, je nachdem, wie man das jetzt heißen soll. Wichtig ist einfach, dass man die gesamte Kategorienseite nicht als ein Produkt anschaut. Das heißt, man kann durchaus sagen, das sind jetzt verschiedene Produkte dabei. Wir können die verschiedenen Produkte entsprechend markieren mit Structuredata. Es sollte allerdings nicht sein, dass das eine Seite ist, wo man sagt, als Produkt sind da zum Beispiel Schuhe auf dieser Seite, sondern als Produkt hat man die verschiedenen Schuhmodelle, die da einzeln aufgeführt sind. Und ebenso ist es auch mit den Reviews, mit den Ratings, mit den Offers auf dieser Seite, ist es so, dass man die einzelnen Produkte kann man durchaus markieren. Aber die gesamte Seite sollte nicht als ein Produkt angesehen werden. Das heißt, man sollte nicht die Reviews aggregieren und sagen, all meine Schuhe haben im Durchschnitt eine Bewertung von 4,5. Oder all meine Schuhe sind preislich zwischen 100 und 200 Franken. Das sind, sondern man sollte wirklich das pro Produkt entsprechend anschauen. Und das müsste man da wahrscheinlich in der Dokumentation ein bisschen klarer sagen. Ich denke, dass es allgemein ein bisschen schwierig mit diesen vielen Varianten, die es da gibt. Aber muss man mit dem Team anschauen, wie man das ein bisschen verbessern kann. Das ist noch eine Frage. Es gibt keine offizielle Angabe von Google, in welchen Fall jetzt welcher Dokumentation ist das besser? Zum Beispiel auch für News. Ich habe die Frage jetzt nicht richtig verstanden. Kannst du vielleicht nochmal wieder auf die Seite? Es gibt von Google keine offizielle Angabe, wenn ihr News macht, nimm bitte diese Schema.org-Sachen. Wenn ihr Produkt macht, nimm bitte diese Schema.org-Sachen. Es gibt nicht so eine offizielle Empfehlung. Es gibt einfach die verschiedenen Arten von Schema.org. Aber du meinst quasi, ob man jetzt eine Seite aus Artikel markiert oder ob als News-Article. Genau. Also es gibt ja, ihr sagt, dass ihr irgendwo offiziell für das Produkt Shopping nehmt, bitte das und das. Und wenn Daten drin sind, nehmt das. Und die Dokumentation auf Schema.org ist ja sehr, sehr mager. Da steht ja eigentlich gar nicht, wofür man es genau einsetzt. Ja. Man sieht auch übrigens, wenn man verschiedene Webseiten anguckt, dass alle es verschieden machen. Es gibt irgendwie nichts Einheitliches, wenn man zu verschiedenen Newsseiten durchguckt, damit setzt jeder die Schema.org komplett anders ein. Das ist für sich auch okay. Ja, ist okay, aber was ist denn? Also es gibt offensichtlich keine, wo alle davon überzeugt sind, dass es das Beste ist. Gut, ich meine die Vermischung zwischen zum Beispiel Artikel und News-Article, das ist an für sich auch okay. Weil das sind ja ähnliche, von Schema.org gehören die ja an die ähnliche Familien und können scheitern auch ähnlich verwendet werden. Und es gibt ja auch viele Attribute, die optional sind. Und manchmal verwenden die manche nicht. Das ist an für sich total okay. Bei uns landen jede Menge Seiten im Index, die wir eigentlich schon ewig weitergeleitet haben per 301. Trotzdem landet die Ursprungs-Ural im Index und nach Ausschuss verschiedener Fehlerquellen haben wir das Gefühl, Google behandelt unsere 301-Redirects wie 302-Redirects aufgrund unserer Cash-Control-Einstellungen. Kann das einen Einfluss haben? Das geht meiner nach soweit, dass sogar HTTP-Urals immer noch indexiert werden, weil wir zwar HTTP auf HTTPS ohne Cash-Control weitergeleitet haben, danach im Redirect-Chain aber no-Cash verwendet. Was da wahrscheinlich passiert, ist, dass wir mit der Canonicalization einfach die verschiedenen Urals entsprechend anschauen. Das heißt, was da passiert ist, wir sehen, dass verschiedene Urals einen Teil von der gleichen Gruppe zugehören und das kann die Ursprungs-Ural von Redirects dabei haben, die Ziel-Ural der Redirects dabei haben, vielleicht auch andere Urals innerhalb der Website, die die gleichen Inhalte zeigen. Und dann innerhalb dieser Gruppe von Urals versuchen wir aufgrund von den Faktoren, die wir für die Canonicalisierung verwenden, die Urals herauszufinden, die am ersten oder am sinnvollsten entsprechend ist. Einerseits, wo wir das Gefühl haben, das passt eher zu dem zusammen, was ihr uns sagt als Website, andererseits, dass es auch für den Benutzer zusammenpasst in einigermaßen eine verständliche URL ist. Das heißt, nicht mit ewig langen Parametern dabei, solche Sachen. Und dafür verwenden wir Redirects einerseits, andererseits natürlich auch interne Links, Sitemaps, externe Links, Querverlinkungen wie hreflang, den REL Canonical, all die Sachen verwenden wir dazu. Und geben an für sich so ähnlich wie Punkte für die einzelnen Urals und die URL, die am meisten Punkte hat am Ende, das ist dann die URL, die wir entsprechend nehmen für den Canonical-Ural. Und da kann es durchaus sein, dass einzelne Faktoren auf eine URL zeigen und andere Faktoren eher auf die andere URL zeigen und das wird dann eher die andere URL als Canonical entsprechend nehmen. Selbst wenn der Redirects dabei sind, selbst wenn vielleicht ein REL Canonical noch dabei ist, wenn diese verschiedenen Faktoren nicht zusammenpassen, dann sind wir da ein bisschen ungewiss. Meistens kommt das daher, dass vielleicht intern, innerhalb der Website noch die alte URL verlinkt ist, dass wir dann das Gefühl haben, ihr verweist auf die alte URL innerhalb der Website und dann andererseits sagt ihr uns, die neue URL ist die richtige zum zeigen. Dann wissen wir nicht genau, was da effektiv gemeint ist. Das kann dazu da eigentlich da kommen. Ich denke, mit dem Cash Control Header sollte das überhaupt keine Rolle spielen. Auch 301, 302 Redirects, das spielt zwar schon eine kleine Rolle, welche Art von Redirect das da ist, aber an und für sich, wenn man 301 macht, ist das schon ein relativ starkes Zeichen. Aber es heißt nicht, dass es alle anderen Zeichen entsprechend übertrieben wird. Die andere Sache, die ich da vielleicht anschauen würde, ist, wenn man eine Side-Abfrage macht von einer Website gezielt, die alten URLs sucht, dann zeigen wir die trotzdem in den Suchergebnissen, weil wir das Gefühl haben, du suchst gezielt nach diesen alten URLs, also zeigen wir sie dir auch. Das heißt, wie man dann eher schauen kann, welche URL verwendet worden ist, indem man z.B. einfach einen Titel sucht oder einen Teil vom Text auf dieser Seite und dann sieht man sehr schnell, dass diese URL effektiv dafür die Indexierung verwendet wird. Wichtig ist vielleicht auch zu sagen, dass das vom Ranking her eigentlich keinen Einfluss hat, welches diese URLs wir verwenden. Wenn die ein Teil von der gleichen Gruppe sind, dann kann da an und für sich jeder diese URLs dargestellt werden in den Suchergebnissen und vom Ranking her ist das eigentlich das Gleiche, egal welches diese URLs verwendet werden. Das heißt, was ich da jetzt im ersten Moment vielleicht machen würde, ist nachschauen, wie du überprüfst, welche URL indexiert ist und dann im zweiten Moment würde ich mal überprüfen, all die anderen Faktoren innerhalb der Website passen die zusammen, ist die interne Verlinkung vielleicht so, dass sie auf die alten URLs zeigt oder ist das wirklich angepasst auf die neue URLs, sind die Sign-App-Dateien aktualisiert, die da ein bisschen eine Rolle spielen. Wir haben im Hilfe-Center ein Artikel, wo dann auch die verschiedenen Faktoren aufgeführt werden für die Canonicalization. Das ist, glaube ich, der Artikel mit dem Royal Canonical insgesamt. Dann eine Frage von David bezüglich der SPAM in Google Alerts. Ich weiß nicht genau, was ich dazu sagen kann, weil Google Alerts ein bisschen separat läuft. Je nachdem, wie das eingerichtet ist, ist es ja auch so, dass wir da versuchen, möglichst schnell diese Alerts zu triggern und dass da vielleicht das Spam filtering noch nicht greift. Aber wenn du das in Google Alerts meldet, sollte das eigentlich schon ans Team kommen. Ja, das ist gar nicht so leicht, so etwas zu melden, weil es tatsächlich so die, ich hab das dokumentiert da, vielleicht kannst du das in dem Thema und ich hab schon oft diese SPAM-URLs gemeldet, aber die sind ja so vergänglich, dass wir da keiner, die sind dann nicht blöd, die Leute, die das machen, das wird dann morgen wieder weg sein und woanders hingewandert sein. Und mich hat gewundert, dass diese, dass diese URLs, die angezeigt werden oder die Domains, die angezeigt werden auf den ersten Blick für mich komplett SPAM-Domains sind, wo ganz klar ist schon vom Snippet, dass das gescrapte Ergebnisse sind und da bewundert es mich, dass Google da das durchlässt. Das wäre wirklich so leicht einmal kurz drauf zu klicken quasi, um zu sehen, Ups, das ist dreckes SPAM, also wirklich der furchtbarsten Art. Und wo überhaupt kein Zweifel ist, dass das SPAM ist und wo die Domains auch nur dafür angelegt sind, das ist tatsächlich für mich verwunderlich und das hält sich schon sehr, sehr, sehr lange. Da ist wirklich Google Alerts ein echtes SPAM-Schleuder. Hast du das auch mal gesehen? Ich benutze schon, aber ich sehe das eigentlich sehr selten. Ich kann auch dein Dokument nicht öffnen. Ich weiß nicht, dass der richtige Link ist oder ob da irgendwas vielleicht mit den Berechtigungen vielleicht anders ist. Okay, dann gucke ich gleich noch die Berechtigungen dafür und schick dir das nochmal separat. Okay, super. Danke. Wenn es um ein Domainumzug geht, soll man da auch die Bilder per 301 weiterleiten oder muss man das nicht machen. Wenn es um die Veränderung der URL-Struktur von Bildern geht, braucht man da die 301 Weiterleitungen? Ja, auf jeden Fall. Es ist so, dass Bilder in der Regel weniger häufig gekraut werden. Und gerade deshalb ist es wichtig, dass wir da ein 301 Redirect finden, damit wir die ganzen Signale, die das alte Bild gesammelt hat, dann wirklich auch an das neue Bild weitergeben können. Weil was sonst passieren würde, wenn nur die HTML-Seite diesen Redirect macht, dann sehen wir diese neue HTML-Seite, die den Redirect gemacht hat. Und wir sehen effektiv neue Bilder, die da eingebunden sind und müssen dann erstmal annehmen, das sind ganz neue Bilder. Wir müssen die vielleicht erstmal verstehen und verstehen, wie man die in der Bildersuche zeigen kann. Hingeben, wenn wir wirklich die alten Bilder crownen können und den Redirect sehen und das dann wieder passend in der Seite entsprechend auch sehen als Entwicklung, dann ist das für uns eigentlich relativ klar, dass diese Bilder einfach von einem Ort zum anderen Ort weitergegangen sind. Und dann können wir die ganzen Signale entsprechend auch viel einfacher weitergeben. Das heißt, wenn man einen Domain umzug macht, wenn man eine Strukturveränderung der URLs auf der Website macht, würde ich auf jeden Fall schauen, dass man diese Bilder weiterleiten kann. Wenn möglich, würde ich vielleicht auch überlegen, wie man das mal einrichten kann, dass diese Bilder sich nicht immer wieder verändern müssen. Wenn man zum Beispiel mit einem CDN arbeitet, würde ich schauen, dass man diese CDN auf dem eigenen Subdomain hat, damit diese Bilder jeweils gleichbleiten auch wenn man dann später von einem CDN zum anderen CDN wechselt, dann mit dem eigenen Subdomain kann man ja die gleichen URLs behalten. Das heißt, gerade bei Bildern ist es sehr wichtig, dass man da auf die URLs achtet und das sieht man meistens nicht so einfach wie mit html-Seiten. Das heißt, da lohnt sich es erst recht ein bisschen, vielleicht mit eigenen Tools das auch anzuschauen und zu überlegen werden alle URLs, die wir vorher hatten als Bilder, werden die auf Sauber weitergeleitet an die neuen URLs. Wie geht Google mit Backlinks um die Aufseiten mit No-Index Follow verweisen? Kommt der Linkjuice auf der Domain an und wer trotz No-Index weitervererbt oder werden No-Index-Seiten wie 404-Seiten behandelt das ist wie eine eine Vermischung von diesen beiden Varianten. Das heißt, wenn eine Seite längerfristig auf No-Index ist und wenn das etwas ist, was wir nicht sehr häufig verlinkt sehen, dann nehmen wir schon an, dass es eher eine 404-Seite ist und lassen die aus dem Index fallen. Es macht ja auch keinen Sinn für uns die beizubehalten im Index, wenn die auf No-Index ist, dann können wir die ganzen Informationen, die da sind entsprechend nicht beibehalten. Das heißt, wenn der interne Verlinkung auf diesen Seiten ist all das wird entsprechend dann doch fallen gelassen und die Links, die auf diese Seiten verweisen, die werden schlussendlich ignoriert. Das heißt, für uns ist hier gerade bei Links wichtig, dass wir von einem Canonical URL zu anderen Canonical URL diesen Link weiterhalten können. Und wenn die Ziel-Url dann gar nicht mehr bei uns im Index vorhanden ist, dann verfällt dieser Link an und für sich. Wenn das entgegen Seiten sind, die häufig verlinkt werden, dann ist es eher schon so, dass wir sagen, gut, wir sehen diese Seite relativ häufig, die werden häufig verlinkt. Irgendwas ist da wahrscheinlich interessant. Wir behalten die im Index. Wir sind da nicht an in den Suchergebnissen, aber wir verarbeiten sie, wir verarbeiten die Links auf dieser Seite und entsprechend die Links, die reinkommen und die Links, die rausgehen von dieser Seite, da können entsprechend die Signale, das PageRank und all das entsprechend auch weitergeben. Das sind an und für sich die zwei Varianten da. Grundsätzlich, wenn man wirklich sicher sein möchte, dass Seiten gut verwendbar sind und das Lending Pages für externe Links, dann würde ich auch schauen, dass man die indexieren kann, so dass man wirklich auch sicher ist, dass dadurch Signale weitergegeben werden können. Ich finde es immer ein bisschen schwierig, wenn man sagt, ich möchte, dass Leute auf diese Seite hier verlinken, aber diese Seite soll gar nicht indexiert werden. Das wirkt ein bisschen kompliziert oder unnötig kompliziert. Wenn man schon schaut, dass andere externe Leute auf eine Seite verlinken, dann würde ich schon schauen, dass diese Seite auch entsprechend was sinnvolles ist, was ihr indexiert haben wollt. Wenn man ein Adressportal ähnlich wie Yelp betreibt, welches über verschiedenen lenderspezifischen Top Level Domains aufrufbar ist, wie verferrt man dann am besten mit den einzelnen Adressen, sollen die nur über eine eindeutige Top Level Domain für das jeweilige Land besitzen oder unter verschiedenen URLs aufrufbar sein, die dann mittels Canonical Tag Verwendung jeweils auf die Hauptseite verweisen. Das ist immer, ich denke wie mit vielen Sachen, Grund um SEO, immer ein Balance, den man da suchen muss. Einerseits, wenn man verschiedene Top Level Domains verwendet und man verschiedene Domains verwendet, dann kann man eher lenderspezifisch etwas machen. Andererseits, wenn man viele Domains verwendet, dann verdünnt man sozusagen den Wert der Website. Das heißt, es ist dann schwieriger für diese einzelnen Versionen, auch stark in den Suchergebnissen zu erscheinen. Das heißt, ich würde da, wenn möglich, würde ich schon anraten, dass man erstmal mit weniger URLs arbeitet als mit vielen URLs. Das heißt, entweder mit dem Canonical Tag jeweils auf die optimalste Variante verweisen oder mit einem redirect score oder vielleicht die Inhalte nur auf eine dieser Varianten entsprechend aufhören, so dass man wirklich sicher ist, dass dieses Inhalt Stück, das man da hat, dass es wirklich auch sehr stark ist und dass es wirklich auch gut in den Suchergebnissen erscheinen kann. Wenn man das aufteilen will, auf verschiedene Top Level Domains ist das an und für sich machbar das ist eine Strategie, die manche Websites so verbetreiben. Was praktisch da in vielen Fällen passiert, ist, dass wir dann erkennen können, das sind die gleichen Inhalte auf verschiedenen Domains und dann geht das quasi in Richtung Canonicalization wieder. Das heißt, wir sehen, diese URLs sind in der gleichen Gruppe, die haben die gleichen Inhalte, wir suchen ein von diesen URLs aus und zeigen die in den Suchergebnissen. Manchmal geht das sehr gut, manchmal geht das nicht so gut, gerade wenn eine Seite sehr dynamisch ist, dann kann es sein, dass wir die Seite einmal crawlen und die Inhalte so finden und das nächste Mal, wenn wir sie crawlen, was vielleicht ein paar Tage später ist oder eben die andere URL, wenn wir die crawlen, was vielleicht ein paar Tage später ist, dann sehen wir ein leicht andere URLs, dann können wir nicht genau erkennen, dass das wirklich zusammengeklappt. Aber wenn sie natürlich nicht zusammengeklappt werden können, dann müssen sie für sich selber dastehen und müssen dann auch einzeln in den Suchergebnissen ranken und das ist dann, je nach Webseite, natürlich wieder ein bisschen schwieriger. Wenn man eine sehr große, starke Webseite hat, ist das vielleicht ein bisschen einfacher, dass man sagt, gut, wir teilen das auf in verschiedenen länderspezifischen Domains und machen das so, dass sie entsprechend in den einzelnen Ländern sind. Gerade bei kleineren Webseiten lohnt es sich schon, dass man da wirklich einfach die ganzen Signale alles ein bisschen konzentriert und dafür stärkere Seite macht und nicht allzu vieles. Dann ist da eine Spam-Meldung, die mal an das Team weitergehen. Ist es in einem neuen Search Console nicht mehr möglich, den doppelten Title Tag und doppelten Descriptions einzusehen? Bei einem Online-Shop mit Tausenden von Seiten kann das durchaus mal vorkommen, was man jetzt nur mit Kosten-Wichtigen Optimisation anzeigen lassen kann. In Search Console haben wir, ich glaube, das mit den doppelten Title Tags und doppelten Descriptions haben wir herausgenommen, ich glaube schon vor einiger Zeit. Weil wir gesehen haben, dass das sehr selten verwendet wird und dass es ein bisschen verwirrend ist und es schwierig zu aktualisieren ist. Man kann das natürlich auch mit einfachen Mitteln selber zusammenstellen, je nachdem, welche Kenntnisse man da hat. Es gibt sicher auch External Tools, die das relativ schnell machen können. Wobei fällen jetzt keine Namen konkret ein. Ich kann mal schauen, ob ich da vielleicht was Kurzes zusammenstellen kann, mit ein paar Links und poste das dann nachher mal auf Twitter. Dann ein Link zu einem Bild wo man nach Audi, Cabriolet sucht und bekommt verschiedene Arten. Davon ist das eine neue Funktion. Warum sind hier japanische Ergebnisse Begriffe dabei und hat die Funktion einen Namen und Zukunft bei Google? Meines Wissens ist das schon sehr lange so, dass man da nach Kategorien suchen kann und dass da solche Ergebnisse gezeigt werden. Bezüglich der japanischen Ergebnisse weiß ich nicht, was da im Spiel ist. Das klingt ein bisschen fehler, aber an für sich ist es eigentlich relativ alt, dass man da so verschiedene Kategorien auch entsprechend sehen kann und dann entsprechend auch die Suche ein bisschen verfeinern kann und er die auch das genaue Produkt quasi dann eher danach suchen kann, um das zu finden. Gibt es da noch andere Beispiele oder auf andere Bereiche oder Produktarten, ist das noch anzuwenden? Weil ich habe es jetzt wirklich nur, wir haben überall mal gesucht und ohne so eine Darstellung haben wir jetzt wirklich nur bei Audi Cabrio. Wenn man BMW Cabrio eingift, findet man schon wieder nichts. Ich habe gemeint, das gibt es schon sehr lange, aber vielleicht ist es etwas, was auf Englisch schon sehr lange existiert und auf Deutsch erst jetzt langsam kommt. Okay. Also ich vermute, wenn du auf Twitter Barry Schwartz fragst, dann wer da dir sagen können, genau wann das gekommen ist. Ich weiß auf Anhieb nicht, er sammelt solche Sachen und findet das dann relativ schnell heraus. Okay, danke. Keyword Stuffing, was bedeutet das? Keyword Stuffing. Grundsätzlich ja, wo kann man da anfangen? Ist es so, dass gerade am Anfang der Suchmaschine, als die erst angefangen haben, war es so, dass die Suchalgorithmen eher einfach waren und dass man dann eher gesagt hat, wenn ein Keyword mehrmals auf eine Seite vorkommt, dann muss diese Seite besonders relevant sein für diese Keywords. Und als man das gemerkt hat, hat man natürlich sehr schnell reagiert und entsprechend dann angefangen einfach Keywords mehrmals auf eine Seite zu bringen. So weit, dass wenn man diesen Text einfach vorliest, dass es total unnatürlich klingt und das geht dann in Richtung all dieser SEO-Witze die da existieren, wo einfach all die verschiedenen Keywords immer erwähnt werden auf einer Seite. Ich würde sagen in den letzten, 10 Jahren ist das sicher so, dass die Suchmaschine da anfühle, sich schon damit umgehen kann und meistens ist es ja auch relativ einfach zu erkennen, wenn gewisse Keywords einfach mehrmals wiederholt werden. Und was da in der Regel dann passiert zumindest auf Google-Seite, wenn wir sehen, dass da wirklich starkes Keywords-Stuffing betrieben wird, dann schalten unsere Algorithmen erstmal einen Schritt zurück und sagen, ja, wir wissen jetzt nicht, ob wir diesen Keywords wirklich trauen können, weil sie ja so häufig und so unnatürlicherweise wiederholt werden und dann sind wir dann erstmal ein bisschen kritischer mit dieser Seite. Und das geht so weit an und für sich auch, dass sag ich mal, dass es da gewisse Tools gibt, die auch nach der Keyword-Frequenz innerhalb einer Seite dann Tests machen und sagen, man muss ein Prozent aller Wörter sehen, dann ist das gut. Und das sind alles Sachen, die an und für sich moderne Suchmaschinen brauchen das nicht und die erkennen solche Versuche relativ schnell und können damit eigentlich schon relativ gut umgehen. Es gibt immer wieder Situationen, wo man sagen muss, ja, das könnte ja eigentlich jeder erkennen, dass diese Keywords nur da irgendwie platziert werden, ohne besondere Bedeutung, wo unsere Algorithmen das auch vielleicht verbessern werden können. Aber an und für sich können wir da relativ gut mit umgehen. Das heißt, es lohnt sich sicher nicht, der künstlich Keywords in großer Menge auf Seiten zu platzieren, einfach damit man das Gefühl hat. Wenn ich jetzt, ich weiß nicht, blaue Schuhe irgendwie hundertmal verwende auf dieser Seite, dann kommen alle Suchmaschinen und sagen, das ist jetzt die beste Seite für blaue Schuhe. Dann zu den hoch auflösenden Fotos steht dies im Zusammenhang mit Lazy Loading, assoziiert Google mit Keywords und findet resultate Ortsbezogen. Ich glaube, das sind verschiedene Fragen. Die hoch auflösenden Fotos, das haben wir bei Google Iow erwähnt, dass das kommen wird. Ich glaube, das ist noch nicht soweit, dass man sich da entsprechend auf die großen hoch auflösenden Fotos entsprechend freigeben kann für die Suche. Im Moment ist es ja so, dass wir in der Bildersuche eher einen kleinen Thumbnail verwenden und mit den hoch auflösenden Fotos kann man dann zum Beispiel sagen, ich möchte, dass auch die größeren Bilder dargestellt werden in der Bildersuche, gerade wenn man etwas hat, wo man sagen kann. Es macht für mich Sinn, dass benutzer hoch auflösende Fotos sehen in der Suche und dass sie dann eher zu meinen Inhalten kommen. Ich denke, da muss jeder ein bisschen selber überlegen, ob das Sinn macht, diese Fotos freizugeben oder nicht. In einigen Fällen kann ich mir schon vorstellen und sagen, ich möchte die auf meiner Website behalten und möchte wirklich nur kleine Thumbnails in den Sucheergebnissen zeigen. Das ist auch aus meiner Sicht vollkommen okay. Das hat keinen Zusammenhang mit Lazy Loading. Lazy Loading ist eine Technik, die man mit Lazy Loading verwenden kann, um Bilder nach Bedarf zu laden. Das heißt, wenn eine Website geladen wird im Browser, dann kann man mit Lazy Loading sagen, diese Bilder, die unterhalb vom sichtbaren Bereich sind, sollen erst dann geladen werden, wenn sie dann wirklich im sichtbaren Bereich sind. Das macht es in der Regel so, dass diese Seiten schneller geladen werden können. Vielleicht ein bisschen schneller mit der Website zurecht und können da vorwärts machen. Assoziiert Google mit Keywords und findet resultate Ortsbezogen. Ja, teilweise. Das heißt, ich weiß nicht genau, wie die Frage gemeint ist, aber grundsätzlich ist es schon so, dass es nicht so wichtig ist, dass man den Standort von Benutzer dazu zu nehmen, wenn wir erkennen können, dass die Suche nach etwas lokalem ist. Das heißt, wenn wir erkennen können, dass der Benutzer wirklich etwas aus der Umgebung haben möchte, dann kann man das entsprechend auch so weiter verwenden. Das heißt, wenn ich zum Beispiel nach einem Restaurant suche, möchte ich wahrscheinlich eher etwas haben, was in meiner groben Umgebung mit dem Keyword Restaurant versehen ist. Dementsprechend ist das ein bisschen unterschiedlich, je nach Suchanfrage. Was wir auch noch machen, ist, wenn wir erkennen können, dass die Suchanfrage eher überregional gemeint ist, dass wir dann die einzelnen Resultate aus einem Land entsprechend ein bisschen stärker betonen. Wir nennen das Geotargeting. Das heißt, wir sehen, dass der Benutzer etwas einkaufen möchte und wir wissen, dass es Websites gibt, die in der Schweiz tätig sind und der Benutzer ist in der Schweiz und macht es vielleicht eher Sinn, dass wir diese Schweizer Websites zeigen, statt deutsche Websites oder vielleicht amerikanische Websites, die irgendwie vielleicht auch in die Schweiz liefern würden oder vielleicht nicht einmal in die Schweiz liefern würden. Das ist das, sag ich mal, so die verschiedenen, fast wie Ebenen, die dazukommen können. Einerseits, dass man wirklich lokal etwas sucht, was so in der Ortumgebung ist, andererseits was länderspezifisch ist und es gibt natürlich auch viele Suchanfragen, die eigentlich nur nach Informationen suchen, welches dann global an und für sich verwendet werden kann. Du hast den letzten Hänger gesagt, ich habe das Problem, dass für jede flacken Variante und Longtail Produkte, die einmal in 6 Jahren gesucht werden, eine eigene URL habe. Ich habe mir folgende Lösung überlegt. Die unwichtigen Produkte bekommen ein No-Index und werden nur noch über die Kategorien-Seite gefunden, die links zu den No-Index-Produkten verwendet werden. So, dass Google die unwichtigen URLs nicht mehr crawlen muss und kein Page-Rang verloren geht. Die Produktdetails-Seiten der unwichtigen URLs existieren praktisch nur noch für den User. Könnte das klappen oder siehst du da Probleme? H0 für sich kann doch schon klappen. Also, ich denke da musst du dir, musst du selber überlegen, ob das so für dich ist. Ob diese Produkte wirklich gar nicht in den Suchergebnissen erscheinen sollen. Aber das kann durchaus so eine Lösung sein. Also, ich würde jetzt nicht sagen, dass man das machen muss, dass man so Produkte, die sehr selten gesucht werden, dass man die so verstecken muss. Aber man kann das durchaus so machen oder man kann das auch mal so testen und ausprobieren und schauen, funktioniert das, funktioniert das nicht. Gerade wenn man die Website verändert und erstmal eine Detail-Seite auf No-Index-Sets und die Verlinkung entsprechend herausnimmt intern, dann wird es wahrscheinlich schon so sein, dass wir für eine gewisse Zeit trotzdem diese URL erst mal weiter normal crawlen. In der Regel ist das ja auch kein Problem. Bei den allermeisten Websites ist Crawl-Budget eigentlich nicht ein Problem, dass man da irgendwie weniger URLs haben muss, weil wir nicht mit dem Crawling durchkommen, sondern ich denke auch bei dir ist es weniger das Crawling, sondern eher einfach die Frage von wie kann ich es so machen, dass einzelne Seiten meiner Website ein bisschen mehr Information dabei haben oder ein bisschen mehr Signale sammeln können, auch wenn die Produkte dann nur ein Teil von diesen Seiten ausmachen. Und ich denke von dem her sollte das schon machbar sein. Meine Online-Shops haben extrem hohe Schwankungsbreite bei der Sichtbarkeit. Die Shops sprechen teilweise mit 80 Plätzen Verschiebungen im Ranking auf Google Updates an. Ist ein ständiges Hin- und Her. Manchmal ranken Keywords auf der ersten Seite, dann kommt wieder ein Update und die Keywords rutschen runter auf Seite 8. Woran kann das liegen? Schwierig zu sagen. Meist nicht genau, wie man da das am besten anschauen könnte. Meistens ist es so, wenn wir größere Ranking Schwankungen sehen, ist es so, dass unsere Algorithmen da nicht 100%ig sicher sind, wie sie mit dieser Website umgehen sollen. Das wäre vielleicht eine Variante, die man anschauen kann. Aber es ist natürlich schwierig zu sagen, gerade wenn das ein größerer Shop ist, wo sind da die Probleme oder wo könnte man etwas verbessern. Ja, ich habe da nicht etwas Konkretes, wo ich hinzeigen könnte und sagen, das ist das Problem. Ich denke, die Idee mit dem Konzentrieren der Signale auf weniger Seiten, das ist vielleicht eine Variante, die man angehen könnte. Ich würde da einfach sicher stellen, dass die Qualitäts von diesen Kategorienseiten dann nicht daran leidet, dass allzu viele Produkte da auf einmal verschachtelt werden. Ich würde mich interessieren, ob für die Bereitstellung von Job Content der häufig aktualisiert wird, besser ist die API zu benutzen oder ob die Bereitstellung einer die Jobs leistet. Gute Frage. Ich vermute, dass es über die API ein bisschen einfacher ist bzw. ein bisschen schneller geht. Einfach daher, weil das direkt mit unseren Systemen so verbunden ist und auch weil man über die API angeben kann, welche Seiten jetzt nicht mehr aktuell sind. Mit den Jobs kann es ja passieren, dass ein Job besetzt wird und dann möchte man dieses Listing möglichst schnell aus dem Index herausnehmen und das kann man über die API angeben. Über die Sitemap kann man eigentlich nur angeben, diese URL hat sich verändert und wir schauen die dann an und versuchen festzustellen, was meint ihr damit? Aber mit der API kann man gezielt auch sagen, diese URL wurde entfernt und ich habe eine ganz kurze Rückfrage. Es geht darum, es geht um die Joblistings von einem Personaldienstleister und das sind ungefähr so 300, 400 Jobbackanzen, die da ständig aktuell sind und die aktualisieren sie im 2-3-Tages-Rhythmus. Das hat damit zu tun, dass man auf anderen Jobbausen besser gelistet wird, wenn die Dinge aktueller sind. Es könnte ja auch eine Strategie sein, dass man spezifische Jobs, die explizit für Google bereit gehalten werden und dann auch ein bisschen Historie und Signale aufbauen können. Ich nenne es diese Spammingstellen, die explizit ausschließt, die ausgliedert. Ich würde nicht sagen, dass man die URLs längerfristig beibehalten muss, um da irgendwelche Signale einzusammeln. Ich weiß jetzt nicht, dass bei Google für Jobs insgesamt angeschaut wird, aber es ist eigentlich normal, dass es Stellen gibt, die besetzt werden und dann sind sie nicht mehr da und dann kommen neue Stellen dazu. Also von dem her würde ich nicht sagen, dass es sich lohnt, künstlich die Stelleneinträge quasi beizubehalten und immer wieder zu aktualisieren, sondern wenn sie besetzt sind, dann würde ich einfach die neuen reinnehmen und die Alpen rausnehmen. Aber ich denke gerade, wenn man jetzt einige Hunderte von Stellen hat, dann ist wahrscheinlich die Aktualisierungsgeschwindigkeit mit einer Sitemap und mit der API sehr ähnlich. Wenn man jetzt einige Hunderttausend hat, die ständig rein und rauskommt, dann kann man mit der API wahrscheinlich ein bisschen mehr herausholen. Aber wenn das nur einige Hunderte sind, dann ist das mit einer Sitemap der Time, mit dem normalen Crawling, ist das eigentlich recht gut machbar. Okay, darf ich da ganz kurz nachfragen, weil ich bin jetzt auch kein Webmaster, das ist ein Marketing. Wie lange dauert das durchschnittlich, wenn man quasi Google-Meteil die Sitemap hat sich verändert, bis der Bot wieder vorbei kommt und den Content aktualisiert? Das hängt ein bisschen von der Website ab. Wenn wir sehen, dass die die Seiten, die in der Sitemap-Datei gelistet sind mit dem aktuellen Aktualisierungsdatum dabei sind, wenn wir sehen können, dass wir dem gut trauen können, dann geht das relativ schnell. Dann ist das eine Frage von Minuten, Stunden in dem Rahmen etwa. Ähnlich ist es auch mit der Indexing-API. Ich glaube, da ist es ein bisschen schneller, bis der Bot dann wieder vorbei kommt. Aber das ist immer noch weniger als ein Tag. Danke. Dann eine Frage zum aktuellen Google Update. Sofern du etwas dazu sagen kannst, das wird wahrscheinlich schwierig. Mal schauen. Wir betreiben eine Nischen-Seite im Gesundheitsbereich. Wir haben nach dem Medical Update letztes Jahr sehr gelitten. Wir haben eine Reihe von Maßnahmen ergriffen. Unter anderem Frage-Antwort-Portal ausgelagert, Artikel konsolidiert, Redaktion mit weiteren Experten verstärkt, mehr Transparenz geschaffen. Das war erfolgreich und wir sind seit dem Jahr dabei sehr erfreulich in on-page KPIs. Nun haben wir im Zuge des aktuellen Updates 50% unseres organischen Trafiks verloren. Vorgelegt sind Apotheken-Seiten, Fachmagalzine, Art-Seiten und große Brands auf großen Verlagen. Die rankenden Beiträge sind zum Teil sehr schwer verständlich für Nicht-Experten oder wirklich vergleichbar zu unseren eigenen Texten. Wir wissen nicht, was wir da machen sollen oder wie man da konkurrenzieren kann. Schwierig zu sagen ohne konkrete Beispiele zu sehen. Was du gerne machen kannst, ist mir einige Suchbegriffe mal zuzuschicken und einige von euren Seiten entsprechend dabei zu nennen, damit ich das wirklich mit dem Ranking-Team hier mal anschauen kann. Ich bekomme ab und zu solche Beispiele von verschiedenen Websites und das ist immer sehr interessant für das Ranking-Team diese Beispiele konkret anzuschauen. Das heißt, es hilft uns relativ wenig, wenn man sagt es sind jetzt mehr Apotheken in den Suchergebnissen, sondern wenn man wirklich sehen kann für diese Art von Suchbegriffen oder für diese konkreten Suchbegriffen sind jetzt diese Seiten vorhanden und die Ergebnisse sind schlechter als vorher aus diesen Gründen. Dann ist das wirklich etwas, was für das Ranking-Team sehr wichtig ist. Schwierig ist natürlich auch, wenn wir sagen, ja, die anderen Seiten sind genauso gut, wie die Seiten, die jetzt gezeigt werden in Suchergebnissen, dann ist da eigentlich kein Handlungsbedarf vom Ranking-Team her, weil sie denken, wenn es genauso gut ist müssen wir ja nichts verändern, oder? Das heißt, es hilft uns wirklich, wenn wir konkrete Suchanfragen sehen, wenn es nicht schlecht sind, wo man wirklich sagen kann, da könnte man etwas Besseres machen. Und das habe ich schon einige Mal von verschiedenen Leuten hier in den Hangouts bekommen und das war eigentlich immer sehr hilfreich für das Team. Ich kann nicht versprechen, dass wir da diese Such Suche entsprechend anpassen und dass wir da manuell etwas verändern, damit eure Seiten wieder höher erscheinen. Aber das ist auf jeden Fall sehr wichtig für das Team, dass wir solche Beispiele haben. Wie sieht die Zukunft vom Data Highlighter aus? Ist bisher noch nicht in den neuen Search Console? Gute Frage, weiß ich nicht. Data Highlighter wird vom Structured Data Team an und für sich gemacht. Vielleicht müsste man das dann einfach nur ein bisschen sauberer verwenden. Ich müsste mal anschauen. Okay, zeitlich sind wir leider jetzt ziemlich am Ende. Ich sehe, da sind noch ein paar Fragen dabei. Ich schaue mal, ob ich da etwas dazu noch sagen kann. Und ja und im Chat sind da auch alles mögliche Sachen noch dabei. Okay, kopiere ich das alles mal raus und speichere das auf der Seite ab. Okay, dann bedanke ich mich erstmal für die vielen Fragen und Hinweise von euch. Ich schaue die Sachen auf meiner Seite auch mal wieder an mit dem Team. Wenn ihr mir weitere Informationen schicken wollt, zum Beispiel über die Bemerkungen da beim Hangout, könnt ihr das gerne machen. Ich richte auf jeden Fall auch noch die nächsten Hangouts ein, dass wir uns das nächste Mal vielleicht wieder treffen können. Okay, dann wünsche ich euch allen noch einen schönen Tag und hoffentlich sehen wir uns in ein von den nächsten Hangouts wieder. Tschüss allerseits. Merci.