 Okay, herzlich willkommen beim heutigen Webmaster Central Sprechstunden Hangout. Ich bin Johannes Müller, ein Webmaster Trans Analyst hier bei Google in der Schweiz. Teil von dem, was wir machen, sind solche Webmaster Hangouts, wo Webmaster Publisher SEOs kommen können und diverse Fragen rund um die Websuche stellen können. Sind schon einige Fragen eingereicht worden über YouTube, aber wenn einer von euch loslegen möchte, seid ihr gerne eingeladen schon mal anzufangen. Ist das auch okay? Also, dann starten wir doch mal die Fragen durch. Wenn ihr weitere Fragen oder Kommentare zwischendurch habt, einfach nur loslegen. Eine Frage über JavaScript und Navigation. Wenn ich meinen JavaScript deaktiviere und dann eine Shop-Seite anserfe, dann funktioniert das Dropdown mit den gesamten Kategorien-Links nicht mehr. Angenommen die Links würden dadurch aus dem Source Code verschwinden. Wie geht Google in Schritt 1 ohne JavaScript rendering damit um? Die Verbindung zwischen Start- und Kategorien-Seite könnte damit unterbrochen sein. Können ihr durch regelmäßig wiederkehrendes Sichtbarkeitssprünge entstehen? Grundsätzlich versuchen wir eigentlich, das Rendering möglichst schnell zu machen. Das heißt, wir versuchen diese Seiten möglichst direkt zu renderen, sobald wir das können. Im Schnitt ist es, glaube ich, innerhalb von, ich weiß nicht, Minuten oder so, haben wir, glaube ich, kürzlich gesagt. Von dem her gibt es eigentlich nicht mehr so diesen großen Unterschied zwischen der nicht gerenderten Version und der gerenderten Version beim Indexierung. Das heißt, wir würden versuchen, zumindest diese Seiten so zu sehen, wie sie mit JavaScript laufen würden. Von dem her sollte das eigentlich klappen. Was ich da vielleicht machen würde, einfach damit man sicher ist, dass diese Navigation kommt, mit dem Inspect-URL-Tool zu arbeiten, wo man dann auch die HTML-Version von der gerenderten Version anschauen kann, damit man wirklich sicher sein kann, dass da wirklich sauber links gefunden werden, dass die Links mit einem A-Element im HTML dabei sind, mit einem href, mit einer sauberen URL, damit wir in der gerenderten Version wirklich saubere Links erkennen können. Was manchmal gemacht wird, ist, dass man einfach HTML-Elemente nimmt und dann quasi ein Event dazu fügt und sagt, wenn jemand auf dieses Element klickt, dann soll zu einer anderen URL navigiert werden. Solche Sachen würden wir in der Regel nicht erkennen. Das heißt, wenn man Links einbauen möchte und wenn man möchte, dass diese Links quasi befolgt werden für das Crawling und Indexing, dann müssen das auf jeden Fall A-Elemente sein mit einem href Link entsprechend dabei. Dann eine Frage zum Crawling-Frequenz. Macht es Sinn, dies über Black Friday auf Niedrig zu setzen? Ich denke, das ist ein bisschen spät jetzt, aber grundsätzlich kann man das machen. Die Crawling-Frequenz tritt ein circa am nächsten Tag. Das heißt, wenn ich jetzt eine Änderung mache, dann am nächsten Tag, wenn unsere Crawler quasi die Konfiguration neu laden, dann trifft diese neue Konfiguration ein. Das heißt, wenn man jetzt die Änderung machen würde für Black Friday, wäre das schon sehr knapp. Ich weiß nicht, ob das noch greifen würde. Was man hingegen machen kann, wenn man wirklich sicher sein möchte, dass vom Crawling her das Googlebot erst mal aus dem Weg bleibt und die Informationen im Moment jetzt nicht crawled und nicht indexiert, ist man kann die Robots Text-Dateien mit einem 503 Status Code zurückgeben. Was dann passieren würde, ist Googlebot würde diesen Status Code sehen, 503 und würde dann erst mal zurückhalten und sagen, gut, ich crawler jetzt gar nichts von dieser Website im Moment und die Robots Text-Datei werden ein bisschen später dann nochmal kontrolliert, mehrmals an und für sich über die nächsten paar Tage und sobald wir wieder die Robots Text crawlen können, versuchen wir dann normal die Website wieder zu crawlen. Das heißt, wenn alle Inhalte effektiv so indexiert sind, wie ihr sie haben wollt und ihr wollt sicherstellen, dass Googlebot gar nicht die Website im Moment crawled, ohne dass man die Website direkt mit disallow alles in der Robots Text sperrt, kann man das mit dem 503 Status Code machen. Wir sehen das aus einem temporären Fehler an, das heißt, wir würden diese URLs nicht aus dem Index nehmen und wenn nach ein paar Tagen sich das wieder einpendelten, wir die Robots Text-Datei wieder crawlen können, dann können wir eigentlich wieder normal loslegen. Ich habe noch eine Frage zu der ersten Frage. Würde es eigentlich in Richtung Cloking gehen, wenn Googlebot die Links, also diese A-Links nicht sieht, aber der User doch, also ich benutze halt, also ich schaue, dass die Links für die User da sind, aber ich möchte halt ein bisschen den Googlebot steuern, also die Priorisierung irgendwie vornehmen. Also es sind Artikel, die jetzt nicht wichtig sind und der User sieht halt nur den Link zu dem Artikel. Würde in die Richtung gehen, grundsätzlich ist das wahrscheinlich etwas, wo das Webspam-Team jetzt nicht irgendwie manuell eingreifen würde, weil das sind ja nicht größere Veränderungen an einem Inhalt direkt. Ich könnte mir einfach vorstellen, also eines Eingrund, warum wir das in der Regel nicht empfehlen, weil das schwieriger ist mit in der Wartung. Das heißt, nach einer gewissen Zeit weißt du dann vielleicht nicht mehr genau, welche Links werden für Googlebot sichtbar, welche sind nicht sichtbar. Das macht es möglich, dass man da unter Umständen, die die normale Linkstruktur einer Website quasi ausversehen versteckt und auf einmal kann Googlebot die normalen Seiten gar nicht mehr richtig crawlen. Das ist mal die eine Sache. Die andere Sache ist, dass in vielen Fällen, dieses quasi Page-Rank-Scoping, wie man das nennt, funktioniert eigentlich nicht so, dass man da wirklich einen großen Unterschied sieht. Es hängt ein bisschen von der Website ab, wie das alles eingerichtet ist, aber im Großen und Ganzen macht man sich sehr schnell auch sehr viel Aufwand, der eigentlich nicht wahnsinnig viel Nutzen hat. Ich weiß nicht, wie das jetzt bei dir eingerichtet ist oder was du da ausprobierst, aber das wäre vielleicht eine Sache, die man noch bedenken würde. Das heißt, aus Webspam gründen würde ich jetzt nicht sagen, dass da das Webspam-Team eingreifen würde. Ich denke, wenn du soweit sicher bist, dass du das sauber einrichten kannst, dann würde ich damit vielleicht mal etwas ausprobieren, schauen, ob das für dich wirklich einen Nutzen bringt und dann kannst du ja auch weiter schauen, ob das wirklich für dich auf längerfristig Sinn macht oder ob das einfach mehr Overhead ist, der mit der Wartung dann wieder alles komplizierter macht. Also was ich auch gesehen habe, dass zum Beispiel links durch robots.txt blockiert werden, also dass zum Beispiel bei Affiliate-Seiten, dass die Produktdetails dann halt geblockt werden, das ist ein ganz großer Online-Shop, weiß ich jetzt nicht, Partner-Shop, und die haben das zum Beispiel, die haben links zu ihren Produkten, aber dann durch robots.txt geblockt. Also da fließt ja auch kein Patchwink oder fließt doch Patchwink weiter wahrscheinlich. Ja, was da passieren würde, ist, wir würden unter Umständen diese Links zu diesen Seiten finden, vielleicht auch externe Links, und da könnte es passieren, dass wir diese URLs ohne zu crawlen auch indexieren. Das heißt, wir sehen einfach die Links, die intern da hingehen und sehen, dass wir diese Inhalte nicht crawlen können, aber wir vermuten, dass da sinnvolle Inhalte sind, und dann kann es sein, dass wir die URL indexieren, ohne dass die Inhalte effektiv indexiert sind. Und dann kann es, also was man da normalerweise sieht, ist, wenn man jetzt eine Site-Abfrage in der Suche macht, mit normalen Suchen innerhalb der Website oder insgesamt im Web, hängt es ein bisschen davon ab, ob man jetzt andere Inhalte hat, die dazu passen. Wenn ich zum Beispiel eine Produkte Seite eigentlich immer per robots.txt blockiert habe, dann kann es sein, dass wenn jemand nach diesem Produkt sucht, dass wir diese per robots.txt blockierte Version zeigen in den Suchergebnissen. Hingegen, wenn ich eine Variante, eine Produktseite per robots.txt blockiert habe und ich eine andere Variante habe, die normal crawlbar ist, dann werden wir, in der Regel würden wir dann versuchen, die crawlbare Version einfach zu zeigen. Das heißt, es ist nicht ganz das Gleiche. Je nachdem, was man machen möchte, wäre das vielleicht auch eine Variante. Es hängt auch ein bisschen davon ab, wie man die Website strukturiert und was man effektiv auch indexiert haben möchte. Okay, danke schön. Ich hätte noch eine Ermerkung zu den PageRanks Sculpting. Ich hatte mir mal angeschaut, zum Beispiel auf Otto.de gibt es auf der Startseite ca. 800 bis 900 ausgehende Links und auf Amazon.de, zum Beispiel nur so 250. Und da wäre jetzt die Frage, weil Schraubs das ja natürlich ganz oft machen, dass sie irgendwie auf alle Kategorien verlinken. Ich weiß nicht, ganz viele Produkte. Und da wäre die Frage, ist das ein Problem? Sollte man eigentlich lieber die Links versuchen, auf der Startseite zu minimieren und nur auf Kategorienseiten zu verlinken oder macht das auch für euch eigentlich keinen Unterschied? Es ist einfach, es ist unterschiedlich. Also es ist nicht so, dass es für uns keinen Unterschied macht. Aber man kann das meistens so ansehen, dass in vielen Fällen ist die Startseite eines der stärkeren Seiten in der Website. Viele anderen verlinken direkt auf die Startseite. Deswegen sehen wir die Startseite an als etwas, was sehr wichtig ist. Und die Links, die von dort rausgehen, das sind auch für sich Links, die wir als eher wichtig betrachten würden. Und dann ist natürlich die Frage, wie man mit diesem Wert von der Startseite umgeht, ob man das eher konzentriert auf Kategorienseiten schicken möchte. Wenn man sagen möchte, diese Kategorienseiten sind für mich wirklich kritisch. Oder ob man das vielleicht ein bisschen breiter gefächert verteilen möchte und sagt, dass die Kategorienseiten und die Detailseiten und vielleicht die Neuigkeiten oder die Nachrichten, je nachdem, was man alles verlinkt hat auf der Startseite, ob die auch ebenfalls wichtig sind. Und das sind, denke ich, verschiedene Überlegungen, die man halt anstellen kann und sagen kann, ich möchte, dass es möglichst breit gefächert ist oder ich möchte, dass es möglichst konzentriert ist. Man kann auch eine Mischung davon machen, dass man sagt, grundsätzlich nur die Kategorienseiten oder nur die Kategorienseiten, die für mich interessant sind, dass man sich auch überlegt, wo habe ich den meisten Wert, wenn Benutzer kommen? Oder wo ist die stärkste Konkurrenz, dass man da vielleicht auf das achtet und dass man dann vielleicht trotzdem die Neuigkeiten von der Startseite, so dass die neuen Produkte relativ schnell auch indexiert werden, dass sie auch relativ schnell mal einigermaßen stark auch dastehen in den Suchergebnissen. Aber da würde ich sagen, gibt es keine genaue Regel, weil es hängt wirklich davon ab, was ihr damit erreichen wollt. Mit den normalen Shopstrukturen, quasi mit diesen Kategorien und Unterkategorien und dann Produktdetailseiten, da kommen wir eigentlich relativ gut zurecht. Das heißt vom Verständnis her, das ist sicher okay. Man kann das aber sicher auch optimieren und ein bisschen so steuern, wie man das eher haben will. John, wenn jetzt in der Navigation schon 400 links drin sind, wie bei Otto.de, ich habe mir immer so aufgenommen, dass Google diese Side-Wide-Header-Funktion sowieso nicht so ganz ernst nimmt, würde ich mal sagen. Also einfach, dass wenn das auf jeder Seite drauf ist und die Seite startet erstmal mit 400 links, hat das nicht sowieso weniger Wert und wird ignoriert von Google? Also ignoriert sicher nicht. Was passiert vor allem mit den Boilerplate-Inhalten? Wir würden das als Boilerplate bezeichnen, wenn das quasi mehrfach wiederholt wird über die Website, ist dass wir da vor allem die textlichen Inhalte vielleicht ein bisschen unterbewerten, wenn wir das auf anderen Seiten sehen. Das heißt, ich würde mal sagen, mit der Startseite würden wir das als etwas relevanter sehen, weil das da halt auch erwähnt ist. Aber wenn das auf allen Detail-Zeiten nochmal wiederholt wird, dann können wir sagen, gut, wir haben das von der Startseite schon sauber indexiert, wir müssen das nicht so stark bewerben für die anderen Detail-Zeiten. Das heißt, vom Crawling her würden wir diesen links trotzdem noch folgen. Auf der Startseite würden wir das sicher auch normal berücksichtigen. Auf den Detail-Zeiten ist es aber so, dass wir dann sagen würden, gut, vom Inhalt her bringt uns das nicht noch mehr wert. Wir konzentrieren uns eher auf die hauptsächlichen Inhalte von diesen Detail-Zeiten. Wie ist das denn, wenn Kategorie-Seiten sehr hoch gelistet werden? Also ein sehr hohes Wankinger, zum Beispiel Position 1, 2 oder 3, geben diese Seiten denn auch ein mehr Signale weiter, also wenn noch unter links bestehen? Klar, ja. Also wenn wir denken, dass diese Kategorie-Seiten wichtig sind, dann sind die Sachen, die von dort aus verlinkt werden, entsprechend für uns auch relativ wichtig. Und wenn ein Suchwort zum Beispiel auf Seite 6 ganz unten ist, also Platz 60, 70 oder so, dann gibt diese Seite nicht so viel Signale weiter, auch wenn die von nach Homepage aus verlinkt ist. Also du meinst in den Suchergebnissen dann auf? Ja, also ich habe halt eine so eine Qualitätsseite, wo ich nicht genau weiß. Also es gibt diese Frage, wo versucht ihr mit einem Suchwort zu ranken, was nicht unbedingt so richtig passt, da habe ich eine Seite von. Und die ist auf Platz 60 irgendwo, ist aber von nach Homepage prominent verlinkt. Wäre es dann so, dass diese Seite dann den Rest noch ein bisschen mit runter zieht, also das ist ja eigentlich Verschwendung von der Homepage verlinkt auf diese Seite. Ich könnte ja eigentlich den Link auch entfernen und dann mehr abgeben auf die anderen Kategorien. Kann man wahrscheinlich machen. Ich weiß nicht, ob das Verschwendung ist. Es ist schwierig zu sagen. Was vielleicht auch wichtig dabei ist, ist, dass das Ranking hängt nicht nur davon ab, wie das quasi intern verlinkt ist, sondern wir versuchen natürlich auch die Relevanz von diesen Seiten bezüglich diesen Keywords zu bestimmen. Und da kann es durchaus sein, dass etwas gut verlinkt wird intern, aber dass wir denken, diese Seite ist trotzdem vielleicht nicht so wahnsinnig relevant für diese besondere Suche. Das heißt, da nur vom Ranking allein, würde ich nicht sagen, dass wir denken, diese Seite ist irrelevant oder dass sie schlecht verlinkt ist, sondern das hat da eine Kombination von vielen verschiedenen Faktoren. Okay, alles klar. Aber normalerweise, wenn du siehst, dass etwas wirklich auch stark in den Suchegebnissen erscheint, nicht nur für eine Suchanfrage, sondern auch vielleicht für eine Sammlung von Suchanfragen, die für deine Seite relevant sind, dann ist das schon eher ein Zeichen, dass wir denken, das ist eher eine wichtige Seite für uns. Okay. Dann eine Frage zum Sight Link Suchfeld. Wir haben unter Sight Link Suchfeld trotz der richtigen Implementierung in JSON-LD in den Suchegebnissen verloren. Laut Search Console und dem Test Tool für strukturierte Daten ist das Suchfeld für unsere Website gültig. Bei Betrachtung anderer Domains ist aufgefallen, dass diese, die gleichen strukturierten Daten verwenden und bei denen ein Suchfeld in den Google-Ergebnissen angezeigt wird. Welchen Grund könnte es hierfür geben? Gerade beim Sight Link Suchfeld ist es so, dass wir in erster Linie darauf achten, ob es für uns jetzt Sinn macht, den Sight Link Search Suchfeld zu zeigen oder nicht. Und wenn unsere Algorithmen sagen, dass wir jetzt ein Sight Link Suchfeld zeigen sollen, dann schauen wir, ob ihr dieses Markup habt, ob wir das sauber verwenden können und dann zeigen wir quasi eure Variante oder dann zeigen wir halt eine normale Sight Such Variante. Das heißt, wenn das Sight Link Suchfeld verschwindet oder gar nicht dargestellt wird, dann ist es in der Regel eigentlich nicht ein Zeichen, dass das Markup falsch ist, sondern dass unsere Algorithmen einfach denken, im Moment macht das nicht so Sinn, ein Sight Link Suchfeld zu zeigen. Das heißt, was ich jetzt an eurer Stelle da machen würde, ist, das Markup einfach beibehalten und das vielleicht einfach weiterhin beobachten und schauen, ob das wieder zurückkommt oder ob das jetzt einfach halt jetzt nicht mehr dargestellt wird. Wir versuchen das dann darzustellen, wenn wir denken, dass das für den Benutzer auch sinnvoll ist. Das heißt, wenn wir erkennen können, dass die Benutzer mit eurer Website eigentlich soweit gut zurechtkommen, das heißt, über die Suche dahin kommen, wo sie hin wollen in eurer Website, dann müssen wir eigentlich kein Sight Link Suchfeld zeigen. Wir wollen dahin gegen feststellen, dass jemand immer nach eurer Website zuerst sucht und dann nach Varianten innerhalb der Website sucht, dann denkt mir, dass es vielleicht Sinn macht, ein Sight Link Suchfeld zu zeigen. Zum Beispiel mit YouTube oder den meisten anderen Videosites, viele suchen vielleicht nach YouTube, aber sie wollen nicht auf die YouTube-Homepage gehen, sondern sie wollen bestimmte Videos anschauen. Und dann macht es vielleicht Sinn, dass wenn jemand nach YouTube sucht auf der Video Website, dass wir sagen, was auf YouTube oder was auf dieser Video Website wollte eigentlich sehen und da macht es dann vielleicht eher Sinn, ein Sight Link Suchfeld zu zeigen. Aber das ist nicht ein Qualitätszeichen, das ist nicht etwas, was man quasi erreichen muss, sondern es ist wirklich einfach, wir versuchen zu erkennen, wann macht das Sinn und wann macht das weniger Sinn und das kann sich im Laufe der Zeit auch verändern. Ganz viele Fragen über Ranking und Search Console von Hans. Mindestens die erste Rezepturale in den Rezeptkarussells wird unter der Box auch noch einmal als ganz normaler organischer Treffer angezeigt. Wie wird das in Search Console gewertet? Wir haben für Search Console eine relativ ausführliche Hilfeseite, die in diese ganzen Varianten von quasi Elementen und mehrere Suchergebnisse auf einer Seite eingeht. Ich würde das auf jeden Fall mal anschauen. Grundsätzlich ist es so, dass wenn mehrere Seiten von einer Website in den Suchergebnissen dargestellt werden, dann wird in Search Console das Element mit dem höchsten Ranking quasi gezählt und das wird dann für den Durchschnitt verwendet. Das heißt, wenn ich 2, 3 Elemente habe auf einer Suchergebnisse Seite von der gleichen Website, dann nehmen wir das höchste Element und nehmen das dann für den Schnitt für die Website insgesamt, für diese Suchanfrage. Wenn man das pro URL anschaut, dann nehmen wir natürlich das Ranking von dieser einzelnen URL Das heißt, es ist ein bisschen unterschiedlich, ob man das pro Suchanfrage oder Website anschaut oder ob man das pro URL anschaut. Wenn man das, wie gesagt, auf der pro Suchanfrage oder pro Domain Sicht anschaut, dann nehmen wir den höchsten Punkt. Pro URL trifft natürlich die einzelnen URL entsprechend dazu. Für die Position innerhalb der Rezept-Carousel gelten da die gleichen Ranking-Faktoren, wie in der organischen Suche. Ich glaube, das hängt ein bisschen davon ab vom Carousel, wie das gehandhabt wird. Es muss nicht unbedingt das gleiche Ranking sein, wie in der normalen organischen Suche. Das heißt, in diesen Carousels können unter Umständen andere Kriterien auch relevant sein für das Ranking innerhalb von Carousel ein bisschen anders haben. Gibt es spezielle Faktoren welche die Reihenfolge der Rezepte innerhalb des Carousels beeinflussen haben für sich aus meiner Sicht nicht spezielles, was man da erwähnen könnte aus unserer Seite. Noch mehr Rezepte. Wie wertet Google in der Search Console bei Rezepten die Rich Cards in den Rezept Carousels. Auf dem Desktop werden 3 auf dem Smartphone 4 Rezepte auf dem Anfang der Suchergebnisse angezeigt. Werte Google dann zum Beispiel auf der Desktop alle 3 Rezepte in der Box aus Platz 1. Gibt es bei den Auswertungen in der Search Console ein Unterschied ob man innerhalb der Box auf Platz 1, 2 oder 3 ist. Das ist auch in diesem Hilfe-Dokument dabei. Da ist es so dass wenn die Elemente nebeneinander dargestellt werden in einem Block, dann sehen wir das als ein Element. Das heißt, wenn dieser Block an 2. Position ist und da sind 3 verschiedene Rezepte in diesem Carousel dabei dann sehen wir alle 3 von diesen Rezepten als Position 2 in Search Console. Das Ganze mit Position zahlen und wie man das zusammenstellt ist immer ein bisschen kompliziert. Ich denke wichtig ist dass man einigermaßen weiß wie das gerechnet wird. Aber es gibt natürlich so viele verschiedene Suchvarianten und Suchelemente, dass es da schwierig ist zu sagen was diese Position genau heißt. Da würde ich einfach immer was das für meine Website bedeutet wenn sie so dargestellt wird in den Suchergebnissen. Neben den Host Carousels gibt es bei Google 2 unterschiedliche Boxen mit Rich Recipe, Rich Cards von Gemission Anbietern. Hat Google dafür zu unterscheiden bestimmten Namen wie Carousel oder Gallery. Was sind da die wichtigsten Unterschiede? Der Twitter Link funktioniert da nicht. Aber ich glaube ich habe das bei dir auch auf Twitter gesehen. Soweit ich weiß haben wir dann nicht spezielle Namen für diese Carousels. In den meisten Fällen ist es so dass da einzelne Teams an diesen Varianten arbeiten und diese Sachen können sich im Laufe der Zeit leicht verändern und es kann sein, dass wir da 2 Varianten in eine Variante zusammenklappen oder dass wir mal eine Variante auseinander nehmen und in vielen Fällen machen wir das dann extra so dass wir da keine genauen Namen haben für diese Elemente, weil sie sich ja noch ein bisschen verändern können. Von dem her haben wir eigentlich nicht genaue Kennzeichnungen, wo wir sagen würden diese Variante mit dieser Pixel-Struktur bedeutet das und diese Variante hat einen anderen Namen sondern es kann relativ fließend sein und das kann sich relativ im Laufe der Zeit verändern. Wo wir eben schon bei der Search Console waren ich hatte dazu eine Frage mit den Mobile Usability oder Nutzerfreundlichkeit auf Mobilgerätenproblemen ich habe die Frage auch da reingeschrieben und es ist so, es ist ein Nachrichtenkunde das sind jetzt die Zahl über 56.000 gewachsen und Content-Wided Screen und wenn man dann die Einstellungen die dort bemängelt werden, dann kommt man ja wenn man das dann live testet auf den separaten Mobile Friendly Test und dieser Mobile Friendly Test gibt die gegenteilige Aussage, nämlich alles okay und dann natürlich versuche ich Validate Fix zu machen und der kommt nur negativ zurück und sagt sorry alles kaputt und bitte reparieren die Frage ist nur welchem Tool vertraut man jetzt oder welches Tool soll ich ignorieren und woher kommt das eine sagt es ist Mobile Friendly das andere sagt es ist nicht Mobile Friendly ja gerade bei Mobile Friendly Test ist es so, dass es sehr stark davon abhängt vom Rendering das heißt wenn beim Rendering irgendetwas leicht schief geht dann kann es sein, dass wir ein Rendering für diesen Test-Durchlauf ohne z.B. CSS oder ohne allen JavaScript machen und dann kann es sein dass wir beim testen das ist nicht so Mobile Friendly wie wir dachten meinst du jetzt den Mobile Friendly Test innerhalb der Search Console oder außerhalb des Search Console ja, innerhalb der Search Console innerhalb, also der innerhalb ist sensibel irgendwie genau, das heißt wenn wir versuchen natürlich einen großen Teil von den URLs der Website zu testen und das geht nur wenn man das möglichst schnell macht und dann kann es passieren dass solche Sachen auftreten mit einzelnen URLs manuell testet im manuellen Tester ist es so, dass wir da ein bisschen mehr Zeit lassen und ein bisschen eher darauf achten dass wir alle Inhaltsstücke auch mal sauber rendering können und wenn das da gut aussieht, dann ist es eigentlich okay das heißt, gerade im Bereich von Mobile Usability Test wenn ihr seht dass da eine Anzahl Fehler dargestellt werden in Search Console und ein Teil davon manuell testet und das kommt alles zurück dass es okay ist, dann würde ich diese Fehler ignorieren und kann man, die Schwierigkeit ist hier, dass in der Search Console man kann ja den gut, der gerendert ist, nicht sehen weil das nur beim Live Test dargestellt wird es würde mich natürlich trotzdem interessieren woran jetzt dieser Search Console Mobile Test gescheitert ist und da könnte ein kleines Issue sein da irgendwo, gibt es da eine Möglichkeit das zu simulieren irgendwie also einen sensiblen Mobile Friendly Test und sich dann den Code anzugucken Glaube nicht so viel ich weiß sieht man, ist das wirklich nur im Live Test aber gerade mit dem Mobile Usability Report da bist du nicht der Einzige, der damit Mühe hat das ist etwas, wo wir momentan arbeiten sagen wir mal stabilere Fehler auch wirklich bringen können nicht, dass man da die Einzigen testen muss und dann überlegen muss soll ich jetzt diese 7000 Fehler ignorieren oder muss ich da wirklich etwas machen oder einfach zeigen, woran es gelegen hat das wäre schon, wenn man dann den getesteten Code also den HTML sehen würde, dann würde man ja sehen, okay das ist nicht geladen wobei, was ich nicht verstehe, wie du das sagst es sagt mir ja hier zum Beispiel der Content ist wider than Screen oder sowas ich kann das rein technisch nicht nachproduzieren warum, wenn manche Ressourcen nicht geladen werden konnten bei dem schnellen Rendering warum dann ein Content breiter sein könnte als der Screen, wie kann denn das passieren damit es ja echt nicht nee, ich hab gar nicht kann es nicht ableiten ich weiß jetzt nicht genau wie das sein kann aber was zum Beispiel passieren kann ist, wenn man CSS nicht laden können und ihr Bilder eingebunden hat wenn ihr die CSS an die Bildschirmbreite angepasst werden dann kann es schon sein dass wir diese Bilder quasi in hohen Auflösungen eingeladen haben für das Rendering und dass dann das ganze Layout sich verzieht okay, na gut das kann man natürlich nicht ahnen, wenn man nicht weiß was für ein Code geladen ist man sieht ja auch in dieser Variante in dem schnellen Test in der Search Console nicht welche Ressourcen nicht geladen wurden in der langsamen Version 7 und das ja auch das heißt ich kann meinen Kunden sagen wir können diese 56.000 Fehler ignorieren okay, alles klar, vielen Dank okay, dann ist glaube ich noch etwas was mit Rendering ein bisschen zu tun hat wir haben begonnen Produkte auf Produktlisten in der Shopseite mit JSON-LD auszuzeichnen in Search Console laufen nun einige Warnungen für fehlende Felder wie Price Valid and Tell auf was uns Spannendes dabei aufgefallen ist dass Pro Warnung jede URL mit genau 6 Produkten Artikelnamen aufgeführt wird, obwohl es deutlich mehr Produkte auf der liste gibt die ersten 6 Produkte werden per JavaScript Onload geladen, inklusive JSON-LD alle weiteren Produkte werden per Lazy Loading geladen, wenn sie im Viewport sichtbar werden wir dachten, dass Google mit einem sehr großen Viewport die Seiten rendert so dass bei uns initial ein Onload alle Produkten gerendert werden müssten hast du eine Erklärung dafür dass im Search Console Report nur die ersten 6 Produkte angezeigt und deshalb vermeintlich auch nur diese gerendert werden ich weiß nicht wie das in diesem Report bei euch aussieht von dem her ist es ein bisschen schwierig zu schätzen aber grundsätzlich scheint es jetzt so zu sein dass wir die Seiten rendern damit dass wir diesen JSON-LD auch sehen können dass wir diese Produkte sehen können ich vermute, dass wir da beim Rendering irgendwie euer Lazy Loading nicht richtig aktivieren was ich da kontrollieren würde ist zum Beispiel mit dem URL Inspection Tool die Seiten direkt dort zu rendern wahrscheinlich mit der mobilen Variante meisten Websites sind ja jetzt auf den Mobile First Indexing umgestellt d.h. in der mobilen Variante würde ich das testen und da würde ich dann schauen in der gerenderten html Version ob da wirklich nur die ersten 6 Produkte sind oder ob auch wirklich alle Produkte nachgeladen werden oder ob entsprechend mehr als die ersten 6 Produkte nachgeladen werden das sollte sich auch so testen lassen es gibt eben verschiedene Arten wie man Lazy Loading machen kann und je nachdem kann es sein dass Googlebot beim Laden dieser Seite Mühe hat mit der Variante die ihr da in diesem Moment eingebunden habt wir haben auch eine Dokumentationsheite über Lazy Loading wo man ein bisschen nachschauen kann was wir empfehlen würden in der Regel sehen wir Lazy Loading in den meisten Fällen eher als etwas an mit Bildern entsprechend auftritt dass wir die Bilder nicht sauber eingebunden finden dass wir die dann auch nicht sauber für die Bildersuche weiterverwenden können für Produktlisten gerade wenn man sehr viele Produkten hat würde ich trotzdem schauen dass man irgendeine Art Paginierung einführen kann damit wir wirklich zu all diesen Produkten auch kommen können was man natürlich aufmachen kann ist es man sagen kann die Produkte sind ineinander sag ich mal untereinander auch sauber verlinkt sodass wenn wir die ersten 6 Produkte gefunden haben dass wir von dort aus entsprechend die anderen Kategorien finden oder dass man von dort aus wirklich alle anderen Produkte von dieser Art auch trotzdem entdecken können ohne dass wir alle Produkte in einer Liste auch entsprechend laden müssen aber das sind verschiedene Varianten die man da angehen kann manchmal ist es nicht so wahnsinnig einfach das ganze durchzugehen aber ich würde wirklich mit mit dem Testen der Rendering erst mal anfangen schauen was effektiv gerendet wird was Googlebot effektiv sieht und dann überlegen wie ihr das jetzt integriert habt in der Website ob Googlebot wirklich alle Varianten auch sauber auffinden kann und diese Seiten auch indexieren kann oft kann man das auch in der Serverlog-Datei nachvollziehen dass man da sieht werden alle meine Produktvarianten effektiv auch gecrawlt und wenn sie schon mal gecrawlt werden dann ist das schon mal ein relativ starkes Zeichen das wahrscheinlich ist das einigermaßen okay vielleicht kann man da das ein oder andere noch optimieren aber auf jeden Fall ist es nicht so kritisch gewisse Produkte gar nicht auffindbar sind okay, danke dir John für die ausführliche Antwort ich hatte es jetzt gerade nochmal an die Frage von David auch erinnert weil ja auch da für den Mobile Friendly Test in der Search Console ein bisschen anfälliger kann das da auch der Fall sein also du hast im Anfang gesagt du weißt nicht genau wie das bei uns in der Search Console aussieht es ist wirklich so, dass für jede URL die ersten 6 Produkte nur angezeigt werden und es sind aber eigentlich mehr und jetzt wäre halt die These vielleicht auch da ein bisschen anfälliger dass da das Rendering nicht so komplett durchführt, wie das eigentlich sonst der Fall ist, weil wie du es gesagt hast in den Logs und Inspection Tools sieht es eigentlich sehr gut aus wir hatten immer die Annahme Rendering funktioniert bei uns mit Lazy Loading nur mit diesen JSON-LD-Elementen die wir jetzt hinzugefügt haben, da ist es uns dann eben aufgefallen und wir haben uns gewundert, warum da nur ein sehr kleiner Teil der Produktliste jetzt über Search Console berichtet wird die meisten anderen Funktionen in Search Console werden direkt an die indexierten Daten gebunden das heißt wenn die effektiven nicht dargestellt werden in diesem Report die einzige andere Variante die ich mir vorstellen könnte ist dass im Report vielleicht nur 6 Beispiele dargestellt werden weiß ich jetzt nicht auswendig ob das der Fall ist, es wäre ein bisschen komischer Zufall, aber wäre auch eine Variante aber wenn da effektiv nur diese 6 URLs gezeigt werden ist es wahrscheinlich schon so, dass wir nur diese Sehen für die Indexierung Das wäre ja schon ein krasses Problem weil das hätten wir so jetzt nicht erwartet dass es dann ein Problem ist und wie gesagt in den Logs sehen wir auch dass mehr Produktkacheln von Google-Boot auch gerendert und abgerufen werden dass dann so das Gegenbeispiel haben, wo wir eigentlich sagen dann scheint es ja doch ganz in Ordnung zu sein aber müsste man wahrscheinlich noch mal im Detail technisch vielleicht gucken wie da ein Lazy Loading bei uns aussieht vielleicht finden wir auch die Links Ja, ich weiß nicht ob das ein Problem ist das ist im Head mit drin ist das ein Problem? Also es kommt wirklich beim Lazy Loading im Head ein bisschen gar, oder? Das ist ideal Dann schauen wir nochmal Gute Danke dir Schon so ähnlich ist auch das Problem dass der Florian Elbers unten beschrieben hat das habe ich auch, dass Seiten indiziert werden von Google und dann nach einer Weile werden die von Grün wieder aufgecrawlt zurzeit nicht indexiert, zurückgestuft kennst du das Problem? Ich kenne das jetzt nicht als ein Problem in Search Console aber grundsätzlich kann es schon sein dass wir Seiten erstmal indexieren und dann später denken vielleicht müssten wir die gar nicht so indexieren von dem her was ich da macht es mich ein bisschen stützig weil ich jetzt nicht weiß ob das Problem ist, dass wir die Seiten nicht mehr indexieren das wäre aus meiner Sicht an für sich normal, dass wir manchmal Sachen indexieren und dann nachher denken wir brauchen das eigentlich doch nicht oder ob diese Seiten effektiv indexiert sind aber einfach in Search Console nicht das indexiert dargestellt werden das wäre aus meiner Sicht eher ein Problem Das habe ich tatsächlich auch ich habe jetzt in letzten Wochen das nicht mehr geprüft aber ich hatte da 100.000 von URLs die zurzeit nicht indexiert sind gecrawlt aber nicht indexiert das war eine Punktuell-Testung sind viele von denen tatsächlich doch noch ein Google Index Okay Wenn du mir ein paar Beispiele schicken könnt das wäre ich dir extrem dankbar Okay, mache ich gerne Okay, gut Schauen wir das mal an Dann zu SightSpeed Für den Ranking Faktor werden Felddaten sowie Labdaten relevant Hat das ein Grund warum der Search Console Speed Report nur auf Felddaten basiert habt ihr Pläne daran etwas zu ändern und ist das aus deiner Sicht überhaupt ein Problem Wir verwenden effektiv für das Ranking verwenden wir schon die Felddaten und die Labdaten, also die Testdaten wenn wir jetzt einzelne URLs testen In Search Console haben wir uns eigentlich direkt dafür entschlossen die Felddaten darzustellen das heißt die Daten aus dem Chrome User Experience Report die aufgrund von normalen Benutzerdaten an und für sich bestehen Ich weiß jetzt allerdings nicht genau warum wir das so gemacht haben aber das was wir einfach gesehen haben gerade beim Speed Report ist es so, dass es extrem kompliziert ist ein Speed Report aufzustellen der auch effektiv brauchbar ist und ich könnte mir vorstellen, dass das Team sich dafür entschieden hat erst einmal die einfache Variante zu machen dass wir da wirklich nur die Felddaten dazunehmen Vielleicht kommt das dann später irgendwann, dass wir denken dass entsprechend auch ein bisschen erweitern für die ganzen Labdaten das heißt quasi die einzelnen Testungen, dass theoretisch durchgeht Ich weiß allerdings nicht was da die genauen Pläne sind aber das ganze mit dem Speed Report ich weiß nicht, das haben wir rund um Google I.O. in Mai irgendwann mal gedacht wir könnten das herausbringen und das hat extrem lange gebraucht bis wir da das so weit hinkriegen konnten dass es wirklich einigermaßen auch etwas ist womit Websites auch arbeiten können Ich habe neuerdings ein Published and Last Modified Datum und im Markup obwohl ich kein Blog und keinerlei zeitsensitive Branchen wie z.B. News oder Technik habe erscheint nun das Published Datum in den Suchergebnissen da es dort bei Evergreen Themen eigentlich keinen Mehrwert für User hat und Platz wegnimmt möchte ich die Datumsangaben wieder löschen spricht etwas dagegen oder sollte ich aus Sicht von Google die Datümer doch lieber belassen, z.B. für EAT e.g. du kannst das reinnehmen oder rausnehmen wie du willst das spielt da eigentlich keine große Rolle aus unserer Sicht wir versuchen natürlich festzustellen welches Datum da relevant ist unter Umständen zeigen wir das dann in den Suchergebnissen wenn du möchtest dass das Datum erscheint welches du selber bestimmst welches auch vielleicht sichtbar ist dass wir das in Markup definitiv drin lassen wenn es dir soweit egal ist kannst du das natürlich auch rausnehmen es ist nicht so dass wir da ein Trustfaktor haben würden wo wir sagen würden wenn ein Datum vorhanden ist in Markup dann ist diese Seite wichtiger bin ich zu hören ja also ich habe ja nichts gegen diese beiden Datumsangaben also ich finde das durchaus sympathisch wenn das vorhanden ist wenn man das lesen kann okay der Artikel auch wenn er schon ziemlich alt ist der ist irgendwann mal veröffentlicht worden vor so und so vielen Jahren und er ist zuletzt aktualisiert worden zum so und so Füllten also mir ist das eigentlich durchaus sympathisch nur wusste ich nicht dass das eines dieser beiden Datum und zwar leider auch das Publis-Datum das bei mir teilweise auch schon oft sehr sehr alt ist dann im Snippet erscheint das wusste ich nicht und dort ja was macht das Datum dort ist es dort wirklich sinnvoll bringt es einen großen Mehrwert für User wenn er jetzt bei einem Evergreen Thema weiß dass wie gesagt nichts mit Technik oder News oder so zu tun hat dass der Artikel schon 2010 erstmals veröffentlicht worden ist hilft es der Klickrate ich glaube in Zweibesfall wahrscheinlich eher nicht eher dachte ich mir naja also momentan habe ich es in beiden sowohl im Markup als auch auf der Seite und ich würde es dann halt jetzt mal im ersten Schritt probieren und nur im Markup löschen und schauen ob es dann immer noch im Snippet erscheint und wenn es dann immer noch im Snippet erscheint würde ich es dann halt auch auf der Seite löschen beziehungsweise vielleicht das Datum nicht ausformuliert haben sondern nur schreiben irgendwie vermute dann jetzt euer Algorithmus nicht mehr aufnehmen ich könnte mir vorstellen dass das schwierig ist also nicht schwierig in dem Sinn dass man das nicht machen kann aber ich könnte mir vorstellen dass unsere Algorithmen vielleicht im Moment eher denken gut das Datum ist auf der Seite und den Markup vielleicht ist das Wichtiger vielleicht sollten wir das darstellen aber ich weiß nicht ob man davon das Datum aus dem Markup herausnimmt dass wir dann das nicht mehr im Snippet zeigen würden und auch wenn man das Datum jetzt von der Seite vom Inhalt rausnehmen würde ob wir dann sagen würden gut wir wissen nicht wann das veröffentlicht wurde weil wir wissen ja trotzdem ungefähr wann das veröffentlicht wurde was damit zusammenhängt von dem her könnte ich mir vorstellen dass es unter Umständen schwierig ist sag ich mal mit relativ einfachen Mitteln dieses Datum einfach zum Verschwinden zu bringen ich könnte mir auch vorstellen dass wir einfach längerfristig sagen gut das Datum ist jetzt nicht so relevant dass auch wenn das im Markup vorhanden ist dass wir das dann nicht darstellen von dem her sehe ich das ein bisschen als etwas ein bisschen zweifelhaft an ob man das direkt so 1 zu 1 wieder verschwinden lassen kann ihr wisst das Datum jetzt schon ich hab das ja schon zu Kenntnis genommen und damit ist das sozusagen eine gewisse Verbindlichkeit die ihr nicht so ohne weiter ist wie aufgeben wollt wir wissen natürlich auch wir können das Datum auch quasi erahnen auch wenn das nicht direkt auf der Seite erwähnt wird auch wenn das von Anfang an nicht direkt dabei ist weil irgendwann sehen wir diese Seite zum ersten Mal irgendwann sehen wir die links zu dieser Seite zum ersten Mal und dann können wir von dort an ein bisschen verfolgen ja verändert sich diese Seite oder nicht und da kann man ein bisschen schätzen welches Datum relevant wäre auch wenn gar kein Datum erwähnt wird das Markup hilft uns dann vor allem wenn wir unsicher sind ein Datum mit dieser Seite quasi zusammen erwähnen möchten aber vielleicht wählen wir irgendwie das falsche Datum vielleicht nehmen wir das Datum wenn wir diese Seite zum ersten Mal gesehen haben aber eigentlich besteht diese Seite schon jahrelang früher und Google hat sie einfach nicht entdeckt dann kann man mit dem Markup das natürlich angeben und sagen das ist effektiv das Datum was für mich relevant ist aber das umgekehrte dass man sagt ich möchte das gar kein Datum mit dieser Seite verbunden ist das kann man eben nicht so einfach angeben also mir geht es nicht darum dass kein Datum mit der Seite verbunden ist sondern ob es im Snippet erscheint darum geht es letztendlich aber ich kann das ja nicht anders beeinflussen ich kann ja nicht irgendwie in das Search Console die Wahl treffen und irgendwo anklicken und sagen bitte das Datum nicht nicht erscheinen lassen gibt es ja keine Möglichkeit was man machen kann ist mit dem No Snippet mit der Tag arbeiten aber das ist ein relativ großer Hammer das ist natürlich der ganze Snippet weg ne das das ist ein bisschen extrem ja also an deiner Stelle würde ich das einfach mal ausprobieren mal den Markup wegnehmen eine gewisse Zeit lassen bis ich das wieder einpendeln kann und dann schauen wie die Suchergebnisse aussehen und dass man da so Schritt für Schritt vorwärts macht wenn du später merkst dass quasi ohne diesen Markup dass das Datum immer noch dargestellt wird welch froh wenn du mir die Suchern frage und die URL mal zuschicken kannst dann kann ich das direkt mit dem Team hier auch anschauen weil das Team welches an diesen ganzen Datumsarten arbeitet ist auch hier in Zürich da geht das manchmal relativ gut ah ok, alles klar noch eine Sache zu dem JSON LD Skript das ich direkt bei mir auf der HTML Seite habe ist das für euch unter Umständen schwierig wenn ich diesen JSON LD Skript noch in einem Difftag drin habe? Nein solange das gültiger JSON LD ist das überhaupt kein Problem wo das integriert ist ok alles klar, danke du hattest noch als nächstes die Frage mit strukturierten Daten von AMP Artikeln und Non-AMP Artikeln das ist nicht ganz verstanden wie hast du das gemeint? also ich habe Non-AMP Artikel und entsprechende strukturierte Daten und die Seiten sind auch alle indexiert worden und jetzt kann man ja in das Search Console sich da sozusagen ein Feedback anschauen was genau jetzt insbesondere von den Dingen die auch in den Serbs erscheinen was ihr da an strukturierten Daten erkannt habt, gelesen habt was ihr da vielleicht an einzelnen Attributen dann vermisst oder nicht vermisst was vollständig ist oder nicht vollständig ist, da kriegt man ja Feedback in das Search Console und bisher sehe ich da ist jetzt 10 Tage her sehe ich da noch gar nichts also redet ein Feedback über AMP Artikeln noch über Non-AMP Artikeln weil ich mich halt gefragt habe bei dem Testing Tool von euch da wird ja immer von AMP Artikeln ausgegangen ob es vielleicht sein kann dass auch dieses Feedback in das Search Console nur zu AMP Artikeln dort erfolgt nicht zu Non-AMP Artikeln oder woran es liegt, dass bisher da gar nichts erscheint dazu das sollte eigentlich auch für normale HTML-Seiten entsprechend gelten was einfach ist mit dem aggregierten Feed Informationen in Search Console aus der einen Seite wird das aggregiert über die geindexierten Daten das heißt wenn diese Seiten noch nicht so soweit indexiert sind für deine Website dann zeigen wir da vielleicht noch nichts an bei 10 Tagen ist das wahrscheinlich gerade an dem Wert wo ich sage wir sollten das langsam eigentlich erkennen ich vermute wenn du da eine Woche oder zwei warten dann bist du da ziemlich sicher ob das erkannt wird oder nicht was da ist in Search Console sind diese besonderen Reports effektiv sehr genau auf ein Element bezogen das heißt es ist nicht so dass wir dann allgemein strukturierten Daten quasi Report haben sondern wir zeigen da wirklich gezielt für diese Elemente zeigen wir die Informationen in diesem Report an das heißt zum Beispiel wenn da ich weiß nicht nur ein Datum dabei ist könnte ich mir vorstellen dass wir da kein besonderes Report haben wo das sichtbar wäre hingegen wenn man jetzt Rezepte integriert dann gibt es da ein Recipe Report wo wir diese Rezepte entsprechend darstellen würden da hängt es ein bisschen davon ab was du genau da implementiert hast aber ich würde da vielleicht noch eine Woche oder zwei warten ob das jetzt effektiv noch kommt oder ob da vielleicht das einfach in eine andere Art von strukturierten Daten sind die nicht direkt in Search Console dargestellt werden ok danke gerne ok, zeitlich sind wir bald am Ende von dem her möchte ich das vielleicht mal für euch noch eröffnen wenn ihr irgendwelche weiteren Fragen oder Kommentare habt ja und man hört mich folgendes wir haben jetzt seit Mitte Oktober haben wir das Problem dass Seiten bei uns nicht gekrolt weil ich hatte das auch in den Kommentaren schon geschrieben und wir können gar nicht nachvollziehen woran das liegt weil eine Seite mit sogar ähnliche Seite, wir haben halt so Suchergebnisse und die werden dann so gekrolt werden die eine Seite mit weniger Suchergebnissen wurde gekrolt die andere also alle anderen werden nicht gekrolt und eine andere Seite die zum Beispiel nicht gekrolt worden ist hatte mehr Suchergebnisse und für uns ist nicht klar wieso das als Duplicate Content beziehungsweise Duplicate Content wird es another Canonical eingestuft wird immer zur Startseite das geht nicht ganz hervor ok, das war die 3D Find Webseite genau ich habe das vorher kurz angeschaut und was da auf unserer Seite passiert ist dass wir quasi diesen URL muss da erkennen und das Gefühl haben dass alles was mit dem Fragezeichen beginnt an und für sich auf die Startseite zurückgeklappt werden kann und einerseits ist das wahrscheinlich ein Fehler auf unserer Seite, dass wir das so machen weil die Beispiele die du da gezeigt hast die sind effektiv so dass da auch andere Inhalte dabei sind andererseits ist das etwas was unsere Systeme da automatisch erkannt haben das heißt, wir haben wahrscheinlich sehr viele Links auf diese Varianten gesehen wir haben viele von diesen Varianten gekrolt und haben gesehen dass die Inhalte effektiv immer gleich sind das heißt was ich da vielleicht mal kontrollieren würde ist gerade innerhalb der Webseite wenn du die Webseite selber crawls mit Screaming Frog ein Crawler die man selber verwenden kann ob da sehr viele Seiten gefunden werden mit Parameter von der Homepage aus die sehr ähnlich sind oder die immer auf die Homepage zurück weiterleiten oder die die Inhalte von der Homepage wieder zeigen und dann würde ich schauen dass man das ein bisschen verbessern kann so dass wenn Google URLs findet innerhalb der Webseite die zu diesen Parameters Seiten gehen das wirklich direkt immer klar ist die Seiten sind gültig das sind Seiten die können so separat indexiert werden okay, wenn ich da jetzt noch ergänzt etwas zu fragen darf wir haben eine JavaScript-Seite das heißt, wir haben keine echten Links überhaupt da drauf das heißt, wenn man da einklickt dann wird das quasi nur dann gerendert die URL angepasst und so weiter wir sollten also das wenn ich das richtig verständen hab eher zu echten URLs ändern die die anklickbar sind oder wie darf ich das verstehen ähm also zu Atex quasi kann man machen kann man sicher machen ich denke es gibt da verschiedene Varianten die man das angehen kann es ist schwierig zu sagen welche Variante jetzt die einfachste oder die schnellste Variante für euch wäre eben einerseits denke ich mal das Grundproblem dass wir viele URLs mit Parameter empfinden zurück zur Startseite gehen und die Startseite wieder darstellen das ist mal die eine Sache was man da vielleicht machen könnte ist schauen ob man da eine 404 zurückgeben kann für die nicht gültigen Parameter das würde uns sicher helfen zu unterscheiden es gibt gültige Seiten mit Parameter und es gibt ungültige Seiten dass man da sauber unterscheiden könnte was was ich vielleicht an deiner Stelle machen würde um das ein bisschen schneller werden zu lassen ist dass man da, zeig ich mal einfach ein Unterverzeichnis einrichtet wo man diese ganzen Suchanfragen hineinlegt das heißt dass sie nicht per Definition schon alle mit der Startseite zusammengeklappt werden sondern dass ich zum Beispiel die Homepage habe und dass ich dann ein Unterverzeichnungsstrich suche oder wie auch immer und dass dann dort die ganzen Parameterversionen nur kurz zur Ergänzung noch also das heißt wenn ich jetzt zum Beispiel sage ich habe jetzt 3DFind.it also 3DFind.it slash suche und dann mit Fragezeichen Suchparameter dann wäre das kein Problem dann wäre das weniger ein Problem dann ist es zumindest so dass die ganzen alten alten Strukturen da keine Rolle mehr spielen oder dann müssen wir diese Struktur erstmal neu erkennen und wenn du dann schon von Anfang an dafür sorgst dass diese URLs sauber aufgebaut sind dann ist das kein Problem Okay, vielen Dank Kannst du dir die Untersuchung von Search Engine Journal von vorgestern oder so dass JavaScript Indexing immer noch ein Problem ist dass es starke Delays gibt beim Indexing Wir haben das angeschaut und zumindest was das Team dazu meint Also einerseits dass wir nicht genau wissen was da wirklich getestet wurde und andererseits hat es nicht mit dem über einen stimmt was wir sehen beim testen und von dem her ist es ein bisschen schwierig aber ich glaube Bartosz kommt zum Webmaster Conference nach Zürich und da wollte Martin das dann auch mal direkt mit ihm besprechen Ah cool Ja Könnte ich noch eine Frage stellen? Ja, direkt los Du hast das Side Maps Ich habe die aus der GSC gelöscht aber Google Word greift immer noch drauf zu verarbeitet ihr die dann oder was macht ihr damit? Wahrscheinlich schon Wenn es noch Side Maps dabei sind dann versuchen wir die noch zu verarbeiten aber wenn du 4.04 zurück gibst dann geht es einfach ich weiß nicht in den Monat oder 2 und dann lässt das Side Maps System die an für sich ganz gehen Also GSC löschen reicht nicht aus Okay, alles klar, danke Super Dann machen wir vielleicht hier eine Pause Vielen Dank fürs kommen Vielen Dank für die vielen Fragen und dann sehen wir uns vielleicht in einem der nächsten Hangouts wieder Tschüss allerseits Tschüss