 OK. Herzlich willkommen beim heutigen Google Webmaster Essentials Sprechstunden Hangout. Mein Name ist Johannes Müller. Ich bin Webmaster Trans Analyst hier bei Google in der Schweiz. Und Teil von dem, was wir machen, sind natürlich solche Office Hours Hangouts, wo Webmaster und Publisher beliebige Fragen um rund um Websearch, um Websites stellen können und wo wir versuchen können, irgendwelche Antworten da noch zu finden. Wie immer haben schon einige ihre Fragen angereicht im Voraus. Aber wenn einer von euch anfangen möchte mit den ersten Fragen, könnt ihr gerne loslegen. Ja, dann fange ich mal an. Ich hätte eine Frage zum Speed Update über das so gemunkelt wird seit Januar. Ich habe das gesehen, dass am 15. Januar eine Webseite, die von uns betreut wird, wo wir quasi Page Speed Optimierung gemacht haben. Die ist extrem in der Sichtbarkeit gestiegen, um 500%, während aber auch gleichzeitig die Qualität der Webseite besser analysiert wurde. Das heißt, Keywords Kombination zu denen wir gerankt haben, die aber eigentlich gar nicht so für den User so interessant waren bei den Suchanfragen, die sind rausgeflogen. Oder da gab es halt dieses rein raus mal, ist die Seite mit den Keywords im Index und manchmal fliegt sie raus. Also gab es da schon ein bisschen mehr Update im Januar, oder? Kann man das so sagen? Ich weiß eigentlich nicht. Soweit ich weiß, haben wir das ja, ich habe auf dem Juli vorausgesagt, dass das kommen wird. Müßt ihr allerdings die Plattform von uns mal anschauen, damit ich das genau weiß. Aber meines Wissens ist, kommt das erst noch. Also wahrscheinlich habt ihr da einfach andere Effekte gesehen. Es gibt natürlich immer Veränderungen auch in der Suche und manchmal gehen Webseite hoch, manchmal halt nicht. Wenn du siehst, dass die Webseite quasi reingeht und rausgeht und dass er, sag ich mal, nach einem Indexierungsproblem aussieht, dann würde ich mal überlegen, ob vielleicht irgendwelche technischen Gründe noch dahinter stecken könnten. Dass man die Seite vielleicht nicht sauber crawlen kann oder dass da vielleicht die Inhalte per JavaScript eingebunden werden und dass das manchmal mit dem Rendering nicht klappt für uns. Solche Sachen würde ich da vielleicht mal anschauen. Wenn es nur, sorry. Jetzt nur eine Frage, so quasi vom hoch und runter gehen ist und nicht vom Indexieren selber, dann ist es wahrscheinlich einfach die normalen Algorithmen auf unserer Seite, die da nicht ganz sicher sind, wie sie das einstufen sollen. Also die Seiten sind ja jetzt nicht für diese Keywords, die wir da mit beobachtet haben, optimiert. Also das ist da kein Problem. Die müssen nicht dazu ranken. Ich habe halt 450 Keyword-Kombinationen in der Beobachtung gehabt. Ich habe das jetzt um 200 reduziert, um diese, die reingehen und rausgehen, mal auszuschließen. Und die Konstanten ranken, es steigt eigentlich alles an. Und deswegen halt diese Steigerung 500 Prozent mehr Sichtbarkeit in dem Tool, was wir benutzen. Wir arbeiten dann mit Sehobility. Aber das Speed Update ist dann jetzt im Januar live geschaltet, scharf geschaltet worden. Kann man das so richtig verstehen? Ich schau ganz kurz nach. Ich glaube, wir haben das im Juli, kocht das im Juli, also noch nicht im Januar. Das heißt, das sind das wahrscheinlich irgendwas anderes, was natürlich mit Speed immer ein bisschen zusammenhängt, ist auch die Geschwindigkeit, mit der wir crawlen können. Das heißt, einerseits mit dem Speed Update, was wir da haben, ist ja die Frage, wie schnell die Inhalte sichtbar sind für den Benutzer. Für uns ist aber auch die Crawl-Geschwindigkeit, also wie schnell der Server Antworten liefern kann, auch relevant. Und das macht vor allem dann einen Sinn, wenn meine Website hat, die sehr viele Veränderungen hat, zum Beispiel ein Nachrichten-Website, ein, ich weiß nicht, Immomilien-Website oder wo man Kleinen zeigen hat, wo Inhalte sehr schnell rein und raus gehen. Da ist es natürlich wichtig, dass wir schnell crawlen können. Und wenn wir schneller crawlen können, dann können wir unter Umständen Inhalte schneller finden, die wir dann auch ein bisschen zeitgemäßer quasi in den Suchergebnissen präsentieren können. Wenn es aber eher eine statische Website ist, dann hilft das schnellere Crawling eigentlich nicht so wahnsinnig viel. Dann haben wir die Inhalte einmal gesehen, dann verändern sich ja nicht ständig. Okay, weitere Fragen, bevor wir loslegen mit dem, was angereicht worden ist. Ja, hallo, Janis, Michael. Ja, hallo. Hallo. Ich habe die Fragen schon eingereicht. Die erste hat sich für uns jetzt erledigt, aber vielleicht haben andere auch die Problematik. Wir hatten eine Seite, die hat in den Suchersuchresultaten uns immer angezeigt, also wenn wir eingelockt waren, hat sich angezeigt, diese Webseite ist für Mobilgeräte nicht geeignet. Haben wir diese Seite dann getestet mit euren Tool, dann war sie mobiltauglich und das hat bei uns natürlich zur Verwirrung geführt. Und da ist die Frage eigentlich, was ist hier die beste Vorgehensweise? Okay, was habt ihr da am Ende gemacht? Wir haben die Seite nochmal, also die einzelnen Seiten in das Search-Konsole zum Indexieren eingereicht. Und nach circa einer Woche war die Geschichte dann erledigt. Aber die Seiten gibt es schon länger, also die gab es schon vier, fünf Wochen. Ja, manchmal gibt es da so, sag ich mal, Zeitunterschiede, je nachdem, wie wir das angeschaut haben mit dem Indexieren, dass wir da mal quasi die Desktopseite indexiert haben und dann aus irgendeinem Grund die Verbindung zur mobilen Version verlieren oder einfach nicht mehr halt da haben und das Neu-Einreichen zwingt uns quasi, das Neu-Anzusschauen und dann Neu-Züge prüfen. In der Regel müsste man das eigentlich nicht machen, sollte das eigentlich soweit regelmäßig einfach weiterlaufen beziehungsweise mit dem nächsten Crawl, der e kommt für bestehende Seiten, wird sich das e wieder einrenten. Aber das ist ein guter Tipp mit dem Einreichen per Search-Konsole. Aber vielleicht müssen wir das auch hinkriegen, dass das gar nicht erst so quasi auftritt. Die zweite von meinen drei Fragen lautet heute, ob es gute Kunde dafür gibt, seine Crawlingfrequenz in der Google-Search-Konsole zu erhöhen? Erhöhen. Man kann das machen, wenn man sieht, dass Googlebot nicht nachkommt mit dem Crawling und wenn man weiß, dass der Server wirklich mehr Kapazität hat. Meistens ist das etwas, das man nicht machen muss, weil wir passen ja unsere Crawl-Geschwindigkeit automatisch immer wieder an und das geht dann automatisch immer wieder nach oben, wenn wir sehen, dass wir mehr Crawlen möchten und der Server das aushält, dann passen wir das eigentlich automatisch an. Relevant ist das quasi nach oben einstellen, dann, wenn man eine größere Infrastruktur Veränderung macht, das heißt, man wechselt auf einen neuen Server, ein neues Hosting-Umgebung, auf einen Content-Delivery-Network oder etwas Ähnliches. Und in solchen Situationen gehen unsere Algorithmen erst mal auf die sichere Seite und sagen, wir crawlen ein bisschen langsamer und wir passen das dann an in laufender Zahl. Und wenn ihr eine Website habt, die wirklich schnell gecrawlt werden muss, weil da wirklich immer wieder Nachrichten da sind und ihr wirklich sicher sein wollt, dass all diese Neuerungen gecrawlt werden können, dann kann man das natürlich ein bisschen höher stellen, damit wir ein bisschen schneller unsere höhere Geschwindigkeit wieder einholen. Aber normalerweise, sage ich mal, innerhalb von, sage ich mal, eine Woche oder so passt sich das sowieso wieder an. Das heißt, wenn man jetzt eine Infrastruktur Veränderung macht, wir crawlen ein bisschen weniger. Für die meisten Websites ist das ja total egal. Wir kennen ja die meisten Inhalte sowieso schon. Und im Laufe der Zeit wird sich das dann wieder anpassen, dass wir wieder so schnell crawlen oder schneller als vorher. Okay. Danke. Und meine dritte und letzte Frage ist heute folgende. Nämlich, man kann ja bei WordPress, wenn man jetzt Inhalte eingibt, kann in NoFollow mehr setzen. Das war ja die Empfehlung bisher bei Links, die nach Extern gehen, die gegebenenfalls ja, sage ich mal, eigentlich nach einer Empfehlung ausschauen könnten, die für mich auch eine Vorteile hätte. Muss man jetzt in den Quellcode reingehen oder habt ihr da schon irgendwas am H.A. oder so? Wie das dann einfach wird? Weil es fragen mich natürlich die Leute, die Content eingeben, die jetzt keine Technik, das sind die Fragen mir natürlich. Wie soll ich das jetzt machen? War mir nicht bewusst, dass WordPress da etwas geändert hat. Ich schau das mal hier an. Was da jetzt genau anders ist. Aber normalerweise in den meisten Content-Management-Systemen kann man ja angeben, ob das NoFollow-Link sein soll oder nicht. Bei WordPress kann man jetzt nur noch sagen, dass er Extern ist und die neue Version von WordPress gibt einen Zusatz hinzu, die dann dazu führt, dass man nur auf dieser Seite landen kann, die im Link angegeben sind, auf keiner anderen. Das ist jetzt jetzt so die aktuelle Version von WordPress. Okay. Dann probiere ich das mal aus. Mal schauen, was da kommt, ja. Also wenn es noch Fragen gibt, bitte machen bei mir. Okay, cool. Also, dann gehen wir mal die anderen eingereichten Fragen durch. Wenn ihr zwischen euch Kommentare oder weite klärende Fragen habt, nur laut loslegen. Dann können wir das auch anschauen. Da ist gut, dann vielleicht einmal dazwischen, weil gerade das Thema WordPress war. Ich habe auf irgendeiner Seite gesehen, dass Google angeblich zukünftig bei WordPress mithentwickeln will, um quasi die Suchmaschinenoptimierung zu verbessern. Stimmt das? Wir wollen mit WordPress und anderen größeren Content-Management-Systemen ein bisschen besser zusammenarbeiten, damit die Sachen, die mit WordPress produziert werden, wirklich auch gut funktionieren. Weil es werden ja sehr viele Websites mit WordPress erstellt. Und dann möchten wir eigentlich, dass wenn es irgendetwas gibt, worauf Webmaster irgendwie achten sollten bezüglich ihren Inhalten, dass das zum Beispiel auch bei WordPress relativ schnell dabei ist, nicht dass es da irgendwelche Unterschiede gibt, dass wir sagen, man sollte jetzt zum Beispiel auf HTTPS wechseln und die gängigsten Content-Management-Systemen können gar nicht mit HTTPS arbeiten, dann ist natürlich immer eine Konfliktsituation da. Wenn man da ein bisschen mithelfen kann, dass das wirklich soweit gut klappt zusammen, dann denke ich, kann man da zusammen schon ein bisschen was erreichen. Also ich bin mal gespannt, wie sich das einpendelt. Wir hatten ja zwischendurch auch einige WordPress-Plugins, die von verschiedenen Bereichen von Google so gegeben hat. Und manchmal hat das gut geklappt, manchmal sind die irgendwie liegen geblieben und haben nicht mehr Updates gemacht. Vielleicht kann man das auch ein bisschen verbessern. Okay, dann schauen wir mal die Fragen hier durch. Das Fetchers Google Tool zeigt uns aktuell an, dass der untere Teil unserer Webseite abgeschnitten ist, beziehungsweise, dass ein Futter darüber gelegt wird. In der Wirklichkeit sieht das halt anders aus. Wir befürchten nun, dass Google diese Inhalte fälschlicherweise als Hidden Content werden könnte. Müssen wir da quasi unsere Seiten anpassen, oder ist das okay? Wahrscheinlich ist das überhaupt kein Problem. Das mit dem Fetchers Google Tool ist natürlich so, dass wir versuchen, die Seite einfach darzustellen, wie Google vor sich sehen würde. Wir haben aber auch andere Möglichkeiten, da festzustellen, welche Inhalte sichtbar sind, welche nicht sichtbar sind. Und von dem her würde ich mir wegen dem keine großen Sorgen machen. Manchmal deuten solche quasi Layout Veränderungen, aber auch daraufhin, dass in gewissen Browserkonfigurationen wird das vielleicht auch ein bisschen komisch aussehen. Je nachdem, welche Veränderungen halt da sind. Und von dem her würde ich das mal anschauen und überlegen, macht es Sinn, dass man da irgendwelche CSS-Anpassungen machen, die einerseits für GoogleBoard helfen, andererseits für wirkliche Kunden auch helfen. Wenn das wirklich nur eine Sache ist, die für GoogleBoard sichtbar ist, dann würde ich mir einfach überlegen, ob man das zur Diagnosezwecken sehen muss, quasi, wenn man das selber kontrolliert, oder ob das soweit auch okay ist. Und wenn das für euch okay ist, dann kann man das auch so lassen. Eine Frage zu HFLang, beziehungsweise Mehrsprachigkeit und Sitemap. Es gibt ja die Möglichkeit, in der Sitemap-Datei auch die Länder- und Sprachversion zu hinterlegen, ist das grundsätzlich empfehlenswerter aus der Integration direkt auf der Webseite, oder sind die gleichwertig? Aus unserer Sicht sind die gleichwertig. Sie funktionieren auch von der Geschwindigkeit her, funktionieren sie ziemlich gleichschnell. Das heißt, die Annotationen, die wir in der Sitemap-Datei finden, die verarbeiten wir, dann werden wir die Seite crawlen. Das heißt, es ist nicht so, dass, wenn man die Sitemap-Datei einreicht, dass wir all diese HFLang-Anmerkungen sehen und gleich quasi direkt verarbeiten können, sondern wir müssen die Seite erst mal neu crawlen und neu indexieren, damit wir diese HFLang-Information dazu fügen können. Und von dem her ist es nicht unbedingt schneller. Anführe sich vom Ablauf her, es ist gleichschnell. Es ist einfach eine andere Art, die die Angaben einzureichen. Manchmal ist es ja auch so, dass man im CMS die HFLang-Annotationen nicht direkt angeben kann, oder dass es schwieriger ist, wenn man das auf der Seite einbindet, oder dass man so viel Sprach- und Länderversion hat, dass es keinen Sinn macht für alle. Benutzer diese Liste von Linktags quasi dazu zufügen. Und dann ist eine Sitemap-Datei sich ein guter Weg, das auch zu machen. Aber anführe sich, ist es euch überlassen, welche von diesen Methoden für euch am praktischsten ist. Über den Bereich strukturierte Daten im Search Console bekomme ich gerade die Warnung, seiten möglicherweise geändert. Wenn ich auf Bearbeiten klicke, bekomme ich beim Data Highlighter eine reine HTML-Version meiner React-Seiten angezeigt. Beim Gegenchecken mit dem Tool Abruf wieder auf Google werden die Seiten richtig gerendert. Woher kommt da der Unterschied? Das müsste ich mal genauer mit dem Team anschauen, der mit dem Data Highlighter das quasi zusammenstellt. Ich weiß nicht, ob da vielleicht irgendwelche Limiten da bezüglich gerenderten Seiten bestehen, beim Data Highlighter nicht. Was man auf jeden Fall machen kann, oder was ich in der Regel eher empfehle, ist, dass man die Structured-Data-Markierung wirklich auch in den Seiten direkt einbindet. Dann muss man nicht quasi mit dem Data Highlighter arbeiten, dann ist man auch sicher, dass die Angaben direkt verarbeitet werden, wenn die Seite eingelesen wird. Das heißt, ich würde den Data Highlighter dann verwenden, wenn man etwas Neues ausprobieren möchte mit Structured-Data, wenn man das quasi im ersten Moment mal sehen möchte, wie das funktioniert, wenn man nicht die Möglichkeit hat, die Seiten zu verändern. Aber längerfristig würde ich versuchen, all diese Structured-Data-Elemente wirklich in die Seiten selber einzubinden, sodass es keine Interpretation mehr braucht, bezüglich welcher Daten wirklich für diese Seiten gelten. Hallo, Johannes. Ja. Wir haben das tatsächlich mit dem, also eigentlich als in den Code, eingegeben, die ganzen Structured-Data. Nur wir bekommen diese Warnung über die Search Console, dass ein scheinend Google diese Structured-Data nicht richtig interpretieren kann. Und dann geht man auf Probleme beheben und wird man direkt zum Data Highlighter dann weitergeleitet. Okay. Und das war der Grund eigentlich und auch der Schreck, weil... Okay, dann müsste ich mal schauen, ob da irgendein unnötiger Link quasi da vorhanden ist. Und ihr habt beim Data Highlighter keine Markierung vorgenommen oder keine Sites erstellt? Bis jetzt hatten wir gar keine, das ist eine neue Webseite, die wir haben, relativ neu, wo wir bisher mit dem Data Highlighter nichts getan hatten. Okay, ich schaue mir das mal an. Super, soll ich gerne die Jurelle beherrschen? Das wäre vielleicht am besten, genau. Okay, alles klar, danke. Kann ich das gleich mit den richtigen Sachen anschauen. Cool. Okay, dann ist da noch die Frage mit about you, mit der mobilen Version und quasi Desktop-Version, dass da manchmal die eine Version indexiert werden, manchmal die andere Version. Ich bin mir... Super. Okay, ich habe das mit dem Team hier nochmal angeschaut und aus Ihrer Sicht ist es etwas, was im Laufe der Zeit sich anpausen sollte. Aber es scheint so, als ob du da wirklich sehr geduldig bist und dass man das vielleicht ein bisschen schneller machen könnte. Ich muss da mal nachfragen, was jetzt der aktuelle Stand da ist. Das haben wir, glaube ich, im Januar auch noch mal besprochen. Wir haben erst Zeit, wenn das gut klappen würde. Ich denke, mit dem Mobile First Indexing wird das wahrscheinlich irrelevant, weil dann wird mir sowieso alles anders auf die M-DOT-Version wechseln. Aber bis dahin kann man das vielleicht ein bisschen einfacher für euch machen. Okay, vielen Dank. Ich hätte noch eine weitere kurze Frage. Und zwar, wenn ihr das Escape-Fragment-Cruel abschaltet, jetzt demnächst irgendwann Mitte des Jahres, hört ihr dann sozusagen einfach auf, diese URLs zu crawlen und vertraut auf eure eigenen Möglichkeiten, die Seite so zu interpretieren, wie sie der User auch sehen würden? Ist das der Plan? Genau, ja. Okay, danke schön. Das heißt, wir indexieren dann immer noch diese Hashbang-Gurals, also mit dem Fundzeichen und Ausruferzeichen dran. Aber nicht mehr die Escape-Fragment-Version davor. Danke. Okay, eine Erm-Frage. Schadet es der organischen Performance, wenn es eine Erm-Version eines Artikels gibt, oder sollte man längerfristig, das heißt, wenn das News-Interesse nachlässt, die Erm-Version des Artikels wieder löschen, das schadet überhaupt nicht. Die kann man bestehen lassen. Das macht überhaupt nichts aus. Grundsätzlich ist es ja so, dass das nicht duplicate Content ist, sondern dass es einfach eine alternative Version der gleichen Inhalte auf einer anderen URL. Und von dem her ist es nicht so, dass es da irgendwelche Ranking vor der Nachteile gibt, wenn man jetzt die Erm-Version dabei hat oder nicht dabei hat. Wir relaunchen unsere Produktdatenbank und möchten das Produktdatenblatt gerne zur zentralen Ressource zum jeweiligen Produkt machen. Also mit Preisverlauf, technischen Daten, Fotos, Videos und so weiter. Jetzt überlegen wir, ob wir auch die Inhalte unserer Produkttestartikel komplett auf das Datenblatt übertragen, aber haben Angst wegen Google News. Wird das ein Problem sein für Google News? Kann man das eigentlich lösen? Ich weiß nicht, wie das konkret bei Google News angeschaut wird. Ich würde vermuten, dass das schwieriger ist, weil gerade mit Google News versuchen wir ja, die Newsartikel zu festzustellen auf einer Seite. Und die versuchen wir dann irgendwelche rauszulösen. Und wenn der News-Teil von einer Seite immer wieder woanders ist, auf einer Webseite, dann wird es wahrscheinlich schwierig für uns, den Newsartikel zu erkennen und sauber rauszulösen. Von dem her könnte ich mir vorstellen, dass es da Schwierigkeiten gibt. Was man aber machen kann, ist einerseits beim Google News Team direkt Nachfragen über den Hilfecenter, kann man die ja auch kontaktieren. Gerade wenn ihr eine Beispielseite schon mal habt oder irgendeine Seite mal zu Zestsäcken irgendwo zusammengestellt habt, die so aussieht, damit sie das mal anschauen können und sagen können, grundsätzlich ja oder grundsätzlich nein. Oder wenn ihr das macht, dann wird das klappen. Das würde ich auf jeden Fall mal machen. Der zweite Teil der Frage ist, ob man dann die Testartikel behalten könnte und dann zum Beispiel auf noindex für Googlebot setzen könnte. Ob das klappen würde, da ist das Problem, dass beim MatterTag ist es so, dass wir die restriktivste Variante jeweils nehmen, wenn wir die Seite aufmachen. Das heißt, wenn ihr für Googlebot noindex setzt, dann gilt das automatisch auch für Googlebot News. Umgekehrt ist das ein bisschen anders. Umgekehrt könnt ihr schon sagen, Googlebot News, noindex und Googlebot einfach lassen, weil Googlebot News ist ja quasi eine speziellere Variante als nur Googlebot. Und Googlebot allein ist quasi für alle Googlebots gedacht. Das heißt, die Option, dass man da eine Seite auf noindex für die Websuche setzt und bei Googlebot bei News quasi drin behält, das wird über den MatterTag nicht so funktionieren. Und da wir die Seiten mit dem gleichen Googlebot crawlen, kann man natürlich auch beim Crawl nicht erkennen, ist das jetzt für News oder ist das jetzt für normale Websuche, sondern das wird ja mit den gleichen User-Agent auch gefraut. Eine Frage zu umlauten in URLs. Kann Google ohne Probleme damit umgehen, wenn die Umlaute in URLs verwendet werden? Macht es einen Unterschied, ob die Umlaute in der Domain oder in Verzeichnissen subdomain liegen? Werden Umlaute genauso bewertet wie z.B. OE, AE und so weiter? Aus unserer Sicht könnte die Problem losverwenden. Wir können mit umlautenden Domain umgehen. Wir können mit umlautenden in FAD oder in Query-Parameters umgehen. Das sollte eigentlich alles klappen. Im Domain ist es einfach so, dass das per Punicode wird das ja encodiert. Das heißt, man hat dann dieses XP und die komischen Buchstaben zwischendurch als Domain-Namen im FAD. Meine Fragen beantwortet. Ja. Moment. Das heißt, wenn es im Domain ist, ist das per Punicode. Wenn das im Verzeichnis ist, muss man das per UTF-8 einrichten. Aber grundsätzlich kann man das machen. Bezüglich, ob sie genau bewertet werden wie andere Varianten, ist es wahrscheinlich so, dass wir die leicht unterschiedlich bewerten, ähnlich wie wir das mit den Suchen machen. Das heißt, wenn ich nach einem Namen wie Müller ohne umlautsuche, dann habe ich leicht unterschiedliche Suchergebnisse, als wenn ich mit umlautsuche, einfach weil wir das Gefühl haben, das passt ein bisschen besser. Grundsätzlich bei den Suchergebnissen mit dem URL ist das weniger problematisch, weil wir schauen natürlich die Inhalte in der URL schon an für die Suchergebnisse. Aber das ist ein sehr, sehr kleiner Faktor. Das heißt, wenn die Inhalte auf den Seiten direkt sind, ist das für uns eigentlich wichtiger, als ob sie in der URL auch dabei sind. Wir halten in der neuen Search Console Fehler bei Seiten, die in der Sitemap-Datei enthalten sind, aber auf Noindex stehen. Es sind das schwerwiegende Fehler. Das betrifft etwa 7% unserer Seiten. Ja, was soll man sagen? Schwerwiegend hängt ein bisschen davon ab, was ihr mit diesen Seiten machen wollt. In der Regel ist es so, dass wir empfehlen, die Seiten in der Sitemap-Datei einzureichen, die man effektiv auch indexiert haben möchte. Und wenn ihr natürlich eine Seite in der Sitemap-Datei einreicht und das am Ende dann ein Noindex drauf, dann sind wir ein bisschen quasi verwirrt, weil wir denken, ihr wollt diese Seite indexiert, aber andererseits wollt ihr sie auch nicht indexiert haben. Das heißt, wir nehmen an, dass ihr irgendwie einen Fehler gemacht habt und melden das euch entsprechend in Search Console. Längerfristig würde ich schon schauen, dass man nur die Sachen in der Sitemap-Datei hat, die wirklich auch indexiert werden sollen. Das macht das für uns ein bisschen einfacher. Wir indexieren die Seiten natürlich nicht, wenn ein Noindex auf der Seite ist, auch wenn die in der Sitemap-Datei da sind. Kurzfristig macht das manchmal Sinn, dass man eine Seite mit Noindex in der Sitemap-Datei aufführt, vor allem wenn man Inhalte löschen möchte aus Google. Dann kann man natürlich sagen, diese bestehenden URLs wurden jetzt geändert. Wir haben ein Noindex-Teil auf diese URLs gesetzt und per Sitemap-Datei kann man dann melden, diese Seiten sind jetzt quasi kürzlich verändert worden. Google-Baud geht dann hin, crawlt diese Seiten, Neu-Index, ah, das Noindex, also nehme ich die Seite aus dem Index heraus. Das wird dann zwar in Search Console gemeldet, aber das ist ja eigentlich das, was ihr machen möchtet. Ihr möchtet ja, dass diese Seiten ein bisschen schneller aus dem Index verschwinden. Und das kann man dann so mit so einer Konstruktion ein bisschen schneller machen. Längerfristig würde ich die dann trotzdem rausnehmen, damit ihr nicht dieses Problem habt, wie hier, dass irgendwelche Fehler in Search Console gemeldet werden, die für euch eigentlich so auch gedacht sind und nicht als Fehler angesehen werden soll. Dann haben wir da eine lange Frage zum Thema Online-Shops. In der Regel werden Produkte auf Kategorienseiten auf mehreren parkinierten Seiten aufgeteilt. Meistens werden die parkinierten Seiten ab Seite 2 per Noindex ausgeschlossen. Jedoch wird Crawling freigegeben, manche Shops machen die Links zu parkinierten Seiten auch unkenntlich, zum Beispiel über Ajax oder Formularer oder JavaScript, sodass Google wirklich nur die erste Seite crawlen kann. Hat das einen Einfluss, macht das Sinn. Grundsätzlich ist es so, dass man sich erst mal überlegen muss, ist es wichtig, dass diese Seiten crawled werden oder nicht. In vielen Fällen ist es ja so, dass Produkte in unterschiedlichen Kategorien vorhanden sind und dass man sie über unterschiedliche Wege finden kann innerhalb einer Website. Manchmal kann es aber auch so sein, dass ein Produkt zum Beispiel nur auf Seite 3 einer Kategorienseite gelistet ist und dass das der einzige Link zu diesem Produkt ist. Und wenn dieser Link natürlich auf Seite 3 ist und alles ab Seite 2 vom Indexieren ausgeschlossen ist, dann finden wir eigentlich keinen Link zu diesem Produkt. Und das wäre dann ein Problem. Das heißt, wir finden dann keinen Link zu diesem Produkt. Wir wissen dann nicht, wie das in dieser Website irgendwie zusammenhängt, wie man die durch normales Crawling erreichen kann. Und so kann es auch schwierig sein, dass wir die Seite dann überhaupt indexieren, also diese Produktseite. Das heißt, dass es mal das Erste, was ich mir überlegen müsste, ist es wichtig, dass all meine Kategorienseiten quasi durchgecrawled werden oder kann ich davon ausgehen, dass jedes Produkt irgendwo auf der ersten Seite von eben einer Kategorienseite gelistet wird. Man kann das natürlich auch testen mit einem eigenen Crawler, wenn man das durchgehen möchte. Grundsätzlich ist das etwas, was sehr unterschiedlich sein kann gegenüber unterschiedlichen e-commerce-Webseits. Das heißt, es gibt aus unserer Sicht keine eindeutige Regel, wo wir sagen würden, ihr müsst das immer so machen oder ihr müsst das so machen, sondern das hängt wirklich davon ab, wie ist das bei euch aufgebaut. Und wenn man mal weiß, ob das Crawling der ganzen Kategorienseiten wichtig ist oder nicht, dann kann man sich natürlich überlegen, wie kann ich das Crawling entweder blockieren, weil das vielleicht so viel gecrawled wird, dass es Probleme gibt für meinen Server, dann kann man das zum Beispiel per Robots Text blockieren oder dass man das Crawling einfach ein bisschen weniger empfiehlt, indem man zum Beispiel einen No-Follow-Tag arbeitet, dass man da einfach so das Googlebot ein bisschen klar gibt und sagt, ab Seite 2 müsst ihr da eigentlich nicht groß weitercrawlen, ihr könnt ja schon anschauen, wenn ihr wollt, aber es ist nicht notwendig. Und das sind eigentlich die Hauptvarianten, die ich da anschauen würde. Es gibt natürlich Möglichkeiten, dass man diese Links ganz versteckt oder dass man einen No-Follow mit diesen Links arbeitet, mit AJAX oder mit diesem formularen System arbeitet. Aber grundsätzlich würde ich das so einfach wie möglich halten, es macht wenig Sinn, dass man da viel investiert in einem System, das quasi das Crawling fast blockiert, aber nicht ganz blockiert. Weil entweder will man das ganz blockieren oder man will halt sagen, gut, das ist nicht so wichtig, dann kann man auch einfach mit dem Robots No-Follow-Metal-Tag arbeiten. Okay, dann schauen wir mal, wie das da weitergeht. Manchmal sieht man auch, dass auf Seite 1 der Kategorie für die Indexierung freigegeben ist, entweder keine Links auf Produktdetail-Seiten existieren oder dass sie da auch versteckt werden. Obwohl da Produkte vorhanden sind, macht das Sinn. Aus meiner Meinung macht das wenig Sinn. Das heißt, wenn man diese erste Produktkategorie in Seite crawlen lässt, dann würde ich auch die Links crawlen lassen zu den einzelnen Produkten, weil so können wir natürlich auch die Produkte alle entdecken und durch normales Crawling erreichen. Und es geht dann auch ein bisschen wieder zurück zum ersten Teil, dass man sich erst mal überlegt, welche Seiten müssen eigentlich gekrawlt werden, damit die ganze Website abgedeckt werden kann. Eine Frage zu PageRank, gibt es Ihnen noch und welche Bedeutung oder Auswirkungen hat da momentan? Wir verwenden intern schon noch PageRank, allerdings schon seit langer Zeit einfach in anderen Varianten. Aber es ist nicht so, dass wir sagen würden, das ist jetzt unser Hauptfaktor oder das Wichtigste überhaupt, sondern es ist einfach eines von, ich weiß nicht, über 200 Faktoren, die wir allgemein verwenden für das Crawling, Indexing und Ranking. Von dem her würde ich sagen, es macht wenig Sinn, dass man sich da groß Gedanken darüber macht. Es gibt natürlich immer noch, gerade bei größeren Websites, macht es Sinn, dass man sich überlegt, wie ein Crawler durch eine Website geht. Das ist ja eigentlich auch, wie PageRank sich verteilt innerhalb der Website. Aber das ist dann eher einfach eine Frage vom Crawling her. Finden werden alle Inhalte gefunden oder werden die halt nicht so gefunden? Dann eine Frage zum Indexabdeckungsreport in der neuen Search Console. Wäre es hier möglich anzugeben, wo die Fehler auf der Seite gefunden werden? Das ist etwas, was schon einige gefragt haben. Von dem her vermute ich, dass das Search Console Team daran auch arbeitet, das einzurichten. Wenn du es noch nicht gemacht hast, würde ich auf jeden Fall auch über den Feedback-Link in Search Console diesen Feedback angeben. Weil das Team schaut diese Feedback-Reports regelmäßig an und schaut, was da so zusammenkommt, wo die meisten Feedback-Sachen zusammenkommen und versucht die dann auch ein bisschen zu prioritisieren. Das heißt, wenn wir sehen, dass alle wegen einer Thema quasi nachfragen oder dass alle immer irgendwas besonders gut finden, dann hilft das natürlich auch ein bisschen einzuplanen, was als nächstes gemacht werden soll. Bei einem meiner Projekte ist aufgefallen, dass wir auf der Webseite mehr 60.000 Request pro Tag von Lighthouse haben. Diese zwei User Agents konnte ich identifizieren. Das Mehrwertige an der Sache ist nun, dass die IPs dieser User Agents Google zugeordnet werden können. Systemisch haben wir keine Lighthouse-API, der dergleichen angeschlossen ist. Visuertie-Seite ist so massiv von diesen User Agents gekrawlt, respektive gerendert. Krawlt Google nun Webseiten mit Lighthouse. Meiner Meinung nach, also meines Wissen crawlen wir nicht mit Lighthouse. Es gibt eine Sache, wo wir Lighthouse verwenden. Das ist beim HTTP Archive. Es ist so, dass wir die Lighthouse-Tests für diese URLs, die da sind, auch machen. Und wir legen ja dann die Testwerte auch ab im HTTP Archive, so dass man auch agiliert anschauen kann, zum Beispiel alle Websites aus Deutschland. Wie steht es da mit der Geschwindigkeit? Wie steht es da mit den ganzen Lighthouse-Tests, die man also machen kann? Das wird, meiner Meinung nach, aber nur, ich glaube, einmal im Monat, aktualisiert. Also sollte es nicht der Fall sein, dass da 60,000 Requests am Tag stattfinden. Was natürlich sein kann, ist, dass jemand auf App Engine oder auf einen von den anderen Google Cloud Services selber Lighthouse laufen lässt und das auf gewisse URLs quasi verwendet. Und da ist es natürlich schwieriger für uns. Weil einerseits aus der Google-Suche-Seite wissen wir natürlich nicht, was da gemacht wird. Es ist nicht von Google-Suche her. Andererseits, wenn das für euch Probleme ergibt, dann würde ich das auch Google melden. Ich weiß nicht, wo das am besten passiert. Ich vermute, bei den IP-Adressen, wenn man da den hohes Lookup macht, ist auch eine Abuse-Email-Adresse angegeben. Da würde ich das dann einfach melden und sagen, hey, diese IP-Adressen verursachen so viel Verkehr auf unseren Server, dass es Probleme gibt. Könnt ihr das einschränken? Dann wird das entsprechend weiterverarbeitet. Und je nachdem, wenn das als Abuse angesehen wird, wird das wahrscheinlich irgendwie abgeschaltet. Ja, das wären da eigentlich die Möglichkeiten. Wenn du willst, kannst du mir auch die URLs direkt zuschicken, wenn du da irgendetwas in den Logs hast, dann kann ich das mit dem Team hier auch mal genauer anschauen und überlegen, ob das von uns irgendwie intern verursacht wird oder ob das effektiv irgendjemand ist, der auf Google Cloud ein Server quasi laufen lässt. Die vom Google-Bot eingesetzte Chrome-Version kann kein Hard-to-To-P2. Von dem her kann man dem Crawler auch nicht mitteilen, wann verwendet Google quasi die aktuelle Chrome-Version zum Crawl. Grundsätzlich könnte man das unabhängig voneinander machen. Das heißt, wir könnten auch Hard-to-P2-Support einrichten für Google-Bot, auch mit der älteren Chrome-Version, die da verwendet wird. Ich glaube, 41 ist das. Wir haben bisher das einfach nicht prioritisiert, weil wir das Gefühl haben, dass das vom Crawling her keine großen Vorteile gibt, speziell für Google-Bot. Das heißt, vom Crawling her müssen wir immer noch Rücksicht nehmen auf die Kapazität vom Server. Da bringt es für uns relativ wenig, wenn wir verschiedene URLs gleichzeitig abfragen können, wie man das bei Hard-to-P2 machen kann. Sondern wir müssen immer noch einberechnen, dass das Server einfach begrenzte Kapazität hat. Und wir wollen den Server natürlich nicht überlassen. Von dem her ist es etwas, was beim Google-Bot-Team natürlich bekannt ist, aber nicht unbedingt jetzt eine höchste Priorität ist, weil wir einfach das Gefühl haben, das ändert nicht so wahnsinnig viel für die meisten Websites, wenn man per Hard-to-P2 crawlen kann. Für Benutzer ist das natürlich anders, weil da kann man natürlich die ganzen Optionen von Hard-to-P2 verwenden und dann macht das natürlich auch Sinn. Und es ist auch so, dass Hard-to-P2 ist. So weit ich weiß, ist es quasi ein Upgrade einfach auf die Request. Das heißt, man gibt an, man versteht Hard-to-P2, und der Server sagt dann, gut, dann wechseln wir auf Hard-to-P2 und machen das so. Und das ist nicht so, dass das incompatible Protokolle sind, sondern die arbeiten eigentlich immer zusammen. Kannst du bestätigen, dass ein Update im Dezember 2017 stattgefunden hat und vor allem eine höhere Relevanz des Page-Speeds zur Bewertung von Internetseiten für das Google-Ranking enthält. Es haben auf jeden Fall mehrere Updates in Dezember stattgefunden. Ich denke, der Name wurde extern irgendwie erfunden für die verschiedenen Updates, die da stattgefunden haben. Und es ist nicht so, dass wir sagen, wir haben ein Update gemacht in Dezember, sondern wir versuchen, wirklich 1.000 Updates oder irgend sowas im Jahr zu machen. Und das verteilt sich dann einfach im Laufe vom Jahr. Ende Dezember versuchen wir, keine Updates zu machen, einfach weil da die Techniker in der Regel dann auch in den Ferien sind. Wir wollen da nicht eine Situation haben, wo wir ein Update quasi rausbringen. Und dann gehen alle in die Ferien und am nächsten Tag geht es kaputt. Und wir müssen da irgendwie schnell Veränderungen machen. Aber normalerweise verteilt sich das eigentlich recht gut über das Jahr. Das heißt, es sind auf jeden Fall Updates gewesen in Dezember. Wir versuchen natürlich in der Suche immer die Relevanz ein bisschen zu verbessern. Bezüglich PageSpeed selber weiß ich nicht, ob da irgendetwas da eingeflossen ist. Ich vermute, das kommt alles eben, wie gesagt, erst im Juli, wenn wir da wirklich mit diesem PageSpeed Update arbeiten. Aus aktuellen Anlass muss ich wohl oder übel mit dem Disavow-Tool arbeiten. Es gibt ja viele Stimmen, ja oder nein. Wenn Links tot oder gegeben falsche leichte Umgebung das Tool anwenden oder nicht. Wenn die Links von Seiten kommen, die nicht mehr existieren, dann müsst ihr die auch nicht in Disavow-Datei angeben, weil die fallen dann sowieso raus. Und wir versuchen die Seiten wieder zu crawlen. Dann sehen wir, dass diese Seite nicht mehr existiert. Dann fällt dieser Links sowieso dann wieder raus. Für solche Fälle müsst ihr das nicht machen. Wenn ihr das Gefühl habt, dass ihr wirklich sicher sein wollt, dass gewisse Links nicht mehr gezählt werden und die sind immer noch auf dem Web vorhanden, dann würde ich die einfach in den Disavow-Datei nehmen. Es ist nicht so, dass da irgendein Nachteil da besteht, sondern das ist aus unserer Sicht wirklich ein technisches Tool, das ihr verwenden könnt, um zu sagen, diese Links möchte ich nicht, dass sie mit meiner Webseite in Verbindung gebracht werden. Das ist dann vollkommen okay. Das wird dann quasi nicht beurteilt, warum wollen die jetzt diese Links nicht haben? Wollen die vielleicht irgendwie quasi zugeben, dass sie diese Links mal gekauft haben und deswegen müssen wir dann noch ein bisschen kritischer hinschauen. Das ist wirklich nicht der Fall. Sondern aus unserer Sicht ist das einfach ein Tool, wo ihr angeben könnt. Diese Links möchte ich nicht mehr quasi in Zusammenhang mit meiner Webseite haben. Und dann, wenn wir diese URLs crawlen, dann fallen diese Links raus, dann ist das für uns ganz okay. Mobile First Index, wie bekommt man Umstellung für die eigene Webseite mit? Nur über die Log-Files oder über andere Optionen. Wir sind daran, jetzt einen neuen Blog-Post zu machen für Mobile First Indexing. Wahrscheinlich braucht das noch ein paar Wochen, bis wir da so weit sind. Aber das Ziel ist, dass wir da dann wirklich auch über Search Console, über die Meldungen in Search Console angeben können, dass wir jetzt umgestellt haben für eure Webseite auf Mobile First Indexing. Die Schwierigkeit da ist ein bisschen, dass wir natürlich irgendwelche Informationen haben möchten, die wir euch mitteilen können bezüglich Mobile First Indexing, wenn wir so eine Nachricht herausschicken. Das heißt, wir wollen nicht einfach eine Nachricht schicken quasi. Wir haben Internet etwas umgestellt und wollen nicht gar nichts machen. Es bleibt alles beim Alten, weil dann kriegt man diese Nachrichten als Gefühl, man muss irgendwas machen, aber andererseits sagt Google, man muss nichts machen. Wir möchten da wirklich auch sicherstellen, dass wir irgendetwas Schlaues zu sagen haben, bevor wir dann Meldungen an alle Webseite schicken, wenn wir umstellen. Das schauen wir im Moment, wie wir das zusammenstellen können. Wenn man die Domains arbeiten macht es natürlich Sinn, dass man da zumindest die Informationen gibt, dass die Daten dann auf der m.dot Version vorhanden sind, weil das ja dann die indexierte Variante ist. Kann man den Crawler mitteilen, dass man HTT P2 unterstützt? Haben wir gleich vorhin kurz angeschaut, muss man nicht machen. Hat es einen negativen Einfluss, wenn man in der Sidemap Link angezeigt, die keinen Content haben? Beispiel ein E-Commerce, eine Kategoriesite, die keine Produkte hat. Normalerweise macht das wenig Sinn, wenn man so etwas in der Sidemap-Datei aufführt, weil aus unserer Sicht ist das eine sogenannte empty Search Results-Page, das heißt eigentlich eine soft 404-Seite, eine URL mit einigen Inhalten drauf, also alles rundherum, aber eigentlich das wesentliche Feedback das sind ja dann keine Produkte vorhanden in dieser Kategoriesite. Und von dem her macht es wenig Sinn, dass man das angibt, aber es ist auch nicht so, dass es ein kritisches Problem ist, wenn man die trotzdem angibt in der Sidemap-Datei, also es ist nicht so, dass ich da jetzt viel Zeit investieren würde, solche Situationen gezielt zu erkennen und aus der Sidemap-Datei herausnehmen, wenn man das allerdings von Anfang an schon einbaut und sagt, gut, für solche Kategorien-Seiten, die keine Produkte haben, reiche ich das gar nicht erst per Sidemap ein, das ist natürlich auch eine Variante. Aber ich würde mir da nicht groß den Kopf zerbrechen mit solchen Seiten, weil die fallen schlussendlich beim Nachdenindexierenden sowieso irgendwie raus, beziehungsweise die sind dann nicht so sicher bei den Suchergebnissen und haben für sich auch kein Problem am Ende. Wir betreuen einen internationalen Kunden mit Hreflang-Parametern. Es existiert noch keine polnische Sprachversion in Polen renkt der Brandbegriff selbst allerdings die deutschen Seiten. Wäre hier Englisch nicht die sinnvolle Variante, das könnt ihr eigentlich selber entscheiden, wie ihr das machen möchtet. Das heißt, wenn ihr keine Länderversion habt für eine Website, die mit Hreflang arbeitet, greifen wir zurück auf die X-Default-Variante, die ihr angibt. Und so mit der X-Default-Variante könnt ihr dann sagen, für alle Länder, die jetzt nicht klar definiert werden, möchte ich, dass diese Variante gezeigt wird. Das ist an für sich die saubere Variante, wie man das machen kann. Schwieriger ist natürlich, wenn man sagt, für diese Länder, die ich nicht definiert habe, eine andere Version zeigen, meines Wissens kann man das im Moment nicht machen mit Hreflang. Ich vermute, das wird auch nicht kommen, weil das macht es ja viel komplizierter. Dass man da einige Länder quasi angibt und sagt jetzt quasi in Polen die deutsche Version erstandert. In anderen Ländern dann eher die englische Version erstandert. Da ist Hreflang schon sehr wichtig, wenn man die Englische Version für das Hreflang schon selber genug kompliziert, denke ich. Mal kurz schauen, was da noch in Chat eingereicht worden ist. Da sind noch gleich die Beispiele mit diesen URLs. Okay, das ist eigentlich gut. Für den Keyword-Kredit-Rechner werden nicht nur Seiten mit guten Content zum Thema ranken, sondern auch Antragstrecken von einigen Websites, wo eigentlich gar kein Content existiert. Ist das quasi ein Fehler von Google oder was bedeutet das? Aus unserer Sicht kann das natürlich durchaus sinnvoll sein. Wenn man jetzt so ein Keyword vielleicht mal ein Rechner selber hat, wo jetzt kein Artikel dabei ist auf der gleichen Seite und das ist natürlich trotzdem relevant sein für Benutzern, ist nicht ausgeschlossen, dass wir solche Seiten auch in den Suchergebnissen zeigen. Das heißt, man muss nicht unbedingt 2000 Wörter Artikel auf einer Seite haben, damit sie für solche Suchbegriffe ranken. Von dem her würde ich das jetzt nicht unbedingt als Fehler anschauen. Ich kenne die Suchergebnisse für diese Keywords nicht. Wirklich gekämpft wird um die Plätze, aber es kann durchaus sein, dass ein einfacher Rechner quasi mit einem Formular gegenüber von einem langen Artikel auch relevant sein kann und gut positioniert sein kann in den Suchergebnissen. Eine Frage zum Thema Ajax Crawling, das wird ja offiziell nicht mehr unterstützt. Wenn man bei einer relativ neuen Seite Ajax Angular ansetzt und dazu ein Pre-Rendering-Service verwendet, sollte man den Tag lieber ausbauen oder was ist da die beste Vorgehensweise für die Zukunft. Aktuell werden auch Title- und Meta-Description per Ajax geladen. Per Fetch and Render sieht man trotz Pre-Rendering in Quellcode nicht die eigentliche Inhalte, sondern nur den Standard-Titel und Descriptionen. Ja, wo fängt man da am besten an? Einerseits können wir die immer mehr Seiten die JavaScript verwenden, um die Inhalte aufzubauen, können wir eigentlich sauber auch rendering und so die Inhalte herauslesen. Ich denke, das wird zukünftig sicher im Laufe von dem Jahr noch stark verbessert werden. Wir haben auch Pläne, dass wir da ein bisschen mehr Informationen herausgeben, wie gut funktioniert beim Rendering, was weniger gut funktioniert oder wie man das besser machen kann. Das wird auf jeden Fall im Laufe des Jahres noch kommen. Bezüglich Pre-Rendering oder nicht, ich würde das ich weiß nicht, ich würde da, das vielleicht einfach mal testen, auf eurer Seite, auf unserer Seite, wenn wir die Seiten schneller mal, Sie möchten die Seiten lieber selber renderen, als statt, dass man damit eine Pre-Rendered Version arbeitet. Aus praktischen Gründen macht es aber manchmal Sinn, dass man dieses Rendering selber in die Hand nimmt und selber die Pre-Rendered Version machen kann. Vor allem, wenn man sicherstellen kann, dass die Pre-Rendered Version wirklich 1 zu 1 der Seite entspricht. Quasi auf Dorm-Ebene, wenn man weiß, dass die 1 zu 1 eine Pre-Rendered Version auch vorhanden sind, nicht, dass die Pre-Rendered Version eine vereinfachte Version von den Inhalten ist. Ich denke, das ist mal wichtig. Wichtig ist auch zu bedenken, dass wenn man mit Pre-Rendering arbeitet und irgendetwas geht schief beim Pre-Rendering, dann sind das in der Regel Sachen, die man selber gar nicht merkt. Das heißt, man geht auf die Website, die funktioniert für euch vielleicht problemlos. Wenn Googlebot auf die Website geht, quasi die Pre-Rendered Version, die vielleicht irgendein Fehler hatte und gar keine Inhalte zeigt und aus unserer Sicht würden wir das dann anschauen und sagen, ah, diese Seite ist jetzt verschwunden, gut, nehmen sie aus dem Index heraus. Ihr merkt das dann nicht einmal, aber ihr seht diese Pre-Rendered Version ja selber nicht im Browser und da ist es dann manchmal ein bisschen schwierig, solche Probleme zu erkennen. Wenn man das irgendwie durch monitoring überwachen kann und wirklich sicherstellen kann, dass die Pre-Rendered Version 1 zu 1 dem entspricht, dann könnte man das natürlich so machen. Bezüglich der Frage vom Title und Description ist es so, dass wir die auch nach dem Rendering rausholen, das heißt, wenn wir die Seite selber renderen, nehmen wir die gerendered Version für Title und Description, wenn wir dieses Rendering machen können. Allerdings im Fetch as Google Tool mit der nicht gerenderten Version vom Tool ist es so, dass wir nur die HTML-Version der Seite anzeigen. Das heißt, die gerenderte HTML-Version sieht man dort nicht, sondern man kann höchstens, wenn man Rendering angeht, sieht man natürlich das Screenshot, wo man Title und Description da natürlich nicht sieht. Was man machen kann, um das zu sehen, ist mit dem Rich Results Test zu arbeiten. Der Rich Results Test macht auch ein Rendering und hat die Möglichkeit dann dieses gerenderte DOM auch darzustellen im Tool selber. Das heißt, so kann man feststellen quasi, welche Metathags wie gesetzt werden vom Google Button nach dem Rendering. Und da würde ich das mit diesem Tool dann auch anschauen und kontrollieren. Puh, immer noch ein paar Fragen übrig. So wenig Zeit noch übrig. Ja, ich hatte schnell auch mal eine Frage zum Lighthouse. Und zwar, Chrome kann man ja, wenn man die Seite untersucht, kann man ja Audit starten. Das ist, glaube ich, dieses Lighthouse Tool. Wenn ich es richtig verstanden habe, Google prüft Seiten selber auch mit dem Lighthouse Tool und zieht diese Ergebnisse zur Bewertung heran. Das ist dann wahrscheinlich genauer als die Bewertung über PageSpeed Insights oder Test My Size Wir verwenden das für den HDTV Archive. Das heißt, nicht direkt für die Suchergebnisse, sondern einfach für dieses quasi Messsystem wo die Seiten archiviert werden und die Resultate archiviert werden, damit man das quasi archigiert auch mal anschauen kann. Und nicht direkt für die Suchergebnisse. Wir möchten aber im Laufe der Zeit irgendwie eine Möglichkeit finden, dass wir ein einheitliches Tool haben, für die Geschwindigkeitserkennung, dass man da nicht je nachdem mit diesem Tool, diesem Wert zieht mit dem anderen Tool was anderes und da steht gut, da steht schlecht, sondern dass wir etwas Einheitliches haben, von dem her wird da wahrscheinlich etwas mal gemacht um diese ganzen Tests zusammenzufügen. Wie weit das dann in den Suchergebnissen weiterverwendet wird, weiß ich da nicht. Es kann sein, dass wir da Teile davor nehmen, es kann auch sein, dass wir das einfach machen müssen. Einfach aus praktischen Gründen, weil wenn eine Website zum Beispiel in Amerika gehostet wird für Cron von Amerika, ist das vielleicht für uns sehr schnell. Für Besucher aus Deutschland ist das vielleicht sehr langsam, weil irgendwie diese Verbindung dann doch nicht optimal da ist. Und das sind Sachen, die müssen wir da erstmal herausfinden, dass am besten hin kriegt. Okay, also wir hatten das Picture Element bei unser CMS eingebaut und hatten dann schon für kleinere Viewcores extra andere Bilder, verkleinerte Bilder angezeigt, aber die wurden nie in diese Bewertung quasi mit einbezogen und dann gab es dann immer den Hinweis, hier auf der Standard-Bild, da könnte man bis zu 70% reduzieren, wobei wir aber insgesamt glaube ich 90% der Dateigolse bereits reduziert haben für die entsprechenden mobilen Endgeräte. Ja, ja. Wenn das noch kommen würde. Ja, also ich denke mit dem Lighthouse-Test gibt es viele Informationen, die man da herausholen muss, aber man muss es immer noch selber interpretieren. Man muss auch selber überlegen, wo kommt dieser Testwert her, ist das wirklich etwas, worauf ich jetzt konzentrieren sollte, oder ist es einfach, vielleicht irgendwie Nebeneffekt von der eigenen Einrichtung, wie man das auf der Zeit hat. Cool, okay, dann machen wir vielleicht hier Pause. Die weiteren Fragen, wenn sie für euch noch nicht beantwortet sind, könnt ihr sie gerne auf den nächsten Hangout übertragen. Ich glaube, in zwei Wochen haben wir einerseits ein Google News-Hangout für Google News Publisher und am Nachmittag dann wieder den normalen Webmaster-Hangout. Die Hangout selber richtig noch ein, das heißt, ihr könnt dann auch die Fragen da übernehmen. Ich copy mal die ganzen Kommentare noch raus, mit den Beispiel-Links, damit ich dem auch ein bisschen nachgehen kann. Okay, super. Dann sehen wir uns vielleicht das nächste Mal. Bis dann, wünsche ich euch noch eine gute Zeit. Tschüss, allerseits. Ciao Johannes, vielen Dank. Okay, ciao.