 Okay, herzlich willkommen beim heutigen Webmaster Essentials Sprechstunden Hangout. Mein Name ist Johannes Müller, ich bin Webmaster Trends Analyst bei Google in der Schweiz und Teil von dem, was wir machen, sind solche Webmaster Hangouts, wo Webmasters, SEOs, Publishers dazu kommen können und ihre Fragen rund um die Suche stellen können. Es sind schon einige Sachen eingereicht worden, aber wahrscheinlich nicht so viel wie sonst, weil einfach alles halt ein bisschen komisch im Moment noch ist. Aber wenn einer von euch möchte, seid ihr gerne dazu eingeladen, schon mal die ersten Fragen zu stellen. Wenn nicht, schauen wir einfach mal so an, was eingereicht worden ist und ihr könnt euch gerne zwischendurch auch melden, wenn irgendwas aufkommt, wo ihr weitere Informationen gerne hättet dazu. Okay, zu den ersten zwei Fragen habe ich nicht wahnsinnig viel, was ich sagen kann. Fangen wir mal an. Wir haben in Search Console zwei Index-Sitemaps eingereicht und sollte soweit erst mal nicht problematisch sein. Jedoch wird bei der einen Sidemap-Datei nur zufällig zwei Sidemaps erfasst und der Rest nicht. Woran kann das liegen? Das müsste ich mit dem Sidemap-Team mal genauer anschauen, mal schauen, was da hängen geblieben ist. Normalerweise sollten wir die eigentlich schon erfassen können. Es ist allerdings so, dass wir nicht alle Sidemap-Dateien immer ständig verarbeiten, sondern wenn wir das Gefühl haben, dass da die Inhalte zum Beispiel sehr ähnlich sind, wie bisherige Inhalte, die wir haben oder wenn wir das Gefühl haben, dass wir mit der Indexierung soweit eigentlich okay dastehen für diese Website, dann kann es sein, dass wir die Sidemap-Dateien gar nicht mehr groß berücksichtigen müssen für einzelne Sites. Aber ich schau das mal mit dem Team an, ob da irgendwas vom Technischen her klemmt oder ob das eher auf unserer Seite einfach ist. Vielleicht können wir da etwas machen, dass das ein bisschen besser klappt. Das Zweite war zur Search Console Meldung gehackt, Inhalteinschleusung bei einer Bedienungsanleitung. Ich habe den Fehler bereits vor einiger Zeit gemeldet und erklärt, dass es kein eingeschleuster Inhalt ist, aber noch keine Rückantwort erhalten, bzw. ist der Fehler noch drin. Ich kann die Anleitung ja nicht ohne weiteres löschen, da diese von unseren Kunden abgefragt werden. Das PDF an sich habe ich schon auf Schadsoftware hin untersucht und nichts finden können. Muss ich für die Seite eine Penalty oder Herabstufung im Trust fürchten, wenn Google diese nicht als sicher betrachtet? Auch wenn es sich dabei um eine False Pause befandelt. Grundsätzlich ist es so, dass wir versuchen, algorithmisch festzustellen, wenn einzelne Inhalte einer Website so erscheinen, also ob sie möglicherweise gehackt werden. Oft ist das der Fall, wenn eine Website über ein Thema hauptsächlich handelt und auf einmal, sag ich mal, pharmazeutische Seiten noch aufgefunden werden beim Crawling und Indexing. Das sind, sag ich mal, die Standardthemen, die von Hacker verwendet werden und wo dann, sag ich mal, Spam-Seiten erstellt werden innerhalb einer bestehenden Website. Und wenn unsere Algorithmen einigermaßen sicher sind, dass das wirklich etwas ist, was der Webmaster nicht gemeint hat, dass das so veröffentlicht wird, dann wird das als gehackt, entsprechend dort gemeldet und in Search Console kriegt man diese Informationen dann auch und kann dann entsprechend dort auch Rückmeldung machen. Manchmal kann es sein, dass unsere Algorithmen das falsch erkennen und da ist es wichtig, dass wir diesen Feedback kriegen, damit wir das entsprechend verbessern können in unseren Algorithmen. Ich weiß allerdings nicht, wie schnell diese Sachen im Moment verarbeitet werden oder allgemein verarbeitet werden, weil das muss man natürlich manuell dann durchgehen. Ich weiß auch nicht, was bei dir jetzt vor einiger Zeit bedeutet. Wenn das schon einige Monate her ist, dann wäre das etwas, was ich gerne mit dem Team anschauen würde. Wenn das jetzt erst in den letzten, sag ich mal, zwei Wochen passiert ist, dann denke ich, liegt das noch einigermaßen im Rahmen. Grundsätzlich, was da passiert, ist, dass wir in den Suchergebnissen versuchen, wir diese Seiten dann nicht für die vermeintlichen geherkten Inhalte ranken zu lassen. Das heißt, wenn wir zum Beispiel erkennen, dass Pharmazeutigung auf einer Seite quasi angeschlossen worden ist, dann versuchen wir halt, diese Seite für die normalen Inhalte in den Suchergebnissen zu zeigen und dann einfach für diese anderen Inhalte dann halt nicht. Das heißt, wir machen das auf einer einzelnen Seitenebene, nicht auf einer Webseitebene. Das heißt, alles, was sonst in deiner Webseite ist, die anderen Seiten, die bestehen eigentlich weiterhin normal, sondern sind dann wirklich nur diese einzelnen URLs, die entsprechend zu markieren sind, wo wir da ein bisschen sorgfältiger damit umgehen in der Suche. Das heißt, eine Herabstufung im Trust oder eine allgemeine Penalty gibt es deswegen nicht. Das ist wirklich etwas, was auf diese einzelnen URLs bezogen ist. Das heißt, in diesem Fall auf diese Bedienungsanleitung, wenn die Inhalte in den Suchergebnissen erscheinen würde, dann könnte ich mir vorstellen, dass unsere Algorithmen da ein bisschen kritischer sind. Wenn zum Beispiel deine Produktzeite zu diesem Produkt in den Suchergebnissen erscheint, dann ist das eigentlich alles ganz normal. Ja, und eben wie gesagt, wenn das schon einige Monate her ist, dass ihr das gemeldet habt, dann wäre ich froh, wenn du mir die URL mal zuschicken könntest. Das kannst du zum Beispiel auf Twitter oder hier als Kommentar einfach hinzufügen bei der YouTube-Frage. Mit welchen neuen Features sind für die Search Console geplant? Weiß ich nicht. Das Team ist natürlich fleißig an weiterarbeiten. Jetzt ist natürlich alles ein bisschen schwieriger, ein bisschen langsamer. Allgemein sind wir jetzt mal mit neuen Launches ein bisschen vorsichtiger, einfach, dass wir dann nicht noch mehr Verwirrung sorgen mit Search Console oder dass unsere Systeme, die für Search Console verwendet werden, auf einmal extrem mehr Ressourcen brauchen. Ressourcen, die man vielleicht anderswo im Moment jetzt noch einsetzen möchte. Grundsätzlich ist es auch so, dass wir neue Features nicht wirklich im Voraus bekannt geben, sondern eher dann, wenn die halt wirklich bereit sind. Ein Hauptgrund dafür ist, dass sich Sachen in letzter Minute sehr schnell ändern können. Ich habe das zum Beispiel mit einigen größeren Anpassungen gesehen, dass sie soweit bereit waren zum Launchen, dass sie quasi am nächsten Tag hätten erscheinen sollen und dann wurden sie erst nochmal zurückgestellt kurzfristig und dann auch längerfristig zurückgestellt, sodass es, glaube ich, in ein halbes Jahr oder länger noch gebraucht hat, bis sie effektiv dann bereit für den Launch waren. Und da möchte mir natürlich vermeiden, dass wir irgendwelche falschen Versprechungen machen, dass wir sagen, oh, jetzt kommt diese super neue Funktion in Search Console und dann geht es ein halbes Jahr, das ist ja auch ein bisschen frustrierend. Ich plane den Re-Launch an der Website mit 300 Unterseiten. Parallel dazu soll ein Domainswitch stattfinden. Die 100 stärksten URLs sind identifiziert, welches Vorgehen macht am meisten Sinn. Erstens ein Domainswitch durchführen, aber alle Inhalte und URLs komplett identisch zur alten Seite halten und später die URLs anpassen und dann Content anpassen. Zweitens Domainswitch durchführen und gleichzeitig die URLs auch die neue Infrastruktur anpassen, die Inhalte der alten Seite übernehmen und erst nach erfolgreichem Wechsel anpassen oder drittens Domainswitch vornehmen, sowie alle URLs und Content anpassen und einfach für alles passen wir 301 ersetzen. Okay, gute Frage. Das klingt nach einer spannenden Zeit. Gerade bei größeren Website-Umstellungen muss man natürlich schon ein bisschen mit Fluktuationen rechnen. Grundsätzlich, was ich ja empfehlen würde, ist, dass man das möglichst aufteilt. Eigentlich aus zwei Gründen, einerseits, damit man das ein bisschen besser überwachen kann, damit, falls irgendwo etwas schief geht, dass ihr da eher im richtigen Moment noch eingreifen könnt und das entsprechend verbessern könnt. Und der zweite Grund, dass man das ein bisschen aufteilen sollte, ist, dass gerade bei einem Domainswitch ist es so, dass unsere Systeme sehr stark darauf optimiert sind, dass wenn man ein Wechsel von einem Domain zum anderen macht und alles andere gleich behält, dann können wir das sehr schnell verarbeiten. Das heißt, egal ob man jetzt die Umstellung der Website vorher oder nachher macht, wenn man den Wechsel vom Domain quasi separat machen kann und diesen Domainwechsel dann eigentlich vollständig macht für den ganzen Domain, dann ist es etwas, was wir viel schneller verarbeiten können, als wenn man da verschiedene Komplexitäten dazu nimmt, dann müssen wir das quasi auf Seitenebene machen und dann die einzelnen Seiten weiterleiten und überlegen, was wie zusammengehört. Grundsätzlich würde ich in so einem Fall wahrscheinlich eher den Domainwechsel zuerst machen, weil das kann man relativ gut verarbeiten, das kann man relativ gut auch beobachten und schauen, dass das einigermaßen abgeschlossen ist erstmal und dann die Umstellung quasi innerhalb der Website machen. Und da ist es dann eigentlich egal, wie man das aufteilt, ob man jetzt die Inhalte zuerst anpasst oder die Uralsstruktur zuerst anpasst, aber da würde ich vielleicht auch schauen, ob man das irgendwie separat machen kann. Je nachdem, was für ein Wechsel da stattfindet, kann man vielleicht die Uralswechsel nicht von dem Inhaltwechsel separieren. Wenn man es nicht kann, dann kann man das halt nicht. Aber ich würde auf jeden Fall den Domainwechsel zuerst machen, das können wir schnell verarbeiten und dann im zweiten Schritt die quasi interne Veränderung machen innerhalb der Website. Manchmal kann man das nicht so auseinandernehmen und dann muss man quasi alles auf einmal machen. Wenn man zum Beispiel ein Markennamen verändert oder wenn Firmen zusammenschließen, dann kann man das ja nicht einzeln durchführen. Da muss man quasi diese Umstellung insgesamt machen. Wir versuchen das trotzdem herauszufinden und versuchen damit irgendwie das zu verarbeiten, aber es dauert einfach viel länger, als wenn man gerade den Domainwechsel vom Rest irgendwie separieren kann. Dann hätte ich eine Frage bezüglich des kürzlich eingeführten Ergebnisse finden auf Sliders auf den Suchergebnissen mit lokalen Treffern. Wie entscheidet ihr, ob und welches Teaserbild in dem Slider angezeigt wird? Kann man es über Structuredata irgendwie vorgeben? Wir sehen mal Bilder und mal nicht und kein wirkliches Muster. Ich vermute, wir haben dann nicht ein klarer Structuredata, den man nur für dieses Element verwenden kann, sondern wir versuchen da wahrscheinlich einfach das Hauptbild von den einzelnen Seiten zu erkennen und das entsprechend für diese Art von Vorschau zu verwenden. Die Vorschau mit einem Bild ist natürlich auch ein bisschen begrenzt darauf, welche Bilder wir überhaupt nehmen können für ein Vorschaubild oder ob auf diesen Seiten vielleicht irgendwelche Einstellungen vorgenommen sind, dass gar keine Vorschaubilder verwendet werden können. Das ist, glaube ich, mit dem Max Image Preview Method kann man das ja auch angeben. Aber meines Wissens, wenn wir das Hauptbild versuchen zu erkennen auf einer Seite, dann nehmen wir schon den, ich glaube, den Article Structuredata dazu und im Article Structuredata kann man ja auch angeben, welches Bild hauptsächlich da verwendet werden soll und dann versuchen wir da schon zu verwenden. Aber es ist natürlich auch so, dass viele Websites diese Art von Structuredata nicht verwenden und da müssen wir halt auf andere Wege irgendein Hauptbild versuchen zu erkennen, falls es etwas Klares gibt auf diesen Seiten. Ich würde gerne für unsere Kunden eine Präsentation zu Google und Google Ads machen. Gibt es hier denn schon Präsentation und Animation, ähnlich wie eure Playlist Search for Beginners, die ich verwenden kann? Weiß ich nicht. Ich weiß nicht, wie das auf der Google Ads-Seite gemacht wird. Ich vermute, die haben auch YouTube-Inhalte, die man verwenden kann, vielleicht auch bestehende Präsentationen, die man weiter verwenden kann, aber ich kenne mich da überhaupt nicht aus. Dann müsste man bei der Google Ads-Seite mal nachfragen. Wenn eine Desktop-Domain noch eine dazugehörige Mobile Subdomain hat und die Gesamtdomain erfolgreich auf den Mobile First Indexing umgestellt wurde, sollte jetzt zwingend auf ein Responsive Design umgestellt werden, um in fünf bis drei Monaten nicht von der Konkurrenz abgehängt zu werden. Das aktuelle Setting ist zurzeit erfolgreich, weil wir inhaltlich sehr viel angeglichen haben. Besteht hier trotzdem dringend Handlungsbedarf. Grundsätzlich ist es so, dass mit einem separaten Mobile Subdomain ist es einfach alles ein bisschen schwieriger. Es ist nicht der Fall, dass wir sagen würden, die Website kann nicht mehr gut in den Suchergebnissen erscheinen, aber es sind verschiedene Sachen einfach ein bisschen komplizierter, weil wir mehr URLs haben, die an und für sich die gleichen Inhalte zeigen. Das heißt, bei einem Wechsel auf Mobile First Indexing würden wir den Mobile Subdomain quasi als Canonical nehmen. Das ist ein bisschen verwirrend, weil ihr habt natürlich in Markup auf den Seiten, gibt ihr an, dass die Desktop-Version Canonical ist und wir wechseln dann trotzdem auf die Mobile Version und nehmen diesen Canonical und Alternate Link eher dazu, damit wir erkennen können, wo die Desktop-Version wäre. Das macht alles ein bisschen komplizierter, wenn man jetzt noch mit hreflang arbeitet, sollte die Mobile Version auch hreflang haben und zum Beispiel auf die andere Mobile Version mit dem hreflang verweisen, nicht auf die Desktop-Version. Das sind alles so Kleinigkeiten, wo man sagen würde, das betrifft in den meisten Fällen nicht das Gesamtranking einer Website, aber das sind einfach Sachen, die sind dann viel schwieriger. Dann muss man einfach auch viel mehr achten, damit das alles richtig zusammenklappt. Und ja, es sind da verschiedene Sachen, die da so zusammenkommen. Von dem her, deswegen sind wir auf die Empfehlung gekommen, dass man möglichst von der Mobile Subdomain zum Beispiel zurückwechseln kann auf eine Responsive Design, wo immer die gleichen URLs für weiterverwendet werden. Aber das ist nicht so, dass ich da jetzt sagen würde, ihr müsst das unbedingt sofort jetzt machen, sondern ihr spart euch viel Ärger längerfristig, wenn ihr diese Umstellung macht. Mobile First Indexing ist noch nicht Erfolg. Leider ist das Seitentipp der Domain, zu dem uns ein Mobile First Fehler über Search Console gemeldet wurde, komplett inhaltsgleich und laut Tool Mobile Friendly. Können die Fehler und Warnungen zur erneuten Prüfung an euch gesendet werden? Ich kann das gerne mal anschauen mit dem Team, wenn du mir einige Beispiele zuschicken kannst. Grundsätzlich muss man aber auch aufpassen, dass man da unterscheidet zwischen Mobile First Indexing und Mobile Friendly. Mit Mobile First Indexing ist wirklich nur die Indexierung gemeint. Da nehmen wir ein quasi immobiles Gerät, um diese Seiten darzustellen und indexieren dann die Inhalte. Mit Mobile Friendly bezieht sich das eher darauf, wie benutzerfreundlich das ist auf einem mobilen Gerät. Das heißt, wenn zum Beispiel der Text mini-client geschrieben ist auf der mobilen Version, dann ist es für die Indexierung total okay. Wir können den Text ja trotzdem lesen aus der HTML-Version. Vom Mobile Friendliness her wäre das aber hingegen ein Problem. Und das sind so die Arten von Unterschiede, die da aufkommen würden, bezüglich der Fehlermeldung. Es ist so, dass wir für einige Websites haben wir angefangen, Briefe über Search Console zu verschicken, wenn wir sehen, dass unsere Systeme das Gefühl haben, dass eine Website noch nicht bereit ist für Mobile First Indexing. Wir haben anfangs geplant, im Herbst auf Mobile First Indexing umzustellen, ob sich da noch etwas tut mit dem Termin, müssen wir natürlich schauen. Jetzt ist alles irgendwie ein bisschen komisch erst einmal. Aber wir wollen ja eigentlich zu dem Moment dann umstellen. Und damit möglichst viele Websites, die noch nicht umgestellt werden konnten auf Mobile First Indexing, wissen, was sie machen sollten, haben wir angefangen, Briefe zu verschicken über Search Console. Im Moment sind das noch nicht so wahnsinnig viel Briefe, aber ich könnte mir vorstellen, dass das ein bisschen zunehmend, sobald wir unsere Systeme so ein bisschen eingependelt haben, dass wir erkennen können, dass die Fehler, die wir melden, wirklich auch brauchbar sind. Das heißt, wenn wir jetzt Fehler an deine Website geschickt haben, die für dich nicht klar sind oder die vielleicht falsch sind, dann wäre ich sehr froh, wenn man die vielleicht an mich mal senden könnte, dann kann ich das mit dem Team genauer anschauen. Wenn das entgegen Fehler über Mobile Friendliness sind, die dann auch zum Beispiel mit dem Mobile Friendly Test irgendwie zusammenhängen, dann sind das Sachen, die hängen eher nicht mit dem Mobile First Indexing zusammen. Vom Namen her sind sie zu ähnlich, denke ich mal. Und man meint oft, dass sie zusammenhängen, aber das sind wirklich ganz separate Elemente. Und Mobile Friendliness wird eigentlich die Indexierung überhaupt nicht betroffen. Das geht lediglich darum, dass wir erkennen können, wenn eine Seite gut für mobile Geräte ist, damit wir sie auch ein bisschen besser positionieren können in den Suchergebnissen, wenn jemand auf einem mobile Gerät sucht. Im kommenden September steigt Google ja komplett auf Mobile First Indexing um. Aktuell betreue ich eine Website, die noch separate URLs verwendet, die von Google empfohlen an Notation mit Desktop REL Alternate und REL Canonical verwendet. Meine Frage wäre nun, kann diese veraltete Variante mit separaten URLs sich nachteilig auf das ganze Crawl- und Indexierungsprozess auswirken und entsprechend einen Verlust an organischem Performance bedeuten, wenn der komplette Wechsel auf den Mobile First Indexing im kommenden September vollzogen wird? Leider wird aus unterschiedlichen Gründen es auch nicht möglich sein, bis dahin auf ein responsive Webdesign umzuschränken. Ja, viel haben wir ja da schon mal angeschaut. Bezüglich Crawling ist es natürlich so, dass man mit einer Endpunktvariante quasi beide Varianten crawlen, damit wir das sauber indexieren können mit quasi der mobilen Version und dem Verweis auf die Desktop-Version. Normalerweise ist das aber unproblematisch. Das heißt, wenn wir einfach 2-mal so viele URLs finden, können wir in der Regel damit trotzdem leben und können wir in der Regel trotzdem die Website normal crawlen. Problematischer ist es eher, wenn wir z.B. URL-Parameter finden, dass auf einmal 10- oder 100-fach die Menge an URLs vorhanden ist. Aber einfach mit Mobile- und Desktop-Version ist es eher unproblematisch und wahrscheinlich wird das ähnlich sein wie jetzt. Jetzt crawlen wir ja eigentlich auch beide Varianten. Jetzt würden wir eher die Desktop-Variante häufiger crawlen, die Mobile-Variante weniger häufig und dann in Zukunft wird das halt umgekehrt sein. Das heißt, vom Crawling her kein Problem. Vom Indexing her, wenn die Inhalte wirklich identisch sind, ist das eigentlich auch so weit kein Problem. Und vom Performance her, vom Ranking her ist quasi die Indexierung eigentlich unabhängig davon. Das heißt, wenn wir die Inhalte finden können, dann können wir die auch normal in den Suchergebnissen zeigen. Wie einfach vorher bei der anderen Frage erwähnt, es wird einfach alles viel komplizierter. Wenn man separate Mobile-Version hat und mit Mobile-First Indexing insbesondere, andere Sache, die ich jetzt noch nicht erwähnt habe, ist z.B. in Search Console. Wenn ich meine Desktop-Domain in Search Console registriert habe und es wird auf die Mobile-First Indexing umgestellt, dann werden alle Daten bei der Mobile-Version der Website in Search Console dargestellt werden. Das heißt nicht mehr bei WWW, sondern vielleicht bei M-Punkt, wenn man jetzt ein M-Punkt Subdomain verwendet. Das ist alles ein bisschen verwirrend, dann wenn man die Daten so anschaut und wenn man das beeinfachen kann, ist das eigentlich immer gut. Eine Frage zu Redirects und Canonicals. Ist es in Ordnung, per 301 redirect auf eine URL weiterzuleiten, die per Canonical auf den Original-Inhalt zeigt? Oder sollte man das lieber vermeiden? Zum Beispiel, example.com, alte URL, redirect auf neue URL mit Sortierung, gleich Preis, und dann ein Canonical einfach auf neue URL. Grundsätzlich kann man das machen. Wir versuchen, das herauszufinden, was da passiert. Das heißt, wir sehen ein Well Canonical ähnlich an, wie eine Art redirect, und wir würden dann diese drei URLs zum Beispiel in eine Gruppe stellen, wahrscheinlich, oder in vielen Fällen sind dann auch weitere URLs dabei, mit anderen Parametern vielleicht, und würden dann versuchen, aufgrund von den einzelnen Elementen, die da vorhanden sind, um sich zu stellen, welche URL als Canonical ausgewählt werden soll. Und da kommen Faktoren, wie zum Beispiel redirects dazu, der Well Canonical kommt dazu, welche URL in der Signup-Datei dabei ist, kommt dazu, wie das intern verlinkt wird, kommt ein bisschen dazu, wie das extern verlinkt wird, kommt dazu mit hreflang, all solche Sachen kommen ein bisschen dazu. Und jedes dieser Elemente hat ein kleines Gewicht, und dann zählen wir das zusammen für die einzelnen URLs und schauen dann, wo quasi es am wahrscheinlichsten ist, dass ein Well Canonical passen würde. Also nicht ein Well Canonical, sondern wo es am wahrscheinlichsten wäre, dass wir einen guten URL finden würden, die wir in den Suchergebnissen zeigen könnten. Vom praktischen Her ist es so, dass wir eher die Canonical URL häufiger crawlen. Das heißt, wenn irgendwelche Änderungen da sind, dann tauschen wir uns auf die zu konzentrieren. Wir würden die in den Suchergebnissen zeigen, aber es ist nicht so, dass da irgendwie vom Ranking Her eine große Veränderung startfinden würde. Das heißt, wenn wir den Canonical von einer URL auf eine andere wechseln, dann tauschen wir eigentlich die URL aus und vom Ranking Her ist das soweit eigentlich alles das Gleiche. Jetzt in so einem Fall, wenn man ein redirect erst macht und per Well Canonical weiter leitet, dann könnte ich mir vorstellen, dass unsere Systeme erstmal ein bisschen damit kämpfen. Ja, einerseits ist ein redirect hier vorhanden, auf eine URL, andererseits ist von der URL dann ein Canonical woanders hin. Wahrscheinlich würden wir dem einfach so folgen. Ein Element, der auch noch dazu kommt, das habe ich jetzt nicht erwähnt, ist, dass wir versuchen, das Canonical, die kurz sind, die eigentlich gut zum Lesen sind und so könnte ich mir vorstellen, dass wir gerade da dann einige Faktoren hätten, die zusammenpassen würden und dass wir dann eher, sag ich mal, die vereinfachte neue URL nehmen würden. Wichtig ist natürlich auch, dass man die interne Linkung anpasst, dass man wirklich auch klar alles in die Richtung zeigt, was man eigentlich haben möchte. Dann, eine lange Frage zur Paginierung. Ist zustand, ich arbeite an einer Seite, die in ihren News-Bereichnismitteln losscrolling arbeitet und zurzeit keine Links für Google zu den paginierten Unterseiten anbietet. Mal kurz durchlesen, was wir da verschieden machen könnten. Quasi ob man die Paginierung mit NoScript Block nehmen soll, ob man die ganze Liste im NoScript Block reinnehmen sollte. Ja, verschiedene Varianten. Schwierig zu sagen, mit all diesen verschiedenen Varianten, was man da am besten machen würde. Grundsätzlich, aus meiner Sicht, ist es schon so, dass wenn man mit infinite scrolling arbeitet, ist es praktisch für uns, wenn man die einzelnen paginierten Versionen separat scrollen kann, weil sonst verlieren wir die. Es ist nicht so, dass wir eine Seite nehmen und dann einfach endlos nach unten weiter scrollen, sondern was wir vom Praktischen her, was wir machen, ist, wir laden die Seite an und für sich in einen relativ langen Viewport, also wie in einem Browser, der ein ganz langes Fenster hat und schauen dann einfach, was da quasi aufgeladen wird. Wenn die infinite scrolling implementiert wird, kann es sein, dass einfach eine Seite dazu kommt oder dass vielleicht der ganze Viewport vollgeladen wird und dementsprechend haben wir dann halt mehr Links zu einzelnen Artikeln oder weniger. Vom Praktischen her ist es wirklich so, dass man am ersten zu den einzelnen paginierten Seiten Links finden könnten, damit wir da direkt hingehen können und die so indexieren können. Wichtig ist eigentlich, da hauptsächlich, dass wir die Links zu den Produkten dann auch finden oder zu den Detailseiten oder in diesem Fall sind das vielleicht Nachrichtenartikel, die man geschrieben hat und dass wir die die einzelnen Artikel dann entsprechend einfach auffinden können. Das heißt, die paginierten Seiten sind ja eigentlich dann nicht das das Wichtigste für uns, sondern eher die Links, die da vorhanden sind und da kann man diese Links auch auf andere Arten und Weisen zur Verfügung stellen. Zum Beispiel bei einem eCommerce Shop ist ja oft der Fall, dass Produkte in verschiedenen Kategorien sind, dass wir so die Links zu den Produkten finden können. Bei Nachrichten Websites hat man vielleicht auch verschiedene Kategorien oder man hat Tag Clouds mit, sag ich mal, Stichwörtern oder Themen zu einzelnen Elementen zu diesen Seiten kommen, dann sind diese Artikel vielleicht trotzdem in der ersten Seite bei den entsprechenden infinite scrolling dort. Eine andere Variante ist, dass man die Artikel auch untereinander sauber verlinkt entweder, dass man sich überlegt welche Artikel sind zu ähnlichen Themen, damit wenn Google eines dieser Artikel mal findet, dann kann es quasi da so den Rest finden. Eine andere Variante aus diesen Artikeln wäre vielleicht einfach auch nach Datum, das man sagt Vorherigonexte Artikel und dann auf den Artikelseiten dann quasi diese Verkettung auch irgendwie zur Verfügung stellt, damit wir die Links innerhalb der Website wirklich finden können. Ich glaube, irgendeine Frage war auch noch was wegen Sidemap-Datei, dass quasi die Artikel nur über die Sidemap erreichbar sind. Wenn die Artikel nur über die Sidemap-Datei vorhanden sind, ist das schon ein bisschen eine Hilfe, aber wir brauchen wirklich auch intern innerhalb der Website irgendwelche Unterstützung. Das heißt, wir müssen wissen, wie wir diese einzelnen Artikeln gewichten sollen. Welche Artikel sind wichtig für euch? Welche sind quasi einfach nur im Archiv noch irgendwo dabei? Das erkennen wir ja, wenn wir die Website-Struktur anschauen können. Wenn wir da eine Art Hierarchie erkennen können, wo wir sehen, das sind jetzt die wichtigsten Sachen, die sind eher von der Startseite oder vom Startteil der Website verlinkt und das sind dann vielleicht eher Sachen im Archiv, die vielleicht auch noch indexiert werden können, aber die jetzt für euch zumindest nicht das Wichtigste sind. Und ja, lange Rede kurzer sehen. Ich denke, wichtig ist, dass man wirklich einfach Links zu den einzelnen Artikeln und das kann man ja über verschiedene Wege machen. Es muss nicht unbedingt über diese eine Endloßscrolling da gemacht werden. Ich habe ein Suchsnibbit, eine prominenten Seite trotz Updates sowohl im Content als auch Erstellungsdatum den 22.05.2018 angezeigt. Das impliziert, dass das Wissen nicht mehr aktuell ist. Hast du eine Empfehlung für uns, um was man darüber hinaus machen kann? Ich habe das kurz angeschaut. Ich weiß nicht, ob man sagen kann, dass ein älteres Datum bedeutet, dass eine Seite jetzt weniger relevant ist oder veraltet ist. Das kann ja in vielen Fällen auch einfach bedeuten, dass man da schon sich länger mit dem Thema auseinandersetzt und aus Erfahrung sprechen kann. Nicht nur, dass man quasi das aktuellste von heute dabei hat. Grundsätzlich ist es so, dass wir verschiedene Faktoren nehmen für ein Datum. Wir haben, glaube ich, Hilfeartikel mal gemacht darüber, wie man das machen kann. Dass man da in Structuredata zum Beispiel angeben kann, welches Datum jetzt hier relevant ist. Auch die allgemeine Empfehlung, dass man das Datum auch auf den Seiten quasi noch dazu nimmt. Ich vermute, dass es jetzt nicht unbedingt das, was du damit machen möchtest, sondern wahrscheinlich will es einfach, dass das Datum gar nicht gezeigt wird. Nicht, dass da ein anderes gezeigt wird. Wir haben im Moment eigentlich keine Einstellung, dass man sagen kann, ich möchte, dass kein Datum erscheint bei solchen Seiten. Ich habe das kurz hier mal angeschaut, die Seite von dir, und ich sehe, dass unsere Systeme da verschiedene Daten erkannt haben aus verschiedenen Gründen und haben halt gemeint, dass dieses Datum eher am relevantesten ist. Im Moment ist das jetzt nicht mehr auf deinen Seiten dabei. Von dem her wirkt das ein bisschen komisch, wenn man die Seiten so anschaut. Was ich vielleicht machen würde in so einem Fall, ist wirklich schauen, wenn man das Gefühl hat, man möchte lieber ein aktuelles Datum verwendet haben, würde ich einfach schauen, dass es wirklich konsequent auch verwendet wird dort. Einerseits in den Structure Data. Ich glaube, das hast du ja schon dort angegeben. Andererseits aber auch auf den Seiten selber. Wenn wir die Seite anschauen, dass ganz klar im Text für uns eigentlich vorhanden ist, das ist das Datum, welches jetzt relevant ist zu diesem Artikel. Wie beziehungsweise wonach wählt Google die Anbieter aus, die in Google Jobs angezeigt werden. Strukturierte Daten ist klar, wir haben in einem Job nicht immer alle Anbieter gezeigt und wonach wird prioritisiert. Weiß ich leider nicht. Weiß ich nicht, wie das da entschieden wird. Aber so weitlich mich erinnere, wollten einige von Google Jobs auch mal ein Hangout machen, speziell über Google Jobs. Ich weiß jetzt einfach nicht, wie das zeitlich jetzt klappt. Jetzt ist ja alles irgendwie ein bisschen anders. Aber das wäre vielleicht eine Variante, dass man da denjenigen von Google Jobs direkt vielleicht mal die Frage stellen könnte. Gibt es so etwas wie ein Master Search Console von Google, wo alles drin ist, was geht? Dies vergleichen wir mit Google Analytics Test Projekt, das Google Merchandising Shops, das wäre gut für Schulungen. Ja, fände ich auch gut, wenn wir so etwas hätten. Im Moment haben wir so etwas an und für sich nicht. Wir haben mal verschiedene Anläufe gemacht zu etwas zu erstellen, aber es ist relativ kompliziert, gerade wenn man soweit eigentlich aktuelle Daten auch dabei haben möchte, wenn man da nicht einfach nur Beispiel-Test-Daten erstellen möchte. Und gerade in Search Console gibt es ja sehr viele Funktionen, die nur dann sind, wenn man sie verwendet. Gerade bei Structured Data ist es ja so, dass wenn man zum Beispiel, ich weiß nicht, keine Breadcrumbs verwendet, dann werden die auch nicht dargestellt in Search Console. Das heißt, man müsste quasi eine Testzeit haben, die all diese Varianten hat und wahrscheinlich würde eine solche Website gar nicht wahnsinnig viel Sinn machen, wenn man all diese Varianten kombiniert. Aber wir nehmen das sicher nochmal Anlauf und versuchen da so etwas hinzukriegen, weil gerade für Schulungen wäre das natürlich sehr praktisch, auch wenn man neu anfängt mit Search Console, wäre es praktisch, wenn man irgendwie ein Search Console hat, wo alle Daten schon dargeladen sind, wo man nicht warten muss, bis alles nachgefüllt wird und auch wo man ein bisschen dass man Angst hat, dass man jetzt die eigene Website oder irgendwas da kaputt macht. Okay, ich glaube, das sind also ziemlich deutlich im Chat scheint sich da einiges zu tun. Gibt es aus eurer Sicht irgendwas, womit ich noch helfen kann? Ja, ich hätte noch eine Frage. Okay. Wir hatten das letzte Mal das Thema mit den 3D Structured Data. Und wir haben uns das Ganze jetzt auch angeguckt und wollten das Ganze integrieren. Sind aber auf den Punkt gestoßen, der sich jetzt noch nicht klären ließ, ob da vielleicht unsererseits noch was umgebaut werden muss oder nicht. Es geht darum, dass wir die Links zu den 3D-Taten so haben, dass am Ende aber nicht die Datei mit File-Ending zum Beispiel Punkt USDZ steht, sondern dass wir quasi Link haben und das Server liefert dann keine Ahnung, Tiger.usdz oder sowas zurück. Und jetzt ist die Frage, ob das Google auch kann oder ob Google da Probleme hat und wirklich einen absoluten Link mit einem Fallnamen hinten bricht. Also wie wäre das dann? Also statt einfach einer absoluten URL ist es eine relative URL? Also es ist, zum Beispiel ist die URL keine Ahnung, meine Webseite.de slash download slash jener ID und der Server liefert dann aber eine USDZ zurück. Also dann würde ich jetzt, wenn ich es mit ein Pause aufrufe, kriege ich ein Download ein USDZ. Das heißt, die Datei-Endung die quasi verlinkt wird, ist nicht das, was effektiv heruntergeladen wird. Genau. Und müsste ich mit dem Team mal anschauen. Ich weiß nicht, könntest du mir vielleicht mal einige Beispiele zuschicken von solchen Zeiten? Da kann ich das mit dem Team mal anschauen. Kann dir gerne so was zuschicken? Wie schicke ich dir das ein bisschen zu, soll ich das irgendwie per Twitter oder sowas machen, dass du auch was... Ich kann mal kurz die E-Mailer gerade sich rein schreiben im Chat relativ einfach. Und dann kann ich das mit dem Team mal hier genauer anschauen. Weil es klingt ja so, dass das eigentlich passen würde für eure Webseiten. Das wäre ja schön, wenn man das mal zum Laufen bringen könnte. Genau. Deswegen fragte ich da ja nochmal nach. Gut. Und wenn ich dir das schreibe, kriege ich dann nochmal eine Antwort? Ich versuch's. Moment, das ist ein bisschen verwirrend, aber das glaube ich schon. Deswegen frage ich einfach nach oder ob du keine Ahnung, ob das dann irgendwie öffentlich dokumentiert ist und ich da nachschauen soll oder so. Damit ich weiß, wo ich da irgendwie eine Anlaufstelle hab. Ich schau mal nach, was wir da machen. Perfekt. John, kann man mich hören? Ja. Hallo, hier ist Martin. Ich hab dich ja schon direkt angeschrieben. Irgendwann wollte ich das jetzt hier nochmal kurz machen. Irgendwie, dass ich mit der Search-Konsole mit den Links, mit dem Link-Modul bisschen unglücklich bin. Und zwar geht es darum, dass ich eine Domain habe, die sehr viele Spam-Links erhält. Unglücklicherweise und irgendwie, weil sich das jetzt auswirkt, muss man sehen. Ich habe jetzt ein Desktop-File erstellt. Das Problem ist, dass ich teilweise von einzelnen Spam-Links, also von einzelnen Link-Krieger. Das heißt, sie verlinken alle meine Seiten und sogar teilweise noch einzelne Dokumente und so weiter. Also Bilder. Und das führt eben dazu, dass sich Tausende von Links angezeigt bekommen in der Search-Konsole, die aber alle Müll sind. Es ist extrem aufwendig. Ich muss seitenweise mich voran klicken, um überhaupt mal einen sauberen Link zu entdecken. Und mich interessieren aber natürlich und deswegen wäre es wirklich praktisch und hilfreich, wenn man sozusagen diese Links entweder ausknipsen könnte, dass man sagt, die sollen nicht mehr angezeigt werden. Oder wenn vielleicht sogar automatisch die Links, die man dissewaut hat, in der Search-Konsole gar nicht mehr angezeigt werden. Weil die hätten ja sowieso keinen Einfluss mehr. Und dann müsste man sie doch eigentlich auch gar nicht mehr sehen. Also das erschwert nur die Arbeit. Und ich habe ja dann noch erwähnt, irgendwie auch schon in einem Online-Mail irgendwie, es wäre natürlich auch sehr praktisch, wenn ich sozusagen profilaktisch bestimmte Top-Level-Domains ausschließen könnte über die Search-Konsole. Ja, ich habe eine deutschsprachige Seite und es ist einfach extrem unwahrscheinlich, dass ich aus Samoa Links bekomme. Also das heißt, das würde ich von vornherein gerne und gerade weil meine Seite eben in einem scheinbar Wettbewerbs starken Umfeld agiert irgendwie und die Wettbewerber nicht davor zu setzen, also solche Pakete zu kaufen, da wäre es natürlich gut, wenn ich das sozusagen von vornherein einfach gleich sagen kann, also alles, was eben von Seiten oder von Top-Level-Domains kommt, wo sowieso keine deutsche Sprache verwendet wird, irgendwie würde ich überhaupt gar nicht mehr haben. Ja, eben das letzte kann man natürlich machen jetzt. Was viele nicht wissen, ist, dass man in der Disavow-Datei kannst du auch Top-Level-Domains angeben. Man könnte zum Beispiel einfach einen Domain-Doppelpunkt XYZ angeben, um alle XYZ-Domains quasi auszuschließen. Das macht es ein bisschen einfacher, aber die Anzeige in Search Console ist natürlich immer noch schwierig, weil da versuchen wir einfach einen Überblick von den gesamten Links zu zeigen und wenn man sehr viele sinnlose Links dabei hat, dann ist es schwierig, die wirklich da herauszufiltern. Ich weiß nicht, wie weit man da vielleicht mit der Disavow-Datei etwas machen kann, aber grundsätzlich ist es so, dass gerade mit dem Links sehen wir einfach, dass sobald wir irgendwas mit dem Links-Report machen, dann denken alle, oh, Links sind jetzt das Wichtigste wieder, jetzt gehen sie los und möchten noch mehr Links sein. Von dem her sind sie da immer ein bisschen zurückhaltend, wenn jemand kommt und sagt, im Links-Report quasi mehr Funktionalität oder ein bisschen eher etwas ausgebaut haben. Aber vielleicht, ich weiß nicht, vielleicht haben sie im Moment Zeit, um solche Sachen zu machen. Ich frag da mal nach. Also noch ganz kurz eine Ergänzung, was für mich natürlich auch extrem schwierig ist, wenn ich so eine Disavow-Datei anlegen will. Ich habe eben einmal gemacht, da waren vielleicht 200 Domains schon drin und jetzt sehe ich irgendwie, okay, ein halbes Jahr später sind wieder ein paar tausend Neue dazu gekommen bzw. ein paar hundert Top-Level-Domains. Ich gehe dann mühsam diese Liste durch und gucke nach irgendwie, was ist ein Spam und was sind tatsächlich saubere Links und dann kann ich aber, dann ergänze ich die einfach nur in der Disavow-Datei. Also ich weiß nicht, inwieweit da doppelte vielleicht drin sind, weil ich kann ja nicht hunderte von Domains sozusagen absuchen und gucken, ob ich die schon mal hatte oder nicht. Ja, das heißt, meine Disavow-Datei wird logischerweise immer länger und wahrscheinlich enthält hier relativ viele Duplikate. Das ist wahrscheinlich egal. Das ist total egal. Auch wenn zum Beispiel etwas über einen Domain abgedeckt wird und dann über einzelne URLs auch noch dabei ist, das ist überhaupt kein Problem. Okay, danke. Super. Okay. Weitere Fragen. Womit können wir noch helfen? Alles still. Okay. Mir ist gerade noch was eingefallen. Es geht darum, dass wir quasi, weil wir ja 3D-Files für bestimmte Katzsysteme anbieten, dass wir das irgendwie auf unserer Seite unterbringen wollen und da haben wir dann halt quasi Texte mit diesem Katzsystem aufgelistet, würden wir auf unsere Seite stellen. Inwiefern ist das denn, weil das man könnte das ja schon eher als Keywords sehen, wenn jemand sagt, okay, er sucht jetzt zum Beispiel eine Schraube für Samsung NX oder Samsung NX heißt das, glaube ich, das Katzsystem, dann soll das ja bei Google ein Treffer bei uns landen. Könnte das jetzt Beaming ausgelegt werden von Keywords oder also Negativ ausgelegt werden? Moment. Okay. Hast du mich gehört eigentlich? Ja, jetzt. Ich hatte noch was. Wie weit das quasi vom Aspaming gesehen wird, sollte eigentlich unproblematisch sein. Wenn das Inhalte sind, die relevant sind für eure Website, dann würde ich sie dabei behalten. Wenn das Inhalte sind, die nicht zu eurer Website passen, dann habt ihr sie ja hoffentlich nicht dabei. Aber manchmal sind ja quasi so benachbarte Gebiete trotzdem noch relevant. Und gerade wenn ihr die Dateien zu diesen Systemen habt, dann gehört das ja eigentlich darauf, sonst weiß man ja nicht, was das ist. Ja, aber ja, die Frage ist halt dahin gehend, weil wenn wir quasi das auf mehreren Seiten haben, deswegen ist halt die Frage halt die Abwägung, was ist zu viel und was ist okay? Das sollte eigentlich unproblematisch sein. Gerade wenn die Inhalte, die gleichen sind auf mehreren Seiten, dann sehen wir das eher als Boilerplate an. Das heißt, das sind Inhalte, die wir häufig sehen auf der Website, wo wir aber das Gefühl haben, die sind für alle Seiten nicht wirklich relevant, sondern vielleicht für eines dieser Seiten relevant. Das heißt, wenn jemand nach diesem Internet macht, dann finden wir wahrscheinlich eine Seite von eurer Webseite und denken, dass das jetzt die richtige Sinn zeigen, dann würden wir einfach nicht alle Seiten zeigen. Das macht ihr eigentlich soweit auch sehen. Okay, gut, perfekt. Dann danke ich. Super. Ja, Hi John. Christian hier, ich bin jetzt erst später dazugekommen. Ich hätte noch eine Frage und zwar hat mich mal ein Kunden gefragt zuletzt, ab wie viel Prozent über Einstimmung von zwei Seiten man von Duplicate Content sprechen kann. Also müssen die Seiten oder die Inhalte dann komplett gleich sein oder reicht das schon ein bestimmter Prozentsatz an Überlappung, damit man von Duplicate Content sprechen kann? Beides. Das heißt, wir haben verschiedene Systeme, die das auf verschiedenen Arten versuchen zu stellen. Am einfachsten ist für uns natürlich, wenn alles 1 zu 1 gleich ist, die ganze Seite, dann wissen wir, dass das die gleichen Inhalte sind. Meistens ist das quasi Inhalt der gleichen Webseite oder von der gleichen Firma auf verschiedenen Webseiten, wenn man Länderversion zum Beispiel hat. Das ist eigentlich total normal. Das andere ist, wenn wir erkennen können, dass einfach ein signifikanter Teil der Seite identisch ist. Und meistens können wir uns auf die Hauptinhalte zu begrenzen. Das heißt, wenn wir erkennen können, dass quasi das Menü ein bisschen anders ist zwischen diesen beiden Seiten, aber der Hauptteil von der Seite ist eigentlich das Gleiche, dann können wir das auch als Duplicate erkennen. Das heißt, wenn man in Search Console sieht, jetzt eine Seite wurde, als Duplicate erkannt, dann kann das ein von diesen beiden sein. Das ist ja ein bestimmtes Regel oder bestimmten Anteil, sondern das ist da wirklich so von Fall zu Fall wird es bewertet. Es hängt ja zum großen Teil auch davon ab, was quasi um diesen Hauptinhaltsstück herum ist. Wenn man ein großes Menü hat oder ein großen Sidebar, dann ist vielleicht ein großer Teil der Seite unterschiedlich, aber das Hauptinhaltsstück ist trotzdem noch identisch. Super, danke. Ich hatte vorhin jemand noch eine Frage. Hi, das spricht der Tom. Hi. Ich hätte mal eine Frage. Es gab ja bei der Google Search Console API in der Version 2 gab es ja diesen Crawl Error Report wo man eigentlich wichtige Informationen rausziehen konnte. Und jetzt ist halt meine Frage, wird der irgendwann mal geplant, dass der wieder zurück kommt? Dann gibt es ja jetzt eigentlich nicht mehr dass ich die Daten mir wieder ziehen kann via API. Ja. Im Moment haben wir glaube ich keine Pläne, da diese Daten speziell wieder zu holen, weil also der Hauptgrund ist an und für sich dass, wir haben das System ja ein bisschen umgestellt, dass wir weniger auf die einzelnen Crawl Fehler achten, sondern eher auf die Effekte bei der Indexierung achten. Das würde ich mir ja höchstens vorstellen, dass wir irgendwann für diese Index Coverage eine API machen und das entspricht ja dann nicht mehr ein zu eins den einzelnen Crawl. Okay ja. Aber die Crawl Fehler selber als API denke ich eher nicht, dass das da kommen wird. Okay, schade. Ja. Es ist immer schön, wenn man irgendwie alles mal eingerichtet hat und dann verschwindet die Funktionalität. Ja, aber passt schon. Danke. Ja, bitte. Ich hätte tatsächlich auch noch eine Frage. Und zwar, wir haben relativ viele Backlinks bei uns auf der Seite, bzw. bekommen relativ viele Backlinks. Da sind teilweise auch Backlinks dabei, wo ich jetzt sagen würde, das sind eigentlich Spam-Seiten. Kann das uns irgendwie schaden bzw. kann man die irgendwie melden oder wie läuft das? Normalerweise wir filteren solche Sachen selber und filtern die einfach aus. Das heißt, in den allermeisten Fällen muss man da gar nichts Spezielles machen. Uns ist bekannt, dass da alle möglichen Spamming-Websites vorhanden sind, die da links setzen. Teilweise machen sie das einfach automatisiert auf alle Websites. Teilweise wird das quasi bestellt oder irgendwie manuell halt gemacht. Aber das ist etwas womit wir eigentlich rechnen müssen beim Crawling und Indexing auszufiltern. Wenn man das selber in die Hand nehmen will und sagen möchte, ich möchte sicher sein, dass Google diese Links jetzt nicht berücksichtigt, kann man das mit einer Disservow-Datei machen. Und das ist eine Funktion, die ist nicht direkt in Search Console quasi integriert, sondern die muss man manuell aufsuchen. Am besten findet man das im Hilfe Center, dass man da nach Disservow links sucht und den Link dann zum Tool selber. Das kann jetzt nicht direkt zu einer Abstrafung dann aufführen, sondern das wird selbst erkannt. Wir versuchen das eigentlich zu erkennen und dann einfach herauszufiltern. Und manuelle Maßnahme wäre dann eher der Fall, wenn es wirklich ganz klar ist, dass es etwas ist, was du gemacht hast oder was einer von eurem Team gemacht hat. Dann könnte ich mir vorstellen, dass wir eine manuelle Maßnahme machen, und kannst das entsprechend dann auch so quasi beheben. Okay, super, danke. Okay. Machen wir vielleicht noch eine letzte Frage, wenn einer von euch noch etwas hat? Alles still. Okay. Das ist auch okay. Also wenn keiner was fragt, dann frage ich noch was. Okay. Jetzt habe ich noch eine Frage, wenn es zum Beispiel zu einer Website Migration oder zu dem Re-Launch kommt, sehe ich immer wieder ein häufigeres Problem in letzter Zeit, dass PDFs extrem lange dauern, bis die von Google erkannt werden, dass da Redirect stattfindet. Und sogar teilweise dann die Koalition, dass die größere PDF ist, dass es je länger dauert, gut ist jetzt nur Annahme, aber gibt es da irgendwas oder dass PDFs irgendwie dass es schwerer ist, irgendwie zu verarbeiten? Wenn wir klare Signale sehen für ein Domainwechsel, wenn wirklich alles 1 zu 1 weitergeleitet wird, dann sollte das relativ schnell gehen. Okay. Sobald wir nicht 100%ig sicher sind, dass es wirklich 1 zu 1 weitergeleitet wird, dann müssen wir das pro URL bearbeiten und gerade bei PDFs ist es so, dass wir annehmen, dass sie weniger häufig wechseln. Das heißt, in der Regel werden die einfach wieder gecrawled. Dann kann es durchaus sein, dass es mal ein halbes Jahr oder länger geht, bis wir die PDF wieder gecrawled haben und dann sehen wir erst den Redirect und folgen dem quasi zur neuen URL. Okay. Kann ich dir auch mal was schicken? Ja, war auch. Okay. Okay. Gut, dann machen wir vielleicht hier Pause. Ich hoffe, das war hilfreich für euch. Ich hoffe, für die vielen Fragen. Ich hoffe, bei euch ist so weit alles okay. Ihr seid alle noch gesund und munter und sitzt halt zu Hause, statt im Büro. Ich auch. Und hoffe, dass wir uns in einen von den nächsten Hangouts wieder mal sehen. Okay. Tschüss.