 Okay, herzlich willkommen beim heutigen Google 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 SEOs Publisher dazukommen können und ihre Fragen bezüglich der Websuche stellen können. Sind relativ viele Fragen schon eingereicht worden, wenn einer von euch möchte, könnt ihr auch gerne schon mal loslegen, eure Fragen direkt stellen. Okay, wenn nicht, dann fangen wir einfach mal an. Wenn ihr zwischen euch Kommentare habt oder weitere Fragen, einfach nur loslegen. Okay, also die erste Frage bezieht sich auf eine Website. Ich habe vor einigen Monaten meine Seite für Lernzettel erstellt. Nur zu die Search Console und Google Analytics. Allerdings werden die Unterseiten weder geindexed noch gekrawlt. Obwohl sie sich an Google gesendeten Sidemap befinden, alle Live- und Speedtest ohne Probleme ablaufen, Meta-Informationen vorhanden sind, auch ein Canonical Link angegeben wird. Was kann man da machen? Ich habe das ganz kurz angeschaut und zwar am einfachsten geht das, wenn man die Sidemap-Datei da anschaut. Und was ich gesehen habe, ist, dass die URLs alle mit diesen Fundzeichen dazwischen arbeiten. Das heißt, wahrscheinlich ist das eine JavaScript-Seit, die per JavaScript erstellt wird und mit diesen Fundzeichen, diesen Nommanzeichen dazwischen werden die unterschiedlichen Seiten abgerufen. Allerdings ist es so, dass wir solche URLs nicht separat indexieren oder zumindest meistens nicht separat indexieren und auch nicht separat crawlen können. Das heißt, was man da machen müsste, ist eine leicht andere URL-Struktur verwenden. Es gibt zwei Varianten, was man da machen könnte. Einerseits könnte man mit dem sogenannten Hashbang-System arbeiten, also dieses Nommanzeichen und den Ausrufezeichen dazu. Das würden wir so an und für sich indexieren. Ist ein bisschen suboptimal, weil wir eigentlich mit diesem System aufgehört haben zu arbeiten, aber es funktioniert weiterhin und das wäre wahrscheinlich eine relativ einfache Anpassung für die Website, zumindest für den Moment. Das andere ist, dass man mit einer normalen Pfad- und URL-Struktur arbeitet, also nicht mit diesen Nommanzeichen, sondern dass man direkt einfach den Pfad dann angibt und dann zum Beispiel per JavaScript über die History API kann man immer noch hin und zurück wechseln und andere Seiten ansteuern, solche Sachen. Meistens ist es so, dass bei den üblichen JavaScript-Frameworks, die verwendet werden für so eine Website, dass man da einfach umstellen kann zwischen diesen beiden URL-Strukturen, und dass man da relativ einfach von einem System zum anderen wechseln kann, sofern das Server das irgendwie auch unterstützt. Und wenn das so fall ist, würde ich das auf jeden Fall machen. Weil es so wie das im Moment eingerichtet ist, ist es so, dass wir diese URLs zwar finden, wir denken allerdings, dass wir nur den vorderen Teil crawlen und indexieren müssen, weil der zweite Teil sieht aus wie ein Anchor für einen Teil dieser Seite. Und dementsprechend wird das da ignoriert. Ich vermute, dass in Search Console auch nicht groß Fehler angezeigt werden, weil aus unserer Sicht kann man solche Anchor-Uralls auch verwenden. Wir indexieren einfach den vorderen Teil und das ist aus unserer Sicht eigentlich kein Fehler. Wir merken einfach nicht, dass du was anderes damit meinst. Von dem her würde ich da vielleicht im ersten Moment in der JavaScript-Framework mal nachschauen, ob man das umstellen kann. Wenn das von jemand anderem entwickelt wurde, dann würde ich das mit denen vielleicht auch anschauen und schauen, wie man das umstellen kann auf eine andere URL-Struktur, sodass idealerweise einfach ein normaler Pfad unter Teilnamen und so verwendet wird. Wir betreiben einen großen Online-Shop im Fashion-Bereich. Mit diesem sind wir international tätig und verwenden jeweils eigenständige Domains pro Land. Unsere SideMaps sind sehr umfangreich. Was hat wir ein SideMap-Index verwenden mit mehreren darunter liegenden SideMaps? Wenn ich in Search Console für DE die Übersicht zu den SideMaps-Aufrufe bekomme, dann bekomme ich eine sehr umfangreiche Auflistung zum Indexierungstatus, sowie ein Link zum Index Coverage jeweils pro SideMap, was für uns sehr hilfreich ist. Wir bekommen diese Auflistung für andere Domains nicht angezeigt, obwohl diese auch schon seit langer Zeit aktiv sind und die SideMap-Struktur gleich ist. Zudem wird uns beispielsweise für RT als Status Success angezeigt, wenn die Coverage-Urails gleich null ist. Okay, ich denke, da gibt es zwei Sachen, die wahrscheinlich da eine Rolle spielen. Einerseits ist der Indexierungstatus nicht mehr weitergeführt in Search Console. Das heißt, die Zahlen, die man da sieht, entsprechen einfach den Zustand von früher. Soweit ich weiß, haben wir das auch in der UI in Search Console ganz entfernt und es eigentlich nur noch in der API vorhanden. Das heißt, diese Daten sind zumindest für den Moment nicht aufrufbar. Das andere ist, was gerade bei internationalen Websites oft vorkommt. Ich habe jetzt nicht kontrolliert, ob das effektiv der Fall hier ist, aber was oft auftritt, ist das gerade im Bereich Deutschland, Österreich und Schweiz, dass man da die gleichen Inhalte verwendet. Obwohl das für unterschiedliche Länder sind und was bei uns dann passiert intern, ist, dass wir sehen, dass die Inhalte gleich sind und wir indexieren dann auch nur eine Version davon. Mit hreflang, das ist quasi eine Verbindung zwischen verschiedenen Länder- und Sprachversionen, kann man angeben, welche URL für welche Länder entsprechend gebraucht werden soll. Wir können diese URLs auch austauschen in den Suchergebnissen, sodass die richtige URL dargestellt wird. Aber wir indexieren jeweils nur eine Variante. Das heißt, was man in Search Console dann schlussendlich sieht, ist, dass die Indexierung dann bei einer Variante hauptsächlich vorhanden ist und dass bei den anderen Varianten, die wir quasi als Duplikat anschauen, da wird bei der Indexierung, das heißt im Index Coverage Report, wird entsprechend nichts dargestellt oder halt relativ wenig im Vergleich zur Vollendiste. Das heißt, aus unserer Sicht ist das eigentlich nicht wirklich problematisch in dem Sinne, weil wir tauschen ja die URLs trotzdem aus gegen die richtigen In-In-Suchergebnissen. Es ist einfach für die Verwaltung der Statistiken in Search Console, es ist da ein bisschen kompliziert. Und da muss man, wenn man diese Statistiken anschaut, muss man da anwesig schon daran denken, dass gerade mit den Länderversion eine Variante indexiert wird. Und das ist normal, dass vielleicht die österreichische Variante dieser einen Seite nicht das Indexiert angeschaut wird. Es kann variieren über die ganze Website. Das heißt, einzelne Seiten sind dann vielleicht indexiert, gleich mal für DE, andere Seiten sind indexiert für ART. Es ist nicht so, dass der ganze Domain dann als eine Variante indexiert wird. Das heißt, wenn man den Indexierungstatus anschauen möchte über Search Console, müsste man den Indexierungstatus der einzelnen Sprach- und Länderversion zusammenzählen und das so gesamthaft anschauen. Mit unterschiedlichen Domains ist das ein bisschen, bedingt das ein bisschen Handarbeit. Mit einem Domain, wenn man mit zum Beispiel ein .com-Domain arbeitet und Unterverzeichnisse verwendet oder Subdomains verwendet, dann kann man mit der Domain-Property in Search Console arbeiten. Dann sieht man da an für sich das volle Bild automatisch. Ich weiß nicht, wie das längerfristig sich da verändern wird. Ich finde es ein bisschen suboptimal, wie das im Moment gelöst ist, aber das ist im Moment vom Team her gesehen nicht eine Hauptpriorität. Ich vermute, dass wir da irgendwann im Laufe vom Jahr das Ganze mal neu überdenken und mal schauen, wie man das besser handhaben kann, gerade für Websites, die in einer Sprache für verschiedene Länder tätig sind. Wir haben eine Website, die sowohl für Desktop als auch für Mobile existiert. Über eine PHP Weiche werden Nutzer automatisch auf die jeweiligen relevanten Adresse umgeleitet. Nach den anfänglichen technischen Schwierigkeiten mit Canonical und hreflang ausgemetzt worden, taucht inzwischen nur noch die mobile Adresse in die Suche auf. Auch im Cache wird die m-Punkt-Variante der Seite als www ausgegeben. Andere Seiten mit www und m-Punkt-Adresse scheinen diese Probleme nicht zu haben. Ist das eine Auswirkung von Mobile First oder kommt der Googlebot mit unserer Weichen nicht ganz klar? Gute Frage. Ich höre ab und zu von solchen Schwierigkeiten. Es ist so, dass gerade mit Mobile First indexing crawlen und indexieren wir ja hauptsächlich mit dem mobile Googlebot. Das heißt, wir würden in einem solchen Fall sowieso nur die m-Punkt-Variante indexieren. Das heißt, wir kennen dann immer noch den Unterschied zwischen www und m-Punkt und können unter Umständen die richtige URL in den Suchergebnissen zeigen. Aber indexiert wird nur die m-Punkt-Variante. Auch wenn man über die Desktop-Suche geht, sieht man indexiert mit dem Titel und der Beschreibung sieht man nur die m-Punkt-Variante. Das ist an und für sich so per Definition für Mobile First indexing. Was häufiger deswegen auch passiert, ist, dass wir die m-Punkt-Variante in den Desktop-Suchergebnissen zeigen. Das ist oft das Einfall, einfach, dass wir vom Crawling her nicht ganz sicher sind, welche Variante wie verbunden ist. Und dann zeigen wir halt die m-Punkt-Variante an, weil wir das gesehen haben beim Crawling und indexieren. Praktisch gesehen, als Webmaster, was man da machen kann, ist einerseits sicherstellen, dass die Verknüpfung zwischen m-Punkt und www wirklich sauber vorhanden ist. Das heißt, dass man mit dem Rail Canonical arbeitet, dass man mit dem Rail Alternate arbeitet und wirklich diese Verknüpfung zwischen diesen beiden Varianten sauber. Einrichtet. Wichtig ist auch, dass, also nicht kritisch, aber ich denke, es hilft, ist auch, dass man da von der m-Punkt-Variante ein Redirect zur Desktop-Variante für Desktop Benutzer einrichtet. Das heißt, wenn Desktop Googlebot kommt und die m-Punkt-Variante anschaut, dann wird Desktop Googlebot weitergeleitet auf die Desktop-Version. Und ebenso, wenn wir die m-Punkt-Variante in den Suchergebnissen zeigen würden für Desktop-Benutzer, dass der Benutzer, wenn diese URL angesteuert wird, automatisch auf die richtige Variante weitergeleitet wird. Und mit diesen beiden Sachen, dass wirklich die Verknüpfung sauber ist und dass ein Redirect da vorhanden ist, kann man das an für sich so machen, dass es mehr oder weniger egal ist, ob die m-Punkt-Variante in den Suchergebnissen erscheint, weil der Benutzer ja dann trotzdem zur richtigen Variante zurückfinden kann. Ich denke, das sind so die Hauptpunkte da. Wir haben ja auch, ich weiß nicht, vor vielleicht einem Jahr oder so angefangen, die Einrichtung mit einer separaten Mobile-Version ein bisschen weniger zu empfehlen. Und wir unterstützen sie weiterhin in den Suchergebnissen. Das heißt, wir verstehen weiterhin diese Art von Verknüpfung. Aber ich denke gerade, wenn man ein neuerer Website einrichten möchte, würde ich darauf achten, dass man entweder mit Responsive Design oder mit Dynamic Serving arbeitet. Das heißt, statt die URL zu verändern, wenn jemand mit einem anderen Gerät zum Beispiel kommt, verwendet man die gleiche URL und zeigt dann entsprechend einfach die angepasste Inhalte unter dieser URL dann an. Und wenn man das macht, dann hat man diese ganzen Probleme auch weniger. Dann hat man auch weniger das Problem, wie richtet man mit die HF-Lang-Verknüpfung ein. All diese anderen Verknüpfungen zwischen den Seiten, wie man das am besten macht, da muss man sich mit dem gar nicht groß beschäftigen. Dann funktioniert das eigentlich automatisch. Das heißt, konkret in deinem Fall würde ich schauen, dass die Verknüpfung zwischen den beiden Seiten erstmal korrekt ist, ein Redirect von der Mobile zur Desktop-Version einrichtet für Desktop-Benutzer. Und dass du einfach im Hinterkopf behältst, falls du mal eine größere Anpassung machst auf der Website, dass man da überlegt, wie man auf eine saubere, eine URL pro Inhalt Website wechseln könnte. Mich würde interessieren, ob und wann, wenn ja unter welchen Bedingungen, Symbole wie Sterne oder ein Herz oder so ein Checkmark in den Suchergebnissen angezeigt werden. Ich möchte gerne das Herz im Titeltag einer Seite verwenden, die das Wort Love im Titel hat. Grundsätzlich ist es so, dass wir versuchen, solche Zeichen dann zu zeigen in den Suchergebnissen, wenn wir denken, dass sie relevant sind. Manchmal ist es so, dass Symbole wie Sterne eher verwährend verwendet werden, indem man so eine Art Review-Snippet quasi vortäuscht im Titel oder in der Beschreibung. Das sind dann Sachen, die wir versuchen, einfach auszublenden. Es ist nicht so, dass wir die Website deswegen als minderwertig anschauen würden oder weniger gut in den Suchergebnissen platzieren würden. Wir versuchen dann einfach die Titels und die Beschreibung ein bisschen aufzuräumen, sodass das nicht allzu verwährend aussieht. Das heißt, aus meiner Sicht, was ich da vielleicht machen würde, ist es einfach mal ausprobieren. Du kannst ja relativ schnell die Titletags anpassen. Es geht eine gewisse Zeit, bis das auch wirklich sichtbar wäre in den Suchergebnissen. Und dann siehst du ja relativ schnell, klappt das, klappt das nicht, macht das überhaupt Sinn für euch oder macht das weniger Sinn. Manchmal sieht das ja auch sehr asphamik aus, wenn man da alle möglichen Sonderzeichen dabei hat. Dann bringt das nicht wirklich so ein Image von einer seriösen Website hinüber, aber ich denke, das kann man mal ausprobieren. Jetzt seht ihr dann relativ schnell, ob das klappt, ob das mit den Benutzern Anklang findet oder nicht. Ja, von dem würde ich es einfach mal ausprobieren. Ich arbeite für eine Online-Learn-Plattform im deutschsprachigen Raum. Das heißt, wir haben teilweise gleiche Inhalte, aber auf separaten Domains für das jeweilige Land, über ART und vom COM. Seit, eine Kalenderwoche, wurde eine große Anzahl unserer CH-Domain laut Search Console vom Index ausgeschlossen, weil stattdessen die COM-Jurale aus kanonischer Jurale ausgewählt wurde. Hreflang haben korrekt implementiert und auch keine Veränderung vorgenommen in den letzten Tagen. Da mehr 6.000 Seiten betroffen sind, wirkt sich das deutlich auf unsere Rankings und unsere Sichtbarkeit aus. Was können wir tun, um den Fehler zu beheben? Ich denke, das geht zurück auf ein ähnliches Problem wie mit der anderen Website, dass wenn wir sehen, dass die Inhalte effektiv gleich sind, dann indexieren wir eines dieser Varianten und sehen die anderen dann als Duplicat an. Wenn eine saubere Hreflang-Implementierung vorhanden ist, zeigen wir trotzdem die richtige Jurale an und dann ranken wir die Inhalte an und für sich auch gleich. Das sollte eigentlich keine Veränderung vom Ranking haben, aber es betrifft dann effektiv in Search Console, wenn ich bei Index Coverage hineingehe, sieht man da effektiv diesen Unterschied. Und das sind Sachen, die können sich im Laufe der Zeit verändern. Das heißt, es kann sein, dass wir im ersten Moment beide Varianten sauber indexieren, dann später merken wir, die sind eigentlich doch die gleichen, die wir für ein Canonical URL aus, für dieses Inhaltsstück. Es kann sein, dass im Laufe der Zeit, dass wir sagen, eigentlich ist die andere URL besser geeignet als Canonical, dann wechseln wir auf die andere. Das heißt, in Search Console, wenn ihr unterschiedliche Domains habt, müsst ihr für Index Coverage all die Domains zusammenzählen und das Gesamtbild anschauen. Wenn man mit einem Domain arbeitet und zum Beispiel mit Unterverzeichnissen oder Subdomains arbeitet, dann kann man mit der Domain Property in Search Console das Gesamtbild sehen, aber wenn das separate Domain sind, dann kann man das leider nicht zusammengefasst anschauen. In der Search Console finde ich immer wieder Fehler im Bereich Nutzerfreundlichkeit auf Mobilgeräten. Ich bin schon länger irritiert, da die Fehler neu auftauchen, obwohl das Crawling der betroffenen Seite mit unterm Monat her ist und bis in den Dezember 2018 in Einreich. Ich verstehe die Fehlermeldung nicht wirklich, da eine manuelle Prüfung der Seite als fehlerfrei identifiziert. Wir vermuten, dass der Board nicht alle Ressourcen laden kann. Stimmt das und gibt es da Abhilfe? Das kann sehr gut sein. Das heißt, wir müssen für das Erkennen der Mobile-Freundlichkeit die Seite Render bei uns. Wenn gewisse Ressourcen nicht dann verfügbar sind, wenn wir die Seite neu renderen für diese Prüfung, dann kann es sein, dass wir die quasi die übrigen Ressourcen, die quasi geladen werden können, wenn wir die im Browser anschauen, dass wir das Gefühl haben, dass es doch nicht Mobile-Freundlichkeit. Im Grunde genommen kann es solche Fluktuationen immer geben. Ich denke gerade bei einer größeren Website wird das immer eine gewisse Anzahl solcher Fehler haben, wo wir einfach aus irgendwelchen technischen Gründen nicht alle Ressourcen laden können. Manchmal liegt das auf eurer Seite, dass wir da vielleicht gerade die gecached URL nicht holen können vom Server. Manchmal liegt das auf unserer Seite, dass wir da vielleicht eine falsche URL gecached haben. Und das nächste Mal, wenn wir die Seite anschauen, wird das wieder klappen. Von dem her würde ich punktuell manuell diese Seiten einfach prüfen, einfach schauen, dass ihr wirklich nichts verpasst habt. Aber wenn das eine kleine Anzahl ist im Verhältnis zu dem Rest der Website, dann würde ich mir da keine großen Gedanken machen. Ich denke längerfristig müssen wir in den Search Console schauen, dass die Fehler da vielleicht ein bisschen stabiler sind. Das Sachen, die wirklich Fehler sind, dass die klar quasi ersichtlich sind dort. Aber es ist immer ein Balance zwischen Fehler schnell zeigen in Search Console, sodass ihr da schnell reagieren könnt und wirklich auch sicher sein, dass da ein Fehler vorhanden ist und entsprechend vielleicht zwei, drei Mal abwarten, ob das längerfristig ein Fehler ist oder ob das jetzt nur eine einmalige Sache war, die beim nächsten Render wieder okay ist. Von Google gab es ja den klaren Ratschlag, das Canonical Tag und No Index nicht zu mixen, das inkonsistente Signale sind. Kann so ein Mix, Schuld on Ranking beziehungsweise Traffic Verlusten sein. Selbst wenn die betreffende Website diese Einstellung schon über einen sehr langen Zeitraum besitzt und erst jetzt diese Verluste spüren. Glaub ich nicht. Ich denke, das sollte eigentlich kein Einfluss auf das Ranking haben. Vielleicht kurz zurück zum ursprünglichen Problem, was wir damals hatten oder was wir einfach gesehen haben, war das mit dem Canonical Tag, sagt man ja, dass zwei Seiten an und für sich identisch sind, dass man die beliebig die eine oder die andere nehmen kann für die Indexierung. Und mit dem No Index sagt man, diese Seite hier sollte gar nicht indexiert werden. Das heißt, wenn ich eine Seite mit No Index habe und mit einem Canonical auf eine Seite zeige, die kein No Index hat, dann sind das ja sehr unterschiedliche Seiten. Dann theoretisch kann es sein, dass unsere Algorithmen dann sagen, halt, diese Seiten sind genau gleich und hier ist ein No Index, also soll ich beide Seiten nicht indexieren. Ich denke, von vielen Webmastern ist das anders gemeint, in dem Sinn, dass man sagt, hier habe ich ein No Index und ein Canonical, das heißt, ich möchte, dass ihr wirklich nur diese andere Variante indexiert. Und das war damals einfach das Hauptproblem, wo wir gesehen haben, dass das, was Webmaster meinen, nicht ganz mit dem übereingestimmt haben, was unsere Systeme vielleicht vermutet haben. Und in der Regel ist das kein Problem. Das heißt, wir erkennen diesen Canonical Tag, wir erkennen ein No Index, wir wissen, der No Index gilt für diese Seite. Die andere Seite hat kein No Index, also nehmen wir einfach die andere Seite in den Index und an und für sich ist das okay. Das ist aus unserer Sicht einfach eine technische Sache. Ist diese Seite indexiert oder ist sie nicht indexiert? Das hat überhaupt keinen Einfluss auf das Ranking. Das heißt, es ist nicht ein Zeichen für uns, dass die Website nicht gut ist, wenn man das so mischt. Es ist wirklich einfach ein technisches Signal, wo wir zumindest damals nicht ganz sicher waren, wie das eigentlich gemeint wird. Eben, wie gesagt, inzwischen sollte das eigentlich kein Problem sein, das sollte eigentlich einfach so klappen. Und es sollte auf jeden Fall kein Einfluss auf das Ranking der gesamte Website haben. Das heißt, es betrifft ja wirklich nur diese zwei Seiten, die wird indexiert, die wird nicht indexiert. Und es betrifft nicht den Rest der Website. Und wenn diese Seiten indexiert werden, dann sind sie indexiert. Man kann sie normal in den Suchergebnissen erscheinen. Das heißt, wenn ihr ein Ranking Verlust oder ein Ranking Veränderung oder ein Traffic Verlust oder einfach eine allgemeine Traffic Veränderung seht und ihr erkennt, dass ihr mit diesem Canonical No Index etwas habt auf eurer Website, dann wird das nicht wegen dem Canonical No Index sein, sondern dann wird das eher etwas anderes sein. Entweder auf eurer Seite, dass wir da vielleicht irgendwas erkannt haben, auf eurer Seite was nicht ganz optimal ist, oder auch auf unserer Seite, dass wir gesagt haben, wir passen unsere Ranking Algorithmen jetzt leicht an, so dass wir möglicherweise oder idealerweise mehr relevante Inhalte zeigen können und dann gibt es halt die Situation, dass einige Websites werden vielleicht sichtbarer in den Suchergebnissen, andere entsprechend weniger sichtbar. Aber das sind wirklich ganz unterschiedliche Sachen. Einerseits die technische Frage über die Indexierung, andererseits das Ranking, das ist eigentlich ganz klar getrennt. Kann es sein, dass sich zwei Bewertungen einmal beim Type-Organisation und einmal beim Type-Product beißen und Google gar keine Bewertungen in Suchergebnissen durch Sterne ausspielt? Es handelt sich tatsächlich um zwei unterschiedliche Bewertungen, einmal von uns allgemein als Anbieter und dann von einem konkreten Produkt. Kann Google das eventuell nicht trennen oder den Unterschied erkennen und spielt daher nichts aus? Sollte man die Einbindung von Organisation mit Ranking auf Produktzeiten besser weglassen und dort nur den Type-Product mit Produktbewertung auszeigen. Ja, also von den Structured-Data-Wichtlinien ist es so, dass wir erwarten, dass Structured-Data betreffend dem Hauptelement dieser Seite ist und nicht, dass man da verschiedene Elemente entsprechend markiert mit Structured-Data. Das heißt, wenn ihr zum Beispiel eine Bewertung auf diesen Seiten habt, dann soll das entsprechend dem Hauptelement auf dieser Seite sein. Bei einer Produktzeite wird das wahrscheinlich das Produkt sein. Wenn man eine Seite über eine Firma allgemein hat, dann könnte ich mir vorstellen, dass man da auch eine Bewertung über die Firma allgemein hat, aber das wäre dann nur auf dieser Seite über diese Firma. Es wäre dann nicht auf der Produktzeite, dass man dann nochmal separat die Firma bewerten würde. Ob das dazu führen kann, dass wir gar keine Sterne zeigen oder nicht, ist schwierig zu sagen. Auf jeden Fall wäre so etwas verwirrend für unsere Systeme. Das heißt, ich würde im ersten Moment wirklich aufräumen und schauen, dass man die Structured-Data-Guidelines, dass man denen klar folgt, dass man das sauber eingebunden hat auf diesen Seiten und dann mal abwarten, wie das neu verarbeitet wird, dann entsprechend wieder einlegt. Ich glaube, der Rest der Frage ist ähnlich. Ich habe in Search Console 7.931 gültige Seiten. Nutzerfreundlich sind aber nur 2.040 Seiten auf Mobilgeräten. Wir sind im Mobile First Index. Ist die Differenz von 5.000 Seiten nicht freundlich oder gibt es andere Probleme mit diesen Seiten? Alle unsere Seiten sind responsiv. Das ist eine gute Frage. Das kommt, glaube ich, bei einigen Berichten vor in Search Console, z.B. auch mit Structured-Data, kann man solche Unterschiede sehen. Und zwar kommt das daher, dass wir in diesen aggregierten Berichten z.B. über die Nutzerfreundlichkeit oder Structured-Data oder, ich glaube, auch für den Erntbericht nehmen wir eine Probe der Seiten, die wir indexiert haben, also ein Teil der Seiten, die wir indexiert haben und testen die. Das heißt, wenn all diese Seiten okay sind, dann sieht man trotzdem nur ein Teil dieser Gesamtzahl im Test als okay. Wenn wir der einzelnen Fehler sehen, dann zeigen wir entsprechend die Fehler dort auch an. Und jetzt konkret in deinem Fall hast du Größenordnung 8000 Seiten, die indexiert sind, die sind soweit okay. 2000 davon etwa testen wir für die Nutzerfreundlichkeit auf Mobilgeräten und das ist das, was wir in diesem Bericht entsprechend zeigen. Das heißt, auch wenn z.B. ein Teil dieser Seiten mit AMP sind oder ein Teil dieser Seiten eigene Structured-Data-Varianten zeigen, dann nehmen wir einfach ein Teil davon, das aus der Gesamtmenge in diesem Bericht und zeigen entsprechend an, wenn da Fehler dort vorhanden sind. Das heißt, ich würde mir wegen diesem Unterschied zwischen den 2000, die getestet werden und den 8000, die vorhanden sind, würde ich mir nicht den Kopf zerbrechen. Wenn du siehst, dass die, die getestet werden, alle okay sind, dann ist das ja soweit okay. Und eben gerade bei diesem Nutzerfreundlichkeit-Test auf Mobilgeräten kann es wie bei einer anderen Frage gesagt auch vorkommen, dass wir einfach da leichte Fluktuationen haben, dass wir mal einige URLs als nicht nutzerfreundlich sehen würden und dann im zweiten Test sehen wir, ah, jetzt können wir die Seite vollständig laden, die sind doch okay. Ich hätte da eine Frage zu. Okay. Erstmal, ich weiß nicht, deine Webcam ist irgendwie nicht da oder ist das jetzt nur bei mir so? Okay. Okay. Mal schauen, wie die Aufnahme kommt. Vielleicht ist das ja auch noch bei mir so. Ich hätte da eine Frage zu. Und jetzt ist es ja so, dass ich bei mir ein Zeitstempel integriert habe auf den Internetseiten. Dieser Zeitstempel, wenn ich jetzt eine Zeitabfrage mache mit meiner Domain und diesem Zeitstempel, das zeichnet mir Google jetzt im Moment 2800 Seiten an. Wenn ich eine Zeitabfrage ohne diesen Zeitstempel mache, dann werden mir so 8000 Seiten angezeigt. Also diese 2000 Seiten, die kommen irgendwie auch in diese Nutzerfreund, also mit diesen mobilen Seiten. Das passt ja ungefähr mit der Anzahl. Also wieso zeichnet er dann nicht 8000 Seiten auch mit diesem Zeitstempel dann an? Gibt es da irgendwie eine Beschränkung, wie viele Suchtreffer ihr anzeigt? Grundsätzlich ist es so, dass bei einer Zeitabfrage die Gesamtzahl, die wir da zeigen, stark variieren kann. Das heißt, ich würde, gerade eine Zeitabfrage würde ich nicht irgendwie als Diagnosemittel oder so etwas anschauen, sondern da kann es wirklich sein, dass das Faktor 10 oder Faktor 100 irgendwie in die falsche Richtung gehen kann, beides nach oben oder nach unten. Und da würde ich mir wegen dem nicht großgedankt machen. Das ist einfach optimiert auf Geschwindigkeit und manchmal zeigt es Sachen an, wie da jetzt bei dir. Ich bin ein bisschen überrascht, dass die 8000 etwa übereinstimmen, weil normalerweise ist da auch schon ein rechter Unterschied. Also bei der normalen Zeitabfrage ja. Und wenn ich diesen Zeitstempel mit einfüge, dann stimmt es ungefähr halt mit diesen nutzerfreundlichen Seiten mit der Anzahl überein. Deswegen denke ich, dass wahrscheinlich für die Leute, die jetzt nach uns suchen oder beziehungsweise dass nur diese 2800 Seiten auch angezeigt werden überhaupt. Und alle anderen sind vielleicht wegen schlechter Qualität oder so irgendwie nicht drin im Index. Das ist nicht so, als wäre nicht angezeigt. Nein, es sollte eigentlich nicht sein. Du kannst es wahrscheinlich kontrollieren, indem du gezielt nach solchen Seiten suchst, die nicht in diesen 2000 sind. Bei 2000 ist es schon ein bisschen schwierig, das herauszufinden. Bei einer größeren Website lässt sich das kaum noch machen. Aber das sollte nicht der Fall sein. Wenn wir ein Search Console beim Index Coverage zeigen, dass da diese 8000 etwa indexiert sind, dann sind die effektiv auch indexiert. Manchmal ist das einfach eine Frage vom G8D-Mimal sucht. Und bei einer Side-Up-Frage ist es wirklich so, dass wir das auf Geschwindigkeit optimiert haben und nicht unbedingt auf Vollständigkeit. Und da werden die Gesamtzahlen einfach geschätzt. Das heißt, wir schauen das an, was wir im ersten Moment sehen und rechnen da ein bisschen hoch und vermuten, dass es ungefähr stimmt. Ich würde das auf keinen Fall irgendwie als Diagnosemittel nehmen. Du siehst das auch sehr schnell bei größeren Websites. Manchmal, wenn man eine Side-Up-Frage macht, dann kommen da irgendwie 100 Mio. Seiten zurück, obwohl das fast nicht möglich ist. Und manchmal sieht man auch dann lustige Effekte, dass wenn man mehr Suchbegriffe noch dazu nimmt zur Side-Up-Frage, die Gesamtzahl höher wird. Das sind einfach so Artefakte, die man sieht, die davon kommen, dass wir wirklich diese Zahl erschätzen, dass wir nicht durchgehen und wirklich jetzt alle Seiten durchzählen und schauen, wie viele Seiten passen dazu oder wie viel nicht. Okay, danke. Okay. In einem Search Console Konto habe ich mehr als 500 Webseiten und mehr als 100 Nutzer, welche zum Teil auch fälschlicherweise Admin sind und in der Zwischenzeit jedoch das Unternehmen verlassen haben. Um aufzuräumen, möchte ich nun einen neuen Search Console Konto erstellen. Wie importiere ich dafür die Daten des alten Accounts in den neuen? Da ich die Daten nicht verlieren möchte, wenn der Account gelöscht ist. Einfach unter Settings, Users on Permission den neuen Account zum Inhaber machen und den neuen Account per DNS validieren und den alten Account wieder löschen oder verliere ich dabei Daten. Gibt es eine Möglichkeit die Validierung von 500 Webseiten zu automatisieren? Ich denke, das sind verschiedene Sachen drin verpackt in der Frage. Einerseits kann man die Validierung von Webseiten auch per API einrichten. Das heißt, so könnte man relativ einfach nach dem was man für Möglichkeiten hat kann man auf jeden Fall das einrichten, dass man per API diese Websites quasi einreicht für die Validierung, dass man den Token zurückkriegt über die API, dass man den Token dann auf der Websites einrichtet z.B. per DNS oder per Metathag oder Datei automatisiert. Das heißt, man muss wahrscheinlich nicht diese 500 Websites von Hand neu anlegen. Ich glaube, das mit den 100 Nutzern wird wahrscheinlich schwieriger sein dass man das alle wieder einrichtet aber das könnte man unter Umständen auch irgendwie über die API machen wenn man einen eigenen Script auf dem eigenen Domain hat. Bezüglich Nutzern die das Unternehmen verlassen haben was ich normalerweise empfehle ist, dass man z.B. als Policy hat, dass man nur die Nutzern mit einem E-Mail-Adresse vom eigenen Domain zulässt dann ist es ja so, dass wenn dieser Konto für den Domain entsprechend entfällt weil der Benutzer jetzt nicht mehr bei der Firma ist dann ist automatisch der Zugriff auch auf die Website wieder weg. Bezüglich den Übernahme der Daten ist es eigentlich so, dass man da nichts übernehmen muss. Das heißt, die Einstellungen sind ja gesamthaft für die Websites und wenn ich die Website mit einem neuen Konto verifiziere dann sind die ganzen Einstellungen weiterhin dort. Das heißt, es ist nicht so wie bei Google Analytics dass man da quasi ein Archiv der bisherigen Daten nehmen muss und weiterverarbeiten muss sondern man kann durchaus mit einem ganz neuen Konto anfangen und dann sieht man die vollen Einstellungen die vollen Daten auch im neuen Konto. Das heißt, man muss nicht von einem Konto zum anderen übernehmen es ist einfach nur eine Frage von der Verifizierung, von der Validierung von diesen unterschiedlichen Benutzern und Websites. Okay, vielen Dank dafür. Ich beschäftige mich momentan mit Paginierung durch viele unterschiedlichen zum Teil verhalten Ansichten etwas verwirrt. Da bist du nicht alleine. Unsere Situation wir haben eine starke Landing Page mit meinem Verständnis nach muss die Landing Page auf Index Follow stehen auf dieser Landing Page gibt es Bereiche mit Pagination klickt man auf Seite 2 gelangt man zur eigenen URL von diesem Konto. Seite 2 Index Follow Werter LinkJuice auf die verlinkten Seiten von Seite 2 weitergegeben auch wenn die Seite selbst auf No Index steht wie sieht es mit dem langzeiten No Index Follow Wer zu No Index, No Follow umgewandelt heraus. Das ist an und für sich denke ich mal die Hauptproblematik in dem wenn wir längerfristig sehen dass eine Seite auf No Index ist dann nehmen wir an dass die Effektivverleichten gar nicht verarbeitet werden soll gar nicht indexiert werden soll wir crawlen die dann auch immer weniger und dann wird es so sein dass wir die Links von diesen Seiten auch nicht weiter verfolgen. Das ist an und für sich schon seit recht langer Zeit so das ist nicht etwas was was sich jetzt neuerdings verändert hat das ist eigentlich schon ziemlich seit dem Anfang so gewesen und so wie ich das sehe ist es eigentlich in den meisten Fällen unproblematisch auf diese Art weil die Sachen die jetzt weiter zurückliegen auf verschiedenen anderen Seiten wenn die sonst nirgendwo auf der Website verlinkt sind dann ist es ja meistens dann denke ich passt das einigermaßen zusammen worauf ich einfach achten würde wenn man jetzt eine Website mit sehr vielen Inhalten die nur über eine Paginierung erreichbar sind würde ich einfach darauf achten dass man auch in eine Querverlinkung einrichtet zwischen diesen einzelnen Inhaltsstücken das heißt wenn ich zum Beispiel ein Blog habe dass ich mit Kategorien auch arbeite oder dass ich die ähnliche Elemente miteinander verbinde einfach dass man da möglichst verschiedene Varianten hat mit der Google mit dem Anfang auf einer Seite der Website den Weg durch die gesamte Website auch finden kann und dann ist es eigentlich auch unproblematisch wenn man sagt ich habe einzelne Inhalte die sind auf Seite 4 oder 5 dieser Paginierungslisten aber die sind ja auch dann sonst wie index verlinkt innerhalb der Website dann müssen sie über diese Paginierungsliste auch nicht separat nochmal gefunden werden aber ich denke du wirst nicht alleine mit verwirrt sein bezüglich Paginierung ich denke dann müssen wir wahrscheinlich mal mit der Dokumentation das ganze neu zusammenverpacken und schauen wie man da gute Tipps auch mal zusammenstellen kann wie man das am besten angehen kann dann eine andere Frage wir überarbeiten unser System gerade in Richtung React mit server-side rendering damit die Seite für die Nutzer gut indexierbar sein wird kann es notwendig sein nur das Skeleton der Seite auszuliefern und die Inhalte verzögert nachzuladen wie wird der Crawler damit umgehen wenn im Ausgattel lieferten HTML nicht der gesamte Content vorhanden ist dann erst verzögert nachzuladen wird an und für sie ist das okay solange wir diese Seiten rendering können sehe ich da kein Problem es gibt 2 Sachen worauf ich achten würde wenn man das so macht einerseits wenn man mit dem Robots MatterTag arbeitet dass man den Robots MatterTag in der Skeleton Variante der Seite quasi auf Index stellt oder einfach nicht definiert auf dieser Seite damit dann im 2. Schritt wenn wir diese Seite renderen dass wir da den Robots MatterTag dann entsprechend auch korrekt vorfinden können weil was wir manchmal gesehen haben ist wenn man den Robots MatterTag quasi per Default auf No Index setzt dann lesen wir diese HTML Seite ein wir sehen den No Index MatterTag da und denken ah gut wir müssen diese Seite gar nicht indexieren oder gar nicht renderen weil wir wissen dass wir sie eh nicht indexieren dürfen und dann wird das mit dem rendering gar nicht erst ausgeführt das heißt wenn man ein Robots MatterTag auf der Skeleton Variante der Seite ausliefert soll das auf jeden Fall eher auf Index oder einfach ein leerer Robots MatterTag sein das 2. was relativ ähnlich ist ist dass man mit dem Canonical Tag auch so arbeitet das heißt idealerweise dass man ohne Well Canonical arbeitet auf dieser Skeleton Seite damit wenn wir die HTML Seite laden dann sehen wir kein Canonical Tag wenn wir sie dann indexiert haben oder gerendert haben dann sehen wir den Canonical Tag entsprechend passend zu dieser Seite andersherum wäre das vielleicht komplizierter wenn man zum Beispiel die HTML Seite erst mal laden wir sehen ein Canonical Tag und da steht zum Beispiel Canonical ist die Homepage oder Canonical ist ein Platzhalter für ein Variabel der danach per JavaScript ausgetauscht wird dann kann es sein dass unsere Systeme denken gut das ist der Canonical wir gehen dann einfach nur zur Canonical URL und renderen gar nicht erst diese einzelne Seite das heißt beides Robots MatterTag und Canonical würde ich möglichst nur bei der gerenderten Version ausliefern nicht schon in der statischen HTML Variante dann geht es gleich noch ein bisschen weiter wird dann der dynamische Content erst im Rendering Prozess interpretiert ja wenn wir die Seite renderen müssen um die Inhalte zu sehen dann sehen wir die Inhalte erst dann wenn die Zeitspanne das dynamische Content zu groß ist kann es vorkommen dass der Content für den Crawler interpreter nicht sichtbar ist und der Content nicht entdeckt wird theoretisch kann das passieren es ist so dass wir beim renderen relativ großzügige Timeouts haben und wir versuchen die einzelnen Unterkomponenten möglichst zu caching das heißt wenn wir sehen dass der JavaScripts Dateien werden auf diesen Seiten und das immer der gleiche Script dann versuchen wir diesen Script zu caching so dass wenn wir das Rendering ausführen dass wir da nicht alle einzelnen Inhalte für jede einzelne Seite noch mal neu laden müssen sondern dass wir da mit diesem Cache arbeiten können und so geht das eigentlich relativ schnell man sieht manchmal deswegen auch ein Unterschied zwischen Inspectorial in Search Console wo man das testen kann um mit der effektiven Indexierung in dem das mit dem Inspectorial Tool denken wir dass er benutzt möglichst alle Inhalte sofort sehen möchte und dass möglichst nichts vom Cache gelesen wird und wenn es dann zu langsam geht mit dem Rendering dann sieht man vielleicht nur eine Teilseite im Testing Tool bei der Indexierung ist es so dass wir mit dem Cache arbeiten können dass wir ein bisschen länger warten können das klappt das in der Regel eher das heißt wenn es im Testing Tool funktioniert mit den Timeouts dann funktioniert es auf jeden Fall dann auch bei der Indexierung Würdest du in dem Fall Hybrid Rendering empfehlen Googlebot bekommt eine langsame vollständig gerenderte HTML-Seite und der Nutzer sieht dann einfach die Kleinzeit-Version kann man machen ich denke das ist immer eine Frage von wie man das als einteilen will wenn man Hybrid Rendering macht muss man natürlich die Kleinzeit oder die Server-Seite gerenderte Version auch bereitstellen man muss diese Weiche einrichten das bringt auf jeden Fall mehr Komplexität manchmal hilft das mit Testing mit anderen Crawlern wenn man andere Testprogramme verwendet das ist an und für sich euch überlassen wir unterstützen beide Varianten wir sehen das auch nicht als Cloaking, wenn Benutzer eine Kleinzeit-Rendert-Version sehen und Googlebot eine Server-Seite-Gerenderte-Version sehen wenn die Inhalte an und für sich gleich sind dann ist das aus unserer Sicht okay vielen Dank für die ausführliche Antwort super langsam kommen wir gegen Ende der Zeit ich überlasse euch mal falls es noch Fragen aus eurer Seite gibt versuch die gerne zu beantworten von meiner Seite Johannes eine Frage ähnliches Thema Cloaking wenn eine Seite Content-Elemente versteckt und zwar nur für mobile User also alle User ab einer Media Query 480 Pixel Breiter plus sehen gewisse Inhalte aber mobile User nicht dort verstecken wir diese wirklich also sind nicht zugänglich für mobile User aber diese sind natürlich im Code komplett vorhanden wie ist das zu bewerten ist das Cloaking im Moment würden wir das glaube ich nicht Cloaking anschauen wenn die Inhalte effektiv im HTML vorhanden sind und wenn die für den Benutzer sichtbar sein können dann würden wir das als normale Inhalte anschauen die wir auch indexieren können weil gerade auf mobilen Geräten hat man ja einen beschränkten Platz und da kann man nicht alles Mögliche darstellen und da würden wir das an und für sich akzeptieren denke wichtig ist vor allem dass die Inhalte weiterhin zu diesen Seiten passen nicht dass das komplett fremde Inhalte dort sind die sonst nicht sichtbar wären in den meisten Fällen ist es ja so dass auf mobilen Seiten, dass man das so einrichtet dass man da zum Beispiel mit einem Tab oder mit bestimmten Bereichen dann einen größeren Text auch ausklappen kann dann könnte man ja trotzdem die vollständigen Inhalte anschauen und dann wäre das an für sich auf jeden Fall ok genau weil das ist ja der große Unterschied jetzt wenn man Akkordions oder Kollabstechniken benutzt aber die Frage war wenn man sich bewusst dagegen entscheidet gegen solche Ausklappen und Akkordions, sondern sagt wir verstecken diese ab einer gewissen Bildschirmbreite wie dann das zu bewerten ist ich vermute dass man da eher einfach Effekte von Benutzer sehen würde und nicht dass man da von Google etwas sehen würde also ich könnte mir schon vorstellen dass das Webspam-Team wenn man so etwas sehen würde und das wäre wirklich problematisch in diesem Rahmen, dass man zum Beispiel sagt nur ab 10.000 Pixel breite sieht man diese Inhalte das heißt kein normaler Benutzer würde die jeweils sehen dann könnte ich mir schon vorstellen dass das Webspam-Team sagt gut das sind so gut wie versteckte Inhalte und wenn die Inhalte nicht wirklich zu dieser Seite passen wenn man da versucht ich weiß nicht Wikipedia-Seiten Inhalte noch so zu verstecken dann könnte ich mir schon vorstellen dass das Webspam-Team damit nicht ganz zufrieden wäre aber alle Fälle die ich bisher gesehen habe waren eigentlich eher im normalen Rahmen dass man sagt, ich kann nicht ganz alles darstellen in meiner mobilen Variante also verstecke ich das mit responsive design die Inhalte passen weiterhin zu diesem Thema es ist nicht so dass grundlegend etwas anderes dargestellt wird auf anderen Bildschirmbreiten sondern das sind die gleichen Inhalte einfach ein bisschen ausführlicher oder ein bisschen weniger ausführlich manchmal sind ja auch Bilder in verschiedenen Auflösungen vorhanden dann sieht man sie einfach in klein auf mobile und dann vielleicht in groß auf desktop das ist eigentlich total okay aus unserer Sicht verstehe und was ist ich meine es gibt ja im mobilen Bereich oder grundsätzlich bei mobilen Geräten die Rotate-Funktion also horizontal und vertikal berücksichtigt ihr das beim Rendering in irgendeiner Form oder nehmt ihr nur eine Version und rendered mit der Version ich glaube wir nehmen nur eine Version und rendered mit der so viel ich weiß also das quasi in der normalen ich weiß nicht wie Portrait Portrait, genau in der Variante das heißt man sieht das ja auch im Testing Tool das ist an für sich die Art wie wir das testen, wir nehmen das nicht quer und wir haben ja nicht so diese Landscape Variante das schauen wir so für das Rendering nicht an vielen Dank könnte ich noch eine Frage zum Ranking stellen ja also uns hat es im März erwischt bei diesen Core Update also die Sichtbarkeit ist unheimlich gesunken jetzt so ungefähr seit Mai steigt es langsam wieder an und komischerweise seit Mai habe ich jetzt eigentlich auch fast überhaupt nichts mehr irgendwie an der Internetseite gemacht einfach laufen lassen wir mussten uns hier intern um so ein paar andere Dinge kümmern Windows 10 Umstellung ja so Zahlungsrichtlinien und so was alles meine Frage dazu ist können viele Änderungen an einer Internetseite eigentlich ein Abwärts Trend wenn es jetzt runtergehen würde nochmal beschleunigen oder würdest du sagen oder gibt es irgendwie wenn man zu viel ändert dass es eigentlich schlecht ist für die Seite würdest du sagen das passt so ungefähr diese Aussage oder sollte eigentlich nicht sein aber nicht grundsätzlich man kann ja auch viel verändern und das wird besser ich denke wenn man viele Sachen verändert dann kann es sich verändern in der Suche aber nicht dass es grundsätzlich schlecht wäre aber so Thema Neubewertung dass wenn man jetzt eine Änderung macht und auf einmal muss da nochmal alles neu bewertet werden und das kann dann 3 Monate dauern kann es sein eher selten also ich sehe das als etwas was passieren kann wenn man ein komplettes Redesign der Website macht das heißt die URL Struktur verändert dann braucht es einfach Zeit bis wir alles neu berechnet haben aber wenn wenn das normale Veränderungen sind an Inhalt dann geht das nicht so schnell und zum Core Update wenn ich mir das Core Update jetzt so vorstelle macht ihr dann ein Reset praktisch und sagt okay diese Seite hat zum Beispiel dann 100 Punkte und dann kann diese Seite ab diesem Zeitpunkt dann wieder neue Punkte sammeln und dadurch steigt die Seite da ich muss leider hier aus dem Zimmer raus aber vielen Dank fürs Gäumen nochmal und hoffentlich sehen wir uns richtig mit Kameras nächstes mal wieder okay, tschau