 Okay, herzlich willkommen zum heutigen Webmaster und SEO Sprechstunden Hangout. Mein Name ist Johannes Müller, ich bin Webmaster Trans Analyst oder Search Advocate hier bei Google in der Schweiz und Teil von dem, was wir machen, sind solche Webmaster Hangouts. Wir haben die auf Deutsch schon relativ lange nicht mehr gemacht, nicht weil ich sie nicht machen möchte, aber einfach weil die Zeit halt irgendwie nicht geklappt hat jeweils. Aber sind jetzt wenigstens wieder hier. So wie es aussieht sind nicht wahnsinnig viele Fragen eingereicht worden, aber wir gehen die mal durch und schauen wie weit wir da durchkommen. Wenn einer von euch anfangen möchte mit irgendeiner Frage, seid ihr gerne dazu eingeladen? Wenn nicht, dann springe ich einfach mal rein, gucken wir was wir hier haben. Wenn Google im kommenden Jahr vollständig auf den Mobile Index umstellt, macht dann eine Optimierung für Desktop auf die Core Web Vitals überhaupt noch Sinn? Oder sollte man sich hier besser auf eine Mobile Optimierung der Core Web Vitals konzentrieren? Das ist eine gute Frage. An und für sich mit den Core Web Vitals und der ganzen Optimierung um diese Faktoren herum ist es so, dass es sich auf das bezieht, was effektiv für Benutzer dargestellt wird in den Suchergebnissen. Das heißt, wenn jemand mit einem mobilen Gerät sucht, dann gelten die mobilen Werte der Core Web Vitals, wenn jemand mit einem Desktop Gerät sucht, dann gelten die Desktop Werte der Core Web Vitals. Die sind im Moment ja noch nicht aktiv. Wir geben euch auf jeden Fall Bescheid etwa sechs Monate bevor wir sie einschalten, damit ihr euch ein bisschen darauf vorbereiten könnt, wenn man so sechs Monate im Vorraus denkt, ist das irgendwann wahrscheinlich im nächsten Jahr. Bezüglich der Mobile First Indexierung ist es da ein bisschen anders. Da crawlen wir die Seiten und indexieren dann nur die Mobile Version. Aber die kann man ja dann auch normalen Desktop benutzen, oder normalen Mobile Geräten benutzer zeigen. Und von dem her macht die Optimierung oder das Arbeiten an jeweils der Desktop und der Mobile Version trotzdem noch sind, gerade in Bezug auf Core Web Vitals. Die Werte da kann man ja auch separat einsehen in Search Console. Diese sind ja bezogen auf die Werte von PageSpeed Insights oder vom Chrome User Experience Report. Da kann man auch jeweils ein bisschen mehr Einblick kriegen. An und für sich aus meiner Sicht macht es auf jeden Fall Sinn, sich auf solche Speed und Usability Faktoren zu konzentrieren und dann ein bisschen etwas zu investieren. Aber man kann natürlich auch sagen, wir sind Desktop Benutzer inzwischen total egal. Ich konzentriere mich nur auf die Mobile Benutzer. Oder man kann auch den Standpunkt nehmen, dass wenn man jetzt für Mobile Geräte optimiert hat, dann wird die Geschwindigkeit auf Desktop wahrscheinlich auch okay sein. Weil meistens es ist ja so, dass es eher auf Mobile ein bisschen schwieriger ist, da gute Werte hinzukriegen. Aber das ist an und für sich euch überlassen, wie ihr das machen möchtet. Im Moment bezüglich Speed ist es so, dass wir das nur in den mobile Suchergebnissen berücksichtigen. Mit den Core Web Vitals ist es natürlich dann wieder auf beiden Bereichen. Dann haben wir da eine zweite Frage. Wir haben gerade ein Problem mit Google News und zwar, dass unsere Ergebnisse ohne Bilder dargestellt werden. Wenn wir die URLs mit dem Mobile Friendly Testing Tool überprüfen, bekommen wir die Meldung Other Error für die Bilder URL. Die Image URLs finden wir zwar im geründeten HTML allerdings nicht im Screenshot. Das eigentlich im Beispiel URLs. Ich habe das kurz hier mal angeschaut und was ich gesehen habe ist, dass der CDN, den ihr verwendet für die Bilder, dass wir das sehr müde haben, den zu crawlen. Seit Größenordnung einer Woche, ist das glaube ich. Und da kommen wahrscheinlich diese Probleme her. Das heißt, wenn wir die Bilder URLs nicht normal crawlen können, dann können sie auch nicht so zauber indexieren. Und so wie ich das sehen kann, können wir einige URLs lesen von diesem CDN. Aber der Großzahl der Request, die wir da machen möchten, haben wir keine Antwort. Und das kann von zwei Seiten her kommen. Einerseits kann es sein, dass zum Beispiel der der Besitzer in Search Console von diesem CDN gesagt hat, ich möchte die Crawling Rate für unseren Domain beschränken. Ich weiß nicht, ob das da gemacht worden ist. Das eine Variante, die andere Variante ist, dass wir einfach das gemerkt haben, dass wir viel weniger crawlen können, als wir vorher gemacht haben. Sei es aufgrund von der Servergeschwindigkeit, der Antwortszeiten oder die Fehler, die zurückgegeben werden vom Server. All diese Sachen können dann ein bisschen zusammenspielen. Man, ihr könnt das wahrscheinlich relativ schnell testen, indem, dass ihr einige Testzeiten macht mit den Bildern einfach woanders gelagert oder die Bilder von anderen URLs einbinden. Um einfach ein bisschen einzuschränken, ist es wirklich unser CDN oder ist es etwas, was wir sonst machen? Wenn das nicht euer CDN ist, ist es natürlich alles ein bisschen schwieriger, aber vielleicht hilft er schon ein bisschen. Hallo, Johannes. Danke für deine Antwort. Ja, also wir haben gemerkt, dass wir auch extrem viel bei Google Discover verloren haben. Natürlich, dass wir derzeit ohne Bilder dargestellt werden und was uns auch ein bisschen Sorgen gemacht hat, ist, dass wir allgemein jetzt ohne Bildern dargestellt werden. Jetzt, wo Google das CDN nicht, also die Bilder nicht mehr abrufen konnte. Allgemein aus allen Ergebnissen, die Bildern auch entfernt worden sind. Und ja, da ist jetzt also eines der Test, eines der Möglichkeiten tatsächlich, wie du gesagt hast, was wir uns überlegt haben, waren die Bildern anders dann zu integrieren. Einfach ein paar Pages dann zum Testen. Aber könnte es irgendwie auch irgendwie eine Art automatisches IP-Blocking gewesen sein, oder sowas, dass auf einmal vielleicht Googlebot zu schnell gecrawlt hat oder irgendwas in der Richtung? Ja, also ich weiß nicht, was auf diesem CDN eingerichtet ist oder ob das unter eurer Kontrolle ist oder nicht. Aber was ich einfach sehe, ist, dass viele der Request, die wir da gemacht haben, einfach blockiert werden, dass wir da keine Antwort kriegen. Und das könnte schon in Richtung IP-Blocking gehen, dass sie vielleicht das Gefühl haben, diese IP-Adressen rufen besonders viele Dateien ab, deswegen sind das vielleicht irgendwie schlechte Bots. Ich weiß nicht, wie das da eingerichtet ist oder ob das quasi auch vom Tageszeit abhängt, dass sie vielleicht irgendwie am Morgen, dass wir da crawlen können und dann im Rest vom Tag, dass wir dann einfach nicht mehr crawlen dürfen vom Server aus. Aber ich würde das, was ich einfach mal machen würde, ist erst einmal einfach nur die Bilder URLs verändern. Das heißt, die Bilder vielleicht direkt bei euch irgendwie mal lagern für einige Testseiten, schauen, ob das funktioniert. Und wenn das effektiv so funktioniert, dann ist wenigstens vom HTML her, vom Structure Data auf euren Seiten, ist das ja dann eigentlich okay. Und dann ist es wirklich eine Frage davon, wo sind die Bilder gelagert und wie können wir sicherstellen, dass zumindest unsere Bilder URLs einmal abrufbar sind. Okay, alles klar. Vielen Dank. Bitte. Da ist noch die Frage- und Antwortfunktion auch noch in Google Meet dabei. Cool. Okay, ich gehe mal die eingereichten Fragen erstmal durch. Ich habe eine Frage zu lokalen Landing Pages. Wir haben eine Schule, die eine bestimmte Ausbildung an ihrem Standort anbietet. Dafür haben wir eine lokale Landing Page erstellt. Wie kann ich außerhalb der Stadt, wo sich diese Schule befindet, besser für diese Ausbildung gefunden werden, zum Beispiel in den liegenen Städten, in Einzugsgebieten und Wohnorten der Schüler? Ich vermute, wenn du meinst, außerhalb der Stadt, dann werden die vielleicht im Moment über Google My Business dargestellten in den lokalen Suchergebnissen, weil normalerweise für die Websuche ist es nicht so, dass wir da den Standort so stark berücksichtigen würden, dass wir dann gar nichts mehr anderes zeigen würden. Normalerweise machen wir das Geotargeting auf Länderebene, das heißt zum Beispiel ganz für die Schweiz oder für ganz Deutschland. Und gerade bei Seiten, wo vielleicht nicht so wahnsinnig viele Möglichkeiten gibt, die wir darstellen können, sollte das wahrscheinlich auch im ganzen deutschsprachigen Sprachraum irgendwie sichtbar sein. Bezüglich der Landing Page selber ist es anfühlt sich nicht so, dass man da etwas Spezielles machen muss, um sichtbar zu sein, quasi in einem breiteren Bereich. Vielleicht ist es eher eine Frage davon, wie Benutzer suchen und wie man da aufhindbar ist. Vielleicht ist es einfach eine allgemeine Rankingfrage. Wie kann man allgemein für diese Keywords ein bisschen sichtbarer sein? Für allgemeine Rankingfragen, ja, weiß ich gar nicht, wie man da am besten anfangen würde, je nachdem, wie viel ihr schon gemacht habt, würde ich da vielleicht die SEO Starter Guides mal anschauen. Wir haben eine, es gibt verschiedene andere Anbieter, die solche Starter Guides haben. Die gehen eigentlich viele der Punkte durch, die man machen kann, um eine Seite allgemein ein bisschen besser sichtbarer zu machen in Google. Aber auf jeden Fall ist es nicht so, dass man da spezielle Structuredata oder Metatags verwenden muss, um sichtbarer zu sein, quasi in der Umgebung von diesem einen Standort. Unsere Nachrichtenseiten werden zusätzlich zur normalen Responsive-Variante auch aus AMP-Variante ausgespielt. Im Quellcode wird über AMP HTML auf die AMP-Version verlinkt. Allerdings wird die AMP-Version nach ca. 10 Tagen wieder entfernt und es bleibt nur noch die Responsive-Variante stehen. Dann wird auch das AMP-HTML Tag aus dem Quellcode entfernt. Für die dann nicht mehr ausführbaren AMP-Versionen wird keine Weiterleitung auf die Responsive-Variante gesetzt, ruft jemand dennoch die AMP-Variante auf. Zum Beispiel durch manuelles Anpassung der URL wird eine leere Seite mit Status Code 200 angezeigt. Kann das nur temporär zur Verfügung stellen der AMP-Versionen zu Problemen, hinsichtlich Indexierung, Traffic und Ranking-Sphere? Schwierig zu sagen. Ich meine, grundsätzlich vom Best-Practice her würde man auf jeden Fall ein Redirect einsetzen von der alten AMP-Version zur aktuellen Version der Seite. Einerseits hilft das Google dazu erkennen, dass die AMP-Version wirklich nicht mehr existiert, dass wir die ein bisschen schneller quasi die Verlinkung zur AMP-Version rausnehmen können aus den Suchergebnissen. Andererseits hilft das Benutzern auch, dass sie eher auf die richtige Version kommen, wenn sie irgendeinen externen Link auf die AMP-Version gefunden haben. Bezüglich externen Links spielt das natürlich auch ein bisschen eine Rolle, weil ab und zu sehen wir, dass Benutzer auf die AMP-Version von Seiten verlinken. Und wenn wir solche Links finden auf die AMP-Version und das liefert dann quasi nur eine leere Seite zurück, dann fällt dieser Link anfühlt sich ins Leere. Das heißt, ihr habt da ein bisschen dann die Möglichkeit verspielt, dass ihr irgendein Wert aus diesen Links zu diesen AMP-Seiten herausziehen könnt. Und von dem her würde ich schon empfehlen, dass man irgendeine Art von Redirect einsetzen kann für solche AMP-Seiten, dass man nicht einfach nur ein 200er zurückgibt. Bezüglich allgemein Indexierung, Traffic and Rankings, das heißt, über die normale Suche, wenn man jetzt diese externen Links zu diesen AMP-Seiten erstmal ausklammert, spielt das keine Rolle. Das heißt, wenn man AMP hat und man nimmt dann die AMP-Seiten wieder zurück, ist das an für sich eure Sache. Das ist eher einfach eine Frage davon, welche URL zeigen wir in den Suchergebnissen für welche Benutzer. Das heißt, für die anderen Sachen spielt das keine Rolle. Man hat einfach diesen kleinen Faktor, dass vielleicht Benutzer mal auf diese Seiten gehen, vielleicht das externe Links mal auf diese AMP-Version verweisen und dass ihr da vielleicht ein bisschen nicht so voll davon profitieren könnt, wie wenn ihr ein Redirect hat. Ihr könnt das aber auch ein bisschen überprüfen, erst einmal, bevor ihr da große Umstellungen macht in der Infrastruktur, indem das ihr zum Beispiel die Server Logs mal anschaut und schaut, wie viel Crawler und wie viel Benutzer gehen wirklich auf diese AMP-Version nach diesen zehn Tagen. Und da könnt ihr einigermaßen dann abschätzen, macht es Sinn, dass wir da jetzt noch groß investieren und ein Redirect einrichten? Oder ja, ist es also, vielleicht kann man einfach eine schönere 404-Seite darstellen und sagen, diese Seite existiert im Moment nicht. Wenn eine Seite Ads schaltet, die Massenweise wegen einer Ads-Policy abgelehnt werden, kann es dann sein, dass die selten oder ähnlichen Gründe für eine schwache SEO-Performance dasselbe Seite verantwortlich sein können. In unserem Fall ist es die Prescription Drugs und eine Family-Friendly-Policy. Wir können da keine Zertifizierung als Online-Apotheke machen, weil wir in der ersten Linie Sprechstunden mit Ärzten anbieten. Hast du generell ein Rat für Seiten mit medizinischem Inhalt, die auch Arzneimittel verkauft? Zum Beispiel kann es Sinn machen, Call to Actions oder Referenzen zum Medikamenten im Info-Content zu entfernen, oder ist so etwas kein Faktor. Ich weiß nicht, wie da das Ganze auf der Ads-Seite gehandhabt wird. Von dem her kann ich da nicht wahnsinnig viel dazu sagen. Bezüglich allgemein medizinischen Seiten und den Inhalten und quasi die Varianten, die auf diesen Seiten bietet, ist es schon so, dass unsere Systeme in den letzten Jahren ein bisschen mehr darauf achten, wie quasi korrekt diese medizinischen Seiten sind. Im Englischen wird da viel davon gesprochen von EAT, von Expertise, Authority, Tiveness und Trustworthiness. Das ist in unseren Quality-Rator-Guidelines. Unsere Algorithmen achten nicht quasi direkt auf diese Faktoren, aber wir nehmen viele Sachen hinein, die ein bisschen ähnlich in die Richtung gelten. Und gerade bei Seiten, wo wir das Gefühl haben, da müssen wir ein bisschen vorsichtiger sein. Da kann es schon sein, dass das ein bisschen eine stärkere Rolle spielt und medizinische Seiten passen natürlich gerade da hinein. Und da ist es dann, sag ich mal, weniger eine Frage davon, welche Ads-Polices gelten und wie das quasi da gehandhabt wird. Sondern wirklich, wenn wir die Seiten anschauen, können wir sicher sein, dass das korrekte Informationen sind, dass das Informationen sind, die unseren Benutzer weiterhelfen, wo wir uns darauf verlassen können, dass das wirklich etwas Relevantes und Korrektes ist. Und da gibt es verschiedene Möglichkeiten, wie man das ein bisschen angehen kann. Es ist nicht so, dass man da einfach ein Mattertag setzen kann und sagen kann, ja, das ist alles super korrekt und relevant, sondern man muss da natürlich ein bisschen überlegen, wie könnte ich das Benutzern auch klarstellen, was wir anbieten und warum sie unseren Seiten vertrauen sollten. Und in vielen Fällen ist es so, dass wenn das für Benutzern klar ist, dann geht das an für sich auch für die Suchmaschinen oder für Google zumindest, dass wir diese Faktoren auch ein bisschen herauspicken können und besser verstehen können. Und manchmal kann man das mit Call to Action ein bisschen anpassen oder mit Referenzen oder dass man da Informationen über die Autoren, über die Urheber von diesen Inhalten ein bisschen besser darstellen kann. Alle solche kleinen Sachen können natürlich schon ein bisschen eine Rolle spielen. Dann, ich habe eine Frage zu Google Indexing. Das ist natürlich gerade jetzt im Moment ein bisschen awkward. Wir sind eine Nachrichten-Webseite und haben über 100.000 Bilder, die zu den Artikeln gehören als separate Seiten mit separaten Canonical. Derzeit indexiert Google Crawler diese Seiten als Duplikate und indexiert sie nicht. Wäre es sinnvoll, diese Bilderseiten mit dem Canonical der Artikelseite zu markieren? Könnte ich mir schon vorstellen, dass das Sinn machen könnte? Ich denke, in solchen Situationen kann ich mir immer überlegen, was ist das Ziel von diesen Seiten? Weil es ist sehr einfach und verlockend, dass man hingeht und sagt, ich habe so viele Dateien und ich mache so viele Seiten daraus und möglichst viele Seiten indexiert bei Google, heißt, dass wir möglichst viel Traffic kriegen bei Google. Aber es ist ja eigentlich nicht wirklich das, sondern für uns ist ja wichtig, Seiten zu haben, wo wir wissen, diese Seiten sind zu diesem Thema relevant, und benutzer die nach diesen Sachen suchen. Sollen wir zu diesen Seiten schicken und da ist wirklich auch etwas Relevantes für sie dort zu finden. Und wenn man jetzt einfach nur Bilderseiten hat, wo einfach ein Bild drauf ist und dann vielleicht ein Bildnahme oder einfach die Bildnummer, dann ist es nicht wahnsinnig relevant für viele Anfragen, die für euch vielleicht interessant sind. Das heißt, wenn jemand nach dieser Bildnummer sucht und auf dieser Seite landen würde, ich weiß nicht, das ist nicht so wahnsinnig interessant für eine Nachrichtenseite, weil das sind ja nicht Benutzer, die wirklich die Nachrichten dann weiterlesen oder die häufiger zu euch zurückkommen. Und von dem her könnte ich mir schon vorstellen, dass man die Bilder vielleicht eher einfach bei den Artikeln indizieren lässt, sodass wenn jemand in der Bildersuche nach etwas aus diesem Artikel sucht, dann können wir diese Seite ganz klar in der Bildersuche auch darstellen. Weil euer Ziel ist ja wahrscheinlich nicht, dass ihr diese Bilder einzeln verkauft oder dass ihr diese Bilder einzeln zur Verfügung stellt, sondern ihr möchtet ja das Benutzer zu euch kommen und anfühle sich eure Nachrichten lesen oder etwas von euch kaufen oder je nachdem, was ihr halt anbietet. Und von dem her würde ich dann nicht einfach blind darauf achten, möglichst viel zu indizieren, sondern wirklich überlegen, was möchte ich anbieten, wofür möchte ich das Benutzer zu meinen Seiten kommen und wie kann ich das so gestalten, dass das wirklich Versuchmaschinen auch klar ist, dass wir relevant sind zu diesen Bereichen. Und ich denke, da würde ich, ich meine, einerseits kann man den Canonical zu den Artikelseiten setzen, könnte das machen, aber ich würde wahrscheinlich die Bilderseiten einfach ganz weglassen und die Bilder wirklich nur bei den Artikeln indizieren lassen, damit Benutzer wirklich auch gezielt zu euren Artikeln kommen und nicht einfach die Bilder anschauen. Hallo? Ja, hallo. Ja, ja, das ist mich präfidisch und die Frage ist auch ganz klar, ja, die eine Movieschreite ist zum Canonical setzen, die andere Movieschreite ist, wo dann alle Galleryseiten weg marken. Aber, actual, wir haben viele Organic-Traffic zu dieser Galleryseiten auch, ja. In einem Jahr, das vielleicht sind Millionen seit Klicks, wo diese Seite auch, und wir müssen diese auch haben in Zukunft und nicht weg marken. In dieser Situation, Canonical ist besser oder was ist besser? Also was natürlich mit, mit dem Canonical passieren würde, ist, dass wir uns auf die Artikelseite konzentrieren für die Indexierung. Das heißt, wenn wir dem quasi folgen, sind an und für sich die Bilderseiten separat gar nicht mehr indexiert. Aber was ich da vielleicht wirklich darauf achten würde, ist nicht nur die Anzahl Benutzer quasi anschauen, also die Anzahl Klicks, die ihr kriegt von diesen Seiten, sondern was effektiv der Wert ist von diesen Benutzern. Sind das wirklich solche, die für euch relevant sind oder sind das einfach Leute, die quasi Bilder zum Herauskopieren suchen? Und wenn Sie einfach die Bilder herauskopieren wollen, ist es ja eigentlich nicht relevanter Traffic für euch, dann ist es ja nicht wertvoll. Genau. Das ist ein ähnliches Problem, haben wir mit unseren Entwicklerseiten auch immer wieder, in dem das wir oft wie einfach allgemeine Begriffe wie Google Suche ranken. Und die meisten Leute, die nach Google Suche suchen, die suchen natürlich ein bisschen was anderes als irgendwelche Entwickler-Dokumentation. Und da ist es dann manchmal schwierig, wirklich auf die bloße Anzahl Benutzer zu achten, weil wir wissen, dass da ein großer Anteil einfach von ihr relevanten Traffic dabei ist. Okay, alles klar. Und diese Galerisator weg machen ist auch ein guter Punkt für Google Crawl Rate, ja. Das ist auch ein guter Google Crawl Rate für uns sehr weniger. Und diese Seite gibt es keine Value. Und das ist auch eine gute Idee, wenn wir das weg lassen. Ja. Ja, das kann durchaus Sinn machen, wenn es viele Seiten sind. Ich meine, eine andere Variante ist zu überlegen, wenn ihr schon so viel Traffic für diese Bilderseiten gibt, gibt es vielleicht etwas, was ihr dort anbieten könnt, was relevant ist für die Benutzer. Wenn das jetzt eure Bilder sind, von euren eigenen Fotografen, könnt ihr diese Bilder vielleicht irgendwie lizenzieren und weiterverkaufen, würde das für euch Sinn machen. Wenn ihr schon viel Traffic rippt, vielleicht kann man ja da auch irgendwie einen Vorteil daraus holen. Aber das sind, denke ich mal, mehr Geschäftsfragen als SEO-Fragen. Okay, alles klar. Okay, danke. Okay. Könntest du noch auf die Umstände der URL-Inspection-Tools in Search Console angehen und gegebenfalls Alternativen anbieten? Ja, was kann man da sagen? Mit dem URL-Inspection-Tool ist natürlich das Inspection-Tool selber besteht weiterhin. Man kann das durchaus weiterhin verwenden. Einerseits, um die indexierte Version anzuschauen, andererseits, um die Live-Version anzuschauen. Das Einzige, was da abgeschaltet ist, ist, dass man die Seiten quasi zum Indexieren weiter schicken kann. Und das sind verschiedene Sachen, die da hineingeflossen sind, dass wir das jetzt erstmal abschalten mussten. Wir haben das, ich denke vor 1, 2 Tagen, haben wir das intern erstmal abschalten müssen. Und wir haben jetzt gemerkt, dass das wirklich etwas ein bisschen längerfristig geht, bis wir das wirklich alles sauber wieder hinkriegen. Und deswegen haben wir das jetzt auch irgendwie offiziell gemacht und auch ganz klar jetzt, glaube ich, im Tool ist es selber, dass dieser Knopf jetzt auch deaktiviert, damit man wirklich weiß, was da los ist. Bezüglich Alternativen kann man natürlich über das normale Crawling und Indexieren gehen. In den meisten Fällen ist es so, dass wir eigentlich Websites normal crawlen und indexieren können. Und wenn man für eine Website wirklich manuell immer alle neuen Seiten einreichen müsste, dann ist das aus meiner Sicht eher einfach ein Zeichen, dass irgendwas sonst mit der Website nicht optimal läuft. Vielleicht geht es darum, dass man einfach zu viele Seiten hat oder zu viele neue Seiten hat oder dass unsere Systeme einfach das Gefühl haben, wir wissen nicht genau, ob sich das wirklich lohnt, alles zu indexieren von dieser Website. Und das könnte natürlich ein Hinweis sein, dass man ein bisschen an der Qualität der Website allgemein arbeiten müsste. Das ist natürlich immer ein bisschen eine schwierige Sache, dass man da quasi an der Qualität arbeiten muss, wenn man das Gefühl hat, die ist ja eigentlich schon einigermaßen okay. Aber unsere Systeme versuchen natürlich festzustellen, wann gibt es da Sachen, die auf dieser Webseite neu veröffentlicht werden, die wirklich relevant sind für unsere Benutzer, die wir wirklich möglichst schnell auch crawlen und indexieren müssen. Gibt es vielleicht Websites, wo wir das Gefühl haben, ja, das ist schon okay, aber es ist nicht kritisch für uns. Und da lohnt es sich an und für sich schon, wenn man versucht, herauszufinden, wie kann man wirklich die Qualität der Website wirklich einen Schritt höher bringen. Und das sind dann Sachen, die unsere Systeme dann auch versuchen zu erkennen. Also einerseits, denke ich mal, mit Sign-Apps kann man natürlich ein bisschen arbeiten. Andererseits über das normale Crawling würde ich auf jeden Fall auch schauen, dass das einfach sauber funktioniert. Mit dem normalen Crawling, gerade bei größeren Websites, wenn man jetzt mehrere Millionen Seiten hat, lohnt es sich auch, auf die ganze Frage bezüglich Crawl-Budget einzugehen und da ein bisschen zu überlegen, wie kann man sicherstellen, dass Google wirklich mit der optimalen Geschwindigkeit crawlen kann. Wir haben einen Blog-Post gemacht, zwei Jahre über Crawl-Budget. Und das sind wirklich die relevanten Punkte dabei. Da kann man das auch ein bisschen anschauen. Und einerseits schauen, wie kann ich Google zeigen, dass meine Inhalte wirklich relevant sind und wie kann ich sicherstellen, dass Google aus technischer Sicht möglichst schnell alles crawlen kann. In der alten Search Console konnte man beim neuen Indexieren einer Seite angeben, ob der Crawler auch die Links auf der Seite folgen soll. Das ist nicht mehr möglich. Wird das nach der aktuellen Umstellung wieder möglich sein? Hintergrund ist der, dass ich bei der Seite aktuell viele Seiten aus dem Index nehme. Ein Anstoß über die übergeordnete Seite wäre da einfacher, um den Prozess zu beschleunigen. Ich vermute, das kommt nicht so schnell wieder in Search Console, dass man da wirklich alle verlinkten Seiten auch neu einreichen kann. Ich denke, gerade in solchen Situationen, wo man viele Seiten entfernt hat, würde ich auch eher über die Sign-up-Datei gehen, dass man wirklich sagt, diese URLs wurden verändert an diesem Datum und dass wir über das dann das Crawling ein bisschen anstoßen können. Ist natürlich ein bisschen verwehrend, wenn man in der Sign-up-File explizit Sachen aufnimmt, die nicht mehr existieren auf einer Website. Man kann möglichst schnell crawlen können und nicht, dass wir die entfernten Seiten indexieren, sondern wir müssen sie hier crawlen, um zu erkennen, dass sie nicht mehr existieren. Was man vielleicht auch machen kann, gerade wenn man Inhalte innerhalb einer Website ein bisschen schneller indexiert haben möchte, ist, dass man die auch ein bisschen relevanter darstellt, innerhalb der Website. Ich denke, jetzt bei entfernten Seiten oder gerade bei neuen oder veränderten Seiten macht das natürlich Sinn. Und das kann man machen, indem man sie eher an einer übergeordneten Stelle innerhalb der Website verlinkt. Das heißt, wenn ich zum Beispiel ein Artikel habe, der jetzt neu dazugekommen ist in einem Shop, statt einfach diesen Artikel einzustellen, irgendwo tief in der Hierarchie von der Website, da erstmal die letzten neuen Produkte auch noch auflistet und da kann Google, wenn die Startseite gecrawlt wird, wirklich dann auch ein bisschen schneller kennen. Ah, das sind neue URLs, die kann ich auch jetzt indexieren und neu crawlen. John? Ja. Ich habe noch eine Frage zu der Frage vom Stefan, die du vorher beantwortet hast. Diese Abschaltung von dem Inspection Tool im Hintergrund betrifft es auch Apicords, die wir machen können, um euch zu sagen, dass ihr eine URL crawlen könnt oder funktioniert das immer noch? Das funktioniert immer noch. Also ich nehme an, du meinst die Indexing API? Ja. Das funktioniert immer noch, das besteht weiterhin. Mit der Indexing API ist es allerdings so, dass das nur Jobseiten, und ich glaube live Video Seiten betrifft. Also normale Web Seiten, Artikel, solche Sachen sind ja nicht in der Indexing API und unterstützt. Okay. Okay, dann mal hier die neuen Sachen, da in der neuen Funktion anschauen, kannst du sagen, ob die Chrome User Experience Daten auch Daten enthalten von Dokumenten, die auf No Index stehen oder via Robots Text gesperrt wurden. Und wer in diese Daten ab 2021 eine Rolle spielen für das Ranking oder fließen hier nur die Bot-Daten ein. Für das Ranking mit den Page Experience Daten, die wir haben, sind effektiv nur die Daten vom Chrome User Experience Report relevant. Das heißt, da sind ja auch die Daten drin von Benutzern, die effektiv auf eure Seiten gehen. Da werden Sachen mit hinein bezogen, wie zum Beispiel die Daten zu eurem Server und die Geräte, die sie haben. Und von dem her ist das eher relevant, als wenn wir einen theoretischen Wert errechnen. Bezüglich No Index und Robots Text blockierten Daten, die können da auch dabei sein. Das heißt, wenn man einen sehr großen Anteil von Seiten hat, die auf No Index sind oder die im Robots Text blockiert werden, kann es sein, dass die Daten für Chrome User Experience Report relevant sind. Es ist natürlich so, dass wir einen sehr kleinen Sample von allen Benutzern anschauen. Das sieht man ja im Chrome User Experience Report oder in PageSpeed Insights. Da kann man ja die einzelnen URLs anschauen, die da quasi bewertet wurden. Wir versuchen aus den bewerteten URLs auch Muster zu erkennen, welche Seiten zusammengehören. Und von diesen Mustern versuchen wir dann, die entsprechenden Ranking-Signale zu nehmen, weil es ist ja so, dass die Chrome User Experience Daten werden ja aggregiert über ein Bereich von etwa einem Monat. Und wenn man neue Seiten dazu nimmt, haben die natürlich erst einmal keine Informationen dabei. Und da müssen wir dann von diesen alten aggregierten Daten erst mal auf die neuen Werte für die neuen Seiten entsprechend Schlüsse ziehen. Das heißt, einerseits wird es bei einigen Websites so sein, dass wir wenig Daten haben, dass wir nur für die gesamte Website quasi Daten haben, die wir auf alle URLs entsprechend verteilen müssen. Für andere Websites wird es so sein, dass wir für einzelne Bereiche ein bisschen mehr Informationen haben. Und das sieht man in den Chrome Core Web Vitals Report in Search Console schon jetzt, wenn man da hineingeht bei den einzelnen Faktoren, wenn man sagt, ah, ich muss jetzt, ich weiß nicht mit den CLS Wert, muss ich da ein bisschen arbeiten mit diesen URLs. Sieht man meistens einzelne URLs und dann eine Zahl für ähnliche Beispiele URLs, die ähnlich sind. Insgesamt zusammenadiert wird das nicht die gesamten indexierten Daten oder die indexierten URLs geben, aber man sieht dann schon, dass es ein Muster, was sehr breit verwendet ist innerhalb der Website oder das sind vielleicht einzelne Muster, die nicht so breit erkannt werden innerhalb der Website. Und so kann man da ein bisschen abschätzen, wie das verwendet wird. Ich denke, schwierig ist es höchstens in solchen Fällen, wo ein großer Teil der Website quasi auf No Index gesetzt wird oder per Robots Text blockiert wird, aber das sind natürlich dann auch alle Seiten, die er in den Suchergebnissen nicht erscheinen wird. Die Blockierung der CDN Image URLs könntest du mir sagen, welchen Server-Response ihr bekommt. Ich müsste das mal genauer nachschauen, aber was ich da auf den ersten Hinblick von unseren Internet-Testing-Tool gesehen habe, ist, dass wir einfach unreachable er kriegen für die Robots Text Datei. Das wird da an und für sich gar keine Antwort kriegen vom Server. Aber ich schaue das nachher noch mal ein bisschen genauer an. Da vielleicht kriege ich da noch ein bisschen mehr raus. Danke, Johannes. Okay, mal schauen, ob wir da noch neue Fragen dazu gekriegt haben. Wenn eine Seite über 301 auf einer anderen Seite weitergeleitet wird, diese Zielseite aber dann wieder über ein Canonical auf die erste Seite verweist, kann das zu Problemen führen. An und für sich zu Problemen führen, ist eher unwahrscheinlich. Höchstens, wenn wir wirklich sehr mühe haben diese Website zu crawlen, dass quasi mehrere URLs dann einfach zu viel sind für uns zu crawlen. Was höchstens schwierig ist oder was höchstens problematisch ist, ist eher für euch. Dass ihr da ein bisschen Schwierigkeiten habt in den kleinen Kennen von welcher URL effektiv jetzt dargestellt werden in Suchergebnissen. Weil in einer solchen Situation, was da passiert ist, wir haben dann diese beiden URLs und sehen, dass die quasi in einem Cluster für Duplicate Content da vorhanden sind und wir müssen dann über die Canonicalization herausfinden, welches diese beiden URLs in Canonical dabei ist. Dann ist es natürlich ein bisschen schwieriger. Dann kann es sein, dass wir vielleicht die Ursprungs-URL-Name für die Suchergebnisse oder vielleicht die Ziel-URL. Vom Ranking her spielt das keine Rolle. Seitdem ihr macht das über quasi von einem Domain zu einem anderen Domain oder sind da länderspezifische URLs noch da im Spiel, dass eine für die Schweiz, eine für Deutschland ist oder so etwas. Aber im Normalfall, wenn das alles auf der gleichen Website ist, dann ist es eigentlich nur eine Frage davon, welches diese beiden URLs in Suchergebnissen dargestellt und entsprechend die, die dargestellt wird, ist dann auch die, die ihren Search Console sieht. Das heißt, für das Tracking ist es einfach ein bisschen schwieriger, weil einerseits wisst ihr nicht genau, welche Variante dargestellt wird in Search Console und andererseits kann das auch wechseln im Laufe der Zeit. Das wir sagen, vielleicht nehmen wir die erste, erste Mal und dann irgendwann haben wir genug Signale für die zweite und wechseln auf die zweite und wenn ihr pro URL das Tracking macht in Search Console, dann sieht das manchmal ein bisschen komisch aus. Auf Domain-Ebene sollte das keinen Unterschied geben. Es gibt auch keinen Unterschied vom Ranking her, von der Sichtbarkeit in den Suchergebnissen. Es ist wirklich einfach nur eine Frage, wer diese URL dargestellt oder die andere URL. Puh. Wir haben alle Fragen durch, die eingereicht worden sind. Gibt es aus eurer Sicht noch irgendwas, was wir kurz besprechen sollten? Vielleicht noch ein Thema, wenn ich darf. Ja. Für ein News Publisher ganz relevant ist diese Veränderung, dass ab 2021 auch Non-AMP-Pages in den M-Crossel aufgenommen werden sollen. Wird es so, als wäre eine Art Veränderung oder was, woran man sich richten kann, um danach zu optimieren, wenn man jetzt auf Non-AMP verzichten möchte, wo man sagt, wir erreichen einen gewissen KPI und wir gehen davon aus, dass wir dann aufgenommen werden? Weiß ich nicht. Das Ziel ist, dass wir da die Page-Experience-Faktoren, also die Core Web Vitals, dazu nehmen um zu bestimmen, welcher Seiten dargestellt werden in diesem Top-Stories-Crossel, glaube ich, heißt das. Aber ich weiß nicht, ob wir da einen gewissen Benchmark haben, wo wir sagen würden, es muss alles im Grün sein oder es muss quasi 80% oder irgendetwas sein. Aber das würde ich auf jeden Fall nochmal nachfragen, wenn wir da ein bisschen näher sind zu diesem Datum. Vielen Dank. Okay. Wenn keine weiteren Fragen da sind, dann machen wir sonst hier Pause. Ich richte auf jeden Fall die nächsten Hangouts wieder ein. Ich denke zeitlich klappt es alles wieder ein bisschen besser. Und vielleicht sehen wir uns dann ein von den nächsten Hangouts dann wieder. Vielen Dank fürs Kommen. Vielen Dank für die vielen Fragen. Und ich hoffe, ihr fand das auch hilfreich. Tschüss, allerseits. Vielen Dank, Johannes. Ja, vielen Dank.