 Okay, herzlich willkommen beim heutigen Google Webmaster Central Sprechstunden Hangout. Mein Name ist Johannes Müller, ich bin Webmaster Trends Analyst hier bei Google in der Schweiz. Und Teil von dem, was wir machen, sind solche Webmaster Hangouts für Webmaster Publisher SEOs. Wie immer habt ihr die Möglichkeit, die Fragen direkt per Google Plus einzureichen. Oder könnt ihr natürlich auch hier im Hangout irgendwelche Fragen stellen. Wenn einer von euch möchte, könnt ihr gerne gerade loslegen mit Fragen anfangen. Ansonsten schauen wir mal die Fragen an, die schon eingereicht worden sind. Und wenn es aus eurer Sicht irgendwelche Unklarheiten gibt oder weitergehende Fragen dazu, einfach nur loslegen. Fangen wir da mal an. Gibt es schon Neuigkeiten bezüglich Start von Google for Jobs im deutschsprachigen Raum? Da weiß ich nicht von nicht speziell, wie das weitergeht, wie das sage, plant wird. Ich habe gesehen, dass es jetzt in einigen weiteren Ländern verfügbar ist. Vielleicht wird das jetzt ein bisschen breiter weitergeführt. Auf jeden Fall solltet ihr da eigentlich von uns allgemein auch was hören, wenn das so weit kommt. Dann gibt es da eine lange Fragen mit vielen Unterfragen. Okay, fragen wir da mal an. Ich betreibe mehrere Projekte und manchmal macht es thematisch hin, dass ich von einem Projekt auf das andere verlinke. Nicht ständig, aber wenn es für mich Sinn macht und den User ein Mehrwert bietet, gibt es da eine Faustregelabwand, dass für Google problematisch ist. Aus meiner Sicht ist es in der Regel unproblematisch. Wenn das jetzt so handvoll Webseiten sind, die auf die ihr weiterleitet, an denen ihr auch arbeitet, ist es in der Regel unproblematisch. Ich würde einfach sicherstellen, dass das nicht übertrieben ist, dass ihr da nicht so ein riesiges Link-Netzwerk aufbaut mit diesen einzelnen Projekten, sondern dass das wirklich in einem normalen Rahmen ist. Normalerweise ist es auch so, dass es oft mehr Sinn macht, weniger Projekte zu betreuen und die einfach ein bisschen stärker zu machen, als irgendwie alles in einzelne Websites aufzusplittern und dann einzeln indexieren und crawlen zu lassen. Weil wenn das weniger Seiten sind, wenn das weniger Websites sind, dann haben sie oft die Möglichkeit auch einfach ein bisschen stärker für sich zu stehen und ein bisschen für Google oder für Benutzer auch ein bisschen mehr Wert anzusammeln. Ist es für Google okay, wenn man gewisse Crawler zum Beispiel Ahrefs oder Moz blockiert oder wird diesen irgendeiner Art und Weise negativ gewertet? Aus unserer Sicht ist das total egal, was ihr mit anderen Crawlern, Suchmaschinen oder Tools oder so macht. Wir crawlen die Seiten mit Google-Word. Und wie andere Crawler da behandelt werden, ist an und für sich eure Sache. Gibt es für Google einen Unterschied, ob man internationale Ausrichtungen über die Einstellungen in Search Console vornimmt oder per hreflang? Ja, das sind an und für sich unterschiedliche Einstellungen. Das heißt, die internationale Ausrichtung ist das sogenannte Geotargeting. Das hilft uns festzustellen, welcher Teil der Website oder welche Website insgesamt für einzelne Länder ausgerichtet ist. Das hilft uns dann bei lokalen Suchen, dass wir diese Seiten dann ein bisschen höher ranken können. Und hreflang ist hingegen etwas, was uns hilft, da die wichtige Version am richtigen Moment zu zeigen. Das heißt, es ändert das Ranking nicht. Es tauscht dann einfach die URLs entsprechend aus, wenn ein Benutzer aus einem Land sucht und wir wissen, dass da jetzt eine Variante für diesen Benutzer auch besser passen würde als die gegebenen Seite, dann tauschen wir die einfach aus. Das heißt, das Ranking bleibt gleich für diese Seiten. Es wird einfach eher die richtigere URL angezeigt. Dann geht es gleich weiter mit einer ähnlichen Frage bezüglich Deutschland und Österreich, dass man da Artikel auf der deutschen Website in Österreich veröffentlichen möchte. Wie kann man das am besten machen? Ich würde in einem solchen Fall beides machen. Das heißt, beides die internationale Ausrichtung einstellen und per hreflang zu arbeiten mit der internationalen Ausrichtung ist natürlich so, dass man von diesem Ranking bei lokalen Suchen ein bisschen einen Vorteil herausholen kann und mit dem hreflang können wir einfach sicherstellen, dass die richtige Version eher gezeigt wird. Kann es zu Problemen kommen, wenn man das hreflang tag erst zum Beispiel nach zwei Jahren setzt? Statt von Anfang an aus unserer Sicht ist das vollkommen okay. Das gibt es hier noch nicht so lang, das hreflang und von dem her ist es normal, dass viele Websites das erst nachträglich eingebaut haben. Ist es abzuschätzen, wann es soweit sein wird, dass der Algorithmus so gut sein wird, dass Links überhaupt keine Rolle mehr spielen? Links haben einen so großen Manipulationspotenzial und der Folge, dass Seiten mit Link-Content seit Jahren auf Platz 1 gibt, obwohl andere Seiten zehnmal besser sind oder Mehrwert für die User bieten. Ich denke, in vielen Fällen werden Links von SEO ein bisschen überschätzt. Wir verwenden schon Links für einige Sachen innerhalb der Websuche. Ich denke, dass wir so schnell auch nicht weggehen. Auch andere Suchenshien, die zum Teil Experimente gemacht haben, ganz auf Links zu verzichten, verwenden die auch. Von dem her vermute ich nicht, dass die wirklich von einem Tag zum nächsten verschwinden werden. Züglich, was ist das, First Link Priority? Werden die Links im Menu einer Seite immer noch als First Link angesehen? In der Regel muss man sich da eigentlich keine Sorgen machen, welche Links auf einer Seite zuerst gefunden werden. Also würde da nicht allzu groß Zeit verlieren mit solchen Sachen. Gibt es eine Möglichkeit, sich aus einem Manual Penalty zu 100% zu erholen? Also so, als wäre nie etwas passiert? Ja, klar, eine manuelle Maßnahme ist, wie der Name sagt, einfach eine manuelle Maßnahme. Und wenn die beobene ist, versteht die nicht mehr. Dann ist eigentlich der Zustand wie vorher wieder da. Es hängt natürlich immer ein bisschen damit zusammen, wofür diese manuelle Maßnahme war und was entsprechend korrigiert wurde. Wenn das zum Beispiel für etwas ist, was auf der Website war und man hat das beobene und die manuelle Maßnahme wird entsprechend beobene, dann ist die Website ja eigentlich, wie sie vorher wieder war. Wenn hingegen die manuelle Maßnahme zum Beispiel wegen unnatürlichen Links war und man behebt diese unnatürlichen Links und man behebt dann die manuelle Maßnahme, dann ist es natürlich so, dass die Website vorher aufgrund von diesen unnatürlichen Links vielleicht anders platziert war in der Websuche. Und wenn diese unnatürlichen Links weg sind, dann ist einfach der natürliche Zustand ein bisschen anders als das vorher war. Und von dem her erholt sich die Website natürlich schon von dieser Situation. Aber das heißt nicht, dass sie nachher am gleichen Ort steht, wie sie vorher war. Dann... Jonas? Ja. Ich habe vorhin eine E-Mail geschrieben, die bis jetzt vielleicht noch nicht dazugekommen. Und zwar habe ich heute die Nachricht erhalten, dass die Website von einem Projekt, das sie begleiten, umgesteckt wurde auf dem Mobile First Index. Jetzt habe ich mir das Projekt angesehen und habe bei Google gesucht und habe dann den Hinweis bekommen, deine Seite ist für mobile nicht optimiert. Hab mir dann auch den Tipp zu herzen genommen, mal im Cage nachzuschauen, ob da die mobile Version drinnen ist. Und da kam dann eine 404. Gibt es da schon eine Empfehlung, was wir jetzt als Webmaster tun sollen oder ist das mal nur vorübergehend und in zwei Wochen anders? Also wie meinst du? Also die Sache ist das. Ich warte, ich rufe mir nur schnell das Suchergebnis nochmal auf, das ich da geschickt habe. Und zwar, es war die... Es steht, wenn ich die Webseite aufrufe in der Google Suche, das ist der Grünauer Hof, wenn ich nach dem Suche, dann steht hier, deine Seite ist nicht für Mobilgeräte optimiert, habe aber die Nachricht erhalten, also eine E-Mail von der Search-Konsole, Mobile First Index Enabled vor und genau diese Seite. Das ist jetzt für mich gerade umschlüssig und habe eben dann den Tipp vom letzten Mal genommen, wo du gesagt hast, schaut euch die Cage-Version an und ihr wisst dann, ob ihr schon im Mobile First Index seid und wenn ich die Cage-Version anschaue, bekomme ich eine 404. Okay, ich denke, das sind zwei, zwei unterschriebenen Sachen. Einesseits, wir haben nicht eine Bechersterik auf allen Seiten und manchmal gibt es einfach aus technischen Gründen, zeigen wir die dann auch nicht an. Das ist wahrscheinlich das, was du da siehst, bezüglich Mobile First Indexing und der gCash-Version sieht man natürlich den Unterschied, wenn man unterschiedliche Inhalte in der gCash-Version sieht oder auf der mobilen Version hat, dann sieht man das im Cash entsprechend auch. Wenn das hingegen die gleichen Inhalte sind, wenn das zum Beispiel eine Response-Webseite ist oder eine nur Desktop-Webseite ist, dann sieht man natürlich auch keinen Unterschied in der gCash-Version. Das andere, bezüglich Mobile First Indexing und nicht für Mobile-Geräte optimiert, ist ein bisschen was anderes. Das heißt, Mobile First Indexing bezieht sich auf die Indexierung und das bezieht sich nicht auf Mobile Friendly. Das heißt, es ist egal, ob die Seite jetzt für Mobile-Geräte optimiert ist oder nicht, sie wird einfach so entsprechend jetzt indexiert. Das heißt, in vielen Fällen ist es ja auch so, wenn ich jetzt nur eine Desktop-Version einer Website habe, dann ist das ja eigentlich das Gleiche auf Mobil wie auf Desktop, auf Mobilgeräte muss man halt suchen, damit man die Inhalte entsprechend sieht, aber die Inhalte selbst sind ja eigentlich gleich. Das heißt, für solche Websites, wenn man die auf Mobile First Indexing umstellt, verändert sich eigentlich nichts, weil inhaltlich ist alles noch gleich, von Links her, von Bildern, Strukturdata ist ja eigentlich alles gleich auf der mobilen Version, die eigentlich die Desktop-Version ist. Von dem her ist das ein bisschen verwirrend, dass beide halt mit Mobile, Mobile First Indexing und das andere Mobile Friendly, könnte man das nicht zusammenhängen, aber an und für sich sind das ganz separate Konzepte. Okay, danke. Also, ich wäre noch interessiert, wenn du irgendwelche Änderungen siehst, im Indexing oder im Ranking, für diese Seite, wäre ich noch interessiert, wenn du irgendwelchen Feedback schicken kannst, weil bisher hören wir von den meisten, das ist eigentlich so quasi, ich habe das E-Mail bekommen, aber es hat sich nichts verändert und das ist eigentlich für uns ein gutes Zeichen. Okay. Super. Die letzte Frage von dieser Mega-Sammlung von Fragen, wie werden Social Signals von Google gemessen? Woher hat Google die Daten? Wie oft eine Seite aus Facebook und so weiter angeklickt wird? Wie verenden Social Signals nicht? Das heißt, wir müssen sie auch nicht messen. In vielen Fällen ist es ja sowieso, dass die Links von diesen ganzen Social Networks CDA per No Fall aufhersähen, von dem her gibt es eigentlich nicht wahnsinnig viel, um einzusammeln. Bitte erklären nochmal, was genau bei einem gesetzten Kanalekul passiert und zwar auf der verweisenden Seite Inhaltigen verlandet, welche Signale handelt es sich, folgt Google den Hintern links. Mal kurz schauen. Komplizierte Frage. Bezüglich Produktvariation. Also was mit dem Canonical Tank an und für sich passiert, ist, dass wir da, gerade wenn wir in eine Situation kommen, wo wir sehen, dass zwei Seiten eigentlich die gleichen Inhalte haben oder fast die gleichen Inhalte, dann können wir mit dem Canonical Tank ein bisschen eure Meinung quasi dazuhören, welche von diesen URLs ihr indexiert haben möchte. Und das ist eben die Canonicalization Frage an und für sich. Wir nehmen da verschiedene Signale zusammen. Einerseits den REL Canonical, andererseits redirects, interne Verlinkung, externe Verlinkung, sitemaps, hreflang, all das spielt ein bisschen eine Rolle. Aufgrund von diesen Signalen schauen wir dann diese beiden Seiten an oder wenn das mehr oder was sind. Manchmal sind das ja ganz viele Seiten, die eigentlich gleich sind. Nehmen wir diese Seiten, schauen die Signale an und schauen, was jetzt für welches diese URLs sprechen wird und die URL, die quasi am meisten Signale kriegt, ist ganz vereinfacht gesagt, die wählen wir dann entsprechend aus. Und das ist dann unser Canonical URL und von dieser Seite nehmen wir dann die Inhalte für die Indexierung. Das heißt, wenn ich jetzt verschiedene Seiten habe, die leicht unterschiedlich sind, aber an und für sich sonst gleich sind, dann wenn wir da ein Canonical URL für diese Seiten aussuchen, dann nehmen wir nur diese Seite und die Inhalte auf dieser Seite für die Indexierung. Das heißt, bei deiner Frage bezüglich Produktvariation, wenn ich zum Beispiel verschiedene Produktvariationen habe und ich wähle eine dieser Variationen aus Canonical aus und Google folgt diesen Hinweis, dass wir diese Seite aus Canonical nehmen sollen, dann verlieren wir an und für sich die Inhalte von diesen nicht Canonical Seiten und indexieren die nicht. Das heißt, wir indexieren dann wirklich nur die Seite, die wir aus Canonical ausgesucht haben. Was man da natürlich machen kann, ist, wenn man jetzt, sag ich mal, verschiedene Urals hat für Variation und ein URL hat für dieses Produkt allgemein, dann kann man natürlich ein Canonical auf dieses allgemeine Produkt setzen, wo vielleicht die Variationen aufgelistet sind und verlinkt werden und dementsprechend haben wir dann alle Variationen auf dieser Canonical Seite und so verlieren wir an und für sich die Informationen nicht. Adam Jones? Ja. Wie bewertet denn Google die ausgehende, also die Rück-Links praktisch zu den Canonical, also zu den verweisenden Seiten auch nochmal, also wenn wir jetzt diese Hauptvariante haben per Canonical dann von der Variante verweisen, dann gibt es ja diesen Link wieder zurück zu der verweisende Seite. Also als ausgehender Link wird das dann auch nochmal irgendwie zusätzlich bewertet, weil die Inhalte verloren von der Variante. Ja. Wie meinst du mit dem ausgehenden Link? Ja, also ich verlinke von der, sagen wir mal einfach, von der Kategorie Seite zurück zu der verweisenden Seite. Ja. Bewertet Google da irgendwie noch diesen Link, also irgendwie muss der Google bewerten, dass jetzt dieses Canonical richtig ist und auch mehr Wert bietet für den Link. Ja. Wir nehmen, also was gerade bezüglich Links passiert ist, wir falten das eigentlich dann alles zusammen in diese Canonical-Variante. Das heißt, wenn jetzt ein Link auf diese eine Produktvariante gezeigt hat, dann und wir eine andere Variante als Canonical nehmen, dann nehmen wir für uns diesen Link eigentlich auf diese Canonical Seite. Das heißt, wenn ich von der Canonical Seite auf die Produktvariante verlinke, dann ist das wie ein Link auf sich selber, dann verändert das ja eigentlich nicht wahnsinnig viel. Aber die Canonical Seite wird stärker, dadurch, dass man jetzt viele zusammenfaltet, hattest du ja beim letzten Mal auch irgendwie gesagt? Ja, weil wir haben dann einfach eine stärkere Seite statt, diese einzelnen Varianten. Im Prinzip würde ich vermeiden, dass man so verschiedene Varianten zusammenklappt, weil das sind ja eigentlich nicht wirklich identische Seiten. Ähnlich ist es, wenn man mit Canonical Sprache oder Länder übergreifend arbeitet, dann sind das ja eigentlich verschiedene Varianten, die separat auch indexiert werden können. Da wäre ich immer ein bisschen vorsichtig, dass man sagt, gut, wir nehmen all diese Varianten und setzen einen Canonical dazu. Das würde ich eine andere Situation machen, wo sicher ist, dass auf der Canonical Seite alle Varianten irgendwie aufgeführt sind und wo man wirklich auch sicher ist, dass sonst keine Informationen von diesen nicht Canonical Varianten verloren geben würden. Dass da wirklich nichts, sag ich mal, Wichtiges irgendwie auf den nicht Canonical Seiten steht, dass nicht auf der Canonical Version auch stehen wird. Okay. Ja, eine weitere Frage zu Hreflang. Soll ich Hreflang überhaupt nutzen, wenn die Sprache eindeutig durch Ordner, zum Beispiel Strich EN oder den Inhalt erkennbar ist und eine Ausrichtung auf Länder nicht nötig ist. Muss man, muss man eigentlich nicht machen. Also Hreflang ist etwas, das würde ich vor allem dann nehmen, wenn ihr sieht, dass wir die falsche Version in den Suchegebnissen zeigen und ihr uns das irgendwie mitteilen wollt und sagen wollt, hey, diese Version ist jetzt wirklich für Deutschland oder auf Deutsch und statt der französischen Version, je nachdem wie das halt eingerichtet ist. In der Regel mit den Sprachen ist es so, dass wir die Sprache der Seite eigentlich relativ gut erkennen können und die Sprache von den Suchern fragen, können wir auch relativ gut erkennen und so können wir eigentlich in den meisten Fällen schon die richtige Sprachvariante machen. Das Schwierige ist es, wenn eine Sprachvariante für mehrere Länder gilt und hier wirklich gezielt einzelne Länder ansprechen wollt, dann macht es sicher Sinn. Oder wenn ihr sieht, dass die Suchanfragen mehr deutlich sind bezüglich der Sprache, das sieht man vor allem dann, wenn jemand zum Beispiel nach einer Marke sucht, dann ist ja eigentlich die Suchanfrage ein bisschen unklar, welche Sprachvariante wird jetzt gemeint wenn du jetzt jemand, vielleicht mal in einer Marke sucht. Google ist vielleicht ein bisschen blöder Beispiel, aber in einem Marke halt, wenn man danach sucht, welche Sprachvariante möchten die Benutzer sehen, ist eigentlich unklar. Und dementsprechend zumindest für die Homepages oder vielleicht die größeren Categorypages macht es wahrscheinlich Sinn, dass man da mit dem hreflang sagt, hey, das ist jetzt die Version für Deutsch, das ist die Version für andere Länder oder je nachdem man einrichten möchte. Und von dem her ist es sicher nicht notwendig, dass man immer mit hreflang arbeitet, aber gerade wenn ihr sieht, dass wir manchmal die falsche Version zeigen, könnt ihr uns so entsprechend nachhelfen. Was ihr auch machen könnt, ist natürlich mit einer JavaScript Banner auf den Seiten zu arbeiten, so dass wenn ihr erkennen könnt, dass die Benutzer auf die falsche Version kommen, dass ihr dann auch sagen könnt, hey wir haben eine Version auf Deutsch verfügbar, hier kannst du klicken und dann kommt es zur deutschen Version. Und so kann man Benutzer auch ein bisschen weiterleiten auf die richtige Sprach- oder Länderversion, egal wie sie zu euren Seiten kommen. Dann eine Frage mit hreflang und canonical und noindex mit der Kombination. Ich denke, das ist wie gesagt ein bisschen schwierig. Wenn man mit hreflang und canonical arbeitet, das heißt, wenn man sagt, das ist jetzt die deutsche Version, das ist die französische Version und dann mit dem canonical sagt, die deutsche Version ist meine canonical Seite, dann wenn wir diese Anweisung folgen, dann würden wir die französische Seite ganz verlieren. Und wenn jemand auf französisch sucht, dann finden wir die Seite gar nicht, weil wir die deutsche Version aus canonical ausgewählt haben ist diese Kombination. Bei einem Relaunch planen wir die Website Bilder in unterschiedliche Größen für Mobile und Desktop auszuliefern. Es ist wichtig, dass sich der Datiname der Bilder unterscheidet. Die Bilder werden vom CMS ausgegeben. Ich denke, das macht auf jeden Fall Sinn, dass wir unterschiedliche URLs haben für die verschiedenen Bildergrößen. Das ist mit einem Source Set Element zu arbeiten im HTML, wo man gezielt wie responsive Design angeben kann. Für dieses Bild habe ich Varianten in dieser Größe oder in dieser Größe. Und so ist es auch möglich für uns, für die Bildersuche, beide Varianten zu sehen. Und dann je nachdem, wenn jemand nach einer größeren Version sucht, dann können wir diese Variante in die kleinere Version entsprechend nehmen. Von daher würde ich auf jeden Fall separate URLs nehmen und das möchte ich so markieren, dass wir beide Varianten auch finden können. Dann eine Frage zur Software 04 Trotz Erreichbarkeit. Auf unserem Reiseportal können unter anderem Hotelübernachtung gebucht werden. Jedes Angebot der angeboten Hotel verfügt dabei über eine individual URL. Auf den Detail zum Hotel auch die aktuelle Buchungsverfügbarkeit dargestellt wird. Vor einigen Monaten ist nun das Problem aufgetaucht, dass für diese Hotel URLs in Search Console immer dann ein Software 04 Fehler gemeldet wird, wenn zum Zeitpunkt des Aufrufs keine freien Zimmer verfügbar sind. Die URL ist aber reichbar und die Seite enthält weiterhin alle beschreibenden Texte und Bilder. Es können im Moment einfach keine Zimmer gebucht werden. Verliert eine URL e-Ranking wenn Google diese einen Software 04 zuordnet. Ja, wenn wir das Gefühl haben, dass diese Seite sei ich mal nicht oder dieses Produkt oder was ihr da anbietet, entsprechend nicht mehr verfügbar ist, dann kann es sein, dass unsere Systeme das aus Software 04 ansehen und sagen, gut, das ist jetzt nicht mehr verfügbar. Also macht es nicht Sinn, dass wir das in den Suchergebnissen irgendwie zeigen und dann kann es sein, dass wir das aus Software 04 erkennen und wenn das aus Software 04 erkannt wird, dann wird das nicht in den Suchergebnissen gezeigt, denn es ist handelfüßig wie ein 404 Fehler. Sobald sich das wieder ändert, also wenn wir die Seite wieder neu crawl und sehen, dass wir die normal zeigen können in den Suchergebnissen, dann taucht sie natürlich wieder normal auf in den Suchergebnissen, also die vorher war. Wie können wir dafür sorgen, dass Hotel URLs, die zum Zeitpunkt der Abfrage keine freien Zimmer haben, nicht mit einem Software 04 bestraft werden? Gute Frage. Wenn ihr so Beispiele habt, wäre ich froh, wenn ihr die mir mal zuschicken könnt, dann kann ich das mal hier anschauen mit dem Team. Im Grunde genommen kann ich mir aber vorstellen, dass das eigentlich so korrekt funktioniert. Das heißt, wenn wir zum Beispiel eine Produktseite finden und da steht drauf, dieses Produkt ist nicht verfügbar, dann macht es ja eigentlich auch Sinn, dass wir das in den Suchergebnissen nicht zeigen. Hingegen wenn das jetzt eine Produktseite ist, die weiterhin einen Wert hat, weil sie vielleicht, ich weiß nicht, einfach nur temporär nicht erreichbar ist, ist es vielleicht etwas, was wir irgendwie anders verarbeiten müssten bezüglich Software 04. Vielleicht macht es aber auch Sinn, dass man das anders auf der Seite markiert, dass man nicht sagt, dieses Produkt ist nicht mehr verfügbar, sondern dass man da vielleicht einfach das Buchungs die Buchungsvariante entsprechend anpasst, dass man sagt, in diesem Zeitraum ist es jetzt nicht verfügbar, aber zu anderen Zeitraum ist es nicht verfügbar. Webseiten können ja mit Unterseiten Sternen in Suchergebnissen bekommen, mit der Startseite geht das bekanntlich nicht. Hier erlaubt Google ja keine Sterne beziehungsweise ignoriert die Sternenarztzeichnungen im Quelltext. Wir gehen jetzt mit unseren Kunden Webseiten um welche oder wie gehen wir mit diesen Seiten um welche Bewertungen bestehen. Kann man da etwas machen oder nicht? Grundsätzlich kann man da schon Bewertungen auch auf diesen Seiten nehmen. Wichtig ist einfach, dass man wirklich den Struktur der Richtlinien entsprechend entspricht. Das heißt, die Bewertung soll sich ja auf die Hauptinhalt dieser Seite eigentlich entsprechend dem widerspiegeln. Manchmal ist das mit einer OnePager Website über eine Firma schwierig, dass man da Benutzer Bewertungen angeben lässt, die dann entsprechend dargestellt werden auf einer Seite. Von dem her müsste man sich wahrscheinlich überlegen, wie man das sauber intermittiert. Wichtig ist ja auch, dass gerade bei solchen Sternbewertungen, auch Bewertungen aussucht, sondern dass Benutzer wirklich die Möglichkeit haben, diese Bewertungen anzuschauen und entsprechend neue Bewertungen quasi einzureichen. Und manchmal geht das mit einer OnePager Website nicht so einfach. Aber theoretisch sollte das eigentlich schon machbar sein. Du hast uns im letzten Hänger Tipps zum Umgang mit ungewohnten Video Thumbnails in Snippets gegeben. Dann noch ein Beispiel. Wir legen großen Wert auf Videos, dass sie unserem User auf einfache Art und Weise wertvolle Informationen zu unseren Produkten übermitteln. Deshalb haben wir sehr viele Videos auf fast allen unseren Seiten. Wir würden nun über die Robots Text alle MP4-Dateien blockieren, um Video Thumbnails zu vermeiden. Wir sind uns jedoch nicht sicher, ob das tatsächlich der beste Weg ist und wie es sich auf rankings auswirkt, wenn Googlebot keine bewegten Inhalte mehr findet. Könnte wie schädlich sein. An und für sich für die Web-Suche ist das vollkommen okay, wenn ihr Bilder oder Videos entsprechend per Robots Text blockiert. Dann wir beschränken uns ja sowieso auf die textlichen Inhalte der Seite für die Web-Suche. Für die Videosuche ist es natürlich so, dass wenn wir diese Videos nicht mehr sehen, dass sie nicht in der Videosuche zeigen. Ähnlich für die Bildersuche, wenn die Bilder blockiert sind, kann man das entsprechend in der Bildersuche auch nicht mehr zeigen. Eine Sache, die man auch machen könnte, ich weiß nicht, ob das bei euch Sinn macht, ist, dass man mit dem Exploration-Date arbeitet. Das heißt, dass man für diese Videos oder für diese Seiten mit einer Videosite-Map arbeitet, wenn ihr nicht indexiert haben wollt und dass ihr in der Videosite-Map gezielt angibt, diese Videos sind an und für sich jetzt nicht mehr gültig. Das heißt, man kann einen Exploration-Date angeben in der Videosite-Map und sagen, dass diese Bilder zum Beispiel im letzten Jahr abgelaufen sind und jetzt nicht mehr gültig sind. Und so, wenn wir dann die Videos anschauen, dann können wir ja unter Umständen trotzdem noch die MP4-Dateien anschauen, dass sie nicht mehr gültig sind und zeigen sie entsprechend dann auch nicht mehr als Videosnippet in den Sucher geben müssen. Neulich hast du dich per Twitter zum Thema Rendering und Canonical geäußert und das Google und das Canonical Tank nur im HTML-Code der Website auswertet, nicht im gerenderten Code, wenn dich zum Beispiel per JavaScript integriert werd. Gilt das auch für andere Elemente Robots oder previous one next. Und unter Umständen. Also gerade bezüglich Rendering und der quasi HTML-Version, die wir ursprünglich kriegen, ist es so, dass wir den Canonical nur aus der statischen HTML-Seite lesen und nicht aus der gerenderten Version. Das ist es auch mit dem Link zur AMP-Seite, also zum der linkwell AMP HTML. Meines Wissens werden die meisten anderen tags trotzdem noch normal gelesen. Das heißt, wenn wir per Rendering etwas finden, dann versuchen wir dementsprechend zu folgen. Aber gerade mit dem Canonical und mit dem link AMP HTML ist es so, dass wir da möglichst schnell eine Entscheidung treffen wollen und dementsprechend nehmen die Informationen, die in der statischen Version vorhanden sind. In vielen Fällen ist es natürlich so, dass ein Canonical nur ein Signal von vielen ist und dementsprechend wählen wir dann trotzdem noch die richtige Seite als Canonical aus. Aber wir machen das nicht aufgrund vom Linkwell Canonical, wenn das per JavaScript nur gesetzt wird. Mit dem MetaRobots ist es ein bisschen komplizierter, in dem sehen, dass wenn die Seite ein Noindex zum Beispiel in der statischen Version hat, dann werden wir die Seite in vielen Fällen gar nicht erst rendering und dementsprechend sehen wir dann nicht, ob per JavaScript diese Noindex vielleicht umgeschaltet wird auf ein Index. Ähnlich ist es mit einem Index auf der Website, wenn das per JavaScript auf Noindex umgestellt wird, ist natürlich immer ein bisschen zeitliche Verzögerung dabei. Das heißt, wir indexieren erst einmal die statische Version in der Mitte der Moment, vielleicht nach einigen Tagen oder so, sehen wir, dass das umgestellt wird auf Noindex und dann erst lassen wir die Seite aus dem Index entsprechend fahren. Von dem her soweit wie möglich würde ich schon versuchen die richtigen Tags direkt in der statischen Version auch auszuliefern oder zumindest dafür zu sorgen, dass sie nicht kritisch sind für das Indexing dieser einzelnen Seite. Seitdem der Mobile First Index ausgerollt wurde, dreht sich die Indexierung unserer Website wortwörtlich durch. Wir haben in den letzten Monaten kontinuierig unseren Content, the landing pages, the usability of mobile Geräte und vieles mehr verbessert, doch seit der Umstellung beobachten wir ein ständiges Auf- und Ab, unsere Sichtbarkeit in den organischen Google Rankings. Das ist ein bisschen schwierig zu sagen, was es genau sein könnte. Wichtig ist einfach gerade bezüglich Mobile First Index, dass das pro Seite ausgerollt wird. Das heißt, wir haben nicht irgendwie den Mobile First Index jetzt eingeschaltet und alle Websites sind jetzt umgestellt. Das heißt, wenn ihr kein Email bekommen habt, dass wir für eure Website das Mobile First Indexing eingeschaltet haben, dann wird eure Website ganz normal indexiert sein. Das heißt, wird dann nicht speziell stattfinden, also außer natürlich die normalen Veränderungen in der Websuche. Von dem her wird das wahrscheinlich wenig mit, also ich vermute jetzt mal, es wird wahrscheinlich wenig mit dem Mobile First Index jetzt hier zu tun haben, sondern es sind einfach normale Veränderungen die ihr in der Websuche seht. Das heißt, was ich daher jetzt versuchen würde im ersten Moment ist vielleicht im Hilferforum darüber mal zu posten und mal Informationen von anderen zu kriegen, was Sie da sehen. Vielleicht sind es da einzelne technische Hinweise, die für diese Seite jetzt helfen würden. Vielleicht ist da irgendetwas, was manchmal geht, manchmal nicht geht, dann dementsprechend in der Suche dann auch zu Schwankungen führt. Vielleicht sind das einfach normale Schwankungen, wie Sie eigentlich in der Suche immer wieder geben können. Wir haben gesehen das Meta Description anzeigenden Google Suchergebnissen wieder auf die ursprüngliche Länge gekürzt worden. Was empfiehlst du Webmaster und SEOs, welche nun alle Seiten auf die langen Descriptions angepasst haben? Gut, wir haben ja nie gesagt, dass ihr eure Seiten auf die langen Descriptions anpassen soll. Von dem her weiß ich nicht, was ich da groß sagen soll. Im Grunde genommen soll ja der Meta Description eine kurze Beschreibung sein über die Seite. Und manchmal hat man eine kurze Beschreibung, manchmal hat man eine längere Beschreibung, manchmal vielleicht mehrere Sätze als Beschreibung und ich denke, diese allgemeinen Hinweise, die gelten weiterhin auch in die Länge der Meta Description oder die Länge vom Snippet, wie sie dargestellt werden kann ja auch immer variieren. Das heißt, manchmal zeigen wir ein bisschen mehr an, manchmal ein bisschen weniger. Das hängt oft von der Suchanfrage ab, vom Geläb, was verwendet wird für die Suche. Das kann sich ja immer verändern. Das heißt, wenn man immer, sag mal, auf die die aktuellen Suchergebnisse reagiert und immer gerade alle Anpassungen macht, auf den Seiten passen zu den aktuellen Suchergebnissen, dann hat man halt diese Situation, dass es Veränderungen in Suchergebnissen gibt und dass man dann wieder zurückspringen muss oder etwas anderes machen muss. Aber in Normalfall, wenn man eine gute Beschreibung angegeben hat, dann funktioniert sie auch, wenn sie ein bisschen kürzer ist oder wenn sie ein bisschen länger ist. Bezüglich Ganzlöschen vom Meta Description von allen Seiten kann man natürlich auch machen. Es gibt viele Sites, die haben keinen Meta Description und in vielen Fällen versuchen wir die Texte von der Seite selber zu nehmen, als Meta Description. Das kann ja eigentlich auch gut funktionieren. In einigen Fällen ist es ja auch so, dass zum Beispiel ein CMS vorhanden ist und einfach die ersten zwei Sätze von Inhalt nimmt und das als Meta Description verwendet und das können wir in vielen Fällen natürlich auch schon so herausholen. Aber manchmal will man auch einfach ein Description selber angeben und das kann man mit Meta Description schon machen. Meta Description ist ja auch kein Ranking-Signal. Das heißt, es ist wirklich nur das einfach, wie das in den Suchergebnissen präsentiert wird. Manchmal möchte man mehr präsentieren, manchmal weniger, aber das verändert sich halt immer in den Suchergebnissen. Würdest du denn sagen, das bleibt jetzt so kurz oder wird das jetzt wieder länger? Ich würde mal behaupten, dass in den Suchergebnissen verändert sich alles ständig. Von dem her ich weiß jetzt nicht, was die Gründe sind, warum Sie jetzt so in diese Varianten getestet haben oder das ausprobiert haben, aber ich würde eigentlich davon ausgehen, dass es weiterhin unterschiedliche Tests und Versuche geben wird. Gerade bezüglich der Länge von dem Meta Description im Moment ist es ja so, zumindest als ich gestern da verschiedene Sachen mal ausprobiert habe, auf meinen Geräten gibt es manche Suchergebnissen, die haben relativ langen Snippet, manche haben relativ kurzen Snippet und da ist es ja dann auch nicht so, dass man einfach eine Länge auf die optimieren kann und sagen kann, das ist jetzt der Maß aller Dinger, alles muss jetzt auf, was da war, eine Frage. Ich habe 160 Buchstaben quasi optimiert sein oder auf 270 Buchstaben war in der Frage. Das kann sich eigentlich immer verändern. Ich würde einfach schauen, dass man im Description wirklich einfach eine Beschreibung der Seite hat und manchmal ist es kurz, manchmal ist es lang. Ich habe in Search Console öfter mal die Meldung des Ressourcen blockiert waren beim Aufruf der Seite aus Sicht des Googlebots. Wenn ich dann per Robots Text-Tester die Seite auf zeigte, dass mir das alles okay ist und nicht blockiert ist. Es sind dabei fast immer Bilderteien gewesen, die als blockiert gelistet sind. Ist das ein Fehler im Tool oder woher kann das kommen? Ich weiß jetzt nicht genau, wo du dann nachschaust in Search Console. Es gibt da verschiedene Sachen, die passieren könnten. Einerseits kann es sein, dass wir die Robots Text-Datei nicht sauber crawlen können. Wenn wir die nicht sauber crawlen können, dann wenn wir zum Beispiel ein Timeout kriegen statt der Robots Text-Datei, dann nehmen wir an, dass das alles erst mal blockiert ist, weil wir wollen auf der sicheren Seite bleiben und dann kann es sein, dass wir für diesen Tag erst mal sagen, gut, wir wollen auf der sicheren Seite crawlen können. Das heißt, alles, was wir versuchen zu crawlen, an diesem Tag wird, wie blockiert durch Robots Text entsprechend gemelft. Das ist eine Variante. Normalerweise sieht man das allerdings auch in Search Console, im Robots Text-Testing Tool, gibt hier oben die Möglichkeit, die älteren Versionen anzuschauen und oft wird dann aufgelistet, dass wir an diesem Tag sind und dann ist es ein bisschen klarer, was da passiert ist. Die andere Variante ist, wenn ihr im Testing Tool zum Beispiel im Mobile Friendly Test die Seite aufruft und dann sieht, dass einzelne Bilder blockiert sind, könnte es unter Umständen einfach sein, dass wir nicht so viel Seiten vom Server crawlen können, dass wir das quasi intern wie blockiert anschauen, um sicher zu stellen, dass wir euren Server nicht irgendwie überlassen. Und dann ist nicht so, dass diese Seiten per Robots Text blockiert sind, sondern sie sind einfach vom Crawling her blockiert und wir konnten sie nicht aufrufen. Wenn man diesen Test später nochmal macht, vielleicht am nächsten Tag, dann kann es sein, dass es einfach funktioniert. Für die Indexierung ist das in der Regel kein großes Problem, weil wir sind da geduldig, wir testen diese Seiten auch später und versuchen, die Bilder entsprechend später nochmal herauszuholen. Manchmal ist es aber ein Zeichen, dass das Server ein bisschen eher langsam ist oder Serverfehler ab und zu zurück gibt, so dass wir nicht sicher sind, ob wir wirklich so viel crawlen können, wie wir eigentlich crawlen möchten von diesem Server. Und dann, wenn man das Gefühl hat, dass das vielleicht zutreffen könnte, dann lohnt es sich zu überlegen, wie kann man das Crawling für Google ein bisschen vereinfachen. Entweder, dass man mit verschiedenen Einstellungen auf dem Server vielleicht optimiert, dass man die Geschwindigkeit so optimieren kann, dass es schneller funktioniert, dass es weniger Serverfehler gibt, oder dass man den Server entsprechend ein bisschen aufstockt, so dass einfach mehr Kapazität da ist für Benutzer allgemein. Das heißt, ob das Google-Bord ist oder ein normaler Benutzer, das einfach alles ein bisschen schneller und ein bisschen besser funktioniert. Das sind die zwei Varianten. Entweder, dass wir die Robots das Text-Datei einfach nicht crawlen könnten oder, dass wir vom Crawling her, vom Crawl-Budget wird oft davon gesprochen, dass wir da einfach nicht genug Kapazität haben um wirklich alles zu crawlen, was wir gerne crawlen würden, von diesem Server. Wir werden links, die beim direkten Aufrufen Inhalte in JSON-Format ausliefern, auch indexieren. Bei Unterumständen Das heißt, wenn wir URLs finden, die JSON-Inhalte zurückgeben, das ist ja dann quasi wie eine JavaScript-Datei, dann kann es sein, dass wir diese indexieren. In der Regel ist es aber so, dass wir die nicht für normale Suchergebnisse zurückgeben. Das heißt, wenn jemand nach irgendwelchen Stichwörtern sucht, dann haben wir eure normalen Inhalte auch auf der Seite. Und das sind dann die Seiten, die wir dann zurückgeben mit normalen Suchergebnissen. Entgegen, wenn jemand gezielt mit einer Side-Abfrage diese URLs aufrufen will, dann kann es sein, dass wir sagen, ja, wir haben sie indexiert, da sind sie. Und wenn man mit einem Snippet direkt nach diesen Seiten oder nach diesen JSON-Dateien sucht, dann können wir die Unterumständen auch entsprechend finden. Aber in den normalen Suchen, wie ein normaler Benutze eigentlich suchen würde, sollten sie eigentlich also auf diversen Seiten zum Thema JavaScript SEO für Single-Page Apps. Das geht ein bisschen Richtung Canonical Tags ein. Wie man das machen kann. Wie gesagt, wichtig ist einfach gerade bei solchen Tags, die kritisch sind für die Indexierung, also eben mit dem Rail Canonical, den Link Rail MHDML und ich denke auch mit den Meta-Robots ist es einfach wichtig für uns, dass wir möglichst den Endzustand direkt haben. Das heißt, wenn wir die Seite aufrufen, dass wir da wirklich diese Signale direkt kriegen und auch verarbeiten können. Und das kann man am besten machen mit der statischen HTML-Version, die ausgeliefert wird, wenn man das machen kann mit Dynamic Rendering oder Hybrid Rendering ist es weniger ein Problem, macht das Server eine Art Pre-Rendering selber und fügt eigentlich diese Meta Tags entsprechend schon in die statische Version ein, die direkt zu Googlebot geliefert wird. Was ist mit Eingrund, warum wir da diese Varianten entsprechend auch empfehlen? So, mal schauen, was sonst noch gekommen ist. Gibt es irgendeine Möglichkeit Googlebot Temporware eine Escape-Fragment-Version zuzuweisen? Weiß ich nicht, wie du das am besten machen würdest. Wie bist du gerade hier? Perfekt. Was war dein Hintergedanke dazu? Wir haben eigentlich ein Projekt, das seit drei Jahren entwickeln. Wir haben eigentlich vor sechs, sieben Monaten im Online gestellt und damals die Indexierung war perfekt. Wir hatten eigentlich ein Interesse über 10.000 im Google Index und plötzlich ist es irgendwie verschwunden und ich denke mal Google scrollt unserer Seite. Wir haben eigentlich den Server gewechselt und ich könnte die originale Version von unserem System direkt klausen können. Deswegen ist es eigentlich die Escape-Fragment-Version, ich denke mal zumindest. Das ist das Problem und es sind nicht genügend URLs indexiert. Ich weiß nicht, auswischen Kunden und wir haben eigentlich eine Escape-Fragment-Technologie zu wechseln und wir brauchen eigentlich ein paar Monate dafür, aber wir wollen eigentlich bis dahin die Inhalte im Google Index haben. Okay. Was unter Umständen sein könnte, ist, dass wir die Seiten einfach nicht sauber renderen kann und so entsprechend die Inhalte vielleicht nicht finden. Was ich da vielleicht machen würde, ist den Google IO-Session vielleicht mal anzuschauen, den wir letzte Woche gemacht haben, gerade für JavaScript sites and search. Das sind einige Tipps dabei, wie man testen kann ob Googlebot diese Seiten renderen kann und wo vielleicht die Probleme sind. Vielleicht gibt es da einfache Sachen, die man verändern kann, die das dann anfühlt sich dafür zu führen, dass wir die normalen Version sauber renderen können und so sauber indexieren können. Ich vermute, dass es ein bisschen in die Richtung geht, dass wir quasi diesen Hashbang-Version finden, dass wir die Seite suchen zu renderen und wir sehen dann immer die gleichen Inhalte und dann falten wir diese Inhalte zusammen und sagen gut, das ist mehrmals die gleiche Seite. Wir machen das einfacher für den Webmaster und falten die entsprechend zusammen. Wenn wir die Seiten sauber renderen könnten, dann sollten wir eigentlich sehen, dass das unterschiedliche Seiten sind und können die auch separat so indexieren. Das heißt, die Hashbang-Version geht auf jeden Fall nicht weg. Was einfach im Moment passiert ist, dass wir die Escape-Fragment-Version immer weniger crawlen. Ja, das habe ich immer schon bemerkt und die interessante Sache ist, wir haben mal endlich über 200 Seiten im Google-Index und das ist das überraschende, weil wir haben eigentlich über 10.000 genau dasselbe Strukturierte Seiten nur Inhalten sind anders und wieso sind die nicht indexiert? Das ist die Frage. Im Siegkonsole sehe ich mal gefunden, zurzeit nicht indexiert, über 10.000 Einträge hält. Okay, und das ist dann keine genaue Erklärung, warum nicht indexiert in dem Fall. Und Google crawt unser Seite eigentlich früher war das eigentlich über 10.000 Seite pro Tage, aber jetzt ist es zum Beispiel gestern nur 1.000 Seiten halt. Die ignorierte die wie war das, gefunden nicht zurzeit nicht indexiert, die werden noch mal indexiert oder gekrollt. Okay. Ich würde vielleicht bei den URL-Parameter-Einstellungen einfach mal kontrollieren in Search Console, dass da nicht irgendwie was eingestellt ist oder irgendwie vorhanden ist, dass unter unschen Probleme dafür verursachen. Ja, das habe ich mal eigentlich vor vier Monaten. Ich kämpfe mit diesen Problemen seit sechs Monaten ehrlich und wir haben über 15.000 Einträge in unserem System und nur 200 sind im Online und niemand findet unsere Systeme oder unsere Seite Inhalte und so weiter. Und ich habe es eigentlich schon mal im Google Forum gepostet und ich sehe eigentlich im URL-Parameter eine Eintrag, der halt es gibt Fragment. Es ist eigentlich über 9.000 Einträge für das Google-Bot der Zeit. Das klingt eigentlich so weit gut. Könntest du mir vielleicht einige URLs mal zuschicken? Dann kann ich das hier mal anschauen und sehen, ob da etwas auf unserer Seite klemmt oder ob es da vielleicht etwas gibt, was ihr machen könnt. Soll ich jetzt machen oder später? Kannst du? Wie du möchtest? Würde ich gerne jetzt machen. Okay, cool. Du kannst sie einfach in den Chat rein posten. Ich kopiere sie nachher dann raus oder einfach auch per Google Class zuschicken, dann kann ich das nachher entsprechend rausholen. Aber vielleicht, dass das Problem ist, unsere Seite ist eigentlich ziemlich speziell, weil ich wir sind aus der Mongolei und wir haben eigentlich quillische Buchstaben im URLs non ASCII-Zeichenhalt. Deswegen ist eigentlich vielleicht nicht ganz optimal für den... Ich hoffe immer, aber das klemmt irgendwie. Zum Beispiel diese Seite. Okay, cool. Ich kopiere mir das mal raus. Damit ich das nicht verliere. Das ist eigentlich eine Liste und zum Beispiel das ist ein einzelner Leintrag, den wir im Google Index haben möchten. Okay. Cool. Dann schaue ich mal, was ich da finden kann. In der Regel sollte das eigentlich, wie gesagt, sollte das eigentlich funktionieren. Und wenn das schon seit ein halben Jahr oder länger so ist, dann vermute ich, dass das wenig mit der Umstellung mit dem Hashtbang zu tun hat, sondern dass es irgendwie vielleicht irgendwas anderes ist, was da nicht ganz sauber funktioniert. Aber schaue ich mal nach. Okay. Okay. Gut. Zeitlich sind wir jetzt, glaube ich, ziemlich am Ende gekommen und soweit ich sehen kann, die Fragen haben wir auch alle durchgekriegt. Ich richte auf jeden Fall die nächsten Hangouts noch ein. Falls ihr weitere Fragen habt, könnt ihr das dann dort entsprechend auch rein posten. In der Zwischenzeit seid ihr natürlich auch gerne eingeladen, in den Hilferforum zu posten, entweder auf Deutsch oder auf Englisch. Geht natürlich beides. Ansonsten bedanke ich mich für die vielen Fragen und für die Teilnahme und sehen wir uns vielleicht