 Okay, herzlich willkommen beim heutigen Webmaster Essentials Sprechstunden Hangout. Mein Name ist Johannes Müller, ich bin Webmaster Chance Analyst hier bei Google in der Schweiz. Und Teil von dem, was wir machen, sind solche Webmaster Hangouts, wo Webmaster Publisher vorbeikommen können und Fragen stellen können oder weitere Formationen einfach rund um die Websuche abfragen können. Wie immer sind schon einige Fragen eingereicht worden, aber wenn einer von euch möchtet, könnt ihr gerne schon mal loslegen. Nicht spezielles, okay. Ja, ich möchte mich auf jeden Fall bedanken für deinen Händweis, was Svenger betraf. Also, wir haben dann intern gesucht, war es noch letzte Woche? Ah ja, genau. Und genau, das war es. Jetzt haben wir es ausgemerzt und der Botcrod dient nicht mehr bei uns. Vielen Dank. Super, okay, toll. Manchmal ist es schwierig herauszufinden, wo das alles herkommt. Okay, sonst schauen wir mal die Fragen an, die eingereicht worden sind und schauen wir mal, wie weit wir kommen. Wenn ihr zwischen euch Kommentare habt, wo der weitere gehende Fragen einfach loslegen. Als Erstes, eine Frage zu Emojis in den Suchergebnissen. Viele Mitbewerber verwenden zum Beispiel so ein Haken oder ein Plus in Metadescription, einfach um etwas mehr Aufmerksamkeit zu erhalten. Diese Emojis erscheinen mir jedoch an vielen Stellen einfach deplatziert. Und für mich sieht das schon ein bisschen nach Spamming aus. Wir sehen daher davon ab, da es unserer Meinung nach keinen Mehrwert hat. Bist du der Meinung, dass wenn wir so etwas bei anderen Seiten in Suchergebnissen sehen und Google es offenbar auch anzeigt, Google es somit für relevant und nicht für Spamming hält, können wir so etwas auch gezielt einsetzen, ohne mit einer Abstrafung zu rechnen. Gute Frage. Ich weiß nicht, irgendwie auf in den deutschen Suchergebnissen ist das sehr verbreitet, das Ganze mit den Emojis in Description oder im Titel auch dabei. Ich sehe das sehr selten auf Englisch. Ich weiß nicht, warum das so ist. Wir haben das mit den Team vor einiger Zeit also das Ganze ein bisschen angeschaut und grundsätzlich aus Sicht von unseren Engineering Team ist es nicht so, dass wir das aus Spamming sehen würden. Einige dieser Symbolen filtern wir heraus, wenn wir denken, das könnte verwirrend sein, aber viele lassen wir an und für sich so wie sie in den Sucher, in den Descriptions oder im Titel sind und zeigen sie es so einfach an. Von dem her könnt ihr da schon so machen. Ich finde es auch ein bisschen, sieht ein bisschen Spamming aus, aber vielleicht funktioniert es, vielleicht funktioniert es bei deutschen Suchenden eher und vielleicht bei Englischen weniger. Ich weiß es nicht. Ihr könnt das gerne ausprobieren. Auf jeden Fall ist es nicht so, dass wir das als Spam sehen würden und wenn das für uns problematisch wäre, würden wir diese einzelnen Symbole einfach herausfiltern in den Suchergebnissen und der Eintrag, das Ranking in den Suchergebnissen wäre an und für sich gleich. Description wird ja auch nicht als Rankingfaktor verwendet. Von dem her könnt ihr damit durchaus ein bisschen spielen und schauen, was für euch am besten funktioniert. Wir sind mit sämtlichen Shops mittlerweile Mobile First geswitched laut Search Console. Aktuell betreiben wir Dynamics-Serving, unsere mobilen Seiten dediziert und nicht responsiv. Ich habe bis dato immer noch nicht zinssichtlich des Canonicals bei dedizierten mobilen Seiten gelesen. Im Allgemeinen verweisen ja die dedizierten Seiten per Canonical auf die Desktop-Variante. In dieser Wiederum verweist wir real alternate auf die mobile Variante. Rein logisch gesehen fühlt sich das merkwürdig an, wenn weiterhin vom Mobile zu Desktop kanonisiert wird, obwohl doch die Inhalte vom Mobile für das Render in den Suchergebnissen verwendet wird. Ja, das ist durchaus ein bisschen verwirrend. Grundsätzlich ist es aber so, dass wir diesen Link mit real alternate und real canonical hilft uns einfach die Desktop-Version der mobilen Seite zuzuordnen. Das heißt, wir sehen das nicht als Zeichen, dass wir die Desktop-Version als Canonical verwenden sollen, sondern einfach, dass diese beiden Seiten zusammengehören und das entsprechend mit diesem Verhältnis, dass sie die Seiten zusammen verlinkt sind. Das heißt, eins ist die Desktop-Variante, eins ist die mobile Variante. Von dem her ist es so, dass wir bei mobile-first indexing die mobile Variante als canonical auswählen und die auch für die Indizierung verwenden. Aber dieser Link mit dem real canonical sollte trotzdem zur Desktop-Version zeigen, einfach damit wir diese Verbindung zwischen der mobilen und der Desktop-Version sauber aufrecht haben. Ich denke, das ist eines dieser Sachen, die ein bisschen verwirrend sind mit mobile-first indexing macht. Auf dem ersten Blick nicht wahnsinnig viel Sinn, weil wir ja die mobile Variante als canonical nehmen und eigentlich erwarten, dass man den real canonical auf die Desktop-Variante setzt. Aber gerade bei separaten mobilen Seiten ist das halt diese Kombination immer noch gültig. Wir haben das am Anfang mit dem Team auch angeschaut, ob man das nicht ändern sollte oder sagen sollte, ihr könnt das umdrehen und wie quasi ein real alternate Desktop einbinden. Aber vom mobile indexing Team war eigentlich der grundlegende Gedanke, dass man das Webmaster möglichst wenig verändern muss für mobile-first indexing. Das heißt, wir wollen nicht erwarten, dass Webmaster diesen Zeitpunkt irgendwie möglichst auf den Tag genau erwischen können und dann alle diese Links umstellen innerhalb ihrer Website, weil teilweise werden die Links ja auch von anderen Suchmaschinen verwendet und dementsprechend haben wir dann uns einfach entschlossen, dass wir diese bestehende Verknüpfung weiterhin beibehalten und trotzdem einfach die mobile Version für die Indexierung nehmen. Weiß nicht, ob... Tecmo war noch, glaube ich, mit SideMaps auch da eine Frage. Gerade jetzt, wenn man mobile Version hat und eine Desktop-Version, welche nimmt man in die SideMap Datei. Aus unserer Sicht ist die weiterhin die Desktop-Variante, die definitiv in der SideMap Datei dabei sein sollte. Man kann aber auch die mobile Variante dazu nehmen. Wir crawlen ja dann auch die mobile Variante und sehen dann den Link zur Desktop-Version und können das entsprechend so dann auch wieder zurückverfolgen. Im letzten Hangout ging es um die Darstellung von Rich Snippets. Du hattest gesagt, dass es drei Gründe dafür gibt, dass bei einer Seite kein Rich Snippet angezeigt wird. Google vertraut dem Domain nicht. Jason Aldi hat einen Fehler oder das wird gegen die Richtlinien verstoßen. Die Frage ist ein bisschen länger, aber ich glaube, es geht daraufhin, dass einige Seiten innerhalb der Website bei denen wertwohl gerade die Star-Ratings gezeigt bei anderen Seiten nicht. Und ob es da irgendwie gezielt etwas gibt oder ob da vom Quality-Hair vielleicht das auf einem Seitenebene weiter bearbeitet wird. Wir schauen das grundsätzlich eher auf Domain-Ebene an oder auf der Ebene der Website halt. Das heißt, es ist nicht so, dass wir dann sagen würden, einzelne Seiten vertrauen wir nicht, in anderen Seiten schon. Von dem her würde ich da jetzt nicht allzu viel in die Richtung hineingehen, aber es ist aus unserer Sicht auch ganz normal, dass wir einfach für alle Seiten einen bestimmten Suchergebnis nicht Rich Snippets zeigen. Manchmal ist es ja auch so, dass wenn man die Suchergebnisse anschaut, dass da einfach so viele optische Elemente dabei sind, dass wenn wir für jede Seite alle möglichen Rich Snippets zeigen würden, dann wäre das einfach unübersichtlich. Und dementsprechend ist es schon so, dass unsere Algorithmen dann sagen für eine bestimmte Suchergebnisseite, nehmen wir da entsprechend ein paar Rich Snippets dazu und zeigen das so an. Wenn wir nicht zu viel haben, dann machen wir einfach stopp und sagen, wir können nicht für alle Seiten in diesen Suchergebnissen die Rich Snippets zeigen. Was ich da aber trotzdem machen würde, wenn das wirklich einzelne Seiten sind, die bei denen nie Rich Snippets gezeigt werden, einfach wirklich nochmal gezielt die ganzen technischen Voraussetzungen anschauen, mit den entsprechenden Testtools das nochmal anschauen. Und damit man sicher ist, dass wirklich vom technischen her das dann nicht irgendwo was klemmt. Ich habe eine Frage zu Search Console. Im Bereich Leistung werden im oberen Diagramm Clicks insgesamt angezeigt. Die Anzahl Clicks unterscheidet sich jedoch meist stark von der tabularischen Darstellung im Bereich Suchernfragen. Und dann das ist aus unserer Sicht normal. Es ist ein bisschen verwirrend in Search Console gebe ich zu, aber es ist so, dass bei den Suchanfragen, die wir darstellen in Search Console, gibt es einen gewissen Filter, um einzelne Suchbegriffe herausfiltern, die sehr selten verwendet werden. Und da ist es eigentlich normal, dass wir oben quasi die Gesamtzahl darstellen, aber dass wir nicht die Suchanfragen da auflasten. Das heißt, wenn man die einzelnen Suchanfragen zusammenzählt, dann gibt es nicht unbedingt die Summe oben. Das heißt, die Summe oben ist eigentlich wirklich das Total. Und die Suchergebnisse, die dargestellt werden, sind einfach diejenigen, die nicht herausgefiltert worden sind. Man sieht das auch manchmal, wenn man wechselt zwischen der Darstellung mit den Suchanfragen und der Darstellung mit den Seiten. Bei den Seiten müssen wir diese Filtrierung nicht machen. Und da ist es meistens schon so, dass die Einträge, die in der Tabelle zusammengezählt werden, dass sie dementsprechend was oben beim Total auch erscheint. Wie sollte man idealerweise mit 404 Fehlern umgehen? Versuchen so viele wie möglich zu reparieren. Zum Beispiel durch 301 Weiterleitung oder anderen Content einsetzen oder 404 beibehalten. Einige URLs beziehungsweise Medien, Bilder und Videos abgelaufen sind und nicht mehr vorhanden sind. Was macht man da am besten? Aus unserer Sicht sind 404 Fehler kein Fehler, den man beheben muss. Sondern das ist einfach wirklich ein Zeichen, dass diese Inhalte existieren halt nicht mehr. Und wenn sie wirklich nicht mehr existieren innerhalb deurer Website, dann ist 404 der richtige Status Code zum zurückgeben. Schwieriger oder problematischer bei 404 ist eher, wenn ihr zum Beispiel aus Versehen 404 zurückgegeben habt, wenn wir eigentlich diese Seite indexiert haben wollen. Und teilweise wird das in Search Console auch so herausgezogen. Das heißt, wenn wir zum Beispiel sehen, dass eine Seite in einer Sidemap Datei ist und 404 zurückgibt, dann sind wir nicht ganz sicher was da jetzt passiert ist. Ob das vielleicht ein Fehler ist auf eurer Seite oder wie ihr das handhaben wollt. Und deswegen wird das ein bisschen speziell in Indexierungsbericht in Search Console dargestellt. Das heißt, mit der Sidemap Datei sagt ihr, diese Seite möchte ich indexiert haben. Und mit dem 404 sagt ihr, diese Seite soll nicht indexiert werden. Und das würden wir dann in Search Console ein bisschen hervorheben. Einfach damit ihr diese Seite mal anschauen könnt und kontrollieren könnt, soll die wirklich 404 zurückgeben oder ist da vielleicht irgendein technischer Fehler auf eurer Seite. Wenn bestehende Seiten ersetzt werden durch neue Seiten, ist eine Weiterleitung eigentlich korrekt. Wenn gewisse Seiten gar nicht mehr vorhanden sind, dann ist 404 halt das Richtige. Es ist nicht so, dass eine Website bestraft wird, wenn 404 nur 4 Fehler da sind, das ist ein normaler Zustand. Das werden wir URLs aufrufen, die nicht mehr existieren, dass ihr uns dann klar sagt, die Adresse funktioniert nicht, da gibt es nichts zu indexieren. Leere Seiten, die eventuell später wieder Content haben, man hat eine Seite, auf der man Veranstaltungen von Künstlern und Informationen dazu auflistet. Nun hat nicht jeder Künstler immer Konzerte. Wir können mit diesen Seiten auf eine Webseite umgehen. Aktuell lassen wir die Seite bestehen, verlinken diese auch weiterhin intern auf einer Übersichtseite aller Künstler. Auf der Seite selbst zeigen wir dem Nutzer an, dass der Künstler aktuell keine Konzerte geplant hat. Der Nutzer hat dann die Möglichkeit, seine E-Mail Adresse einzutragen und informiert zu werden, wenn es wieder Konzerte gibt. Da es viele Künstler gibt, es gibt viele Seiten, die vermutlich den Content haben. Wie würdest du mit diesen Seiten umgehen? Wir haben drei Möglichkeiten herausgearbeitet, wie bisher Seite bestehen lassen und auch intern verlinkt lassen oder zweiten Seite bestehen lassen, aber intern nicht mehr verlinken, damit in der Übersicht nur Künstler sind, welche auch aktuelle Termine haben und drittens, wenn keine Termine vorhanden sind, sind die Seiten auch 4.04. An und für sich kann man mit allen drei dieser Varianten das durchaus machen. Ich denke, es ist wirklich einfach eine Frage wie weit diese, sag ich mal, leere Suchergebnisse Seite, also diese Seite für den Künstler ohne speziellen Informationen, wie weit die wirklich für Nutzer brauchbar ist. Wenn die durchaus für den Nutzer relevant sein könnte, wenn sie interessant ist, wenn sich viele da eintragen wenn diese Seiten vielleicht häufig auch separat aufgerufen werden, dann könnte ich mir schon vorstellen, dass man die beibehält und dass man die auch entsprechend intern verlinkt. Wenn hingegen die Seite wirklich wie eine leere Suchergebnisse Seite ist und eigentlich steht da, wir haben keine Informationen zu diesem Thema, dann könnte ich mir vorstellen, dass vielleicht auch in 4.04 der richtige Status da ist, dass sie wirklich aus dem Index herausfällt, dass wir nicht Benutzer auf eure Seite schicken und dann heißt wir haben doch nichts für dich. Aber das hängt wirklich, würde ich sagen, eher davon ab wie ihr das Hand habt und welchen Nutzen ihr für Benutzer macht, wenn es im Moment keine Konzerte gibt. Von dem her ist es schwierig zu sagen, wie ich das machen würde, ohne eure Seiten direkt anzuschauen. Ich würde einfach, wenn ihr sie bestehen lassen wollt, würde ich wirklich schauen, dass es wirklich auch irgendein Mehrwert auf diesen Seiten da ist, dass es Sinn macht, für uns Benutzer zu euren Seiten zu schicken. Das heißt, wenn jemand nach einem Künstlernamen plus Konzerte sucht und wir eure Seite zeigen würden, dass er nicht einfach enttäuscht ist, wenn er auf eure Seiten kommt und dass man da ein bisschen mehr Informationen hat, vielleicht über die bisherigen Konzerte, vielleicht über Konzerte in anderen Regionen, irgendwelche Informationen, die relevant sein könnten für den Nutzer. Eine Frage zum Thema Backlinks. Gesetzt in Fall, eine Online-Zeitung schreibt über unsere Beiträge. Ich schreibe in einem News-Artikel, dass sich sogar die Zeitung mit unserem Beitrag beschäftigt hat und verlinke auch auf diesen Beitrag. Siehst du, sieht das jetzt für Google wie ein Linktausch aus. Sollten beide Artikel Links mit NoFollow arbeiten, würde es reichen, wenn ich den Link zur Online-Zeitung auf NoFollow setze, sodass ich von deren Follow-Link doch profitieren kann. Was, wenn ich deren Logo ein Partnerliste aufnehme und sie ihn verlinke. Das klingt eigentlich alles sehr organisch aus. Also alles so, wie ich sagen würde, ist überhaupt kein Problem. Ich würde mir da in der Regel nicht groß den Kopf zerbrechen, wenn irgendjemand über eure Beiträge schreibt und ihr seid stolz darauf, dass ihr da erwähnt werdet, dann würde ich doch das auch erwähnen und da entsprechend hinverlinken und das meinen Kunden zeigen. Das ist auch, dass man da wie eine Art externe Referenz hat, dass jemand anders, dass die Information oder die Website, die Dienstleistung, die Produkte getestet hat und darüber selber geschrieben hat. Das aus meiner Sicht ist das überhaupt kein Problem. Mit dem Linktausch ist es eher dann problematisch, wenn wir sehen, dass wirklich alle Links von dieser Website diesem Schema folgen, dass irgendjemand dann gleich wieder zurück. Wenn das so aussieht, als ob das fast systematisch gemacht wird, dann könnte ich mir vorstellen, dass unsere Webspam Algorithmen das anschauen und denken, irgendwie sieht das zu stark nach abgesprochen aus und dann müssen wir da vielleicht ein bisschen kritischer das anschauen. Bei normalen, vielleicht mal organischen Erwähnungen von einer Website mit einem Nachrichten Website, sehe ich da überhaupt keine Probleme. Also da würde ich mir gar nicht groß den Kopf zerbrechen, bezüglich NoFollow oder nicht, sondern wenn ihr stolz auf diese Erwähnung seid, dann könnt ihr darauf auch verlinken. Das sehe ich überhaupt kein Problem. Ich hätte da eine Frage zu. Wie erkennt da ein Google, ob jetzt ein Link kritisch ist, also in meinem Fall fünf Online-Shops, alle nicht gegeneinander, also auch von allen Artikelseiten. Also erkennt ihr das, dass das alles zusammen gehört? Meistens schon. Meistens sind die Muster im Größe, wenn man das Gesamtbild anschaut, sieht man die Muster da schon relativ gut. Und ich denke gerade, in so einem Fall, wenn das fünf Websites sind, die zusammenarbeiten, vielleicht für einzelne Länderversion, einzelne Sprachversion, die wir ja oft im Internet, das ist überhaupt kein Problem. Linktausch, wenn es Richtung Webspam geht, ist wirklich etwas, wo wir, wenn das zum Beispiel jemand manuell anschaut, dann ist es eigentlich sehr klar, was da passiert. Dann sind das irgendwie so low quality Blogs, die sich gegenseitig in den Sidebar irgendwie verlinken und dann steht noch ein Link dabei, quasi du kannst dich hier eintragen und du musst dann nur auf meine Seite und die lassen sich relativ schnell erkennen. Und sobald das etwas ist, wo wir sagen würden, das ist eigentlich eher organisch und wenn wir sehen, dass das nicht alle Links diesem gleichen Muster folgen, dann ist da eigentlich überhaupt kein Problem. Also zum Beispiel alle Domains sind auf der gleichen IP oder im selben Subnetz, das wäre dann schon so ein Hinweis darauf, dass das wohl zusammen gehört. Ja, wenn das in deinem Fall, wenn das wirklich Webseite sind, die zusammengehören, dann sehe ich da auch kein Problem, wenn das auf unterschiedlichen IP-Adressen ist, ist nicht so, dass man das irgendwie kennzeichnen muss, also sagen muss, quasi wir sind ein Teil der gleichen Gruppe. Das ist eigentlich überhaupt kein Problem. Okay, danke. Wir sind ein Live-Blogging Software as a Service Anbieter für Publisher. Neue Live-Blogs auf unseren Server, unser Kunden werden euch einen Eintrag in ihre News-Sitemap schnell indiziert. Aber Updates im Live-Blog brauchen trotz News-Sitemap Updates teilweise Tage. Ein solches Beispiel ist ein Fußball-Transfer-Ticker mit Updates zur Spiele wechseln. Gibt es Empfehlungen, was für ein schnelleres Reindexierung machen könnte? Schwierig zu sagen, ich glaube, es gibt ein Art Structure-Ticker speziell für solche Live-News-Updates, aber ich weiß nicht, ob das freigeschaltet ist oder ob das in Deutschland überhaupt erhältlich ist. Das wäre vielleicht eine Variante. Andererseits ist eigentlich nur, sag ich mal, das normale, was man so machen kann, um Updates entsprechend bekannt zu geben, das über die Sidemap-Datei mit einem neuen Änderungsdatum, das ist sicher mal eine gute Sache. Man kann einzelne Seiten kann man eigentlich auch über Search Console, über Inspect-Ural dort auch einreichen. Ich denke, für einen normalen Publisher, der regelmäßig neue Sachen dazu bringt auf einer Seite ist das wahrscheinlich nicht so praktisch, weil das muss man hier wirklich auch von Hand an und für sich machen. Von dem her würde ich schon eher in Richtung Sidemap, New Sidemap so tendieren. Was ich vielleicht mal machen würde, ist, wenn ihr seht, dass das nicht funktioniert, dass ihr mir mal genauere Informationen gibt, also einzelne Beispiel-Urails, damit ich das mit dem Team mal überlegen kann, wie könnten wir solche Updates ein bisschen schneller abfangen. Schwieriger ist es manchmal bei, gerade bei News Publisher, wenn wir sehen, dass in der Regel diese News Artikel sich gar nicht verändern im Laufe der Zeit und nur einzelne diese Artikel quasi durch solche Live Updates immer wieder aktualisiert werden, dann ist es schwierig für uns abzuschätzen, wie häufig müssen wir einzelne Seiten neu crawlen. Es macht ja wenig Sinn, dass wir alle News Artikel, sag ich mal im 10 Minuten Tag neu crawlen, aber irgendwie müssen wir erkennen können, dass diese einzelnen Artikel doch Updates haben, die relevant sind. Aber ich würde das gerne mit dem Team mal anschauen, wenn du mir einige Beispiel-Urails mal schicken könntest, wenn du siehst, dass so etwas gerade am Laufen ist. Eine Frage dazu noch, welche Möglichkeit spielen wir mit L-Renames? Wir sehen das bei Publisher, was die das immer wieder machen, in eine neue URL geben, dann als neue Seite eintragen. Ist das Bad Behavior? Ich glaube bei Google News sehen sie das nicht so gern. Ich weiß, ich bin jetzt nicht 100% sicher, aber meines Wissens ist das gerade bei Google News, ist das etwas, was dagegen die Publisher-Richtlinien da verstößt. Weil das macht es uns so schwierig, um die einzelnen URLs im bestimmten Datum zuzuordnen. Von dem her würde ich davon herabsehen. Ich weiß, einige machen das so. Teilweise könnte man meinen, dass sie das machen, weil sie das irgendwie so gamen können. Teilweise sehe ich aber auch, dass das irgendwie auszusehen gemacht wird, dass man einen Schreibfehler in der URL korrigiert, noch einmal ist man damit zwei Beiträgen für den gleichen Schrift dabei. Ich würde gerade bezüglich Google News einfach mal kontrollieren in den Richtlinien dafür, ob das okay ist von Google News Seite. Das weiß ich jetzt nicht auswendig. Danke. Wir stellen Website RB-Tests über einen JavaScript-Weiche um unseren Kunden verschiedene Versionen zu zeigen. Google Word kann alles auf der Seite sein, denn wir denken, Transparenz ist hier der richtige Weg, stimmt das so oder ist der Content dadurch unstabil zu unterschiedlich für Google Word? So ich das verstehe, ist das die gleiche URL und die Inhalte werden einfach ausgetauscht. Aus meiner Sicht ist es okay so, dass Google Word die beiden Varianten sehen kann. Ich könnte mir vorstellen, dass je nachdem wie unterschiedlich das ist, dass es ein bisschen verwirrend ist für uns. Vielleicht ist es auch verwirrend für Benutzer. Was ich gesehen habe, was einige machen, ist, dass sie mit einem Art Cookie arbeiten oder dass sie die Benutzer über eine bestimmte Herrschfunktion einer dieser Varianten zuweisen. So dass wenn der Benutzer wieder auf diese Seite kommt, dass der Benutzer dann wieder die gleiche Variante sieht. Das kann Google Word auch machen, wenn man damit eine Herrschfunktion zum Beispiel arbeitet. Cookie hingegen würde da nicht funktionieren, weil Google Word die Cookies nicht zurück spielt. Aber wenn man zum Beispiel über, ich weiß nicht, ein Herrsch der IP-Adresse oder irgendetwas macht, dann könnte ich mir vorstellen, dass es einigermaßen funktionieren könnte. Aber auch wenn wir immer da kein großes Problem. Gibt es eine Möglichkeit mit Analytics den korrekten Anteil Desktop Mobile Tablet User zu sehen? Die gängigen Adblocker, der Browser verzehren das Bild ja leider zugunsten Mobile. Keine Ahnung, weiß ich jetzt nicht, wie das in Analytics gemacht wird. Ich weiß, einige Registrieren zum Beispiel diejenigen, die mit dem Adblocker arbeiten auch separat oder diejenigen, die Analytics blockieren separat. So dass man da, über ein Umweg das Gesamtbild noch anschauen kann. Ich glaube in Analytics selber sieht man das ja nicht, weil wenn zum Beispiel der Google Analytics Script blockiert wird, dann können wir ja da über Analytics gar nichts locken. Von dem her ist das ein bisschen schwierig, aber wenn ihr die zum Beispiel separat lockt, dann seht ihr ja einigermaßen auch, wie viel mit einem blockierten Google Analytics arbeiten, wie viel über Analytics kommen. Vielleicht kann man da auch die User Agents separat ablocken und das so entsprechend dann auch einzeln sehen. Aber ich vermute, wenn Analytics dann kann Analytics das selber gar nicht wissen. Ich habe gesehen, dass Googlebot Search Console mittlerweile mit dem Canonical sehr strikt umgeht. Ich habe bei der ersten Indexierungsphase, circa drei Monate her einige Canonicals falsch gesetzt, gleich repariert. Einige wurden erkannt und sind indexiert, andere, aber in der neuen Search Console nach wie vor als Alternative Seite mit richtigem Tag gekennzeichnet plus Datum der ersten Indexierung. Scheint als wenn Googlebot daher diese Urals gar nicht mehr neu crawlt und somit die korrigierten Canonical nicht automatisch erkennt. Habe nun einige diese Urals manuell gesendet mit der neuen Search Console. Echt mühsam. Wäre wohl ein bulkfunktion praktisch. Ist das so gewalt oder wie kann ich sich erstellen, dass diese Urals selbstständig findet und indexiert. Teilweise ist das sicher so gewollt, also gewollt weiß ich nicht ob gewollt, aber auf jeden Fall ist es so geplant. Weil wir sehen ja sehr viele Urals im Internet und wir müssen diese Urals einigermaßen einteilen in verschiedene Kategorien sage ich mal, um festzustellen wie häufig wir diese Seiten neu crawlen müssen. Das heißt es macht ja nicht Sinn, dass wir jede Seite im Internet täglich neu anschauen. Das würde die meisten Server überlasten gerade bei einer größeren Website und dementsprechend ist es so, dass wir die Seiten grob einteilen in verschiedene Zeiten wie häufig wir die neu crawlen müssen. Und vielleicht mal die größte Kategorie die am längsten ist in einzelnen Recrawls ist, glaube ich, etwa ein halbes Jahr. Das heißt, Urals die wir mal gesehen haben, wo wir wissen oder wo wir vermuten, dass sie sich sehr selten verändern, die schauen wir vielleicht einmal im halben Jahr nochmal neu an. Einfach um sicher zu sein, dass wir ihnen da nichts verpasst haben. Und Urals die, wo wir das Gefühl haben da könnten jetzt häufiger Änderungen vorkommen, die schauen wir dann halt häufiger an. Das wir sagen täglich oder vielleicht sogar stündlich und das wir die einfach wirklich regelmäßig neu crawlen. Und dementsprechend kann es schon sein, dass wenn etwas vor einigen Monaten gecrawlt wurde und ihr das inzwischen verändert habt, dass wir das noch nicht neu gecrawlt haben. Das ist eigentlich einigermaßen im normalen Bereich. Was man da machen kann, einerseits man kann warten, das ist vielleicht die einfachste Variante, andererseits man kann mit einer Sidemap Datei arbeiten und in der Sidemap Datei könnt ihr einen Änderungsdatum angeben für diese Seiten. Das ist eigentlich so gedacht wie, sag ich mal, dieser Bulkfunktion zum URLs einreichen. Mit dem Änderungsdatum wissen wir, wann sie verändert worden sind. Wichtig ist, dass man mit dem Änderungsdatum einfach sauber umgeht. Nicht, dass man immer sagt meine Sidemap Datei, alle Seiten innerhalb meiner Website wurden immer geändert, weil ich habe vielleicht ein PHP-Script, welches meine Seiten zusammestellt und unten wird das Datum immer ausgetauscht. Deshalb sind alle meine Seiten heute verändert worden. Das hilft uns nicht wahnsinnig viel, weil die Hauptinhalte auf diesen Seiten haben sich ja nicht verändert. Und dementsprechend lernen unsere Systeme dann im solchen Fall erstmal gut das Änderungsdatum in dieses Sidemap Datei ist nicht wahnsinnig hilfreich. Und dann nehmen wir die Sidemap Datei um neue URLs zu finden, aber sie wird dann weniger verwendet um bestehende URLs neu zu crawlen. Von dem her ist es wichtig, dass in der Sidemap Datei das Änderungsdatum einigermaßen korrekt ist, damit wir dem auch wirklich trauen können. Und das ist eigentlich egal, welche Art von Veränderung ihr auf diesen Seiten macht, ob das mit dem Canonical ist, ob das Titel sind, ob das ein Description ist, was ihr verändert habt, ob das die Inhalte selber sind, die auf diesen Seiten. Mit dem Änderungsdatum könnt ihr uns das an und für sich ein bisschen bekannt geben. Es ist auch trotz Sidemap Datei nicht so, dass wir dann garantiert losgehen und all diese Seiten neu crawlen, sondern wir versuchen, da das Crawling auf eine Menge zu beschränken, die bei euch gleich mal den Server nicht verlangsamt, welches kein Problem auf eurer Seite verursacht und das kann schon sein, dass ihr uns 100.000 Seiten gibt und sagt, die wurden jetzt alle verändert und wir schauen dann vielleicht erst mal 10.000 oder 1.000 diese Seiten an und im Laufe der Zeit versuchen wir das dann entsprechend abzubauen und durchzuarbeiten. Ich hätte da eine Frage zum Ranking. Du hast ja gesagt, dass es bis zu einem halben Jahr dauern kann, bis URLs noch mal gecrawlt werden. Ist das auch der Zusammenhang warum eine Seite dann auch langsam steigt also dann praktisch bis zu einem halben Jahr steigen könnte? Je nachdem, wie viel ihr crawlt und wenn Google erkennt, die Qualität ist besser geworden und bei mir steigt es zum Beispiel jetzt im Moment langsam seit dem letzten Update wahrscheinlich, weil jetzt gecrawlt wird erstmal. Normalerweise ist das Crawling eher, sag ich mal eine technische Sache auf unserer Seite. Es ist nicht so, dass wir sagen würden, dass was häufiger gecrawlt wird ist von höherer Qualität oder müsste vom Ranking her höher gestellt werden. Das heißt, oft ist es so, dass wenn wir sagen, dass eine Seite wichtig ist, dann crawlen wir sie auch ein bisschen häufiger, aber es umgekehrt ist nicht wahr. Das heißt, wenn wir etwas häufiger crawlen, heißt nicht, dass unsere Systeme denken, dass das jetzt eine wichtigere Position ist, sondern wir denken dann vielleicht einfach, da gibt es häufigere Veränderungen, also müssen wir diese Veränderungen irgendwie aufnehmen können und dann, wenn jemand gezielt danach sucht und wir das im Ranking zeigen können, zeigen wir das halt so. Okay, dann hätte ich noch eine Frage zum Ranking. Also ich habe so ein bisschen Keyword, kann die Ballisierung bei uns auf der Seite zum Beispiel Paris Flagge erscheint bei uns jetzt auf der Position 16 und jetzt ist es so, dass auf dieser Position 16 unterschiedliche UALs erscheinen. Also die haben, klar, die haben alle irgendwie was mit Paris Flagge zu tun. Was passiert da konkret? Also wenn jetzt auf einer Position sagen wir mal bis zu fünf UALs ausgespielt werden, was passiert bei Google in dem Moment, wenn das gemacht wird. Also wie meinst du, dass da unterschiedliche URLs... Also zum Beispiel die Größen, eine Größe für die Paris Flagge 20 mal 30, 90 mal 150 und jetzt habe ich halt gesehen, dass auf der Position 16 unterschiedliche, also unterschiedliche Seiten ausgespielt werden, aber die Position bleibt gleich. Also das Ranking ist gleich, aber verschiedene Seiten. Also was passiert da konkret? Was passiert da? Schwierig zu sagen. Ich denke einerseits wenn das so Position 16 oder so ist, dann ist es in einem Bereich, wo die Konkurrenz wahrscheinlich weniger stark ist. Das heißt, innerhalb eurer Website sehen wir wahrscheinlich, dass da verschiedene Seiten einigermaßen gleichwertig sind, die wir vom Ranking her zeigen können. Und dann ist es einfach eine Frage von unseren Algorithmen, wie ich jetzt die Texte auf diesen Seiten quasi gewertet werden. Und das kann durchaus sein, dass es quasi plus minus eins oder so bei der Gesamtbewertung gibt und das tauscht an die, das Ranking von diesen Seiten und wenn man nur eine URL von eurer Website nehmen, dann kann es durchaus sein, dass da so verschiedene URLs der Website quasi ausgetauscht werden für den gleichen Ranking-Punkt. Also rankt dann die Domain für dieses Keyboard? Nein, wir denken einfach innerhalb eurer Website sind diese Seiten mehr oder weniger gleichwertig und dann ist es eher eine Frage passt vom der Rundungsfehler oder so etwas bei der genauen Berechnung vom Ranking für diese Seiten. Okay, okay, alles klar, Dankeschön. Ich hätte auch noch eine Frage, wenn du erlaubst. Du hast eben gesagt gehabt, dass wenn man etwa bei ja fehlerhaft Zeitangaben macht oder immer wieder behauptet man hätte was geändert, aber es hat sich nichts geändert, würdet ihr nicht mehr auf diese Angaben vertrauen? Haben denn Website-Metreiber überhaupt eine Möglichkeit, das Vertrauen wieder zu erlangen? Also ist man da gezwungen als Website-Metreiber so lange wieder sauber zu arbeiten und zu warten bis irgendwann, dann ihr nach nach einer gewissen Zeit sagt, okay jetzt hat er sich drei Monate lang brav verhalten jetzt glauben wir ihn wieder also gibt es da so eine Zeitspanne oder kannst du dazu was sagen? So wie ich das in Erinnerung habe ist das wirklich von mal zu mal wenn wir die Seitenabdatei einlesen. Das heißt was wir einfach gesehen haben ist gerade bei so dynamischem Website wenn man das Änderungsdatum von einzelnen URLs anschaut, wird hier immer das aktuelle Datum zurückgegeben und einige Sitemap Generators haben das dann auch so quasi weiterverwendet. Das heißt wenn wir die Sitemap-Datei aufrufen, dann ist das Änderungsdatum überall genau das gleiche oder sag ich mal innerhalb von wenigen Minuten alles das gleiche und das ist für uns dann einfach ein Zeichen, dass wir diesen Datungsangaben nicht trauen können. Wenn wir beim nächsten aufrufen das Sitemap-Datei sehen, dass das Änderungsdatum ist nicht für jedes diese Seiten das gleiche, dann ist es für uns eigentlich ein Zeichen, dass irgendwas steckt dahinter also können wir dem wahrscheinlich eher trauen. Also es ist nicht so, dass ein gewisse Zeitspanne geht bis wir das Sitemap wieder trauen können, sondern es ist eigentlich da ist ein brauchbares Datum dabei oder das sind überhaupt keine brauchbare Daten dabei. Ich verstehe, also die Daten selbst zeigen euch inwieweit man der Datei vertrauen kann oder nicht oder den Angaben. Genau, genau. Danke. Dann mal schauen im Chat, da noch eine Frage zu 410 gone, ob man das nicht auch verwenden sollte ja bei uns ist es so, dass intern wird 410 ein bisschen schneller verarbeitet als 404, das heißt mit 404 sagt man quasi im Moment sind die Inhalte nicht da und mit 410 sagt man die Inhalte sind definitiv weg. Das heißt es ist dann nicht mal eine Frage von, ist das jetzt temporär, ist das ein kurzer Serverfehler oder nicht, sondern man sagt jetzt wirklich weg die Inhalte. Vom Praktischen her ist es so, dass wir URLs oft vielleicht ein, zwei Mal noch zusätzlich crawlen, wenn 404 dabei ist einfach damit wir sicher sind, dass diese Seite wirklich nicht mehr existiert und mit 410 können wir das überspringen und ein bisschen schneller verarbeiten. Von dem her geht das ein bisschen schneller mit 410 aber praktisch gesehen ist es eigentlich leicht sich das fast auf. Das heißt im großen Ganzen ist es nicht so, dass man irgendwie ein Ranking-Vorteil hat, wenn man mit 410 arbeitet sie verschwindet ein bisschen schneller, aber meistens ist es dann eine Frage von ein paar Tagen früher oder später. Das heißt in den meisten Fällen lohnt es sich nicht, dass man 410 gezielt noch irgendwie einbindet in der Webseite und sagt statt 404 muss man jetzt 410 zurückgeben, sondern in der Regel ist es etwa gleichwertig. Wenn man genau schaut dann sieht man schon diesen leichten Unterschied aber das ist, würde ich sagen bei den meisten Webseiten ist das nicht so kritisch. Mal schauen was haben wir da noch. Welche Chrome Version nutzt denn das Fetch as Google Tool in Search Console? Gute Frage. Hoffentlich kommen da jetzt bald Updates dazu bisher ist es so, dass die Fetch as Google und Inspektual und ein von den Structured Data Testing Tools alles noch die ältere Version von Chrome verwendet hat für das Rendering und wir hoffen, dass wir bald eigentlich auch die Version umstellen können, die wir normal von Crawling und Indexierung verwenden. Das heißt, dass man das auch wirklich sauber testen kann. Natürlich geht das nicht mehr all zu lang. Ich weiß, das Team hat da schon eigentlich das schon fast bereit gehabt seit einiger Zeit. Ich weiß nicht genau, was da noch klemmt. Aber hoffentlich geht das nicht mehr lange. Wir haben in NL und BE Shops die technisch sauber voneinander getrennt sind. Canonicals and Atract Langtags sind sauber implementiert. Es kommt jedoch vor, dass Google plötzlich die NL-Urals als Canonical nimmt und BE als Duplicat bewertet. Nach zwei bis drei Monaten greifen wieder die Canonicals und Atract Langtags und alles wie es wieder in Ordnung. Das Gleiche passiert auch mit IE und UK Domains. Was löst das aus? Beziehungsweise, wie kann man so eine Fehlinterpretation vermeiden? Ja, es ist immer ein bisschen kompliziert. Wenn man, also grundsätzlich ist, dass wir denken, dass diese Varianten gleichwertig sind. Das heißt, wenn die Texte zum Beispiel gleich sind auf diesen Seiten, denken wir, dass wir da ein Canonical auswählen können. Weil das ist ja eigentlich ähnlich wie wenn man sonst irgendwie Duplicate auf der Website hat. Wenn ich zum Beispiel zwei deutsche Texte habe einmal für Deutschland, einmal für Österreich und das sind genau die gleichen Texte, dann könnte man die ja eigentlich zusammenklappen in dem Fall indexieren. Was dann nachträglich passiert, ist mit dem Atract Lang tauschen wir dann die URLs in den Suchergebnissen aus. Das heißt, Canonical ist dann eine dieser Varianten in den Suchergebnissen, könnte man aber beide sehen. Das Schwierige ist, das In-Search-Consult ist das sehr unübersichtlich, das heißt, bei den Indexierungsstatistiken sieht man das nicht, weil das ja nur die Canonical der Bahn, die Stadistiken ebenfalls, ist ja auch nur der Canonical erwähnt. Das heißt, bei der Indexierung sieht es so aus, als ob halb so viele URLs indexiert sind. Und bei der Leistung sieht es dann so aus, als ob nur die Variante für Deutschland dargestellt werden in Suchergebnissen und die andere gar nicht. Bei der Leistung kann man das selber aufteilen, indem man das pro Land anschaut, dann sieht man da schon eher, dass bei den beiden Ländern Suchergebnissen gezeigt worden sind. Mit dem H-of-Lang sollte da eigentlich auch die Richtige gezeigt werden. Also vom praktischen her sollte das trotzdem funktionieren, wo es manchmal klemmt ist, wenn zum Beispiel im Titel oder in der Beschreibung das Land erwähnt wird. Dann kann es so sein, dass wir, sagen wir mal, die österreichische URL zeigen und im Titel steht dann und das ist ein bisschen ärgerlich. Was man da machen muss, wenn man das wirklich auftrennen will, dann muss man einfach sicherstellen, dass diese Seiten für die einzelnen Länder wirklich auch unterschiedlich sind. Das heißt, damit dass unsere Systeme, die nicht irgendwie zusammenklappen können und als eine Seite indexieren können, sondern dass wir wirklich klar erkennen können, diese beiden Varianten müssen separat indexiert werden. Und dann funktioniert das auch mit den Statistiken separat. Bei den Leistungsstatistiken in Search Console sieht man das sauber separat. Bei der Indexierung sieht man das sauber. Dann sollte das eigentlich soweit klappen. Ich weiß, dass das kann man nicht überall machen, dass man da wirklich unterschiedliche Inhalte hat. Gerade wenn man Produkte Seiten hat, geht das ja nicht so wahnsinnig gut, aber zumindest bei den Hauptzeiten von einem Schaub würde ich schon in die Richtung tendieren, dass man dafür sorgt, dass die Seiten so unterschiedlich sind, dass man die wirklich nicht zusammenklappen kann. Das heißt, mehr aus einfach nur zum Beispiel die Währung wechseln oder eine Telefonnummer wechseln, sondern dass die Inhalte wirklich auch sichtbar unterschiedlich sind auf diesen Seiten. Ich hoffe, dass wir das in Search Console beziehungsweise ein bisschen besser funktioniert, gerade bei solchen Duplikaten, die über verschiedene Ländervarianten sind, aber in der gleichen Sprache. Aber das Problem besteht schon seit einiger Zeit, von dem her denke ich nicht, dass das demnächst verändert wird. Ich möchte das Shop System wechseln. Die Domains und URLs der CMS-Kategorie- und Produktzeiten bleiben gleich. Was ich nicht retten kann, sind die Bilder URLs. Grundsätzlich ändert sich das Layout, aber die Informationsstruktur bleibt fast gleich. Kannst du kurz erklären, wie der Ablauf bei Google sein wird, sollte grundsätzlich beim Start bereits alles eingerichtet sein oder kann ich auch nach und nach die weniger wichtigen Inhalte migrieren. Schritt für Schritt migrieren ist überhaupt kein Problem. Das kann man sicher machen. Das Wichtige aus meiner Sicht wirklich, dass möglichst mit den URLs, dass sich da nicht viel verändert und dass auch die grundsätzliche Struktur der Website einigermaßen gleich bleibt, dann ist das für uns viel einfacher, als wenn die URLs auch alle verändert werden. Die Bilder URLs könnte ich mir vorstellen, dass das ein bisschen schwieriger ist. Wenn möglich, würde ich schauen, dass man da irgendwie weiter Leitungen machen kann. Vor allem, wenn man über die Bildersuche viel Traffic bekommt. Wenn man über die Bildersuche sehr wenig Besucher kommt, dann kann man auch sagen, gut, es dauert halt jetzt mal ein paar Monate, bis die Bilder wieder eingependelt sind. Das ist vielleicht nicht gerade kritisch. Wenn hingegen wirklich viele über die Bildersuche kommen, würde ich da auch schauen, dass man zumindest ein Redirect dabei hat. Das Problem mit den Bilder URLs, wenn man die Alten einfach auf 404 setzt und bei der Bildersuche ist die Indexierung viel langsamer als bei der normalen Websuche. Das heißt, es geht einfach viel länger bis unsere Systeme solche Veränderungen sauber erkannt haben und auch sauber verarbeitet haben für die Bildersuche. Das heißt, wenn möglich, wenn man auf die Bildersuche achtet, würde ich auf jeden Fall Redirect einrichten, vielleicht sogar irgendwie schauen, ob man die Alten URLs beibehalten kann. Ist das Ranking irgendwelche Auswirkungen, wenn die Bilder fehlen soll, also die Altenbilder weg sind? Für das Ranking in der Websuche nicht. Okay, also also in der Bildersuche da natürlich, aber in der Websuche nicht. Ich habe noch eine Frage zu diesem Edge Refling gerade zu der Frage. Ich habe bei mir das Edge Refling aufgelöst. Ich finde, das Ranking nicht verbessert bei mir. Also zum Beispiel hatte ich ein Canonicle auf DE gehabt und dann über Edge Refling die URLs aufgelöst, in der Schweiz zum Beispiel oder in Österreich. Aber ich empfand jetzt nicht, dass es irgendwie die gleichen Position hat wie die eigentliche CH-Domain oder die AT-Domain. Kannst du das denn so bestätigen, dass hier AT und CH irgendwie fortzieht in den Eigen, also in der CH-Suchmaschine? Also es geht ja um GOIP und der Schweizer Franken ist ja auch auf der CH-Domain und wenn jetzt die DE-Domain, also der Content von der DE-Domain rankt in der Schweiz kann ich mir vorstellen, dass er das nicht so gut findet wenn jetzt da Euro steht. Die Währung spielt da weniger eine Rolle aber die Domain-Endung wird wirklich für Geotargeting verwendet. Es gibt ja 30 weniger, aber die Domain-Endung dann schon, gerade wenn ich jetzt CH oder AT habe versuchen wir dann, wenn jemand in der Schweiz sucht und wir erkennen können, dass die Suche wahrscheinlich etwas nach etwas lokalem ist, dann bevorzuholen wir schon CH-Domains dann werden die ein bisschen höher rankt. Also was jetzt im Moment passiert ist wahrscheinlich zwei Ergebnisse das Schweizer Ergebnis weiter oben das deutsche Ergebnis weiter unten ist für mich jetzt so kein Problem im Endeffekt. Ja, also wenn das für dich funktioniert kein Problem. Okay, also es muss nicht sein, dass man hreflengt benutzt und dann alles canonisiert sondern man kann es auch so lösen weil für euch ist ja Dublikate Content kein Problem wird ja oft auch gesagt und dann erscheint es einfach weiter unten. Okay, aber die Qualität leidet jetzt nicht darunter. Okay, gut. Es ist auch am Anfang als wir angefangen haben mit hrefleng hat das Engineering Team eigentlich immer wieder gesagt, dass wenn wenn jemand keine Probleme sieht mit den verschiedenen Länderversionen in Suchergebnissen dann muss man nicht mit hrefleng arbeiten. Sondern hrefleng hilft eher diese Probleme ein bisschen zu vermeiden wenn man wirklich sieht die falsche Version wird dargestellt. Aber wenn es vom Ranking her eh so ist für dich, dass die richtige Länderversion gezeigt wird dann ja haben wir sich die Mühe ersparen. Okay, danke. Okay, da noch ein großer Kommentar, gerade im Chat noch dabei ich glaube ich komme nicht dazu, das ist ja bezüglich irgendwie diesen Subdomain leasing ich werde ja jetzt irgendwie groß besprochen ich weiß jetzt nicht genau was ich da groß dazu in einer Minute noch sagen kann aber ich richte auf jeden Fall nochmal die nächsten Hangouts ein dann können wir das da beim nächsten Mal vielleicht mal kurz anschauen. Ansonsten erstmal vielen Dank fürs kommen, vielen Dank für die vielen Fragen und hoffentlich sehen wir uns in einem für den nächsten Hangouts wieder. Tschüss allerseits. Tschüss.