 Okay, herzlich willkommen zum heutigen Webmaster Essentials Sprechstunden Hangout. Mein Name ist Johannes Müller, ich bin Webmaster Trans Analyst bei Google in der Schweiz. Teil von dem, was wir machen, sind solche Webmaster Hangouts, wo Webmaster SEO Publisher zusammenkommen können und ihre Fragen oder Kommentare bezüglich der Suche bringen können. Es sind, wie eigentlich fast immer, einige Fragen eingereicht worden auf YouTube, aber falls einer von euch loslegen möchte mit einer ersten Frage, seid ihr gerne dazu eingeladen? Ja, dann hätte ich direkt schon eine Frage. Super. Ja, ich hatte das letzte Mal da schon angesprochen wegen Sitemaps, dass die bei uns nicht richtig gequart werden, also die Index-Sitemaps. Und das wolltest du ja, glaube ich, weitergeben, hast du es so gemeint? Ja. Ja, das gehe ich mal von aus, hast du auch getan? Ja. Ich habe einfach noch nichts da zurückgehört. In vielen Fällen sind das einfach so Meldungen, die wir weitergeben an das Team und die müssen das dann selber irgendwie priorisieren. Aber ja, mal schauen. Okay, ne, weil es hat sich bisher noch nichts getan, da wollte ich einfach fragen, ist es allgemein irgendwie ein bisschen, weil bei uns ist auch irgendwie der Durchlauf, das Crawlen der Seiten ein bisschen langsam möchte ich mal behaupten. Ich sage mal vor Corona, das kann jetzt noch gefühlt natürlich sein, aber vielleicht einfach, dass jetzt mehr Unternehmen sich dachten, okay, gut, wenn wir schon so nichts machen können, dass man halt mehr jetzt auf Web sich konzentriert, dass vielleicht irgendwie eine Rolle spielt oder so. Weiß ich nicht. Weiß ich nicht. Also mir wäre eigentlich nicht bewusst, dass mehr Crawlen müssten als auch schon, beziehungsweise, dass sich das irgendwie negativ auf andere Websites auswirken würde, weil die Infrastruktur ist ja eigentlich da. Und auch wenn sich das ein bisschen mehr verteilt, dann sollte das eigentlich nicht groß spürbare Veränderungen im Crawlen geben. Eine Sache fällt mir aber gerade ein, vielleicht hängt das auch damit zusammen, weil irgendwie versuchen wir halt eine Lösung zu finden. Wir haben jetzt aber auch im Zuge letztens, also vor über einem Monat die Domain gewechselt. Kann das vielleicht damit zusammenhängen, dass das heißt also, weil wir die Domain gewechselt haben, dass deswegen der Crawling-Prozess halt ein bisschen langsamer ist, weil die Domain noch nicht bekannt ist? Das kann gut sein. Was unsere Systeme machen, wenn wir feststellen können, dass die Infrastruktur sich verändert hat, das betrifft ja auch ein bisschen Domain-Namenwechsel, aber auch zum Beispiel, wenn man auf ein CDN wechselt oder wenn man allgemein das Hosting woanders hin verlagert, dann sind unsere Crawling-Systeme meistens ein bisschen zurückhaltender und crawlen erstmal ein bisschen langsamer, bis sie merken, dass sie wieder mit der vollen Geschwindigkeit crawlen können. Einfach um sicherzustellen, dass Crawling nicht noch irgendwelche anderen Probleme für Ursacht wird. Und in den meisten Fällen ist das etwas, was sich vielleicht mal im Laufe von einigen Wochen wieder einpendelt. Also wenn das jetzt vor Monat oder so war, dann kann das gut sein, dass das noch einigermaßen da in diesem Rahmen liegt. Okay, perfekt. Danke schon für die schnelle Antwort. Super. Okay, vielleicht noch irgendwelche weiteren Fragen, um das Leben mit dem, was eingereicht wurde. Nichts. Okay, vielleicht kommt ja zwischen euch noch ... Ja, hier. Hallo, John. Hallo, Michael. Hört ihr mich? Ja, war ein bisschen zerbrochen zwischen euch, aber probier mal. Hört man mich jetzt? Ja, jetzt wieder nicht mehr. Okay, also ich glaube, ich muss das Video weggeschalten so, weil die Verbindung unterbricht immer wieder. Aber ich stelle meine Frage, falls ihr die hören könnt, bitte beantworten. Und zwar gibt es so etwas wie eine Master-Search-Konsole von Google, wo man reingehen kann, dass man reinkommt und mal wirklich alle Funktionen sieht. Bei Google Analytics gibt es sowas. Nein. Im Moment zumindest nicht. Wir haben das mal ein bisschen untersucht, um schauen, ob man da so etwas zusammenstellen könnte. Vielleicht auch mit dem gleichen Setup wie bei Analytics. Ich glaube, das ist der Google Merchandise Shop. Genau. Und wir haben aber gesehen, dass es nicht so einfach ist, wie wir uns das vorgestellt haben. Insbesondere, wenn man die verschiedenen Funktionen verwenden möchte, sind ja viele dieser Funktionen hängen davon ab, welche Funktionalität auf der Website vorhanden ist. Das heißt, die verschiedenen Rich-Results-Typen, AMP-Seiten oder nicht, das hängt ja alles sehr davon ab, was auf diesen Seiten effektiv veröffentlicht wird. Und da ist es schwierig, etwas zu finden, was einigermaßen natürlich ist, wo wirklich all diese verschiedenen Varianten vorhanden sind. Und wenn man das ganz künstlich erstellen würde, solche Daten, dann wäre das einfach vom Aufwand her ein bisschen zu groß. Okay. Aber ich weiß, das ist ein Thema, das immer wieder aufkommt, wo wir auch intern versuchen, da Möglichkeiten zu finden. Gerade wenn man ja ganz neu anfängt, dann hat man erstmal keine Daten in Search Console, geht es ein paar Tage, bis man das hat. Und es wäre ja praktisch, wenn man einfach ein bisschen rumklicken könnte und sehen könnte, wie wäre das, jetzt schon mal ein bisschen etablierter wäre, was für Daten könnte man da sein? Okay. Dann die nächste Geschichte, die ich noch fragen wollte, ist bei dem Webmaster-Tool sehen wir in den alten Entitäten immer wieder, also bei htdp oder nicht, dass da noch einiges immer wieder los ist, obwohl seit, sage ich mal, zwei Jahren die redirects sauber gesetzt sind. Gibt es hier eine Empfehlung von dir, wie man das verstärken könnte, dass hier mal der Stall sauber wird, sage ich mal so? Das kann es geben, aber normalerweise betrifft das eher einfach kleine Bereiche innerhalb einer Webseite. Und es ist nicht so, dass man das manuell forcieren müsste. Man kann zum Beispiel auch nicht mit dem Entfernungstool da arbeiten, das werden ja dann alle Varianten rausgenommen. Und von dem her, wir helfen einfach die redirects im Platz und macht da eigentlich so weiter wie vorher. Okay, also in dem Fall heißt deine Empfehlung abwarten und so eine XML-Seitmap hochzuladen, wo die alten htdps drinnen wären und damit Google anzuregen, die zu lesen. Ich glaube, das kann es sein. Ich denke gerade, wenn das schon, also wenn man jetzt ganz frisch stehen, ein weiter Leitung einrichtet, dann macht das sicherlich. Aber wenn das jetzt schon einige Monate zurückliegt, dann würde ich das nicht mehr machen. Und wenn das ein paar Jahre zurückliegt, dann ist das recht nicht. Okay. Und jetzt meine dritte und letzte Frage. Dank an alle, die mich da noch lassen ist. Eine alte Geschichte, die wir immer wieder aufwärmen, das Hotelstadt München, sage ich mal in Leipzig, dass ihr da ein bisschen Ranking-Probleme hat. Gibt es hier irgendwas Neues, eine Veränderung, irgendeine Verbesserung, die du uns empfehlen würdest, die man hier angehen sollte, sage ich jetzt mal, wie Maschinenlisbare Daten etc.? An und für sich sind da die üblichen Empfehlungen, die man machen könnte. Also, dass man zum Beispiel ein Google My Business-Seite hat, dass man die Adressen mit strukturierten Daten angibt. Aber ich könnte mir vorstellen, dass das eigentlich immer wieder ein Problem sein wird. Weil wenn wir den Namen anschauen, könnte man meinen, das ist Stadt München. Wenn wir den Standort anschauen, dann ist es klar, dass es an einer bestimmten Stelle, was wahrscheinlich nicht verschwinden wird, wäre so Rankings wie Hotel München. Ist ja, glaube ich, bei dir in der Frage auch dabei gewesen. Was wahrscheinlich besser funktionieren sollte im Laufe der Zeit, ist, wenn man jetzt Hotel Leipzig zum Beispiel sucht, dass das trotzdem kaum. Also, da können wir ja dann erkennen, Leipzig ist der Ort, wo dieses Hotel im Moment ist und es ist ein Hotel, also würde das dazu passen. Aber es ist nicht so, dass bei Hotel München, dass das dann verschwinden würde, weil das ist ja schon fast eine Suche nach dem Namen und dann macht es ja trotzdem Sinn, das irgendwie zu zeigen. Ist das etwas, was öfters vorkommt, dass das so Hotels nach anderen Orten genannt werden? Ja, leider Gottes. Wir in Österreich haben ja wahnsinnig viel Tourismus und da heißen dann oft halt das Hotel Tirol. Das gibt es in, glaube ich, in jedem Ort, in Österreich und so weiter. Also, da gibt es viele solche, und ich sage auch mal nicht nur österreichische Namen, dann auch weiß ich nicht, Hotel Tirol und so. Also, das ist wirklich, das ist halt gewachsen so, dass die das halt früher genannt haben. Das kommt ja noch aus Zeiten, wo es noch kein Online-Markt und kein Google gab. Ja, okay. Aber das sind ja dann eher regional. Ja, okay. Ich schau das mal mit dem Team an. Das ist ein anderes Protagon, um das hier geht. Okay, okay. Wenn du mir die genauen Beispiele mal zuschicken könntest, dann kann ich das direkt auf dem Team mal anschauen. Okay. Ja, guck ich da mal an. Ach, ich gerne, ja. Super. Dankeschön. Okay. Gut, irgendwelche weiteren Fragen bevor wir loslegen. Sonst lese ich mal der Reihe nach. Ich glaube, die ersten waren eh von dir, Michael, die haben wir jetzt gemacht. Ich habe gestern eine Seite im Google Mobile Friendly Test getestet und sie wird als nicht für Mobilgeräte optimiert deklariert. Wenn ich mir die Details anschaue, dann wird mir angezeigt, dass Style Sheets, JavaScript-Dateien an ein paar Bilder nicht geladen werden konnten. Die Dateien sind nicht blockiert. Und wenn ich die Seite am Smartphone betrachte, funktioniert auch alles, hat dies von eurer Seite Auswirkungen auf die Seite? Oder ist das nur ein Fehler im Mobile Friendly Test? Und wie kann ich solche Fehler beheben? Ja, ich denke, was versteht dann auch in Support Form, wo der ähnliche Frage mit der Test hat Probleme und ist nicht einfach so beantwortet. Ja, ich denke, dass es immer, gerade mit dem Mobile Friendly Test, ist das immer ein bisschen schwierige Situation. Ich weiß, das sind unsere Teams auch daran, das ein bisschen zu verbessern. Normalerweise ist es so mit dem Live Test, dass es da schon eher dem entspricht, was wir sehen, wenn wir die Seite versuchen zu renderen. Schwieriger ist es mit dem Mobile Friendly Information in Search Console, wo die einzelnen Seiten dargestellt werden. Da kann es durchaus sein, dass wir zum Beispiel temporär die Seite nicht laden konnten. Und dann zeigen wir die Seiten in Search Console. Wenn man sie dann einzeln testet mit dem Testing Tool, dann sind sie okay. Und in solchen Fällen, wenn das mit dem Testing Tool okay ist, muss man sich da eigentlich nicht groß sorgen. Ich glaube, in diesem Fall ist es so, dass auch im Testing Tool sie nicht ganz okay sind. Und normalerweise hängt das gerade, gerade jetzt eben in solchen Fällen damit zusammen, dass wir die Seiten einfach nicht rechtzeitig renderen können. Das ist irgendeinem Grund, dass da vielleicht zu viele Ressourcen verwendet werden, die da eingebunden werden in diesen einzelnen Seiten, die alle geladen werden müssen, dass unter Umständen einige Ressourcen auf einem Server geladen sind, wo wir nicht so schnell crawlen können. Das heißt, wenn man die Seite dann testet, im Live Test, wird da einfach alles nicht in der richtigen Zeit machbar sein von unserem Testsystem her. Und deswegen melden wir das dann als unter Umständen nicht mobile-friendly. In vielen Fällen ist es so, dass wir für unsere internen Bewertung für das Ranking ist es ja so, dass wir da mehr Zeit haben. Wir können die Seiten ein bisschen in Ruhe renderen lassen. Wir können die gecacheden Ressourcen verwenden, statt alles live abzurufen. Und da pendelt sich das dann schon wieder ein, dass wir die Seite normal auch für die Indexierung und für das Ranking als mobile-friendly sehen würden. Was ich einfach machen würde, wenn das im Test regelmäßig nicht klappt, würde ich versuchen, mit zum Beispiel Webpage Test.org die Seiten auch zu laden und zu sehen, wo gibt es vielleicht Bereiche, wo man eine Optimierung machen kann. Bezüglich gerade die Anzahlressourcen, die gebraucht werden zum Laden. Bezüglich der Ladezeit von den einzelnen Ressourcen. Vielleicht ist es zum Beispiel möglich, die Bilder auf ein CDN zu nehmen, damit sie viel schneller geladen werden können. All solche Optimierungen kann man da machen. Und die sieht man relativ gut in diesem Wasserfall-Diagramm in WebpageTest.org. Ich weiß, die Seite ist jetzt da angegeben. Ich habe sie noch nicht direkt dort getestet. Ich hoffe, da sieht man wirklich was in WebpageTest.org. Aber normalerweise in solchen Situationen sieht man da schon, dass da vielleicht hunderte von Ressourcen geladen werden und dass vielleicht einzelne Sachen ein bisschen länger brauchen zum Laden. Wir haben unsere Webseiten komplett in AMP programmiert. Bei LiveTest in Search Console erscheint die Nachricht der JavaScript-Konsole bei allen Seiten folgende Fehler. ServiceWorker Registration failed. In Lighthouse bestehen alle Seiten alle PBR Checks und auch bei Test mit den Chrome DevTool oder LiveTests im Internet arbeiten die ServiceWorker scheinbar korrekt. Was sagt dieser Fehler zu bedeuten? Es ist so, dass für das Rendering verwendet keine ServiceWorker. Das heißt, soweit ich weiß, ist die Funktion einfach wie ausgeklammert beim Rendering. Und der Grund dafür ist eigentlich, dass wir die Seiten versuchen, so zu laden, wie sie komplett neu wären. Das heißt, wie wenn wir sie zum ersten Mal sehen würden, ohne irgendwelche Session-Cookies oder Side-Cookies da zu verwenden und dementsprechend macht es auch wenig Sinn, dass man ServiceWorker beibehält, der quasi im Hintergrund immer läuft. Und deswegen verwenden wir da gar keine ServiceWorker. Worauf man da einfach achten müsste bei Websites ist, dass man nicht vom ServiceWorker abhängig ist. Das heißt, dass die Seiten trotzdem funktionieren würden, wenn der ServiceWorker nicht verwendet wird. In der Regel ist das kein Problem. In der Regel ist es so, dass der ServiceWorker eher dazu dient, quasi für den nächsten Aufruf alles vorzubereiten. Das heißt, dass Sachen gecached werden, vielleicht für Offline-Zuriff noch bereitgestellt werden. Aber es ist nicht so, dass eine Website den ServiceWorker braucht, um die ursprünglichen Inhalte darzustellen. Und wenn das so ist, dann ist das eigentlich total okay. Dann kann man diesen Fehler in Search Console an und für sich ignorieren. Wenn hingegen man die Inhalte gar nicht sehen kann, wenn man den ServiceWorker nicht verwendet, dann wäre das etwas, was man verändern müsste. Dann kann man das einigermaßen testen mit dem Inspect URL Tool in Search Console. Kann man ja einzelne URLs eingeben oben und die dann testen lassen und renderen lassen. Und das sieht man dann sehr schnell. Sind die vollen Inhalte da oder sind sie nicht da? Wenn sie nicht da sind, kann man dann auch bei der Fehlerkonsole dort nachschauen, was klemmt oder wo könnte man vielleicht etwas optimieren, quasi optional betrachtet wird, statt dass es notwendig ist für das Laden dieser einzelnen Seiten. Weil im Grunde genommen, ServiceWorkers finde ich eine tolle Technologie, da kann man sehr viel machen für Benutzer, gerade bezüglich Offlinezugriff und in den meisten Fällen funktioniert das problemlos auch für die Suche. Wir haben circa 6000 Produktzeiten die ausschließlich in AMP programmiert und als Produktstruktur ausgezeichnet sind, diese sind seit 2 Jahren alle komplett und konstant indexiert. Trotzdem nehmen in den letzten Monaten die gültig angezeigten AMP-Zeiten auf zuletzt 1600 und die gültig angezeigten Produkte auf zuletzt 1100 ab. Es werden keine Fehler ausgewiesen. Was könnte der Grund sein? Das hängt davon, dass in Search Console bei den ganzen Aggregatsberichten ist es so, dass wir ein Teil der Website betrachten. Das heißt, wir nehmen ein sample von den relevanten Seiten dieser Website und testen die dann bezüglich diesen Fehlern und Elementen, ob es da vielleicht Optimierungsmöglichkeiten gibt, ob es Warnungen oder Fehler noch dazu gibt und zeigen das dann an dort in Search Console. Das heißt, wenn man zu diesen Berichten hineingeht und 1000 Seiten zum Beispiel sieht und die werden alle als gültig anerkannt, dann kann man davon ausgehen, dass eigentlich die gesamte Website als gültig gesehen wird. Um die Gesamtzahl der indexierten Seiten zu sehen, würde ich dann eher mit dem Index Coverage Report arbeiten, statt mit den einzelnen Aggregatsberichten für diese einzelnen Teilbereiche der Website. Von dem her, wenn das sauber dort dargestellt wird, wenn es keine Fehler gibt oder verhältnismäßig wenig Fehler gibt, dann würde ich davon ausgehen, dass der Rest der Website ähnlich betrachtet wird. Eine Frage zur hreflang Steuerung. Bei Online Shop es gibt 8 hreflang Varianten plus ein X-Default die englische Seite. Auf die X-Default Seite sind aber nicht alle Produkte oder Kategorien vorhanden. Manche Produkte gibt es nur für Deutschland. In Ordnung, bei solchen Seiten X-Default hreflang wegzulassen. Was wäre Best Case in diesem Fall? Natürlich kann man das machen, wie man will. Mit dem hreflang kann man einzelne Seiten verknüpfen. Das ist dann auf Seitenebene gemacht. Das heißt, man muss nicht die ganze Website so verknüpfen. Und das ist durchaus legitim, dass man sagt, jetzt mal 5 Varianten, andere Seiten haben 8 Varianten. Das kann man machen, wie man will. Und mit dem X-Default kann man ebenfalls angeben, was man da als Default-Version haben möchte. Es kann zum Beispiel auch sein, dass es einzelne Produkte in Deutschland gibt. In anderen Ländern gibt es sie vielleicht nicht. Das heißt, dass man auf eine 404 Seite verweist. Das macht wahrscheinlich wenig Sinn, aber zumindest auf eine Seite verweist, wo dann steht, dieses Produkt ist nicht verfügbar. Oder, dass man sagt, man hat nur die deutsche Variante quasi indexiert auf der Website. Es kann auch sein, dass man Informationseiten hat, die leicht unterschiedlich sind. Zum Beispiel, wenn ich Information über den Standort in Deutschland und den Standort vielleicht in Österreich habe, dann sind ja da unterschiedliche Adressen, die auf der Website unterschiedliche Informationen dabei. Das sind alles Varianten, die kann man mit dem hreflang machen. Dass man da wirklich auf Seitenebene arbeitet und sich überlegt, welche Seiten sind equivalent, die aber in anderen Ländern so unterschiedlich dargestellt werden sollten. Das andere, worauf man da immer ein bisschen achten muss, ist, dass hreflang nicht ein absolutes Mittel ist. Es ist immer diese Variante in diesen Ländern oder diesen Sprachvarianten gezeigt wird. Das heißt, es lohnt sich eigentlich fast immer, dass man noch ein Backup hat auf der eigenen Website. Dass man da zum Beispiel testen kann, ist der Benutzer wahrscheinlich auf der richtigen Version oder wahrscheinlich auf der falschen Version. Und wenn der Benutzer auf der falschen Version ist, dann kann man zum Beispiel testen, wie es hier ist. Vielleicht wäre das jetzt relevanter für euch. Das sind so die Sachen, wo man ein bisschen achten kann. Und anführer sich, gerade mit dem hreflang kann man da das wirklich auf Seitenebene einfach mal ausprobieren und testen, was funktioniert, wo macht Sinn, wo ist es vielleicht auch weniger kritisch. Weil in vielen Fällen ist es ja so, dass wenn jemand die Sprache schon besucht, dann wird zum Beispiel auch allgemein in der Sprache schon besucht, dann finden wir eh die richtige Seite. Das heißt, es ist nicht immer 100%ig notwendig, dass man die Produkte-Seiten alle mit hreflang verknüpft und die Startseiten auch, sondern vielleicht macht es Sinn, dass man einfach nur die Startseiten erst mal verknüpft und dann in einem zweiten Schritt überlegt, wie kann man diese eine Sprächstunde sagen, dass Google versucht, White Label-Seiten zu erkennen und sie in Zukunft unabhängig von der übergeordneten Domain zu bewerten. Seitdem ist in den Ergebnissen nichts passiert. Sieben der Ergebnisse für Zalando-Gutscheins sind White Label-Sites. Neue sind mega erfolgreich. Hat sich Google's Einschätzung dieser Strategie verändert. Wir versuchen einzuschätzen, wie riskant diese Strategie ist und wie die Kosten bei der Übernahme einer bereits gut funktionierenden Subdomain und wären für deine Antwort sehr dankbar. Ich würde mal sagen, es hat sich nichts getan, weil da haben wir schon einige Sachen gemacht, um das ein bisschen besser einzuschätzen. Ich denke, es gibt immer zwei Varianten, gerade bei solchen Situationen. Einerseits macht es natürlich Sinn, diese Websites möglichst unabhängig anzuschauen. Andererseits sind es auch normale Websites, die normal gut in den Suchergebnissen dargestellt werden können. Es ist nicht so, dass wenn wir zum Beispiel erkennen können, dass das jetzt ein Unterteil einer bestehenden Website ist, dass wir sagen würden, wir zeigen die gar nicht in den Suchergebnissen an. Von dem her ist schwierig zu sagen, dass man das nicht empfehlen würde. Ich denke, das muss man selber ein bisschen einschätzen, wie weit macht es Sinn, dass man mit anderen Websites zusammenarbeitet und wie weit macht es Sinn, dass man vielleicht etwas Eigenes aufbaut, dass man dann längerfristig beibehalten kann und welches diese beiden Strategien quasi kurzfristig und längerfristig erfolgreicher sein wird. Das kann ich nicht wirklich hundertprozentig einschätzen. Das ist ein Thema, das ab und zu aufkommt auf unserer Seite und wo unsere Ranking-Teams auch regelmäßig daran arbeiten, damit das sauberer läuft. Werden ein PDF und eine HTML-Seite mit identischem Inhalt als duplicate Content betrachtet? Das ist immer eine interessante Frage. In erster Linie ist es nicht duplicate content, die Inhalte sind ja anders. Einer ist eine PDF, das andere ist HTML. Das ist anfühlt sich von der Struktur her von den bytes in diesen Dateien ist es schon mal anders. Also ist es nicht so, dass wir das als rein duplicate content betrachten würden. Wir würden da wahrscheinlich beide Varianten indexieren. Die Frage ist dann, was ist mit den Inhalt? Wie steht es, wenn da jetzt die Ärzte drin sind, die eigentlich gleich sind auf der HTML-Version wie auf der PDF-Version und aus unserer Sicht würden wir das dann textmäßig anschauen. Das heißt, indexiert werden beide Varianten. Wenn jemand nach einem Text-Stück sucht, das in beides dieser Dateien etwa gleich ist, dann versuchen wir, eines dieser Dateien auszuwählen und zeigen die dann in den Suchergebnissen an. Wir können sich das so vorstellen, dass wir versuchen den snippet unterschiedlich zu haben für die einzelnen Sachen, die in den Suchergebnissen erscheinen. Das heißt, wenn im snippet das Gleiche stehen würde, wenn jemand nach etwas sucht, dann macht es ja wenig Sinn, dass man beides dieser Seiten zeigt, weil die Vorschau ist ja schon mal gleich für den Benutzer, lässt sich schlecht erkennen, welches dieser Varianten ein besseres Ergebnis wäre. Das sieht man dann ein von diesen beiden aus. Meistens ist es so, dass wenn man zum Ende der Suchergebnissen geht, gibt es da ein Link, dass man quasi auch die ausgedländeten Varianten anzeigen kann. Ich weiß nicht, wie das auf Deutsch heißt. Und da sieht man dann auch die, sage ich mal, als duplikat anerkannten Seiten dort auch. Das andere, was auch oft in diesem Thema aufkommt, ist quasi duplikat Content allgemein etwas, was man vermeiden muss. Ist das ein Problem, wird unsere Website vielleicht abgestraft, weil wenn duplikat Content da ist, ist das vielleicht ein Zeichen, dass die Website nicht so gut ist. Und aus unserer Sicht ist das ein rein technisches Problem. Das ist nicht etwas, wo wir sagen würden, eine Website würde weniger gut ranken in den Suchergebnissen, das ist ein Problem auf unserer Seite. Einerseits die Seiten, die wirklich 1 zu 1 doppelt sind, die müssen wir natürlich nicht beide indexieren. Anderseits die Inhaltsstücke, die doppelt sind, da müssen wir halt vom Ranking her verstellen, welches dieser Seiten am relevantesten ist und die dann entsprechend zu zeigen in den Suchergebnissen. Aber in beiden dieser Fällen ist es nicht so, dass die Website dann als schlechter abgestuft wird. Problematisch ist das nur dann, wenn eine Website komplett aus duplicate Content besteht. Das heißt, wenn eine Website Inhalte aus dem Internet kopiert und die ganze Website ist eigentlich nur eine Kopie von einer anderen Website oder von verschiedenen anderen Websites, dann ist das eher eine Frage vom Spam, wo wir dann sagen würden, es lohnt sich wahrscheinlich nicht, die Website überhaupt zu indexieren, weil wir finden da nichts, was alleine dargestellt werden kann, nichts, was separat indexiert werden muss. Und das ist dann eher problematisch. Aber wenn eine normale Website einzelne Seiten hat, die verdoppelt sind, ist das überhaupt kein Problem. Das ist sehr normal. Das haben fast alle Websites, so in einer Form oder der anderen. Informationen über Mobile Index als Hauptindex werden die anderen Indexen total verlassen. Ja, kann man so an und für sich sehen, ist es so, wenn wir ein Domain auf Mobile First indexing wechseln, dann nehmen wir nur die mobile Variante im Index auf. Das heißt, wir crawlen die anderen, die Desktop-Variante noch ab und zu. Sehr selten. Aber im Index ist effektiv nur die mobile Version. Das heißt, wenn irgendwelche Inhalten auf der Desktop-Version vorhanden werden, dann würden wir die gar nicht sehen. Das heißt, entsprechend auch, wenn man eine Website hat, die so unterschiedlich ist zwischen Mobile und Desktop-Version, muss man sich einfach bewusst sein, dass das Wichtigste muss wirklich auf der mobile Version sein. Im Moment ist es so, dass wir die Domains noch einzeln quasi überschalten auf Mobile First indexing und geplant ist im September dann wirklich alles auf Mobile First indexing umzuschalten. Ich weiß nicht, wie weit wir das Datum September einhalten können. Jetzt ist ja alles irgendwie ein bisschen speziell. Aber wir sehen, dass immer wieder Websites sich quasi durcharbeiten, durch diese Problematik und die Probleme auch beheben. Wir schicken auch über Search Console E-Mails an Websites und damit ein bisschen mehr Information über solche Differenzen, die wir gesehen haben mit der Mobile und Desktop-Version. Ich denke, so lange wir sehen, dass das Website noch an diesem Problem arbeiten, dann können wir wahrscheinlich mit diesem Datum weiterarbeiten, wie sich die ganze Situation entwickeln wird, bis dahin wer weiß. Hoffentlich beruhigt sich das, aber ich denke, das ist noch lange Zeit, bis wir so weit sind. Wie relevant ist es bei einer Änderung der AMP URL Struktur, die redirects von den alten AMP URLs auf die neuen AMP URLs zu setzen? An und für sich ist das immer wichtig für uns, dass wir die alten URLs auf die neuen quasi eine Weiterleitung finden. Ich könnte mir vorstellen, dass es bei AMP vielleicht weniger kritisch ist, einfach weil die URLs nicht so lange quasi separat gezeigt werden in den Suchergebnissen. Das heißt, wenn Benutzer auf die alten AMP URLs kommen, dann ist das wahrscheinlich nur eine relativ kurze Zeit, wo man da die redirects auch haben muss. Aber im Grunde genommen ist es immer ein Best Practice, dass wenn man eine URL Struktur Veränderung macht, dass man da von den alten auf die neuen auch immer eine Weiterleitung macht. Bei AMP könnte ich mir vorstellen, dass diese Weiterleitung einfach weniger kritisch ist, als wenn man jetzt eine normale URL Struktur Veränderung macht innerhalb einer Website. Wir betreiben einen größeren Online Shop und haben zwei Fragen. Wir möchten unserem Shop Kategorien Seiten mit leicht unterschiedlichen Layouts jeder Weise erstellen für Mobile und Desktop. Wenn nun in Folge der Umstellung eine unterschiedliche Anzahl internen Links auf die gemeinsamen URL darstellen, auf Mobile 30 ausgehende internen Links auf Desktop 60, werden dann große, werden dann aufgrund vom Mobile First Ansatz die zusätzlichen Links auf der Desktop Version bei den internen Link Power Verteilungen ignoriert. Ja, wenn diese Links nicht mehr auf der mobilen Variante sind oder nie waren auf der mobilen Variante, dann nehmen wir die entsprechend auch nicht. Normalerweise bei Kategorien Seiten ist das weniger ein Problem, weil wir können ja durch diese Seiten durchblättern und alle für sich dann statt alles auf der ersten Seite der Kategorien Seite, dann halt auf der ersten und zweiten Seite finden. Von dem her ist das jetzt nicht unbedingt etwas Kritisches, aber es ist effektiv so, dass wir wirklich nur die mobile Variante nehmen für den ganzen internen Link für die Umstellung, für den Page Rank für die Bilder, die da vorhanden sind die Links, all das. Es gibt also nur die mobile Variante wenn wir umstellen auf Mobile First Indexing. Vielleicht ist noch zu erwähnen, bei Mobile First Indexing ist das eine Umstellung die wir auf Domainebenen machen. Das heißt, wenn man eine Website hat die unterschiedliche Subdomains hat wo einzelne Teile vielleicht bereit sind und andere nicht müssen wir da trotzdem eine Umstellung auf dieses Domain ist jetzt alles bereit oder es ist noch nicht bereit. Und wenn wir sehen, dass im großen Bild wirklich alles bereit ist für eine Umstellung auf diesem Domain und einzelne Unterbereiche noch nicht bereit sind, dann stellen wir halt trotzdem auf Mobile First um und dann muss man halt das mit den Unterbereichen selber ein bisschen erkennen und entsprechend beheben. Besteht in Gefahr, wenn wir Google in einem server-seitig gerenderten Code mehr Produkte zeigen als in den JavaScript Code den der User zu sehen bekommt. Der User wird die Produkte durch eine für Google nicht erreichbare Paginierung normal aufrufen können. Im Grunde genommen kann man so etwas schon machen. Aus unserer Sicht würden wir das wahrscheinlich so einstufen wie andere Sachen, die man mit JavaScript machen kann, fällt der Name jetzt nicht ein. Aber an für sich könnte man das schon machen. Ich denke, die größere Gefahr da ist einfach, dass man nicht erkennt, wenn irgendwelche Fehler auf der Website passieren gerade bezüglich Google Word. Das heißt, Fehler wird es ja immer geben, wenn man etwas programmiert und wenn Fehler auftreten, die nur für Google Word sichtbar sind, meistens viel länger bis ihr das auch merkt, dass da jetzt Probleme vorhanden sind. Das heißt, jedes Mal, wenn man diese Art von cloaking oder quasi for render macht für Google, muss man wirklich festsch, irgendwie einbauen, dass man ein Art Monitoring hat, dass man selber erkennen kann, klappt das alles noch oder gibt es da vielleicht irgendwelche Probleme. Aber ansonsten kann man das durchaus so machen. Ich weiß nicht, ob es effektiv lohnt, gerade wenn sich das auf diese 30 oder 60 Links bezieht, aber kann man an und für sich so machen. Ich hätte dazu gerade noch eine passende Frage. Also, wenn ich die gerade reinwerfen kann, weil das wäre passend zum Thema, nämlich folgen, das geht mir dabei durch den Kopf. Wir haben ja auch eine JavaScript-Seite und die ganze Suche ist auf JavaScript und wenn ich jetzt hingehen würde wenn der Googlebot kommt, wir spucken standardmäßig irgendwie ich glaube 10 Ergebnisse aus. Wenn der Googlebot kommt, würden wir dann, wenn wir dann sagen wir möchten 30, dass er mehr Content hat zum Crawling, wäre das auch okay? Also, wenn wir ihn quasi mehr an die Hand geben. Ich denke, das kann man schon machen. Ich weiß nicht, wie weit man da effektiv Worteile davon hätte oder ob das soweit klappen wir, ich suche gerade bei den JavaScript-Dokumentationen die wir haben, wie das heißt. Dynamic Rendering nennen wir das. Ich würde da in der Entwickler-Dokumentation mal nachschauen und ja, würde mal schauen, wie das da direkt implementiert ist. Mountain macht auch regelmäßig Office Hours, wo man sich anmelden kann und direkt bezüglich JavaScript auch mal fragen kann. Ich weiß nicht, ob das diese Woche stattfindet oder nächste Woche. Das wäre auch noch eine Frage gewesen, die ich am Ende stellen wollte, weil das habe ich jetzt auch gesehen, dass er jetzt so spezifisch JavaScript-Seo macht. Aber ich glaube, da komme ich am Ende noch mal dazu, da hätte ich dann noch mal eine Frage, wo man sich da irgendwie anmeldet und wie gesagt, ich denke, man kann das schon machen, dass man da unterschiedliche Anzahlprodukte pro Seite darstellt. Manchmal macht man das ja auch nach Gerätetyp oder vielleicht, ob ein Benutzer angemeldet ist oder nicht. Von dem her sehe ich das eher aus unproblematisch. Ich weiß einfach nicht, wie weit man da wirklich einen Vorteil aus SEO-Sicht hätte, wenn man das macht. Aber das kann man ja auch ausprobieren. Dass man sagt, für eine Kategorie Seite probieren wir das mal so aus oder andere probieren wir das anders aus. Dann kann man dann ein bisschen testen und schauen, was besser funktioniert vom SEO her, was vielleicht auch von Usability her besser geht. Vielleicht gibt es ja auch etwas, was für beide Varianten klappt. Warum sieht man auf Google News nur die Hauptwebsites und nicht die Kleineren, die auch gute Inhalte haben? Gibt es eigentlich Infos über die letzte Version von Google News Publisher? Ich habe leider überhaupt keine große Einsicht in Google News. Aber ich weiß, es ist so, dass wir da nicht nur die Hauptwebsites zeigen, sondern dass wirklich auch kleinere Websites da eine Chance haben, bei Google News gesehen zu werden. Aber was da, die genau an Hintergründe sind oder wie das mit dem Google News Publisher Center klappt, weiß ich effektiv nicht. Da müsste man vielleicht im Google News es gibt für Google News Publisher eine extra Hilfeform. Das würde ich vielleicht mal nachfragen. Auf unseren Seiten, wenn man genau nach dem Titel eines Artikels bei Google sucht, dann erscheint der Titel in den Suchergebnissen fälschlicherweise ohne Bindestrich. Ansonsten wird dieser bei allen anderen Suchanfragen korrekt dargestellt. Was könnte der Grund hierfür sein? Ich habe das mal angeschaut mit diesem Suchbegriff, den du da angegeben hast und das sieht effektiv komisch aus. Ich weiß nicht genau, was man da machen könnte. Also was ich gesehen habe, ist der Bindestrich in den Dateien ist quasi ein Unicode-Bindestrich. Ich denke, das macht es ein bisschen schwieriger für uns zu erkennen. Aber ich war doch überrascht, dass da kein Lehrschlag zumindest zwischen den Wörtern ist, sondern dass sie gerade direkt aneinandergeschrieben sind und habe das mal in das Team hier weitergegeben. Aber wenn das effektiv nur die Variante betrifft, nach diesem Titelsuch, dann ist es vielleicht weniger zeitkritisch. Aber vielleicht gibt es etwas, was wir da verbessern können auf unserer Seite. Wenn ich nach unserer Organisation in Google suche, eine große Grundlagenforschungsorganisation in Deutschland, findet und zeigt Google die Hauptseite der Website in den Suchergebnissen. Allerdings wäre nicht die Beschreibung aus dieser Seite in den Suchergebnissen gezeigt, sondern die Beschreibung aus einer Forschungsmeldung. Auf dem Newsroom, die nichts mit allgemeinem Mission der Organisation zu tun hat. Wie können wir dies korrigieren lassen? Momentan ist das die wichtigste Suchergebnisseite für uns und völlig verwirrend. Also, vielleicht erstmal so, wir passen die Titel und die Beschreibung nicht manuell an. Das heißt, es ist nicht so, dass man jemand bei Google anrufen kann und sagen kann, ich möchte gerne die Beschreibung geändert haben. Sondern wir machen das alles algorithmisch aufgrund einerseits von der Suchanfrage, die gestellt werden, andererseits über die Information auf den einzelnen Seiten. Bezüglich den Seiten, gerade bei den Beschreibungen, ist es so, dass wir den Meta Description verwenden, also Description Meta Tag und auch die Inhalte der Seite selber. Das kann durchaus sein, dass wir sagen oder dass unsere Algorithmen das Gefühl haben, dass der Meta Description ist vielleicht jetzt nicht wirklich passend hier. Wir nehmen eher Inhalte aus dem Hauptteil der Seite. Und wenn zum Beispiel Pressemeldungen auf dieser Seite sind, wenn Abschnitte von Pressemeldungen dabei sind und das als wichtigster Inhaltelement quasi angesehen wird von unseren Algorithmen, dann kann es durchaus sein, dass wir das als Description auch dazu nehmen. Wie man das ein bisschen vermeiden kann, andererseits einen guten Meta Description zu nehmen, also etwas, was einigermaßen eigenständig ist, wo wir erkennen können, das passt wirklich zu dieser Seite. Etwas, wo wir auch erkennen können, das passt zur Suchanfrage. Wenn jemand zum Beispiel nach dem Namen sucht von einer Firma, dann macht es vielleicht Sinn, dass man das auch in dieser Beschreibung entsprechend erwähnt, damit jemand, wenn sie die Beschreibung anschauen, dass sie erkennen können, aber andererseits, dass diese Information wirklich auch gut sichtbar auf der html-Seite selber sind. Das heißt, wenn wir die Seite aufrufen und den Browser darstellen, dass die Informationen auch irgendwie relativ weit oben auf der Seite sind, nicht, dass sie versteckt sind irgendwo, sondern, dass sie wirklich gut sichtbar sind. Und wenn man diese beiden Sachen macht, dann ist es schon eher so, dass wir dann solche Sachen noch dazunehmen für die Beschreibung. Es ist nie garantiert, weil die Beschreibung stellt sich ja ein bisschen aus dem zusammen, was wir finden auf dieser Seite und wo wir denken, das könnte vielleicht relevant sein. Aber wenn beide dieser Varianten gut zusammenkommen, dann sollten wir das in den meisten Fällen eigentlich schon auch hinkriegen. Und wenn das trotz allem nicht klappt, wenn da wirklich die Beschreibung, also die Meta Description gut ist und die Inhalte auf der Seite sind relevant und wir nehmen etwas, was total irrelevant ist in die Beschreibung hinein. Gerade für etwas wie eine Homepage dann wäre ich sehr froh, wenn ihr mir die Informationen mal zuschicken könntet. Einerseits die Suchanfrage und andererseits vielleicht auch ein Screenshot, wie das aussieht bei euch. Weil unter Umständen sieht das ein bisschen anders bei uns aus je nach Einstellungen und Ort, von wo aus man sucht. Aber das wäre da schon ein bisschen hilfreich, wenn wir das ein bisschen genauer anschauen könnten. Und es ist nicht so, dass wir dann manuell diese Descriptions anpassen würden, sondern wir würden einfach versuchen, unsere Algorithmen zu verbessern, damit wir besser erkennen können, was ist jetzt wirklich relevant hier und wie können wir das darstellen in den Suchergebnissen. Und gerade mit Titel und Beschreibungen ist es manchmal auch so, dass unsere Algorithmen werden natürlich irgendwo entwickelt und die Entwickler sprechen vielleicht Englisch oder ich weiß nicht, wenn die woanders sind, andere Sprachen. Aber es ist nicht so, dass sie direkt alle Sprachvarianten anschauen. Wir haben zwar Tested, die Suchergebnisse jeweils auch durchgehen und sagen, es ist okay oder es ist nicht okay in verschiedenen Sprachen. Aber wenn das zum Beispiel eine Sprache ist, die nicht so häufig verwendet wird, dann könnte ich mir schon vorstellen, manchmal ein bisschen suboptimale Ergebnisse bringen. Ich denke auf Deutsch ist das weniger der Fall, aber gerade mal weniger bekannte Sprachen könnte da schon eher passieren. Und auch in solchen Fällen ist es dann wichtig, dass wir dieses Feedback haben, damit wir das auch verbessern können in unseren Systemen. Okay, ich glaube, das sind wir ziemlich bei den Fragen durch. Mal kurz schauen, ob da noch etwas Neues dazu gekommen ist. Ja, ich glaube, das war es ziemlich von den eingereichten Fragen. Was gibt es noch aus eurer Sicht? Ja, ich wollte nochmal eine Frage stellen. Genau, nämlich ist es so gewesen, ich gucke halt über den Community tab immer. Vielleicht, also du sattest jetzt vorhin schon vor dem Gespräch, dass du das auch auf Twitter postest, aber wie sieht das denn aus? Also des JavaScript SEO Talk Hangout, der SEO Hangout, man nicht. Du sattest jetzt gerade vor ein paar Minuten, man kann sich da ja anmelden für. Wo mache ich das denn? Also bei mir würde es betreffen, beziehungsweise in der Bereiche. Ich schau kurz nach, weil einige dieser Sachen machen wir quasi total offiziell und die sind dann in unseren Event Challenges dabei. Andere sind die quasi laufen eher so im Hintergrund ab, wo einzelne Mitarbeiter Sachen arbeiten. Muss man kurz schauen. Martin macht eben auf Twitch, macht da jeweils seine Sachen. Ich kann den Link mal kurz hier hinein kopieren. Gerade bezüglich JavaScript macht es wahrscheinlich Sinn, dass man Martin auch auf Twitter ein bisschen verfolgt und das klingt irgendwie nicht so optimal, aber halt da nachschaut und er macht eben auch auf Twitch regelmäßig mehr oder weniger solche Hangouts, wo er zum Beispiel an der Dokumentation für die das ganze JavaScript Rendering arbeitet oder ein Präsentation darüber arbeitet und da kann man ihn dann auch direkt ein bisschen ausquetschen und fragen, wie das in bestimmten Zeiten ist oder wie er das machen würde in bestimmten Situationen. Klar auf Twitch kann ich ja per Chat teilnehmen, aber so wie jetzt hier quasi, dass man wirklich der Sprachchat beiwohnen kann, habe ich jetzt einmal gesehen, ist ja auch auf dem Channel hochgeladen, aber ich habe keine Ahnung wo ich da mich quasi für anmelden oder anschließen kann. Ja, es kann sagen, dass einfach im Moment nichts geplant ist. Gerade so, die Sachen zu speziellen Themen sind in vielen Fällen sind es einfach einmalige Sachen, die wir mal machen. Wir haben glaube ich über Google News mal etwas gemacht, über E-Commerce haben wir jetzt 2 gehabt und das sind einfach so Office-Hour Sprechstunden, die wir einfach dann einmal machen und die nicht regelmäßig stattfinden. Ach so, okay, gut. Also das ist jetzt nicht quasi das hier jetzt regelmäßig geplant, sondern das ist einfach nur jetzt mal spontan gewesen und ja. Genau, ja. Also ich denke, auch gerade bei JavaScript kannst du jederzeit Martin Direkt auch anschreiben, besprecht auch Deutsch. Wir haben auch ein Forum, wo man sich anmelden kann. Hat mal raus. Wo gerade für JavaScript-Zeits kann man sich da anmelden und auch mit anderen ein bisschen austauschen, die mit JavaScript-Zeits gerade bezüglich der Suche arbeiten. Das ist quasi ein privates Forum, einfach damit man die Sachen ein bisschen besser besprechen kann, ohne dass es gerade indexiert wird in den Suchergebnissen. Aber da sind diverse mit JavaScript-Zeits zu arbeiten. Cool, noch irgendwelche weiteren Fragen. Alles soweit klar, okay. Gut, sonst machen wir doch hier eine Pause. Vielen Dank fürs kommen. Ich hoffe, das war hilfreich. Ich denke, die nächsten Hangouts machen wir wieder in 2 Wochen etwa. Ich stelle das wieder bei YouTube hinein. Wenn ihr bis dahin Fragen habt, könnt ich auch gerne im Hilferforum posten oder uns auf Twitter kontaktieren. Ja, und dann hoffentlich sehen wir uns ein von dem nächsten Mal wieder. Vielen Dank fürs kommen. Bleibt gesund und bleibt zu Hause, ich glaube, wahrscheinlich für alle. Und bis zum nächsten Mal. Tschüss.