 Okay, herzlich willkommen beim heutigen Google Webmaster Central Sprechstunden-Hangout. Mein Name ist Johannes Müller, ich bin Webmaster Trans Analyst bei Google in der Schweiz und arbeite zusammen mit dem Websearch-Team hier in der Schweiz und in Amerika und überall bei Google. Wir haben jetzt einen speziellen Hangout gemacht für Nachrichten Websites aus Deutschland. Es sind schon ganze Menge hier bei uns im Hangout dabei. Wollt ihr euch vielleicht auch kurz vorstellen, wenn ihr Lust habt, nicht notwendig? Wollen wir, wir anfangen? Hier ist Anni von Welt.de und Fabian auch von Welt.de und Orgen von Welt. Wir sind die Guten. Wollen wir? Das ist aber schön. Okay. Und alles Gute zum Frauentag. Irgendwo sind vielleicht noch so YouTube-Fans da auch. Wir sind die Guten. Wir sind die Guten. Wir sind die Guten. Wir sind die Guten. Wir sind die Guten. Wir sind die Guten. Wir sind die Guten. Wir sind die Guten. Irgendwo sind vielleicht noch so YouTube-Fans da auch. Ich höre irgendwie so wie alles noch mal im Hintergrund. Gibt es noch weitere, die Sie vielleicht kurz vorstellen wollen? Ja, da machen wir doch mal weiter. Wir sind von Hubbard, Buda Media, Konrad und Kloge. Wir sind auch alles Gute zum Welt-Frauentag. Super. Ich bin der Maik aus Zürich und ich komme von 20 Minuten. Hallo? Hallo. Mein Name ist Kat, ich bin vom Staden aus Wien. Super. Sehr gut, dann mache ich weiter. Hi, mein Name ist Christian. Ich bin von der Funke Media Group. Ja, und hier sind Till, Daniel und Martin. Hallo? Ich habe keine Toden. Irgendwas stimmt da nicht. Jetzt hören wir dich. Ja, hören dich. Hallo, hier ist die Melanie. Ich bin vom Gute-Fragen-Net. Hallo. Hallo, ich bin der Eduard, heute für DEMO im Einsatz. Alles Gute zum Vorantag, genau. Ich glaube, da haben wir sogar alle durch. Super. Wie gesagt, wir machen das ein bisschen speziell für die Nachrichten-Websites. Die Fragen, die eingereicht worden sind, sind zum großen Teil von euch. Und ich gehe dir ein bisschen durch. Es gibt einige Bereiche, wozu ich nicht wahnsinnig viel sagen kann, das betrifft eigentlich den Bereich Google News selbst. Das heißt, alles, was so umgrund um den Publisher-Center geht oder um spezielle Arten, die man die Daten einreichen kann bei Google News, kann ich nicht wirklich weiterhelfen. Aber viele der Themen sind ja eher allgemein oder sind auch bezüglich Websearch. Und da kann ich hoffentlich ein bisschen helfen. Ich habe mir einige der Fragen mal zusammengestellt, wenn ihr zwischendurch weitere Fragen dazu habt oder wenn irgendetwas unklar ist oder wenn ihr sonst irgendwie etwas habt, was ihr unbedingt noch eingringen wollt, einfach nur loslegen. Dann machen wir es ein bisschen interaktiver, auch wenn ihr Lust habt dazu. Ein Bereich, der oft gefragt wurde, ist alles rund um Mobile First Index. Ich denke, das ist ein Thema, das immer ein bisschen im Hintergrund herumschwert. Wir haben ja schon seit einiger Zeit darüber gesprochen. Und fangen jetzt demnächst langsam damit an, das ein bisschen größeren Nütztipel auch einzuführen. Eine Frage war der Zeitpunkt der Einführung. Für uns ist es so, dass wir das nicht von einem Tag auf den anderen einführen wollen, sondern wir versuchen, das so einzuführen, dass wir die Websites erkennen, bei denen das unproblematisch ist und dass wir die dann Schritt für Schritt quasi umstellen. Das heißt, eigentlich ist die Idee, dass wenn eure Website gut funktioniert auf Mobile, dann sieht ja eigentlich keinen großen Unterschied, weil eigentlich sollte das einfach weiter funktionieren. Websites, die separate Mobile-Zeiten haben, da ist es natürlich ein bisschen schwieriger, als zum Beispiel mit einer Responsive-Website. Bei einer Responsive-Website haben wir einmal die ganzen Inhalte und egal mit welchen Geräten man die anschaut, die gleichen Inhalte. Und da funktioniert das auf jeden Fall. Eine Frage, die eingereicht worden ist, es gibt spezielle Hinweise, wenn man eine m.dot-Domain hat, was muss man da machen. Aus unserer Sicht ist es so, dass das weiterhin eine Art ist, wie man mobile Websites machen kann. Aus praktischer Sicht ist es natürlich so, dass man da immer ein bisschen mehr Schwierigkeiten hat, an diese zwei Versionen der Website und muss dann die beiden Versionen irgendwie auch verwalten und aufrecht halten und immer auch ein bisschen darauf achten, wie wird das intern verlinkt, wie wird das von quasi extern verlinkt, wie arbeitet man mit Canonicals. Das sind alles Themen, die anfühle sich nicht neu sind, aber die gerade im Bereich Mobile-First Indexing sind natürlich ein bisschen relevanter. Weil früher war es eher so, dass wir uns einfach nur auf die Desktop-Version konzentriert haben und wenn da alles stimmt, dann ist alles, was auf der mobilen Seite ist quasi irrelevant, mehr oder weniger. Jetzt ist es allerdings dann so, dass wir eher die mobile Seite dann indexieren und wenn die mobile Seite wirklich wesentlich weniger Inhalte hat oder zum Beispiel Structured Data nicht verwendet, die hreflang Attribute nicht verwendet, mit dem Canonical nicht sauber arbeitet, dann wird das da eher ein Problem geben. Das heißt, es ist nicht so, dass man speziell etwas anders machen muss, sondern man muss einfach das umsetzen, was eigentlich schon seit Jahren quasi als Best Practice eingeführt wurde. Weitere Fragen waren dann noch bezüglich quasi den Inhalten selber auf der mobilen Seite, ob man da etwas speziell machen muss, weil auf mobilen Seiten sind oft weniger Inhalte drauf. Für uns ist natürlich so, dass wir die Inhalte der mobilen Seite indexieren und dann eigentlich die Desktop-Seite gar nicht groß anschauen. Wir kontrollieren einfach, dass es noch einigermaßen zusammenpasst, aber wir konzentrieren uns wirklich auf die mobile Seite. Das heißt, wenn zum Beispiel Text auf der mobilen Seite nicht vorhanden ist, dann ist das vielleicht ein Problem. Wenn Structured Data gar nicht mehr vorhanden ist auf der mobilen Seite, dann ist das auch ein Problem. Wenn allerdings die Inhalte nicht direkt sichtbar sind auf der mobilen Seite, aber trotzdem auf der Seite selber sind, dann ist das für uns auch problematisch. Damit können wir eigentlich problemlos umgehen. Wenn zum Beispiel Breadcrumbs je nach Geräte-Typ und Größen nicht direkt sichtbar sind, aber oft im Markup der Seite selber sind, dann ist das allen für sich okay für uns. Das geht dann auch ein bisschen weiter in Richtung Search Console von dort. Wie müssen wir die verschiedenen Subdomains einrichten in Search Console, damit das alles klappt? Was mit dem Mobile First Indexing passieren wird, gerade wenn man ja einen End-Dot-Domain hat, ist, dass wir eher die Daten in der mobilen Version dann zeigen. Das heißt, wenn ihr jetzt separat ein End-Dot-Domain habt und wir schalten eure Website auf Mobile First Indexing um, dann wird es so sein, dass die Daten, die bisher der Desktop-Version vorhanden waren, dann nach einer mobilen Version vorhanden sind. Zumindest ist das der Moment, der stammt. Das heißt, wenn ihr zum Beispiel Information über die Sichtbarkeit in der Desktop-Version anschaut, wenn ihr die Rankings, die Clicks & Impressions anschaut in Search Console, dann werden diese Daten in erster Linie Richtung mobilen Version rüber verschoben werden. Das heißt, ihr müsst, wenn ihr jetzt ein Vergleich mit der Vergangenheit anstellen wollt, dann müsst ihr wirklich beide Versionen anschauen und auch sicher sein, dass beide Versionen verifiziert sind in Search Console, damit ihr wirklich auch das volle Bild der Daten habt. Wir sind immer noch ein bisschen am Schauen, wie man das ein bisschen einfacher machen kann in Search Console, ob man da die Daten irgendwie kombinieren kann oder wie man das am besten anstellt. Vermutlich wird es so sein, dass wir einfach eine Markierung setzen in Search Console und sagen, ihr müsst jetzt die mobilen Version ab diesem Datum anschauen, damit man zumindest weiß, wann man rüber wechseln muss. Was man machen kann in Search Console ist mit Property Sets arbeiten, das ist eine Art, die man verschiedene Websites zusammennehmen kann und da einige Informationen quasi gemeinsam führen kann. Das ist im Moment in der neuen Search Console noch nicht unterstützt, das kommt aber auch. Und so kann man zumindest im Bereich Search Analytics dann immer noch das Gesamtbild anschauen. Das heißt, das sind dann die mobilen Version, die Desktop Version zusammen. Und da sieht man selbst, wenn wir ein Wechsel von der Desktop Version auf die mobile Version machen, sieht man eigentlich dann immer noch durchgehend Informationen über die Clicks und Impressions, solche Sachen. Das heißt, eben all diese Sachen sind ein bisschen Schwierigkeiten, die gerade mit einem End-up-Domain dann noch dazukommen. Das heißt, wenn ihr im Laufe vom Jahr überlegt, ob wir auch responsive wechseln oder mit einem Domain arbeiten, statt mit diesem Subdomain, das sind vielleicht auch das Argumente, die euch das Leben längerfristig ein bisschen einfacher machen. Sind vielleicht von euch noch einige Fragen zum Mobile First Indexing, bevor ich da weiter gehe. Noch nicht. Okay, gut. Okay, dann noch ein paar Fragen zu Search Console. Wie heutig werden die Daten in Search Console aktualisiert? An und für sich wird das unterschiedlich schnell aktualisiert. Das heißt, einige Bereiche sind fast sofort sichtbar. Das sind zum Beispiel Bereiche, wie die Seiten, die entfernt worden sind, die Sitemapsindexierungszahlen, solche Sachen werden mehr oder weniger sofort aktualisiert. Andere Daten werden eher täglich aggregiert. Das heißt, wir haben verschiedene Systeme, die unsere Websearch-Pipeline durchgehen und den aktuellen Stand abrufen und das dann in Search Console übertragen. Das passiert täglich zu unterschiedlichen Seiten, wahrscheinlich so verteilt über den Tag hinweg. Aufgrund von der Art und Weise, wie die verschiedenen Pipelines innerhalb von Google zusammenhängen, kann es sein, dass es da einige Tage Verschiebungen auch gibt. Das heißt, gerade bei Search Analytics ist es so, dass wir erstmal die Daten für den Tag aktualisieren müssen und dass wir in einem System abgespeichert, zum nächsten System weitergegeben am nächsten Tag und vielleicht am dritten Tag oder so ist es dann sichtbar in Search Console. Das sind so Sachen, die versuchen, ein bisschen schneller hinzukriegen, aber im Moment ist das immer noch so, dass man da wie eine Zeitverzögerung entsprechend auch hat. Je nachdem, welche Funktion man natürlich anschaut in Search Console, ist eine Bereitstellung der Search Console-Daten für 13 Monate geplant, um einen Vergleich für den Vorjahresmonat zu haben. Mit dem neuen Search Console in der neuen Search Analytics, ist es so, dass wir 16 Monate anziehen. Das heißt, man kann sogar den gleichen Quartal vom letzten Jahr noch mal vergleichen. Es ist nicht ewig, aber ich denke, das hilft schon viel, wenn man ein bisschen mehr als ein Jahr Daten auch anschauen kann. Für einige Websites braucht es einfach eine gewisse Zeit, bis wir diese Daten alle angesammelt haben. Und wie gesagt, wenn man eine m.dot-Domain hat und eine desktop-Domain, dann muss man einfach darauf achten, dass man diesen Wechsel dann auch merkt, nicht, dass man das Gefühl hat, dass alle Daten jetzt auf einmal weg sind, wenn man auf m.dot gewechselt haben. Es gibt auch diverse Tools, die die Daten in Search Console automatisch herunterladen, dass man quasi selber ein Archiv von diesen Daten hat, gerade für Search Analytics. Es gibt eine API für die ältere Version von Search Analytics, wo man die, was sind das, glaube ich, 90-Tage-Daten bekommen kann. Mit dem kann man natürlich die Daten auch automatisiert herunterladen. Wir planen die API auch zu erweitern für die neue Search Console, dass man wirklich auch die vollen 16 Monate herunterladen kann. Dann gibt es da eine Frage, die ähnlich ist wie vorher, wie mit dem aktualisierenden Daten, ist es geplant, vielleicht Echtzeitprobleme in Search Console irgendwie anzuschauen. Kann man das irgendwie ein bisschen schneller hinkriegen, dass man da gerade bei Nachrichten noch schnell merkt, wenn man etwas falsch gemacht hat. Im Moment ist das so, dass die Daten einfach aggregiert werden, und da geht es manchmal ein bisschen länger. Wir planen aber, dass wir da diverse Systeme haben, um diese Daten ein bisschen schneller zu erkennen und dass wir zumindest euch Nachrichten schicken können. Durch Search Console und sagen können, hey, aktuell, jetzt im letzten paar Stunden, haben wir gesehen, dass dieses Problem vermehrt aufgetreten ist mit eurer Website. Das müsst ihr unbedingt sofort anschauen. Ihr seht das vielleicht noch nicht in Search Console, aber das ist ein grundlegendes Problem, was wir gerade gesehen haben. Gerade bei Crawling-Problemen könnte man das natürlich eher so machen. Indexierungsprobleme sind dann ein bisschen schwieriger, aber meistens braucht das auch eine gewisse Zeit, wenn man das aber erkannt wird. Und bis wir auch erkennen können, ob da wirklich ein Fehler vorhanden ist oder ob ihr vielleicht einfach selber diese Sachen gelöscht habt oder ob das Sachen einfach absichtlich nicht sauber indexiert werden können, so wie sie vielleicht früher waren. Weil das will man ja auch, die Möglichkeit haben, das selber zu steuern. Okay. Dann, im Rahmen vom Datenschutzgesetz müssen wir bei allen User die Cookie-Zustimmungseite erst mal zeigen. Und erst nach der Zustimmung dürfen die User die Website benutzen. Wie würde Googlebot mit diesem Szenario umgehen? Es hängt sehr davon ab, wie ihr das implementiert. Das macht es vielleicht ein bisschen schwieriger, auch bezüglich, wie ihr das implementieren dürft oder was ihr da machen müsst. Einerseits ist es so, dass Googlebot in erster Linie aus America crowd, das heißt, für euch speziell ist das vielleicht hilfreich. Weil ihr könnt zum Beispiel sagen, Benutzer aus Amerika dürfen unsere Website zuvor sehen. Wir müssen da vielleicht nicht irgendetwas vorschalten. Und dann ist es so, dass Googlebot einfach die Seite sieht, wie jeder andere Benutzer aus Amerika und wenn Googlebot dann direkt auf die Inhalte kommt, ist das überhaupt kein Problem. Schwieriger ist es natürlich, wenn ihr eine Zustimmungseite zeigen müsst, dann ist es so, dass wenn ihr ein redirect auf eine Zustimmungseite macht, dann ist das für uns ein bisschen schwieriger. Weil wir müssen dann erst mal erkennen, dass von dieser Seite es geht eigentlich zurück zu den eigentlichen Inhalten. Idealerweise würden wir einen Link finden zu den eigentlichen Inhalten, damit wir diese Inhalte auch irgendwie crowd und indexieren können. Wenn man die wirklich nicht wegen einem Knopf gedrückt hat auf einer Seite, dann wird es wahrscheinlich so sein, dass wir die Seite nicht sauber indexieren können. Weil Googlebot speichert in der Regel keine Cookies ab. Das heißt, es ist nicht so, dass bei der zweiten Abfrage dann Googlebot diesen Cookie ausliefern kann und sagen kann, ja, ich habe zugestimmt. Das macht es natürlich ein bisschen schwieriger. Eine andere Variante ist, dass man diesen Zustimmungseite quasi als Overlay macht mit JavaScript oder mit HTML, so dass die eigentlichen Inhalte im HTML noch dabei sind, aber für Benutzer nicht auf den ersten Blick sichtbar sind. Dann ist es meistens so, dass Googlebot damit immer noch umgehen kann und sagen kann, ich sehe das zwar ein großes Overlay hier, aber eigentlich sind die Inhalte auf dieser Seite. Ich kann sie trotzdem indexieren. Für uns ist das nicht optimal, weil wir nicht vorstellen können, wie sind diese Inhalte wirklich auf der anderen Seite. Das macht es ein bisschen schwieriger. Meistens klappt das aber trotzdem. Das sind hier Sachen, die sind nicht unbedingt neu. Gerade bei je nach Website-Typ ist es natürlich so, dass man sowieso schon irgendein Overlay haben musste. Sei es, dass es vielleicht irgendwelche erwachsene Inhalte sind oder dass es ein Alkohol-Website ist, wo man irgendein Altersangabe bestätigen muss. Es gibt ja auch diverse Plugins für WordPress zum Beispiel. Und mit den meisten kommen wir eigentlich sehr gut zurück. Dann haben wir da zum Indexierung diverse Fragen gerade bezüglich quasi der Menge an Seiten, die eingereicht worden sind. Bei Nachrichtenwebsites ist das ja auch immer ein bisschen ein Thema. Unser Titel bei ungefähr gleicher Seitenzahl stark unterschiedliche Anzahlseiten indexiert. Manchmal haben wir zum Beispiel 380.000 indexiert, beim anderen nur 200.000 indexiert. Bei einer anderen Frage waren es, glaube ich, 900.000 eingereicht und davon sind nur 140.000 indexiert. Ist das ein Problem? Woran kann das hängen? Es ist so, dass es gibt diverse Sachen, die ein bisschen da zusammenspiegeln. Einerseits ist es vom Crawling her. Natürlich eine Frage, wie das alles aufgebaut wird. Das heißt, wir müssen die Seiten ja erst mal irgendwie erkennen. Wir müssen sie irgendwie finden können. Über eine Signalt-Datei finden wir diese URLs relativ schnell. Und so könnten wir die relativ schnell crawlen. Wenn wir sicher sind, dass der Server das verträgt, versuchen wir die dann auch zu crawlen. Das hängt ein bisschen davon ab, wie das eingerichtet ist auf der Website. Es ist so, dass wir das pro Server versuchen zu erkennen. Und wir versuchen zu erkennen, wie viel verträgt der Server, bevor der Server ein bisschen langsamer wird, bevor wir merken, dass wir eher Probleme verursachen, als dass wir da eigentlich helfen durch das Indexieren und Crawling von weiteren Seiten. Das heißt, wir schauen, wie schnell es nicht die gleiche Zeit, die es braucht und die Seite quasi aufzuladen im Browser, sondern die Zeit, die es braucht bis die HTML-Dateien effektiv ausgeliefert werden an uns. Das ist ein Faktor, ein anderer Faktor ist, wie viel Fehler wir sehen beim Crawling. Und das betrifft nicht 404 Fehler, sondern vor allem Server Fehler. Das heißt, wenn wir viel crawlen und wir sehen viele Server Fehler, dann nehmen wir an, dass wir vielleicht ein bisschen zu viel machen und uns ein bisschen zurückhalten müssen, damit der Server nicht überlastet wird durch unser Crawling. Und so halten wir uns ein bisschen zurück. Das sind die Hauptfaktoren da. Was dann noch dazu kommt, ist natürlich, dass wir nicht einfach beliebig viele Seiten indexieren von jeder beliebigen Website, sondern wir versuchen ein bisschen festzustellen, macht es überhaupt Sinn, dass wir so viele Seiten von einer Website indexieren oder macht es da vielleicht Sinn, dass wir die Seiten indexieren und uns eher auf die Hauptseiten, die wichtigeren Seiten konzentrieren. Das hängt sehr davon ab vom Website zu Website. Und da kann es natürlich sein, dass bei einem Titel, bei einer Website, dass ihr sie da wird, fast alles indexiert und bei einer anderen sieht ihr, da wird, weiß ich, nur ein Viertel indexiert. Das hängt in der Regel davon ab, wie wir abschätzen, wie weit macht es Sinn, ein weiterer technischer Faktor, der ein bisschen dazu spielt, der allerdings bei moderneren Websites weniger ins Gewicht spielt, ist die Art und Weise, wie die URL-Struktur gemacht wird. Das heißt, wenn wir viele Duplikates finden, dann ist es einfach schwieriger für uns, wirklich alles abzudecken. Das heißt, wenn zum Beispiel ein Titel bei euch unter einer Haupturale vorhanden ist, aber unter, sag ich mal, 10, 20 verschiedenen anderen URLs auch erreichbar ist und auch irgendwie intern verlinkt ist, sei das zum Beispiel mit verschiedenen Tagging-Parametern oder anderen Artenweisen, wie das intern verlinkt ist, dann müssen wir fast 20-mal so viel crawlen, um diese URLs überhaupt zu finden. Und das macht es für uns dann natürlich auch ein bisschen schwieriger. Das sind so technische und kann man auch freuen. Manchmal ist das nicht so einfach aufzuräumen. Bei den meisten moderneren Websites ist es allerdings etwas, wo wir gesehen haben, ist es weniger ein Problem, weil viele von euch haben ja schon SEOs, die da schon eine Weile machen, die auf solche Sachen eigentlich auch gut achten. Dann war da, glaube ich, noch eine ähnliche Frage bezüglich den Seiten, die nicht indexiert ist, ob man da etwas Spezielles machen muss. In der Regel ist es so, dass wenn wir die Seiten crawlen können und einfach nicht indexieren, dann muss man aus technischer Sicht nicht unbedingt etwas machen. Das ist eher einfach ein Zeichen, dass wir denken, es lohnt sich vielleicht nicht, all diese Seiten zu indexieren von dieser Website. Dann muss man sich halt überlegen, wie kann ich Google zeigen, dass meine Website das wirklich wert ist, dass alles indexiert wird. Das ist dann natürlich eher etwas außerhalb dem reinen SEO-Bereich, sondern dann vielleicht eine Frage von Marketing oder allgemein, wie präsentiert man sich, sodass Google wirklich merkt, dass wenn wir diese Seiten nicht alle indexieren, dass wir da irgendwie Fehler machen. Also, so. John, würdest du uns empfehlen, hier ein bisschen aufzuräumen, wenn wir sagen, wenn wir feststellen, dass da ein Gap ist und also wir erreichen eine große Anzahl von Artikeln an, aber nur ein Bruchteil davon wird indexiert, dass wir uns genauer anschauen, welche Artikel jetzt nicht indexiert werden und daraus als erstes versuchen zu deindexieren wie wir das machen. Das kann man natürlich auch machen, dass man es quasi selber ein bisschen schon voraussortiert und sagt, das sind Sachen, die sind mir wirklich wichtig und die möchte ich wirklich eingereicht haben und auch indexiert haben und das sind Sachen, die sind vielleicht ein bisschen weniger wichtig. Das heißt, gerade wenn man z.B. Pressemeldungen von Presseagenturen einfach 1 zu 1 abdruckt, dann sind das vielleicht Sachen, die möchte man auf der Website haben, aber das sind jetzt nicht die wichtigsten Sachen, die man auf noindex damit benutze, die zwar finden können, dass sie aber für Google jetzt nicht große eine Rolle spielen. Das wäre vielleicht eine Variante oder was man auch machen kann, ist, dass man z.B. im Archiv das Ganze mal anschaut und überlegt, wie kann ich das strukturieren, dass es für Google klarer ist, welche Sachen im Archiv sind, welche Sachen jetzt immer noch die haupteilis sind der Website, dass man da mit der internen Verlinkung sieht, dass man vielleicht den Archiv-Bereich ein bisschen intern einfach separat verlinkt, so dass wir wissen, das sind Bereiche, die sind zwar vorhanden, die müssen aber nicht so regelmäßig crawlen, weil da verändert sich auch in der Regel wenig. Aber dass die wichtigen neuen Sachen dann auch wirklich sauber von der Startseite oder von den Hauptkategorienseiten verlinkt werden, so dass wir die sehr schnell auch finden können. Schauen wir vielleicht da anknüpfen. Wir haben jetzt News Publisher oftmals zu ganz vielen Themen ganz alte und ganz viele Inhalte, keine Ahnung, zu Angela Merkel hat wahrscheinlich jede 1.000.000 Inhalte und auch von vor 10 Jahren Inhalte dazu, die ja wahrscheinlich überhaupt nicht mehr relevant sind, aber im großen Teil des Indexes ausmachen. Das ist eben schon ein bisschen zu Archiv-Sachen, was gesagt. Vielleicht kannst du da nochmal was speziell so für uns News Publisher irgendwie sagen, wir wirklich Content in Massen umgehen sollten. Im Allgemeinen würde ich solche Sachen nicht löschen. Ich denke, das bringt einerseits nicht wahnsinnig viel für euch und das ist natürlich auch schade, wenn die Inhalte irgendwie verloren gehen. Aber praktisch für uns ist, wenn wir wirklich erkennen können, dass diese Inhalte jetzt nicht konzentriert werden, dass wir vom Crawling her uns nicht so sehr auf die konzentrieren müssen. Das heißt, wir versuchen das Crawling ja ein bisschen einzutagen. Wenn wir jetzt, ich weiß nicht, 20.000, 50.000 Seiten am Tag von euer Website crawlen können, möchten wir natürlich in erster Linie die neuen und veränderten Sachen finden. Und da ist es wichtig, dass wir wirklich alle Signale kriegen und sehen, das sind jetzt neue oder wichtige veränderte Sachen. Und dass wir auch erkennen können, dass sie zwar vorhanden sind, also in der Seitenapp Datei sind, aber dass sie zum Beispiel das Änderungsdatum immer noch von Damo als haben. Auch auf den Seiten selber, dass ihr nicht mit dem Datum quasi einfach das Datum wechselt auf den Archiv-Seiten, weil jetzt heute, ich weiß nicht, der 8. März ist, den 8. März nochmal drauf, das macht für uns dann viel schwieriger zu erkennen, dass das eigentlich Inhalte sind, die eigentlich quasi eher nicht so oft crawlen. Wir zeigen die zwar immer noch in den Suchergebnissen, wenn jemand dann auch speziell sucht, das denke ich immer noch richtig, aber wir müssen uns mit dem Crawl nicht speziell auf die Seiten konzentrieren. Was wäre, wenn du so die Seiten an sich, der Text und Content und die Metadaten eigentlich gleichbeim, aber stell dir vor, du hast unter dem Artikel so, nennen wir es mal meist gelesen Boxen, die irgendwie side-wide sind, die natürlich auch bei einem Artikel der vor 10 Jahre alt ist, side-wide von heute wäre und vielleicht steht sogar noch das Datum irgendwie drauf, an dem Teaser mit dran. Sagst du, gleiches Problem oder seht ihr denn mehr als Super Crawl? Das sollte kein Problem sein. Wir erkennen in der Regel, wo die Hauptbereiche sind, eine Seite und konzentrieren uns auf das und solche quasi weiterführenden Bereichen nehmen wir dann eher dazu, um quasi neue Links zu finden, die wir verfolgen können. Kann ich noch was zu dem Archiv fragen? Wie würdest du das technisch Kennzeichnen? Gibt es da auch Möglichkeiten, dass Google besser versteht, außerhalb der internen Verlinkung, dass es dann Archiv ist? Ich glaube eigentlich nicht. Also, was für uns praktisch ist, ist, wenn wir irgendwie über die URL-Struktur erkennen können, wie das zusammenhängt. Ich weiß von Crawling her, ist es so, dass wir die Crawl-Geschwindigkeit zum Teil aufgrund von der URL-Struktur versuchen einzuteilen. Das heißt, wenn man jetzt ein Bereich hat mit Archiv in der URL-Struktur, hilft uns das auch, wenn man nur ein Bereich hat, wo das Jahr zum Beispiel dabei ist. Das hilft uns schon mal ein bisschen festzustellen. Das sind jetzt Inhalte, die sind zwar vorhanden, die müssen wir aber nicht so oft crawlen. Wir sollten jetzt aber nicht alle alten Strukturen im letzten Jahr in der URL 301 machen auf einem Slash-Archiv. Oder, das habe ich jetzt noch nicht rausgehört? Ich denke, so größere URL-Strukturveränderungen macht man natürlich irgendwann mal, aber ich würde das nicht einfach wild wegen irgendwie kleinen Veränderungen machen. Weil das verursacht immer ein bisschen Bewegung in den Suchergebnissen und da weiß man nie genau, wann braucht es, bis es sich wieder ein bisschen eingependelt hat. Vom Crawling her ist es natürlich auch so, dass wir erkennen, dass irgendetwas seitweitsig verändert hat. Dass wir dann versuchen, da noch mehr zu crawlen. Und gerade bei Nachrichten-Websites ist das vielleicht nicht die falsche Richtung. Indem, dass wir dann auf einmal losgehen und nur die alten Archiv-Seiten alle crawlen, weil wir gesehen haben, dass wir jetzt auf einmal redirects dabei. Das hilft euch wahrscheinlich nicht. Das heißt, wenn ihr größere Veränderungen klaren könnt, würde ich solche kleinen Sachen vielleicht dazu nehmen. Aber ich würde die kleinen Sachen jetzt nicht nehmen und quasi, jetzt machen wir diese große Veränderungen und ändern die URL-Struktur. Ich denke, das kennt ihr ja auch alle. Wenn ihr da größere Veränderungen macht auf der Website, dann schwankt erstmal alles für eine Weile und dann hofft ihr, dass es sich einigermaßen wieder einpendelt. Ich habe noch eine Frage zum Archiv und die erzeugen das Archivs für braucht einiges an Ressourcen und da ist jetzt die Frage, weil wir auch beim Archiv auch eine Side-Map haben, ob das vielleicht ja, ob wir den Archiv bei uns auf der HTML-Seite überhaupt noch brauchen oder ob ein Archiv also die Abbildung der URLs vom Archiv in der Side-Map ausreicht. Ob der Seite ist es nicht mehr, gibt es den Link Archiv nicht, sondern es gibt nur noch eine Web. Das ist eine große Frage. Ja, kann man natürlich auch machen. Ich denke, optimal ist es schon, wenn wir über beide Wege die URLs irgendwie finden können. Aber wenn man wirklich sagt, man kann vielleicht über die Suchfunktion intern noch finden und ihr wollt sie wirklich nicht mehr intern im Hauptbereich der Website irgendwie verlinken, dann geht das wahrscheinlich schon noch. Aber es ist optimal, weil wir dann auch irgendwie die Verbindung zum Rest der Website irgendwie verloren haben. Das heißt, wenn man irgendwie trotzdem durchscrolling zum Archiv-Bereich kommen kann, auch wenn das nur irgendwie ein Link ist, der ein bisschen versteckt ist, irgendwie im Futter oder in einem anderen Bereich der Website, das hilft auf jeden Fall. In den meisten Fällen würde ich das nicht ganz entfernen im sichtbaren Link. Okay, dann gibt's da noch ganz viele Fragen. Schauen wir mal, wie wir weiterkommen. Was ist die Empfehlung, mit geteilten Inhalten umzugehen? Wie kann man damit am besten umgehen? Sollen wir da einen Canonical setzen oder soll jeder Titel quasi einen eigenen Canonical haben? Aus unserer Sicht ist es so, dass man mit dem Canonical kann man angeben, welche Version von diesen Inhalten möchte man am ehesten indexiert haben. Das hilft, gerade wenn man jetzt verschiedene, vielleicht mal Nachrichten-Websites betreibt und die gleichen Artikel hat, hilft das uns natürlich all die Signale, die wir kriegen, auf eine Seite zu konzentrieren. Das heißt, statt dass ihr vielleicht fünf oder sechs verschiedene URLs habt, die die gleichen Artikel zeigen, habt ihr dann ein URL, den wir so indexieren können, wo wir all die Signale zusammenfassen können, alle Links, die auf diese einzelnen Versionen kommen, können wir zusammenfassen und so irgendwie ein bisschen stärker dann auch sichtbar machen. Das ist etwas, was ich da auf jeden Fall empfehlen würde, wenn ihr das machen könnt und ihr habt wirklich die gleichen Inhalten auf verschiedenen Nachrichten-Websites, dass man da möglichst irgendwie ein System ausdenkt, wie kann man da einen Canonical setzen, welches von diesen Websites ist jetzt die Haupt-Website zum Thema und dass man das uns auch mitteilen kann über den Canonical. Wie schnell ist der Google-News-Bot beim Verarbeiten von Canonicals? Also es geht ja hier bei uns auch, das sieht man News sehr stark? Weiß ich nicht. Gute Frage. Wir crawlen ja mit dem gleichen, aber mit der Verarbeitung ist es natürlich ein bisschen separat bei Google News. Meistens gerade, also ich kenne jetzt nur aus der Websuche her, ist es so, dass wir meistens die Seiten im ersten Schritt erstmal separat indexieren und dann im zweiten Schritt quasi den Canonical verarbeiten und das versuchen zusammenzuklappen. Das heißt, es kann sein, dass gerade bei kurzlebigen Nachrichten, dass es so ist, dass wir wirklich beide Varianten oder alle Varianten indexiert haben in den Suchergebnissen und das erst nach einigen Tagen klappt es dann alles zusammen, sagen wir gut, wir konzentrieren uns auf die Hauptversion. Ich weiß nicht, wie das mit Google News klappt oder wie sich das verändert dort, gerade wenn man jetzt als Google News Benutzer vielleicht sagt, das ist jetzt die Nachrichten Website, die ich irgendwie bei meinen Sources hinzufügen möchte, ob das da vielleicht irgendwelche Schwierigkeiten verursacht. Wüsste ich jetzt nicht. Vielleicht noch ein Punkt zum Canonical, eine Frage, eine kurze, inwieweit, wie schlimm es ist, wenn sich dort ketten will. A. Canonical zu B, B zu C. Ketten. In der Regel ist das unproblematisch, es macht's einfach so, dass es ein bisschen länger braucht, bis wir alles verarbeitet haben. Weil, was bei uns an und für sich passiert ist, wir versuchen diese Seiten erst mal zu indexieren. Mit dem Canonical wissen wir, dass die zusammengehören in einer Gruppe. Wenn da eine Kette von Canonicals ist, dann braucht es quasi wie im zweiten Durchlauf, bis wir das wirklich alles gefunden haben. Gerade wenn man jetzt diese Zwischenschritte einzeln nicht gesehen haben. Wenn wir die Zwischenschritte alle einzeln sowieso sehen, dann ist es weniger problematisch, aber wenn wir die Zwischenschritte gar nie gesehen haben, dann geht es einfach ein bisschen länger, bis wir das verarbeitet haben. Also es ist nicht so, dass wir das dann ganz fallen lassen, aber es braucht einfach ein bisschen länger. Kommt unser Ton an? Ja. Ah, sehr schön. Zu den Canonicals nochmal. Also wäre es nicht ein gangbarer Weg zu sagen, also man hat jetzt eine Kontenzymikapsion, hat mehrere Portale, wie wir ihn gleich erinnert haben. Erst mal sozusagen den Canonical auf das Portal selbst zeigen zu lassen, zu schauen, welche Seite rankt denn überhaupt in Google, um dann sozusagen später den Canonical auf die Variante zu setzten, die das wie gesagt als die stärkste heraus geprägt hat, um wieder zu stärken. Wenn ihr das machen könnt, könnt ihr das schon machen. Also wenn der Canonical wechselt im Laufe der Zeit, ist das für uns überhaupt kein Problem. Das könnt ihr so machen. Wichtig ist natürlich, dass ihr das irgendwie so macht, dass es dann nachher nicht die ganze Zeit zurückwechselt. Ja. Aber wenn das mal ein einmaliger Schritt ist, nach, ich weiß nicht, nach ein bestimmter Anzahl Tagen wechselt ihren Canonical auf die Version, die eh am meisten traffic bekommt, das könnt ihr gerne machen. Okay. Cool. Dann geht's in die andere Richtung. Nämlich, wie man Sachen aus dem Index entfernen kann am schnellsten. Das ist ja natürlich auch immer ein wichtiges Thema, weil man möchte ja nicht nur alles indexiert haben, manchmal muss man auch Sachen schnell herausholen oder schnell verändern. Aktuell ist es so, dass man zum Beispiel Bildern mit sehr viel manuellen Aufwand entfernen muss. Wenn man Löschanfragen hat, sind das manchmal, da steht jetzt bis zu 14 Euro, die eingereicht werden muss, müssen über das Entfernungstool. Da gibt es da vielleicht eine Möglichkeit, das per API anzusteuern. Im Moment gibt es keine Möglichkeit, das per API anzusteuern. Was man machen könnte, ist mit No Index zu arbeiten und diese URLs zum Beispiel per Seitenabdatei einzureichen. Es ist nicht ganz das gleiche wie mit dem Entfernungstool, aber es macht es ein bisschen einfacher, dass man da nicht immer direkt mit dem Entfernungstool so ein Hand machen muss. Und zwar kann man natürlich in der Seitenabdatei angeben, dass sich eine URL verändert hat und die kann natürlich sich so verändert haben, dass sie jetzt No Index hat. Oder sie kann sich so verändert haben, dass sie jetzt 04 zurückgeht. Und das sind Veränderungen, die sind für uns auch wichtig und wenn wir das mit dem Änderungsdatum in der Seitenabdatei wieder ein bisschen schneller aus dem Index fallen lassen. Mit dem Entfernungstool ist es so, dass es meistens innerhalb von weniger Stunden entfernt wird, gerade wenn man das als Besitzer quasi einreicht. Über den No Index mit der Seitenabdatei ist das natürlich ein bisschen, ja, weiß man nicht, wie schnell das genau geht, weil das hängt ein bisschen davon ab, wie schnell können wir diese Seite neu crawlen, wie schnell können wir dann erkennen, dass die Seite effektiv ist. Und gerade bei Seiten, die sich jetzt nur verändert haben, ist das manchmal ein bisschen schwieriger. Das heißt, gerade bei Bildern, wenn die Build URL weiterhin besteht und jetzt aber jetzt einfach etwas ausgeblendet ist auf dem Bild oder etwas verändert worden ist auf dem Bild, dann erkennen wir das meistens nicht so schnell. Ingegen mit dem Entfernungstool könnt ihr dann trotzdem gezielt sagen, das Bild möchte ich jetzt aus dem Index haben, auch wenn das noch auf dem Server steht. Wir haben da verschiedene Versuche, gerade mit sehr großen Websites auch gemacht, wie man das ein bisschen automatisieren kann. Das heißt, wenn man jetzt irgendwie ein Profil auf einem Social Media Website löscht, dass das ein bisschen schneller verarbeitet wird. Ich weiß nicht, wie weit wir das auch für allgemeine Websites irgendwie zur Verfügung stellen können. Ich weiß, dass da im Moment dran verarbeitet wird, dass man das ein bisschen besser und ein bisschen breiter machen kann. Einerseits zum Einreichen vom Content, andererseits aber auch zum Angeben, welche Inhalte jetzt gelöscht worden sind. Das heißt, im Moment müsst ihr weiterhin mit dem Entfernungstool arbeiten für Sachen, die wirklich sofort entfernt werden müssen. Aber ich vermute, im Laufe des Jahres gibt es da vielleicht weitere Möglichkeiten, dass man das ein bisschen automatisierter ist. Was natürlich mit der Automation auch zusammenhängt, ist, dass man dann halt auch eher aufpassen muss, was man macht. Weil, wenn man das von Hand macht, kann man das sehr schnell auch wieder rückgängig machen. Wenn das automatisiert gelöscht wird, dann hat man manchmal das Problem, das ist es halt entfernt. Und dann ist es weg. Und man merkt gar nicht, warum das weg ist. Einfach weil irgendjemand im CMS vielleicht den Haken am falschen Punkt gesetzt hat. Da ist noch eine Frage vom Crawling her. Wir planen eine Umstellung auf HTT-P2. Müssen wir noch zusätzlich HTT-P1 unterstützen? Ja. Das heißt, für Google im Moment ist es so, dass wir HTT-P2 nicht separat crawlen, sondern wir nehmen eigentlich die vielleicht noch normale Variante mit HTT-P1, crawlen wir noch so. So weit ich das weiß, ist es auch vom technischen her eigentlich so gedacht, dass man mit HTT-P1 quasi anfängt und da macht man wie ein Upgrade der Verwindung auf HTT-P2. Das heißt, wenn man jetzt HTT-P1 gar nicht mehr unterstützt, dann ist es wie, dass man da irgendwie noch Probleme verursacht für normale Benutzer auch. Und da würde ich auf jeden Fall empfehlen, dass zumindest im Moment, dass man die HTT-P1 Variante auch noch beide hält. Ich glaube, bei den meisten Versionen ist das sowieso Standard. Also es ist nicht unbedingt etwas, wo man gezielt achten muss. HTT-P2 bringt vor allem dann Vorteile für Benutzer. Das heißt, gerade auf HTT-PS-Seiten kann man mit HTT-P2 mehrere Ressourcen im gleichen Request quasi zurückliefern. Das macht es ein bisschen schneller, gerade für Browser. Für Google ändert das eigentlich relativ wenig, weil wenn wir Ressourcen gleichzeitig abfragen würden, müssten wir die dann trotzdem irgendwie beim Crawl-Budget dazu zählen, weil das ist ja auch ein Aufwand der Server dann betreibt, um diese Ressourcen zu schicken. Das heißt, für das Crawling macht das eigentlich auch nicht wahnsinnig viel Sinn. Deswegen haben wir das da noch gar nicht groß implementiert. Für Benutzer hingegen kann das natürlich einen großen Vorteil haben. Die Anzahl No-Index-Seiten. Wir haben circa 20 Millionen Seiten auf No-Index gesetzt. In dem entgegen stehen etwa 9 Millionen Seiten, die indexiert werden können, ist das ein Problem. Aus unserer Sicht ist das überhaupt kein Problem. Das könnt ihr so machen, wenn ihr das wollt. Für uns ist eine Seite mit dem On-No-Index eigentlich eine Seite mit No-Index. Das ist eure Wahl. Ihr könnt das machen, wie ihr wollt. Und nicht ein Zeichen, dass die Website irgendwie von der Qualität her nicht gut ist oder dass da irgendwie sonst etwas problematisches mit der Website, sondern das ist wirklich einfach eure Wahl. Ihr könnt sagen, das soll indexiert werden, das soll nicht indexiert werden. Vom Crawling her ist es natürlich so, dass No-Index-Seiten müssen gekraut werden, damit wir das No-Index sehen. Das heißt, wir schauen die Kotzen noch ab und zu an. Aber für die Indexierung verwenden wir das dann nicht. Darf ich dazu gleich noch was fragen? Das war nämlich die Frage-Kampfung, gute Frage. Wie würdest du denn insgesamt empfehlen, wie wir damit umgehen sollten? Würdest du Fragen, die wir vielleicht als nicht mehr so relevant empfinden, die vielleicht keinen Traffic generieren und vielleicht schon seit 2007 irgendwie im Index sind, dann eher auf No-Index belassen oder würdest du die 14 Variante nehmen und sagen, okay, wir müssen da mal ausmisten? Ich denke, dass es euch überlassen. Aber das ist natürlich auch immer ein bisschen schwierig, je nachdem, wie viele Seiten das sind und wie man das machen möchte. Ich weiß, andere große Websites haben zum Teil recht Erfolg gehabt mit dem Aufräumen. Irgendwo war gleich mal eine Konferenz von eBay, war irgendetwas, wo sie da wirklich mal gezielt alle Sachen aufgeräumt haben, die wirklich keinen Verkehr mehr aus der Suche generieren. Aber grundsätzlich ist das euch überlassen. Mit dem No-Index ist das aus unserer Sicht für die Indexierung problemlos machbar. Wir müssen die natürlich trotzdem noch crawlen. Wir finden die Links innerhalb der Webseite immer noch. Wenn es für euch relevant ist, dass Benutzer diese Seiten trotzdem noch finden, dann würde ich die vielleicht lassen. Wenn die Seiten wirklich für Benutzer überhaupt keinen Nutzen mehr haben, dann macht es vielleicht Sinn, dass man die irgendwann auch mal ausräumt. Und Aufräumen wäre dann für dich ein bisschen zufrieden oder würde auch 404 reichen? 404 auf 410 ist etwa das Gleiche für uns. Wir verarbeiten 410 ein kleines bisschen schneller. Aber in der Praxis macht das vielleicht ein Unterschied von 1 oder 2 Tagen. Also nicht unbedingt etwas, worauf ich jetzt gerade bei Sachen, die aus 2007 sind, würde ich mir jetzt nicht den Kopf zerbrechen, um 404 oder 410. Danke schön. Darf ich ganz kurz ergänzen was? Ist es nichts so, dass wir bei 404 Seiten dann auch irgendwann auch mal wieder schaut, ob die eventuell wieder da sind und beim 410er ist das ja nicht der Fall? Das ist bei beiden eigentlich so. Bei beiden? Ja. Bei beiden ist es so, dass wir ab und zu die Seiten noch mal crawlen, damit wir sicher sind, dass die Seiten auch wirklich nicht mehr existieren. Meistens hängt das damit zusammen, dass wir irgendwo einen neuen Link gefunden haben, der auf die alten Seiten zeigt. Und das ist wahrscheinlich ein alter Link, der auf die Seiten zeigt. Aber wir sehen den dann vielleicht zum ersten Mal auf dieser Seite und denken, ah, vielleicht hat sich jetzt was verändert. Wir schauen nochmal kurz nach. Okay. Vom Crawling her ist es so, dass wir diese älteren Seiten, die lange 404 oder 410 hatten, einfach so dazunehmen, wenn wir gerade noch Zeit haben. Im Haupt Crawling, irgendwie ein Problem verursachen, sondern wenn wir sehen, ah, wir hätten noch Platz für, ich weiß nicht, 100.000 Seiten heute von dieser Website und wir kennen all diese alten 404 Seiten, dann schauen wir die vielleicht auch mal an. Im ersten Schritt ist es natürlich so, dass, wenn wir denken, die Seite existiert noch, dann crawlen wir die natürlich erstmal normal. Aber dann im späteren Bereich, jetzt zeigen wir, Jahre, später schauen wir die einfach dann und zu noch an. Wenn man sehr viele 404 Seiten hat, wenn man die 404 Fehler in Search Console anschaut, dann ist das natürlich immer eine riesige Liste, weil selbst, wenn wir die einmal alle zwei Monate anschauen, sind da sehr viele Seiten. Und da würde ich diese Fehlerliste einfach vielleicht mal kurz überblicken und sagen, ah, die ersten Paar sind jetzt total irrelevant, sind alte Seiten, dann wird der Rest in der Liste auch irrelevant sein. Dann würde ich in Kopf zerreichen. Ich hatte auch noch eine ganz kurze Frage. Und zwar bei Seiten, die auf New Index gestellt sind, heißt es, dass ihr die weniger crawlt. Wenn ja, wie oft weniger denn, also prozentual? Wie oft weniger, das lässt sich eigentlich bei fast keinen Element genau sagen. Das heißt, es hängt immer ein bisschen davon ab, wie die Webseite eingestuft wird, einerseits und wie wir das Gefühl haben, wie oft diese Seiten sich verändern. Da, so, so passt sich an für sich die Crawl-Geschwindigkeiten meistens an. Mit dem New Index ist es so, dass wir die meistens weniger auf Crawlen, weil wir die dann eher als Soft 404 einstufen. Das heißt, intern schauen wir die Seiten dann so an, als ob das eine 404 Fehlercode zurückgeben würde. Wir lassen die ja dann auch irgendwann aus dem Index fallen. Und wie andere 404 Seiten crawlen wir die dann einfach nicht so häufig. Das passiert meistens erst nach einiger Zeit. Das heißt, Seiten, die New Index haben, werden vielleicht am Anfang erst mal normal wiedergecrawlt. Weil wir denken, vielleicht kommt das wieder zurück. Aber dann späteren, wenn wir merken, die Seite ist wirklich jetzt ganz weg, wenn wir ganz aus dem Index lassen für immer, dann crawlen wir die ein bisschen weniger häufig. Meistens ist es so, dass vom Crawling her unterscheiden wir in verschiedene Gruppen von der Geschwindigkeit grob. Und da ist so, ich glaube, der längste Zyklus ist, ich weiß nicht, sechs bis neun Monate und so etwas pro URL. Und irgendwann fallen diese 404 Seiten dann in diesen Bereich rein, dass man die vielleicht alle sechs bis neun Monaten mal wieder anschaut. Aber das natürlich, je nachdem, wenn das sehr viele Seiten sind, ist das natürlich immer noch eine Menge, die einfach regelmäßig gecrawlt wird. Warum ich halt gefragt hab, ist wegen den Pagern, wie geht dir da bei Pagern um? Da sind ja Artikel dahinter und erkennt es? Also bei Paginierungen also ich denke mal, jeder wird seine Paginierung auf eine Index stellen. Ich will nicht, dass jede Seite in den Index kommt. Wie geht dir da um? Erkennt dir das, dass es Pager sind und crawlt dir die dann ein bisschen öfter vielleicht? Es ist unterschiedlich. Meistens ist es so, dass wir gerade so bei, sag ich mal, langen Kategorienzeiten, wo wir sehen, dass das irgendwie ich weiß nicht, 10, 20 weitere Seiten da gibt, ist es so, dass wir die ersten paar Seiten dort ein bisschen häufiger crawlen, weil die eher quasi weiter vorne an der Webseite verlinkt sind. Und dass wir die weiteren Seiten irgendwann merken, dass da kommen einfach immer mehr gleiche oder ähnliche Inhalte links zu Artikel, die wir eh schon kennen und die crawlen wir dann sowieso ein bisschen weniger häufig. Und das ist etwas, was wir über verschiedene Faktoren versuchen zu erkennen. Einerseits mit dem No Index, das hilft uns natürlich auch dabei. Mit Rail Next Rail Previous hilft uns ein bisschen dabei. Manche nehmen Rail Canonical ist nicht ganz so optimal, weil eigentlich ist das technisch gesehen nicht so korrekt. Manche nehmen das Yrel Parameter Tool in Search Console, dass sie uns sagen, da dieser Parameter ist quasi jetzt die Seitenzahl und das impaginierte Inhalte. All solche Sachen helfen uns, dass wir nicht allzu tief in diesen Bereichen einfahren. Was ja eigentlich auch der Sinn ist, dass wir da die neuen veränderten Inhalten relativ schnell finden. Die sind ja dann meistens oben auf der Liste. Und dass die anderen Sachen, die haben wir irgendwo schon mal gesehen, die haben wir eigentlich schon mal irgendwie Index drinnen. Danke. Okay, mal kurz schauen, was man da noch am besten Gott anschauen kann. Das Paid-Thema, John. Paid-Thema, okay, leg los. Hast du auch bekommen? Also First-Lick-Free, Flexible Sampling, Cloaking an Anführungszeichen, was dir da erlaubt, gar nicht bös gemeint. Paid Content ist ja generell gerade ein großes Thema, auf vielen Seiten zusätzliche Allösströme etc. Und wir bei Welt implementieren das auch gerade und wir haben uns ein bisschen gefragt User, die das in der Suche sehen, Paid Content, wären ja sicherlich höher und öfter Bouncen auf diesen Artikeln, weil sie nicht alle sofort sagen, ja, ich will hier ein Abo als auf normalen Artikeln und nicht nur Bouncen, sondern auch Back to Serb gehen und irgendwie keine Ahnung, Platz 2 anklicken, dass da drunter ist. Debatieren wir bei uns heftig und uns noch nicht einig, ob das auch bezogen auf unsere Google Performance der Gesamtseite irgendwie schlechte Einflüsse haben könnte oder ob wir das irgendwie stark minimieren sollten oder in diese Richtung. Grundsätzlich sollte das eigentlich für SEO selber eigentlich kein direkten Einfluss haben. Aber es hat natürlich auch indirekt ein Einfluss einfach als Benutzerverhalten, in dem wenn Benutzer oft auf eure Website kommen und jedes Mal dann quasi in Paywall sehen und sagen, ich klicke gar nicht mehr auf diese Website und dann selbst wenn man im Ranking gleich ist, wenn die Leute dann nicht mehr draufklicken, ist das natürlich ein Problem. Das heißt, das ist ein Thema, was für uns recht wichtig ist, dass wir das versuchen, irgendwie sauber zu erkennen, aber für euch ist natürlich auch wichtig, dass ihr das ganzheitlich aussieht. Wie kann ich mit meinen Benutzern umgehen, dass ich da einigermaßen trotzdem noch gute Inhalte zeigen, sodass sie meine Website, meine Inhalten auch kennenlernen und dass man dann trotzdem auch die Möglichkeit hat, gut, wenn ihr jetzt häufiger kommt, dass ihr dann vielleicht auch eher in Paywall sieht, solche Sachen. Das heißt, diese Balance zwischen allen Inhalten quasi hinter einer Paywall und irgendein Teil der Inhalte hinter einem Paywall das ist etwas, das müsst ihr irgendwie fast, ich weiß nicht, experimentieren oder herausfinden, wie das am besten für euch funktioniert. Vom SEO her würde ich mir da jetzt eigentlich keine großen Sorgen machen. Hilft das ein bisschen? Ist keine absolute Antwort. Ich denke, das hängt natürlich auch sehr davon ab, was für Inhalte man hat, welche Art von Benutzern man hat. Wenn das alles Benutzer sind, die quasi einfach nach dem aktuellen Tag das Thema schauen und es gibt Zick-Sorsten, wo man diese Informationen kriegen kann, dann ist es vielleicht ein bisschen anders. Wenn man, sag ich mal, wissenschaftliche Informationen hat, wo Leute wirklich zu euch kommen und sagen, ich weiß, dass diese Website eigentlich die einzige Quelle ist für diese Informationen. Und wenn ich da ein Paywall beim ersten Mal sehe, dann denke ich gut, dass es halt der Preis, den ich zahlen muss, um an diese Informationen zu kommen. Das ist natürlich ein recht große Brandbreite an möglichen Benutzern, die je nachdem unterschiedlich Verhalten haben. Da lohnt es sich, das manchmal ein bisschen auszuprobieren, ein bisschen zu analysieren, wie reagieren gewisse Benutzern auf gewisse Teile meiner Website, wenn die jetzt mit einer Paywall konfrontiert werden. Gut, aber das heißt, ich habe jetzt mitgenommen, dass ich mir keine Sorgen machen muss vor generell ansteigender Erfahrungen, schlechte Nutzersignale, die irgendwie im Algorithmus natürlich drin sind und die irgendwie andere Seitenbereiche schaden könnten. Genau, ja. Ich denke, für uns ist das natürlich auch wichtig, dass man da irgendwie ein Weg findet dem Publisher, solche Chancen auch zu geben, dass sie das ausprobieren können. Nicht, dass man da quasi dann verhaft wird, dass man sagt, gut, ich habe jetzt das Problem, dass meine Benutzer irgendwie sich nicht so toll fühlen und dann kommt Google noch und sagt, jetzt bestrafen wir euch noch wegen mit SEO-Problemen. Planen Sie das irgendwie zu Kennzeichnen in den Suchen? Das weiß ich nicht. Weiß ich nicht, wie das da weitergeführt wird. Ich weiß, vom Ampere ist das natürlich ein großes Thema, dass man da auch die Möglichkeit hat, ich weiß, es arbeiten diverse Gruppen innerhalb von Google auch an diesen Problemen, dass man da das irgendwie so hinkriegen kann, dass Publisher von guten Inhalten wirklich auch eine Möglichkeit haben, davon sauber zu leben, ohne dass man da die ganze Seite nur mit Werbung zulastern muss. Und Amp war das Stichwort gerade, was sich da anschließt, wenn wir gleich ist, nicht nur auf der mobilen Webseite oder Desktop-Webseite sondern auch in Amp und sagen, okay stehen wir dann vor der Herausforderung und sagen, naja, unsere Software-Entwickler, bitte baut mir die ganze Amp-Login und was es alles gibt auch ein zusätzlicher Aufwand oder würdest du sagen, naja, ist schon okay, wenn ihr, sagen wir mal, in Amp auch nur den Teaser, ein Anreißer, ein Stück vom Content und dann eine Art, nennst du mal, Payball, aka statischer Teaser und sagen, wenn du die ganzen Funktionalitäten etc. haben willst, dann klick hier und wir leiten eben aus dem Amp-Universum rauf auf unsere Seiten. Könnte man sich vorstellen, allerdings kam mir dann so, beim Recherchieren nochmal, dieses Chefkoch.de Beispiel in den Hinterkopf, wo ihr, glaube ich, auch auf dem Block oder das Geist hat auf jeden Fall durch die Szene, die ja irgendwie sagt, okay, wenn du das ganze Rezept lesen willst, dann klick hier, du kommst auf unsere Webseite, wo ihr gesagt habt, das wollt ihr eigentlich nicht und Ähnliches wäre es ja so ein bisschen bei diesen Geschichten und da fragen wir jetzt uns einfach, müssen wir diese ganze Lock-in-Logiken wirklich so viel in Amp zusätzlich investieren oder würde es reichen, wenn wir halt diesen bisschen Chefkoch-Weg dort wählen? Ich weiß jetzt nicht, was der aktuelle Stand ist. Gerade bezüglich Amp-Login und Amp-Paywall oder wie das mit dem Paid-Content da funktioniert. Aber grundsätzlich ist schon so, dass wir mit den Amp-Seiten die gleichen Inhalten sehen wollen, wie auf der normalen Seite. Wenn natürlich auf beiden Varianten nur der Teaser vorhanden ist, dann sind die ja eigentlich gleich. Aber wie das genau gehandhabt wird, gerade mit dem Paid-Content, weiß ich da nicht. Wir bauen ja alle gerade so ein, dass wir in Anführungsstrichen cloaken, dass ihr mit dem Google-Crawler das schon könnt, also User-Agent, Reverse-IP-Lookup etc. Und das normalerweise für unsere normale Infrastruktur müsste man das jetzt für die AMP-Infrastruktur quasi auch noch mal da bauen oder weil du hättest schon, der Crawler würde schon einen Unterschied sehen. Ich weiß es ehrlich gesagt. Ich vermute, dass da irgendwas auch noch kommt gerade vom AMP-Team her auch irgendwo dokumentiert ist. Ich weiß jetzt ehrlich gesagt eine gute Frage. Was ist nochmal was zum Indexierungsprozess fragen? Und zwar haben wir oft das Problem älterer Vs. jüngerer Content. Beispielsweise, wie lange geht der Superbowl oder wann beginnt die Bundestagswahl? Zieht sich Google immer den alten Content raus, obwohl wir eigentlich schon zu selben Thema haben. Wir haben auch alles eigentlich klar und deutlich ausgewiesen mit Datum und so weiter aber irgendwie versteht es Google nicht und wie würdest du quasi da am ehesten umgehen? Weil wir haben auch teilweise Schwierigkeiten quasi halt eben Google zu zeigen. Was ist denn jetzt unser neuer Content? Weil Google versteht sich nicht. Gute Frage. Weiß ich jetzt nicht, wie man das am besten machen kann. Es hängt wahrscheinlich ein bisschen davon ab, wie das strukturell machbar ist auf der Website. In der Regel ist es so, dass wir ja, die können wir vielleicht machen. Vielleicht eine Variante wäre, dass man eher Kategorienseiten da für solche Sachen dann verwendet. Dass man das so macht, dass die Kategorienseiten eher verlinkt werden von den höheren Stufen der Website. Aber vermutlich ist das auch schwierig mit einer Website wie eurer, dass man das genau markiert. Was man natürlich auch machen könnte ist mit dem Canonical Arbeiten, dass man sagt ich setze quasi von den alten Seiten den Canonical auf die neue Seite. Das geht aber natürlich auch nur, wenn ihr genau wisst, was sind die alten Fragen und was sind die neuen Fragen dazu? Ja, der Punkt ist nur, dass wir öfter sagen wir mal 10 selbe Fragen haben, die unterschiedlich gestellt werden. Eine fragt, wie lange geht das Super Bowl? Die andere fragt, wie lange geht das Super Bowl? Weil wir sehr longtälich unterwegs sind und beide Varianten ranken für unterschiedliche Suchanfragen und beide generieren dann auch Traffic. Sonst hätte ich gesagt, dann mache ich eine 301-Weiterleitung, aber bei uns ist das Problem wohin denn? Je nach Suchanfrage rankt die Frage, aber leider auf die falsche. Das ist gerade eine Herausforderung, die wir uns stellen müssen. Was mir vielleicht helfen würde, ist, wenn ihr solche Beispiele uns mal zuschicken könnt. Gerade mit dem Super Bowl das sind so Sachen, wo ich weiß, dass bei uns diverse Teams arbeiten daran, um festzustellen, was sind jetzt die richtige Balance zwischen alten Inhalten und neuen Inhalten. Ich weiß, dass es ein Problem ist, das kommt immer wieder irgendwie hervor. Wahrscheinlich auch für normale Websites. Wenn ich nach einem Nachricht ein Thema suche, dass dann vielleicht die alten Sachen herkommen, statt die neuen Sachen. Solche Suchanfragen, wenn ihr das sieht, dass das wirklich falsch kommt, hilft uns auf jeden Fall, diese Algorithmen ein bisschen besser zu tun, dass wir das ein bisschen besser hinkriegen können. Das mache ich sehr gerne. Für uns ist es natürlich klar, dass wir dann schlechte Nutzer-Signale generieren, wenn dann die Frage von 2011 ganz klar und deutlich neuen Content haben. Kann man die auf eure Seite irgendwie auch erkennen, dass man dann zum Beispiel ein Link zu den neueren Varianten findet? Ja, wir haben schon Kategorie Seiten, die sind in der Hierarchie-Ebene weiter von oben verlinkt, also auch von der Paginierung her. Und die anderen müssten eigentlich schon auf Paginierungsseite, weiß ich nicht, 2000 oder 3000 sein. Also eigentlich ist es von der Hierarchie schon klar deutlich gekennzeichnet. Und auch haben wir noch ein paar Orte mit Datum integriert. Und das Datum ist eigentlich auch klar ersichtlich. Aber das passiert uns wirklich öfter, also bei verschiedenen Frage-Typen oder Varianten. Okay. Ja. Ich schaue mir gerne Beispiele an und schaue das mit dem Team auch mal an, was man da vielleicht machen könnte. Auch von anderen, wenn von Nachrichten-Websites irgendwas so in der Art auftritt. Solche Beispiele sind auf jeden Fall sehr hilfreich. Wie kann ich dir die zukommen lassen? Ich habe ja Google+, da bin ich drin, einfach so quasi nur direkt mit mir teilen. Dann kann ich das an das Team weitergeben. In den meisten Fällen kann ich dann nicht wahnsinnig viel dazu sagen oder irgendwie weitere Informationen geben, weil das sind Sachen, die werden vom Team erst mal verarbeitet und die überlegen dann, wie können sie das in die Planung mit hineinnehmen oder wie dringend müssten da Änderungen gemacht werden. Da kann ich dann nichts zurückkommen und sagen, ja, das verändern wir jetzt über Manuell, weil wir möchten natürlich eher eine algorithmische Lösung finden, die überall funktioniert. Vielen Dank. Okay, gibt es vielleicht sonst noch irgendwelche letzten Fragen, bevor wir da... Ich habe eine Frage, die betrifft, glaube ich, ganz vielen in der Verlachtswelt. Und zwar das Thema DPA. Wir liefern ja alle DPA-Content aus und bei uns ist es so, ja, mit manchen DPA-Artikeln, also so, wie die sind, ohne Veränderung, wir treffen hier, an anderer Stelle nicht. Und was wäre da deine Empfehlung? Also sollten wir weiterhin alle denselben Content ausspielen oder sollen wir sagen, DPA nur dann ausspielen, wenn wir es vorher verändert haben und ein bisschen nie gemacht haben? Genau. Kann ich das beantworten? Ja, gerne. Also ihr solltet alle komplett die Finger davon lassen. Niemand mehr das DPA machen? Außer ihr, oder wie? Außer wir. Das heißt, dass wir DPA machen. Also wir nutzen... Also wir sind keine DPA mehr? Nee, das war mein Ratschlag für alle anderen. Alle anderen, okay. Ich weiß nicht, ob das so allgemein. Doch, doch, doch. Du hattest, was ist deine Meinung? Also, an und für sich finde ich das nicht so problematisch, wenn ihr die Inhalte so habt. Ich würde mir einfach überlegen, ob das längerfristig quasi bei euch auf der Webseiten Platz hat oder ob ihr sagt, ihr liefert die einfach aus und wenn die nach 2, 3 Tagen nicht mehr relevant sind, dass ihr sagt, gut, ihr nehmt die dann halt wieder raus oder macht ein Canonical auf euer Eigenartikel zu diesem Thema, damit das ein bisschen aufgeräumt wird. Nicht, dass ihr einfach ein Archiv hat von 99% DPA-Meldungen und der Rest ist dann quasi ein kleiner Teil von euch, was wir auch feststellen können. Hauptsächlich hat diese Webseite eigentlich normale eigene Inhalte auch, die wir uns verlassen können. Okay, danke. Ich hatte noch eine kleine Frage, oder? Ich hatte mal ein Fall bzw. hab den immer noch. Ich hab da immens viel Traffic drüber bekommen und ich hab mich halt gefragt, woran liegt denn das? Aber einmal die URL genommen, und hab dann gesehen, dass ich tausend Ergebnisse bekommen hab und dass so erotische komische Seiten darauf verlinkt haben, aber irgendwie versteckt verlinkt haben, ich hab keine Ahnung wie, und es war auch kein Ahreflink. Was kann man dagegen tun? Und seht ihr das, also wenn ihr den Link dann auf diesen erotischen Seiten seht, kann da aber irgendwas, also kann meiner Seite da was passieren? Was sollte eigentlich unproblematisch sein? Also, gerade wenn das, sage ich jetzt mal allgemein sage ich mal Spam Webseiten sind, die auf eure Sachen verlinken, in der Regel erkennen wir das sehr gut und ignorieren das einfach. Was höchstens sein könnte in einem solchen Fall ist, dass man irgendwie von den Keywords her dazu irgendwie noch verbunden wird. Das heißt nicht, dass wir dann eure Seiten nicht mehr für eure normalen Keywords erkennen, sondern dass wir vielleicht einfach zusätzliche Keywords noch dazu haben. Das heißt, wenn man vielleicht nach, weiß nicht, irgendwelchen Anchor Text, der da verwendet wurde, gesucht, dass eure Seiten dann auch noch auftauchen. Und das, ich meine, das ist einfach zusätzlicher Verkehr auf eure Seiten, die, den ihr eigentlich ignorieren könnt, weil wahrscheinlich konvertiert ihr ja nicht, wahnsinnig gut. Ja, das komische ist, dass wir wirklich eine Verwaltung davon sechs Minuten oder sieben Minuten haben. Also, ja. Sehr komisch. Also, ja. Also, an und für sich sollte das nicht schneller. Das sind, das sind alles Sachen, die passieren immer wieder im Internet, dass man da verlinkt wird von den diversesten Seiten. Man hat keine Ahnung, warum. Und wir müssen das irgendwie verstehen oder versuchen, damit umzugehen. Oder einfach zurück nachher. Okay. Ich habe noch eine Frage zu den Suchergebnisseiten in der Lage, da ist uns aufgefallen. Wir haben relativ viel Content dazu. Es ist aufgefallen, dass in den vergangenen zwei Jahren eigentlich Google zunehmend in der Lage schien, immer den Search Intents zu einem bestimmten kurzen Keyword ganz gut zu verstehen. Ich gebe mal ganz kurz ein Beispiel. Menschen, die nach Trombose suchen, das also typisches Heldskurzes Keyword, suchen meistens in der Hand fort auf die Frage, ob sie selbst eine Habensprech, also so dieser Unteraspekt anzeichen. Uns ist aufgefallen, dass in den letzten Monaten ungefähr seit Januar vermehrt wieder Seiten auftauchen auf den ersten Suchergebnisseiten, wo dieser Search Intent nicht mehr so abgebildet wird wie in der Vergangenheit schon. Es war also früher so, dass die geringten Seiten meistens die waren, die genau diesen Aspekt auch primär und schwerpunktmäßig behandelt haben. Sieht man jetzt manchmal wieder verschiedene Unterseiten von einem einzigen Publisher mehrere Unterseiten, die dann alle Aspekte dieses großen Kontext Trombose abbilden, aber nicht mehr den Search Intent. Sprich, der User muss selber wieder entscheiden, welches Ergebnis kriege ich eigentlich an, was ist mein Search Intent. Was ist also der Hintergrund und wie kann man das günstig beeinflussen? Weiß ich nicht genau. Also es sind, an und für sich sind das normale Veränderungen, die wir in unseren Algorithmen immer wieder machen. Und ich vermute, das sind Sachen, die entweder werden sie einzeln getestet und vielleicht sieht ihr solche Tests auch ein bisschen eher. Oder es sind Sachen, die wir einfach aus unseren Tests gesehen haben, dass sie ein bisschen besser funktionieren, oder dass sie ein bisschen klarer sind für die Benutzer. Oder dass wir diesen Intent vielleicht vorher nicht so eindeutig einstufen konnten, dass wir mehr Möglichkeiten für den Benutzer auch bieten müssen, dass die Benutzer auch selber ein bisschen entscheiden können, was meinten sie eigentlich mit dieser Suche, die eher allgemein ist, wollen sie in diese Richtung gehen, oder wollen sie eher in die andere Richtung gehen. Und das sind, sag ich mal, solche Veränderungen, die gibt es immer wieder in der Suche. Dass wir da feststellen, dass es Sinn macht, dass wir das so in die Richtung machen müssen, oder manchmal müssen wir merken, dass es in die Richtung geht, oder wir testen etwas und dann geht es schief, dann müssen wir trotzdem wieder in die andere Richtung machen. Das sind Sachen, die kommen und gehen eigentlich immer wieder. Das ist gerade dabei, dass dann auch von einem aus einer einzigen Domäne gleich mehrere Inhalte auf der ersten Seite verlinkt sind. Also auch zum Beispiel von uns dann gleich 2 oder 3 Inhalte dazu. Aber die Service ist natürlich damit nicht mehr so divers, wie es sich der User vielleicht wird, das Informationsangebot. Ich hätte das auch erst als Testphase verortet, aber das ist jetzt tatsächlich so eine Entwicklung, die wir schon über relativ viele Wochen sehen und uns dann gefragt haben was für eine Eigenierung versus holistischer Content ist. Was ist da jetzt für uns die beste Strategie? Schwierig zu sagen. Ich denke, gerade mehr Resultate auf einer gleichen Website in den Suchergebnissen ist eigentlich auch normal. Es hängt sehr davon ab, wo nachgesucht wird und wie wir den Nutzer ein bisschen einteilen können. Aber schwierig zu sagen, was man da genau machen müsste. Ich würde einfach aus Empfehlungen geben, dass man nicht die Website an die aktuellen Suchergebnissen anpasst, weil die Suchergebnissen, die werden immer wieder neu zusammengestellt. Das heißt, jetzt nicht groß strategische Veränderungen innerhalb eurer Website machen, nur weil aktuell die Suchergebnisse so aussehen, sondern wirklich auch längerfristig klaren und überlegen, wie kann ich am meisten Nutzen bieten für Nutzer, die auf meine Seiten kommen, wie kann ich die am besten zu den Inhalten die ich als wichtigsten innerhalb meiner Website erkennen kann und auf das konzentrieren und weniger auf die Art und Weise, wie aktuell die Suchergebnisse präsentiert werden, weil die Suchergebnisse die verändern sich ständig. Und da kann man nicht, sag ich mal, eine Strategie aufbauen und sagen, so sehen die Suchergebnismoment aus, also verstelle ich meine Content-Strategie um und mache etwas ganz anderes, nur damit ich in das aktuelle Schema passe. Weil das kann sich nächste Woche wieder verändern. Das kann ein Monat wieder anders sein. Manchmal hält sich das auch mehrere Monate oder Jahre, aber das würde ich nicht unbedingt als etwas nehmen, woraus man sich ausrichten sollte. Danke nämlich, dass man so mitkommt. Okay, gut. Ich glaube, zeitlich sind wir ein bisschen über den Rahmen schon hinüber. Von dem her möchte ich mich bei euch erstmal ganz herzlich bedanken für die vielen Fragen, für die interessanten Gespräche. Ich habe da einige Sachen noch auf meiner Liste, die schalte ich mal an euch, ob ich da vielleicht allgemein etwas dazu noch schreiben kann. Wenn ihr weitere Fragen habt, könnt ihr natürlich auch in den nächsten Hangouts dazu Fragen stellen. Ich glaube, heute Nachmittag ist der nächste deutsche Hangout sogar. Das sehen wir uns dann vielleicht auch mal wieder. Ansonsten wie gesagt, vielen Dank fürs Kommen. Vielen Dank für die ganzen Fragen und sehen wir uns dann mal wieder. Wir danken dir an. Danke. Tschüss.