 Okay, herzlich willkommen zum heutigen Webmaster Essentials-Sprechstunden-Hangout. Mein Name ist Johannes Müller, ich bin Webmaster Trans Analyst hier bei Google in der Schweiz. Teil von dem, was wir machen, sind solche Webmaster-Hangouts, wo Webmaster und Publisher allgemein einfach Fragen zu ihrer Website und der Google-Suche stellen können. Es sind schon recht viele Fragen eingereicht worden, aber wie immer empfangen wir vielleicht am besten mit euch an. Ist auf eurer Seite irgendwas, womit wir anfangen sollen? Nein, nicht. Dann fange ich einfach mal mit den eingereichten Fragen an. Zwischendurch könnt ihr gerne weitere Fragen zu den Fragen oder Antworten stellen. Und dann schauen wir, dass wir am Ende auch noch ein bisschen Zeit haben für weitere Fragen, die noch kommen. Okay, also fangen wir mal an mit hreflang. Sind gleich ein paar Fragen mit hreflang gekommen. Was empfiehlst du bezüglich der Nutzung von hreflang-Attribute auf non-canonical Seiten, also mit einem Tracking-Parameter zum Beispiel dabei? Sollen wir da die hreflang-Attribute im Source Code einbauen, auf die kanonische Sprachversion zeigen, keine hreflang-Attribute einrichten oder irgendwas anderes machen. In solchen Fällen würde ich immer auf die canonical Version der Seite zeigen mit dem hreflang, weil wir verwenden hreflang auch als ein Signal für die Canonicalisierung. Das heißt, wenn wir verschiedene URLs haben, wie zum Beispiel mit Tracking-Parameter und ohne, und merken, dass da die gleichen Inhalte gezeigt werden, dann versuchen wir da ein Canonical zu finden für diese Seite oder für diese Inhalte. Und hreflang ist eines von diesen Signalen, die wir da verwenden. Das heißt, wenn wir zum Beispiel auf einer nicht-canonical URL ein hreflang finden, der auf andere canonical URLs verweist, dann können wir das so ein bisschen mitverwenden. Das heißt, ich würde das am ehesten so einrichten. Es ist keine Garantie, dass wir die URLs nehmen als Canonical, die ihr effektiv dort angibt, aber das hilft uns an und für sich schon. Kannst du etwas mehr über die Kategorie gecrawled zurzeit nicht indexiert erzählen? Es gibt darin auch URLs, die auf noindex stehen, ist die Kategorie durch noindextag ausgeschlossen, eine Unterkategorie von gecrawled zurzeit nicht indexiert und komplett darin enthalten. Da ist irgendwie die Frage abgeschnitten, aber okay. Grundsätzlich ist das auf unserer Seite eine Kategorie, die wir erstellt haben, um ein bisschen einfach das Gesamtbild abzurunden. Das heißt, wenn ihr in euren Log-Dateien seht, dass wir URLs gecrawled haben und ihr wundert euch, warum die nicht am Ende indexiert worden sind, dann sind die wahrscheinlich in dieser Kategorie dabei. Und das beinhaltet URLs, die wir einfach nicht indexiert haben, weil wir haben sie vielleicht angeschaut und gemerkt, vielleicht sind die nicht so wahnsinnig kritisch. Es kann unter Umständen sein, dass da URLs dabei sind, die noindex haben. Es sind da verschiedene Gründe, warum wir URLs nicht indexieren würden. Normalerweise, wenn wir feststellen können, dass dann noindex ist und dass sie deswegen nicht indexiert sind, dann versuchen wir das in die Kategorie direkt mit noindex entsprechend reinzunehmen. Aber aus meiner Sicht finde ich das immer ein bisschen schwierig, sei es mal mit dieser Kategorie, weil einerseits finde ich es gut, dass wir möglichst die Informationen auch weitergeben. Das heißt, wir sagen, wir kennen diese URLs, wir haben die schon mal gesehen, wir haben die schon mal gecrawled. Andererseits ist es nicht sehr hilfreich für euch, wenn ihr einfach eine Liste habt von den URLs, die wir nicht indexiert haben, weil ihr seht ja dann eigentlich den Hintergrund nicht, warum wir sie nicht indexiert haben. Das heißt, ich würde diese Liste gelegentlich einfach mal anschauen und überlegen, ob es da vielleicht Muster gibt, die ihr verbessern könnt auf eurer Website, dass es einerseits vielleicht klarer ist für Google, dass das richtige Teil ist in der Website, oder vielleicht seht ihr auch, dass all diese URLs wirklich URLs sind, die nicht für euch kritisch sind, die nicht unbedingt indexiert werden müssen. Wir haben eine große Gaming-Seite, die schon fast 20 Jahre alt ist und somit 100.000 indexierte Seiten. Nun hat eine Thin-Content-Analyse ergeben, dass wir tausende URLs löschen könnten, weil die Artikel extrem inhaltsarm oder gar leer sind. Ist es problematisch für Google, wenn wir quasi über Nacht 10.000 Fehlerseiten produzieren? Sollen wir den Thin-Content lieber in eine Tappen löschen? Ich finde das total unproblematisch, wenn ihr viel Inhalt auf einmal löscht. Das kann es geben, das ist nicht für uns ein Zeichen, dass irgendetwas schlecht ist mit der Website oder dass sie nicht mehr so gut ist oder nicht mehr so wichtig ist wie früher, sondern wenn ihr Inhalte löschen wollt, dann könnt ihr die löschen. Dann ist es nicht so, dass man die schrittweise löschen muss oder dass man da irgendwie das verschachteln muss mit Redirect oder sonst etwas, sondern einfach wenn ihr jetzt einen Teil von der Website löschen wollt, dann könnt ihr das einfach löschen. Das ist überhaupt kein Problem. Und insgesamt auch, wenn das mal 10.000 Seiten sind, innerhalb einer Website, die mehrere 100.000 Seiten hat und das 10.000 Seiten sind, die so gut wie kein Traffic aus der Suche bekommen, ändert wahrscheinlich auch nicht wahnsinnig viel für euch. Wenn das hingegen Seiten sind, die wir sehr häufig crawlen, dann spart ihr euch längerfristig natürlich ein bisschen crawlen und wir können uns besser auf die Sachen konzentrieren, die ihr wirklich indexiert haben wollt. Von dem her, wenn ihr feststellen könnt, dass das Inhalte sind, die wirklich nicht mehr brauchbar sind, dann würde ich die einfach löschen. Ich finde verstärkt Descriptions, die von Google selbst gesetzt werden, anstatt die zu nutzen, die von den Webmastern vorgegeben werden. Ich verstehe, dass Google wenig relevante Descriptions so zum Wohl einer besseren User Experience ersetzen möchte. Gleichzeitig sehe ich aber die Qualität dessen, dass Google aus Textfragmenten des Side-Contacts zusammenstellt, als deutlich schlechter an, als was die Webmaster in den allermeisten Teilen zur Verfügung stellt. Sollen wir uns die Arbeit sparen, mit MetaTags überhaupt zu arbeiten oder was kann man da machen? Grundsätzlich ist es, sag ich mal, so, dass wir wahrscheinlich weiterhin aufgrund von den Description-MetaTags arbeiten, sowie auch Teile vom Inhalt der Webseiten, der Hauptgrund, den ich da immer wieder sehe, ist, dass wir versuchen, den Descriptions so anzupassen, dass das zu dem passt, wo nach der Benutzer gesucht hat. Das heißt, damit es für den Benutzer wirklich klar ist, warum diese Seite gerade jetzt relevant sein soll, können wir ja dann Auszug von der Seite oder ein Auszug vom Description nehmen und das entsprechend so präsentieren für den Benutzer. Das heißt, es ist weniger der Fall, dass wir immer die gleiche Description verwenden würden für einzelne Seiten, sondern wir versuchen, das wirklich je nach Suche anzupassen. Und dementsprechend kann es auch ein bisschen, sag ich mal, irreführend sein, wenn man mit einer Side-Abfrage zum Beispiel nachschaut, wie sind meine Seiten indexiert? Und dann zeigen wir ja häufig Titel und Snippets an, die vielleicht eher allgemein sind. Einfach, weil wir nicht genau wissen, wovon auch gesucht wird. Mit einer Side-Abfrage sagt man ja eigentlich nicht, was man jetzt sehen möchte. Und dementsprechend kann es sein, dass dort die Snippets ein bisschen anders sind, als was der Benutzer effektiv sehen würde, wenn man nachschaut, wo nach die Benutzer suchen. Das heißt, zur Kontrolle, was ich da machen würde, ist eher in Search Console nachschauen, welche Suchanfragen die meisten Impressions geben, welche Suchanfragen vielleicht vom Click-through-Rate her ein bisschen auffallen. Weil das sind ja dann oft Sachen, wo man sehen kann, dass sie häufig gezeigt werden für den Benutzer, aber der Benutzer klickt nicht so häufig drauf. Das heißt, es ist für euch vielleicht ein Zeichen, dass man da etwas mit der Beschreibung verbessern könnte. Und dann effektiv diese Suchanfragen ausprobieren, nicht mit einer Side-Abfrage, sondern wirklich mit diesen Suchanfragen das auszuprobieren und dann schauen, was dort dargestellt wird. Und manchmal sieht man, dass wir einen Teil aus der Description-Metathalke rausholen. Manchmal nehmen wir einen Teil von der Seite hervor, weil wir denken, das ist relevanter. Wenn man das Gefühl hat, dass für diese Seite, dass man da eine bessere Beschreibung erstellen könnte, würde ich das mit dem Description-Metathalck probieren. Es ist nicht so, dass wir immer Inhalte aus der Seite herausholen, sondern wir machen das eher, dann entfällen, wenn wir über den Description-Metathalke nicht die richtigen Informationen finden, die wir den Benutzer darstellen können. Das heißt, manchmal sehen wir, dass im Description-Metathalck zum Beispiel etwas allgemein ist, steht und der Benutzer sucht nach etwas Speziellen, was nur im Bereich der Seite selber ist, dann versuchen wir das hervorzuheben. Wenn wir hingegen diese speziellen Informationen auch in Meta-Descriptions schon finden können, dann können wir das ja direkt dort aus diesem Teil der Seite herausholen. Das heißt, Meta-Descriptions gehen sicher nicht weg. Ich denke, dass die bleiben weiterhin relevant. Und dass es weiterhin eine Möglichkeit, wie ihr euch ein bisschen besser in den Suchergebnissen präsentieren könnt, egal, ob ihr vom Ranking-Hair jetzt etwas davon seht oder nicht. Meta-Descriptions werden ja auch für das Ranking nicht verwendet. Darf ich dann eine kurze Nachfrage noch stellen? Ja, klar. Und zwar sind die Descriptions kein Direktive-Ranking-Signal, aber ihr werdet ja doch aus, wie die User drauf reagieren. Jetzt sehe ich, dass das, was wir produzieren als Webmaster, eine Beschreibung dessen ist, was der User finden kann. Das soll ihn ja auch animieren zu klicken. Also das ist ja auch der Wettbewerb, in dem wir stehen. Wohingegen die von Google produzierten Descriptions fragmentiert wirken, schwer liestbar sind und eigentlich kaum wirklich den User auffordern hier, klick mich. Und insofern entgeht uns da ein Ranking-Signal, weil der Klick eben nicht passiert. Und das zweite, was ich denke, ist bei ganz verschiedenen Suchernfragen in ganz unterschiedlichen Bereichen, habe ich festgestellt, dass mittlerweile echt 70 bis 80 Prozent von Google quasi überbügelt werden. Ich habe das dann geprüft, Descriptions sind eingetragen, aber Google findet die nicht gut genug, offensichtlich, zu Suchernfrage. Und das irritiert mich einfach. Also werdet ihr verstärkt in diese Richtung gehen oder schraubt ihr das auch wieder zurück, sodass wir mehr bestimmen können, wie eure Serbs aussehen quasi? Ob das stärker oder weniger stärker ist, kann ich nicht sagen. Das ist schwierig zu sagen. Aber was mir sehr helfen würde, ist, wenn ich Beispiele hätte, dann kann ich nämlich mit diesen Sachen direkt zum Team gehen. In vielen Fällen habe ich als Beispiel nur eine Site-Anfrage von Benutzern. Und da kann ich eben nicht wahnsinnig viel mit anfangen, weil das ja keine, sag ich mal, normale Suchernfrage ist. Aber wenn du mir zum Beispiel Screenshots schicken könntest mit normalen Suchernfragen, wo man wirklich sehen kann, dass die Beschreibung, die da gebracht wird, nicht gut laserlich ist, dass das wirklich schlecht zusammengestellt ist, dann ist das etwas, womit ich dann auch zum Team gehen kann und sagen kann, hey, zumindest auf Deutsch, vielleicht bei dieser Webseite gibt es da Probleme, die wir besser hinkriegen müssen, wo wir vielleicht eher auf den Description-Meter-Tag zurückgehen sollten oder vielleicht, wo wir einfach allgemein unsere Algorithmen da ein bisschen verbessern können. Prima, das Angebot nämlich gerne an, schicke ich dir eine Mail. Danke. Super, okay. Das gilt übrigens für alle. Also wenn ihr insgesamt sieht, dass zum Beispiel bei den Titels oder bei den Snippets, dass da Sachen Kong, die schlecht zusammengestellt werden, dann höre ich das gerne. Was ich vielleicht noch dazu sagen möchte bezüglich indirekten Ranking-Signals, ist nicht so, dass wir da diesen Click-through-Rate als Ranking-Signal verwenden. Das heißt, es ist nicht so, dass wenn ihr jetzt mal schlechte Clicks habt für die Suchergebnisse, sodass das irgendwie problematisch wäre für das Ranking der Webseite, es ist natürlich so, dass wenn der Titel oder die Beschreibung nicht gut aussieht, dann klicken wir Nutzer vielleicht woanders hin. Das ist sicher eine Sache, aber vom Ranking her würde ich mir da keine Gedanken machen. Ich hätte da eine Frage zu, wenn man jetzt auf Platz vier ist, also könnte man dann theoretisch über den Titel gar nicht versuchen, einen Platz höher zu kommen, so wie ich das jetzt gerade verstanden habe. Also zum Beispiel so ein Click-Anreiz bieten, das würde nicht funktionieren, oder? Ich glaube, das würde nicht funktionieren. Ich meine, wir verwenden die Titel, verwenden wir schon aus kleinen Ranking-Signal. Das heißt, wenn Sachen im Titel dabei sind, die relevant sind für diese Suchernfragen, dann helfen die uns schon. Aber es ist nicht so, dass, wenn man jetzt irgendwie ein Click animiert, dass man auf einmal höher steht. Okay, alles klar. Würde ja dann schnell dazu führen, dass jeder einfach irgendwelche blinkende Symbole noch dazunehmt oder möglichst einfach auffällt, ohne dass es wirklich relevant ist. Okay. Seit unsere Domains auf Mobile First umgestellt wurden, schlagen bei uns in der Google Search Console immer mehr Hreflang-Fehler auf. Zum Beispiel DE keine Rücklings. Unser Canonical entspricht in Google Anforderungen für Mobile First. Vom Einstellungen her sieht es eigentlich okay aus. Das heißt, die Website hat eine WWW-Version für Desktop und eine M-Punkt-Version für Mobile. Und die Hreflang-Links sollten eigentlich zwischen der M-Punkt-Version sein, gerade auf Mobile. Das heißt, wie kann man das erklären? Das heißt, wir indexieren ja die mobile Version als Standard-Version, gerade bei einer Website, die Mobile First Indexing ist. Und wenn man eine M-Punkt-Version als Standard-Version hat, dann nehmen wir diese Variante für die Indexierung und dann müssen die Hreflang-Links zwischen dieser Version entsprechend auch passen. Das heißt, auf der M-Punkt-Version, wenn man ein Hreflang-Link hat, dann sollte das auf andere M-Punkt-Versionen verweisen und entsprechend auch zurück. So wird das wir die Sauber verknüpfen können. Das Ganze ist gerade bei mobilen Sites mit einer M-Punkt-Version und das heißt mit separat der mobilen URLs, ist das immer komplizierter. Früher war das in die andere Richtung kompliziert, dass wir da manchmal die mobile Version gezeigt haben bei Desktop oder die Desktop-Version, bei Mobile-Version. Und jetzt ist es natürlich andersherum ein bisschen komplizierter, dass wir uns eher auf die M-Punkt-Version konzentrieren müssen und da die ganzen Signale finden müssen. Das heißt, wir empfehlen eher nicht mit separaten mobile URLs zu arbeiten, sondern eher einfach mit einer einzigen URLs. Dann hat man diese Probleme auch weniger. Trotzdem denke ich auch mit einer normalen M-Punkt-Version, wie jetzt hier, sollte man das eigentlich auch hinkriegen können, dass die hreflang links verlinkt werden und dass die sauber anerkannt werden. Es ist natürlich immer so, dass je nachdem, wie wir solche eine Website indexieren, wenn einzelne URLs als Desktop-Version trotzdem indexiert werden, dann gibt es so diese Unterschiede. Das heißt, ein klein Teil von diesen hreflang links, die man hat, würde ich sagen, wäre einigermaßen normal, dass das trotzdem als Fehler auftritt in such konsum. Das bedeutet nicht, dass wir den Rest der hreflang links vergessen. Gerade bei hreflang ist es so, dass es ja einerseits auf Seitenebene ist und zwischen verschiedenen Sprach-Versionen. Und wenn einzelne links nicht funktionieren oder nicht sauber aufwundbar sind, dann können wir den ganzen Rest trotzdem weiterhin verwenden. Das heißt, selbst wenn ihr einzelne Fehler sieht und ihr wisst, eigentlich ist das sauber verlinkt, dann würde ich nicht gerade zu viel Schlaf verlieren. Weil das pendelt sich wahrscheinlich im Laufe der Zeit wieder ein bisschen ein und manchmal hat man ein bisschen mehr, weil das gerade mit der Indexierung ist, ein bisschen so in die Richtung geht, manchmal ein bisschen in die Richtung. Aber insgesamt, wenn man sieht, dass die Mehrheit der hreflang links sauber funktionieren, dann ist das eigentlich okay. Du hast im letzten Hangout gesagt, dass Zeitlinks erscheinen können, wenn Google versteht, zu welcher Kategorie ein Produkt gehört. Bei mir ist es aber so, dass die Tischflagge Italien zur Kategorie Tischflaggen gehört und zur Kategorie Italien. Es gibt zwei Breadcrumb-Navigationsfader. Und irgendwie ist deine Frage da abgeschnitten worden. Bist du, glaube ich, hier, oder? Ja, also soll ich nur eine Kategorie benutzen, wäre es besser, nur eine zu benutzen, um vielleicht diese Zeitlinks hinzubekommen. Also wäre es für euch sinnvoller, wenn man sagt, das gehört wirklich nur zu Italien und nicht noch diese zusätzliche Größenkategorie mit reinzunehmen? Ich vermute, das spielt keine große Rolle. Das heißt, es ist ja an und für sich normal, gerade beim Einkommersbereich, dass einzelne Produkte in unterschiedlichen Kategorien dabei sind. Und wenn das bei euch so der Fall ist, dann würde ich das einfach so lassen. Zeitlinks sind, einerseits hilft uns das natürlich, wenn wir die interne Navigation sauber erkennen können für Zeitlinks, aber das sind Sachen, die tauchen eher dann auf, wenn wir wirklich sehen, dass Benutzer gezielt nach solchen Sachen suchen. Das heißt, wenn jemand zum Beispiel nach, ich weiß nicht, eurer Website sucht und wir sehen, dass sie dann im zweiten Schritt immer nach Italienflacke auch suchen, dann könnten wir zum Beispiel für die Suchen nach eurer Website dann auch den Link zur Italienflacke zeigen als Zeitlink. Aber das sind Sachen, wo wir einerseits sehen, wie die Benutzer in der Suche reagieren, andererseits versuchen wir zu erkennen, wie das auf der Website gestaltet ist. Aber wenn man jetzt nur die Gestaltung der Website ändert, dann heißt es nicht automatisch, dass man Zeitlinks auch sehen würde in den Suchergebnissen. Okay. Meine Fragen betreffen die Werbung von Keyword Stuffing und Duplicate Content. Ein Produkt gibt es in unterschiedlichen Ausführungen und jede Ausführung bekommt eine eigene Seite. Die Texte sind jedoch recht ähnlich. Ein Zelt bleibt ein Zelt. Und gespickt mit Keywords. Die Keyword Dichte zwischen 6 und 10 Prozent. Jede Seite hat ihre Relevanz. Da konnten ja eventuell genau dieses Produkt zu Suchen. Wie kann man nachvollziehen, ob die Seite abgewertet ist wegen Keyword Stuffing und oder Duplicate Content? Und mit welchen Mitteln kann man hier Abhilfe schaffen? Ich denke, das Problem haben sehr viele e-Commerce-Sites oder zumindest die Frage. Wie weit soll man quasi Produkte auf einzelne Seiten nehmen oder wie weit soll man die zusammenfassen? Aus meiner Sicht gibt es da keine Standardantwort. Es ist auch nicht so, dass wir vom Technischen her sagen würden, man muss das so machen oder man muss das so machen. Sondern häufig ist es einfach eine Frage von einer Balance zu finden. Das heißt, wenn man einzelne Seiten gestaltet, dann stehen sie in Konkurrenz gegeneinander. Das heißt, wenn ich nach einem Produkt suche und dieses Produkt steht auf verschiedenen Seiten innerhalb meiner Webseite, dann müssen diese einzelnen Seiten miteinander konkurrenzieren und eines davon wird vielleicht gezeigt in den Suchergebnissen. Aber die müssen alle quasi für sich selber darstehen. Wenn ich hingegen verschiedene Varianten auf eine Produktseite nehme, wenn ich zum Beispiel verschiedene Farben habe oder verschiedene Größen, die vielleicht zur Second-Air-Attribut einfach die Größe haben, dann ist es so, dass wir eine einzelne Seite haben und die hat natürlich ein bisschen mehr Gewicht innerhalb eurer Webseite. Dann ist es ein bisschen einfacher für uns, die in den Rankings zu zeigen. Und da muss man halt ein bisschen die Balance finden, inwiefern es Sinn macht, dass man, sag ich mal, Sachen zusammen nimmt. Vielleicht sind Farben eine gute Möglichkeit, Sachen zusammenzupacken und auf eine einzelne Seite zu nehmen. Und wie weit man die Sachen auseinandernehmen möchte. Das heißt, wenn man sieht, dass gezielt jemand nach einer bestimmten Größe immer sucht, dann macht es vielleicht Sinn, diese Größe separat herauszunehmen. Wenn man sieht, dass die Größe eher ein sekundärer Attribut ist, das heißt, jemand sucht nach diesem Produkt oder der Produktkategorie und dann die Größe ist quasi eigentlich nicht so ausschlaggebend für die Suche, dann würde ich, dass er als Attribut auf dieser Seite nehmen, statt einer einzelnen Seite dafür zu machen. Das ist mal, denke ich mal, die allgemeine Richtung. Bezüglich Keyword-Stuffing ist es so, dass in den allermeisten Fällen ist das unproblematisch, auch bei Websites, die sehr viel ähnliche Produkte haben. Ich sehe das manchmal als etwas, was auffällt, wenn man z.B. eine Kategorien-Seite hat. Man nimmt als Alttext und als Link und als Beschreibung für jedes Produkt auf dieser Seite immer diesen gleichen Standardtext. Das heißt, wenn ich manchmal ein T-Shirt-Shop habe und das sind alles kurz-ämlige T-Shirts, dann würde vielleicht bei jedem Produkt, was auf dieser Kategorien-Seite ist, ich weiß nicht, vier, fünf, sechs Mal, die gleiche Produktbeschreibung stehen mit immer diesen Keywords, quasi kurz-ämliges T-Shirt, kurz-ämliges T-Shirt und diese Variante, kurz-ämliges T-Shirt und dieser Variante. Und wenn wir dann die Kategorien-Seite anschauen und wirklich sehen, dass da hunderte Mal diese Keywords vorkommen, dann kann es sein, dass unsere Algorithmen sagen, vielleicht ist diese Seite nicht so wahnsinnig relevant für diese Keywords, weil das sieht es aus, als ob das irgendwie unnatürlicherweise dort untergebracht ist. Wir haben kein Testing-Tool dafür. Das heißt, man sieht nicht genau, ab wann so etwas passiert. Es ist auch nicht so, dass wir da ein Grundlagen oder irgendwelche Grundangaben haben, woran man sich halten muss. Das heißt nicht, dass man irgendwie maximal so viel Prozent oder so viele Vorkommnisse von einem Keyword haben darf. Meistens sieht man das einfach indirekt, dass man merkt, dass diese Seite einfach für diese Keywords kaum noch erscheint. Und dann kann man das vielleicht ein bisschen genauer anschauen und überlegen, warum erscheint die Seite für diese Keywords nicht. Ich habe doch nur 500 Mal diese Keywords auf dieser Seite verwendet. Dann würde ich vielleicht eher in die Richtung gehen, dass man sagt, gut, vielleicht muss ich diese Keywords ein bisschen weniger häufig auf der Seite verwenden, statt dass man das noch stärker zu machen. Ich hätte dazu noch eine Frage. Natürlich, ja. Und zwar, du sagst ja auch sehr oft, dass man eine Seite so gut wie möglich, also dass das Thema einer Seite so gut wie möglich auch immer praktisch dann erscheinen soll. Jetzt ist es so, ich habe eine englische Seite und es geht um Autoflagen. Und ich sage mal für das Suchwort bei K-Flex soll auch bitte die Kategorie erscheinen. Kommt nicht, es kommt ein einzelnes Produkt. Jetzt ist es so, dass bei den Produkten noch ein Block dabei ist, der handelt über Mengenrabatte. Dort steht dann Bulk Buying. Kauf jetzt, also Order from us. Buy many and for less money, so was halt. Jetzt frage ich mich, ob vielleicht dieses einzelne Produkt durch diese Erwähnung von Bei schon wieder das Thema verfehlt. Also es kommt, man tippt ein, bei K-Flex und es kommt die Nigeria Autoflage. Und in der Meta Description steht Bulk Buying und da ist ein schöner Link und sieht alles super aus, nur ist es irgendwie der falsche Suchtreffer. Wenn ich, sollte ich da in diesem Bereich dann praktisch das Bei mit rausnehmen, das kaufen und dann nur wirklich auf der Kategorie Seite bei erwähnen? Ich denke, das würde nicht wahnsinnig viel verändern da. Normalerweise pendelt sich sowas im Laufe der Zeit wieder ein, wenn wenn die Kategorien Seite eher allgemein verlinkt ist innerhalb der Website, dann sehen wir ja, dass das irgendwie ein bisschen übergeordnet ist zu den einzelnen Länderversionen. Aber ich, was ich da jetzt nicht machen würde, ist versuchen diese einzelnen Länderversionen, sag ich mal, minderwertiger zu machen. Das heißt, da ist ja dann immer auch die Gefahr da, dass wenn ich jetzt diese Keywords von dieser Seite entferne oder wenn ich ein Canonical Set auf die Kategorien Version, das wird dann einfach gar nichts zeigen von der Website, statt diese, sag ich mal, einzelnen Produktseite. Aber auf der Kategories Seite steht kein Bei, der Titel lordet K-Flex for sale. Ja, gut, das sind so Sachen, die würden wir erkennen, als Synonym und so, dass das eigentlich das Gleiche bedeutet oder dass wenn jemand bei irgendetwas sagt, dann erkennen wir, dass diese Benutzer vielleicht nicht unbedingt diese Wörter auf der Seite sucht, sondern einfach eine E-commerce-Seite sucht, die diese Produkte auch anbietet. Okay, ja, ich probiere es gerade aus, also ich versuche gerade, aus bei rauszunähen. Also einfach statt bike-buying, habe ich dann bike-discount zum Beispiel. Okay. Vielleicht. Ja, also ich mein, ausprobieren kann man es auf jeden Fall, ich wäre einfach ein bisschen vorsichtig, wenn du das jetzt im großen Stil über die größere Website machst, wo du siehst, dass du eigentlich Benutzer kriegst für diese Suchanfragen, dass sie einfach auf der falschen Seite landen. Wenn du erkennst, dass eigentlich genug Leute kommen zur Website, dann würde ich eher versuchen, innerhalb der Website das irgendwie umzulenken. Das heißt, dass man vielleicht ein bisschen sichtbaren Kategorienbalken hat oder einen kleinen Banner oder irgendwas, einfach, dass man die Benutzer dann eher zu der Kategorienseite lenken kann, wo man denkt, dass sie eher relevant sein könnte. Okay, danke. Und da war, glaube ich, auch noch die Frage wegen duplizit Content. Das kommt ja auch relativ häufig vor bei E-commerce. Das heißt, wenn ich verschiedene Produkte habe, dann sind manchmal einfach die Produktbeschreibung sehr ähnlich unterhalb bei den verschiedenen Produkten. Das heißt, jetzt zum Beispiel bei Fahnen hat man ja vielleicht mal eine Beschreibung von dieser Fahne und dann geht es ums Material, um die Größe und solche Sachen und dann gibt es die Variante, die einzelne Ländervariante. Und diese ganzen allgemeinen Informationen sind häufig dupliziert über eine Website. Und aus unserer Sicht ist das nicht problematisch. Das heißt, es gibt ganz sicher keine Web Spam, Manual Action, also keine manuelle Maßnahme oder Penalty, das gegen solche Seiten sprechen würde. Duplizit Content ist aus unserer Sicht eher dann ein Problem, wenn eine Website wirklich komplett Inhalte von anderen Websites kopiert und die eins zu eins weiter gibt. Innerhalb von einem E-commerce-Shop ist das ja eigentlich nicht der Fall. Das heißt, man hat ja seine Produktbeschreibung, vielleicht hat man die offizielle Produktbeschreibung auch, das ist an für sich auch okay. Aber es ist nicht so, dass wir das anschauen würden und sagen würden, es macht gar keinen Sinn, diese Website zu indexieren, weil wir diese Inhalte schon irgendwo anders haben, sondern dieser E-commerce Website macht ja auch Sinn, dass wir die einzelnen indexieren und dass wir die Produkte entsprechend in der Suche zeigen würden. Und schon geht es weiter mit mehr E-Commerce. Bei einem Online-Shop-Projekt möchten wir die klassische Paginierung aufgeben und auf Infinite Scrolling umsetzen. Im Internet kursieren etliche Anleitung für die technische Umsetzung, die meine Einschätzung nach aus Bot-Crawling-Sicht nicht wirklich optimal sind. Durch den Evergreen-Bot soll der Google-Bot nun ja auch Intersection Observer unterstützen, was cool ist, kann man sich das nun banal gesagt so vorstellen, dass Google-Bot den gesamten Inhalt einer Seite crawled oder nur einen Teil und alle anderen Produkte werden gar nicht identifiziert oder bekommen kein Page-Rank. Ich denke, es ist gut, wenn man das ein bisschen kritisch angeht und nicht gerade eine größere Website umstellt auf Infinite Scrolling, weil da kann man tatsächlich auch Probleme verursachen, indem, dass wir auf einmal die nächsten Seiten nicht mehr sehen würden. Wenn es, also unsere Empfehlung bei Infinite Scrolling ist allgemein, dass man einerseits diese Funktionalität, zum Beispiel Intersection Observer verwendet, damit Google-Bot erkennen kann, dass es weitergeht, andererseits, dass man trotzdem paginierte Versionen hat, die Google-Bot direkt crawlen kann. Das heißt, wenn ihr sicherstellen wollt, dass Google-Bot, vielleicht mal die dritte oder vierte Seite crawlen kann, dann ist es am besten, wenn wir auch links zu diesen Teilen dieser Seite finden, damit wir die ganz sicher auch crawlen können. Mit dem Intersection Observer, was da grundsätzlich passiert, ist, wir laden diese Seite erst mal auf und rendern die dann auf einen sehr langen Viewport. Und dann schauen wir, wie sich das mit dem Intersection Observer da entwickelt, ob da noch mehr Inhalte nachgeladen werden, wie weit das ungefähr geht. Und das nehmen wir dann als Basis für die Indexierung. Das heißt, es ist nicht so, dass Google-Bot immer weiter und weiter scrollt und immer mehr sieht, sondern wir machen da einmal einen Snapshot mit einer gewissen Größe, schauen, was sich da noch verändert, kommt vielleicht noch ein bisschen was dazu und nehmen das dann für die Indexierung. Das heißt, wenn ihr, sage ich mal, mehrere Seiten habt, die nacheinander nachgeladen werden, dann kann es durchaus sein, dass wir die nicht alle sehen. Und deswegen ist es eben gut, wenn wir da die einzelnen Links zu den paginierten Versionen trotzdem noch haben. Bei einem eCommerce Shop ist es manchmal aber auch gar nicht so kritisch, weil oft sind Produkte in mehreren Kategorien, oft sind die Produkte untereinander auch entsprechend verlinkt, so dass wir mehrere Wege haben, die einzelnen Produktseiten zu finden. Und dementsprechend, wenn wir jetzt euch mal ab Seite 2 oder Seite 3 von einer Kategorienliste gar nicht mehr weiterkommen, weil sie mit Infinite Scrolling nicht sauber nachgeladen wurde, dann ist das vielleicht nicht kritisch für euch. Es ist ein bisschen schwierig, das allgemein zu sagen, weil jeder eCommerce Shop ist natürlich ein bisschen anders eingerichtet. Und was ich da vielleicht empfehlen würde, ist, dass man das mit eigenen Crawlers einfach mal austestet. Mal schaut, wie gut kommt ein Crawler durch, wenn gar kein Infinite Scrolling getriggert wird? Wie gut kommt ein Crawler durch, wenn, sage ich mal, einmal eine Seite nachgeladen per Infinite Scrolling getriggert wird? Einfach, dass man ungefähr weiß, wie das theoretisch aussehen könnte. Wenn Googlebot jetzt unendlich viel Zeit hätte und wirklich alle Links crawlen könnte, würde Googlebot zu allen Produkten kommen oder würde Googlebot irgendwo stehen bleiben? Und aufgrund von dem kann man dann auch ein bisschen entscheiden, ob man jetzt mehr oder weniger Querverlinkung haben möchte, ob man vielleicht Produkte eher wirklich auf verschiedenen Kategorienseiten nimmt, ob man die Größe von diesen Kategorienseiten vielleicht standardmäßig irgendwie gezielt anpasst, ob man vielleicht auch einfach mehr mit Zeichnatterteien arbeiten muss, damit man die anderen Sachen noch dazu bringen kann oder ob man die Reihenfolge auf diesen Kategorienseiten optimieren kann, so dass zumindest die Produkte, die für einen kritisch sind, dass die auf jeden Fall indexiert sind und dass die Sachen, die weniger kritisch für die Website sind, dass die vielleicht dann halt weiter hinten sind und entsprechend dann vielleicht schaffen sie es für die Indexierung, vielleicht auch nicht. Wir betreiben ein Fashion Shop auf internationaler Ebene, bei dem für jedes Land ein eigenes Domain verwendet wird. Entsprechend haben wir auf mehrere Properties in der Search Console angelegt, da unser Shop sehr umfangreich ist, sind unsere Sitemaps entsprechend in Cluster unterteilt, also Kategorien, Produkte und so weiter. Vor kurzem haben wir für weitere Seitentippen eine zusätzliche Sitemap erstellt und diese auch über Search Console eingereicht. Während auf der DE-Domain die Sitemap ohne Weiteres akzeptiert wurde, wird die entsprechende Sitemap für andere Länder mit dem Status Couldn't Fetch angezeigt. Was kann da falsch sein? Ich habe die Sitemap-Latei kurz angeschaut und habe die mal an unser Sitemaps-Team weitergegeben, damit sie das kontrollieren können. Ich vermute, dass das auf unserer Seite irgendwo da klemmt. Und von dem her ist jetzt praktisch, dass ich da ein Beispiel-Link habe. Wenn ihr weitere Links habt, die von von diesem Setup her nicht funktionieren, also Sitemaps, die nicht geladen werden können, welch froh, wenn du sie mir zuschicken könntest, dann kann ich das auch an das Team weiterleiten. Grundsätzlich ist es okay, wenn man verschiedene Sitemap-Dateien hat, ist es auch okay, wenn man verschiedene Seiten hat, die in mehreren Sitemaps dabei sind. Worauf man einfach achten müsste, ist, dass die die Angaben bei mehreren Sitemaps für die gleiche URL-Konsistenz sind. Das heißt, wenn ich als Änderungsdatum irgendein Datum habe für ein Produkt und das in einer Sitemap-Datei so drin habe, dann sollte das gleiche Datum auch bei den anderen Sitemaps-Dateien dabei sein. Nicht, dass da irgendwie das Ganze ein bisschen vermischt ist, dass wir nicht genau wissen, welches Änderungsdatum jetzt gilt. Und gerade bei Sitemaps ist ja auch das Änderungsdatum eigentlich eines von den wichtigsten Informationen dort. Das heißt, über die URL und Änderungsdatum können wir einigermaßen planen, was wir als nächstes crawlen sollten. Das sehen wir ja dann relativ schnell, ob wir seit diesem Änderungsdatum die Seite schon mal angeschaut haben. Und wenn nicht, dann ist es für uns schon ein Signal, dass wir diese URL möglichst bald crawlen sollten. Die anderen Informationen in der Sitemap-Datei, also Priorität und Änderungsfrequenz, die verwenden wir nicht. In den Quality-Rator-Guidelines wurden neu, also die Quality-Rator-Guidelines wurden neulich erst geändert. Dabei sind News und Ereignisse weiter oben in den Fokus gerückt. In Kontext user-generated Content wird gerade bei jüngsten Ereignissen viel spekuliert, fantasiert und diskutiert. Inwieweit erwartet ihr, dass wir als Betreiber diese user-generated Content bereits sensorialen Kontext, zum Beispiel Fake News. Das ist eine gute Frage. Weil ich weiß nicht auf Hannhieb, wie wir das am besten angehen würden. Im Grunde genommen sind die Quality-Rator-Guidelines ist ja nicht irgendwie der Source-Code von unseren Algorithmen. Das heißt, das wird nicht eins zu eins so umgesetzt, sondern das hilft uns, wenn wir verschiedene algoritmische Veränderungen machen, festzustellen, in welche Richtung wir, sag ich mal, richtig gehen, in welche Richtung wir weniger richtig sind oder wo die Ergebnisse weniger relevant sind. Die Quality-Rator-Guidelines sind inzwischen recht umfangreich. Es sind viele, sag ich mal, Unterthemen, die alle dabei sind, weil es verändert sich ja auch relativ viel auf dem Web. Und unter Umständen sind diejenigen, die diese Quality-Ratings machen, nicht unbedingt diejenigen, die zum Beispiel jetzt in Deutschland vorhanden sind, vor Ort sind oder die in Amerika vor Ort sind. Und die kennen dann vielleicht die lokalen Gegebenheiten, nicht so wahnsinnig gut. Und deswegen sind da einfach sehr viel umfangreicher Information in diesen Guidelines dabei. Inwieweit man das eins zu eins umsetzen würde, ich denke, insgesamt würde ich diese Quality-Rator-Guidelines eher so auch als Richtlinien vielleicht ein bisschen anschauen und überlegen, wie kann man sicherstellen, dass die eigenen Website-Inhalte, die man zur Verfügung stellt, auch relevant sind. Und dementsprechend auch, sag ich mal, die diesen Grundsätzen, die dort dargestellt werden, dass man denen auch gerecht werden kann. Und gerade bei gewissen Arten von Inhalten macht es natürlich ein bisschen mehr Sinn oder ein bisschen weniger Sinn. Bei, sag ich mal, bei User-Generated Content ist es natürlich immer so, dass da alles Mögliche zusammenkommen. Ich denke, wichtig ist einfach, dass man sich bewusst ist, dass User-Generated Content nicht bedeutet, dass ihr für diese Inhalte in der Suche nicht quasi darstehen müsst, sondern ihr veröffentlicht ja diese Inhalte. Und wenn das Inhalte sind, die ihr denkt, sind nicht wahnsinnig gut, dann würde ich mir überlegen, ob man die wirklich so veröffentlicht will auf der eigenen Website. Das heißt, also was auf unserer Seite einfach passiert ist, wir indexieren die Inhalte, wie ihr sie zur Verfügung stellt. Und da denken wir, dass das ist, was, wofür ihr darstehen wollt in den Suchergebnissen. Und wenn man zum Beispiel User-Generated Content hat und User-Generated Content ist von einer hohen Qualität oder besonders interessant, dann finde ich das eine tolle Sache. Wenn das hingegen User-Generated Content ist der mehrheitlich Spam ist oder wo die Inhalte eigentlich nicht so wahnsinnig wertvoll sind, dann sind das vielleicht nicht Inhalte, die man unbedingt direkt veröffentlicht will auf der eigenen Website. Inwieweit ihr das quasi lenken wollt, ist natürlich euch überlassen. Ihr könnt entscheiden, was ihr veröffentlichen wollt auf eurer Website und wie ihr indexiert werden wollt. Und dementsprechend ist es nicht so, dass wir vorschreiben, was ihr machen müsst, sondern ihr müsst einfach selber entscheiden, was wollt ihr indexiert haben, wo kommen die Inhalte her, was muss ich vielleicht machen, um sicherzustellen, dass das wirklich Inhalte sind, die zu dem passen, wofür ich stehe mit meiner Website. Und manchmal heißt es, dass man da vielleicht mit Moderation ein bisschen besser arbeiten muss. Manchmal bedeutet das auch, dass man einfach von einfach eigene Qualitätssignale suchen muss, wie man sicherstellen kann, dass das wirklich auch Inhalte sind, die man so vertreten will. Was man auch machen kann, gerade bei User-Generated Content, bei Websites, die viel User-Generated Content haben, dass man zum Beispiel mit No-Index auch arbeitet. Das heißt, ihr müsst ja die Inhalte, sagen wir nicht direkt löschen, wenn ihr nicht sicher seid, ob das gute Inhalte sind, sondern ihr könntet die zum Beispiel auf No-Index setzen. Und wenn ihr es sieht, im Laufe der Zeit, dass diese Signale zusammenpassen, wenn ihr zum Beispiel, ich weiß nicht, Kommentare habt, weitere noch dazu schreiben, oder wenn ihr es sieht, dass bestehende Benutzer, die diese Inhalte entsprechend befürworten, dann kann man das ja auch automatisch dann umsetzen und sagen, das geht jetzt von No-Index auf indexierbar, und das ist jetzt für uns so weit okay. Aber grundsätzlich ist es euch überlassen, wie ihr das machen wollt. Beim Crawling kann der Googlebot an unterschiedlichen Stellen URLs ermitteln, die Ajax JavaScript Request URLs sind. Zum Teil sind es nicht nur Content-Fragmente, sondern funktionelle Aspekte. Diese URLs sind via HTTP erreichbar. Ein HTML-Header-Steuerung ist zum Teil nicht möglich. Wie sollen Webseitenbetreiber die URLs einstellen, damit es nicht zu Indexierungen oder Crawling-Problemen kommt? Grundsätzlich ausschließen per Robots Text oder Search Console, ist ein HTTP Canonical auf die eigentliche Seite eine Option. Da kommen verschiedene Varianten zusammen. Grundsätzlich ist es so, dass wir wahrscheinlich diese URLs für die eigene Indexierung nicht finden würden. Das heißt, was passiert, ist wir laden die normale HTML-Seite auf, und wenn der JavaScript auf diese Seite ist, dann führen wir diesen JavaScript aus beim Rendering. Wenn wir einzelne Ressourcen vom Server holen müssen für das Rendering, dann brauchen wir die für das Rendering. Das bedeutet aber nicht, dass diese Resource-Urall separat für die Indexierung auch verwendet werden. Das heißt, wenn ich eine JavaScript-Datei habe und die ist eingebunden in meiner normalen HTML-Seite, dann heißt es nicht, dass ich diese JavaScript-Urall separat als Text-Datei zum Beispiel indexieren würde, sondern wir machen das eigentlich nur, wenn wir normale HTML-Links finden auf diese anderen Inhalte. Das heißt, wahrscheinlich sieht ja in den Server-Logs, dass wir auf diese Dateien zugreifen, weil wir müssen das ja machen, wenn das beim Rendering notwendig ist. Aber das heißt nicht, dass wir die für die Indexierung verwenden würden. Das heißt, wir indexieren die nicht selbstständig. Was man machen kann, wenn man das Gefühl hat, dass das nicht sauber funktioniert, einerseits die eigene Webseite mal crawlen und schauen, ob man nicht vielleicht doch irgendwo links, HTML-Links zu diesen Dateien hat, zu diesen URLs, weil normalerweise würden wir die nicht einfach aufrufen für die eigene Indexierung. Eine andere Sache, wenn man das einfach nur beheben will und nicht herausfinden kann, woher er das kommt, kann man mit dem X-Robots tag arbeiten. Das ist ein HTTP-Header, den kann man bei jeder Art von Datei entsprechend angeben. Und da kann man zum Beispiel sagen, Noindex. Und dann, wenn wir diese Datei separat für die Indexierung aufrufen würden, dann sehen wir nicht, das ist eine JavaScript-Datei, sondern wir sehen auch sofort, die sollte nicht separat indexierbar sein. Man kann auch ein Canonical angeben per HTTP-Header. Ich denke, das bringt in den meisten Fällen nicht so wahnsinnig viel, weil wenn man eine JavaScript-Datei hat, dann ist ja eigentlich nicht klar, was die Canonical-Version von dieser JavaScript-Datei sein sollte. Von dem her würde ich da eher einfach Noindex bei diesen JavaScript-Dateien zum Beispiel verwenden, wenn man sieht, dass sie separat indexiert werden. Ich vermute allerdings, dass in den meisten Fällen sieht man diese URLs einfach in den Server-Logs, aber sie werden nie separat indexiert. Wir haben 10.000 paginierte Seiten bei... Johannes, verzeih mir, dass ich unterbreche. Ich habe eine Rückfrage zu der Frage, die ich von mir eingerichtet. Das bedeutet, dass... Also die im Moment sind die Dateien nicht im Index, also die JavaScript, also die JS URLs. Aber sie sind in der Konsole, ist das Crawling ausgesperrt. Und das würde ich gerne sozusagen entfernen und das Crawling erlauben, weil immerhin beschwert sich auch der Bot, dass er zum Teil Ressourcen nicht crawlen kann. Mein Verdacht war halt mit der Angst der Indexierung, dass es deshalb zu einer Indexierung kommt. Würde es, wenn ich per HTTP ein Noindex implementiere, würde das nicht dazu führen, dass die bei den Content-Fragmenten das zu Problemen führt, dass die eigentliche Seite, die diese Fragmente beinhaltet, plötzlich nicht vollständig indiziert wird, das wird dann nicht passieren. Nein, nein. Der Noindex bezieht sich wirklich nur auf diese URL, wenn diese URL aufgerufen wird. Das heißt, wenn wir diese URL für die Indexierung verwenden würden und das Noindex sehen, dann bezieht sich auf diese URL. Wenn diese URL als Teil eingebunden ist einer anderen Seite, dann wird das dann nicht betroffen. Ah, super. Ich verstehe. Ja, super. Herzlichen Dank. Super. Okay, wir haben schon nur noch ein paar Minuten übrig. Wechseln wir vielleicht zu Euren Fragen, wenn es dann noch weitere Sachen auf Eurer Seite geht. Eine Sache aus Rainer Neugierig vielleicht. Okay. Ich habe festgestellt, ihr habt ein bisschen rumexperimentiert mit den Darstellungen in den Serbs, gerade auch übers Wochenende. Da wurden dann Eikens, also Fabrikons, wurden angezeigt, der Titel rutschte unter eine URL beziehungsweise eine Breadcrumb. Das ist offensichtlich wieder zurückgerollt. Gibt es da irgendwelche Erkenntnisse, geht es weiter? Wollt ihr in die Richtung gehen? Sag doch mal was dazu. Es ist schwierig zu sagen, wie das weitergeht, weil wir machen ja eigentlich immer wieder solche Experimente und manche funktionieren gut, manche funktionieren weniger gut. Aber es ist eigentlich selten so, dass wir sagen würden, wir wollen das jetzt so machen und versuchen das mal und dann machen wir es trotzdem auch, wenn es schlecht rauskommt. Das heißt, wir machen einfach da wie andere, ständig A-B-Tests, zum Schauen, wie funktioniert das besser, wie funktioniert das weniger gut. Gerade mit den Titels in den Suche, nein, wie war das, mit den Website-Titels habe ich eigentlich relativ viel Feedback gekriegt, gerade von SEOs, dass sie das nicht so wahnsinnig scholl finden, dass sie lieber die URLs in den Suche-Ergebnissen haben. Es sieht an und für sich ähnlich aus wie die mobilen Suche-Ergebnisse, von dem her kann ich mir vorstellen, dass das Team einfach gemeint hat, gut, wir machen das konsistent, ähnlich wie das im Mobile-Bereich ist, aber anscheinend gerade bei Desktop verwenden viele trotzdem irgendwie noch Control-F, um Websites zu suchen innerhalb den Suche-Ergebnissen. Inwieweit das bleibt oder weiter ausgebaut wird, ich denke, das hängt immer von den Ergebnissen dort ab. Den Feedback, den wir kriegen zum Beispiel auf Twitter, das geben wir natürlich weiter an das Team, aber oft ist es natürlich so, dass gerade die SEOs machen natürlich einen sehr kleinen Anteil von den Gesamtbenutzern aus. Und nur weil den SEOs etwas nicht gefällt, heißt nicht, dass es den normalen Benutzer nicht gefällt. Manchmal ist es auch umgekehrt, dass eine Änderung den SEOs besonders gefällt und dann die normalen Benutzer sind da ein bisschen verwirrt. Aber das sind sicher alle Sachen, die wir da an das Team entsprechend weitergeben. Wie hast du das gefunden mit der URL oben unten und mit dem Symbol? Also ich fand es anders erst mal, ja, war okay, klar habe ich die Parallelität zum Mobile entdeckt. Klar, gedacht, aber trotzdem ist da auch noch wieder ein Unterschied. Ich glaube, im Mobile hatte der Breadcrumb und Desktop-Barns URL, die dann angezeigt wurden oder andersrum, irgendwie so ein ganz kleiner Unterschied war. Für meinen Geschmack ein bisschen viel clicky-bunty, aber eigentlich auch irgendwie frisch. Also ich hatte jetzt kein Problem damit. Okay. Ja, ich weiß nicht in welche Richtung die da weitergehen. Ich finde es toll, dass sie da immer wieder Experimente machen und dann ist das ein bisschen verwirrend natürlich, wenn man das so eins zu eins weiterverfolgt. Aber ich denke, in großen Ganzen muss man einfach immer wieder Sachen neu ausprobieren. Und manchmal sind die Sachen, die wir vor einem Jahr ausprobiert haben, nicht geklappt haben, auf einmal doch brauchbar. Okay, Zeit für eine letzte Frage haben wir noch. Wenn jemand noch was hat. Nicht? Okay. Dann gucke ich mal kurz hier an. Ich glaube, die anderen Fragen sind alle ein bisschen lang. Und bei Johannes, wenn du erlaubst, eine hätte ich noch. Okay, lege kurz. Es ist wieder die selbe Thematik, Ressourcen. Wie sieht das mit PAP-Dateien aus? Etwa bei der Suche. Die Suche wird ja dann funktionell eingebunden und ist jetzt nicht unbedingt die als Ressource anzusehen. Oder seht ihr das? Ja, wenn verstehst du, was ich damit zu ausdrücken möchte? Nein, nicht ganz. Wie meinst du das? Ja, nehmen wir mal zum Beispiel Elastik ist so ein typisches Beispiel, wo dann die Suchmaschine durchaus direkt angesprochen werden kann. Also irgendeine Domain und dann sehr oft elastik.php, die dann im normalen Code auch an irgendeiner Stelle eingebunden ist, weil sie funktionell etwas ausführen muss, damit es dargestellt wird am Dokument. Aber die eigentliche URL ist dann irgendeine. So, diese PAP-Datei kann natürlich direkt angesprochen werden, aber ist nicht unbedingt als eine Ressource eingebunden. Ja, das würden wir wahrscheinlich gar nicht merken. Das heißt, wenn das sauber implementiert ist, sodass die PHP-Datei, sage ich mir, nur im Source Code verknüpft ist, dann würden wir die gar nicht erst finden. Kann man davon ausgehen, dass ... Nee, kann man nicht. Nee, ich habe mir sie gerade selber beantwortet. Okay, danke schön. Cool. Okay, dann machen wir vielleicht eine Pause hier. Vielen Dank für die vielen Fragen und die angereicht worden sind. Alle haben wir nicht durchgehen können. Ich richte noch die nächsten Hangouts ein. Ihr könnt gerne die Fragen weiter tragen fürs nächste Mal. Dann schauen wir sie damit entsprechend auch an. Okay, dann wünsche ich euch noch allen einen schönen Nachmittag und bis zum nächsten Mal. Tschüss allerseits. Tschüss.