 Okay, herzlich willkommen beim heutigen Webmaster Essentials-Sprechstunden-Hangout. Mein Name ist Johannes Müller, ich bin Webmaster Trends-Analyst hier bei Google in der Schweiz. Teil von dem, was wir machen, sind solche Webmaster-Sprechstunden-Hangouts, wo jeder einfach kommen kann und seine Webmaster Fragen bringen kann. Und wir versuchen da Antworten irgendwie zu finden. Es sind einige Sachen schon eingereicht worden auf YouTube direkt als Kommentare. Aber wenn ihr wollt, könnt ihr gerne schon mal loslegen mit den ersten Fragen. Ja, ich hätte gerne schon mal HWF-Lengen angesprochen einmal. Also es geht um diese Kanonisierung, die Google vorne nimmt, diese automatische Kanonisierung. Wenn ich jetzt zum Beispiel an Österreich, Schweiz und Deutsch Setup habe, also Online-Shops habe und Google alle drei, also alle, die Österreich und Schweiz nach Deutschland kanonisiert, dann ist es so, dass wenn ich in der Google-Suche auf in der Schweiz, Land-Schweiz wähle, dass dann die deutsche Seite nicht erscheint. Also die Kanonisierung hebt ja praktisch dieses Geotagetheben, glaube ich, auf. Sollte eigentlich nicht. Also siehst du, dass das passiert bei dir, oder? Ja, ich sehe das schon eigentlich die ganze Zeit, weil du hast ja auch mal gesagt, dass nach Geotagetheben eigentlich die Seiten bevorzugt, die dann im gleichen Land sind. Also wenn jetzt auf Google CH gesucht wird, kommen ja irgendwie die CH-Domains. Aber wie gesagt, wenn die Kanonisierung vorgenommen wird, dann erscheinen die Seiten nicht. Ich kann mir gerne Beispiele schicken. Ja, das wäre gut. Dann kann ich das mal mit dem Team anschauen hier. Normalerweise, also so wie ich das vom Team verstanden habe, sollte das eigentlich so sein, dass wir den Canonical nehmen, aber dass dann trotzdem eigentlich die länderspezifische Version dargestellt wird und auch vom Geotageting her, dass sich da nichts groß ändert. Also es klappt nur, wenn du das Land nicht auswählst in der Suche oben. Dann funktioniert es. Okay. Also unter Tools kann man ja das Land auswählen. Und wenn du dann explizit sagst, nur in der Schweiz suchen, dann kommen die Seiten nicht. Okay. Aber ich schiebe das. Oder wie siehst du das? Kommt dann die DE-Variante, also die Variante für Deutschland irgendwo, oder erscheint dann gar nichts? Nee, es erscheint gar nichts. Die Seite kommt gar nicht. Also das wird ausgehebelt. Das Geotageting wird komplett ausgehebelt dann. Aber schaust du mal an, ich schicke dir dann mal ein Beispiel. Okay. Okay. Schauen wir das mal an. Cool. Ich glaube, da waren auch andere Fragen mit HF Lane eingereicht. Aber gibt es sonst noch irgendwas, was wir vielleicht vorher noch anschauen sollen? Okay, dann fangen wir es uns mal an. Und wenn ihr zwischen euch Kommentare oder Fragen habt, zu den eingereichten Fragen einfach loslegen. Und am Ende haben wir sicher noch ein bisschen Zeit, um allgemeine Sachen anzuschauen. Um die ganzen irrelevanten Filter URL vom Crawling effektiv auszuschließen, damit im Parameter Handling in Search Console haben wir keine hundertprozentige Sicherheit erlangen können, würden wir gerne das PRG Pattern einsetzen. Das Implementieren der PRG Pattern in unseren Shops ist leider mit erheblichen IT Aufwand, durch die große Infrastruktur verbunden. Daher meine Frage, wie lange wird es dauern, bis der Crawler das Form submit kann, um dann nach dem Redirect erst die Location per Get zu halten, die mit dem Pattern maskiert wird? Ja, gute Frage. Also, ich vermute, dass man da sehr großen Aufwand einbringen kann und da ich nicht so wahnsinnig viel erreichen kann mit diesem PRG Pattern. Mit PRG ist gemeint, dass da statt ein normalen Link, den man quasi aufrufen kann, dass da wie ein Postrequest gemacht wird. Das heißt, es ist wie ein Einreichen von einem Formular statt, dass man einen Link folgt. Und normalerweise würde das, sag ich mal, die Suchmaschine blockieren, dass sie da durchcrawlen kann. Auf Google-Seite gibt es schon eine Gefälle, die auch Postrequests machen, um weitere Inhalte von einer Website zu holen. Von dem her ist es eigentlich auch nicht eine hundertprozentige Sicherheit. Aber ich denke in den meisten Fällen ist es auch nicht so, dass man wirklich ein hundertprozentiges Blockieren von diesem URL haben muss. Das heißt, wir erkennen eigentlich auch, selbst wenn man nichts Spezielles macht, erkennen wir solche Patterns und versuchen diesen Patterns entsprechend auch weniger Gewicht zu geben im Laufe der Zeit, so dass vom Crawling her das nicht besonders viel Einfluss hat auf das Gesamt Crawling von einer Website. Was man auch machen kann, ist einerseits den Parameter-Handling-Tool. Wie gesagt, das ist nicht ein hundertprozentiges Blockieren, sondern das ist so, dass wir das Signal nehmen und dass wir eigentlich zum größten Teil wirklich dieses Crawling dann auch sein lassen von diesen Parametern. Das geht soweit, dass wir manchmal auch die Indexing-Teams haben, die uns kontaktieren und sagen, wir sollen dieser Website sagen, dass sie mit diesem Tool das normale Crawling auch blockiert hat. Es ist nicht so, dass es hundertprozentig das blockiert. Unsere Systeme können dann manchmal trotzdem noch diese Parameter aufrufen, aber es ist schon sehr stark reduziert. Das heißt, wahrscheinlich würde das eigentlich reichen in den meisten Fällen. Die andere Variante ist, dass man zum Beispiel mit No Follow arbeitet, dass man einfach sagt, diese bestimmten Parameter sind per No Follow quasi so, dass sie keine Signale weitergeben. Das funktioniert eigentlich auch relativ gut. Was man im schlimmsten Fall auch machen kann, wenn wirklich das Crawling selber ein Problem ist, ist mit Robots Text arbeiten. Das kann man auch kombinieren mit den anderen Varianten. Mit Robots Text ist es an und für sich für uns ganz klar, dass wir diese URLs gar nie crawlen sollen. Und wenn wir aufgrund von den anderen Signalen sehen, dass es sich auch nicht groß lohnt, diese URLs zu crawlen, zum Beispiel mit dem Parameter-Handling-Tool oder mit No Follow, dann ist es eigentlich so, dass es das ist eigentlich gut genug. Von dem her würde ich da eher raten, die normalen Sachen zu verwenden, statt mit diesem Post-Regress-Gate-System quasi zu arbeiten. Es gibt ja einfache Wege, das Ganze zu machen. Wenn man das kompliziert macht, braucht es einerseits viel Zeit, bis man das sauber implementiert hat. Andererseits, um das sauber auch zu verwalten und sauber auch zu kontrollieren im Laufe der Zeit, ist es natürlich viel komplizierter. Von dem her würde ich da mit Parameter-Handling, No Follow und im schlimmsten Fall für Robots Text arbeiten und mit dem kann man das eigentlich recht gut abdecken. Also auf jeden Fall nicht so, dass wir erwarten, dass e-commerce-sites irgendwelche komplizierten Sachen da einrichten, sondern wir müssen mit dem Web zurechtkommen, wie es da vorhanden ist. Und auf den meisten Websites geht das eigentlich recht gut. Kannst du etwas zum Update vom 7. November sagen, bei zwei Websites habe ich von einem Tag auf den anderen über 40% der Sichtbarkeit verloren. Es handelt sich um seit Jahren wirklich gut gepflegte Seiten mit guten Content. Ich habe den Eindruck, es könnte eine EAT-Verschärfung sein, der die Content als solcher völlig egal ist und das Ranking gradikal verschlechtert. Es ist schwierig zu sagen, was du da genau siehst. Ich kenne jetzt die Websites nicht und im Grunde genommen, so weit ich weiß, sind das eigentlich normale, sagen wir mal Core-Ranking-Updates, die wir da gemacht haben. Ich weiß jetzt nicht, ob das 7. November so ein Core-Update war, aber das sind eigentlich alles so normale Ranking-Updates, die wir machen. Die versuchen einfach eher relevantere Inhalte zu erkennen und die dann ein bisschen sichtbarer in den Suchergebnissen zu zeigen. Das heißt, für manche Websites wird das dann mehr sichtbar sein, für andere wird das vielleicht weniger sichtbar sein. Es hängt ein bisschen von den Arten von Websites ab. Auf jeden Fall bezüglich EAT ist es so, dass wir da nicht irgendwie eine EAT-Bewertung als solches haben und dass die Algorithmen das wirklich eins zu eins anschauen. Aber das sind natürlich verschiedene Sachen, die zusammenkommen und uns ein bisschen Signale geben können, welche Websites in welchem Moment relevant sind, welchen Websites wir wie entsprechend auch vertrauen können. Und je nach Art von Website macht es vielleicht mehr Sinn, dass man auf solche Sachen wie Autorität oder Trustworthiness ein bisschen mehr setzt und wirklich auch den Benutzern zeigt, was steckt dahinter, was steckt hinter diesen Informationen, die wir auf dieser Website haben. Ich denke, das ist nicht etwas, was jede Website machen muss, aber wenn es gerade sich um eben ein Gebiet handelt, wo Benutzer vielleicht ein bisschen kritischer geworden sind im Laufe der Zeit, dann würde ich da auf jeden Fall in die Richtung hin auch weiterarbeiten. Und es klingt ein bisschen so, dass du da schon ein bisschen bei dir siehst, dass man da vielleicht etwas verbessern kann. Und wenn du da schon ein bisschen so ernst, dann würde ich in die Richtung auch vielleicht ein bisschen mehr Arbeit einsetzen und ein bisschen schauen, dass man das ein bisschen verbessern kann. Es ist, wie gesagt, nicht so, dass wir die gleichen Kriterien bei allen Websites verwenden. Bei vielen Websites müssen wir da nicht wahnsinnig viel mehr Informationen haben, aber manchmal macht es schon Sinn, dass man da ein bisschen Hintergrundsinformation dazu bringt. Dann zum mehrsprachigen Websites noch ein bisschen. Lohnt es sich, CHDE und DE-DE einzusetzen, wenn die Inhalte nicht speziell unterschiedlich in den Ländern sind, also für die Schweiz und für Deutschland unterschiedliche Versionen. Grundsätzlich würde ich sagen, wenn man weniger Varianten machen kann, dann würde ich das bevorzügen. Das heißt, gerade wenn sich die Inhalte nicht unterscheiden, wenn man die Benutzer besonders ansprechen will in den einzelnen Ländern, dann würde ich eher schauen, dass man eine deutsche Version hat und die möglichst weiterverwendet. Mit einer Version der Website ist alles immer ein bisschen einfacher. Das Ganze mit dem Linking ist ein bisschen einfacher, dass man da wirklich weiß, welche Seiten man wie untereinander verlinken will. Vom Crawling her ist es ein bisschen einfacher. Man muss nicht mit dem hreflang kämpfen, man muss nicht mit Canonicals groß arbeiten, sondern wir sehen dann einfach eine große starke deutsche Version und die können wir dann auch global entsprechend darstellen. Das heißt, wenn es sich für euch nicht lohnt, wirklich unterschiedliche Versionen zu machen, dann würde ich, wenn möglich, wirklich einfach eine einzelne Version machen pro Sprache, statt unterschiedlicher Proland. Ich hätte dazu noch eine Frage. Ich habe eine generische Domäne, ein Punkt-Komm-Domäne und ich habe die ausgerichtet auf Frankreich. In Bezug auf meine erste Frage funktioniert es halt auch nicht. Wenn ich jetzt zum Beispiel bei in Belgien suche, also Google-Bergien, also Tools und das Land-Bergien-Anstelle, dann kommt meine Domäne auch nicht. Ist das denn bei den generischen Domäns so, wenn ich jetzt das Geotargetrigen rausnehmen würde, würde die dann überall erscheinen? Für die Belgien oder für die französische Sprache? Ja, ich wäre da vielleicht ein bisschen vorsichtig mit dieser Einstellung in den Tools, weil so weit ich weiß, ist es wirklich darauf ausgerichtet, schaut, ob die Website speziell von dem Land ist oder für das Land ist und nicht unbedingt ein Vergleich, wie das vom Geotargetrigen her aussehen würde. Ich müsste das ein bisschen genau ausprobieren, aber meines Rissens ist das nicht das Gleiche, wie wenn jemand in Belgien suchen würde, wenn du diesen Filter auf Belgien stellst. Weil da versucht es, glaube ich, wirklich nur die Resultate von dem Land zu bringen. Ja, es wäre interessant, wer das denn überhaupt nutzt. Wenn das keiner nutzt, dann ist es ja eigentlich egal. Ja, meines Rissens, wie man das herkontrollieren kann, wo der Benutzer ist, ist mit dem GL-Parameter in der URL. Das heißt, es gibt ja HL und GL als Parameter in der Suche. Und HL ist für den Language, also für den Sprachcode. Und GL ist für den Geocode, also für das Land. Und da kann man zum Beispiel einfach die Suche machen und dann mit dem Unzeichen zum Beispiel GL gleich CH. Und dann sieht man, wie das in der Schweiz aussehen würde. Okay, probiere ich aus. Sollte man bei mehrsprachigen Webseiten die Bilder mehrfach hochladen und die Dateinamtitel in der jeweiligen Sprache bereitstellen, muss man eigentlich nicht machen. Das heißt, man kann das gleiche Bild nehmen. Wir können verschiedene Landingpages zu einem Bild zuordnen. Und dementsprechend können wir dann auch verschiedene Seiten quasi das Landingpage bringen für ein einzelnes Bild. Wenn die Bilder eh diegleichen sind, dann würden wir dann auch so ähnlich wie bei Webseiten ein Canonical für dieses Bildversuchen herauszufinden und das entsprechend zu verwenden. Von dem her ist es eigentlich ziemlich das Gleiche. Natürlich Dateinamen ist dann halt in einer Sprache. Ja, ich denke, das macht in den meisten Fällen wahrscheinlich, macht das relativ wenig aus. Aber, ja, weiß ich jetzt nicht genau, muss man vielleicht mal ausprobieren. Aber meines Wissens soll das eigentlich problemlos so gehen. Und die Konzentration auf eine Datei bringt das dann ein bisschen mehr Vorteile? Bei den Bildern. Ja. Weiß ich nicht. Also bei den Bildern wird das sowieso so sein, dass wir da ein Canonical für dieses Bild versuchen, so herauszufinden. Manchmal sieht man das auch für die verschiedenen Größen. Das heißt, wenn ich jetzt ein Bild, sag ich mal, ein kleinerer Auflösung für Mobilgeräte haben, größere Auflösung für Desktopgeräte, klappen wir die auch zusammen, weil wir erkennen können, dass das gleiche Bild ist. Und dann sollte das eigentlich automatisch so klappen. Also wäre es eigentlich ähnlich, wenn man das gleiche Bild mit verschiedenen Dateinamen aufladen würde. Also ich kann nicht vorstellen, dass man da einen großen Extrawert in der Bildersuche hat, wenn man ein Bild nimmt, statt mehr Bilder mit dem gleichen Bild, mit dem gleichen Inhalt. Okay. Darf ich dazu noch eine Frage stellen? Ja. Wie ist das dann mit Alttexten? Weil die sind ja dann effektiv das, was wirklich nützt, vor allem für die Bildersuche. Wenn ich also nur ein Bild hochlade, habe ich eigentlich nur einen Alttext in einer Sprache. Der Alttext ist ja auf der Landingpage von der Bild. Und wenn man verschiedene Landingpages hat, dann kann man auch einen anderen Alttext pro Landingpage nähen. Aber das ist dann ein technisches Problem, oder je nachdem müsstest du das Bild 2-mal hochladen, je nach CMS? Ja, gut. Ich denke, das macht eigentlich nicht so wahnsinnig viel aus. Also wenn man zum Beispiel eine Bilddatei auf verschiedenen Seiten implementiert hat, also auf verschiedenen HTML-Zeiten, in verschiedenen Sprachen, dann kann man ja auch unterschiedlichen Alttexts pro Seite an für sich verwenden. Es kann sein, dass vielleicht einzelne CMS nur einen Alttext für eine Bilddatei haben. Aber grundsätzlich könnte man das ja machen, dass man da pro HTML-Zeit unterschiedlichen Alttext hat. Okay, danke. Gute Frage mit den verschiedenen Sprachen bei Bildern. Ich glaube, da haben wir gar keine große Dokumentation dazu. Aber das müsste man vielleicht mal zusammenstellen. In unserem Online-Shop werden nicht mehr vorhandene Produkte per 301 redirect auf eine Sammelseite weitergeleitet, welche einen 200er-Statuscode ausgibt. Dies wurde in der Vergangenheit so angefordert, dass die Linkkraft im Shop bestehen bleibt. Und dann hat es den besten Frage abgeschnitten. Schauen, was nachwarten kann. Diese Seiten werden in der Search Console nun als Soft 404 ausgegeben. Wie wäre hier die korrekte Vorgehensweise? Grundsätzlich würden wir das als Soft 404 ansehen, weil die bisherigen Produkte sind ja jetzt nicht mehr vorhanden. Und dann ist es eigentlich wie ein 404. Also die Seite gibt es jetzt nicht mehr. Wenn man nach diesem Produkt sucht, findet man die nicht mehr bei euch im Shop. Ein redirect wäre dann das Richtige, wenn man ein Ersatzprodukt hat. Das heißt, wenn ein Produkt jetzt nicht mehr auf Lager ist und man ein Ersatzprodukt hat, was eigentlich das mehr oder weniger entspricht, dann kann man da ein redirect machen und von der einen Version zu anderen weiterleiten. Wenn man auf zum Beispiel eine Kategorienseite oder auf eine andere Sammelseite würden wir in den meisten Fällen als Soft 404 anschauen. Ich würde das so angehen, dass ihr euch eher überlegt, wie wollt ihr den Benutzern das präsentieren. Weil die andere Variante wäre ja zum Beispiel einfach direkt eine 404-Seite zurückzugeben. Aus unserer Sicht ist da eigentlich kein großer Unterschied mit einer Soft 404 und einer normalen 404. Und da würde ich mir dann eher überlegen, wie wollt ihr das Benutzern präsentieren. Wenn das für euch okay ist, dass der Benutzern einfach auf eine Sammelseite weitergeleitet wird, könnt ihr das gerne so machen. Dann ist eigentlich diese Sammelseite wie eure 404-Fehlerseite. Wenn ihr das zum Beispiel auf Kategorien-Ebene machen könnt, ist das aus unserer Sicht eigentlich okay. Für Benutzer ist es vielleicht ein bisschen verwirrend. Aber es gibt keinen Sinn machen, dass man wirklich eine klare Seite hat, wo man sagen kann, dieses Produkt gibt es nicht mehr. Aber wir haben jetzt ähnliche oder andere Produkte in der gleichen Kategorie, haben wir jetzt hier vorhanden, wenn das klar quasi dargestellt wird für den Benutzern. Im Grunde genommen sind das eigentlich da die zwei Varianten. Bezüglich dem, dass die Linkkraft im Shop bleibt, ist es natürlich aus unserer Sicht so, dass wenn diese Seiten nicht mehr existieren, dann existieren die nicht mehr auf dieser Webseite. Und dann würden wir das aus Soft 404 oder 404 entsprechend anschauen. Und dann würden auch die Links auf diese einzelnen Produkten auf unsere Sicht nicht mehr existieren, weil die ja auf eine Fehlerseite zeigen. In den meisten Fällen ist das aber nicht wahnsinnig problematisch, weil normalerweise hat man eigentlich eher die meisten Links zum Beispiel auf die Startseite vom Shop oder auf Kategorien, statt auf einzelner Produkten. Wenn man wirklich sieht, dass einzelne Produkte sehr stark Links angezogen haben und man möchte das irgendwie beibehalten, dann würde ich mir überlegen, ob man, sag ich mal, eine Platzhalterseite für diese Produkte und beibehalten kann. Dass man zum Beispiel sagen kann, dieses Produkt haben wir im Moment nicht auf Lager, aber hier sind die ganzen Informationen dazu oder hier sind die Bedienungsanleitung oder die technischen Angaben, dass man irgendwas Informatives dann einfach hat als Ersatz für diese Produktseite. So dass wir diese informativen Informationen trotzdem noch in der Suche zeigen können, wenn jemand danach sucht. Und dann können wir auch die Links, dann können wir dann eigentlich auch weiter verwenden und sagen, man kann das zwar jetzt nicht mehr da kaufen, aber man kann da trotzdem noch mehr Informationen dazu kriegen. Wichtig ist, wenn man das so macht, dass man wirklich auch schaut, dass ein Großteil dieser Seite wirklich auch eigene Informationen zu diesem Produkt ist, nicht, dass es einfach eine Seite ist, wo quasi dieses Produkt gibt es nicht mehr und tschüss quasi, weil dann würden wir diese Seiten auch relativ schnell als SoftFinal4 anschauen, weil da nichts dabei ist, was wir eigentlich wirklich groß indexieren können. Da noch einige Fragen zum Thema Hreflang. Sollen Hreflangs nur auf Canonical Urals existieren oder auf allen Seiten? Aus unserer Sicht könnt ihr Hreflangs auf alle Seiten verwenden. Wir verwenden Hreflangs auch aus einem Canonicalization Signal. Das heißt, wenn wir eine Seite finden auf eurer Website und wir sehen, dass da verschiedene Hreflang-Links vorhanden sind, dann würden wir diesen Links entsprechend auch folgen und versuchen die Hreflang-Varianten zu crawlen und zu indexieren und so würden wir dann eher auch die Canonical-Version von diesen Sprachvarianten finden. Von dem her würde ich die auf jeden Fall die nicht Canonical-Varianten auch zeigen. Normalerweise ist das mit den meisten CMS, ist das ja eigentlich so auch automatisch. Wenn ich eine URL mit einem Parameter aufrufe, dann kommt quasi, kommen die Inhalte dieser Seite ohne Parameter auch dazu. Und wenn da ein Hreflang vorhanden ist, dann hilft uns das auch schon ein bisschen, eher in Richtung von dem Canonical, den ihr haben wollt, auch in die Richtung zu gehen. Sollen Hreflangs nur zu Canonical URLs führen? Ja, idealerweise schon. Ich denke, schwierig ist es hier in den Situationen, wo wir ein Canonical über verschiedene Länderversionen aus unserer Sicht auswählen. Aber selbst da ist es hilfreich, wenn wir die Hreflang-Assignale haben. Wenn wir wissen, dass da zum Beispiel eine deutsche Variante für die Schweiz und für Österreich und für Deutschland vorhanden ist und auch wenn wir eine Variante als Canonical auf unserer Seite auswählen, können wir mit dem Hreflang dann die richtige Variante in den Suchergebnissen zeigen. Das heißt, was da praktisch passiert, ist, wir indexieren eines dieser Varianten, den Canonical Version, und wir wissen, dass die Hreflang-Links funktionieren. Und wenn jemand dann zum Beispiel in der Schweiz sucht, dann können wir die URL austauschen gegen die Schweizer Variante. So sollte das zumindest theoretisch funktionieren. Manchmal klappt das nicht so perfekt und da bin ich immer froh, wenn ich Feedback habe von euch und das dann auch dem Team weitergeben kann. Eine Frage noch dazu. Sollte man denn auch selber Canonisieren, also einfach sagen, okay, man hat drei Versionen und wir packen einfach alles auf die deutsche, die Canonical, also die Canonisierung. Also ich kann mir vorstellen, es gibt ja auch Suchmaschinen, die Hreflang nicht unterstützen. Da wird es ja wahrscheinlich dann Probleme geben. Ja, dass man quasi selber sagt, die Deutschland-Version ist der Canonical-Version, so meinst du? Also, wobei es einfach von allen anderen Online-Shops auf die Deutsche, also von Österreich und von nach Schweiz, sodass nur noch die Deutsche praktisch im Index ist. Ich vermute, dass wir da die Hreflang-Links dann verlieren würden, weil wir würden dann nur die Deutschland-Variante versuchen zu crawl und indexieren und würden dann hätten dann nicht mehr die Möglichkeit, die österreichische oder die Schweizer-Variante entsprechend auch einzulesen und zu verarbeiten. Also funktionieren tut es, wenn man das jetzt so macht, dann das funktionieren schon, aber würdest du... Das funktioniert, okay. Ja, das funktioniert, aber... Also theoretisch aus unserer Sicht wäre das nicht empfehlenswert. Ich könnte mir vorstellen, dass das manchmal funktioniert, aber nicht standardmäßig. Ich müsste aber mit dem Team mal nachfragen, weil gerade in den Situationen, wo wir sowieso alles auf eine Länderversion quasi canonicalisieren würden intern, ist es eigentlich sehr ähnlich, wie wenn du das selber entscheidest, wenn du sagst, gut, ich nehme die Deutschland-Variante als mein canonical Variante und habe einfach Hreflang auf die anderen Version. Aber ich müsste mit dem Team mal nachfragen. Oder wenn du sagst, dass es funktioniert, hast du vielleicht ein Beispiel, den ich da weitergeben kann? Ich habe das wieder ausgemacht, weil ich mir da unsicher war, die stärkste Webseite nehme. Ich hatte mal im Forum gepostet gehabt und Sven hat mir halt mal geantwortet, dass bei mir jetzt die Canonicles immer wieder hin und her springen. Mal ist es die Schweizer Version, mal die deutsche Version. Deswegen habe ich das einmal probiert, auf die deutsche Version alles zu verweisen. Aber ich war mich glücklich damit und habe es wieder ausgemacht. Und jetzt probierst du gerade wieder ohne Canonisierung. Verflank und dann auf Selbstreferenzierung. Mit der Selbstreferenzierung. Ja. Ich müsste das fast mal ausprobieren. Ja. Ich müsste mehr Testseiten haben, um solche Sachen auszuorientieren. Ist immer ein bisschen schwierig. Aber ich könnte mir vorstellen, dass es vielleicht funktioniert. Aber auf jeden Fall von unseren Informationen, die wir dokumentiert haben, können wir eigentlich auf die eigene Version Canonikalisieren. Das heißt, die deutsch-deutschland-Variante auf sich Canonikalisieren und die deutsch-schweiz-Variante auf sich und damit im Hreflang gegenseitig entsprechend verweisen. Das zumindest so, wie wir das empfehlen. Ich könnte mir vorstellen, dass es vielleicht trotzdem funktioniert, wenn man das anders macht, dass unsere Systeme das versuchen, einfach zu korrigieren. Ich hätte noch eine Frage dazu. Die ist mir da nämlich gerade gekommen. Wie sieht das denn aus? Bei uns ist es so auf der Seite, wir haben quasi firm generierten Content, den wir da zeigen. Und da gibt es manchmal dann Produkte, die sind nicht komplett übersetzt. Also die sind dann nur auf Englisch dort. Die ähneln natürlich dann sich, vielleicht auch in mehreren Sprachen, sind sie halt durchgehend Englisch. Wäre das negativ für die Canonical, für den Hreflang, weil Canonical haben wir standardmäßig die Englische und ansonsten halt die Hreflang. Ja. Man kann das schon machen. Was dann einfach schwieriger ist, ist, wenn jemand wirklich auf Deutsch sucht und wir haben das Produkt nur auf Englisch bei euch auf den Seiten, dann ist es schwierig für uns zu erkennen, ist das jetzt genug Deutsch, dass wir das da zeigen sollen oder nicht? Weil was hier in vielen Fällen ist, ist, dass man quasi den Hauptinhalt hat, zum Beispiel auf Englisch und der Rest vom Shop, die ganze Navigation, alles runter rum, ist alles auf Deutsch. Und in solchen Fällen können wir erkennen, dass da zwei Sprachen vorhanden sind auf diesen Seiten, also es ist nicht super kritisch. Mit Hreflang kann man dann trotzdem arbeiten und sagen, das ist jetzt meine deutsche Variante. Wir kennen zwar, es ist nicht vollständig Deutsch, aber das ist eigentlich auch okay. Aber vom Ranking her ist es natürlich schwierig, wenn jemand nach dem deutschen Produkt namensucht und ihr habt das nur auf Englisch auf euren Seiten, dann müssen wir da fast was verraten, ob das jetzt die richtige Seite ist, die wir zeigen sollen oder nicht. Gut, vielen Dank. Mal schauen bei der Frage weiter mit den Canonicals, haben wir, glaube ich, angeschaut. Wenn wir das Suchergebnis seiten in verschiedenen Sprachen indexieren, können wir das Sucherflanks sein, nur wenn bestimmte Suchernfragen in zweiter Sprache auch genutzt werden. Ich vermute, bei Suchseiten macht das nicht besonders viel Sinn. Ich meine, man kann das auf jeden Fall machen. Aber was gerade bei Suchseiten halt eher ist, ist, dass wir das eher verwenden, um neue Inhalte zu finden. Das heißt, wir suchen da eher links zu den eigentlichen Produkten und die Suchergebnisseiten selber sind ja eigentlich in vielen Fällen gar nicht so sichtbar in den Suchergebnissen. Von dem her ist das normalerweise da nicht so wahnsinnig kritisch. Was auch ein bisschen dazu kommt, gerade wenn man verschiedensprachige Inhalte hat, ist, dass Benutzer ja eher in einer Sprache suchen und wir können dann auch aufgrund von den Wörtern, die verwendet werden bei der Suche, können wir eher Seiten finden, wo diese Wörter auch vorhanden sind. Das heißt, wenn wir verschiedene Longtail-Seiten haben und wir da keinen HF-Lang haben, können wir trotzdem erkennen, das ist jetzt die deutsche Variante, das ist die englische Variante, die französische Variante. Und wenn jemand in diesen Sprachen sucht, dann wissen wir eigentlich, welche Variante da passen würde. Und können da vom Ranking her aufgrund von der Sprache selber und nicht unbedingt nur aufgrund vom HF-Lang. Das heißt, ich würde, also zumindest wie unsere Ingenieurs das jeweils gebracht haben am Anfang, ist es so, dass HF-Lang macht vor allem dann Sinn, wenn man wirklich auch Probleme sieht in der Suche. Das heißt, wenn jemand auf Deutsch nach einem Produktnamen sucht und es kommt immer die englische Variante, dass sich etwas mit HF-Lang verbessern kann. Wenn jemand, nach einer Produktbeschreibung sucht, dann sind es ja schon mehrere Wörter in dieser Sprache, dann kommt sowieso automatisch die richtige Variante. Aber es ist eher dann halt wirklich auch kritisch, wenn man einen Produktnamen hat, der so verwendet wird in verschiedenen Sprachen, wenn das zum Beispiel Markennamen der Suche selber welche Sprache gemeint ist. Und dann können wir mit HF-Lang eher die richtige Variante herausholen. Die andere Variante ist natürlich auch über Länder übergreifend, wenn jemand auf Deutsch sucht und in Deutschland ist, dann können wir eher die Deutschland-Variante zeigen, wenn wir wissen, dass es unterschiedliche deutsche Versionen gibt. Uns ist aufgefallen, dass der Googlebot wohl eine JavaScript-Datei bei uns casht, immer noch etwas ausspielt, auch bei neuen Seiten, die er noch nicht kennt, was es in der Form nicht mehr so gibt. Wie lange casht Googlebot diese Dateien und wie können wir ihm klarmachen, dass es sich dort geändert hat. Es ist so, gerade bei Rendering ist es so, dass wir da sehr viele extra Dateien brauchen für das Rendering. Das heißt, die JavaScript-Dateien, an derseits vielleicht Server-Antworten, CSS-Dateien, Bilder, all das wird ja verwendet, um das Rendering zu machen. Das heißt, pro HTML-Seite ist es so, dass wir sehr viel mehr Request brauchen, um eine Seite aufzuladen. Und aus dem Grund machen wir das so, dass wir die Dateien, von denen wir vermuten, dass sie sich nicht so häufig verändern, dass wir die möglichst lange Dateien und beibehalten können. Manchmal kommt es dann zu solchen Situationen, dass wir mit einer älteren JavaScript-Datei arbeiten, obwohl es jetzt inzwischen nicht schon eine neuere Variante davon gibt. Und dass dann irgendwas vielleicht beim Rendering oder so schief geht, dass wir mit dem Cash einfach die falschen Varianten aufheben. Was man da machen kann, ist die JavaScript-Datei mit einer Versionsnummer versehen. Dass man da zum Beispiel den Script einbaut und dann den Script entsprechend mit der JavaScript-Datei in der HTML-Seite einbettet und dann mit einer Versionsnummer da noch versieht. So, dass wir wirklich erkennen können, dass es jetzt eine neue URL ist für diesen Script, dass wir den alten Cash gar nicht verwenden können, weil es jetzt eine neue URL. Aber für diese verschiedenen Versionen müssten wir die JavaScript-Datei neu laden, weil es unter Umständen jetzt eine neue Datei und dementsprechend können wir dann beim Rendering die neue Variante entsprechend auch dazu nehmen. Ich würde da einfach aufpassen, dass man da nicht allzu tief in diese Richtung geht, dass man sagt, gut, jede Veränderung an meiner Website verende ich alle meine URLs, weil das macht es natürlich dann besser, weil wir dann noch viel mehr Requests machen müssen zu einem Server und gar nichts mehr caching können. Das heißt, ich würde das mit der Versionierung dann vor allem machen, wenn man wirklich auch größere Veränderungen in diesen Dateien gemacht hat. Das geht bei JavaScript-Dateien ist das am häufigsten der Fall. Manche verwenden das auch bei Bildern oder bei Video-Dateien und da ist es eher problematisch, wenn man das mit Veränderungen macht, weil gerade Bilder-Dateien und Videodateien, die verändern sich eigentlich nicht groß im Laufe der Zeit und wenn man dann quasi erzwinkt, dass wir eine neue Variante indexieren müssen, dann fällt erstmal die alte Variante aus dem Index heraus und dann bei Bildern geht das einfach entsprechend viel länger, bis die neue Variante wieder indexiert ist und die ganzen Signale, die wir mit der alten Variante gesammelt haben, wieder neu aufbauen. Das heißt, wir müssen erstmal wieder erkennen, wo überall ist dieses Bild eingebaut, welche sind die Landing-Pages, die dazu gehören, wie können wir vom Ranking her diese Seiten bringen, die Landing-Pages mit diesem Bild zusammen. Das sind alles Sachen, die gehen bei Bildern, dauernd die einfach viel viel länger als mit html-Dateien und dementsprechend würde ich, wenn möglich, das so machen, dass gerade bei Bildern, dass man nicht quasi mit Versionierung arbeitet. Bei JavaScript ist das ein bisschen anders, weil das verwenden wir ja eigentlich nur für das Vendron, aber bei Bildern werden die natürlich auch in der Bildersuche dargestellt. Eine Frage habe ich dazu noch, die Frage kam nämlich von mir. Reicht es dann schon, wenn ich sage, okay, so wie es zum Beispiel andere Anbieter dann machen, mit den Fragezeichen v ist gleich eins, das würde vollkommen genügend, also wenn ich so dann versioniere oder muss ich den Dateinamen wirklich anpassen? In den meisten Fällen sollte das reichen. Was einfach passieren kann, ist, wenn wir erkennen können, dass diese Versionsparameter irrelevant sind, wenn wir erkennen können, dass die Datei sich gar nicht verändert und man ständig neue Versionsnummern verwendet, dass wir dann irgendwann lernen, diese Versionsparameter ist egal und den können wir ignorieren. Aber wenn man sie einsetzt und wirklich nur Versionsnummer verändert, wenn die Datei sich verändert hat, wenn man da zum Beispiel mit Content-Hash arbeitet oder so etwas, dann sollte das problemlos gehen. Perfekt, vielen Dank. Wir hatten einen Re-Launch unserer Seite mit einer neuen Domain-Endung vorher RTD-E-C-H, also verschiedene Ländervarianten, jetzt.org die Indexierung Webseiten, Transfer und so weiter wurden eingetragen und Search Console, wie lang dauert das bis alle alten RTD-E- und CH-Ergebnisse durch die neuen Seiten ersetzt werden? Sollen man die alten Seiten auf No Index setzen, derzeit gibt es überall ein 301. Die Weitereitung per 301 ist effektiv das Wichtigste da und ich würde das so lange wie möglich beibehalten einfach, weil wenn wir in Zukunft wieder links finden auf diese älteren CH oder DE oder RT-Seiten, dann versuchen wir die wieder zu crawl und wenn da zum Beispiel eine Seite ist mit einem No Index, dann denkt man, gut, da gibt es nichts zu indexieren und dann lassen wir diese Signale dann entsprechend verhalten und mit einer Weiterleitung können wir das trotzdem immer noch weiterleiten auf die bevorzugte Variante auch Benutzer, wenn sie kommen wenn sie weitergeleitet werden ist das eigentlich die richtige Lösung dort. Bezüglich wie lange das geht bis die ganz rausfallen, ist unmöglich zu sagen weil es sind da verschiedene Sachen die zusammenkommen. Einerseits wenn man verschiedene Websites auf eine zusammenfügt, ist das nicht eine normale Domainweiterleitung von einem Domain zum anderen, sondern dass man da die verschiedenen Websites an für sich zusammenfügt in einer anderen Website solche Veränderungen brauchen in der Regel viel länger zum verarbeiten als ein normaler Domain umzug. Das heißt, wenn ich von einem Domain zum anderen wechsle und alles bleibt sonst gleich, können wir diese Signale möglichst eins zu eins weitergeben wenn man verschiedene Websites zusammenfügt in eine größere Website dann müssen wir das alles eigentlich neu berechnen und das geht in der Regel einfach ein bisschen länger das heißt, immer geht es schon ein bisschen länger wobei man eigentlich auch nicht genau angeben kann wie lange das normalerweise gehen würde aber das dauert da schon ein bisschen länger das andere ist, dass wenn man gezielt nach diesen alten URL sucht, dann versuchen wir die auch darzustellen in den Suchergebnissen obwohl wir vielleicht schon wissen dass sie weitergeleitet werden und woanders hinführen das heißt, wenn ich zum Beispiel eine Site-Abfrage mache für diese CH-Variante oder die AT-Variante dann wird es sein, dass wir eigentlich noch die Inhalte zeigen würden in einer Site-Abfrage weil wir das Gefühl haben der Benutzer möchte wirklich Informationen über diese Website haben wir wissen, dass die Website mal da war die ist jetzt weitergezogen, woanders hingegangen, aber wir wissen immer noch dass sie mal unter diesen alten URLs war trotzdem noch mit diesen alten URLs bei in solchen Fällen ist es so, dass normalerweise, wenn ich nach normalen Begriffen suche also wenn ich nicht eine gezielte Site-Abfrage mache, dann zeige ich mir schon die richtige Variante von dem her ist es nicht so, dass viele sehen würden, aber es könnten trotzdem noch einige sehen man kann das relativ gut dann auch kontrollieren, dass man da weiter anschaut in den Suchergebnissen, dann sieht man dass da quasi die neue URL dargestellt wird, in der gecacheden Seite aber die alte URL in den Suchergebnissen gezeigt wurde und das ist eigentlich schon ein klares Zeichen, dass wir diesen Umzug haben wir eigentlich schon verarbeitet, wir wissen, dass alles unter dieser neuen URL ist wir wissen aber auch, dass es früher mal unter der alten URL war und das ist eigentlich auch okay das heißt, praktisch gesehen dass man technisch diese weite Leitungen sauber eingerichtet dass sie wirklich alle vorhanden sind und dass man einfach überprüft in Search Console müsste eigentlich quasi die älteren die alten Domains die Indexierung müsste langsam runtergehen und bei den neuen Domains müsste die Indexierung langsam hochgehen und die Informationen in Search Performance wird entsprechend auch runtergehen bei den älteren, bei der vorherigen Variante und wieder hochgehen bei der anderen Variante aber es kann durchaus sein, dass es nicht ganz auf Null zurückgeht und das ist aus unserer Sicht eigentlich auch okay und nicht unbedingt etwas was man forcieren muss also mit No Index muss man nicht die alte Variante ganz aus dem Index herauszwingen oder dass sie nie mehr erscheint in den Suchergebnissen, sondern für uns ist es eigentlich auch okay wenn wir wissen, dass es mal weitergeleitet wurde manchmal zeigen wir das vielleicht auch in seltenen Fällen und in meisten Fällen zeigen wir die neue Variante das heißt man muss das nicht per No Index forcieren oder mit den Entfernungsabfragen muss man das nicht irgendwie einreichen an und für sich ist das okay also ich würde da zeitlich würde ich schauen, dass man da das gerade am Anfang ein bisschen besser überwacht vielleicht mit den Log-Dateien auch zum Schauen, dass die redirect wirklich sauber funktionieren vielleicht auch mit dem externen Test-Tool dass man die alten URLs mal crawled und schaut, dass wirklich für alle diese alten URLs ein redirect vorhanden ist und dann würde ich mal grob annehmen, dass das einige Monate dauert bis der Mehrheit diese Seiten wirklich auf den neuen Version vorhanden ist und dass es dann nachher eine Handvoll Seiten noch gibt die vielleicht mit der älteren Variante dargestellt werden Johannes? Ja ich überlege bei meinem Artikel-Markup die beiden Datumsangaben wieder rauszulöschen ich habe das auch beim letzten Hangout mal kurz angesprochen gehabt und jetzt habe ich aber entdeckt, dass ja laut euren Developers-Richtlinien diese zwei Datumsangaben möglicherweise eine Rolle spielen für diverse Serp-Features also beim Artikel-Markup bei den AMP Artikeln sind sie tatsächlich wichtig bei den non-AMP Artikeln was mich jetzt betrifft da gibt es überhaupt keine required also zwingend erforderlichen Attribute aber es sind 4 oder 5 Erwünschte Optionale genannt und zwei davon sind tatsächlich diese Datumsangaben jetzt steht allerdings nur über diesen zwei noch folgender Hinweis mit dabei und zwar schreibt ihr da auf der Developers-Seite das Testtool für strukturierte Daten zeigt keine Warnung für diese Property an da sie nur dann empfohlen wird wenn du da an sich bist dass die Property für deine Website relevant ist also wenn ich jetzt keine User-Artikel habe und auch keine zeitsensitiven Themen bearbeite so dass man also nach gesunden Menschenverstand sagen kann okay, das Datum ich persönlich finde es eigentlich gut für den User es ist eine nützliche Information auch mit Copyright und so weiter aber jetzt so im Allgemeinen brauche ich es nicht das heißt das kann ich dann wirklich aus der Sicht auf eigentlich will ich es ja weg lassen aber auch aus der Hinsicht ist es dann unbedenklich wenn ich die zwei Dinger wieder rausnehmen würde, oder? ja, jedenfalls aber diese zwei Hinweise dann kann das Datum auch kein echtes Kriterium sein das dann mit darüber entscheidet um die Seite dann in den Serbs als irgendwelche Artikelfeatures wenn es so freiwillig ist dass man es machen kann oder auch nicht und normalerweise ist ja das Erfüllung der required oder auch der empfohlenen Attribut ein Kriterium für euch ob man die Webseite dann tatsächlich auch mit den entsprechenden Features in den Serbs bringt oder nicht bringt und deswegen sollte man ja möglichst alle required haben und auch möglichst viele von den Optionalen und wenn es noch weitere gibt kann es auch nicht schaden aber die zwei können dann ja eigentlich kein Kriterium dafür sein, oder? wenn ihr davon habt was für eine Art von Suche das ist und wie ob wir da irgendwie erkennen können dass jemand zum Beispiel aktuelle Informationen haben möchte dann hilft uns ein Datum schon eher zu bestätigen dass diese Seite ist jetzt relativ aktuell oder was quasi vom Datum her da entsprechend dazu passen würde zu dieser Seite und von dem her hängt es wirklich davon ab wie benutze wenn das mal Referenzinformationen sind die sich nicht groß verändern dann ist es ja nicht so dass sie jetzt den neuesten Artikel über den Pythagoras brauchen, sondern die Sachen sind ja schon irgendwie etabliert oder die verändern sich jetzt nicht mehr von einer Woche auf die nächste hingegen vielleicht vielleicht mal geografische Informationen kann natürlich sein, dass auf einmal ein Land eher in den Nachrichten steht und dass man dann eher vielleicht Informationen zu diesem Land haben möchte für diesen Zeitrahmen und dass dann nachher, dass man wieder die Referenzinformationen haben möchte von dem her hängt es wirklich davon ab wie benutze mit diesen Inhalten umgehen das heißt es tankt davon ab wie ihr die Suchanfrage einschätzt im Hinblick auf ihre Aktualitätsrelevanz ja, mehr oder weniger ja okay, gut also wenn es um medizinische Grundlagen Themen geht oder ähnliches das ist ja nichts, wo ihr dann wahrscheinlich sagt dass es Zeit sind ja, ich denke das kann man nicht für allgemein manchmal gibt es ja auch irgendwelche Forschungsdurchbrüche wo man sagen muss dass es jetzt wirklich was Neues zu diesem Thema dann macht es Sinn dass man das auch wirklich auch klar darstellt und sagt ich habe jetzt die neuesten Informationen dazu und in vielen Fällen sind es einfach Fakten die seit Jahren so etabliert sind oder wenn eine aktuelle Grippe epidemie gerade irgendwie umgeht oder so, das wäre auch was Aktuelles da könnte man dann schon auf die Idee kommen zu sagen ja okay dann warte ich noch drauf dass nach dreieinhalb Wochen mittlerweile nachdem die Seiten indexiert sind also das mag ab ist immer noch nicht verarbeitet, ich habe nur bisher das Feedback bekommen bei einer Seite das ging auch ziemlich schnell da waren Sonntagsfehler und bei einer anderen Seite da sind ein paar viele Attribute die vermisst werden allerdings absichtlich, weil auf der Seite geht eigentlich nicht um dieses Attribut das soll eigentlich auch gar nicht in den Serbs erscheinen das ist da nur auf dritter, vierte Ebene tief verschackt und irgendwo da drin und auch nur kurz erwähnt aber ihr greift das auf und erkennt dass das grundsätzlich ein Datentyp ist also es geht um ein Event das grundsätzlich Serbfeatures haben könnte und dann kriege ich da immer die vielen hässlichen Fehlermeldungen, was da alles fehlt und so aber das muss mich nicht weiter jucken also wenn ich auf der Seite auf das gar nicht hinaus will es geht da um über mich Seite und da ich es aber unter Ferner liefen erwähnt dass ich irgendwo mal eine Veranstaltung gemacht habe die auch bereits vergangen ist also kann mir egal sein wenn da Fehlermeldungen kommen genau es ist ja mit diesen Fehlermeldungen ist es ja so dass wir das dann darstellen wenn wir ein Teil von diesem Markup finden und dann denkt mir vielleicht hast du das besonders in den Suchergebnissen darstellen wollen und wenn das der Fall ist dann muss man das natürlich richtig angeben aber wenn du das nicht speziell darstellen möchtest in den Suchergebnissen ist das total ok es ist nicht so dass wir die Seite dann irgendwie herunterstufen würden oder sagen würden die ist weniger wertvoll weil sie weniger Markup hat sondern einfach für diese Feature in den Suchergebnissen bräuchten wir das wenn dir diese Feature egal ist dann ist das total ok und das kann auf Seitenebene sein, das heißt du kannst einzelne Seiten haben wo vielleicht jetzt bei einem eCommerce Shop das Produkt haben im Moment nicht auf Lager, wir haben keinen Preis dann kommt auch schnell die Warnung, Achtung das Product Markup ist auf dieser Seite quasi ungültig, weil kein Preis angegeben ist und auf den anderen Produkten wo man Preise haben die können wir normal verarbeiten die können wir normal mit Product Markup entsprechend auch verwenden es ist nicht so dass der eine Fehler dann den Rest der Website schlechter macht also ihr konzentriert nicht darauf was auf der Seite als Top Level Item angegeben ist sondern ihr schaut auf tiefer alles was an Datentüten da ist und auch wenn das irgendwo nur auf dritter, vierter Ebene verschafft und das haltet ihr es für möglich, dass das trotzdem so gemein sein könnte, dass das ein wichtiger Datentyp ist der vielleicht in den Service, die das irgendwie erscheinern könnte oder sollte ok, gut, danke Kann ich noch eine Frage stellen zum Ranking ich habe also ich habe einen generischen Suchbegriff und zwar das in Flaggen jetzt ist es so, dass bei mir immer wieder also von einem Tag auf den anderen immer wieder gewechselt wird zwischen einer Kategorie und der Homepage die Homepage erscheint so auf Seite 4 und die Kategorie auf Seite 2 was ist der Grund dafür, wie könnte ich das optimieren, also dass ich vielleicht irgendwie mehr Signale auf die Homepage habe gute Frage manchmal ist es ein bisschen schwierig weil wir verwenden ja verschiedene Signale für das Ranking und dann kann es sein dass wir vom Textinhalt her von diesen verschiedenen Varianten das Gefühl haben, dass die eine Art von Seite eher relevant ist oder eher die andere Variante der Seite manchmal spielt auch die interne Navigation eher eine Rolle und da gibt es manchmal überraschende Veränderungen in dem Sinn, dass gerade bei einer e-Commerce Website ist in der Regel, ist die Homepage schon die stärkste Seite und die Kategorien Seiten eher ein bisschen weniger stark und dann die Produktzeiten aber je nachdem wie man zum Beispiel die Verlinkung auf den Produktzeiten macht verteilt sich das Gewicht natürlich dann auch ein bisschen, dann kann es durchaus sein, dass auf einmal die Kategorien Seiten fast so stark sind wie die Homepage und dann schwankt es dann halt manchmal zwischen diesen beiden Varianten je nachdem wie wir vielleicht die Texte einschätzen auf diesen Seiten das heißt vom Praktischen her ist es natürlich schwierig zu sagen was man da jetzt groß anders machen könnte ich würde auf jeden Fall textlichen Inhalten mal schauen ob man das wirklich auch klarstellen kann welches dieser Seiten eher relevant sein kann und von der internen Verlinkung her würde ich mir überlegen wie man wirklich auch eine klare Hier-Hie darstellen kann wo man sagen kann, das ist wirklich immer die stärkste Seite und die anderen Sachen werden immer weniger stark es kann manchmal auch sein dass man okay ist mit einer Kategorien Seite die in den Vorgängnissen für eher generische Termen auch rankt wenn man sieht, dass vom Performance her vom Conversion her dass die Kategorien Seite vielleicht mal besser funktioniert als die Homepage von dem her gibt es da nicht eine Regel die für alle da funktionieren würde aber ich würde in erster Linie schon eher auf die textlichen Inhalte und dann vielleicht im zweiten Moment auch überlegen wie die Verlinkung quasi unterhalb der Kategorien Seite funktioniert wie man das auch klar darstellen kann dass von den Produkten geht es eher zur Homepage, wenn man eher die Homepage bevorziehen möchte wenn man vielleicht Nachrichten Seiten, Informationszeiten hat, dass es dann auch eher zur Homepage geht, statt zur Kategorien Seiten manchmal ist das ein bisschen überraschend wie man das zusammenstellen kann also in Österreich funktioniert so in der Schweiz auch, also da kommt immer die Homepage und auch sehr weit oben nur halt in Deutschland es wird immer wieder ausgetauscht die URL, also die Seite würde es was bringen, wenn man intern mit dem Begriff Flaggen vielleicht auch verlinkt zur Homepage vielleicht, ja würde ich mal ausprobieren also von den Kategories Seiten jetzt nicht zurücklinken mit Startseite vielleicht einen kleinen Text schreiben und dann halt mit Flaggen zurücklinken ja könnte man ausprobieren, das sich eigentlich relativ schnell ausprobieren, mal schauen ob das verwendet was verhilft da ok, alles klar, danke schön cool ok, zeitlich sind wir jetzt schon am Ende angelangt gegen schnell vielen Dank fürs kommen, vielen Dank für die vielen Fragen die nächsten Hangouts ein wahrscheinlich so gegen Ende Woche und dann sehen wir uns vielleicht in den nächsten wieder ok, dann wünsche ich euch noch eine schöne Woche und bis zum nächsten Mal Tschüss Tschüss