 Okay, willkommen beim heutigen Google Webmaster Essentials-Sprechstunden-Hangout. Mein Name ist Johannes Müller, ich bin Webmaster Trends Analyst hier bei Google in der Schweiz. Das heißt, ein Teil von dem, was wir machen, ist mit Webmastern und Publishern zu sprechen, wie jetzt hier im Hangout und natürlich auch solche, die schon Fragen vorher eingereicht haben. Es sind ja alle möglichen Fragen schon mal eingereicht worden, aber wenn einer von euch will, könnt ihr gerne auf die Hüfte fragen stellen. Ja, okay. Ihr könnt uns gerne durch euch zu Wort melden und falls irgendwas auftaucht von Fragen oder von den Antworten her, seid ihr gerne eingeladen. Und wieder haben meistens auch noch ein bisschen Zeit für weitere Fragen von euch. Okay, fangen wir mal hier an. Wäre das nicht besser nützlicher oder leichter verständlicher für User oder für das Ranking, wenn man zum Beispiel die dynamischen URLs und statische URLs ohne Parameter umwandelt. Ich habe vor einigen Jahren ein Blog-Poster gemacht über dynamische oder statische URLs und da war in erster Linie der Anstoß einerseits vom Indexing-Team, vom Crawling and Indexing-Team, dass wir einfach gesehen haben, dass sehr viele URLs umgeschrieben werden in einer Art, die das Crawling sehr negativ beeinflusst. Das heißt, zum Teil war es dann so, dass wir da die Keywords mit bloßem Kleinschreibung crawlen konnten oder dass die Reihenfolge der Wörter in der URL egal ist, oder dass da vielleicht sogar Session IDs in den Verzeichnismamen dabei sind. Und also gesagt machen wir es sehr schwierig für uns die Website zu crawlen. Ingegen, wenn diese Werte als Parameter übergeben werden, können unsere Systeme relativ schnell ausprobieren, welche Parameter funktionieren, welche sind relevant, welche Parameter kann man ignorieren. Die kann man dann auch mit dem Parameter-Tool in Search Console angeben, so dass das ganze Crawling und Indexing schon eine Stufe einfacher geht. Das heißt, aus unserer Sicht sind die beiden Arten von URLs an und für sich ähnlich bezüglich Ranking. Das heißt, wir haben da keinen großen Vorteil für die ein oder andere Arten. Wir sehen einfach, dass man viel weniger Fehler machen kann, wenn man mit Parameter arbeitet, als wenn man die Wörter direkt in die URL hineingibt. Das heißt, was ich da vorschlagen würde, ist, wenn man wirklich weiß, dass man das sauber implementieren kann, wenn man ein CMS hat, welches das sauber von Anfang an schon macht, wenn man den WordPress macht das zum Beispiel sehr gut, dann würde ich einfach mit den Wörtern in die URL arbeiten. Man ist ja dann einigermaßen sicher, dass das auch schon funktionieren wird. Wenn man hingegen nicht so sicher ist und selber etwas zusammenbauen möchte, dann würde ich eher mit Parametern arbeiten, zumindest am Anfang, dass man wirklich sicher ist, dass man das sauber implementieren kann, dass das sauber gecrawled und geindexed werden kann. Und wenn man jetzt die eine oder andere Art schon hat und eine andere Art umstellen möchte, dann würde ich mir überlegen, wie man das machen kann, dass man das wirklich auch längerfristig beibehalten kann. Weil mit der Umstellung von, sag ich mal, Parameter auf statisch aussehende URLs, gewinnt man anfühlt sich nicht viel in der Suche. Und die Umstellung selber ist hingegen problematisch. Es ist wie ein Side-Proof. Da müssen unsere Systeme erstmal die ganze neue Struktur neu erkennen und das gibt sicher, denke ich mal, für eine gewisse Zeit auch einen negativen Einfluss in der Suche, weil wir erstmal alles neu erkennen müssen, neu crawlen, neu indexieren müssen. Das heißt, für die Umstellung ist es eineseits negativ, nachher ist der Zustand etwa gleich. Das heißt, ich würde mir da wirklich zweimal überlegen, ob sich die Umstellung wirklich lohnt. Und wenn man die Umstellung wirklich machen möchte, überlegen, was ist eine Struktur, die man längerfristig beibehalten kann, so dass man nicht wieder eine Umstellung machen muss. Und dass man sich vielleicht auch eine Zeit aussucht, wenn man eine solche Umstellung macht, wo der Traffic von der Suche nicht so kritisch ist. Das heißt, wenn in der Suche für vielleicht einige Wochen vielleicht nicht so viel Traffic kommt, dass man da einfach eine Zeit ausgesucht hat, wo das nicht so problematisch ist. Wirkt sich eine schlechte User-Experience, Beispiel Nutzer benötigen länger um die gesuchten Links für Unterkategorien zu finden, negativ auf die Rankings aus und bekommen below-the-fold-Links weniger Gewichtung als links above-the-fold. In der Regel ist es so, dass wir User-Experience nicht recht messen können. Wir verwenden das schon in einigen Arten vielleicht um die Qualität der Website allgemein zu erkennen, bezüglich zum Beispiel diesen Kriterien, die wir für Panama veröffentlicht haben. Aber es ist nicht so, dass wir da, dass irgendwie aktiv zählen würden und dass wir das dann positiv oder negativ auf die Rankings auswirken würden. Bezüglich below-the-fold und above-the-fold die Gewichtung von links sollte da einigermaßen equivalent sein. So weit ich das weiß. Was vielleicht unterschiedlich wäre, ist, wenn Inhalte im Hauptbereich vom Content sind, bezüglich... Wie kann man das erklären? Wenn man eine Seite anschaut, gibt es ja ein Bereich der Seite, wo die Hauptinhalte wirklich sichtbar sind. Und der Rest ist quasi das, was immer wieder wiederholt ist auf der Website. Das heißt, die Headings, die Menustruktur, vielleicht der Footer von der Website. Wir nennen das alles Boilerplate, weil das immer wieder wiederholt wird. Und aus unserer Sicht, wenn wir gerade Inhalte anschauen, dann versuchen wir, die Inhalte, die im Hauptteil sind, ein bisschen stärker zu gewichten. Weil wir wissen, dass es jetzt wirklich vielleicht etwas Einmaliges auf dieser Seite, da müssen wir ein bisschen mehr Gewichtung verwenden. Und ähnlich wirkt sich das dann auch auf die Links aus. Das heißt, wenn die Links wirklich im Hauptteil von den Inhalten da sind, dann ist es für uns ein Zeichen, dass es wirklich Links sind, die zu diesem Inhalten gehören, die wir da vielleicht ein bisschen anders behandeln müssen als solche Links, die über die ganze Website hindurch immer wieder verwendet werden. Ein Beispiel für die 4-0-4-Thematik, das Search Console, es werden Seiten als 4-0-4 ausgewiesen, die wir bewusst offline stellen. Da es zum Beispiel Produkte sind, die wir nicht mehr im Programm haben. Das Komische ist, als Seiten, über die das Produkt angeblich noch verlinkt ist, werden die Produktergebungslisten angezeigt. Aus diesen verschwindet das Produkt, jedoch natürlich, wenn wir es offline stellen. Ja, wenn ihr Bewusstseiten aus der Website herausnimmt, dann ist 4-0-4 eigentlich der richtige Statuscode dafür. Das hilft uns, die Seiten dann auch wieder rauszunehmen aus dem Index und dass wir uns ein bisschen mehr auf den Rest der Website konzentrieren können, was euch natürlich dann auch zugute kommt. Und von dem her ist es eigentlich vollständig normal, dass wir solche URLs als 4-0-4-Fehler auflisten. Aus unserer Sicht bringen wir die Listen ja in erster Linie, damit ihr sieht, wo wir Fehler gefunden haben und wenn, wie ihr sagt, diese Fehler sind für mich okay, sie sind, habe ich bewusst so, dann ist das aus unserer Sicht okay. Es ist nicht so, dass wir eine Website negativ bewerten, die viele 4-0-4-Fehler haben. Wir nehmen einfach diese Seiten aus dem Index heraus, die halt 4-0-4 zurückgeben. Darf ich? Ich hatte leider technische Probleme und weiß nicht, ob meine Frage schon beantwortet wurde. Wegen der Seite, die bei der Infoabfrage die andere Domain anzeigt. Ja. Habt ihr die Frage schon beantwortet heute? Nein. Noch nicht. Okay. Kann ich Sie eingringen jetzt? Ja, klar. Super. Und zwar, es geht um die Domainhochsätzeinladungen.de und die Domainhochsätzeinladungen.cc. Da wurde ein Relaunch gemacht. Beide Domains zeigen den gleichen Inhalt an, aber die eine ist für den österreichischen Markt, die andere für den deutschen Markt und war schon seit vielen Jahren. Und jetzt ist das Problem, wenn man die Infohochsätzeinladungen.de abricht, wird die Hochsätzeinladungen.cc angezeigt und auch die Rankings haben enorm stark nachgelassen. Siehst du da etwas, was da speziell jetzt wäre? Weil wir haben jetzt schon mal alles durchgeschickt, aber wir haben nichts gesehen, was zeigen würde, was da wirklich ein großes Problem ist von der Seite? Ja. Ich habe das kurz bei uns vorher noch angeschaut. Und was da passiert, ist es wirklich, dass auf unserer Seite, wie ihr das Gefühl habt, das sind die gleichen Seiten und haben sie zusammengeklampft und haben die CC-Variante quasi als Canonical ausgewählt dafür. Normalerweise betrifft das eigentlich nur die URL, die gezeigt wird in den Zufergebnissen. Sollte eigentlich die Rankings nicht wirklich beeinflussen. Was natürlich in diesem Fall vielleicht ein bisschen speziell ist, ist, dass eine Seite ist natürlich.de und dann entsprechend mit dem Geotargeting für Deutschland vorgesehen und die andere CC. Und ich nehme an, in Search Console habt ihr angegeben für Österreich, oder? Ja. Und da sind jetzt quasi diese beiden Länder-Varianten zusammengeklappt worden, was aus meiner Sicht nicht ganz optimal ist. Und da muss ich mit dem Team nochmal das anschauen, was man da machen könnte, um das aufzuheben. Soweit ich das gesehen habe bei euch, ihr habt ja auch mit dem Atre-Flank selber gearbeitet. Und von dem her sehe ich da jetzt auf Anhieb nichts, was ihr da anders machen müsstet, um das zu beheben. Okay. Und tatsächlich, was man natürlich machen kann, ist das Versuchen zu vermeiden, in dem man wirklich schaut, dass die einzelnen Versionen wirklich unterschiedlich sind. Ich weiß nicht von den Inhalten her, wie unterschiedlich diese beiden Homepages sind. Das wäre vielleicht etwas, was man anschauen könnte, ob man da wirklich die Inhalte gezielter an die Länder anpassen kann, so dass unsere Systeme gar nicht das Gefühl haben, wir könnten identisch ertragen sein. Das Problem bei Österreich und Deutschland, in dem Segment ist, dass es keine Unterschiede gibt. Also schweiz schon, weil da haben wir ja das Vermeldungsfilet statt der Hochzeitskarte, aber in Österreich und Deutschland gibt es keinen Unterschied. Und die zwei Moments sind kulturell gewachsen, weil eben der deutsche Kunde nicht in Österreich bestellt. Okay. Ja. Also ich muss da auf jeden Fall mal nachfragen, bei einem Team, was man da auf unserer Seite machen könnte, um das ein bisschen aufzuheben. Grundsätzlich, was vielleicht noch dazukommt, ist, dass in der Regel nicht pro Domain ist, sondern einfach pro Seite. Bei euch ist es natürlich auch auf die Homepage, wo wahrscheinlich der Meisterverkehr eh hingehen würde. Und von dem her ändert das nicht wahnsinnig viel, aber es ist allen an und für sich pro Seite. Aber ich schau mit dem Team das mal an, ob es da irgendwas ist, was man da auf unserer Seite einfach machen könnte, um das wirklich sauber zu treffen. Vielen Dank. Okay. Dann gehen wir mit den Fragen mal weiter. Google hat letztes Jahr angekündigt, das mobile Site mit Interstitials, bei denen der Content für die User nicht direkt zugänglich ist, ab dem 10. Januar ein Malos in den Rankings erhalten können. Kannst du uns da zwar ein Update geben. Ja, das ist allen für sich jetzt passiert. Das war, ich denke, in den letzten paar Tagen ist das ausgerollt. Es sollte eigentlich jetzt langsam überall so aktiv sein, dass das wirklich für diese Websites entsprechend so gilt. Wie lang dauert es bis gelöschte URLs aus dem Index verschwinden, wenn Googlebot beim Aufruf der URL 410 als Status erhält, Tage, Wochen oder Monate? Ja, Tage, Wochen oder Monate. Ungefähr in dieser Reihenfolge. Es ist so, dass wenn eine Seite ein 404 oder 410 zurückgibt oder ein Robotsnow Index hat, dann müssen wir diese Seiten zuerst einmal crawlen, damit wir wirklich wissen, dass dieser Status jetzt da sich so entsprechend verändert hat. Und wenn wir sie gecrawled haben, können wir das natürlich dann berücksichtigen. Die Schwierigkeit ist, dass wir natürlich die Seiten nicht alle mit der gleichen Frequenz crawlen. Das heißt, einige Seiten crawlen wir vielleicht mehrmals am Tag, vielleicht alle paar Tage, andere Seiten alle paar Wochen, andere Seiten, die sich schon lange nicht geändert haben, crawlen wir vielleicht nur alle paar Monate. Und so kann es natürlich sein, dass wenn ich jetzt einen größeren Teil meiner Website auf New Index setze oder mit 404 zurückgebe, dann kann es natürlich sein, dass ein Teil wird sehr schnell aus dem Index entfernt und ein anderer Teil braucht einfach ein bisschen länger, bis das wirklich verarbeitet ist. Manchmal kann das wirklich Monate dauern, bis das wirklich vollständig verarbeitet worden ist. Was man machen kann, wenn man das beschleunigen will, wenn das zum Beispiel jetzt ein Handvollseiten sind, die man möglichst schnell aus dem Index haben möchte, kann man mit dem URL Entfernungstool arbeiten in Search Console, mit dem man gezielt angeben kann. Die Seiten haben sich entweder verändert oder habe ich entfernt und sie möchte sich, dass sie in der Suche wirklich wirklich schnell nicht mehr dargestellt haben. Und dann geht das in der Regel vielleicht ein halben Tag und dann werden die entsprechend auch in der Suche ausgeblendet. Die werden nicht direkt aus dem Index entfernt, aber die werden einfach in der Suche quasi erstmal ausgeblendet und dann passiert dieser normale Ablauf mit dem Neu Crawlen und dann werden sie dort auch entsprechend entfernt. Ich sehe im Chat gecrawlt, werden täglich alle Seiten... Ja, wir crawlen natürlich viele Seiten täglich, aber gerade bei der Entfernung von URLs, wenn das Seiten sind mit Parametern, dann kann es durchaus sein, dass es mehrere Monate geht, bis das Ganze entfernt wird. Und was man natürlich auch machen kann, ist, dass man das Crawling ein bisschen beschleunigt, indem man, dass man uns gezielt sagt, diese Seiten haben sich jetzt neuerdings verändert. Und das könnte man mit einer Sidemap-Datei zum Beispiel machen, dass man die Sidemap-Datei einreicht und sagt, Änderungsdatum ist für diese einzelnen Seiten der Tag, an dem ich jetzt No Index gesetzt habe oder das auf 404 oder 410 umgestellt habe. Und wenn unsere Systeme dann merken, wir haben die Seite mit diesen neueren Zuständen auch nicht gecrawlt, dann gehen sie in der Regel eher ein bisschen schneller dorthin, um die Neu zu crawlen, damit sie ein bisschen schneller herausfahren. Sind Speaking URLs ein Ranking-Faktor oder ist das dem der Bord egal, ob URL-Parameter oder auch eben die Wörter drin sind? Eben wie gesagt, aus unserer Sicht sind die etwa identisch. Für den Benutzer sind natürlich URLs, die man verstehen kann, ein bisschen praktischer manchmal, aber vom Crawling her ist es so, dass wenn man jetzt nicht Übung hat mit dem Aufbau von einer Website mit umgeschriebenen URL, dann würde ich eher mit Parameter arbeiten. Und das Ganze wird meiner Meinung nach mehr und mehr weniger relevant, weil gerade in den Suchergebnissen zeigen wir mehr und mehr auf die Breadcrumbs an. Man kann auch mit Breadcrumbs Markup arbeiten, sodass die Benutzer, an für sich die URLs, wie sie indexiert sind, kaum mehr sehen. Und von dem her könnte ich mir vorstellen, dass vielleicht in den nächsten paar Jahren, dass der Trend dann eher Richtung Parameter wiedergeht, sodass man sich vielleicht eher auf die Inhalte konzentriert und weniger auf die URLs selber. Aber sehen wir mal, wie sich das verändert. Ich habe im Forum meine Frage gestellt, jedoch nur wenig Rückmeldung bekommen, probiere ich es kurz hier. Ich glaube, das war die Website, die den Relaunch gemacht hat mit vielen Readeracts auf der Website und es sind noch nicht alle quasi neuen URLs so indexiert. Aus unserer Sicht gibt es da verschiedene Sachen, die da zusammenkommen. Einerseits ist es so, dass wir vielleicht nicht gewusst haben, welche URLs sich alle verändert haben. Also mit einer Sidemap-Datei kann man da auch ein bisschen nachhelfen, indem man sagt, diese URLs bitte neu crawlen. Da ist jetzt ein Redirect zu den neuen URLs. Dann können wir dementsprechend so dem weitergehen. Das ist vielleicht eine Sache, die man noch zusätzlich machen könnte. Andererseits ist es so, dass wir natürlich gerade größere Websites einfach erst mal crawlen müssen. Und das kann eine gewisse Zeit dauern, bis wir wirklich die ganze Website gecrawlt haben, bis wir wirklich alles mal durchgegangen sind. Wir crawlen die wichtigeren Seiten in der Regel ein bisschen schneller. Also eben eher im Bereich Tagen. Und die Seiten, die wir sehen, die sich schon lange nicht mehr verändert haben, crawlen wir dann vielleicht im Bereich Wochen oder Monate. Und so kann bei einer größeren Website kann es durchaus sein, dass wir einen Teil schon übertragen haben auf die neue Struktur und einen anderen Teil geht es einfach noch sehr lange. Dazu kommt eine Funktionalität in der Suche, die das Ganze vielleicht ein bisschen verwehrender macht, indem das, wenn wir sehen, dass jemand gezielt nach URLs sucht, die wir zwar schon im Index umgeschrieben haben, die wir aber so gekannt haben, dann versuchen wir die auch zu zeigen. Das sieht man vor allem bei einem Domainumzug, wenn ich von einem Domain auf einen anderen wechsle. Und wenn wir sehen, dass jemand gezielt nach dem alten Domainnamen sucht, mit einer Side-Abfrage oder direkt mit dem Domainnamen selber, dann versuchen wir diese URLs zu zeigen, weil wir denken, der Benutzer hat jetzt gezielt danach gesucht und dann zeigen wir das, wie die auch noch kennen, obwohl wir die redirects vielleicht schon verarbeitet haben. Und von dem her kann es sein, dass wenn man gezielt mit einer Side-Abfrage gerade so eine Strukturveränderung anschauen möchte, dass es einfach da noch die alten URLs sichtbar sind, obwohl wir eigentlich einen großen Teil schon umgeschrieben haben auf die neue Struktur. Aus unserer Sicht ist die ganze Umstellung in solchen Rahmen weniger problematisch, dass man das jetzt möglichst schnell verarbeiten muss, weil wir ja dann auch wissen, dass wenn Benutzer auf die alten URLs gehen, werden sie auch die neuen weitergeleitet. In der Regel ist es auch so, wenn man ein 1 zu 1 Verhältnis zwischen alten und neuen URLs besteht, dann verändert sich vom Ranking her auch nichts. Das heißt, die URL-Struktur ist ein bisschen anders. Der Benutzer hat einfach ein redirect noch dazu. Aber von der Sichtbarkeit in der Suche sollte sich da eigentlich nicht viel verändern. John, dazu eine Frage. Wenn die alte Domain, die sauber weitergeleitet ist, weiter angezeigt wird, wenn man dann nach so auf dem Side-Befey, woher weiß man dann, dass man die Umstellung korrekt überstanden ist, sodass man zum Beispiel die redirects rausnehmen kann? Die redirects würde ich auf jeden Fall Größenordnung ein Jahr oder so noch drin lassen. Einfach, dass man wirklich sicher ist, dass Google das wirklich sauber verarbeiten kann. Man kann das kontrollieren, indem man die gecachede Seite anschaut, einerseits. Man kann auch ein Infoabfrag machen. Und meistens, wenn man jetzt einen alten Domain abfragt, dann die URL, die dargestellt wird dort, ist dann die neue schon. Und so kann man das für einzelne Seiten kontrollieren. Für eine größere Menge von Seiten kann man das mit der Sidemap-Datei auch kontrollieren. Man sieht ja in Search Console, von dieser Sidemap-Datei sind so viel schon indexiert worden. Wenn ich eine Sidemap für die Alten und für die neuen habe separat, sehe ich dann, bei der Alten werden sie mehr weniger, bei der neuen werden sie mehr. Die alte Sidemap kann ich ja für eine alte Domain im Webmaster Tool gar nicht mehr sehen, weil die ja wahrscheinlich gar nicht mehr verifiziert ist. Weil die gibt es ja gar nicht mehr, die Domain. Verifiziert kann sie ja trotzdem werden. Wenn jetzt ein Redirect da ist, zum Beispiel für die Verifizierungsdatei, dann kann man das trotzdem so verifiziert belassen. Man kann die Sidemap-Datei ja auch woanders aus. Das heißt, auf dem neuen Domain kann ich zum Beispiel die Sidemap-Datei für den alten Domain haben. Solange die beiden Websites verifiziert sind im gleichen Kontrum, sieht man die Angaben dort auch. Okay. Ich hatte dazu im Chat auch eine Frage gestellt, die so ein bisschen verwandt ist, auch zum Domain-Umzug. Nämlich alte neue XML-Sidemaps. Ich habe hier einen Fall, da wird einfach von HTTP auf HTTPS umgestellt und in den Google Support-Unterlagen, ich hatte den Link auch reingetragen, steht tatsächlich alte URLs in eine XML-Sidemap, neue URLs in die neue XML-Sidemap. Und die IT stößt einmal an die Grenzen, weil die XML-Sidepaps normalerweise dynamisch on-the-fly generiert werden, sodass die Alten, die müssten wir jetzt quasi, da müssten wir quasi ein Screenshot nennen, ein Screenshot ist falsch, also ein Snapshot von machen und eine lange Liste machen von alten URLs, von dem wir wissen, dass sie alle weitergeleitet sind oder 4.04 Fehler sind. Ist es aber, ist es tatsächlich so, dass ihr ratet, ein Snapshot zu machen mit alten URLs und die in einer XML-Sidemap abzulegen und diese weiterhin im Webmaster-Tool einzuhängen? Wir raten dazu in erster Linie, damit wir vom Crawling her das ein bisschen schneller verarbeiten können. Das heißt, in der Regel, wenn wir erkennen können, dass ein Zeitpunkt stattfindet, auch von HTTPS auf HTTPS, dann crawlen wir sowieso schon ein bisschen schneller. Das heißt, im großen Teil sollte sich das schon einpendeln. Mit einer Sidemap kann man aber auch gezielt angeben, diese alten URLs bitte noch mal crawlen. Wir sehen dann die redirects oder die 4.04 und können das ein bisschen schneller verarbeiten. Aber ihr seht doch sowieso die neue Sidemap mit den aktuellen, ich meine, warum solltet ihr die alte, schneller crawlen als die neue? Wichtig ist, dass wir die ganzen Signale von der alten auf die neuen übertragen können. Mit der neuen sehen wir natürlich, das sind jetzt neue URLs, aber wir wissen nicht, was der Kontext ist. Wir wissen nicht, wie wertvoll sind die, sollen wir die gleichzeitig zeigen oder sind das einfach irgendwelche zufällig neuen URLs, die da entstanden sind. Und mit dem redirect können wir das ganz ein bisschen schneller, so wirklich auch die ganzen Werte, die sich jetzt angesammelt haben, über die Jahre weitergeben. Okay, das heißt also, der Rat ist, habe ich korrekt verstanden, jetzt, wenn wir morgen relaunchen und Umstellungen machen von http auf https, tatsächlich heute ein Snapshot zu ziehen von der, sagen wir mal, hunderttausend alten URLs, wissen, dass die dann morgen, wenn wir die XML Sidemap statisch quasi ablegen, das sind alles redirects oder File 4 Fehler. Das heißt, das Webmaster Tool wird da auch richtig Search Console, ich kann mich an den neuen Namen nicht gewöhnen. Die Search Console wird also auch meckern darüber, weil das sind ja alles Sinnweise, denn das sind da redirects, sollen da eigentlich nicht drin stehen, richtig? Ja, aber trotzdem mir erratet dazu, alte XML Sidemap, neue XML Sidemap separat voneinander legen und beide darlassen für ein Jahr oder so. Ich denke, die Sidemap kann man ein bisschen schneller rausnehmen, aber die alte, ja, die alte. Ich würde einfach auch sicherstellen, dass man vom Änderungsdatum her ein Datum angegeben hat, was nach diesen redirects quasi ist. Na ja, aber dann gibt es die ja gar nicht mehr. Das ist ja so die alten ULs, HTTP ULs gibt es ja ab morgen gar nicht mehr. Das Änderungsdatum kann ja dann höchstens heute sein. Ja, einfach so, dass wir erkennen können, dass wir die neu crownen müssen. Wie sagt man euch, dass ihr die neu crownen sollt in der XML Sidemap? Mit dem Änderungsdatum am einfachsten. Änderungsdatum wäre dann also morgen, also sollen wir da künstlichen, in zukünftiges Änderungsdatum reinschreiben? Zum Beispiel, ja, kann man machen. Wichtig ist einfach, dass die, also was auf unserer Seite passiert, wir schauen uns die Sidemap-Datei an. Wenn wir sehen, wir haben diese einzelnen ULs heute schon gekrowt und das war soweit okay. Und ihr reicht morgen eine Sidemap-Datei ein mit einem neuen Änderungsdatum für diese Seiten, dann wissen wir, dass wir diese Seiten nochmal neu crownen müssen. Das versuchen wir da mit dem Änderungsdatum quasi herauszuholen. Okay, alles klar, danke. Das macht es wahrscheinlich in eurem Fall ein bisschen schwieriger, wenn das Ganze dynamisch gemacht wäre. Naja, das ist ja ein großen System immer so, dass es dynamisch generiert wird. Ich kenne keinen Fall, wo jemand sagt, jetzt drück jetzt auf den Knopf und generiere jetzt eine XML Sidemap. Auf jeden Fall nicht in großen Systemen oder in Shops oder so, das ist ja unmöglich. Aber ich meine, ist ja okay. Wir können ja quasi, ich kann sie ja quasi nicht lassen, also kopieren heute und händisch in der Textdatei umwandeln, die XML heißt, und händisch alle Daten auf das morgige Datum ändern. Ist ja, kann ich ja machen, ist ja kein Problem. Und dann wieder hochladen, das Ding. Ja, das wäre eine Variante. Okay, gut. Hey John, ich will dich hier kurz einhacken. Okay. Bei dieser Seite, wo es diese vielen 901 Redirects gegeben hat, wir haben hier die Sidemap beispielsweise, die Alte. Haben wir mit den alten Urls noch etwa ein Monat nach Re-Launch in der Search Console umgelassen, auch in der RoboSticks. Und wir wollten damit sicherstellen, dass ihr uns crawled und dass ihr die 301 Redirect crawled. Das habt ihr gemacht. Wir haben gesehen, dass, wir haben in den Logfels nachgesehen und haben gesehen, dass nahezu alle Seiten gecrawled wurden von euch. Und ich würde gern wissen, was genau heißt, ihr verarbeitet die Seiten. Wir sehen, ich würde euch gern ein Beispiel schicken im Chat. Das ist eine dieser alten Urls im Cache aufgemacht. Das Cache sagt, ihr habt das letzte Mal am 17. November gecrawled. Den Re-Launch haben wir im Appil gemacht. Wie kann es sein, dass ihr quasi im November schon diesen 301 Redirect gecrawled habt, aber diese Url immer noch im Index ist? Weiß ich nicht. Müsste ich genauer anschauen mit so einem Beispiel. Mich führt halt der gesamte Prozess in, also wie ihr diese Seiten verarbeitet, das würde mich interessieren. Mal ganz kurz schauen, ob ich da was sehe, aber wahrscheinlich lässt sich das nicht so quasi live nachschauen, was wir da gemacht haben. Müsste ich mal separate anschauen. Aber grundsätzlich ist es so, dass gerade solche Veränderungen, das betrifft eigentlich wirklich nur die Url, die dargestellt wird in der Suche, das ändert eigentlich nichts für euch in der Suche selbst. Das heißt, diese Url und vom Ranking her, von der Sichtbarkeit her ändert sich da eigentlich nicht. Okay. Aber ich schaue das mal an mit dem Team, was da vielleicht jetzt da passiert ist oder was wir damals gecrawled haben. Es ist ein bisschen schwierig so live herauszuholen. Okay, ich sage schon mal, danke im Vorhaus. Ja, bitte. Okay, schauen wir mal die nächsten Fragen an. Ist es Duplicate Content bei Bildern den selben Subtitel oder Alttext für verschiedene Website mit verschiedenen Inhalten zu präsentieren? Duplicate Content an und für sich, für Bilder ist das okay. Was wir bei Bildern ja jeweils machen, ist, dass wir einerseits auch die Bilder selber versuchen zu indexieren und so erkennen wir natürlich sehr schnell, ob das unterschiedliche Bilder, andererseits nehmen wir da verschiedene Inhaltsbereiche zusammen um für das Bild ein bisschen besser zu verstehen, wie wir das präsentieren können. Das heißt, einerseits nehmen wir schon den Alttext dazu, andererseits versuchen wir auch zu erkennen, ob da jetzt ein Caption auf dem Bild ist, irgendwie ein Untertitel dabei, welche Texte rund um das Bild herum sind und all die Sachen versuchen wir da zusammenzuziehen um festzustellen, wie wir dieses Bild in der Bildersuche präsentieren. Und von dem her, ob jetzt der Alttext überall gleich ist oder nicht, das ist vielleicht nicht ganz optimal, aber es ist nicht gerade das kritische Problem, weil wir haben da genug andere Möglichkeiten, Informationen über das Bild herauszuholen. Schauen wir mal wieder weiter. Eine Frage zur Anzeige von 404 in Search Console und zwar werden uns 404 Seiten als neu erkannt ausgewiesen wie laut Search Console auf unseren Seiten auch noch verlinkt sind aber was da nicht der Fall ist woher stammen die Daten unter verlinkt über, wenn ich mir die 404 Seite genauer anschaue in Search Console. Was da in der Regel passiert ist, dass wir diese URLs finden auf unserer Website irgendwann einmal und wir behalten sie in unserem System an und für sich längerfristig geben wir sie auf und hoffen, dass sie irgendwann wieder Wert haben und dass es irgendwann wieder Sinn macht die zu crawl und zu indexieren und so versuchen wir die immer wieder mal neu zu crawl. Und in Search Console zeigen wir dann das Datum, wann die zuletzt gecrawt worden sind das ist an und für sich das Datum, was man da sieht also nicht unbedingt, dass wir die Seite neu gefunden haben, sondern wir haben sie vielleicht damals gefunden wir haben sie aufgehoben, wir versuchen sie ab und zu wieder mal und schauen einfach nach, ob da jetzt Inhalte da sind die wir indexieren können. An und für sich muss man da nicht spezielles machen, aus unserer Sicht ist es vollkommen okay, wenn eine Website 404 Fehler hat, das ist ja ein Zeichen dass die an und für sich sauber aufgebaut ist dass wirklich die Inhalte die indexiert werden sollen, sind vorhanden und die Inhalte die nicht indexiert werden sollen, gibt der Server klar ein Zeichen zurück, das sind jetzt ungültige URLs und das ist aus Unter Sicht vollkommen okay. In Search Console selber was man machen kann, um ein bisschen herauszufinden, welche URLs auf welche man achten muss ist einfach die Reinfolge, die Priorität die wir angeben für die 404 Fehler das heißt bei der Priorität berücksichtigen wir ob das Seiten sind, die schon früher mal Traffic gekriegt haben aus der Suche, ob sie intern noch verlinkt sind, ob sie vielleicht in einer Site Map Partei dabei sind und wenn diese Faktoren irgendwie dazu kommen dann zeigen wir die URLs höher in der Liste, das heißt wenn ich in die 404 Fehler Liste gehe und ich finde alles nur URLs, die wirklich irgendwann mal existiert haben und schon lange nicht mehr relevant dann ist es ein Zeichen, dass es gibt nichts interessanteres, was wir euch dort zeigen könnten und ihr könnt wahrscheinlich den Rest der Liste auch überspringen und aus unserer Sicht ist das vollkommen okay wir bringen diese Liste in erster Linie damit ihr kontrollieren könnt gibt es da irgendwelche Fehler die dargestellt werden, wo ich eigentlich Inhalte erwarten würde und wenn man so etwas findet dann würde ich dem vielleicht nachgehen wenn man einfach sieht, dass sind alles wilde URLs, die irgendwann mal gefunden worden sind, dann kann man das getrost ignorieren zum Canonical wir leiten alle sonstigen URL Varianten per 301 weiter auf die https kundendomain.de wie sollte das Canonical Tag am besten benannt werden, gesamte URL der Seite oder reicht hier quasi einfach das Verzeichnis man kann das machen wie man möchte wenn man eh ein Redirect auf die eine Variante hat dann kann man mit dem Canonical Tag sich auch mit dem Relativen URL arbeiten, statt mit der absoluten URL persönlich finde ich das immer ein bisschen praktischer mit der absoluten URL weil da muss man sich nicht drum sorgen wo die URL jetzt gefunden worden ist man kann aber durchaus mit der Relativen URL arbeiten SEO Plugins, wir fallen für mehr Zeiten auf deren SEO Plugins die Meta Description einfach mit der H1 oder dem ersten Text der Webseite befüllen, vergleicht Google diese Angaben und wenn ja wie geht Google damit um wir verwenden den Meta Description nicht als Ranking Faktor wir verwenden den nur für den Snippet d.h. in den Suchergebnissen wenn jemand nach der Seite sucht oder wenn wir die Zeit in den Suchergebnissen zeigen würden versuchen wir den Meta Description zu verwenden und wenn wir das Gefühl haben, dass jetzt eine passende Beschreibung ist für diese Seite ansonsten können unsere Algorithmen natürlich auch automatisch einen anderen Teil der Seite darstellen d.h. wenn eure Plugins sowieso nur einen anderen Teil der Seite weiter verwenden und gar keine eigene Description verwenden, dann würde ich das einfach auch vielleicht weglassen im Meta Description dann muss man das nicht für uns ausfüllen weil wir würden ja dann sowieso einen Teil der Webseite nehmen um als Description in den Suchergebnissen zu zeigen d.h. wahrscheinlich macht das nicht viel Sinn zumindest für Google, für andere Suchmaschinen ist es vielleicht anders vielleicht ist es auch für Contextual Ads ist es vielleicht auch unterschiedlich dass man da ein Description angeben muss aber zumindest für Google ist es nicht so dass man ein Description ausfüllen muss und wenn man das automatisch ausfüllen lässt dann ist es sowieso ähnlich wie das was Google sowieso machen würde im letzten Hangout wurde gesagt dass beim mobilen Index auch nicht sichtbare Inhalte indexiert werden Tabs, Slider Codion Tabs sind ja praktische Komponenten um Inhalte anzubieten bereitzustellen ohne immer die gesamten Informationen zu zeigen früher sah das anders aus ja das ist eine der Änderung die beim Mobile First Index wahrscheinlich kommen wird in dem dass wir gerade bei bombilen Seiten uns auch bewusst sind dass es dann noch schwieriger ist die Inhalte sauber zu platzieren so dass sie immer sichtbar sind auf einer Seite und dementsprechend versuchen wir dann auch die nicht sichtbaren Inhalte dazu zu ziehen wie sich das dann effektiv auswirken wird sehen wir dann noch ich denke da sind noch viele Experimente nötig auf unserer Seite aber da hört ihr sicher auch von uns noch mehr, wenn wir näher sind Such Console, wir haben Kundendomains mit HTTP, HTTPS jeweils mit und ohne WBW als Property hinzugefügt das SSL Zetetikart ist ein Multi-Domain Zetetikart und wurde nur für die WBW Variante ausgestellt jetzt gibt es beim HTTPS nicht WBW dass das Zetetikart nicht zum Domain passt was kann man da machen grundsätzlich ist es so, dass wir die WBW für euch bringen, damit ihr das anschauen könnt und wenn das relevant ist entsprechend auch beheben könnt wenn ihr wisst, dass sowieso niemand auf diese Variante zugreift dann kann man das natürlich auch getrost erstmal ignorieren und von dem her wenn ihr bewusst seid dass an und für sich niemand direkt auf die Nicht-WBW Variante zugreift und diesen Zetetikart-Fehler sehen würde, dann ist das eigentlich auch okay für euch in der Suche ist es so dass wir Zetetikart-Fehler im Moment nicht berücksichtigen in dem Sinn, dass wir die Seite eigentlich bestrafen würden oder dass wir die in Ranking weniger zeigen würden sondern wir würden die Seite trotzdem noch so zeigen der einzige Nachteil ist halt, dass wenn ihr als Canonical eine Seite angibt die ein Zetetikart-Fehler hat, dann gehen alle Benutzer erstmal durch dieses Interstitial wo sie angeben müssen, ja ich möchte die Seite trotzdem sehen obwohl da irgendwas total schief ist und das ist dann vielleicht etwas was man da beheben müsste aber wenn sowieso niemand auf diese Variante zugreifen würde das sieht ja sicher auch in Analytics dann ist es an und für sich egal viele WordPress-Teams benutzen vordefinierte H-Tags beispielsweise in Logo für den Seitentitel oder gar für Breadcrumbs mit einem Wort oder zwei im Foto geht es dann weiter mit H3-Tags für Kontakt und so weiter sollten die Theme-Entwickler nicht den Benutzer in die Chance ergeben um ein einzigartiges H-Tag im Body and Content zu benutzen sollten die Enwickler nicht eher eine eigene Klasse definieren ja kann man natürlich machen es ist schwierig uns den Enwicklern zu sagen was sie machen sollen aus unserer Sicht ist es so, dass wir mit allen möglichen Websites umgehen müssen und wir müssen da die Headings auch so bearbeiten können wie sie kommen das heißt es ist wahrscheinlich nicht so, dass man da große Veränderungen in der Suche sehen würde wenn man jetzt die Headings aller umstellen würde auf eine andere Variante ich denke wenn man das sauber machen möchte dann macht das sicher Sinn dass man da eine klare Struktur hat mit den Headings auf einer Seite richtig problematisch sehe ich das aber an und für sich nicht das heißt es ist jetzt nicht so dass ich sagen würde diese Enwickler die das machen das ist total verkehrt die Websites die das so einsetzen die haben großen Nachteil wir sehen das ein bisschen pragmatischer an und müssen mit dem halt umgehen was wir geliefert kriegen von den Websites was sind die 3 wichtigsten Themen für 2017 für SEOs tja schwierig zu sagen so eine einfache Frage ich denke das was wo ihr sicher am meisten hören wird ist alles rund um Mobile das ist immer noch ein Thema was bei uns sehr präsent ist gerade mit der Umstellung auf den Mobile First Index ist das etwas was gerade denke ich bei SEOs vielleicht mal ein Thema wird in dem Sinne das bisher wenn man jetzt on-page SEO gemacht hat hat man sich natürlich auf die Desktop Variante konzentriert und hat wenn man jetzt eine separate mobile Version hat hat man hier eigentlich gar nicht groß angeschafft man hat vielleicht kontrolliert dass das eine gültige mobile Webseite ist aber man hat mich darauf geachtet dass man jetzt on-page SEO für die mobile Seite selber macht und das wird sicher etwas sein denke ich mal in diesem Jahr ein bisschen verändern wird in dem dass man wirklich vermerkt auch die mobile Seite anschauen muss und sich überlegen muss welche Faktoren bezüglich on-page SEO möchte ich da vielleicht noch einbauen das heisst natürlich auch dass man die Tools die man verwendet entsprechend auch ein bisschen anpassen muss oder anders anwenden muss so dass man wirklich auch gezielt die mobile Seite anschaut und das wird sicher etwas sein wo man mehr von uns hören wird im Laufe vom Jahr wo aber auch viel von denke ich den SEO Blogs und so mehr Informationen dort auch kommen wird was sind denn wenn du schon die Faktoren die on-site Faktoren erwähnt hast was sind denn mobile die wichtigsten on-site Faktoren die sich wesentlich unterscheiden von den desktop on-site Faktoren an und für sich unterscheidet sich nicht viel aber wir sehen einfach dass gerade auf mobilen Seiten werden die on-site Faktoren gar nicht verwendet das heisst Sachen wie Headings die ich vorher erwähnt habe die werden auf mobilen Seiten gar nicht groß verwendet man macht dann einfach den Markup irgendwie anders so dass die Titel ein bisschen mehr hervorgehoben sind oder bei Bildern, dass man mit dem Alt Text arbeitet das sind Sachen die auf mobilen Seiten oft verloren gehen Structured Data wird in vielen Fällen gar nicht verwendet auf mobilen Seiten das sind alles so Elemente die man im Laufe der Jahre gelernt hat dass man die auf desktop Seiten suchen muss oder dass man die vielleicht kontrollieren sollte und die man auf mobilen Seiten bisher gar nicht groß angeschaut hat Du sprichst hier von Fällen wo die desktop Version auf einer anderen Verzeichnissen oder andere Domain läuft als die mobile Version alles das was du sagst ist ja voll responsive sowieso hinfällig oder? Genau wenn man jetzt voll responsive alles aufgebaut hat haben wir das alles eh schon zusammen wenn man die mit einem M Dot Website zum Beispiel gearbeitet hat mit separaten URLs oder wenn man eine separate mobile Version herausliefert wenn mobile Benutzer kommen dann kommt das alles ins Spiel aber wenn man eh schon responsive arbeitet dann hat das eigentlich alles wie gehabt Dazu gleich noch eine Frage EMP Ich hatte einen Kunden der natürlich das gehört hat da sind online Shop ein großer und der hat mich gefragt sollen wir jetzt beim nächsten relaunch den Mai ansteht alles auf EMP setzen und ich habe da extreme Schmerzen weil es ja noch so am Anfang ist Ratet ihr jetzt tatsächlich dazu online Shops komplett auf EMP zu setzen? Ich vermute dass man das noch gar nicht vollständig machen kann also ich weiß jetzt nicht was was die neuesten Sachen sind auf der EMP Seite aber gerade bezüglich Personalisierung bezüglich quasi dynamischen Preisen alles solche Sachen sind ja vollständig und nicht unterstützt genau, caching das sind Sachen da kann man zwar mit iFrames arbeiten aber das ist natürlich ja, weiß ich nicht Nein, okay Vielleicht Schmerzen von früher Also ich höre daraus die EMP ist toll aber bei online Shops wartet lieber noch paar Jahre paar Jahre weiß ich nicht die sind sehr schnell Du kannst dir vielleicht vorstellen was für eine riesen Änderung für einen online Shop-System eine Umstellung auf EMP ist also wir reden da über Mannjahre der Entwicklung und man will ja nicht hier Testkaninchen sein für ein System was sicherlich Vorteile hat aber tatsächlich die Projectquellen da wird man lesen, Leute jetzt seid ihr bereit, ja? Genau, genau was man natürlich auch machen kann ist, dass man gezielte Seiten einfach auf EMP nennen das heißt wenn ich jetzt vielleicht ein Bereich habe über Produkte-Neuerungen wo was dann vielleicht eher aussieht wie Blog-Post oder Presser-Artikel die man heraus gibt dass man sagt diese Sachen nämlich gezielt auf EMP dann kann ich einfach ein Plugin verwenden das vielleicht leicht anpasst dass es gut aussieht und dann habe ich einfach den Teil auf EMP aber der ganze Rest vom Shop kann man ja dann weiterhin auf dem alten System Du wirst aber zustimmen wahrscheinlich dass für ein Shop mit 400.000 Produkten die 10 Magazin-Seiten nicht so relevant sind, dass ich da in eine EMP-Entwicklung reingehen würde und das dann vollständig ja in vielen Fällen wird das sicher der Fall sein man sieht ja auch wie viel Verkehr auf der Seite kommt wenn man weiß, dass das wenig auf diese Seiten kommt dann muss man sich überlegen macht es Sinn da wirklich Zeit zu investieren oder kann ich das vielleicht mit einem Plugin einfach in ein oder zwei Tagen erledigen dann ist es vielleicht weniger problematisch aber das sind natürlich alle so praktische Fragen die wenn man jetzt beim EMP-Team direkt nachfragen würde sagen die wahrscheinlich schon das sollte man auf jeden Fall machen und das ist natürlich der Sicht muss man natürlich immer abwägen so viel Arbeit ist das so viel habe ich schlussendlich davon macht das Sinn gibt es eine Alternative zum EMP es gibt ja dieses, wie heißt das Active Web Apps oder so was weiß ich jetzt nicht was Active Web Apps ist habe ich nur gestern aufgeschnappt ich muss mich nochmal informieren dazu also vielen Dank schon mal für die Antwort machen wir doch, stellen wir doch einfach um auf eure Fragen direkt ist jemand vor mir? leg los super ich gucke mir gerade eine sehr große Webseite an mit ein paar 100.000 Millionen Seiten und die Seiten kommen aus den unterschiedlichen Content Management System jetzt ist große Aufregung bei der Mobilumstellung kann man schon herausfinden welche Seiten werden Probleme bereiten und welche nicht und gibt es da eine schlaue Möglichkeit sich Gedanken zu machen welche meiner Seiten beim Mobile Switch ich zuerst prüfen sollte also es sind auf jeden Fall von den Seiten viele Seiten nicht für mobil optimiert aber Sie wissen noch nicht in welcher Reihenfolge Sie jetzt priorisieren können da habe ich noch keine einfache Lösung was was vielleicht das Ganze ein bisschen einfacher macht ist, dass gerade bei der Umstellung auf den Mobile First Index wenn eine Seite wirklich nur als Desktop Variante vorhanden ist dann indexieren wir die natürlich weiterhin so dann ist es nicht so, dass wir die Seite aus dem Index fallen lassen weil sie nicht mobile friendly ist sondern wir nehmen dann einfach die Desktop Variante und indexieren die so auf jeden Fall wird sich wahrscheinlich wenig verändern problematischer ist wenn jetzt wirklich eine separate mobile Version vorhanden ist und die ist wirklich sehr vereinfacht im Vergleich zur Desktop Version für diese einzelne Seite dann verlieren wir natürlich Inhalt und das sind dann die Situationen die man versuchen muss herauszufinden wir planen auf jeden Fall Informationen auch zu verschicken an Webmaster wenn wir erkennen können dass der große Teil der Website so ist, dass wir Informationen wirklich verlieren würden wenn das eine Website ist die viele unterschiedliche Bereiche hat könnte ich mir vorstellen, dass es schwierig für uns ist, das wirklich zu erkennen und zu sagen in diesem Unterverzeichnis hier mit diesem Content Management System gibt es noch Probleme die ihr beheben müsst der große Teil der Website ist aber okay von dem her ob man vielleicht auch selber irgendwelche Tools erstellen kann um die Website als mobile Version zu crawl ich nehme an, so moderne Crawler wie Screaming Frog, kann man das wahrscheinlich auch machen ich habe da jetzt keine praktische Erfahrung wie man das am besten angehen könnte okay aber es ist eine interessante Information dass eine bestehende Desktop Version nicht automatisch wegfällt sondern okay, alles klar, Dankeschön Ja, bitte im Chat steht da natürlich noch ein bisschen was sollen wir für unsere CMS in Bezug auf Usability neue Content Komponenten entwickeln die auf Desktop Inhalte vollständig anzeigen und alternativ auf Mobile Inhalte aufklappen oder per Slide auf Canvas Horizontal Sliden alles im Responsive Design per CSS um die Vorart Ranking Frage wäre natürlich auch wichtig wenn man das kann, dann ist das vielleicht eine Variante, dass man das so macht dann kann man natürlich auch die gleichen Inhalte einerseits im Desktop vielleicht ein bisschen größer oder direkt darstellen und auf mobile dann vielleicht eingeklappt darstellen das gibt da verschiedene Variante wie man das angehen kann ich würde auf jeden Fall solche Sachen würde ich auch mit A-B-Tests mit Benutzern direkt ausprobieren also nicht einfach plain sagen Google kann das so, deshalb stellen wir alles um auf diese Variante sondern wirklich auch testen macht es wirklich für die Benutzer auch Sinn ist die Conversion Rate immer noch ähnlich wie vorher oder vergleichbar zu Desktop dass man da wirklich sich nicht irgendwo in eine Ecke einbaut Google sollte das so verstehen also machen wir das so, auch wenn das unsere Benutzer überhaupt nicht verstehen mal schauen in Search Console unter Fetch as Googlebot wird für keine meiner Seiten die gesamte Quelltext gezeigt, das bricht innerhalb eines JSON Scripts ab aber nie an derselben Stelle im Script die Renderingsvorschau zeigt aber die ganze Seite, inklusive Futter an und auch in Google Cache die Seiten komplett gerendert ist das ein Problem in der Regel was da wahrscheinlich passiert ist, dass dass wir einfach eine Limite haben in Search Console also wir haben auf jeden Fall eine Limite in Search Console für Fetch as Google dass wir nicht quasi zu viel Inhalte direkt darstellen auf dieser Textseite und wahrscheinlich also dass wir für die Indexing eine größere Limite haben als jetzt da in Search Console und diese Seite ist jetzt irgendwo dazwischen und je nachdem wie die dynamischen Inhalte der Seite erstellt werden, kann es natürlich sein, dass ein bisschen mehr oder ein bisschen weniger quasi über die Limite in Search Console hinüber geht wenn die Renderingsvorschau okay ist, wenn die Cache-Version okay ist, dann würde ich mir da keine großen Sorgen machen für die Teams, die du wirklich empfehlen kannst da ihr eine gute Erfahrung gemacht habt habe ich nicht spezielles leider keine Teams die ich jetzt besonders hervorheben könnte, wo ich sagen könnte das funktioniert auf jeden Fall mit SEO zum großen Teil ist es denke ich mal schon eher so, dass WordPress sehr ausgereift ist und dass es da viele Möglichkeiten gibt wirklich etwas Gutes rauszuholen was auch gut für die Suche funktioniert manchmal ist es so, dass man da gerade bei komplizierten Teams muss man vielleicht selber noch ein bisschen Hand anlegen und das ein bisschen anpassen aber im Großen und Ganzen ist WordPress eigentlich schon relativ gut ausgeragelt ich habe noch eine Frage wenn sonst keiner mehr hat und zwar online shopp wieder es geht um Facetelnavigation das heißt ich habe eine Seite, eine lange Produktliste verarbeitet wird man hat ja immer das Problem dass man den Crawler davon abhalten muss Milliarden von Filter, Kombinationen Permutationen zu indizieren ich habe mich gefragt warum macht man das eigentlich so selten warum sieht man das so selten dass eine lange Produktliste einfach per Ajax dann so bearbeitet wird sodass der die URL stehen bleibt und der header bleibt stehen und nur die Liste selber wird verändert und ich habe dann besser gefragt warum man das nicht macht ich mir ist nichts dafür eingefallen gibt es da Grund dagegen also eine lange Liste, keine Ahnung alle Hosen in diesem Job und dann filtern ohne dass es die URL verändert da habt ihr doch eigentlich nichts dagegen, oder? das ist ganz okay für uns gibt es irgendwelche Nachteilte von also die spontanen Einfallen dass das Ajax dann doch vielleicht irgendwie gecrawlt wird oder so, dass dann URLs kommen die man gar nicht kennt die man schlecht ausschließen kann ich denke der Hauptnachteil ist dass man das selber entwickeln muss ich sehe jetzt von der Suche her sehe ich kein Nachteil wichtig ist einfach dass wir die Produkte Seiten irgendwie finden können dass sie irgendwo auf einer indexierbaren Seite sind aber wie man das machen will wenn das jetzt wenn die Produkte sowieso indexiert sind wie man das mit der Sortierung und Facility Navigation machen will ist vollständig euch überlastet wenn wir das Windows so machen gibt es für Google dazu eigentlich Best Practices wie man mit Facility Navigation umgehen sollte irgendwie den Hills Materialien ja, wir haben eine ältere Blog Post dazu in welchem Blog ist das? im Webmaster Central Blog aber vielleicht müsste man das mal anschauen, kontrollieren ob das wirklich alles noch so stinkt ich vermute das ist alles noch okay aber gerade mit der Ajax Variante die du jetzt erwähnt hast wird da wahrscheinlich nicht erwähnt sein ach, wird nicht erwähnt sein wird da wahrscheinlich nicht erwähnt sein ist das nicht so neu, oder? ja, es ist einfach etwas was so gut wie niemand macht von dem her ja, aber warum nicht? ich frage mich warum, das hört sich doch so total logisch an also ich... ich weiß es nicht wahrscheinlich einfach, dass es kompliziert ist kompliziert für die Entwicklung okay okay, bitte okay, dann machen wir vielleicht hier Schluss vielen Dank für die ganzen Fragen und was ihr gekommen seid, für die Kommentare ich richte die nächsten deutschen Hangouts wahrscheinlich gegen Ende Woche ein das heißt wenn weitere Fragen noch kommen können wir die gerne da auch dazu nehmen und ansonsten wünsche ich euch erstmal einen schönen Nachmittag schönen Abend und gute Restwoche tschüss, alles leid tschüss