 Okay, herzlich willkommen beim heutigen Webmaster Essentials-Sprechstunden-Hangout. Heute speziell für News Publisher, speziell aus Deutschland oder den deutschen Sprachraum zumindest. Haben hier einige, die schon eingewählt sind. Wenn noch weiter bei der Zuschluss, ist das auch toll. Einige Fragen sind bereits eingereicht worden. Ich denke, ich gehe einfach zum Auswahl dieser Fragen durch. Wenn ihr zwischendurch Fragen oder Kommentare habt zu den einzelnen Fragen oder Antworten oder etwas genauer erläutern möchtet, einfach nur loslegen. Dann können wir das machen. Ja, fangen wir doch oben gerade mal an. Eine Frage, die wir ab und zu gekriegt haben, habe ich mal am Anfang hingenommen. Wir haben oft das Problem, dass ein falsches Datum in Google News oder in der Suche dargestellt wird. Obwohl wir eigentlich alles soweit richtig machen, woran kann das liegen? Grundsätzlich ist es so, dass wir versuchen, das Datum auf diesen Seiten zu finden und sauber herauszulesen. Manchmal klappt das gut, manchmal klappt das nicht so besonders gut. Was man aber machen kann, ist mit Structuredata kann man jeweils angeben, wann ein Artikel zuerst gepublished wurde und wann es vielleicht verändert wurde. Das heißt, man verwendet da den Article Structuredata und nimmt DatePublished und DateModified. Wichtig, was wir da ab und zu sehen, ist, dass teilweise die falschen Zeitzonen angegeben werden bei diesen Daten oder keine Zeitzone angegeben wird. Dann ist es natürlich schwierig für uns zu erkennen, welches Datum wir da nehmen sollen. Was auch für uns wichtig ist, ist, dass man nicht nur Structuredata nimmt für ein Datum, sondern dass es wirklich auch passend auf den Seiten selbst im Text oder zumindest im Artikel irgendwo erwähnt wird, damit wir wirklich klar feststellen können, das passt überein, das sieht so korrekt aus. Wenn all das gegeben ist, wenn das Structuredata angegeben ist, wenn da kein Konflikt da ist, dass unterschiedliche Daten in Structuredata vorhanden sind, wenn die Zeitzone richtig eingestellt ist, dann sollte das eigentlich soweit klappen. Wenn es trotzdem nicht klappt, wäre ich froh, wenn ihr uns möglichst schnell solche Sachen melden könntet, damit wir das hier auch nachstellen können, damit wir das direkt mit dem Team anschauen können. Manchmal ist es ein bisschen schwierig, dass man da quasi in Bereich anschaut, eine Stunde oder mehrere Stunden, ob das jetzt eine Stunde vor einer Stunde veröffentlicht wurde oder vor zwei Stunden, je nachdem, wie das gerundet wird, ist das ein bisschen schwierig. Aber in der Regel sollte das eigentlich relativ gut übereinstehen. Wie sieht ihr das? Klappt das bei euch jeweils, oder ist das etwas, was mal funktioniert und mal weniger gut klappt? Das ist bei uns in der Tat so, dass es zwar überwiegend kann sein, funktioniert, aber es gibt halt Fälle, wo es nicht funktioniert und wo wir dann nicht dahinter kommen, warum das so ist. Dann habe ich noch eine Frage, wie geht eigentlich Google mit den Daten, um die in der Newsside-Map noch mal mitgegeben werden, während diese Zeitstempel irgendwie verarbeitet, verwertet? Meines Wissens verwenden wir die hauptsächlich, um festzustellen, wann wir die Seiten crawlen müssen. Das heißt, wenn jetzt neue Seiten dabei sind, dass wir das möglichst schnell merken und dass wir die entsprechend schneller crawlen. Ich weiß jetzt allerdings nicht, ob bei der Newsside-Map auch ein Update published dabei ist oder ob das nur quasi Änderungsdatum von der Seite angegeben ist. Ja, also wir haben beide Zeitstempel drin. Aber das Datum, was auf der Seite selber steht, ist sozusagen das Wichtigere für das Datum, was dann in der Schlagzeilenbox angezeigt wird. Ja, also es muss wirklich auf der Seite selber klar erkenntlich sein, idealerweise, dass es auch bestätigt wird mit Structured-Data, damit wir das wirklich auch so bestätigen können und nicht, dass wir so eine Situation haben, dass da verschiedene Daten auf einer Seite erwähnt werden, weil ein Bericht vielleicht über verschiedene Ereignisse geschrieben wurde und dass wir dann nachher nicht wissen, welches Datum ist jetzt eigentlich das Wichtige für diese Seite. Danke. Bei den anderen klappt das soweit mit dem Datum oder ist das auch mal besser, mal schlechter? Bei uns ist es auch der Case, dass es in den meisten Fällen tatsächlich klappt. Aber es gibt Fälle und den laufen wir dann auch hinterher, weil wir gerade, wenn wir Anpassungen von Stories haben und das Neues dazugekommen ist an Info, den Refresh machen wollen wir natürlich auch, dass das sichtbar ist und das kann dauern und das geht dann auch soweit, dass nicht nur irgendwie die Zeit nicht korrekt angezeigt ist, sondern teilweise ist auch sehr lange dauert, einen Seiten viel Refresh zu bekommen. Also, die Story sieht einfach alt aus. Also, wenn man will, ist tatsächlich zumindest nach meinem Wissen alles, was jetzt angesprochen hast, auch umgesetzt und sollte in der Theorie funktionieren. Wir geben es dann sogar noch mal über die Search-Kontrolle zusätzlich ein, den Recrawl. Aber das kann bis zu einem Tag dauern und dann ist die Story halt hoch. Okay. Das heißt, wenn ihr bestehende Seiten anpasst, dann geht es, geht es länger, als wenn man jetzt etwas Neues, zum Beispiel veröffentlicht. Das haben wir öfter gesehen. Ich schließe das andere nicht aus. Das kann sicher bei uns auch passieren, aber das sind die Fälle, die uns besonders aufgeben. Okay. Gut. Dann muss ich mal mit dem Team anschauen. Ja. Also, wir haben aktuell den Fall, was meines Wissens nach auch ein Back-auf-Seiten von Google News ist, wurde mir gesagt, was ein bisschen mit den Indexierungsproblemen in der Mitte des Monats tun hat. Das Zeitstempel, das scheinbar Google News Probleme dabei hat, die Zeit richtig nachzuvollziehen und das Kurioses ist. Wir haben jetzt Artikel, die beispielsweise heute rausgekommen sind. Und dann wird der Google Suche und auf Google News angezeigt, sie wären fünf Tage alt. Und wenn wir sie überprüfen in der Search-Konsole, sagt uns die Search-Konsole, sie wären noch gar nicht indexiert. Okay. Das ist ein bisschen komisch. Wenn du mir solche Beispiele mal zuschicken könntest, dann würde ich die gerne mit dem Team anschauen. Gerade wenn sie noch so weit frisch sind, dass wir das hier nachstellen können, das hilft auf jeden Fall. Sehr gerne. Okay. Dann schauen wir mal weitere Sachen an. Ja. Und zwar, also genau, noch ein anderer Fall. Wir haben festgestellt auch bei älteren Artikeln, dass das nach gewissen Aktualisierungen, die wir machen, die aber wirklich am Content sind, sind für der Weise, dass dann auch manchmal auch ein altes Datum zurückgesprungen wird. Weiß ich, ob das bei den anderen auch schon mal der Fall war. Aber das haben wir auch gesehen. Was wie das kommt sozusagen an der Stelle, also wir machen wirklich auch tatsächlich eine sinnvolle Aktualisierung bei Mathike und stellen aber trotzdem fest, dass das Datum eben nicht mitaktualisiert wird, sondern der irgendwann wieder zurückgeht. Und das ist auch total schwer für uns nachzuvollziehen, warum das an der Stelle passiert. Ich vermute, dass es allgemein ein bisschen schwierig für uns, wenn wir, sag mal, der Ursprungsdatum haben und ein Änderungsdatum haben, welches dieser Daten wir in der Suche darstellen sollen. Aber das müsste man vielleicht gerade bei Nachrichteninhalten ein bisschen schlauer machen, dass man da wirklich dann auch das Änderungsdatum jeweils darstellt. Okay, gut, fangen wir gerade mit dem schwierigen Problem an. Naja, kann passieren. Okay, also mal ein bisschen was anderes. Wir haben ein Inhaltsverzeichnis, das per Default eingeklappt ist und die Frage ist, ob Google das genauso gewichtet wie etwas, was ausgeklappt ist per Default. Aus unserer Sicht ist das total okay, wenn man zum Beispiel ein Menü hat, welches standardmäßig eingeklappt ist und die Links da drin sind im ersten Moment unsichtbar. Wichtig ist einfach, dass die Links auf der Seite selber sind. Das heißt nicht, dass wenn man auf dieses Menü-Element klickt, das dann erst per Server-Abfrage diese Navigation geladen wird, sondern dass die wirklich von Anfang an schon sichtbar ist, also nicht sichtbar, aber zumindest im HTML dabei ist, damit wir diesen Links verfolgen können. Und dann ist es eigentlich soweit kein Problem. Es ist nicht so, dass wir das dann als Spam oder versteckte Inhalte, die problematisch sind, irgendwie anschauen würden, sondern das ist eigentlich eine normale Art, eine Navigation zu machen. Okay, ja, genau, die Fragen kamen nämlich von uns. Das heißt, es wird genauso gewichtet und beispielsweise diese Minisight-Link wird für uns eben wunderbar auch oft gezogen werden. Wäre dann die Wahrscheinlichkeit genauso groß, dass wir das dann funktionieren? Genau, ja, auf jeden Fall. Super. Dann eine Frage zu Keyword-Cannibalisation. Das heißt, wenn man jetzt verschiedene Seiten hat, die zum gleichen Thema sind, ist das problematisch, wenn man zum Beispiel einmal ein Artikel hat und einmal eine Bildergalerie oder erkennt Google hier die unterschiedlichen Aufbereitungsformen und zeigt die zum Beispiel nebeneinander an. Aus unserer Sicht ist das total okay. Es ist eigentlich normal, dass man verschiedene Seiten hat, die zu den gleichen Keywords vorhanden sind und wir versuchen da einfach jeweils die relevantesten Seiten für die einzelnen Suchen herauszuholen. Es kann sein, dass wir da mehrere Seiten von einer Webseite zeigen. Es kann auch sein, dass wir einfach eines dieser Seiten nehmen und die darstellen in der Suche für diese Webseite. An und für sich ist das normal. Gerade bei Nachrichtenseiten ist es eigentlich gang und gäbe, dass man verschiedene URLs hat, die Artikel haben über grob, die sagt das gleiche Thema oder vielleicht über die gleiche Person. Normalerweise sollte man damit eigentlich relativ gut zurechtkommen. Sollte eigentlich unproblematisch sein. Genau, da noch eine Nachfrage. Das heißt, GoogleEig oder ihr kennt dann auch eben wirklich so ein bisschen diese unterschiedliche mediale Aufbereitungsform. Also so, dass es eben hauptsächlich vielleicht in Bildern abgehandelt ist, weil es da vielleicht automatisch irgendwie Sinn macht. Das wird quasi dann schon auch eben erkannt. Wir versuchen einfach, die relevanteste Seite jeweils zu finden. Die Aufbereitungsform ist weniger relevant für uns, sondern welche Inhalte sind jetzt auf dieser Seite. Das heißt, wenn ich in der Bildersuche bin, dann versuchen wir natürlich eher, Bilderseiten herauszuholen in der normalen Websuche, konzentrieren uns einfach auf die Texte, die auf dieser Seite sind. Wenn jetzt auf einer Seite weniger Texte sind zu diesem Thema, müssen wir halt schauen, dass wir mit diesen wenigen Texten besser zurechtkommen oder dass wir das irgendwie einstufen können und sagen können, ja, diese Seite ist jetzt relevanter für dieses Thema, weil vielleicht ist sie neuer oder vielleicht ist sie kompletter, vielleicht sehen wir einfach sonst, dass sie relevanter ist insgesamt im Web. Danke. Dann zum Thema Crawling und Indexing. Wir haben bei einigen unser Titel in der Google Search Console den Fall, dass viele URLs mit gefunden zurzeit nicht indexiert oder gecrawled zurzeit nicht indexiert markiert sind und daher nicht in Google zu finden sind. Hier stellt sich die Frage quasi, was kann man da machen? Grundsätzlich ist es, also es sind, ich glaube, das sind zwei Sachen, die ein bisschen zeitlich zusammenfallen, die das Ganze ein bisschen verwehrend machen. Einerseits hatten wir, ich glaube, Mitte November Größenordnung ein bisschen ein Problem, dass wir Inhalte insgesamt nicht so schnell indexieren konnten und dass wir da die Inhalte quasi gecrawled haben, aber nicht so schnell im Index zeigen konnten, wie wir das eigentlich normalerweise machen würden. Das ist mal die eine Sache und die andere Sache ist, dass wir diese beiden Status in Search Console erst relativ neu haben. Das heißt, erst mit dem neuen Search Console zeigen wir das und die neue Search Console wird jetzt immer mehr auch verlinkt intern. Das heißt, man findet eher den Weg zu einem neuen Search Console und findet dann solche Meldungen. Und in Grunde genommen sind die beiden Status eigentlich für uns normal. Das heißt, wir crawlen sehr viele Seiten, wir sehen sehr viele URLs im Web und wir indexieren eigentlich nur einen kleinen Teil davon. Das heißt, auch innerhalb von einer größeren Website ist es total normal, dass wir viele URLs kennen, dass wir einfach einen Teil davon indexiert haben. Und wenn man bei Search Console gezielt jetzt diese herausholt und sich überlegt, ja, ist das ein Fehler, machen wir da irgendwas falsch? Normalerweise sind das eigentlich nur Sachen, die wir auch sonst nicht indexieren würden. Das heißt nicht, dass ihr irgendwas falsch macht, sondern es heißt einfach, wir haben so viele URLs gesehen von eurer Website und wir denken, dass wir das meist eigentlich gut abgedeckt haben und müssen im Moment jetzt nicht noch mehr indexieren von dieser Website. Das heißt, diese beiden Status, ich glaube, in Indexabdeckungsreport in Search Console, sind aus unserer Sicht in den meisten Fällen total normal. Was ich da einfach kontrollieren würde, wenn man das anschaut, ist, wie weit die Seiten, die da gemeldet werden, wirklich wichtig für euch sind oder ob das einfach andere URLs sind, die halt gefunden worden sind auf eurer Website, die nicht so kritisch sind. Ob das jetzt neuere, aktuelle Artikel sind oder ob das wirklich ältere Sachen sind, die wonach vielleicht niemand zu geben sowieso sucht und worauf man sich eigentlich, wo man sich nicht so viel Sorgen machen muss, wenn sie nicht indexiert werden. Wenn das Sachen sind, die eigentlich indexiert werden sollten, die für euch wichtig sind, dann würde ich einfach schauen, dass sie intern innerhalb der Website auch wirklich klar und deutlich sichtbar verlinkt werden, dass wir, wenn wir die Website anschauen, wirklich merken, das sind eigentlich schon wichtige Seiten, damit wir dann im nächsten Schritt die dann auch wirklich indexieren. Nicht, dass wir die irgendwie im Archiv mal in der hintersten Schublade gesehen haben und dann denken ja, wenn sie so weit hinten vergraben sind im Archiv, dann sind sie vielleicht nicht wahnsinnig richtig. Aber ich denke, da müssen wir wahrscheinlich in Search Console allgemein das Ganze mal ein bisschen vielleicht überdenken oder überarbeiten, wie wir das zeigen, weil ihr seid da nicht die einzigen, die damit ein bisschen verwirrt sind. Und wenn es aus unserer Sicht ein normaler Zustand ist, dann sollten wir das nicht irgendwie als Fehler für euch melden und euch damit quasi beauftragen. Ihr soll das für uns beheben. Weil in den meisten Fällen ist das total normal. Darf ich da noch was zu sagen? Ja. Die Frage kam nämlich von uns und es ging konkret um ein Sportportal, wo quasi zu, ja, von Kreisklasse, sonst so was, bis Bundesliga in einem bestimmten Verzeichnis sehr automatisiert Live-Ticker, also die Verlinkung zu einem Live-Ticker sind. Die sind aber gesperrt für Google. Und also sprich, die Daten, die aus der Datenbank kommen und wo sich das automatisch generiert ist, quasi über die Robots TXT gesperrt oder über die Robots TXT gesperrt. Und wir hatten dann den Fall. Ich müsste mal zurückgehen im Datum. Vielleicht ist es in diesem Mitte-November-Fall reingefallen, dass wir halt einfach einen Fußballspiel redaktionell live begleiten wollten mit einem redaktionellen Live-Ticker. Und wir haben es nicht geschafft, dass dieser Live-Ticker eben in den Index gekommen ist. Sodass eben so ein bisschen dieses, na ja, Mensch, okay, anhand dieses einen URL-Pattern, es hat Google gesehen, Live-Ticker wird, soll nicht rein. Und wir hatten dann halt ein bisschen die Befürchtung, dass er halt eben, weil das Wort Live-Ticker auch in dem redaktionellen Artikel eben vorkam, dass er das eben per se ausgeschlossen hat. Wir haben dann quasi während des Spiels versucht, noch auf eine andere URL zu schiften. Wir haben einen zweiten Artikel dazu gemacht. Es war für uns nicht möglich, in diesem Moment der Index reinzukommen. Und der Artikel ist halt jedes Mal in diesem Bericht in der Search-Konsole gelaufen. Ich prüfe das nochmal vom Datum. Das war auf jeden Fall verwirrend und ärgerlich. Ja, also vom Datum her weiß ich nicht, ob das vielleicht da reinpassen könnte. Was natürlich auf unserer Seite schon auch passiert, ist, dass wir versuchen festzustellen, welche URLs normalerweise gut gehen mit der Indexierung und welche wir normalerweise nicht indexieren können. Und wenn wirklich alles andere per Robots Text blockiert ist in diesem Verzeichnis, dann kann es schon sein, dass unsere Systeme denken, ja gut, wir haben da was gefunden, aber erfahrungsgemäß ist alles in diesem Verzeichnis nicht etwas, was wir brauchen können. Also nehmen wir das vielleicht im zweiten Moment und versuchen da später mal aufzunehmen. Das heißt, wenn man das ein bisschen trennen kann, dass es wirklich Bereiche gibt, wo wir sagen können, das sind Sachen, die wir indexieren sollten, die wir nicht indexieren sollten, dann geht das sicher ein bisschen einfacher. Normalerweise in den meisten Fällen sollte das trotzdem klappen. Aber das sind vielleicht mal kleine Elemente, die da ein bisschen mit hineinspielen, die das manchmal ein bisschen schwieriger machen. Das passiert zum Teil auch mit Duplicate Content. Wenn wir zum Beispiel erkennen können, dass gewisse URL-Parameter immer die gleichen Inhalte zurückgeben und einmal verwendet ihr die Parameter, um etwas anderes zurückzugeben, dann kann es sein, dass unsere Algorithmen denken, ja, dieser Parameter ist irrelevant und dann merken wir gar nicht, dass es einmal doch etwas relevantes dabei gegeben hätte. Okay, danke dir. Also wir haben bei uns auf jeden Fall auch festgestellt, dass es immer mal Fälle gibt, wo einzelne Artikel nicht indexiert werden und wir können es tatsächlich auch nicht so richtig verstehen an der Stelle, also nichts, was jetzt auf die RobotsDXD etc. Sportdatenbank in nichts anschließen würde. Ich weiß nicht, inwiefern, ich glaube, es gibt bei anderen auch ab und zu mal das Problem, aber es ist halt auch total schwer festzustellen, welche davon betroffen sind. An der Stelle, ich weiß nicht, inwiefern es aber ein großes Problem ist oder wirklich es ganz selten war. Wie merkt ihr das im ersten Moment? Oder wie fällt das bei euch auf? Das ist tatsächlich, wenn auch mit Uta mein Redakteur sagt, jeder Artikel ist nicht indexiert, wir stellen wirklich fest, dass er nicht da ist. Genau, solche Fälle können sich einzufälle, aber wo wir es dann tatsächlich auch sehen können, das ist nicht mehr indexiert. Aber Artikel sind auf der Startseite, also nichts, was jetzt wirklich versteckt wird. Also nichts von der Startseite oder auch Sachen, die von der Startseite verlinkt sind? Sachen, die von der Startseite verlinkt sind? Ja. Es ist immer ein bisschen schwierig, solche Sachen anzuschauen, weil bis wir die Meldung gesehen haben, die werden oft indexiert, dann denkt man, gut, ist eigentlich alles okay. Für euch ist es einfach in der Zwischenzeit ein bisschen schwieriger. Aber was sicher helfen würde, ist, wenn ihr solche Sachen uns oder vielleicht mir mal zuschicken könntet, gerade wenn sie passieren, damit wir das gerade in dem Moment auch mal anschauen können und überlegen können, warum ist es jetzt mit diesem Artikel mit dieser Seite so gelaufen? Sehr gerne. Wir gehen uns an oder für uns als Anweisung, wenn sowas so was vorkommt, dass diese in die Search-Konsole gehen und dort ein Artikel manuell einreißen. Wir haben dann, aber auch gestern hat es vielleicht nicht geklappt, wir haben mit einem Artikel, das ging um die dritte Liga, 5-mal eingereicht haben und der Artikel war auch auf der Startseite, es ist nicht durchgekommen. Und dann weiß ich nicht, was die Redaktionen erzählen. Weil ich habe mal gesagt, als erstes Prüfung ist der Artikel der News-Sale-Map, ist der gut verlinkt, ist er auch, wenn es da nicht geht, über die Search-Konsole einreichen, ist es auch passiert. Normalerweise, die Sachen, die über die Search-Konsole eingereicht werden, sollten schon relativ schnell indexiert werden. Wenn das nicht klappt, dann gibt es wahrscheinlich Sachen, wie wir auf unserer Seite da verbessern könnten. Es ist immer ein bisschen schwierig, wenn man das so in Nachhinein erfährt, oder wenn man das nicht rechtzeitig kontrollieren kann, dann ist es schwierig zu erkennen, wo ist es jetzt klemmend geblieben, wie kann man das ein bisschen verhindern oder was? Aber wenn ihr solche Sachen mir melden könntet, dann kann ich das sicher mal nachschauen mit dem Team. Ich kann nicht garantieren, dass wir die Sachen gerade sofort indexieren. Das ist auch nicht ein sauber Knopf, aber zumindest können wir dem ein bisschen nachgehen und schauen, was es da passiert, damit wir das in Zukunft ein bisschen besser machen können. Okay. Vielleicht kommt es ja noch. John, wir hätten bei 100 Jahren noch eine brennende Frage zum Mobile Index. Könntest du darauf eingehen, die ist irgendwo unter den Notizen, direkt beim Hangout? Was war die Frage? Was war die Frage? Wir haben bei 100 Jahren für Mobile und für Desktop zwei unbeschlegene Technologien, das HTML war ich noch nicht ab, aber es war auf der Inhalt. Wir suchen jetzt den optimalen Weg, wie wir Mobile Index-mäßig uns dort möglichst optimal aufstellen und brauchen dann noch ein bisschen Unterstützung, wie wir davorgehen sollen. Wir werden es nicht schaffen, kurzfristig auf einen responsive Ansatz zu gehen. Okay. Dann folgt mir die kurzfristige Lösung und eine langfristige, die wir davorgehen sollten. Das war das war das war das ist eine Ausassung. Ja, genau. In der Mobile Seite machen wir mit Javascript. Das heißt, der Caller muss tatsächlich auch noch das Javascript renderen und danach interpretieren, das sonst auch eine kurzfristige Lösung wahrscheinlich im Nachteil hat. Okay. Ja, ich habe es kurz eingeschaut. Bohre ich bei dir noch ein bisschen Echo? Perfekt. hier kurz mal angeschaut, also nicht speziell die Website, aber grundsätzlich, was da passiert, sind da denke ich mal zwei Sachen. Einerseits, in vielen Fällen, können wir die mobile Version oder eine JavaScript Website auch renderen und da die Inhalte trotzdem sehen. Und ich könnte mir vorstellen, dass unsere Mobile First Indexing Algorithmen das dann anschauen und sagen, gut, die mobile Version ist komplett, gleich wie die Desktop Version, wir könnten das eigentlich umschalten auf Mobile First Indexing. Ich denke, das wäre soweit nicht wahnsinnig tragisch, wenn das auf Mobile First Indexing ist, aber was dann passieren würde, ist, wir müssten dann die JavaScript Version wirklich regelmäßig renderen, um die Inhalte herauszuholen und weil das Rendering jeweils ein bisschen länger braucht, bis das alles passiert, ist das wahrscheinlich gerade bei Nachrichtenseiten nicht optimal. Das heißt, was ich da machen würde, ist einerseits Dynamic Rendering einsetzen, zumindest für die JavaScript Version. Mit Dynamic Rendering schaut man, schaut man den User Agent an, der diesen Request macht und dann je nachdem, wenn das ein User Agent von einer Suchmaschine ist oder von Social Media oder was auch immer, dann schickt man eigentlich eine gerenderte Version dieser Seite zurück. Das heißt, technisch gesehen hat man natürlich ein bisschen mehr Infrastruktur, die da zusammenarbeiten muss, dass man die Seiten selber renderen muss oder dass man vielleicht mit einem Anbieter zusammenarbeitet, der dieses Rendering für euch macht. Aber wenn die per Dynamic Rendering zurückgegeben werden an uns, dann sinkt das eigentlich normale HTML-Seiten wie andere HTML-Seiten und die können wir dann eigentlich auch so genauso schnell indexieren wie normale HTML-Seiten. Ich denke, das wäre sicher eine Variante, die ich anpeilen würde. Ich bin nicht sicher, ob wir jetzt so etwas auf Mobile First Indexing umschalten würden oder nicht. Es hängt ein bisschen davon, wie gut wir die Seiten renderen können. Weil für Mobile First Indexing schauen wir im ersten Moment auch die Inhalte an, ob die mobile Version mehr oder weniger die gleichen Inhalte hat wie die desktop Version. Und wenn das der Fall ist, dann können wir das eher umschalten. Wir schauen auch solche Sachen an wie die interne Verlinkung. Das heißt, die mobile Version sollte ähnliche interne Verlinkung haben wie die desktop Version, ob Bilder und Videos auch sauber eingebunden sind, ob Structured Data vorhanden ist auf der mobile Version. All diese Sachen kommen ein bisschen zusammen und wenn wir das geprüft haben und sehen, dass es so weit okay ist, dann können wir auf Mobile First Indexing umschalten. Wenn die mobile Version mit dem Rendering nicht 100% klappt, dann könnte ich mir vorstellen, dass wir das zumindest am Anfang nicht für Mobile First Indexing verwenden würden. Eine Schwierigkeit da ist vielleicht, dass wenn wir eine Website auf Mobile First Indexing umschalten, dann ist das quasi umgeschaltet. Es gibt dann nicht eine Option, dass man das hin und zurück schalten kann. Das heißt, aus meiner Sicht würde ich einfach das vorbereiten, dass es wirklich auch klappt mit dem Dynamic Rendering, damit falls das umgeschaltet wird oder wenn das halt umgeschaltet wird, dass alles so weit klappt. Dass wir da die mobile Version sauber crawlen und rendering können mit der gleichen Geschwindigkeit wie mit der desktop Version. Okay, so weit verstanden. Vielen Dank. Aber das heißt, wenn wir noch nicht so weit zeigen, würde es jetzt nicht plötlich umgestellt werden und in den Nachteil reingeraten, sondern Google guckt erst mal, wie weit sind wir und wenn das dann optimal wäre, dann würde man umstellen. Genau, ja. In welchem Zeitraum kann man von dieser Logik ausgehen? Wir haben schon recht viel von Geschäck auf dem Weg. Das heißt, das wird, von meiner Information her wird das eigentlich laufend weitergemacht. Das heißt, es werden laufende neue Websites umgeschaltet auf Mobile First Indexing. Aber es ist im Moment zumindest nicht so, dass wenn wir sehen, dass eine Website nicht bereit ist, dass wir sie irgendwie zwingen oder es trotzdem umschalten, sondern wir sind auch bereit, ein bisschen zu warten, wenn das ein Jahr geht oder länger geht, bis eine Website wirklich bereit ist, dann müssen wir halt die Zeit auch nehmen, um das sauber zu machen. Okay, letzte Nachfrage dazu. Die Desktop-Seite wird hier hoffentlich mitbewertet in dem Index. Würden die jetzt beide abreichen mobile und desktop, wie stark würde das negative? Okay. Wenn wir auf Mobile First Indexing umschalten, dann nehmen wir nur die mobile Version für das Indexing und für das Ranking da zusammen. Wir schauen die Desktop-Version dann eigentlich nur an, um festzustellen, welche Desktop-Burals passen zusammen zu diesen Mobile-Burals. Das heißt, wenn jemand mit dem Desktop sucht, dass wir dann auch die richtigen Desktop-Seiten zeigen können, aber wir nehmen die Inhalte von der Desktop-Version gar nicht dazu, wenn wir die Website auf Mobile First Indexing umgeschaltet haben. Ja, und? Nein. Ja. Gute Frage hier. Grüß dich. Ich habe eine Frage, du hattest vorher mal Duplicate Content angesprochen, und das ist tatsächlich so ein Themenbereich, der uns als UTC-Portal natürlich einigermaßen beschäftigt. Wir haben viele Power-Nutzer, die vorformulierte Antworten, die sie in Wörterkommenten schon mal ausformuliert haben, dann einfach als, ich sage mal, generisch passende Antwort auf eine Frage mit rein posten und dann vielleicht fünf bis zehn Prozent des Inhalts tatsächlich adaptieren. Jetzt kann man natürlich aus Google-Sicht sagen, ja, ja, Moment mal, da ist eine Website, die Medaille-Content rumschläutert am Werk. Wenn man sich die einzelnen Fragen natürlich anschaut und die Adaptionen dann nochmal mit ins Kalkül einnimmt, dann macht die jeweilige Ergänzung von den jeweiligen Nutzern und auch das reinkopierende Frage tatsächlich Sinn. Jetzt stellt sich uns natürlich die Frage, als diejenigen, die da geschickte Strategien dafür dagegen ausbald obern sollen. Die Frage, wie seht ihr denn das tatsächlich? Ja, Duplicate Content ist immer ein Thema. Was bei uns im ersten Moment bezüglich Duplicate Content problematisch ist, ist, wenn eine Website nur aus Duplicate Content besteht, dann kann es sein, dass unsere Algorithmen sagen, gut, wir wissen nicht, ob es sich wirklich lohnt, diese Website zu indexieren. In den meisten Fällen, die so einen Hangouts kommen, die im Forum kommen, ist das eigentlich nicht der Fall, sondern sind da nur entweder Teile einer Seite oder einzelne Seiten innerhalb einer Website, die als Duplicate Content da angesehen werden. Und das ist aus unserer Sicht eigentlich vollkommen okay. Was normalerweise passiert, ist, dass wir versuchen zu unterscheiden zwischen Seiten, die wirklich eins zu eins kopiert sind. Das sind zum Beispiel Seiten, die auf HTTB und HTTPS vorhanden sind. Die sind ja genau die gleichen Seiten. Die versuchen wir zusammen zu klappen und indexieren jeweils nur eine Version. Und andererseits versuchen wir innerhalb von den Seiten auch die Kopien zu finden. Das heißt, jetzt sind zu einem Fall verschiedene Fragen mit Teile von den Antwortblöcken, die gleich sind. Und was wir da machen, ist, wenn jemand gezielt nach etwas sucht, das in diesem duplizierten Bereich ist, zeigen wir einfach eines dieser Seiten an in den Suchergebnissen. Wir merken dann quasi im Snippet würden wir jetzt mehrmals das Gleiche zeigen, weil das in diesem Bereich ist, der kopiert ist. Dann wählen wir eines dieser Seiten aus und zeigen die. Wenn jemand nach etwas anderem sucht auf dieser Seite, zum Beispiel nach der Frage, die gestellt wurde, die ja dann auch unterschiedlich ist, dann kommt das gar nicht ins Spiel. Dann sehen wir da unterschiedliche Seiten. Wir hätten unterschiedliche Snippets auch für diese Seiten. Wir können die alle eigentlich so weit zeigen in den Suchergebnissen. Und von der Qualität her ist das für uns wirklich weniger ein Problem, dass da einzelne Blöcke innerhalb einer Seite kopiert sind, sondern das ist wirklich einfach rein praktisch gesehen eine Frage von, wie sollen die Suchergebnisse aussehen, damit benutzt wir auch wirklich unterschiedliche Snippets in den Suchergebnissen haben und nicht immer den gleichen Lock. Okay, cool, danke. Ich hätte doch noch mal eine Rückfrage zu dem Mobile Index. Wenn wir nicht responsiv gehen, also wenn der Mobile und der Desktop HML unterschiedlich sind, wie stark wird sich das auf SEO Sichtbarkeit auswirken? Du hast es vorhin schon gesagt, Mobile Inhalt wird gekrollt, aber für die SEO Sichtbarkeit werden wahrscheinlich alle Signale übergessüchtet. Für eine Website auf Mobile First Indexing umgeschaltet ist, nehmen wir alles nur von der mobilen Version. Das heißt, wir sehen die mobile Version dann als canonical intern an. Das heißt, alle Links, die zum Beispiel auf die Desktop Version gehen, nehmen wir an, würden ebenfalls für die mobile Version gelten. Vom Ranking her, alle Signale, die wir von der Desktop Version haben, können auf die mobile Version übertragen. Aber es ist nicht so, dass wir die Desktop Version separat dann irgendwie behandeln würden, sondern wir würden die einfach ansehen, wie eine Kopie von der mobile Version und fügen die Sachen einfach so zusammen. Das heißt, von der Sichtbarkeit her, vom Ranking her, ist es wirklich beschränkt wirklich nur auf die mobile Version im Ende. John, ich habe auch noch mal eine Frage zum Mobile Index. Und zwar liegen unsere Side Maps, sowohl die News Side Maps als auch alle anderen, die Archive unter der Hauptdomain BWB, müssen wir die Side Maps, wenn es irgendwann umgestellt wird, auch alle unter der Mobile Version zur Verfügung stellen? Zum Ende des Moment nicht. Wir versuchen, wir versuchen weiterhin diese Verbindung zwischen der Desktop und der mobile Version zu kennen. Und wenn man in der Side Maps-Datei die Desktop Version einreicht, dann sehen wir ja dann auch die Desktop Version, sehen dann die Verbindung zur mobile Version und können das so entsprechend aufnehmen. Längerfristig, weiß ich nicht, könnte mir vorstellen, dass man es vielleicht sagt, in einem Jahr oder so, dass eigentlich macht es mehr Sinn, wenn wir nur die mobile Version in der Side Map sehen. Aber zumindest im Moment ist es so, dass wir da einfach keine Veränderung erwarten, dass man wirklich nur die Desktop Version so jeweils verlinkt in der Side Map-Datei. Auch mit dem REL Canonical schlagen wir vor, dass man weiterhin so arbeitet, dass man die Desktop Version aus Canonical angebt, dass man mit REL Alternative Mobile Version verlinkt. Es sind also Sachen, die sind wahrscheinlich ein bisschen verwirrender, wenn man wirklich eine separate mobile Website hat. Weil man jetzt sagt, der Canonical ist die Desktop Version, Google verwendet aber als Canonical die mobile Version. Für uns ist aber eigentlich nur die Verbindung zwischen diesen beiden Seiten wichtig. Und das macht man halt mit dem Canonical und der REL Alternative Version. Das heißt, alle, die schon aufresponsiv umgestellt haben, haben natürlich jetzt viel weniger zu tun. Ich würde auch noch mal was fragen. Wir haben ja bei Welt.de nicht ganz komplett aufresponsiv umgestellt. Das heißt, wir haben noch, zum Beispiel die Themen Seiten, die haben wir damals leider aus technischen Gründen noch nicht umgestellt. Die sind immer noch über eine M-Welt.de erreichbar. Ist das für Google ein gewisserweise ein Problem oder kann es sogar, wenn du sagst, Mobile First Indexierung, spät ist da eine Rolle für die Bewertung, wann wir vielleicht umgestellt werden? Also, was hat das noch für einen Einfluss, ist es um die Negativ? Wenn man eine saubere M-Punkt-Version hat, ist das total okay. Damit können wir auch leben. Das ist für uns kein Problem. Auch wenn wir beides haben. Also, wenn wir responsiv und engst nur noch so ein klein Teil in eine M-Welt. Genau. Da schauen wir auf einer Seitenebene an. Also, nicht für die ganze Website, sondern für die einzelnen Unterseiten jeweils. Und dann sehen wir dann, da für diese URL ist da die mobile Version hier und für die andere URL ist die mobile Version die gleiche, weil du responsiv ist. Okay, mal schauen, was wir sonst noch bei den Fragen haben. Oder wenn Sachen von euch noch sind, könnt ihr gerne loslegen? Klar, John. Ich habe noch eine Frage aus der User-Generative-Content-Ecke. Aber wir haben natürlich gewisse Herausforderungen mit der Rechtschreibung und Interpunktionen bei uns im Content. Jetzt unterscheiden wir uns dadurch, dass wir ein DGC-Port heißen, natürlich von korratierten Inhalten. Und da war die Frage, die wir im Team diskutiert haben, wenn wir für ein Google tatsächlich das erkennt und berücksichtigt. Oder sagt Google, ja, momentan, das ist ja kein Deutsch. Deswegen erkennen wir da automatisch low quality Content. Was sagt ihr dazu? Normalerweise, was da passiert ist, dass aus einerseits versuchen wir zu erkennen, wo User-Generative-Content ist, damit wir das ein bisschen besser einstufen können. Aber in Grunde genommen sehen wir diese User-Generative-Content-Sachen einfach als Inhalte an, die ihr veröffentlicht und denken, das sind halt die Inhalte, die ihr so bereitstellen wollt. Und wenn da Schreibfehler dabei sind, sind ja auch bei normalen Webseiten Schreibfehler dabei, ist das normalerweise kein Problem. Wenn im Großen und Ganzen aber die Qualität der Inhalte wirklich sehr minderwertig ist, dann schauen wir die Webseite auch an und denken, gut, das sind die Inhalte, die ihr veröffentlichen wollt. Die Inhalte sind eigentlich wirklich nicht gut. Also müssen wir da die Webseite insgesamt vielleicht ein bisschen anders einstufen und denken, vielleicht ist die Webseite insgesamt nicht so vertrauenswürdig oder so gut für normaler Besucher in den Suchergebnissen. Normalerweise ist da die Rechtschreibung, solche Sachen spielt da eher eine kleinere Rolle, sondern wirklich auch die Gesamtmenge der Inhalte, die da halt bereitgestellt werden. Und was man da natürlich machen kann, ist zu versuchen, das ein bisschen selber zu steuern, wenn man da eine Möglichkeit hat, die Inhalte, sag ich mal, ein bisschen zu prüfen oder aufgrund von Eggnriching-Signalen, die man selber sammeln zu merken, das sind gute Inhalte, das sind weniger gute Inhalte, dass man vielleicht die guten Inhalte auf Index stellt und die schlechteren Inhalte auf No-Index automatisch stellt. Wenn man dann später sieht, dass die Qualität von diesen Inhalten sich verbessert hat, kann man das natürlich wieder zurückstellen. Aber einfach, dass man zumindest selber das ein bisschen versucht in den Griff zu kriegen und selber versucht zu sagen, ich möchte wirklich qualitativ hochwertige Inhalte zur Verfügung stellen in der Suche und ich versuche das selber ein bisschen zu steuern, indem ich da, je nachdem die Inhalte kontrolliere oder dass ich da eigentlich die Signale sammle und aufgrund von dem das Ganze ein bisschen selber in die Hand nehme. Okay, danke. Ich vermute, gerade bei User-Generated-Content, die die Rechtschreibung automatisch zu verbessern, das ist wahrscheinlich ein bisschen schwierig, aber möglicherweise kann man das so machen, dass man auch benutzt und hilft, während sie schreiben, dass da mit der Rechtschreibung oder mit dem Qualität von den Inhalten da ein bisschen nachgeholfen wird. Weiß ich nicht, muss man vielleicht mal anschauen. Wir wissen dran, Karjans. Super. Okay, dann... Ich hätte sonst noch eine Frage zu AMP. Okay, okay. Das war so zu einem M-Karossell. Wir haben beim Sternen gemerkt, dass wir auf der Desktop-Ansicht super ranken, in den Newsbox reinbekommen, alles gar kein Problem. Und unter Mobil in den M-Karossellen quasi wie rausgefiltert sind, so wirklich ist. Wir haben uns mit Gubelmitarbeitern, mit AMP Entwicklern unterhalten. Die haben uns mehrfach attestiert, dass es alles technisch korrekt sei. Sieht man auch daran, dass AMP generell funktioniert. Also wir sehen Publisher-Karosselle bei uns, aber in der normalen News-Wombock-Mobil im AMP-Karossell sind wir nicht vertreten. Hast du irgendwie eine Idee, wo man noch draufschauen könnte, wo man es liegen könnte? Und die Entwickler sagen, ja, das ist vielleicht eine Search-Frage oder ein Ranking. Und man sollte sie doch mal öffentlich stellen, insofern hiermit getan. Ja. Ich habe das auch mal hier ein bisschen... gerade mit euren Zeiten. Und ich habe da eigentlich auch nicht Spezielles gesehen, sondern das sieht dann wirklich eher aus wie ein normales Ranking-Problem. Ich gebe das aber auch trotzdem an das Team hier weiter, damit sie das ein bisschen genauer kontrollieren können. Also ich denke auch vom technischen her ist das unproblematisch. Es sind ja auch gewisse Seiten, die werden also aus AMP-Version in den Suchergebnissen dargestellt. Von dem her weiß ich nicht, ob da irgendwas Spezielles vielleicht noch im Spiel ist. Auf jeden Fall sehe ich da nichts Manuelles wegen manueller Maßnahmen auf unserer Seite, sondern das wird wahrscheinlich irgendetwas algorithmisches sein, wo wir vielleicht irgendetwas falsch verstehen aus eurer Sicht, oder wo wir vielleicht irgendetwas sehen, dass ihr dann auch mal verbessern könntet, dass wir zurückgehen können. Ich hätte noch eine Frage zum Thema Sub-Domains. Okay. Und zwar generell, weil wir haben natürlich auch immer Partnerinhalte. Das sind Gutscheine, Reisen etc. Da ist immer die Frage, ob man über einen Verzeichen ist. Gibt es davon Google an der Stelle in der Empfehlung? Also ich weiß das Thema, das ringt besser, wie gesagt immer, dass es egal ist an der Stelle. Aber gibt es sozusagen noch andere Faktoren, die vielleicht höher Sub-Domain oder Verzeichen sprechen? Aber ich weiß ja manchmal auch Partnerinhalte sind die natürlich nicht immer direkt in Nachrichten Bezug haben, sondern sich rund um dieses Thema vielleicht bewegen, aber nicht direkt mit News zu tun haben. Ja. Ich würde solche Sachen, die vielleicht Richtung, sagen wir mal, ein bisschen eher Themen fremd sind, würde ich eher unter den Sub-Domain nehmen, damit wir das ein bisschen besser unterscheiden können. Damit wir auch klarer sehen können, das sind Inhalte, die zu eurem Kerngeschäft quasi gehören, zu den Kerninhalten für die Webseite und das sind andere Inhalte, die wir ebenfalls da sehen. Und dann kann man das ein bisschen einfacher von unseren Algorithmen her auch unterschiedlich behandeln. Ein Ort, wo das häufig vorkommt, wahrscheinlich jetzt weniger bei den Nachrichtenseiten, aber wenn man Adult Content noch dabei hat, dann ist es für uns immer hilfreicher, wenn wir wirklich feststellen können, in diesem Sub-Domain ist Adult Content. Da können wir Safe Search anwenden und im Rest von der Webseite wissen wir, dass wir da mit Safe Search nicht unbedingt gezielt arbeiten müssen. Und je einfacher wir eine solche Unterscheidung machen können, wenn es wirklich etwas grobes ist, was wir unterscheiden müssten, dann geht es einfach so. Im Gegenteil, wenn wir wirklich alles in einem Domain sehen mit unterschiedlichen Verzeichnissen einfach, dann kann es passieren, dass wir sagen, gut, all diese Inhalte sind ein Teil von der Kern-Webseite und dann müssen wir die Qualität von der gesamten Webseite quasi im Schnitt nehmen von all diesen Inhalten. Danke. Ich habe noch eine Frage zum Mobile. Wir sehen bei Mobile einigen Titeln in den letzten Wochen, dass es nach oben geht, bei anderen eher nach unten. Und von unserer Seite läuft ja auf der... alles auf der gleichen Infrastruktur und können jetzt nicht so richtig nachbeziehen, warum das so jetzt ist. Habt es irgendwelche Neubewertungen, wird es ja irgendwas im Mobile-Mix, was jetzt in den letzten zwei, drei Wochen ja, aktualisiert worden ist? Wo siehst du dann die Unterschiede? Also wir sehen die Unterschiede, also gerade auf Mobile, bei den Abo-Titeln, das ist also zum Beispiel KSDA und dann MZ, da geht es ein Stückchen nach unten, aber bei Boulevard-Titeln, die Express geht es dann nach oben. Wir konnten das bisher nicht an nichts festmachen, wo inhaltlich ist, haben wir ja unsere Arbeit nicht verändert. Also es ist ja wie bisher, aber trotzdem sind Bewegungen irgendwie festzustellen. Deswegen Freie, habt ihr da was um Algorithmus in den letzten Wochen verändert, oder glaubst du da keine? Also geändert haben wir natürlich sicher was, aber ob das jetzt gezielt auf irgendwas zurückzuführen ist, ist immer schwierig, weil Änderungen machen wir und da ist eigentlich fast täglich immer irgendwas dabei. Und manchmal bei den Änderungen ist es so, dass wir die anschauen und denken gut, das ändert relativ wenig, aber es betrifft dann halt einzelne Websites trotzdem ein bisschen mehr, also mehr an der Sichtbarkeit als bei anderen. Aber mir fällt jetzt nicht, nicht auf Anhieb, irgendwas gezielt auf Mobile, sondern da eine Änderung wäre. Eben Änderungen sind soweit eigentlich normal. Das sollte eigentlich schon beggemäßige Veränderungen geben, dass wir da versuchen, das ein bisschen besser einzupenden. Und das verändert sich natürlich auch im gesamten Ecosystem, dass da die Benutzer-Awartungen verändern sich teilweise und dann kann man nicht sagen, nur weil man jetzt in den letzten paar Jahren so gerankt hat, wird man weiterhin so ranken. Das kennt ihr wahrscheinlich alle, oder? Es ist eine Verschiebung Richtung Boulevard-Westen-Team, dass die jetzt bevorzugt. Ja. Die Lokalen eher weniger. Das klingt allerdings komisch. Könnte man nicht vorstellen, dass das absichtlich so ist, vielleicht hat sich das irgendwie bei diesen Seiten so ergeben. Aber was für mich da immer praktisch ist, wenn ich einzelne Suchbegriffe habe, wo man das gezielt auch feststellen kann, wo man sagen kann, da ist eigentlich etwas viel schlechter als vorher. Das heißt, wenn ihr so allgemeinere Suchbegriffe habt, vielleicht zwei, drei Wörter maximal, die wahrscheinlich häufiger gesucht werden, wo man sagen kann, objektiv gesehen sind die Suchergebnisse schlechter als vorher, weil die Sachen eher in erster Stelle ranken als nachher, dann sind das Sachen, die wir gerne an das Qualitätsteam weitergeben, damit sie entsprechend auch die Algorithmen ein bisschen verbessern können in dieser Richtung. Aber manchmal ist es auch sehr schwierig, dass man sagt, gut, erster und zweiter Position sind jetzt geweckt, haben jetzt getauscht. Ist das jetzt besser oder schlechter? Darüber lässt sich dann streiten. Okay, danke. Ich hätte da vielleicht eine kurze Anschlussfrage, gerade wenn es um Rankingveränderungen geht. Wir haben so ein Entertainment-News-Portal und haben im Co-Update ganz schön gelitten am letzten im August. Es hat sich danach ein bisschen wieder begangen. Wir konnten allerdings bis dato keine wirkliche Erklärung finden, dass was alles public war, so was wie, ein Medic-Update gewesen oder es geht um Authority und Relevanz. Da hat sich in unserer Art und Weise wie wir die Newscheiben eigentlich nicht größer verändert gehabt. Also, wir machen immer Qualitätsjournalismus. Von daher fragen wir uns, woran es vielleicht gelegen haben könnte. Du hast ja schon gesagt, dass du die Seiten angeschaut hast, vielleicht hast du zufällig etwas gesehen? Ich fühle sich nichts, was, worauf ich jetzt irgendwie hinseiden könnte. Ich denke gerade mit den ganzen Core-Updates ist es natürlich immer ein bisschen schwierig, weil zum Teil verändert sich da einfach die Art und Weise, wie wir die Relevanz von Seitenversuchung feststellen. Das heißt nicht unbedingt, dass die Seiten schlechter sind, sondern, dass wir denken, die sind jetzt vielleicht nicht mehr so relevant für diese einzelnen Suche entfragen, wie sie früher mal waren. Was ich da immer, was ich zeigen kann, ist einerseits den Quality-Radar-Guidelines, dass man die vielleicht mal durchgeht und überlegt, was das da passen würde. Andererseits den älteren Blog-Post von Amit Singhal von, ich weiß nicht, 20-jährigen, irgendwelchen Fragen, wie man sich stellen kann über die Qualität einer Webseite, dass man das mit jemandem, der nicht direkt mit der Webseite verbunden ist. Man kann ein bisschen objektiver beurteilen kann, wo gibt es vielleicht Bereiche, wo wir mit der Qualität etwas verbessern können, oder wo wir die Qualität ein bisschen besser sichtbar machen können, sodass wenn ein Benutzer auf die Seite kommt, dass man wirklich erkennt, ah, das ist nicht von irgendwelchen Schülern eine Zeitung geschrieben worden, sondern es ist auch hochstehende Journalismus. Dahinter stecken die Autorenprofile und die Situation, dass das wirklich auch möglichst klar ist von Anfang an, wenn man das anschaut. Eine Sache, die da vielleicht auch immer ein bisschen ins Spiel kommt, ist, dass viele von diesen algorithmischen Anpassungen werden in erster Linie in Amerika gemacht und in Amerika zusammengestellten getestet. Wir testen zwar schon auch andersprachige Inhalte, aber es kann manchmal sein, dass es gerade bei Sprachen, die nicht so häufig verwendet werden, dass wir das nicht so 100 % hinkriegen. Das heißt, wenn ihr seht, dass eigentlich mal gute Websites schlechter wegkommen mit solchen Qualitätsupdates oder allgemein Ranking-Updates, dann sind solche Beispiele für uns sehr wichtig. Ich denke, Deutsch ist wahrscheinlich eine Sprache, die häufig genug gesprochen wird, dass man das einigermaßen hinkriegen sollte. Aber gerade wenn die Inhalte in irgendwelchen Sprachen sind, die wirklich auch nur in kleineren Ländern gesprochen werden, dann könnte ich mir schon vorstellen, dass wir da manchmal mit den Ranking, mit den Algorithmen da Probleme haben, das zu beurteilen, ob wir das hinkriegen oder nicht hinkriegen. John, in dem Kontext habe ich tatsächlich auch noch mal eine Frage, weil wir uns jetzt weiterhin im User-Generative-Kontext-Bereich, aber trotzdem ein generelles Thema, ist das, wenn man ein horizontales Themenportal ist. Das bedeutet, dass ich also sehr, sehr viele Themenfelder habe, aber nicht wirklich so ein klar erkennbaren Fokus auf irgendein Themenbereich habe. Ich immer mehr Spürigkeiten habe, aktuell und vielleicht auch in Zukunft mit Nischenportalen zu konkurrieren. Nischenportal ist für mich ein sehr, sehr spitzes Portal, das sich thematisch sehr stark fokussiert. Und wenn ich jetzt mal davon habe, dass ich vielleicht den Content in ähnlicher Qualität habe und die Quality Rate Guidelines auch schön brav befolge, dann stellt sich uns gerade in der Diskussion die Frage, hat denn dieses breitaufgestellte Portal im Vergleich zu diesen spitzen Nischenportalen überhaupt noch eine Möglichkeit jetzt in Zukunft ähnliche Rankings und Trafficpotentiale aufzubauen, wie das eben in der Vergangenheit ja relativ, ich sage mal, einfach her, tatsächlich möglich war. Und speziell wenn man die Co-Updates so anschaut, dann könnte sich da ja auch eine Richtung abzeichnen. Ich würde sagen, dass beide, beide Varianten ihre Berechtigung haben. Manchmal macht es Sinn, dass man wirklich auf ein, sag ich mal, ein Portal zeigen, wo wir wirklich auch tiefe Zwachwissen haben. Manchmal macht es aber auch Sinn, dass wir eher auf ein breiter Gefechtes Portal zeigen. Je nachdem wieder besucht, der Benutzer natürlich sucht. Wenn wir erkennen können, dass jemand wirklich nach wissenschaftlichen Informationen sucht, dann macht es vielleicht nicht Sinn, dass man ihn auf irgendein allgemeines Frage-Antwort Portal schicken, sondern vielleicht eher auf ein gezieltes. Wenn das jedoch jemand ist, der vielleicht nicht so viel tiefe Informationen zu diesem Thema sucht, dann ist vielleicht ein breitgefächertes Portal ein bisschen besser. Im Grunde genommen ist es natürlich auch immer eine Frage davon, wie gut kann man quasi diese einzelnen Portale auch unterstützen insgesamt. Das heißt, nicht unbedingt von unserer Seite her, sondern vom ganzen Ecosystem her. Wenn viele auf ein allgemeines Portal gehen, dann ist das natürlich für uns praktisch. Dann sehen wir natürlich sehr schnell, dass da eigentlich viele gute Signale hingehen. Wenn man ein eingeschränktes Portal macht, nur für ein einzelnes Thema, dann ist es manchmal ein bisschen schwieriger zu erkennen, dass da wirklich genügend Signale zusammenkommen, um zu sagen, dass es Macht wird sehen. Das heißt, es lohnt sich wahrscheinlich in den meisten Fällen nicht, dass man sagt, ich nehme ein allgemeines Portal und teile es in einzelne Nischenportale auf, weil die einzelnen Nischenportale dann einfach nicht einzeln genug Unterstützung haben, dass wir die auch sauberen Suchergebnisse zeigen könnten, zum Beispiel. Aber irgendwo dazwischen gibt es wahrscheinlich auch Berechtigungen für beide Varianten, dass man sagt, das ist jetzt wirklich ein sehr tiefes Portal, wo sehr viele Informationen zu einem ganz speziellen Thema vorhanden sind. Und das können wir dann auch zeigen. Wenn jemand gezielt nach diesen tieferen Informationen sucht, wenn wir jedoch sehen, dass das eher allgemeinere Suchen sind, dann zeigen wir vielleicht eher auf einen Portal, wo wir sagen können, da wird in der Sprache vom Benutzer gesprochen. Da verstehen Sie auch die Antworten, die gegeben werden. Danke dir. Hast du noch Zeit für eine? Ja, machen wir doch. Eine ganz schnelle, aber vielleicht ein bisschen tricky. Wir verteilen teilweise Content an andere Webseiten. Und wir haben die Problematik dabei, dass die Zielseite quasi eine Canonical auf uns als Quelle setzt. Sie hat den Canonical aber komplett ignoriert. Ich könnte mir vorstellen, dass das teilweise durch solche Faktoren wie die externe Seite wird vielleicht ein bisschen schneller geladen. Oder meinetwegen, vielleicht ist sie sogar ein bisschen älter, I don't know, ich weiß es nicht. Aber wir haben das Problem halt immer wieder. Und da stellt sich intern als so ein bisschen die Frage, wie geht man damit strategisch um? Das sind zwei Sachen, die da zusammenkommen. Einerseits ist es so, dass wir den Canonical erst im zweiten Moment quasi verarbeiten. Das heißt, wenn wir die Seite zum ersten Mal crawlen und indexieren, nehmen wir die Inhalte erst mal, wie sie da sind. Und dann haben wir quasi beide Varianten bei uns im Index. Und dann je nachdem, wie gesucht wird, nehmen wir die eine oder die andere Version. Wenn wir den Canonical Link gesehen haben und gesehen haben, dass die Seiten an und für sich equivalent sind, dann gibt es verschiedene Faktoren, die dazu zusammenkommen bei der Wahl von Canonical. Das heißt, wir sehen dann im ersten Moment diese beiden Seiten gehören eigentlich zum gleichen Cluster. Also die quasi eine Gruppe von Seiten, die die gleichen Informationen haben. Wir nehmen dann den Canonical Link dazu. Wir nehmen dann die interne, externe Verlinkung dazu. HF Lang, wenn irgendetwas so was vorhanden ist, nehmen wir dazu all die quasi Signale, die wir sehen können zwischen diesen beiden Seiten und versuchen dann aufgrund von denen eines dieser beiden Seiten auszusuchen und die dann aus Canonical zu sehen. Wenn man natürlich Inhalte von einer ganz neuen Website auch auf einer sehr starken bestehenden Website veröffentlicht, dann kann es natürlich sein, dass die ganzen internen und die ganzen linkbasierten Signale dann eher sagen, gut, die bestehende Website sieht einfach viel stärker aus. Das ist wahrscheinlich eher der Canonical. Das wird dann eher in die Richtung stehen. Auch wenn ein World Canonical in die andere Richtung zeigt. Weil ein von den Problemen, die wir immer wieder sehen, ist, dass World Canonical falsch eingesetzt wird. Und wir sehen dann diesen Link zwischen diesen beiden Seiten, aber wir wissen dann nicht genau, ja, gut, ihr sagt, die Seiten sind equivalent, aber soll man wirklich der Zielseite folgen oder können wir auch der Ursprungsseite nehmen als quasi Canonical für die Indexierung. Das heißt, ich denke, praktisch gesehen ist es für euch dann halt eine Frage, wie wollt ihr da vorgehen. Ich denke, man muss immer ein bisschen damit rechnen, dass manchmal der Canonical nicht genommen wird. Und manchmal ist es trotzdem okay, wenn zum Beispiel in Bericht dann steht, gemäß dieser und dieser Website, das und das und das. Dann ist das vielleicht trotzdem noch für euch wertvoll genug, dass ihr sagt, das funktioniert für uns. Wenn ihr wirklich nur eure Seite indexiert haben wollt, dann macht es vielleicht Sinn, die Inhalte nicht weiter zu geben. Aber wenn ein Canonical als Empfehlung sozusagen betrachtet, macht das vielleicht dann Sinn, dann indexieren wir die Inhalte einfach auf beiden Zeitpreis? Kann man auch machen. Was mit dem Canonical passieren wird, also wenn wir die zusammenklappen, dann können wir auch die Signale zusammenklappen. Das heißt, die Signale werden dann auch ein bisschen stärker für uns. Das heißt, vom Ranking her hat man schon ein bisschen Vorteil, wenn man sagen kann, diese verschiedenen Seiten kann man aus einer Seite betrachten. Die müssen dann nicht gegeneinander konkurrizieren, sondern wir können wirklich sagen, die im Ranking ein bisschen besser auch zeigen. Okay, machen wir vielleicht noch eine Frage? Ja, wir haben vom Tag gespielt, wir hatten noch eine. Und zwar bezüglich Google News. Wir publizieren unveränderte Alentur-Meldungen. Die publizieren wir manuell, nicht automatisch. Und die werden in der Regel nie bei Google News angezeigt. Wohingegen von anderen Publishern, die auch original unverändert Alentur-Meldungen haben, angezeigt werden. Was fragen wir uns ein bisschen, warum? Liegt es nur daran, dass wir zu langsam sind? Oder ... Ja. Vielleicht weiß ich jetzt nicht, also einerseits weiß ich nicht, wie das bei Google News gehandhabt wird. In der Websuche wird das wahrscheinlich in Richtung Duplicate Content hinlaufen, dass wir sagen, wir sehen die Inhalte, wir erkennen, dass das eigentlich die gleichen sind, wie wir schon kennen und dass wir die dann nicht nochmal indexieren müssen. Ich weiß nicht, wie das bei Google News gehandhabt wird, ob das da vielleicht ein bisschen anders gemacht wird. Okay, danke. Okay. Dann machen wir doch vielleicht hier ein Pause. Vielen Dank für's Kommen. So zahlreich, was super. Ich hoffe, das war hilfreich für euch und dass wir da die meisten Fragen mal durchgehen konnten. Wenn weitere Sachen kommen, könnt ihr natürlich gerne auch in Webmaster-Hilfeform nachfragen oder in den normalen Webmaster-Hangouts, die wir auch ab und zu machen. Das stelle ich, glaube ich, die für nächste Woche, demnächst ein. Dann könnt ihr die Fragen dort auch einkoffieren. Okay. Vielen Dank nochmal. Danke. Danke. Danke. Tschüss.