 Okay, herzlich willkommen beim heutigen Webmaster Essentials 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 SEO Publisher zu uns kommen können und Fragen zur Websuche stellen können. Wie immer sind da schon einige Fragen eingereicht worden, aber wenn einer von euch möchte, könnt ihr gerne schon mal loslegen oder auch nicht, geht auch, okay? Dann schauen wir mal, was da reingekommen ist über YouTube. Seit dem 14.02. wird in Search Console die Meldung entweder Offers, Reviews oder Aggregate Ratings müssen angegelt werden. Ich glaube, das ist bei Produkten, wenn man den Produktmarkup verwendet, da wir in Fehlerfällen keine Ratings haben und auch keine Reviews existieren, müssen da wohl öfter Offers nehmen und per Microdata bereitstellen. Bei internationaler Ausrichtungen und Shops sind unterschiedliche Preise üblich, zum Beispiel für Schweiz und Deutschland. Wertet Google die Region am Offer aus und beachtet dies dann auch in den Suchergebnislisten. So einfach ist das wahrscheinlich dann da nicht. Das heißt, pro URL, die wir erfinden für diese Website, müssen wir da einen gezielten Offer haben. Das heißt, wenn man verschiedene Währungen als Offer zum Beispiel angebt, dann wird das wahrscheinlich so sein, dass wir einfach einen auswählen und den zeigen. Das ist nicht automatisch angepasst an den Benutzer, sondern es ist einfach pro Seite nehmen wir da einen Offer, von dem die da aufgeführt werden und zeigen das unter Umständen in den Suchergebnissen an. Was man machen müsste, wenn man in einem solchen Fall unterschiedliche Offers hat pro Land, müsste man an und für sich mit separaten URLs arbeiten. Das heißt, dass wir wirklich unter einer klaren URL genau wissen, das ist die URL für die Schweiz, das ist die URL für Deutschland. Das müsste man dann zum Beispiel pro Produkt haben. Das muss nicht mehr unterschiedlicher Fahrt sein, das kann auch mit einem Parameter gewechselt werden. Das heißt, dass ich zum Beispiel Land gleich Schweiz oder Land gleich Deutschland habe oben. Das ist euch überlassen über das Macht, aber wichtig ist, dass man wirklich diese unterschiedlichen URLs hat und dass man dann per der href-Lang Verbindung zwischen diesen Seiten genau angebt, dass es die deutsche Version dieser Seite und die dazu passende Schweizer Version ist die href-Lang ist an und für sich eine Verbindung zwischen dem gleichen Produkt oder dem gleichen Inhalt, einfach für verschiedene Länder oder für verschiedene Sprachen und dann aufgrund von diesem href-Lang Verbindung können wir theoretisch die richtige Version in den Suchergebnissen zeigen. Wichtig ist da einfach auch, dass es ist keine garantierte Indexierung dabei, es ist auch nicht garantiert, dass wir immer die richtige Version zeigen in den Suchergebnissen. Das heißt, man muss damit rechnen als Websitebetreiber, dass ab und zu ein Benutzer auf diese Seite kommt, der eigentlich nicht von diesem Land ist und dementsprechend muss man das irgendwie abfahren oder muss man natürlich nicht, aber ist optimal, wenn man das macht, dass man dazu ein Banner oben zeigt und sagt, hey, ich sehe, du kommst aus der Schweiz, hier ist die Schweizer Version, dann bist du momentan auf der deutschen Version. Und so kann man die Benutzer dann eher dazu weiterführen, auf die richtige Länderversion zu kommen. Was man hingegen nicht machen kann, ist die Versionen ganz unterdrücken, das heißt, wenn Benutzer aus der Schweiz kommen, dass man ihnen gar keine Möglichkeit gibt, die deutsche Version anzuschauen, das ist aus unserer Sicht mehrheitlich aus praktischen Gründen so, weil Googlebot kommt ja auch aus einer Region, kommt mehrheitlich aus Amerika und Googlebot muss ja die verschiedenen Versionen anschauen können. Und wenn ihr automatisch Benutzer immer weiterleitet auf die bestpassendste Version, dann findet Googlebot nie die anderen Länderversion. Das heißt, wir müssen diese einzelnen Versionen einzeln anschauen können, Benutzer sollten die auch einzeln anschauen können und man kann natürlich benutzen, ein bisschen dazu leiten, auf die besser passende Version zu gehen, aber man kann sie nicht ganz davor bewahren, dass sie dann vielleicht die deutschen Preise sehen und denken, das ist so viel Bildung in Deutschland, ich bestelle es mir so. Das sind an und für sich die Sachen, die man da machen kann. Was man natürlich auch machen kann, ist, wie man sagt, diese Verknüpfung mit hreflang ist mir zu kompliziert. Ich mache es einfach so, dass ich keine Preise auf den Seiten habe direkt, beziehungsweise dass ich per JavaScript, die dann einblende, je nachdem, wo der Benutzer herkommt, dann ist es so, dass wir einfach diese einzelne Seite indexieren können. Wir sehen allerdings unter Umständen keine Preise und können die dann auch nicht in den Rich Snips quasi darstellen. Vielleicht ist es okay, vielleicht ist es nicht unbedingt das, was ihr haben wollt, ein bisschen euch überlassen, wie weit man da gehen möchte. Ein Kunde nutzt für seine internationaler Brandseite momentan.ch, also.ch-de und.ch-uk. Trotz korrektem hreflang rankt bei der Brandsuche in der Schweiz die ch-uk Seite. Das Problem wird nun durch die Länderdomain vermutet. Hier lässt sich in Search Console ja auch kein Land einstellen, die dort kaum Adresse ist besetzt. Könnte man hier auf die Punkt Swiss Domain wechseln. Und ist diese Tableau der Domain aus Sicht von Google sinnvoll und lässt sich das für andere Länder verwenden. Der letzte Teil der Frage ist relativ einfach. Ja, was kann man machen? Die ganzen neuen Tableau Domains sind alle Länderunabhängig. Die könnt ihr beliebig mit Geotargeting verarbeiten, wie ihr sie haben wollt. Das heißt, ihr könntet auch eine Punkt Swiss Domain nehmen und die dann gezielt auf Benutzer in den UK ausrichten, wenn ihr das machen möchtet. Was man auch machen kann mit diesen generischen Tableau Domains, ist, dass man Unterverzeichnisse oder Subdomains nimmt und dass man die einzeln auf Länder zuordnet per Search Console. Dafür muss man einfach die entsprechenden Teile einzeln verifizieren in Search Console und dann kann man bei der Länder zuordnen das entsprechend einstellen. Bezüglich der der UK Seite, die in der Schweiz erscheint, ist ein bisschen schwierig zu sagen, ohne die Seite anzuschauen und zu sehen, was da genau gemacht wird. Grundsätzlich mit dem hreflang können wir die Verbindung da schon feststellen und sollten eigentlich die richtige Version auch zeigen können. Schwierig ist da vielleicht, dass ich nicht genau weiß, wie das eingestellt ist bei euch mit der Länder-Einstellung. Das heißt, habt ihr das pro Sprache gemacht oder pro Land. Wenn das pro Sprache ist, dann könnt ich mir vorstellen, dass es vielleicht ein bisschen schwierig ist für uns, wenn die Brand zum Beispiel irgendein englisches Wort ist. Dann sucht jemand nach einem englischen Wort. Wir finden eure Website und denken, ah, der Benutzer hat in Englisch gesucht, also bringen wir die englische Version dieser Website. Sind da alle möglichen Einzelheiten, die da irgendwie ein bisschen dazu kommen können? Und je nach dem kann man das lösen, indem man die hreflang links ein bisschen genauer angebt oder dass man die auch ein bisschen breiter angebt. Das heißt, dass man da zum Beispiel sagt die CH Version ist die Version für, sag mal, Deutsch für die Schweiz und Deutsch für England. Und die UK Version ist einfach die allgemeine englische Version, sodass wenn jemand auf Englisch sucht, egal in welchen Land das sich befindet, kommt auf die UK Version. Wichtig ist auch, dass man kontrolliert, dass die einzelnen URLs in diesem hreflang Set auch separat indexiert sind. Das kann man am einfachsten mit dem Inspect URL Tool machen in Search Console und da kann man dann feststellen, ob wirklich die einzelnen Seiten indexiert sind und als canonical erkannt sind. Wenn das der Fall ist, dann funktioniert auf jeden Fall der hreflang Link zwischen diesen Seiten. Wenn hingegen einzelne diese URLs in diesem Satz nicht indexiert sind, dann nicht das canonical erkannt werden, dann kann es sein, dass wir das einfach fallen lassen, diesen Link zu dieser nicht canonical Version, weil die Version ist ja dann nicht so indexiert und dementsprechend können wir die dann nicht als ein Teil vom hreflang Satz beibehalten. Dann eine Frage zu, okay, ich spring mal da nach unten, wo der erste Teil der Frage ist. Bei der Suche auf Google CH in Französisch für unsere Startseite werden aus Beschreibung und Titel eine Produktbeschreibung angegeben. Woran könnt es hier liegen, dass Google lieber diese eher unglückliche Beschreibung anzeigt und nicht unsere definierten Metadaten. Ich habe das, wir haben das vorher kurz besprochen und ich habe das auch mal ein bisschen hier nachverfolgt, was da passiert sein könnte und da scheint es irgendeine Komplifikation mit dem hreflang zu geben. Das heißt, wie ihr vielleicht bei den anderen Fragen gesehen habt, hreflang ist vielleicht einfach im Prinzip, aber in der Praxis gibt es da ein paar Typen, worauf man achten muss. Und was jetzt in diesem Fall passiert ist, dass wir für die Startseite erkannt haben, dass da hreflang Links zu dieser einzelnen Produktseite vorhanden sind. Und wie das genau gekommen ist, weiß ich jetzt nicht, kann ich jetzt nicht im Moment nachvollziehen, aber was wir da sehen, ist quasi diese Startseite ist indexiert. Wir sehen aber auch, dass die hreflang Links für die einzelnen Sprachen zu einer dieser Produktseiten weitergehen und dementsprechend, wenn man sucht, denkt man, ja gut, wir nehmen diese hreflang Version dazu und zeigen die Beschreibung an, weil das schient ja auch dann die passenden Version dazu. Und das ist wahrscheinlich das, was wir da irgendwie nicht machen sollten. Und wie das dazu kommen kann, dass wir denken, dass diese hreflang Links dazugehören, ist ein bisschen schwierig nachzuvollziehen, weil ich nicht genau weiß, was da genau passiert ist auf der Website. Im Moment ist es so, dass die Produktseiten, die da so verknüpft sind, die sind jetzt auch nicht mehr verfügbar. Also sollte sich das auf jeden Fall selber auch lösen. Aber es kann zum Beispiel sein, dass wir da in einem logischen Redirect erkannt haben zu diesen Produktseiten oder dass diese Produktseiten einen Velcanonical mal auf die Startseite gesetzt hatten, sodass wir denken, diese Seiten gehören alle zum gleichen Satz. Sind da verschiedene Sachen, die da ein bisschen zusammen kommen können. Ihr habt auch erwähnt, dass ihr das habt, seit ihr auf, ich weiß nicht, React gewechselt habt oder einen JavaScript-Framework unter Umständen, wenn ihr die hreflang oder die relcanonical Links per JavaScript setzt, dann kann es natürlich schon sein, dass da irgendwie noch zusätzliche Komplikationen dabei sind. Das heißt, wenn ich View Source mache, sehe ich vielleicht Einsatz hreflang. Wenn man per JavaScript das anschaut, sieht man vielleicht etwas anderes. Wenn irgendwas im JavaScript klemmt unterwegs, vielleicht ist er irgendwann in Zwischenstadium, der übrig bleibt, der das Ganze noch komplizierter macht. Auf jeden Fall wird das nicht ganz einfach sein, denke ich. Aber ich würde auf jeden Fall da mal weiter suchen mit den hreflang Links und schauen, wie die gesetzt werden, ob das sein kann, dass da irgendwie so eine Kreuzverbindung vielleicht mal da war. Wir haben doch mal geschaut und es sieht so weit recht gut aus, was uns auch noch aufgefallen ist. In der Search Console zeigt es auch doppelte Titles und doppelte Descriptions an und da ganz vielen URLs. Das scheint es vielleicht irgendwie auch so ein ähnliches gleiches Problem zu sein. Aber jetzt mit hreflang, wenn da zum Beispiel in einem Tag das L groß ist, dann könnte es ja nicht liegen. So Key Sensitivity sollte kein Problem sein, oder? Nein, das macht nichts. Okay, dann mit. Und habt ihr die Seite, Entschuldigung, habt ihr die Seite per JavaScript Rendering gemacht, also Kleinzeit Rendering oder ist das Server-Site Rendering für euch? Meines Wissens ist das Server-Site Rendering. Okay. Dann müsste man das ja auch mit View Source und so entsprechend auch anschauen können, kontrollieren können. Ja, genau. Und dort schaut eigentlich alles super aus. Also wenn jetzt nicht irgendwie irgendwelche Attribute da auftauchen, die irgendwelche Fehler verursachen oder eben im JavaScript selbst, da sind wir da nicht so gut. Okay, dann schaue ich das mal mit Martyn an. Martyn macht ja die ganzen JavaScript-Sachen inzwischen. Gehen wir Ihnen mal ein Rätsel zu lösen. Okay, dann war noch ein zweiter Teil zur Frage. Hat Google ein Problem, wenn Datenattribute wie Data React Helmet oder Data RH in Mattertags wendet werden? Nein, das stört uns überhaupt nicht. Wenn da weitere Attribute dabei sind, die wir nicht brauchen, dann ignorieren wir die. Das ist ja eigentlich bei HTML so eigentlich so gültig. Normalerweise, dass man da die Attribute einfach rausnimmt, die man braucht und die anderen kann man einfach sagen lassen. Können Verlinkungen, die einer Domain zugehörig sind, wie bei einer Verzeichnisseite, sofern die Links einer Regelfolgen zu einem besseren Ranking führen? Verstehe nicht genau, wie das gemeint ist. Ich weiß nicht, ob du hier bist, Hangout. Weiß nicht genau, wie das gemeint ist, Andy. Wenn du willst, vielleicht einfach beim nächsten Hangout ein bisschen genauer Frage reinnehmen, dann kann ich das ein bisschen besser hier anschauen. Okay, dann haben wir noch eine rätselhafte Antrage von About You. Seit Anfang Februar verlieren unsere Produkte SiteMaps laut der alten Search Console starken Index-Abdeckung. In neuen Search Console zeigt, dass die gesendeten URLs in der SiteMap als no index markiert wurden. Daraufhin haben die SiteMaps kontrolliert und lediglich 1% der URLs gefunden, welche auf no index standen. Bei Validierung einzelner URLs in Search Console werden die als indexierbar erkannt. Eine großflächige Validierung haben wir versucht, aber sie schlug bei der Mehrzahl der Seiten fehlt. Ja, ich habe das ja auch angeschaut und auch gesehen, dass da vom Domain her, dass relativ viele Seiten als no index erkannt werden. Was ich gesehen habe bei euch ist, dass sie auch per JavaScript irgendwas macht mit diesen Seiten und ich weiß nicht, ob das vielleicht noch einen Zusammenhang hat mit diesen no index, weil soweit ich gesehen habe, habt ihr auch per JSON-LD die Robotsmetateige-Information dabei und das scheint per JavaScript noch gesetzt zu werden und da weiß ich jetzt nicht genau, wie das bei euch als Segel quasi eingebaut ist, ob da wenn zum Beispiel bei der Verarbeitung vom JavaScript irgendetwas schief geht, wenn zum Beispiel Produktbilder nicht geladen werden können oder so etwas, ob ihr dann annimmt, dass das Produkt nicht mehr verfügbar ist und dass ihr dann no index setzt oder wie das genau gehandhabt wird, weil was natürlich passieren kann bei Seiten, die JavaScript brauchen für Klein-Site-Rendering, ist, dass unter Umständen können nicht alle JavaScript-Dateien geladen werden. Wenn diese Seite gerendet werden muss unter Umständen können nicht alle Server-Antworten direkt haben für die Rendering und wenn das JavaScript dann nicht ein bisschen robust ist gegenüber solchen Ausfällen, dann indexieren wir unter Umständen wie den Fehlerzustand und je nachdem wie ihr das Hand habt, kann es natürlich sein, dass der Fehlerzustand mit no index versehen ist und dann fahren diese Seiten aus dem Index heraus. Hingegen, wenn ihr dafür sorgt, dass bei einer fehlerhaften Ladung der Seite, dass das trotzdem indexierbar bleibt, dann können wir im nächsten Moment das nochmal probieren mit dem Rendering und dann können wir oft die Inhalte trotzdem normal renderen. Das heißt, meine Vermutung ist, dass da per JavaScript irgendetwas nicht ganz robust gehandhabt wird und wenn der einzelne Teile vielleicht nicht verfügbar sind, dass es dann relativ schnell auf ein no index Zustand wechselt. Ich weiß nicht, ob das bei euch effektiv so der Fall ist oder ob das nur etwas ist, was ich da so grob geschätzt so finde. Was ich natürlich auch machen kann, ist das Ganze mit dem Team vom Rendering nochmal anschauen und überlegen, ob man da ein bisschen genauer Informationen angeben könnte, wo dieser no index gefunden worden ist oder wie der dazu gekommen ist. Das heißt, gerade wenn das bei JavaScript dazu gekommen ist, dass man da vielleicht sagt, der no index kommt von dieser JavaScript-Datei oder so etwas Ähnliches. Ja, bin heute auch hier. Okay, natürlich. Tatsächlich weiß ich nicht genau, wie es im Fehlerfall gehandhabt würde vom JavaScript, aber wir werden in die Richtung forschen auf jeden Fall. Danke für den Hinweis. Zu Fehlern, die auf Seiten, die sozusagen nicht indexiert sind in der neuen Search-Konsole, da gibt es diesen Knopf ansehendes Quellkotst nicht. Also das, was früher mal Fetch and Render war, was jetzt in der neuen Search-Konsole das Frischholen ist, was auf der rechten Seite dann so reinschwebt. Das geht nur bei indexierten Seiten. Wäre toll, wenn das auch für die Seiten, die ihr aus irgendeinem Grund nicht indexiert habt, aber da auflistet, wenn man das bei denen auch sehen könnte, weil da würde man ja sehen, sozusagen, welches Problem ihr in dem Augenblick gesehen habt. Okay, ich schreibe schon mal kurz auf, dann vergesse ich es nicht. Jetzt komme ich das mit dem Klima an. Ja, ich denke, es wird wahrscheinlich schwierig sein, weil wenn die Seiten aus uns bei unserer Seite aus dem Index fallen, dann heben wir die Informationen nicht auf. Das heißt, wenn wir sehen, dass die Seite zum Beispiel 4.04 zurückgegeben hat, dann heben wir den Inhalt der 4.04-Seite nicht auf. Ähnlich wird das sein mit dem No-Index. Wenn wir dann No-Index gesehen haben und die Seite fällt dann bei uns aus dem Index heraus, dann wissen wir eigentlich nur, diese Seite ist im Moment aus No-Index, die wird nicht ausgeliefert und haben eigentlich den Inhalt der Seite dann nicht mehr indexiert. Aber vielleicht lässt sich da irgendwas trotzdem machen, dass man da, sagen wir mal, den letzt vorhandenen Inhalt zumindest irgendwie darstellen kann. Okay, mal schauen. Aber ich denke, das würde es auch für mich ein bisschen einfacher machen, gerade in eurem Fall mit dem No-Index, auch im anderen Fall mit dem A-Trip-Lang wäre das da ein bisschen praktischer. Okay, gut. Probieren wir uns mal weiter. Folgendes Szenario. Es existiert eine normale und eine Endpunktdomain, die Entscheidung, welche Domain der Server ausliefert. Hört ihr dieses Echo auch? Nein, hier eigentlich nicht. Nein. Ich, okay. Vielleicht ist das nur auf meiner Seite komisch. Okay, dann mache ich mal so weiter. Also es existiert eine normale und eine Endpunktdomain, die Entscheidung, welche Domain der Server ausliefert, basierter auf dem Endgerät des Anfragenden. In den Suchergebnissen wird bei einer Brandsuchernfrage auf Platz 1 die Endpunktdomain und auf Platz 2 die normale Domain angezeigt. Unabhängig, ob ich auf dem Desktop oder auf ein Mobile Device suche. Mein Wunsch wäre, dass die Endpunktdomain nur bei Suchernfragen auf dem Mobile Device angezeigt wird. Kann man das beeinflussen? Okay, okay. Was da wahrscheinlich passiert, ist, dass wir die Verknüpfung zwischen dem Endpunktdomain und der normalen Webdomain nicht sauber erkennen können. Und dementsprechend ist es so, dass wir da irgendwie beide Versionen indexiert haben. Wichtig ist, wenn man jetzt mit separaten Endpunktdomains arbeitet, dass man da wirklich dafür sorgt, dass die Endpunktdomain den Rail Canonical zur Desktop-Version hat und dass die Desktop-Version entsprechend mit Link Rail Alternate zum Mobile Version zurückverfügt zeigt, so dass wir wirklich eindeutig die Verknüpfung zwischen diesen beiden Seiten erkennen können. Und wenn wir das sauber erkennen können, dann sollte das auf jeden Fall soweit klappen. Dann sollten wir eigentlich wissen, dass da bei für Mobile Benutzer die Mobile Version gezeigt werden kann und für Desktop Benutzer wird die Desktop-Version gezeigt. Was man auch machen kann, ist natürlich eine automatische Weiterleitung einrichten. Das heißt, wenn ein Desktop-Benutzer auf die mobile Version geht, dass da dann automatisch weitergeleitet wird auf die Desktop-Version und entsprechend umgekehrt auch, wenn ein Mobile-Benutzer auf die Desktop-Version geht, dass da auch weitergeleitet wird. Und dadurch kann man ein bisschen dafür sorgen, dass egal, welches dieser URL ein Benutzer findet, das kann ja über die Suche sein oder es kann auch sonst sein, dass da trotzdem der Benutzer auf der richtigen Version dieser Seite landet. Einfacher ist es natürlich auch mit Responsive Design, da ist dann nur eine URL für diese beiden Varianten vorhanden. Meine Frage bezieht sich auf Canonicals und Produktvarianten. Wenn ein Canonical angenommen wird und das Suche an der Produktvariante in der Canonical-Seite vorkommt, kann es passieren, dass die Qualität der Nicht-Kanonical-Seite verloren geht. Verstehe ich nicht genau, wie das gemeint ist. Grundsätzlich ist es so, dass wenn man mit dem Canonical eine Seite angebt und wir folgen dieser Canonical, dann wird es so sein, dass wir nur die Canonical-Version indexieren. Das heißt, wir sehen im Index dann gar nicht mehr die Information von einer Nicht-Kanonical-Variante. Das heißt, wenn ich jetzt zum Beispiel verschiedene Produkte habe in verschiedenen Farben und ich sage als Canonical ist die Version in blau, dann wissen wir gar nicht, dass es noch eine Seite vielleicht für das Produkt in grün gibt, weil da ist der Canonical zur blauen Version. Das heißt, wenn ich dann nach grünem Produkt suche, dann wird das gar nicht groß in den Suchergebnissen erscheinen. Es ist möglich, dass es trotzdem erscheint wegen irgendwelchen zusätzlichen Signalen, die wir haben, aber auf jeden Fall nicht aufgrund von den Inhaltssignalen, die wir haben für diese Seite. Weil die Seite, die wir indexiert haben, ist dann wirklich nur die blaue Version. Die grüne Version, die den Canonical auf die blaue Version hat, die ist an und für sich dann aus unserer Sicht nicht vorhanden im Index. Das heißt, was man machen könnte in einem solchen Fall ist, dass man als Canonical eine allgemeine Version nimmt, wo die verschiedenen Produktvarianten auch aufgelistet sind. Das heißt, ich habe dann vielleicht statt der blauen Variante als Canonical habe ich einfach nur dieses Produkt, das Canonical, und auf der Produktseite steht dann, dieses Produkt ist verfügbar in blau, grün, rot, gelb und so weiter. Und dann, wenn jemand nach der Farbe und den Produkt sucht, dann ist das natürlich eine gut passende Seite. Und von dort aus kann der Benutzer dann weitergehen zur entsprechenden Landingpage für die gelbe Variante oder die grüne Variante, je nachdem, wie der Benutzer da weitergehen will. Kann man die Qualität durch die interne Linkstruktur beeinflussen? Alle Produktvarianten bleiben indexiert, anstatt zu kanonisieren. Aber die Seite mit der Produktvariantenübersicht steht mehr krawtive über den Produktvarianten. Oder es ist egal, wo sich die duplikate Struktur befinden. Das hat eigentlich weniger, also sagen wir mal, die krawl tiefer oder wie das aufgefunden wird, hat weniger mit der Qualität der Seite zu tun oder wie wir die Qualität bestimmen würden, sondern es bestimmt einerseits die die Relevanz innerhalb der Website und dadurch dann auch ein bisschen die Krawl-Geschwindigkeit. Das heißt, wenn wir sehen, dass etwas sehr relevant verlinkt ist innerhalb der Website, denkt mir, dass das eher vielleicht wichtiger ist und würden wir eher dann auch dahin gehen und diese Seiten versuchen, ein bisschen häufiger zu crawlen. Wie das mit dem Canonicle dann da von dort aus weitergegeben wird, ist allen für sich total separat. Wenn wir eine nicht Canonicle Seite häufig crawlen, dann sehen wir einfach den Link zur Canonicle ein bisschen häufiger und dementsprechend crawlen wir dann auch die Canonicle Version ein bisschen häufiger. Aber wie sich das verteilt innerhalb der Website allen für sich euch überlassen und hat auch keinen Einfluss auf die Qualität oder das Qualitätsempfinden von unseren Algorithmen für diese einzelnen Seiten. Was ich einfach anraten würde, ist, dass man sich überlegt, welche Seiten sind für euch am wichtigsten innerhalb der Website und dann dafür sorgen, dass die wirklich auch prominent verlinkt sind innerhalb der Website, sodass wir sie gut von überall finden können und dementsprechend versuchen wir die dann auch häufiger zu crawlen und versuchen wir die dann auch ein bisschen prominenter in den Suchergebnissen zu bringen, weil wir denken, die sind jetzt wirklich relevant für eure Website. So, mal schauen, was noch alles dazu gekommen ist. 2018 haben Websites, die dem ETH nicht genug entsprachen auf deutlicher Einbußen in der Sichtbarkeit erlitten, was offenbar algorithmisch erfolgte, weil es zu bestimmten Zeitpunkten geschah, am Anfang im März, kann der Algorithmus demzufolge dann auch Verbesserungen verstellen, sobald diese erfolgen. Ja, auf jeden Fall. Ah, ich nehme an, dass sie ist das EAT, was war das? Expertise, Authority, Trust, irgend so etwas. Ja, an und für sich, wenn wir sehen, dass eine Website besser ist, dann versuchen wir das auch automatisch ein bisschen sichtbarer zu bringen in den Suchergebnissen. Ich, Entschuldigung, weiß nicht genau, welche Änderungen da jetzt mit deinen Webseiten da verbunden sind, aber grundsätzlich ist es schon so, dass wenn unsere Systeme automatisch arbeiten, das tun sie eigentlich in den meisten Fällen, dann nehmen sie dann Veränderungen, die auch positiv sind, relativ schnell wieder auf. Und da habe ich auch einige Case Studies noch gesehen zwischen euch, wo wir gesehen haben, dass Websites, die wirklich auch daran gearbeitet haben, sich grundsätzlich zu verbessern, dass die entsprechend dann auch im Laufe der Zeit wieder besser sichtbar waren in den Suchergebnissen. Okay, ich glaube, das war jetzt alles, oder? Sind da Weitauffragen noch dazugekommen? Ja, gibt es aus eurer Sicht noch irgendetwas, womit ich helfen kann? John, wenn ich dich letzte Woche im deutschen Hangout richtig verstanden habe, da hast du auch was über Haare Flangen und wie es in der Search-Konrolle angezeigt wird, gesagt und vielleicht habe ich dich falsch verstanden, weil es wäre schon eine große Nummer, dass von einem Haare Flangen-Set nur eine Variante als indexiert angezeigt wird und die anderen sozusagen parallel laufen und dass sie sich im Hintergrund immer austauscht, aber es in der Search-Konsole sozusagen kein allabdeckendes Bild mehr gibt, vor allem wenn man über mehrere Domains verteilt ist. Bisschen schwierig zu erkennen, weil ich habe irgendwie den ganzen Ton im Moment auch Zeit versetzt nochmal bei mir im Kopf her. Ich weiß nicht, wie das kommt. Was da passiert mit dem Haare Flangen im neuen Search-Konsole, ist, dass wir besuchen, das ganze Jahr auf die Canonical URLs zurückzuführen und wenn man per Haare Flangen Versionen angegeben hat, die an und für sich gleich sind, die wir als ein Canonical quasi führen können, dann zeigen wir nur diese einzelnen URLs in Search-Konsole an und in einem solchen Fall kann das natürlich ein bisschen kompliziert aussehen, weil dann wissen wir zwar, dass die deutsche und die österreichische Versionen, sag ich mal, per Haare Flangen verbunden sind, aber wir nehmen jetzt die deutsche Version aus Canonical an und dementsprechend zeig mir dann nur die deutsche Version in, ich glaube, in Search Performance Report in Search Console. Was man da machen kann, ist einerseits über die Länderzuordnung, kann man das ja den Filter nach Land, kann man das ein bisschen genauer anschauen in Search Console, oder dass man sich halt überlegt, wie kommt es, dass Google denkt, dass diese Versionen gleich sind, was kann ich machen, um diese Version wirklich unterschiedlich zu machen, sodass sie nicht zusammengeklappt. Das manchmal einfacher gesagt als getan, aber das ist wahrscheinlich das Beste, was man da machen kann, dass man da wirklich die Sachen auch separat aufführen kann. Aber ich wäre froh, wenn ihr mir solche Beispiele mal zuschicken könnt, dann kann ich die nämlich auch wirklich mit dem Team anschauen. Die Party, die ich mit dem Team hier schon mal angeschaut habe, diesbezüglich, sehen sie zwar schon auch, dass es problematisch ist, dass es nicht so toll aussieht oder so hilfreich aussieht in Search Console, aber sie haben irgendwie nicht genug Beispiele, um zu sehen, dass es wirklich ein grundsätzliches Problem ist oder ob das nur mit einzelnen Websites da vielleicht nicht so optimal funktioniert. Das heißt, wenn ihr solche Beispiele habt, wo in neuen Search Console, in der Ansicht mit dem Canonical URLs, wirklich die Länder-Version zusammengeklappt werden und das für euch Search Console sehr schwierig macht zu benutzen, wäre ich froh, wenn ihr mir die Varianten zuschicken könnt. Okay, machen wir natürlich gerne. Und noch eine Frage zur Canonisierung und neue Search Console. Ich sehe da in den Fehlerreports zur Abdeckung häufiger, dass URLs per RobotsTech blockiert sind. Aber die URL, die da aufgelistet ist, ist nicht blockiert. Ich vermute mal, da seid ihr über einen Redirect gelaufen und habt den damit reingeklappt und zeigt vielleicht sozusagen die Fehlermeldung für eine URL an, die damit zusammenhängt, aber es ist nicht ideal anzeigt. Könntest du mir da vielleicht ein paar Beispiele zuschicken? Natürlich. Dann kann ich das auch mal anschauen. Weil unter Umständen kann das schon sein, dass wir da mit dem Canonical das ausgeführt haben und dass da die falsche URL quasi dargestellt wird, obwohl wir das per RobotsText quasi blockiert haben. Das ist echt alles voll nervig. Machen wir es vielleicht so. Ich schalte mal kurz den Hangout aus und mache ihn nochmal auf. Und wenn ihr noch weitere Fragen kommt, dann können wir die nochmal kurz anschauen. Okay, bis gleich.