 eine Frage. Ich hätte direkt mal eine und zwei. Okay. Ich habe jetzt gerade mal bei uns in die Lockpfeilzen geguckt vor einiger Zeit und es ist so häufig sehen wir das der Google Crawler, dass wir hinten gekropte URLs haben. Das heißt, also das heißt, wie das letzte Buchstabe fehlt und eigentlich so wie ich es weiß, erwartet ihr, dass ein 404 wieder kommt, was ja auch recht normal wäre. Bei einigen URLs haben wir Filter URLs und weil es manchmal sein kann, dass Partner oder Nutzer der Seite den Filter handisch ändern, werden diese Filter redirected, dreimal als redirected auch praktisch auf die Haupturl. Ist das soweit okay oder sollte man da sicher gehen, dass es dann 404 ist bei sowas? Das sollte eigentlich kein Problem sein. Weil wir haben sehr viele. Also das Anteil ist es wirklich sehr, sehr viel. Ich würde mir wegen der Menge eigentlich keine großen Gedanken machen. Wenn du es sicher bist, dass die URLs eigentlich zu einer anderen gehören, dann ist ein redirect da das Richtige. Dann würde ich das einfach so machen. Okay. Ja, gut zu wissen. Danke schön. Ja, bitte. Okay. Vielleicht irgendwelche weiteren Fragen gerade am Anfang? Nicht spezielles. Okay. Sonst fange ich mal an mit den Fragen, die eingereicht worden sind. Und wenn ihr zwischen euch Kommentare oder weitere Fragen dazu habt, einfach nur losrufen. Okay. Da haben wir eine lange Frage zu Duplicate Content. So wie ich das verstehe, ist es ein Reisebuchungsportal, wo Informationsinhalte zusätzlich quasi auf den Produkte-Seiten noch aufgeführt werden. Und man hat ein bisschen das Gefühl, dass das Duplicate Content eingestuft wird, weil das sind ja dann immer die gleichen Informationsinhalte, die auf verschiedenen Produkte-Seiten wiederholt werden. Aus meiner Sicht sollte das eigentlich total unproblematisch sein. Das heißt, wenn die Inhalte wirklich auf verschiedenen Seiten sind, ändert das eigentlich nichts für uns, weil wir sehen die gleichen Inhalte auf den verschiedenen Seiten und merken aber trotzdem, dass es da vielleicht eine Seite gibt, die als Hauptseite für dieses Thema gilt. Und dann versuchen wir die zu zeigen. Und wenn die anderen Seiten indexiert werden, dann ist das soweit eigentlich auch okay. Dann ist es nicht so, dass wir da irgendwie das als minderwertige Inhalte anschauen würden, nur weil Teile der Inhalte dupliziert sind. Also ist es nicht so, dass man da irgendwelche Tricks reinmachen muss, um diese Kopien quasi zu unterdrücken, sondern man kann die euch aus dem Benutzer ganz normal zeigen. Entweder direkt laden auf der Seite, man kann die auch per JavaScript nachladen, wenn das ein bisschen schneller lädt zum Beispiel. Aber im Grunde genommen spricht da nichts den entgegen, dass man die Inhalte einfach auf den Seiten aufhört. Hallo John, kurz Frage dazu. Was würde denn noch als Duplicate-Content gelten, der negativ ist, wenn Google das mittlerweile alles selber erkennen kann? Ja, das was für uns problematisch ist, ist er, wenn man wirklich Inhalte von anderen Websites einfach zusammenkopiert und auf die eigenen Webseiten hängt. Also quasi Gascrapher-Content, Content, der durch ein Spinner geht, der automatisch quasi umgeschrieben wird. Solche Sachen sind dann für uns problematisch, weil das als Website einfach irgendwie aufträgt. Aber Inhalte, die, sag ich mal, aus technischen Gründen oder aus usability Gründen wiederholt werden, das ist aus unserer Sicht kein Problem. Wir können das erkennen, wir können damit eigentlich relativ gut umgehen. Okay, dann Duplicate-Content-Fragen kommen eigentlich fast immer. Also ihr könnt ruhig weiterfragen, wenn da irgendwie ein Teilbereich nicht ganz klar ist, macht nichts. Ich habe zwei Fragen zur AMP. Erstens gibt es Beschränkungen, wie viele AMP-Seiten man in einer bestimmten Zeit an einen Index schicken kann? Nein, gibt es da nicht. Zweitens, unter welcher URL laufen die Seitenaufrufe in Google Analytics Frontend ein? Das weiß ich jetzt nicht auswendig, wie das bei Google Analytics aufgeführt wird. Ich vermute entweder ist es über die Canonical URL die Angegebenheit auf der Seite oder über die AMP-URL, über die ihr quasi die AMP-Seiten ausliefert. Sollte eigentlich nicht zum Beispiel die AMP-Cache URL sein, weil das ist ja eher eine künstliche URL. Aber wenn ihr da nicht ganz sicher seid, würde ich vielleicht beim Analytics-Forum nachfragen. Man kann ja auch verschiedene Arten von Analytics einbinden, dass ihr da vielleicht genau schaut bei dieser Art von Analytics, die ihr verwendet, welche URL wird effektiv weitergegeben, damit man das ein bisschen genauer anschauen kann. Wir haben einen URL-Change vollzogen und eine kleine Änderung in der Artenweise, wie die URLs funktionieren, gemacht. Man schaut, das ist ja ein bisschen kompliziert, mit verschiedenen Arten von URLs und ein Canonical. Also die Frage ist von mir, wenn das noch nachfragen wirklich kann. Ich erkläre es vielleicht mal kurz. Ja, das Problem ist, wir haben ein Verzeichnis gehabt, das hatte waren zwei Buchstaben, das hat sich geändert, weil es von der Struktur anders gemacht wird. Das haben wir geändert, das war eigentlich alles soweit auch kein Problem. Aber wie es auch häufig ist, dann wird es einfach dann in dieser Veränderung noch ein paar andere Sachen auch noch mitgemacht. Was jetzt passiert ist, ist, dass als Mehrwert für den Kunden der Reisendaten zum Beispiel Einträg oder Filter-Einträg, werden diese im LocalStorage gespeichert, aber kommen auch oben in die URL. Wenn ich also selber mir einen Reiseangebuch zusammenklicke, habe ich oben in der URL mein Departure Date, mein Return Date und so alles mit drinstehen. Und das wird oben in die URL gepusht, wenn ich das anklämpchen Filter auswähle, damit ich zum Beispiel auch Freunden das schicken könnte. Das ist die Idee dahinter. Es wird aber auch im LocalStorage gespeichert und dadurch wird es überschrieben. Jetzt habe ich ein bisschen, dass, ich persönlich habe dir Bedenken, dass wenn ich jetzt, all diese Filterkombinationen haben immer Canonical auf die ursprüngliche Seite eigentlich, weil es sind immer nur Variationen von meinetwegen eine Majorca Seite. Jetzt habe ich aber ein Canonical, zeigt auf diese Majorca Seite. Diese Majorca Seite kann ich aber gar nicht mehr richtig aufrufen. Also ich kann sie aufrufen, wenn ich im LocalStorage aber andere Daten habe, werden die oben in die URL gepusht. Das heißt, wenn ich jetzt, wenn der Crawler den LocalStorage benutzt, da irgendwelche Daten eingesammelt worden sind, dann wird die URL sich oben immer wieder ändern. Und ich persönlich habe da so ein bisschen Bauchschmerzen damit, weil es ein bisschen ja nicht ganz fehlerfrei sicherlich sein könnte. Das ist das Problem. Ja, also fehlerfrei ist wahrscheinlich ein anderes Thema. Aber grundsätzlich ist es so, dass Googlebot verwendet, an und für sich kein LocalStorage zwischen den einzelnen Crawls. Das heißt, jeder Aufruf, der gemacht wird, ist effektiv wie ein neuer Session. Sind keine Informationen von vorherigen Crawls dabei. Das heißt, wenn wir eine Seite aufrufen, ist da irgendwie kein Session Cookie dabei, kein LocalStorage-Information. Eigentlich all das wird gar nicht weitergegeben. Das heißt, Googlebot sieht wahrscheinlich einfach immer die Standard-Version. Und ich denke, in diesem Fall ist das sicher okay. Was man machen kann, ist natürlich quasi als Art Personalisierung, dass wenn jemand schon da war, dass die Inhalte leicht angepasst werden. Ich denke, so wie ihr das macht, sollte es eigentlich okay sein. Wenn der normale Durchschnitts-Benutzer auf die Suchergebnisse klickt, dann sieht der Benutzer ja die Standardseite wieder, weil da noch nichts eingestellt worden ist mit Filter. Dann ist das eigentlich auch okay. Und somit sollte das eigentlich unproblematisch sein. Wir haben jetzt, also klar, es ist ein bisschen die Federsuche, weil wir haben gesehen, dass wir, wir haben, also wir sind dachweit aktiv und wir haben jetzt vor allen Dingen im österreichischen und Schweizer Markt gesehen, dass die Rankings wirklich massiv eingebrochen sind. Und es ist jetzt schon zwei Wochen her. Also so langsam sollte sich eine Erholung einstellen, passiert aber nicht in dem Ausmaß. Was wir nur gesehen haben, ist, dass der Anteil, also in den Logfiles kann man sehen, dass der Anteil des Crawlings, der diese Filter aufruft, massiv nach oben gegangen ist. Während ich jetzt sage ich mal die URL ohne Filter, wird in einem ähnlichen Ausmaß ein ähnlicher Menge gecrawt, aber diese Filter-Variationen davon werden extrem viel gecrawt. Jetzt habe ich natürlich das Bedenken. Einmal habe ich einen Filter, der dann eventuell redirected wird. Auf eine Seite, die dann wieder einen Filter drin hat und auf dieser Seite ist ein Canonical, auf einer klinischen URL, wo eventuell mit dem Logo Storage wieder eine andere URL dazukommt. Also da habe ich ein bisschen bedenken, dass das Crawl-Budget nicht ganz optimal genutzt wird. Ja, das ist vielleicht eine Sache, die man anschauen könnte, um da vielleicht ein bisschen zu optimieren. Also ich vermute, wegen den Rankings hat das keinen großen Einfluss, aber bezüglich gerade vom Crawling her, wenn natürlich die ganze Crawling-Aktivität sich auf diese Filter-Varianten beschränkt, dann bringt das euch nicht so wahnsinnig viel, weil dann können wir die normalen Seiten nicht so schnell crawlen. Was man da machen könnte, sind an und für sich zwei grundlegende Sachen. Einerseits, dass man mit der URL-Parameter arbeitet, statt alles im Fahrt reinzunehmen. Ich weiß nicht genau bei der Frage, ob das vielleicht eine Variante ist, dass man quasi eine Haupt-Url hat und dann mit Parameter diese Varianten vielleicht zusammenbaut. Und dann kann man mit dem Parameter-Handling-Tool in Search Console angeben, diese Parameters sind irrelevant. Und somit können wir vom Crawling her das schon ein bisschen einschränken. Eine andere Variante, wenn das wirklich jetzt ein kritisches Problem ist, ist, dass man per Robots Text vielleicht diese Filter-Varianten blockiert. Ich denke, das wäre eine Option. Das haben wir jetzt mal angedacht, weil das von dem Aufwand hier, das zu implementieren, natürlich sehr gering ist, auf unserer Seite aus. Okay, mit den Parametern ist es ein bisschen schwierig, weil die auch die Art und Weise, wie die Parameter genutzt werden, worden ist. Von daher ist es, ja. Ich denke mit Parametern wären es am optimalsten, weil das ist etwas, was die verschiedenen Suchmaschinen ein bisschen schneller lernen können, als wenn das im Fahrt drin ist. Gerade wenn da so eine Art Session-ID mitten im Fahrt dabei ist, dann ist das schwierig zu erkennen, ah, diese Fahrt-Element ist an und für sich irrelevant. Kann man weglassen, hingegen, wenn das Parameter sind, kann man das relativ schnell lernen, sagen, ah, dieser Session-ID-Parameter. Also vorher war es so, dass wir die Parameter vielleicht mal im Fragezeichen hatten und da hat der Parameter angefangen. Im Moment ist es im Endeffekt immer noch ein Parameter, aber es ist halt URL-Struktur. Genau. Das heißt, von der Funktionsweise ist schwierig zu erkennen. Okay. Ja, das ist ein bisschen das Problem. Von dem her, wenn es jetzt wirklich ein kritisches Problem ist, würde ich vielleicht mit Robots Text anfangen und dann einfach längerfristig würde ich mir überlegen, wie könnte man vielleicht auf Parameter umstellen, damit man das ein bisschen genauer auch steuern kann. Okay, alles klar. Super, danke schön. Super. Ist es aus Sicht von Google ein Nachteil, wenn das URL-Routing client-zeitig macht? Ich vermute, das ist ähnlich wie, sag ich mal, wenn jetzt ein Single-Page-App, wenn man im Browser quasi die Seiten zusammenstellt beziehungsweise, wenn man dann mit einer HTML-Seite arbeitet, aber dann je nachdem, wie die URL zusammengestellt wird, die Inhalte über den Server quasi per JavaScript holt. Aus unserer Sicht kann man das durchaus machen. Wichtig ist da einfach, dass man wirklich auch klare, saubere URLs verwendet, entweder mit Parameter oder dass das im Fahrt drin ist, damit wir auch wirklich erkennen können, dass da unterschiedliche Inhalte vorhanden sind. Nicht, dass man zum Beispiel mit dem Fragment arbeitet, also mit diesem Nomenzeichen in der URL, weil diese URLs lassen wir in der Regel weg, auch beim Indexieren. Ich würde auf jeden Fall das auch mit Search Console, Fetch and Render kontrollieren, damit ihr sicher seid, dass diese Seiten wirklich sauber aufgeladen werden können, dass da nicht irgendwie ein JavaScript-Fehler dabei sind, die man vielleicht noch irgendwie beheben muss, damit die Seite wirklich sauber für Googlebot auch lädt. Google crawlt Tonnen an Artikelbildern auf unsere Seiten. Der Traffic auf diesen Seitenbildern geht gegen Null. Da ich mein Crowd-Budget-Problem zu kämpfen habe, überlege ich diese Pfade für Googlebot, Google Image-Bud zu blockieren. Ja, kann man durchaus machen. Wenn man wirklich will, dass diese Bilder nicht in der Bildersuche erscheinen und wenn das Crawling problematisch ist, kann man sie durchaus so blockieren. Es kann allerdings sein, dass die Bilder trotzdem gecrawlt werden, einfach mit dem normalen Googlebot, während wir zum Beispiel die Seiten einzeln renderen. Das heißt, wir crawlen die Bilder dann nicht in Hinsicht auf Image-Search, sondern eher um diese Seiten aufzubauen. Wenn das auch ein Problem ist, dann würde ich einfach allgemein Googlebot blockieren per Robots Text, dann sind all diese Googlebot-Varianten auch entsprechend blockiert. Eine andere Variante wäre vielleicht, dass man mit Caching-Parametern arbeitet oder die Bilder auf ein CDN auslagert, so dass der Traffic auf diese Bilderdateien nicht so problematisch ist. Wir haben Ende 2015 einen neuen Online-Shop gelauncht. Alles ging prima bis Anfang dieses Jahres und da ist alles zusammengebrochen und Nutzer sind fast gleich Null. Was haben wir falsch gemacht? Was könnte da passiert sein? Schwierig zu sagen, da müsste ich wahrscheinlich die Website mal genauer anschauen. Was ich da vorschlagen würde, ist man vielleicht ein Thread im Hilfeforum aufmacht und wenn du willst, kannst du mir den Link zum Thread schicken, dann kann ich da mal hinschauen und schauen, ob da die relevanten Sachen auch angeschaut werden und dann vielleicht noch ein paar Kommentare dazu liefern. Viele offizielle Seiten haben ein Social Media Account, der vielfach statisch oder wenig unterhalten wird, werden diese Beiträge gecrawlt wie bei einem Blog oder verzichtet Google auf diesen Content. Wir crawlen an und für sich Social Media Seiten, wenn sie öffentlich sind, wie jede andere Website. Das heißt, wir können sie unter Umständen in den Suchergebnissen zeigen. Unter Umständen sind die verknüpft mit den Suchergebnissen, wenn man quasi mit dem entsprechenden Markup, die verbindet. Wir behandeln die eigentlich nicht irgendwie speziell und sagen, dass da es jetzt ein Twitter-Konto, deswegen müssen wir dementsprechend mehr Wert geben, sondern dass es einfach eine Seite, die verknüpft ist mit eurer Website und das ist an für sie okay. Was genau macht die Abruf, wie durch Google Funktion, also das ist in Search Console, eine Möglichkeit, wie man an und für sich Googlebot direkt ansteuern kann. Das heißt, wenn ihr wissen wollt, wie Googlebot eine Seite anschaut, entweder als HTML-Version mit dem entsprechenden header oder als gerenderte Version quasi mit dem ganzen JavaScript und CSS ausgeführt, kann man das mit dem machen. Das ist ein guter Test gerade für Seiten, die sehr dynamisch sind, die viele Inhalte für JavaScript einholen. Um zu kontrollieren, werden diese Seiten wirklich sauber aufgebaut oder kann Googlebot vielleicht nicht die Inhalte voll anschauen. Einige Fragen zu hreflang. Sollten hreflang Attribute auf der mobilen Seite eingebunden werden? Ja, bisher haben wir immer gesagt, hreflang ist aus unserer Sicht vor allem wichtig auf den Canonical Seiten. Jetzt im Hinblick auf den Mobile First Index ändert das ein bisschen, indem das wir natürlich die mobile Seite als die Hauptseite anschauen. Deswegen macht es auch Sinn, dort den hreflang Tag anzugeben. Wir empfehlen im Moment den normalen Desktop Link auf der mobilen Seite für den hreflang anzugeben. Das heißt, die gleichen Markup wie auf den Desktop Seiten habt, könnt ihr eins zu eins auf die mobile Version weiter kopieren und dann können wir das so verarbeiten. Wir haben noch nicht alle Desktop Domains, eine entsprechende mobile Seite. Wie kann man das da verbinden? Da kann man natürlich auch direkt mit der Desktop URL arbeiten beim hreflang. Ist es absehbar, ob es bald eine Testumgebung für hreflang Attribute geben wird? Im Moment ist dann nichts Spezielles geplant. Ich bin aber am diskutieren mit dem Team, ob man da vielleicht etwas machen könnte, weil solche Fragen kommen immer wieder und wenn man warten muss, bis wirklich alles indexiert ist, dann geht das manchmal sehr lange, bis man überhaupt merkt, dass man irgendwas falsch gemacht hat mit der hreflang Einrichtung. Es gibt glaube ich auch andere Tools, die den hreflang Markup kontrollieren. Also ich würde da vielleicht auch mal ein bisschen rumschauen. Es gibt noch noch ganz geschickte Sachen. Noch eine Frage zum hreflang. Wohin sollen die hreflang zeigen, wenn die Seite per canonical zu einer anderen Seite verweist oder sollte dann kein hreflang ausgespielt werden? Grundsätzlich sollte der hreflang Markup zwischen den canonical Version entsprechend sein. Das heißt, wenn ihr, also es sollte auf jeden Fall zur canonical Version von der anderen Sprache entsprechend zeigen und von dieser Version dann zurück auf die canonical Version für die Ursprungssprache. Ihr könnt aber durchaus den hreflang auch auf nicht canonical Seiten nehmen. Das heißt, wenn ihr zum Beispiel eine URL mit Parameter habt und dort ein hreflang auf die saubere URL nehmt, dann ist es aus unserer Sicht okay. In der Regel ändert das nicht viel, weil ihr habt ihr dann mit dem canonical schon angegeben, dass eigentlich ist die andere Seite der canonical für diese Version und dann konzentrieren wir uns eher auf die canonical Version, aber es schadet auch nicht. Das heißt, wenn ihr aus praktischen Gründen, sag ich mal, das nicht irgendwie separat steuern könnt, dann ist das an und für sich kein Problem. Noch mal hreflang tags. Angenommen, ich verwende momentan country code tuppable domains für die Länderwebseiten, also Produktname.de, pump it und so weiter. Gegen Ende vom dritten Quartal plane ich, diese auf ein Unterverzeichnisse zu migrieren, also punkarmstrich.de. Kann ich schon jetzt die hreflang tags, der neuen Struktur verwenden, wenn ich das Unterverzeichnis weiter leite, um mir eine doppelte Implementierung zu sparen. Wahrscheinlich werden wir das nicht so verwenden. Das heißt, wir erwarten, dass der hreflang tag zwischen den canonical Versionen ist. Das heißt, wenn ihr mit dem hreflang tag auf eine URL verweist, die per redirect auf eine andere verweist, dann ist es möglich, dass wir den redirect ziel als canonical schon verwenden und dann ist der hreflang tag nicht mehr zwischen den canonical Versionen und dann funktioniert das nicht. Das heißt, wenn ihr jetzt schon hreflang implementieren wollt, müsstet ihr das entweder quasi zukünftig denkend einrichten, dass ihr sagt, gut, ich mache danach diesen redirect und es ist mir bewusst, dass im Moment der hreflang tag nicht funktionieren wird. Dann kann man das natürlich machen oder dann würde ich eher auf die canonical Version verlinken und vielleicht das entsprechend einbauen in der Website, sodass das dann automatisch dann auch wechselt, wenn der canonical wechselt. Zwei Fragen zu caching bei Googlebot. Unterstützt Googlebot if modified sense. Nur für HTML, Dokumente oder auch für JavaScript und CSS. Ja, wir unterstützen das für allen für sich alle, alle Arten von Dateien. Wichtig ist, dass man halt auch mit den sauberen Cache, Headers arbeitet. Das heißt, gerade bei JavaScript und CSS Dateien ist es ja oft so, dass diese sich nicht so oft verändern und da kann man ja dann sagen, das hält vielleicht ein paar Tage, damit wir diese Dateien nicht so oft nachfragen müssen. Gerade wenn wir die Seite natürlich renderen, müssten wir sonst immer die JavaScript Dateien neu holen. Und wenn wir diese bei uns schon mal caching können, dann kann man sich da einiges sparen. Wir haben bei uns First Click Free eingesetzt und haben dann in Search Console mit Fetch und Render das angeschaut und da wird das Honor River quasi die Variante, die der Benutzer sieht, dargestellt. Ist das korrekt oder ist da ein Problem? Ja, das ist an und für sich so korrekt. Das heißt, die Variante, die Infection Render als Benutzer-Variante gezeigt wird, ist die Variante Honor River und die Variante, die von Googlebaut ist natürlich die Googlebaut Variante. Das heißt, wenn eure Seite Honor River vielleicht mal ein Login oder irgend so etwas zeigt, dann sieht man das natürlich dort auch. Das heißt, ihr müsst in diesem Fall einerseits kontrollieren, dass Googlebaut zumindest die richtigen Inhalte sieht und dann vielleicht selber kontrollieren, dass wenn man von der Google Suche kommt mit dem Google Refer, dass da auch die richtigen Inhalte gezeigt werden. Gibt es eine Möglichkeit, die Darstellung des Sightlings zu beeinflussen? Nein, im Moment nicht. Ich glaube, in der Frage geht es dann weiter, dass irgendwie ein Titel in der Sightlink nicht sauber verwendet wird. Praktisch wäre da, wenn ihr mir vielleicht eine Suchanfrage schicken könnt, wo das genau sichtbar ist. Das heißt, wenn ich nach diesem Wort suche, erscheint die, erscheint die Suchergebnisse so und der Titel in den Suchergebnissen ist da falsch zusammengestellt. An und für sich hilft uns das, dass wir diese Titel dann entsprechend ein bisschen verbessern können. Wir haben aktuell mehrere Tausend Seiten, die wir aus dem Index entfernen möchten. Wir können die entweder per Noindex oder 404 löschen. Mal schauen, wie kann man das am besten beschleunigen an und für sich. Ja, was man da einerseits machen kann, ist, wenn es wirklich ein kritisches Problem ist, das heißt, wenn da jetzt zum Beispiel Inhalte sichtbar werden, die gar nicht in der Suche erscheinen dürften, wenn das zum Beispiel persönliche Daten sind, die aus Versehen indexiert wurden, dann würde ich mit dem URL Entfernungstool arbeiten und dann vielleicht auf Verzeichnissebene das rausnehmen. Das Entfernungstool unterdrückt an und für sich die Suchergebnisse nur beim Benutzer selber. Das heißt, man sieht die danach nicht mehr in den Suchergebnissen. Es nimmt diese Inhalte nicht direkt aus dem Index heraus. Wenn man die aus dem Index auch herausnehmen möchte, dann müssen wir diese Seiten neu crawl und dann einfachsten, gerade wenn das eine größere Menge an Seiten ist, ist das zum Beispiel mit einer Sidemap-Datei, dass man eine Sidemap-Datei erstellt mit einem neueren Änderungsdatum für diese Seiten. Um uns zu sagen, seit diesem Datum sind die Seiten jetzt neu, die haben vielleicht jetzt neu ein No-Index oder sind jetzt Neu 404. Und dann können wir aufgrund von dieser Sidemap-Datei dienen, ein bisschen schneller crawlen und das entsprechend im Index aktualisieren. In der Regel ist es aber so, dass man das nicht so quasi forcieren muss, weil meistens crawlen wir die Seiten sowieso und lassen die dann einfach natürlicherweise aus dem Index herausfallen. Gerade bezüglich dupliziert Content zum Beispiel ist es nicht notwendig, dass man das irgendwie unterdrückt und irgendwie schneller raus nimmt. Aber grundsätzlich sind die verschiedenen Optionen für euch offen. Seht gerade, da sind noch ein paar Sachen im Chat. Gute Schauen. Ich glaube mehr Kommentare zwischen euch. Das ist auch okay. Wenn ihr Fragen habt, einfach loslegen. Ja, John, ich hätte noch eine Frage, weil vorhin das Thema Fetch and Render war ganz interessant. Du sagst, es wird einmal von Google, man kann da überprüfen, ob Google die Seite halt richtig rendert. Wir haben gestern hier was vermutet, das hätte ich gerne bestätigt. Es gibt ja immer wieder mal so Hitmets, wo man analysiert, wo schauen die User am meisten hin. Und das ist ja oft oben links auf einer Seite in dem Bereich, wo der eigentliche Content beginnt. Und das dann Keywords, wenn die dort stehen, scheinen die auch extrem gute Ergebnisse, also für Google sehr, sehr relevant zu sein. Das muss nicht immer der erste Text auf der Seite sein. Analysiert Google das, wo sich die Begriffe befinden beim Rändern, läuft dann auch mal sowas wie ein OCR drüber oder wird so die Kontinate auf der Seite bestimmt. Wir versuchen schon festzustellen, wo die Inhalte stehen, aber soweit ich weiß, nicht in Hinblick darauf, dass wir da diese Keywords dann irgendwie stärker hervorheben für die Relevanz. Das ist eher einfach in Hinblick darauf, sind die Sachen jetzt sichtbar oder nicht? Oder wo sind diese Inhalte? Sind da jetzt mal große Werbeblöcke oben, die die Seite beeinflussen? Das sind dann Sachen, die für uns relevant sind. Weniger quasi jetzt, wo die Keywords auf einer Seite stehen. Danke dafür. Ich habe direkt noch eine Frage. Ich habe mich sehr gefreut, als du das englische Hangouts gemacht hast. Da warst du wohl in den USA und eben nicht der Zürich. Und da hat deine Kollegin gesagt, dass offiziell bestätigt wird, dass mit dem Mobile Index auch Page Speed ein relevanter Ranking Faktor werden wird. Die hat das dann auch ein bisschen ausgeführt, dass ich kannst du noch mal ein bisschen was dazu sagen. Geht es jetzt um den Page Speed Insel-Sites-Test, also das, was da bewertet wird oder pauschal um die Ladezeit der Seite? Soweit ist es, glaube ich, noch nicht klar auf unserer Seite, wie wir das genau machen können, weil gibt es verschiedene Varianten, wie wir das zusammenstellen können, aber es ist natürlich kompliziert, das zu berechnen, wenn wir das jetzt mal künstlich berechnen möchten. Und wir möchten ja in erster Linie das so machen, irgendwie quasi widerspiegeln, wie der Benutzer das sieht. Das heißt, wenn die Verbindung für den Benutzer eher langsam ist, dann ist es vielleicht etwas, was wir berücksichtigen müssen. Wenn, sag ich mal, jetzt alle Benutzer in Deutschland sind und die Website ist in Amerika mit einer langsamen Leitung und zwar mit einer schnellen Leitung zum Google Rechnungscenter, aber langsamen Leitung zum Benutzer, möchten wir das ja auch irgendwie berücksichtigen. Aber wie das genau gehandhabt wird, ist im Moment jetzt noch nicht klar. Es ist auch schwierig, mit der Überlegung insgesamt, können wir das pro Seiten machen oder können wir das pro Website machen oder pro Teil einer Website machen. Das sind alles Überlegungen, die im Moment noch ein bisschen offen sind. Okay, dann war vorgesehen, also beim letzten englischen Hangouts, da war ja ein Teilnehmer, der sich darüber beklagt hat, die hat eine Seite für New York, aber da der Googlebot aus Kalifornien kam, wurde halt immer der Inhalt für die Kalifornie gezeigt. Das wäre ja auch so eine Sache, wenn es um PageSpeak geht, dann würde wahrscheinlich jedes Unternehmen ganz schnell einen CDN Pop in Kalifornien haben wollen, dass die Seite da für Googlebot bereitgestellt wird. Ändert sich das vielleicht irgendwann, dass Googlebot von verschiedenen Standorten auch im Planeten zugreift oder? Wie bei Tracen. Ja, wir haben damit schon mal angefangen. Aber ich weiß nicht, vielleicht vor zwei oder drei Jahren haben wir da verschiedene Sachen gemacht und in verschiedenen Standorten crawled effectively von anderen Standorten. Ich glaube, das ist vor allem Südkorea China, Australien, ich bin jetzt nicht ganz sicher. Wir versuchen da quasi festzustellen, wo sind die Benutzer von diesen Webseiten, wenn sie eher in diesen Bereichen sind, dann können wir eher von diesen Region crawlen, weil wir wissen, dass da viele Websites Besucher von anderen Ländern vielleicht blockieren. Gerade jetzt zum Beispiel in China ist es ja oft so, dass da haben sie einen relativ starker Firewall und die können dann vielleicht nicht auf amerikanische Websites zugreifen und die blockieren vielleicht Besucher, die aus Amerika kommen und dementsprechend wollen wir dann einfach die lokalen Inhalte so sehen, wie der Benutzer dort sie entsprechend auch sieht. Schwierig für uns ist einfach, dass wir natürlich nicht aus allen Ländern gleichzeitig crawlen können. Das heißt, wenn man eine Website hat und schon mit Duplicate Content ein bisschen zu kämpfen hat, dann hat man vielleicht zwei oder drei Versionen, die Googlebot crawlen will und wenn dann jetzt noch aus allen Ländern der Welt gecrawlt wird auf diese Varianten, dann sind die Server einfach überlastet. Dann bringt das einerseits uns wenig, weil wir in den meisten Fällen sehen wir immer wieder die gleichen Inhalte und andererseits ist das für den Webmaster natürlich auch lästig, weil da all diese Googlebots auf der Website herumschweren und immer wieder das Gleiche sehen. Von dem her denke ich, dass wir da zumindest kurzfristig das nicht groß ausbauen werden, und dass wir dann eher auf die normalen Googlebotsstandorte uns weiterhin erst noch konzentrieren. Schwierig ist natürlich dann noch mehr, wenn man jetzt denkt innerhalb von einem Land, ja, ich möchte von allen Großstädten irgendwie crawlen können, weil ich habe jetzt für New York und für Kalifornien unterschiedliche Inhalte und vielleicht unterschiedliche Städte innerhalb vom Start New York, dass ich denke, das wird auf jeden Fall nicht kommen. Das ist dann noch eine Stufe höher und tausendfach alle Inhalte crawlen, das macht dann wirklich keinen Sinn. Aber gerade für die Personalisierung ist es halt wichtig, dass man zumindest die Standardinhalte immer auf den Seiten hat. Man kann dann trotzdem noch Blöcke haben, die man austauscht, je nach Standort von Besucher, aber das zumindest die Standardblöcke einigermaßen sichtbar sind, damit wir die dann jeweils zeigen können und entsprechend auch indexieren können. OK. Ja, weitere Fragen? So weit gut, OK. Ich hätte noch eine Frage ganz kurz zur User-Agent-Frage. Wir haben ab und zu bei uns in Logs tauchen Crawls, oder Crawls auf der User-Agent. Ich habe das Media-Partners, glaube ich, ist es. Ja, ich habe Media-Partners, minus Google ist es. Gleiche IP eigentlich, also alles identisch. Ist es so, dass teilweise aus ökonomischen Gründen da teilweise Informationen doppelt genutzt werden, oder soll man sowas bei Log-Fall-Analysen komplett rauslassen? Meines Wissens ist der Media-Part, oder weiß ich jetzt nicht, wie er genau heißt, ist von AdSense. Also wenn AdSense quasi die Seiten anschaut, zum Feststellen, worum geht es auf dieser Seite, welche Werbung kann da gezeigt werden. Und je nachdem, wenn man natürlich AdSense verwendet, macht es Sinn, dass man das zulässt. Wenn man das blockieren will, kann man das natürlich auch blockieren. Nee, es geht weniger ums Blockieren, sondern sage ich mal, ja, wenn ich jetzt sehe, dass irgendwo, geht irgendwas nach oben von der Frequenz, oder so, ist es, dass man einfach das, das man nicht den Fehler macht, irgendwie Korrelation herzustellen, die eigentlich gar nicht existieren. Ja, also, soweit ich weiß, sind die AdSense-Zugriffe wirklich nur für AdSense? Ist es nicht so, dass wir die dann auch für die Websuche verwenden? Also es sind wirklich ganz, ganz getrennte Systeme im Hintergrund. Als das, wenn der User ist und drin ist, dann ist das gar nicht relevant. Genau. Gut, danke. Okay, das sind... John? Ja. Eine Frage noch, ein Kollege hat noch im Chat geschrieben, und zwar ist uns aufgefallen, auf AMP-Seiten wird teilweise in den Google Serbs werden die Rich Snippets ausgezeichnet, also Bewertung und auch günstigster Preis, der auf der Canonical-Seite, also auf der Desktop-Variante zu finden ist. Und wir haben gar keine Rich Snippet-Auszeichnung, überschieber Org beispielsweise auf der AMP-Variante. Ist das in Ordnung so oder sollten wir das lieber auf der AMP-Variante separat auszeichnen? Das sollte eigentlich okay sein. So viel ich weiß, kann man ja nicht alle Varianten auf der AMP-Seite markieren. Von dem her versuchen wir, die Zusatzinformationen von der Desktop-Seite zu nehmen. Auch für das Ranking, für die Relevanz nehmen wir ja auch die Desktop-Seite, weil das ist ja die Canonical-Version. Also sollte das eigentlich in Ordnung sein. Ich denke, da müsste man das nicht separat hineinnehmen. Wenn man jetzt separate mobilen Seiten hat, jetzt ein Hinblick auf Mobile First Indexing, da macht es natürlich Sinn, dass man da auch die Structuredata-Daten entsprechend einbindet auf der mobilen Version. Aber gerade bei AMP ist es ja so, dass das wie eine noch separate Version ist. Und für die AMP-Seiten verwenden wir wirklich nur die Canonical-Version für das Indexierung. Super, vielen Dank. Okay, sind noch ein paar Fragen da eingereicht. Gehen wir die vielleicht mal kurz durch. Eine Frage zur Crawling 404er. Wieso crawled Googlebot nicht einfach nur die URLs, die in der Sidemap-Datei sind? Warum geht Googlebot immer diese alten 404-Seiten anschauen? Ja, gute Frage. Wir verwenden einerseits die Sidemap-Datei, um das Crawling zu erweitern. Das heißt, wir crawlen sowieso normal und nehmen dann die Information aus der Sidemap-Datei noch zusätzlich dazu. Das heißt, es ist nicht so, dass durch das Einreichen einer Sidemap-Datei weniger gecrawlt wird, sondern wir versuchen einfach, das Crawling dann ein bisschen zu optimieren und eher auf die neueren Seiten dazu konzentrieren, die in der Sidemap-Datei sind. Aber wir crawlen trotzdem noch weiter normal. Der Hauptgrund dafür ist, dass wir sehen, dass viele Sidemap-Dateien sind einfach älter, die sind nicht mehr aktuell, sind nicht nachgeführt. Und wir möchten für solche Fälle dann nicht irgendwie die Websites bestrafen, indem wir die neuen Seiten, die auf der Website sind, nicht noch nachcrawlen. Bezüglich den 404ern ist es so, dass wir wirklich diese 404-Urall immer wieder kontrollieren, weil wir das Gefühl haben, da waren mal vielleicht gute Inhalte vorhanden und wir möchten kontrollieren, dass wir da nichts verpassen. Gerade wenn wir jetzt neue Links zu diesen Seiten finden oder allgemein, wenn wir einfach denken, wir schauen einfach mal, vielleicht einmal im Jahr oder so nach, was auf diesen Seiten jetzt ist. Wenn da ein 404 ist, ist das für uns vollkommen okay. Es ist also nicht der Fall, dass ihr die Anzahl an 404-Fehler irgendwie optimieren müsst, sondern das ist aus unserer Sicht vollkommen okay. Mal kurz schauen. Irgendwie sind eine Google-Sternchen auf unser DE-Domain in der Suche verschwunden, sowohl bei Produkt als auch beim Domain. Auf unser.com und .fr-Domain werden sie noch angezeigt, kannst du sagen, was da passiert ist? Ich habe kurz bei der Website nachgeschaut und da ist es so, dass da eine manuelle Maßnahme vom Web-Sperm-Team vorliegt. Und das siehst du wahrscheinlich in Search Console, wenn du dann nachschaust bei dem manuellen Maßnahme. Eventuell ist auch ein bisschen Information darüber, was da das Problem ist. Wenn es für euch unklar ist, was da wirklich gefunden worden ist vom Web-Sperm-Team, würde ich im Hilfeforum kurz ein Thread aufmachen, dass ihr das vielleicht mit Andor und mal kurz anschauen könnt. John, da hätte ich einmal eine Frage zur Bewertung. Und zwar, damit diese Bewertung zum Beispiel in AdWords angezeigt werden, hat mir nun gesagt, die brauchen da eine gewisse Anzahl pro halben Jahr oder so. Kannst du da was zu den Zahlen sagen? Wie viele neue Bewertungen das sein müssen, damit das angezeigt wird? Keine Ahnung. Also, ich weiß nicht, wie das bei AdWords gehandhabt wird. Oder wie normalen ist das Ergebnis? In den normalen Suchergebnissen ist es nicht so, dass wir da eine gewisse Anzahl brauchen oder dass wir da eine gewisse Aktivität brauchen. Wir schauen effektiv das an, was im Moment markiert ist. Aber es kann durchaus sein, dass AdWords da andere Richtlinien hat. Und dann muss man halt schauen, was man da versucht anzusteuern. Okay, danke. Da haben wir noch eine Frage zur Anchor Tags. Wir schreiben viele Ratgeber verlinken am unteren Ende des Artikels in einer Quellen-Sammlung auf externe Seiten oder andere Ratgeber. Ist es schädlich, wenn erst dort die Quelle genannt wird und dann die H1 der Zielseite komplett verlinkt wird? Und da ein Beispiel. Ich fühle das. Grundsätzlich ist das okay, wenn man da auf andere Seiten verlinkt mit dem Titel der Seite, ist das eigentlich kein Problem. Also seht ihr jetzt nicht problematisches diesbezüglich. Ich denke, das sollte eigentlich okay sein. Wir haben noch eine eigene mobile Subdomain. Die Inhalt und Pfade sind identisch, gemäß Google-Dokumentationen liefern wir den Canonical-Header aus und dann die Verlinkung mit dem Rail-Alternate. Search Console sagt, dass die mobile Version mit gewisser Crawl-Rape gekraut wird. Bei der Indexierung in Search Console ist aber nur ein kleiner Teil dieser URLs indexiert. Was läuft da schief? Grundsätzlich läuft da nicht schief. Es ist so, dass wenn ihr den Canonical angegeben habt bei den mobilen Seiten und wir diese Verknüpfung sauber herstellen können, wird das nicht separat indexiert. Das heißt, die Anzahl indexierter URLs, die da ausgeführt werden für den mobilen Subdomain, sind an und für sich irrelevant. Wichtig ist die Anzahl indexierter URLs für die Desktop-Version, also für die Canonical-Version. Im Zug vom Mobile First Index kann es sein, dass sich das irgendwie wechselt, aber im Moment ist es ja so, dass die mobile Version es ja explizit nicht aus Canonical angegeben und von dem her muss sie auch nicht indexiert sein und die Anzahl indexierter Seiten dort ist an und für sich irrelevant für euch. Wir haben 4.000 Redirects auf unserer Website und unsere Web-Argentur hat vorgeschlagen, den größten Teil von diesen zu entfernen. Es sind alles alte Seiten, die nicht Teil unserer Website sind macht es Sinn, die Redirects zu entfernen. Dann läuft vielleicht die Web-Seiten ein bisschen schon besser. Aus meiner Sicht hängt das eher davon ab, wie viel Verkehr ihr auf diese Seiten kriegt. Das heißt, wenn ihr sieht, dass Benutzer noch auf diese Seiten gehen, dann würde ich die Redirects eher noch dalassen. Wenn ihr sieht, dass Googlebot noch wirklich sehr stark auf diese Seiten geht beim Crawling, dann würde ich diese Redirects noch eine Weile lassen. Wenn hingegen Benutzer so gut wie gar keine mehr dorthin kommen und Googlebots Crawling sich quasi auf das Minimale wieder beschränkt, dann kann man die durchaus entfernen. Ich denke, zum Beispiel jetzt zeig mal nach einem Jahr oder so, wenn die Redirects jetzt immer vorhanden waren und wirklich nicht mehr auf diese Seiten verlinkt werden, wenn Benutzer nicht mehr auf diese Seiten gehen, dann würde ich die Redirects durchaus entfernen. Macht es Sinn, die alte Sitemap mit alten URLs in Search Console parallel zu neuen Sitemap liegen zu lassen, bis die neuen URLs komplett indexiert sind? Kann man machen, kann man machen. Wir haben das gerade bei Websiteumzug oder bei HTTPS Wechsel, haben wir das mal empfohlen, dass wir sagen, die alten URLs auch einreichen per Sitemap Dateien mit einem neueren Änderungsdatum, damit wir die Redirects entsprechend ein bisschen schneller finden können, kann man durchaus so machen. Ich denke, wichtig ist einfach, wenn man das in den Sitemapsfunktionen anschaut in Search Console, dass man sich bewusst ist, dass die Anzahl indexierter URLs dort nicht für euch wichtig ist. Das heißt, es wird wahrscheinlich so sein, dass da Fehler dargestellt werden für die Sitemap, dass die Anzahl indexierter URLs für diese alte Version quasi auch zurückgeht und das an für sich das, was ihr machen wollt. Von dem her ist das vollkommen okay. Ich hätte gerne mal gewusst, wie YouTube kleinere Content Creators schützt. Unsere Videos werden andauend von anderen Usern auf deren Kanal hochgeladen. Ich weiß nicht, wie das YouTube Hand habt. Da würde ich im YouTube-Hilfeforum mal nachfragen. Ich weiß, das ist sicher ein großes Thema auf unserer Seite, aber wie genau das funktioniert? Ja, hoffentlich kommt YouTube nicht immer auf die Idee, dann den Browser neu zu starten zwischen euch. Das macht eigentlich nicht so viel. Okay. Puh, immer was Spannendes zwischen euch. Eben, wie gesagt, mit den YouTube-Fragen würde ich da eher im YouTube-Forum nachschauen und da mal fragen, wie das gehandhabt wird. Ich habe auf einer Website viele URLs, die durch Robots Text blockiert sind, Login Bereiche, die sind teilweise für Internal Links, für Crawler erreichbar. Leider sind da einige im Index gekommen. Was kann man da am besten machen? Ich würde da in erster Linie einfach mal schauen, wie viele von diesen Seiten effektiv in den normalen Suchergebnissen erscheinen. Und wenn das, sag ich mal, zu viele für euch sind, dann würde ich dann weiter schauen, was man damit machen muss. Aber wenn das nur Seiten sind, die per Zeitabfrage sichtbar sind, die quasi nur dann in den Suchergebnissen erscheinen, wenn man gezielt nach diesen URLs sucht, dann würde ich das ignorieren. Ich denke, das sollte eigentlich kein Problem sein. Man kann das kontrollieren in Search Console, in Search Analytics, in dem man die URLs angibt oder im URL-Muster angibt und dann schaut, wie viele Impressions diese Seiten effektiv haben. Wenn man das bereinigen will, kann man das so machen, in dem man zulässt, dass diese Seiten gekrawlt werden und dann mit dem No-Index-Metatag erarbeitet. Das heißt, auf diesen Login-Seiten müsste man das Crawl entzulassen, also diese spären Robotstext entfernen und sicherstellen, dass da einfach ein Meta-No-Index auf diesen Seiten ist. Dann können wir diese Seiten crawlen, sehen, dass da ein No-Index ist und nehmen die entsprechend aus dem Index heraus. In das Search Console haben aktuell drei Property-Einträge, HTTPS und dann Mobile. Wir haben da vor fünf Monaten von eins auf zwei migriert. Können wir die anderen löschen? Was passiert mit den Daten? An und für sich löschen könnte die auf jeden Fall, das beeinflusst die Suche nicht. Das heißt, wenn ihr eine Webseite nicht in Search Console habt oder wenn ihr sie entfernt habt aus Search Console, wird das trotzdem noch normal in der Suche quasi weiterverarbeitet. Von dem her, wenn ihr jetzt eine Weite Leitung eingerichtet habt und ihr keine relevanten Daten mehr auf dem alten Domain findet oder auf der alten Version, dann ist das an und für sich okay, kann man das entfernen. Man kann auch ein Property Set erstellen. Das kann man verwenden in Search Console, wo man verschiedene Varianten von einer Webseite zusammenführt und für Search Analytics wird dann alles zusammen kombiniert und kombiniert sichtbar. Andere Funktionen in Search Console verwenden noch nicht die Property Set Funktionalität, aber Search Analytics, gerade wenn es darum geht, welche Suchanfragen kommen rein, wie viele Clicks und Impressions haben wir, das wird dann an und für sich schön zusammengeführt. Noch eine Frage zur strukturierten Daten. Auf unserer Webseite veröffentlichen wir Veranstaltungen, die wir nach schema.org ausgezeichnet haben. In Search Console wird das entsprechend auch gefunden, allerdings werden die Events nicht in den Suchergebnissen erscheint. Woran könnte das Problem liegen? Schwierig zu sagen, also gerade bei strukturierten Daten ist es so, dass wir einerseits die, der Markup muss korrekt sein. Das klingt so, als ob ihr das richtig habt, weil wenn es in Search Console erscheint und das im Testing Tool erscheint, dann ist der Markup wahrscheinlich korrekt. Andererseits muss es sauber implementiert sein, gemäß unseren Policies und Richtlinien. Wenn in den manuellen Maßnahmen nichts vorliegt, dann stimmt das wahrscheinlich auch. Und drittens muss die Qualität der Webseite insgesamt so sein, dass wir diesen Markup auch sauber vertrauen können. Und das ist manchmal ein bisschen schwierig einzuschätzen. Was ich da machen würde, ist vielleicht im Hilfeforum auch mal nachfragen, wie andere jetzt die Webseite sehen, wie sie diesen Markup sehen und einfach mal grob vielleicht schauen, ob es da irgendwelche Tipps gibt, auf die man reagieren könnte, wie man die Webseite ein bisschen verbessern könnte. Aber gerade, wenn es sich um Qualitätsprobleme handelt, ist es natürlich ein bisschen schwieriger Bereich, denn es ist nicht so, dass man einfach einen Mattertag kontrollieren kann und den korrigieren kann, sondern es ist oft einfach eine Frage vom Gesamtbild der Webseite, wo da verschiedene Sachen zusammenkommen können. Dann noch eine Frage hier. Seit rund vier Wochen sind unsere Google-Position teilweise massiv angebrochen. Im Internet wurde zu dieser Zeit sehr intensiv über größere Google-Updates spekuliert. Kannst du hierzu etwas sagen? Ich weiß jetzt nicht genau, welcher Webseite das ist und welche Updates das sein könnten. Wir machen natürlich immer wieder Updates. Das kann immer wieder Veränderungen geben in der Suche. Was ich da vielleicht auch machen würde, ist im Hilfeforum Nachfragen und mit anderen das mal anschauen. Vielleicht gibt es da grundlegende Sachen, die man verbessern könnte an der Webseite. Insgesamt vielleicht bezüglich Qualität oder vielleicht auch bezüglich den technischen Aufbau. Vielleicht kommt man dann so ein bisschen näher an Stil. Aber das ist, zeig mal ein bisschen schwierig zu sagen, so groß aus der Ferne ohne die Webseite zu sehen und ohne genau zu wissen, welche Datumsbereiche das waren. Okay, haben wir es glaube ich geschafft. Das ist alle Fragen durch. Gibt es vielleicht noch eine letzte Frage von euch? Ja, ich habe noch eine Frage. Super, habe ich jetzt gesehen, dass in den Google Suchergebnissen manchmal Tabellen angezeigt werden. Das war jetzt ein Wettbewerber von einem meiner Kunden und mein Kunde meinte so, es ist ziemlich dumm für den Wettbewerber, weil dadurch braucht keiner mehr auf die Webseite klicken. Kann man sowas auch verbieten? Das sage ich mal größere Suchergebnisse angezeigt werden, also ganze Inhalte der Webseite wie eine Tabelle. Man kann mit dem Snow Snippet Tag arbeiten. Snow Snippet Tag, okay. Ist natürlich ein starker Hammer, sage ich mal, weil dann ist der ganze Snippet weg. Der Titel ist natürlich noch da, aber der ganze Snippet ist dann weg. Aber ansonsten gibt es nicht eine Möglichkeit, dass man das quasi pro Abschnitt auf einer Seite machen kann, sondern es ist dann wirklich nur für die ganze Seite selber. Okay, danke. Aber ich würde vielleicht auch überlegen, ob das vielleicht auch eine gute Sache ist. Also ich weiß, es gibt viele Blogposts, die... Es hat Google schon wieder keinen Internet mehr. Schade. Ha! Irgendwie, Bilderbrowser heute nicht. Wie gesagt, ich weiß, es gibt viele Blogposts, die auch gezielt darauf hinarbeiten, dass man diese Tabellen Snippets kriegt, dass man diese Feature Snippets kriegt. Von dem her würde ich mir vielleicht auch mal überlegen, ob das vielleicht okay ist, dass man die Inhalte so zeigt, weil so sehen die Benutzer ja auch ein bisschen eher, was auf dieser Seite zu finden ist. Und wenn sie das interessiert, dann hat man eher auch die qualifizierten Besucher auf der Webseite. Aber grundsätzlich ist das euch überlassen. Das kann man natürlich auch mal testen, dass man sagt, gut, ich nehme diese Tabelle vielleicht mal raus, oder ich hole die per JavaScript hinein, dass sie irgendwie nicht so einfach lesbar ist, dass man einfach mal testet, welche Auswirkungen hat das insgesamt auf die Convergence von meiner Webseite? Mhm, ja, danke. Okay, dann schalte ich mal bewussten Browser aus. Ich hoffe, die Unterbrechung war nicht zu arg. Und vielleicht sehen wir uns dann in einem der nächsten Hangouts wieder. Wünsche ich euch noch einen schönen Nachmittag. Tschüss allerseits. Danke fürs Kommen. Tschüss.