 Ok, herzlich willkommen beim heutigen Webmaster Essentials-Sprechstunden-Hangout. Ich bin Johannes Müller, bin Webmaster Trans Analyst hier bei Google in der Schweiz und Teil von dem, was wir machen, sind solche Hangouts, wie jetzt hier. Sind schon einige Fragen eingereicht worden, aber wenn eine von euch vielleicht gerade loslegen möchte mit irgendeiner speziellen Frage, nur zu. Niemand? Vielleicht nachher dann. Ok, ich gehe mal die Fragen soweit durch. Wenn ihr zwischendurch Kommentare oder weitere Fragen habt, einfach nur loslegen. Also, eine Frage zu Progressive Web Apps. Denkst du, dass Progressive Web Apps die Native Apps in Zukunft ersetzen werden? Tja, weiß ich nicht. Grundsätzlich sind Progressive Web Apps eine Art Website so zu machen, dass sie besonders gerade auf mobilen Geräten sehr gut funktionieren. Das heißt, man kann es einrichten, dass eine Art Offline Funktionalität vorhanden ist, dass sie sehr schnell laden, dass sie dann auch die Möglichkeit haben, wie quasi ein Link auf die Startseite vom Handy zu setzen, dass man da auch entsprechend, wie heißt es, die ganzen Activities auch zuordnen kann, dass man direkt auch Daten dort hinschicken kann an diese Apps. Und das sind dann trotzdem auch Websites, die normal indexiert werden können für die Suche. Ich denke, dass gibt viele Möglichkeiten, die man damit machen kann, ob das wirklich ganz normale Apps auf dem Handy ersetzt, denke ich eher nicht. Aber das macht es natürlich ein bisschen einfacher für euch, dass ihr nicht mehr so fest entscheiden müsst, möchte ich ein App machen oder möchte ich eine Website machen, sondern ihr könnt dann auch ein Website machen, das einigermaßen so wie ein App auch funktioniert. Und da gibt es, denke ich sicher, viele Möglichkeiten. Wichtig ist für mich natürlich auch, dass sie normal indexiert werden können für die Google Suche. Da gibt es einige Sachen, auf die man auch da achten muss, aber das sind eigentlich die gleichen Sachen wie bei normalen Websites. Zum Beispiel, dass man normaler URLs verwendet, dass man normaler Links zwischen diesen Seiten hat, damit wir die Seiten und die Inhalte auch einigermaßen crawlen können. Aber ich denke, es gibt sicher viel zu tun in die Richtung, viele Sachen auch vielleicht mal auszuprobieren. Und es gibt immer mehr Websites, die jetzt auch mit einem Progressive Web App quasi durchstarten und das mal ausprobieren. Wir haben zwei Nachrichtenseiten und Planinhalte von einer Seite auf die anderen als Empfehlungen anzutiesen, da hier durch ziemlich viele Links entstehen würden, sollten diese Links mit nofollow gekennzeichnet werden. Grundsätzlich, wenn das jetzt zwei Nachrichtenseiten sind, sehe ich da kein Problem, dass man die auch als normaler Links zwischen diesen Seiten hat. Gerade wenn das Nachrichtenseiten sind, die sich mal in unterschiedliche Bereiche abdecken, dann sollte das eigentlich kein Problem sein. Seit sechs Wochen haben wir massive Abstürze im Ranking und Traffic für unser News Portal. Wir haben etliche Werbung entfernt, damit die Ladezeiten verbessert. Auch waren Artikel Links mit Session IDs für Werbertrakern, die nicht in den Index sollten, nur durch die Robots Text gesperrt und nicht auf No Index, was eventuell massiv negativ gewertet werden könnte. Was könnte man da quasi machen? Ich habe die Website kurz mal angeschaut und aus persönlicher Sicht ist da trotzdem noch sehr, sehr viel Werbung davorhanden. Man kann kaum irgendwas machen auf dieser Website, ohne dass da ein Pop-Over oder ein Pop-Under noch erscheint dazu. Ich könnte mir vorstellen, dass das nicht gerade beliebt ist bei deinen Benutzungen, wenn man etwas aggressiv auf die Benutzer geht mit der Werbung, aber das ist eher, sag ich mal, eure Sache, ob ihr das machen möchtet oder nicht. Aus unserer Sicht bezüglich Suchveränderungen, Ranking in Suche, gibt es natürlich diverse Sachen, die wir versuchen, dazu erkennen, zum Beispiel, wie die Qualität der Website insgesamt ist und das versuchen wir dann auch ein bisschen zu widerspiegeln. Wichtig ist vielleicht auch noch anzumerken, dass gerade bei Newswebsites gibt es natürlich auch immer wieder schwankende Sichtbarkeit, weil je nachdem, was im Moment aktuell ist, was ihr beschrieben habt auf euren Seiten, ist das vielleicht sehr beliebt oder ist das nicht so gefragt und dann sind diese Sachen vielleicht einmal sehr sichtbar in der Suche und manchmal sind sie gar nicht so sichtbar in der Suche und das ist eigentlich normal, gerade bei Newswebsites, von dem her gewisse Schwankungen, damit muss man eigentlich immer rechnen, bezüglich Veränderungen wie die Artikel-Links mit Session-IDs, das sind Sachen, die brauchen einfach eine gewisse Zeit auch, bis sie verarbeitet werden können. Das heißt, wir crawlen die ganze Website nicht von Neu jeden Tag, sondern wir gehen da Schritt für Schritt durch und manche Seiten werden öfters gecrawled und manche Seiten halt nicht so oft und da kann es durchaus sein, dass wir einige Sachen sehr schnell erkennen, die verbessert werden in dieser Hinsicht und andere Sachen brauchen einfach ein bisschen länger. Was ich einfach machen würde, mit Artikel, die mit Session-IDs arbeiten, die nicht auf No-Index setzen, sondern mit dem Rail Canonical zu arbeiten und entsprechend auch nicht mit der Robots-Textartei blockieren, weil wenn die auf No-Index sind oder mit der Robots-Textartei blockiert werden, dann können wir nicht erkennen, dass die eigentlich zusammengeklappt werden können. Und mit dem Rail Canonical können wir dann sehr gut erkennen, ah, diese URLs gehören eigentlich zusammen. Wir konzentrieren alle Signale, die wir haben auf diese verschiedenen Varianten von URLs und nehmen die auf eine URL und können so die dann auch ein bisschen besser in den Suchergebnissen zeigen. Noch eine Frage zu Hidden Content. Es ist zurzeit die Rede davon, dass Hidden Content und der Mobile First keine Nachteile hinsichtlich Rankings haben sollte. Gilt dies nur für mobile Rankings oder auch für Desktop? Ja, das ist im Moment ein Thema, was noch bei uns ein bisschen besprochen wird. Wir haben da noch keine definitive Aussagen, aber grundsätzlich ist die Idee schon, dass gerade bei mobilen Websites ist es natürlich schwieriger, die gesamten Inhalte sichtbar zu machen. Und von dem her versuchen wir dann eher auch die Inhalte zu berücksichtigen, die vielleicht hinter einem Tab sind, die in anderen Bereichen von der Seite sind, die von Anfang an nicht sichtbar sind. Und beim Mobile First Index ist es ja so, dass wir die mobile Version als Grundlage nehmen für das Indexing und wir nehmen die als Grundlage für die mobile Version sowie auch die Desktop Version der Suchergebnissen. Das heißt, so wie die mobile Seite indexiert wird, gilt für beide Varianten, wenn wir dann zum Mobile First Index kommen. Wichtig gerade bei Hidden Content ist natürlich, dass diese Inhalte irgendwie geladen sind auf der Seite. Nicht, dass wir da mit der Maus irgendwo hinklicken müssen und dass sie dann erst geladen werden, sondern dass sie wirklich auch von Anfang an geladen sind auf der Seite selbst. Das ist einfach aus unserer Sicht so, Googlebot kann natürlich nicht auf jede Seite gehen und alle Elemente anklicken zum Schauen, was dann nachher passiert, sondern versucht die Seite möglichst einmal zu laden und die Inhalte dann so, wie sie kommen, dann auch zu indexieren. Ein internationaler Kunde redirected basierend auf der Brausersprache, auf die entsprechende Sprachversion, also strich D-E-E-N-E-S. Googlebot wird immer auf die englische Sprache weitergeleitet, per sauberer hreffling. Umsetzung funktioniert die Sprachzuordnung soweit korrekt. Die deutsche Sprache rankt auch in Deutschland. Was passiert mit den backlinks? Wird das irgendwie zusammengeklappt oder was kann man da machen? Grundsätzlich vielleicht am Anfang kurz zu erwähnen. Wichtig ist, dass die einzelnen Sprachversionen jeweils zugreifbar sind ohne redirect. Das heißt, die Homepage kann durchaus diesen redirect machen mit dieser Weiche, je nach Sprachversion im Browser oder vielleicht Standort vom Benutzer. Wichtig ist aber, dass die einzelnen Sprachversionen separat gecrawled und indexiert werden können, dass ein Benutzer direkt zum Beispiel auf die deutsche Version gehen kann, auch wenn der Benutzer einen englischen Browser verwendet. Wenn das soweit funktioniert, dann kann Googlebot auch die einzelnen Sprachversionen sauber indexieren. Ich denke, das wird hier korrekt gemacht, sonst könnten wir die deutsche Version wahrscheinlich gar nicht indexieren. Bezüglich backlinks ist es so, dass die Seiten müssen anfühle sich ihre Links selber irgendwie verdienen. Es ist nicht so, dass wir die backlinks zusammenklappen. Das heißt, mit dem hreflang, was da praktisch passiert, ist, wir machen das Ranking normal für die verschiedenen Seiten und wir schauen dann, welches dieser Seiten an oberster Stelle sind in den Suchergebnissen und schauen danach, ob es eine Version gibt in diesem hreflang Satz, die passender für den Benutzer ist. Das heißt, wenn die deutsche Version zum Beispiel für Benutzer in Amerika aus Versehen an erster Stelle ranken würde, dann würden wir per hreflang das austauschen. Es ist also nicht so, dass die Links quasi verteilt werden oder wie mit einem Royal Chronicle auf eine Version konzentriert werden, sondern wir ranken diese Seiten einzeln. Der hreflang hat keinen Einfluss auf das Ranking, sondern es wird dann einfach die entsprechend passender Version ausgetauscht in den Suchergebnissen. Bezüglich Links von deutschen Seiten oder auf die deutsche Seite würde ich mir da in der Regel keine großen Sorgen machen, weil meistens ist es ja auch so, dass diese verschiedenen Sprachversionen untereinander verlinkt sind. Das heißt, ein Link, der auf die deutsche Version geht, hat natürlich von der deutschen Version dann auch einen Link auf die englische Version oder auf die spanische Version und so wird das entsprechend innerhalb der Website dann auch ein bisschen weiter verteilt. Ist es möglich, dass während eines HTTPS-Umtugs manche Urals für eine Weile gar nicht indexiert sind, also dass das Ersetzen von Urals im Index mit etwas Zeitverzögerung stattfindet? Meistens sollte das eigentlich nicht passieren. Ich könnte mir vorstellen, dass es vielleicht so Ex-Situationen gibt, wo das passieren könnte, beziehungsweise, dass es so Situationen gibt, dass man vielleicht mit verschiedenen Datencenter auf die Suchegebnisse zugreift und bei einem Datencenter sind die HTTPS-Version schon weg und beim anderen Datencenter sind sie vielleicht noch nicht da. Und dann, je nachdem, wenn ich die Anfrage mache, dann gehe ich einmal hierhin, einmal hierhin und dann sieht das vielleicht so aus, also ob die Urals nicht indexiert sind. In der Regel funktioniert dieser Tausch von HTTPS auf HTTPS relativ schnell. Das heißt, vom technischen Her ist es so, dass wir beide Versionen wahrscheinlich kennen, schon von früher und dass wir mit diesem Redirect dann einfach auf die andere Version umwechseln. Das heißt, es ist nicht so, dass wir die Urals neu indexieren müssen, sondern dass wir die dann einfach wissen, ah, jetzt können wir eigentlich eher die andere zeigen, dann schalten wir einfach auf die andere Version um. Gerade bei größeren Websites gibt es aber immer Verzögerung vom Crawling und vom Indexing her, dass wir, wie gesagt, nicht alles von Anfang an jeden Tag neu crawlen können, sondern wir machen das dann Schritt für Schritt. Und da könnte ich mir schon vorstellen, dass man vielleicht in Situationen kommt, dass einige Urals so indexiert sind und dann vielleicht ein paar Tage brauchen, bis sie mit der anderen Version auch erkannt sind und so sauber erfasst werden. Sollt aber eher selten sein beziehungsweise dann eigentlich nicht so sichtbar für den Benutzer sein. Wenn man in Deutschland mit englischer Spracheinstellung im Browser unsere Brand sucht, dann bekommt man immer die österreichische AT Domain ausgespielt und nicht die deutsche. Woran könnte das liegen? Wie kann man das Problem beheben? Wäre mal interessant zu sehen, welche Website das ist beziehungsweise, welche Suchanfragen ihr da sieht, dann könnte ich das mal hier ein bisschen genauer anschauen. Ist mir bisschen schwierig zu sagen, einfach so ohne weiteren Angaben jetzt da. Was vielleicht sein könnte, ist, dass mit dem HPF-Lang irgendetwas nicht ganz sauber funktioniert, dass da vielleicht die englische Version angegeben ist oder ein X-Default-Version angegeben ist und dass wir dann so auf eine alternative Version zugreifen. Was auch manchmal passiert, ist, dass die einzelnen Länder-Version soweit so identisch sind, dass wir die einfach als eine Version indexieren und dann kann es natürlich sein, dass wir diese eine Version mal als DE oder mal als AT Domain ausspielen. Aber wenn du mir die Angaben mal schicken könntest, dann kann ich das auch mal ein bisschen genauer anschauen. Was passiert, wenn ich eine Website bei zwei verschiedenen Google Search Console Accounts validiert habe und zum Beispiel die Website dort unterschiedlich konfiguriere. Grundsätzlich sollte das so sein, dass die Einstellungen einmal vorhanden sind. Das heißt, wenn ich sie an einem Ort ändere, dass sie dann am anderen Ort auch angepasst werden. Das heißt, dass man gar nicht unterschiedliche Konfigurationen haben kann. Manchmal, es gibt vielleicht mal einige Einstellungen, sind ein bisschen persönlicher. Zum Beispiel Property Sets, wenn ich die erstelle, die sind dann bezogen auf das Konto selbst. Ich glaube, die Sidemap Dateien, wenn ich die einreiche, die sind bezogen auf das Konto selbst. Man kann natürlich auch sehen, welche Sidemap Dateien sonst eingereicht worden sind. Also man sieht das schon. Aber standardmäßig ist es, glaube ich, bezogen auf das Konto. Ansonsten sollte es eigentlich nicht so sein, was Einstellungen hat, die irgendwie im Konflikt sein könnten. Ich habe meinen Shop Anfang Februar auf HTTPS umgestellt. Seitdem verliere ich immer mehr an Sichtbarkeit bei Google. Was könnte daran schuld sein? Ich habe das mal kurz angeschaut vor dem Hangout. An für sich ist dieser Veränderung in den Suchergebnissen unabhängig von der HTTPS-Umstellung, sondern einfach allgemein eine neue Beurteilung der Website, die einfach von unseren Algorithmen immer wieder mal stattfindet. Und das hängt nicht mit der Umstellung auf HTTPS zusammen. Was passiert, wenn ich die Ownership einer Website zu einem neuen Konto transferiere und den bisherigen Konto quasi lösche? Ich denke, das bezieht sich auf Search Console. Aus unserer Sicht ist das total unproblematisch. Die Einstellungen werden weitergegeben. Alle Informationen sind eigentlich soweit noch vorhanden, weil die sind ja pro Website abgespeichert, eben außer vielleicht, dass die Seitenverteilen nicht standardmäßig gelistet werden oder das Property Sets nicht standardmäßig übernommen werden. Aber ansonsten kann man das beliebig machen. Es ist auch zum Beispiel kein Problem, wenn man vergisst, welches Konto verwendet worden ist für Search Console oder das Passwort für das Konto nicht mehr hat. Wenn man das neu verifiziert mit einem neuen Konto, hat man all diese Einstellungen wieder zurück. Es ist also nicht wie zum Beispiel bei Google Analytics, dass diese Daten dann wieder neu aufgebaut werden müssen, sondern man hat wirklich die alten Daten dann auch wieder. Perfekt, danke. Die Domain für das Problem der englischen Browsereinstellung. Okay, das kopiere ich mir auf die Seite. Muss ich vielleicht nachher mal anschauen. Du, du, du, in einem Moment. So, mich, dass das verloren geht. Hast du eine Erklärung für mich, warum in Google Maps im Screenshot zu sehende Ranking zustande kommt? Da habe ich leider keine Information, weil Google Maps macht das Ranking an und für sich separat. Das ist nicht etwas, was wir mit der Google Suche groß machen. Da weiß ich eigentlich nicht, wie das gehandhabt wird. Was ich vielleicht machen würde an so einer Situation, ist entweder im deutschen Google Maps Forum nachzufragen oder es gibt für Google My Business einen englischen Forum. Da kann man vielleicht auch mal nachfragen und schauen, ob da jemand Tipps hat oder Ideen hat, was man da machen könnte. Noch eine Frage zu den Backlink-Daten in Search Console. Da müsste ich wahrscheinlich noch mal nachschauen. Eine Frage zur Transliteration von Sonderzeichen, um URL-Encodings zu vermeiden, zum Beispiel Flügelmutter mit UE. Im Ungarischen wäre sprachlich korrekt, ein Ö durch ein anderes O mit so einen schrägen Umlaut zu ersetzen oder durch UE zu ersetzen. Allerdings findet das im Ungarischen praktisch keine Anwendung. Was ist aus Google Sicht sinnvoller? Beugen wir uns den Linguisten oder passen wir uns den Usus an? Das ist eine Sache, die manchmal ein bisschen triggreich, weil aus unserer Sicht ist es nicht so, dass unsere Algorithmen mit Linguisten zusammenarbeiten und versuchen festzustellen, welche Buchstaben da ausgetauscht werden können, sondern wir versuchen aufgrund vom Benutzerverhalten das Eigenanwend für sich festzustellen. Wir versuchen zu erkennen, wenn Benutzer nach dieser Variante suchen und dann nachher auch nach der anderen Variante suchen oder wenn wir sonst kennen können, dass eigentlich zum Beispiel ein U mit einem Umlaut, das gleich irgendwie U mit UE oder nur ein U allein ist, dann versuchen wir diese Wörter dann entsprechend auch als Synonyme zu verwenden und nehmen das dann auch für die Suche so entsprechend auf. Das heißt, es ist nicht so, dass wir versuchen, das linguistische Korrekte zu machen, sondern wir versuchen das zu geben, was Benutzer effektiv suchen. Und da, gerade wenn man jetzt verschiedene Varianten hat, ist es manchmal nicht so einfach. Wichtig ist einfach, dass in vielen Fällen Benutzer das eigentlich intuitiv schon, so dass sie diese Sachen dann auch entsprechend finden. Ihr könnt das auch relativ schnell ausprobieren, indem ihr einfach die verschiedenen Wörtervarianten mal sucht und dann schaut ihr mal welche Varianten gefunden werden und so sieht man dann relativ schnell, wie das bei Google auch gehandhabt wird. Wichtig bezüglich der URL selbst ist es so, dass wir an und für sich die Wörter in der URL nicht so stark bewerten. Das heißt, aus meiner Sicht ist das weniger kritisch, ob man jetzt in der URL selbst, sag ich mal, die ASCII-Version quasi verwendet oder ob ihr damit ein Umlaut arbeitet mit quasi internationalen Domainname oder irgendwas, sondern das ist eher etwas, was sag ich mal euch überlassen wird. Aus unserer Sicht ist das weniger ein starker Rankingfaktor, sondern wir versuchen dann eher die Inhalte anzuschauen auf diesen Seiten. Und in vielen Fällen gleicht sich das dann relativ schnell auch aus. Ich denke, gerade beim Domainnamen würde ich vielleicht irgendetwas nehmen, was wirklich gut für die Benutzer auch erkennbar ist, was die Benutzer auch gut weiter verwenden können. Das heißt, wenn Sie jetzt ein E-Mail schicken an euch, dass Sie dann nicht überlegen müssen, welche Variante von Buchstaben muss ich hier verwenden, damit das E-Mail ankommt. Entsprechend auch, wenn man jetzt auf eine Website verlinkt, dass man da nicht groß überlegen muss, sondern das ist eigentlich ganz einfach funktioniert. Und wenn ihr da wirklich nicht sicher seid, welche Variante am besten funktioniert, dann würde ich vielleicht die Benutzer direkt mal fragen. Vielleicht eine kurze Umfrage machen auf der Website oder sonst irgendwie offline eine Umfrage auch machen. Zum Schauen, welche Variante wird da verwendet, um nach euren Feriennamen zum Beispiel zu suchen. In der Regel ist es sowieso auch, dass gerade bei Feriennamen ist das weniger ein Problem, weil da gibt es ja fast nur eine Version, die wir zeigen können. Bei einzelnen Produkten, Produktbeschreibungen, ist das vielleicht eher dann auch ein Thema. Bei uns ist eine Frage aufgetaucht zu Isomorphic JavaScript im Zusammenhang mit React. Dabei lädt ja nicht immer die ganze Seite neu, wenn man innerhalb der Website navigiert. Dadurch wird ein sehr guter PageSpeed erzielt. Ist das okay? Ist das nicht okay? Aus unserer Sicht ist Isomorphic JavaScript eine sehr gute Variante. Das heißt, mit Isomorphic JavaScript wird das an und für sich so gemacht, dass man eine JavaScript-Website verwendet als Grundlage und dann jeweils die erste Sicht an und für sich auf dem Server rendered und die gerenderte Version an Benutzer dann an erster Stelle ausliefert. Dadurch ist es so, dass Benutzer JavaScript nicht ausführen müssen an erster Stelle, sondern dass die Seite eigentlich sehr schnell lädt. Zusätzlich hat man natürlich den Vorteil, dass gerade die ganzen Suchmaschinen, Crawler, Social Media Sites können direkt auf diese Seite zugreifen und die so verwenden wie eine normale statische HTML-Seite. Und wenn man dann innerhalb der Website navigiert, hat man dann trotzdem noch die Vorteile von der JavaScript-Website. Aus unserer Sicht ist es eine ganz tolle Variante, eine Website zu machen, weil dann hat man wirklich beide Vorteile. Einerseits hat man die ganze JavaScript-Infrastruktur, die man verwenden kann, innerhalb der Website. Die Entwicklung ist entsprechend vielleicht auch ein bisschen einfacher für die Timeworks. Und andererseits hat man dann trotzdem noch eine sehr schnell ladende statische Website, die trotzdem auch sehr gut in Suchmaschinen funktioniert. Wichtig ist vielleicht, dass gerade innerhalb der Website, dass man normale A-Elemente im HTML für die Links zwischen einzelnen Seiten und dass man einfach sauber URLs verwendet für die einzelnen Seiten. Und wenn man normale URLs verwendet, und diese sauber auch verlinkt sind, dann sollte das überhaupt kein Problem sein für uns. Eine Frage zu Return to Serb Rate, die wir ja nicht wirklich nachmessen können. Wenn ich googlen nach beispielsweise Zalando, Nike, Schuhen, Herren und klicke dann quasi hin und zurück, ist das schädlich für unser Ranking oder nicht? Nein. Das sind an und für sich Sachen, die verwenden in erster Linie nicht so viel, das Ranking. Und von dem her, müsst ihr euch wegen dem eigentlich keine großen Sorgen machen, ist ja an und für sich ein gutes Zeichen, wenn jemand schon gezielt nach der Website-Namen, nach dem Website-Namen sucht, weil dann kommen ja automatisch eure Inhalte sowieso schon. Aber aus unserer Sicht ist das überhaupt kein Problem, das ist eigentlich auch ganz normal, dass jemand dann vielleicht ein bisschen hin und her klickt welche Seite passt jetzt am besten zu mir. Eine Frage zur Rich Snippet Auszeichnung, Aggregate Rating, sind hier nur aggregierte Bewertungen von mehreren unterschiedlichen Nutzern zulässig oder kann man als Website-Betreiber auch Produkt-Service unter verschiedenen Gesichtspunkten testen? Ja, das ist wirklich nur für die Bewertung von verschiedenen Benutzern, das Aggregate Rating. Was man vielleicht machen kann, ich glaube es gibt auch eine andere Bewertung, die man angeben kann, wenn man zum Beispiel ein Produkt selber testet und das könnte man dann in solchen Fällen vielleicht verwenden. Wichtig ist gerade bei den Rich Snippets, dass die Bewertung sich auf das bezieht, was das Hauptthema ist von dieser einzelnen Seite. Das heißt nicht die Website selbst, nicht die Firma selbst, sondern wirklich zu dieser einzelnen Website, was wird da jetzt besprochen. Das kann zum Beispiel ein Produkt sein und dann bezieht sich das Ranking auf das Produkt. Wenn das jetzt ein Blogpost ist oder eine Firma allgemein, die Firma-Firmen-Bewertung hat für alles, was auf dieser Website ist, dann sind diese Ratings nicht dafür geeignet. Eine Frage zum Thema Re-Launch, wir entwickeln gerade unser neues Shop-System und werden damit auch unsere URLs optimieren. Können wir sicherstellen, dass unsere Sicherheit nicht zu stark eindricht, beziehungsweise, dass Google unsere Seiten danach wieder schnell crawlen und indexieren kann? Ja, sicherstellen ist wahrscheinlich schwierig. Grundsätzlich ist es so, dass wenn man jetzt innerhalb einer Website eine größere Umstellung macht mit der URL-Struktur, dann gibt es auf jeden Fall Schwankungen. Dann müssen wir anfühlen, die Website erst mal neu crawlen, neu indexieren und all diese Signale, die wir pro URL haben, wieder neu aufbauen. Selbst wenn der Redirect von den alten URLs zu den neuen sind, müssen wir das Ganze erst mal neu verarbeiten und das kann eine gewisse Zeit dauern. Das heißt, wenn man zum Beispiel ein Re-Launch macht, irgendwie die alten URLs beibehalten kann, dann ist das sicher ein bisschen weniger problematisch als wenn man alles neu umstellen muss. Manchmal lässt sich das nicht vermeiden beziehungsweise manchmal ist es auch so, dass man durch eine solche Umstellung einen viel besseren Zustand erreichen kann letztendlich und dann macht es ja trotzdem Sinn, dass man sagt, gut, ich nehme jetzt kurzfristige Schwankungen in Kauf und denke, dass mein Endzustand danach sowieso besser sein wird, weil ich alles viel besser gestaltet habe, weil ich die ganzen, z.B. session IDs weggenommen habe, weil ich eine saubere Struktur habe, all solche Sachen. Aber grundsätzlich lässt sich das nicht garantieren, dass man sagt, ich möchte jetzt diese Schwankungen minimieren und trotzdem all diese Umstellungen machen, weil man macht ja auch die Umstellungen in Hinblick darauf, dass sich irgendetwas verbessert. Das heißt, dass es irgendwelche Veränderungen gibt. Und da, ja, ich denke, aus praktischer Sicht ist es manchmal am besten, wenn man sich einfach eine Zeit aussucht, wo man nicht zu sehr auf Traffic aus der Suche, wo man davon abhängig ist. Das heißt, wenn man sich überlegt, vielleicht irgendwie im Sommer, wenn man sowieso Airflouter hat oder wenn man sowieso vorhat, eine größere Werbekampagne zu machen, dass man das in diesem Rahmen zusammenmacht, sodass benutzt er trotzdem auf die Website direkt kommen, vielleicht über diese Werbung halt und dass man da einfach von der Suche nicht so abhängig ist während dieser Zeit. Manchmal lässt sich das alles halt nicht vermeiden und da muss man das halt im Kauf nehmen. Aktuell bekommen sehr viele deutschen Seiten Spammy-Links von indischen Domains, welche einfach die Alexa-Ranking-Seiten von Creepen und Abbilden. Bei uns hat das quasi einen starken Trafficverlust gegeben, haben ein Disavow-Datei erstellt und das sind noch ein paar Beispiellinks angegeben. Ich habe das ganz kurz mit eurer Website angeschaut und da sind eigentlich die Veränderungen der Suche nicht von diesen Links abhängig. Ich habe auch gesehen, dass die Links, die da angegeben worden sind und vom Webspam-Team schon an und für sich bearbeitet worden sind, dass sie ganz entfernt sind und auch dass selbst vorher, dass die eigentlich nicht verwendet worden sind. Das heißt, die Spammy-Links, gerade von solchen Spammy-Websites, die von Scraper oder sonst wie erstellt werden, werden in der Regel von unseren Algorithmen sowieso ignoriert. Das heißt, da muss man sich nicht allzu viel Sorgen machen. Wenn man unsicher ist, kann man auf jeden Fall trotzdem meine Disavow-Datei einreichen. Mit der Disavow-Datei hat man einfach die Gewissheit, dass diese Links wirklich nicht verwendet werden. Es ist auch nicht so, dass wir die Disavow-Dateien durchgehen und uns überlegen, diese Website hat diese Disavow-Datei eingereicht, also hat sie sicher irgendwas, was sie verbergen will und dann gehen wir mal nachschauen. Sondern aus unserer Sicht sind die Disavow-Dateien wirklich einfach technische Hilfsmittel, die die Websites verwenden können. Und manchmal werden die verwendet, um alte Sachen quasi aufzuräumen, die man vielleicht früher gemacht hat, die man jetzt nicht mehr weiter machen möchte. Manchmal werden die verwendet, um solche Situationen wie hier, dass man denkt, ja, das sind irgendwie Spammy-Websites, die zu meiner Website verlinken. Ich möchte einfach nicht mit denen in Zusammenhang gebracht werden. Und von dem her ist es sicher nicht so, dass wenn man eine Disavow-Datei einreicht, dass man dadurch irgendwie Nachteile hat, außer dass halt diese Links dann nicht mehr gezählt werden. Wir haben kürzlich etwas beobachtet, was uns neu erscheint und Nachfragen wollten. Wir sahen einen unterschiedlichen Rank für den selben Suchbegriff auf Google.de, obwohl vom gleichen IP-Adress aus und gleichen Spracheinstellungen gibt es hier da ein Update. Ich denke, das kann immer wieder passieren. Wir machen, einerseits haben wir natürlich verschiedene Data Center, auf die ihr zugreifen könntet, je nachdem, das sieht man an und für sich nicht in den Suchergebnissen, zu welchem Data Center man weitergeleitet worden ist. Andererseits machen wir immer wieder Experimente intern. Und an und für sich in jeder Suche, die man normal macht, sind dann gewisse Anzahl Experimente immer aktiv. Und das können Experimente sein, die quasi das Aussehen der Suchergebnisse leicht verändern. Es können aber auch Experimente sein, die die Reihenfolge der Suchergebnisse verändern. Und so kann es durchaus sein, dass wenn man eine Suche einmal macht und dann vielleicht ein Tag später nochmal macht, dass da die Reihenfolge der Suchergebnisse ein bisschen anders ist. Und das ist an und für sich nichts Neues, sollte eigentlich normal sein. Eine Frage zu dynamischen Content, wie man am besten indexieren kann. Wir haben drei verschiedene Content-Varianten, die wir abhängig vom Standort unseren User auf einen einzigen statischen URL zeigen wollen. Leider weiß ich nicht, ob Google alle drei Varianten mit der gleichen URL indexieren kann. Wenn das nicht geht, kriegen wir Ärger von Google wegen Cloaking. Was ist die Best Practice? Grundsätzlich ist es so, dass wir in erster Linie von Amerika aus crawlen und wir sehen dann die Inhalte, wie sie wahrscheinlich amerikanischen Benutzern gezeigt werden. Und wenn ihr da einzelne Inhaltsblöcke austauscht, je nachdem aus welcher Region von Deutschland oder aus welcher Region aus Europa ein Benutzer kommt, dann sehen wir das wahrscheinlich gar nicht für das Indexieren. Man kann das sehr gut nachkontrollieren, indem man einfach da die Textstücke vielleicht in Anführungsstrichen nimmt und danach sucht. Wahrscheinlich sieht man die einzelnen Varianten dann gar nicht. Das heißt, mit dynamischen Content, was ich da machen würde, ist einfach schauen, dass man einen gewissen Teil der Seite hat, der eigentlich immer wieder verwendet wird, egal was man sonst noch dynamisches auf diesen Seiten macht. Damit man sicher ist, dass dieser vielleicht mal statische Teil der Seite auf jeden Fall indexiert wird. Und aufgrund von diesem statischen Teil können wir dann auch das Ranking machen, können wir die Seite auch in Suchergebnissen zeigen. Und wenn ihr dann weitere Sachen macht, die je nachdem vom Benutzer Standort oder von Einstellungen aus abhängig sind, dann ist das quasi einfach noch zusätzlich dazu. Dann ist das aus unserer Sicht unproblematisch. Es ist auch kein Problem bezüglich Cloaking in einem solchen Fall. Cloaking wäre für uns problematisch, wenn der Benutzer in, vielleicht mal Amerika, anderer Inhalte sehen würde als Googlebot, wenn Googlebot von Amerika aus crawled, weil das sind ja dann Benutzer im gleichen Standort und es gehen unterschiedliche Sachen. Das wäre aus unserer Sicht ein eher problematisch. Wenn andere Standorte leicht anderer Inhalte sehen, ist das überhaupt kein Problem. Bei einem Webshop werden Produktbilder in jeweils verschiedenen Größen und Ansichten von einem Content Delivery Network geladen. Dabei landen sehr viele de facto gleiche Bilder in verschiedenen Größen, auch in der Bilderindex. Das ist quasi ein Problem oder nicht. Aus unserer Sicht ist das kein Problem. Bezüglich Crawl Budget ist das auch unproblematisch. Wir machen diesen sogenannten Crawl Budget pro Server. Das heißt, wenn man ein Content Delivery Network verwendet, ist das ja meistens auch ein separater Server mit einem separaten Subdomain zum Beispiel oder separaten Domain sogar. Da sehen wir das dann auch separat. Das heißt, wir sehen dann einerseits die HTML-Seiten vom Shop kommen von diesem Server, die können wir mit dieser Geschwindigkeit crawlen, die Bilder kommen von einem anderen Server, die können wir mit einer anderen Geschwindigkeit crawlen und das können wir unabhängig voneinander dann auch so weiter verwenden. Bezüglich Disallow in Robots Text, ich denke, dass es euch überlassen, welche Version von diesen Bildern ihr indexiert haben möchtet, und welche nicht. Das spielt eigentlich keine große Rolle aus unserer Sicht. Das könnt ihr wirklich selber entscheiden. Wichtig ist vielleicht bei Bildern, dass man da keinen Relcanonical verwenden kann. Die können wir da nicht weiterverarbeiten bei der Bildersuche. Und so kann man da nicht zum Beispiel sagen, mein Thumbnail ist ein Relcanonical von diesem größeren Bild, sondern wir indexieren einfach all diese Varianten. In den meisten Fällen können wir erkennen, dass die kleineren Bildern zu den größeren Bilder zusammenpassen und wir dann auch nur ein Bild aus diesem Satz quasi in der Bildersuche zeigen. Es sei denn der Benutzersuch gezielt nach diesem einen Bild und dann will die verschiedenen Größen haben. In Webmaster Tools Crawling Failure kriegen wir immer bei Smartphone lockierte URLs aufgeführt, die Query String beinhalten. Das Smartphones mit Query String nicht umgehen können, ist mir bewusst. Ich habe auch die Robots Text, die URLs aufgenommen, aber ohne Erfolg. Die Crawling Failure tauchen immer wieder neu auf. Ist das ein Problem? Grundsätzlich können Smartphones normal mit Query String-Parameter umgehen. Das sollte eigentlich überhaupt kein Problem sein. Die meisten Smartphones haben einen recht modernen Browser und können eigentlich ziemlich auf alles zugreifen, was man auf dem Desktop auch machen kann, außer vielleicht Java oder Flash. Solche dynamischen Elemente, die dann auch noch zusätzliche Komponenten brauchen, die installiert werden müssten. Von dem her sollte das eigentlich unproblematisch sein. Bei Search Console in den Crawling Failern haben wir für Smartphones eingelogiert, gerade für URLs, die in der Robots Text blockiert sind. Wahrscheinlich ist das, was wir da finden. Es ist nicht so, dass wir da ein Crawling Fehler haben, dass wir einen Fehlercode zurückkriegen, sondern wir würden gerne einfach diese Smartphone-Version dieser Seite sehen und können die nicht auf die zugreifen, weil die per Robots Text blockiert ist. Das heißt, was praktischerweise dann passiert ist, wir wissen nicht, ob diese Seite wirklich Smartphone tauglich ist. Da kann es dann sein, dass wir in den Suchergebnissen, gerade für mobile, benutzen, die Seite nicht so hoch in den Suchergebnissen zeigen. Deswegen bringen wir das auch entsprechend in Search Console dort hinein. Bei einer Umstellung auf Mobile First Indexing wäre das noch problematischer, weil dann hätten wir effektiv gar keine mobile Version, die wir indexieren könnten. Und da könnte ich mir vorstellen, dass es dann wieder ein bisschen kritischer wäre. Beziehungsweise, was wahrscheinlich passieren würde, ist, wir würden einfach die Desktop-Version in einem solchen Fall für die Indexierung nehmen. Aber was ich empfehlen würde, ist da die normalen Zusammenhang zwischen der mobile Version und der Desktop-Version einzurichten. Das heißt, mit dem REL-Alternat von der Desktop-Version und mit dem REL-Canonical von der mobile Version auf die Desktop-Version verzeigen und das Ganze dann nicht per Robots Text zu blockieren, sodass wir wirklich sauber die Desktop-Version, sauber die mobile Version crawlen können, dass wir erkennen können, dass sie miteinander verbunden sind und dass wir dann uns eher auf eine Version von diesen beiden konzentrieren für das Indexing. In Gutschein-Markt betreiben die meisten Anbieter viele White Labels, wo die gleichen Deals angeboten werden, wie hoch ist die Gefahr von Duplicate Content. Reicht es, wenn alle Titel und Beschreibungen von den Gutscheinen unig geschrieben werden? Ja, ich vermute, das ist wahrscheinlich ein bisschen schwieriger da, weil das sind wahrscheinlich auch viele Sachen, die sich sehr schnell verändern und dann lässt sich schlechter kennen, welche Sachen anfühlt sich zusammengeklappt werden. Grunde genommen, wenn ihr das so ausbreitet, wenn ihr die Inhalte von einer Website auf einer anderen Website noch darstellt und die zum Beispiel mit Titels und Beschreibungen so weit auseinandersetzt, dann verdünnt hier an und für sich den Wert von diesen Inhalten. Das heißt, statt eine Seite zu haben, die relativ stark ist, habt ihr dann verschiedene Seiten mit den gleichen Inhalten, die alle unterschiedlich gerankt werden wollen in den Suchergebnissen und das kann natürlich dazu führen, dass man jetzt statt einer Seite, die sehr stark und gut sichtbar ist in den Suchergebnissen, dann vielleicht 4 oder 5 Seiten hat, die einigermaßen sichtbar sind in den Suchergebnissen und das ist wahrscheinlich nicht so optimal. Von dem her, wenn man das irgendwie machen kann, dass man sich auf eine Version konzentriert, hat man wahrscheinlich da ein Vorteil, wenn man zum Beispiel mit dem RelCanonical arbeitet und wirklich sicherstellt, dass all diese verschiedenen Varianten auf ein Canonical verweisen, dann können wir eher diese Canonical URL vielleicht ein bisschen besser in den Suchergebnissen darstellen. Wir haben bisher für unsere Preisvergleichseite zu den Städten zusätzlich Seiten mit Postlite-Zahlen erstellt. Diese haben aber kaum mehr Wert für unsere User erfüllen, deswegen nur unnötig unsere Crawling-Budget. Wir würden nun gerne den Prozess für Google und Nutzer vereinfachen, hätte es eine Idee, wie die Umsetzung gelingen kann. Es sollte in Zukunft immer nur eine Seite pro Stadt geben und ohne diese Postlite-Zahl unterseiten. Ja, ich denke, das ist auf jeden Fall eine gute Idee, weil das sieht natürlich sehr schnell auch nach Doorway-Seiten aus, wenn man jetzt die einzelnen Postlite-Zahlen separat hat, nicht nur vom Crawling-Budget her. Es geht auch ähnlich in die gleiche Richtung wie vorher, indem man die Inhalte, die man vielleicht pro Stadt hat, dann eher auch verdünnt hätte auf die einzelnen Postlite-Zahl-Version, sodass man da vom Ranking her wahrscheinlich gar keinen großen Vorteil hatte von den einzelnen Postlite-Zahl-Versionen. Das heißt, was ich da machen würde in einem solchen Fall, ist das einfach mal ausprobieren und einfach mal testen. Vielleicht für einzelne Städte, wo ihr genügend Sichtbarkeit in den Suchergebnissen habt, wo ihr genügend Daten auch habt über die Suchergebnissen, über wie diese Seiten dargestellt werden in Suchergebnissen, über die Clicks and Impressions und mal überlegen, wie man das am besten zusammenklappen könnte. Und vielleicht reicht das, wenn man einfach die Seite pro Stadt hat, wenn man gar nicht die Postlite-Zahl erwähnt. Vielleicht muss man sich da etwas anderes überlegen. Vielleicht sind auch einzelne Bereiche von größeren Städten soweit so unterschiedlich, dass es sich lohnt, das noch aufzuteilen. Vielleicht kann man auch andere Städte zusammenklappen zu machen, sondern wir machen für die ganze Region eine Seite. Aber das sind Sachen, die würde ich einfach mal austesten und schauen, wie das am besten bei euch ankommt. Einerseits bei Benutzern, andererseits natürlich auch in der Suche. Zu den Rich Snippets, ich denke du meinst Review Rating Ja, ich vermute. Ich weiß jetzt nicht genau, wie was alles auf diesen Dokumenten steht, aber das ist wahrscheinlich das, was ich da gemeint habe. Okay, wow. Ich glaube, da haben wir soweit alle Fragen durchgekriegt. Was gibt es von euch noch? Womit könnte ich noch helfen? Nichts mehr? Okay. Das ist auch okay. Ich richte auf jeden Fall den nächsten Hängerz noch ein, dass wenn weitere Fragen kommen, könnt ihr die gerne da einstellen. Ihr könnt natürlich im Hilfeforum gehen. Das sind jeweils auch sehr viele, die gut weiterhelfen können. Ansonsten wenn nichts weiter ansteht, dann wünsche ich euch noch einen schönen Nachmittag. Danke dir auch. Tschüss allerseits. Tschüss.