 Okay, willkommen beim heutigen Webmaster Essentials-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 ist mit Webmastern und Publishern sprechen, wie jetzt hier im Hangout und wie jetzt einige recht viele Fragen schon eingereicht worden sind. Wie immer, wenn einer von euch hier im Hangout loslegen möchte mit den ersten Fragen, seid ihr gerne dazu eingeladen, ansonsten gehe ich dann einfach mal die eingereichten Fragen durch. Also von unserer Seite nicht. Okay. Von uns auch noch nicht, also ich habe meine erste Frage schon gestellt, also geschrieben, und ich bin gespannt auf die Antwort. Okay, super. Vielleicht kommen ja noch andere noch dazu, ansonsten geht das auch so. Also die erste Frage, die ich hier habe, ist ein bisschen schwierig zu beantworten. Wir bemerken gerade viele Veränderungen in den Suchergebnissen für unsere Hauptkeywords. Im Vergleich zu anderen Anbietern ist unser Backlink-Profil bei weitem stärker und auch im Hinblick auf Keyword-Verteilen, interne Links und Geschwindigkeit sind wir vorne. Was wir jedoch sehen, ist, dass alle Anbieter das Keyword in deren Domain haben. Und dann einige Beispiel suchen, die eigentlich nach Domains aussehen. Laut Google ist das Keyword in der Top-Level-Domain ja kein Ranking-Faktor mehr, was hier jedoch nach meinem ersten Anschein nicht so aussieht. Ich weiß jetzt nicht genau, welche Suchanfragen ihr da angeschaut habt, aber grundsätzlich gibt es eigentlich immer Veränderungen bei uns in den Suchergebnissen. Es ist also nicht so, dass nur weil eine Website jetzt lange Zeit gut sichtbar war in den Suchergebnissen, dass die immer gut sichtbar sein wird, sondern das kann sich eigentlich immer verändern. Und wir verwenden da zahlreiche Faktoren, um das Ranking festzustellen, wie wir das am besten machen können. Viel ist natürlich auch mit Personalisierung dabei oder mit Erkennen von der Qualität von der Website oder von den einzelnen Seiten, die da sind. Und das ist manchmal schwierig, auf ein Faktor zurückzuziehen. Und gerade bezüglich Keyword in der URL ist es schon so, wir nehmen die Keywords, die wir finden in der URL, nehmen wir schon auf und verwenden die auch für das Ranking als ganz kleinen Faktor, aber es ist nicht so, dass das jetzt ein kritischer Faktor wäre. Was wir jetzt neuerdings festgestellt haben bei Gesprächen mit diversen Quality-Mitarbeitern, ist, dass es zum Beispiel bei uns besser funktioniert, wenn die Keywords mit einem Minuszeichen verbunden sind, als wenn sie mit einem Unterstrichenzeichen verbunden sind. Das wäre vielleicht eine Variante, die man machen könnte, wenn man jetzt neu eine Website aufsetzt, also eher mit einem Minuszeichen statt mit einem Unterstrichenzeichen zu arbeiten. Ich würde allerdings jetzt nicht bestehende Websites umbauen, nur damit man die Keywords so einbauen kann. Ich denke, bei jedem Umbau ist es so, dass es eine längere Zeit braucht, bis wir jetzt eine neue URL-Struktur erkennen können. Und da würde ich jetzt wegen so etwas, würde ich jetzt eine Website zum Beispiel nicht umstellen. Und eben wie gesagt, wir verwenden die Keywords in der URL schon, aber es ist einfach ein sehr kleiner Faktor. Das heißt, wenn für, sag ich mal, konkurrenzstarke Suchanfragen, Seiten erscheinen in den Suchergebnissen, dann wird das ziemlich sicher nicht wegen den Keyword in der URL-Sign, sondern wegen all den anderen Faktoren, die wir dazu aufnehmen. Vor kurzem wurde in den Medien wie der Wall Street Journal über eine Art Kooperation zwischen Verlage und Google gesprochen. Ich denke, das geht in Richtung First Click Free und Flexible Sampling. Was hat es damit auf sich? An und für sich ist das eine Weiterführung oder vielleicht ein weiterer Ausbau, sag ich mal von First Click Free, der sich nicht nur auf die ersten paar Clicks bezieht, sondern der den Verlagen ein bisschen mehr Flexibilität gibt, wie sie das gestalten können. Das heißt, sie können dann selber sagen, wie oft Benutzer auf ihre Seiten gehen können. Das kann vielleicht ein bestimmter Anzahlmal pro Tag sein oder pro Monat. Das kann man selber ein bisschen gestalten. Man hat natürlich jeweils den Nachteil, dass wenn man da zustrickt ist, dann merken das die Besucher auch und gehen dann einfach weniger oft auf die Website hin. Das ist der Nachteil, das heißt, man muss für sich selber herausfinden, wie viel ich meine Inhalte direkt zeige, wenn jemand kommt aus dem Suchergebnis und wie viel möchte ich da vielleicht dann entsprechend auch meine Paywall zeigen oder erwarten, dass Benutzer sich registrieren, damit sie die vollen Inhalte sehen, solche Sachen. Wie der Name schon sagt, vom Flexible Sampling kann man sehr flexibel machen, indem man auch sagt, man nimmt nicht nur eine Zahl, sondern man experimentiert vielleicht ein bisschen oder man nimmt verschiedene Schwellen für verschiedene Arten von Benutzer. Das heißt, wenn ich merke, dass jemand regelmäßig auf meine Website zurückkommt, dann kann ich da vielleicht eher mal eine Paywall zeigen und sagen, hey, du bist jetzt so schon so oft gekommen, vielleicht wäre ein Abo das Richtige für dich. Bezüglich der Art, wie man das technisch gestaltet, ist es so, dass man am besten die Inhalte, die hinter dem Paywall quasi verborgen sind, wenn die Paywall gezeigt wird, mit Structured Data markiert. Das heißt, man gibt an, welche CSS-Elemente versteckt werden automatisch und dann je nachdem wie der Besucher kommt, zeigt man die vollen Inhalte oder zeigt man einen Teil der Inhalte mit diesem Paywall-Teil oder nicht. Eine gute Frage dazu, weil eben in dem Best Practices steht eben das, was du gerade erklärt hast mit Metering, wenn ich das richtig da verstanden habe, dass man eben schlussendlich eine bestimmte Anzahl an Artikeln freigeben kann und dann gibt es eine zweite Methode, die heißt ja Lead In, dass man schlussendlich eine Art teaser Text vor der Paywall schon anzeigt und eben, dass der User dann nicht sofort dann abspringt. Meine Frage wäre, sind es beide Methoden führen dazu, dass Google den ganzen Inhalt indexiert und schlussendlich der ganze Inhalt dann als zu 100% dich ranken kann oder ist es eher? Ja, das ist auch für sich die Idee, dass wir die vollen Inhalte sehen können, damit wir das auch entsprechend in den Suchergebnissen zeigen können. Okay, aber mit dieser Lead In-Methode würde es heißen durch den Structured Markup, dass ihr schlussendlich dann das auch auswerten könnt. Genau, genau. Okay, okay, alles klar. Also, man würde auch den gleichen Structured Data verwenden, wenn man die ganzen Inhalte verstecken würde, wenn man jetzt nur eine Paywall zeigen würde. Okay, alles klar, super, danke. Ich denke, das gibt den Publisher ein bisschen eine Möglichkeit, da einige Sachen auszuprobieren und vielleicht wird es sein, dass sie am Anfang ein bisschen zu stark in Richtung Paywall gehen und dann merken, dass sie benutzen, dass sie überhaupt nicht gerne haben. Vielleicht fangen sie da ein bisschen sanfter an sich an andere Grenzen heranzutasten und probieren ein bisschen aus. Wir haben ja gesehen auch schon vorher, dass Publisher das teilweise ein bisschen ausprobiert haben in verschiedenen Hinsichten und so möchten wir einfach sicherstellen, dass es wirklich auch klar ist aus unserer Sicht, dass man das so ein bisschen machen kann. Natürlich könnte ich dann auch relativ wenig Artikel pro Monat dann frei, also ohne Paywall zeigen. Also, wenn ich jetzt zum Beispiel sage, ja, ich will meine Zahl auf 3 reduzieren oder sowas im Monat, dann würde auch der gesamte Content dann ranken. Genau, ja. Okay, super, danke. Und eben, das kann man so machen, dass man das auch flexibel gestaltet bezüglich dem Benutzer. Manche vielleicht 3 sehen, manche können 6 sehen oder 10 oder je nachdem, wie man das halt aufteilen möchte oder dass man sagt, geografisch möchte ich das aufteilen, das ist alles euch überlassen. Okay, super, das ist interessant für uns zumindest. Danke. Super. Okay, eine Frage zu UTM-Parametern. Wir verwenden auf unserem Blog Parameter mit quasi UTM Source und Kampagne und so weiter. Wie man das mit Analytics oft macht. Die Zielseite ist mit Canonical auf quasi die einfache URL gesetzt, ist mit der Canonical Auszeichnung das Problem Duplicate Content und unnatürlicher Linkaufbau aus der Welt. Oder sollte man in Robots Text noch zusätzlich die Parameter ausschließen oder sollte man etwas anderes machen. Ja, das sind verschiedene Sachen, die da zusammenkommen. Vielleicht erst einmal das ganze bezüglich unnatürlichen Linkaufbau. Ich denke, das ist ein ganz anderes Thema. Das heißt, wenn man zum Beispiel Werbung auf anderen Websites kauft und diese Werbung ein Link auf eure Website hat ohne Rel No Follow, dann ist es trotzdem unnatürlicher Link, egal wie man das mit dem Canonical auf der anderen Seite entsprechend quasi auffängt. Das heißt, das ist an und für sich ein ganz anderes Thema als nur Duplicate Content und Rel Canonical und Parameter. Bezüglich Parametern und Rel Canonical ist das eigentlich eine saubere Lösung, wenn man das mit dem Rel Canonical so machen kann. Was da einfach passiert ist, wir crawl und indexieren zunächst trotzdem die Version mit den Parametern, dann verarbeiten wir die Seite nach der Indexierung und dann konzentrieren wir uns auf den Canonical URL. Das heißt, im ersten Moment wird es so sein, dass wir trotzdem diese URLs crawlen, weil wir die irgendwie erst mal auswerten müssen. Wir wissen ja nicht, welche Parameter weggelassen werden. Und dann im zweiten Schritt konzentrieren wir uns auf die Haupturale und das ist eigentlich unproblematisch. Es ist einfach so, dass wenn man jetzt gezielt nach diesen UTM-Parametern sucht mit einer In-Urall-Abfrage oder einer Side-Abfrage, dann kann es sein, dass man die in den Suchergebnissen auch findet, einfach weil sie im ersten Schritt einmal so indexiert worden sind. Das ist aber nicht weiter schlimm, das ist eigentlich nur vom technischen Her, so ist das halt so. Per Robots Text würde ich das auf jeden Fall nicht machen, weil wenn man das Per Robots Text blockiert, diese Parameter, dann wissen wir gar nicht, dass wir die zusammenklappen können. Wenn irgendjemand auf eure Seite mit Parameter verlinken würde und das Per Robots Text blockiert ist, dann geht dieser Link an und für sich ins Leere. Dann können wir das nicht mit euren Inhalten zusammenführen. Eine andere Variante, was man vielleicht machen könnte, ist mit Search Console kann man URL-Parameter auch angeben und sagen, diese Parameters sind irrelevant für meine Website. Das wäre vielleicht eine Variante, die man hier auch machen könnte. So kann man ein bisschen steuern, dass wir gar nicht einmal diese URLs crawlen müssen, dass wir zumindest schon von Anfang an wissen, dass wir diese Parameter weglassen könnten und uns direkt auf die anderen URLs konzentrieren können. Das wären dann für sich die Varianten da und eben bezüglich, wie man jetzt das ganze Tract auf der eigenen Seite, dass man so etwas für Analytics nimmt, das ist an und für sich überhaupt kein Problem. Viele Webmaster wollen mit ihren Produkten-Dienstleistungen im Ranking ganz vorne stehen. Ist es möglich, dass eine Domain mit Keywords und Kombination alle Plätze auf Seite 1 belegt? Theoretisch ist das schon möglich. Meistens ist das etwas, wo wir dann sehen, dass jemand vielleicht gezielt nach einer Marke sucht. Das heißt, wenn jemand nach Google sucht, dann wird es wahrscheinlich Sinn machen, dass wir verschiedene Google-Seiten auch zeigen in den Suchergebnissen oder wenn jemand nach eurer Marke sucht, dann macht es wahrscheinlich Sinn, dass wir die Seiten von eurer Webseite zeigen in den Suchergebnissen und nicht unbedingt ein Mix aus allen möglichen anderen Webseiten, die auch über dieses Thema schreiben. Aber das ist an und für sich so ein Thema, wo wir auf unserer Seite sagen, es gibt keine absolute Grenze, wie oft eine Webseite erscheinen kann in einer Suchergebnissen-Seite. Es kann manchmal 2-mal erscheinen, manchmal 5-mal. Im extremen Fall kann das durchaus sein, dass die ganze Seite mit Ergebnissen von dieser Webseite gefüllt ist. Ich betreibe ein WordPress-Tremen-Portal mit anhängendem Branchenverzeichnis. Im Juni habe ich das Verzeichnisplugging gegen eine umfangreichere Lösung ausgetauscht. Und verhältnismäßig viele neuen Adressen hinzugefügt. Das komplette Verzeichnis habe ich indexieren lassen. Mal kurz schauen, wie das da weitergeht. Ich glaube, das geht in Richtung Ladezeit noch ein. Ob das jetzt einen großen Einfluss auf die Indexierung hat oder nicht, oder ob man das komplette Verzeichnis vielleicht woanders platzieren sollte. Grundsätzlich ist es so, dass die Ladezeit aus unserer Sicht eher unterteilt wird zwischen Webseiten, die sehr, sehr langsam sind und Webseiten, die einigermaßen normal schnell sind. Wenn das jetzt eine einigermaßen moderne Webseite ist und mit dem Plug-in das Ganze vielleicht nicht Sekunde oder zwei länger geht, dann ist das überhaupt kein Problem. Wenn hingegen die Seite wirklich mehrere Minuten braucht, bis sie geladen ist, dann ist das schon eher ein Problem. Und dann wäre das etwas, wo wir aus unserer Sicht vielleicht vom Ranking her etwas unternehmen würden. Bezüglich Indexierung hat das aber in der Regel kein Einfluss. Das heißt, wir merken zwar dann schon, dass der Server ein bisschen langsamer ist und wir crawlen entsprechend dann auch ein bisschen weniger bei dieser Webseite, wenn wir merken, dass der Server das nicht so verträgt. Aber in der Regel kommen wir trotzdem recht gut durch und können die meisten Seiten crawlen und indexieren. Wenn man jetzt sehr viele Inhalte neu dazugefügt hat, dann kann es einfach sein, dass es eine gewisse Zeit geht, bis wir das alles neu verarbeitet haben. Und von dem her denke ich, könnte das an und für sich normal sein, dass es jetzt einfach ein bisschen länger geht, bis das verarbeitet ist. Was ich aber trotzdem vielleicht machen würde, ist im Hilfeforum oder mit anderen Webmasern das mal anschauen und einfach sicherstellen, dass es keine technischen Hürden gibt, die die Seite an und für sich vom Crawling blockieren. Dass wir wirklich links zwischen den Seiten finden können, dass die Seiten aufrufbar sind von Google-Seite, all solche Sachen. Und vielleicht auch, dass man Redirects eingerichtet hat, die die URL-Struktur auch verändert hat. Wir bemerken gerade große Einbrüche in den Rankings bei verschiedenen Seiten im Travel-Bereich. Alle Seiten setzen zwar auf das selbe Thema, aber unterschiedliche Reisenzielen in unterschiedlichen Sprachen. Ja, ist schwierig zu sagen ohne irgendwelche Beispiele, was das sein könnte oder worauf man da irgendwie aufpassen müsste. Ich denke, was ich einfach oft sehe, gerade bei Reiseseiten, ist, dass die Seiten, wenn sie in unterschiedlichen Sprachen sind, manchmal einfach automatisch übersetzt werden und so von der Qualität her sehr schlecht sind. Und das ist vielleicht etwas, worauf ich achten würde, dass wirklich die Seiten, die ich veröffentlicht, dass sie wirklich für sich selber stehen können und dass sie von der Qualität her so sind, dass sie wirklich auch tragbar sind, dass ihr dazustehen könnt und sagen könnt, dass es wirklich eine gute Seite zu diesem Thema in dieser Sprache passend für Benutzer, die jetzt in dieser Sprache nach diesem Thema suchen. Und dass man dann nicht unbedingt einfach sagt, wir haben eine deutsche Seite, ist eigentlich sehr gut, aber die italienische Seite oder französische Seite habe ich keine Ahnung, wie das übersetzt worden ist. Da würde ich einfach ein bisschen aufpassen. Das heißt, nicht einfach wild Seiten generieren lassen, ohne dass man wirklich sicher ist, dass die Seiten von der Qualität her wirklich hochstehend sind. Gibt es eine Möglichkeit, jemanden bei euch zu melden, der Spammy-Markups verwendet? Das heißt, jemand, der Event-Markup verwendet, ohne dass es wirklich ein Event ist. Am einfachsten geht das in Search Console über das Spammelde-Formular. Da haben wir ein eigenes Formular für Rich Snippet Spam, glaube ich. Und da könnt ihr das an das Team weiterreichen. Wenn ihr das Gefühl habt, dass ein bisschen mehr Kontrolle braucht, weil das vielleicht ein kompliziertes Thema ist oder weil das viele Seiten sind, die zusammenhängen und quasi das große Bild, das Problem ist und nicht eine einzelne Seite, dann könnt ihr das auch mir direkt melden oder vielleicht auch im Deutschen Hilferforum. Da sind Mitarbeiter von uns auch immer aktiv und können solche Spam-Meldungen auch ein bisschen entgegennehmen und kurz untersuchen. Ein Kunde von uns hat für einen bestimmten Suchbegriff mit recht viel Suchvolumen immer mit der Startzeit ganz gut gerankt. Vor einem Jahr war das Ranking für diesen Begriff komplett verschwunden. Nach ein paar Monaten ist er wieder weit hinten auf den Suchergebnissen seiten. Plötzlich hat eine andere URL-Gerankt, die nicht so optimal ist. Die frühere Agentur hat viel Linkbildung auf den genannten Begriff betrieben. Wir haben die Disavow-Datei erweitert und geduldig gewartet. Nach einem Jahr hat sich aber noch nicht viel getan. Die Startseite wäre zwar laut Search Console manchmal ausgeliefert, aber auch auf ganz passablen Positionen. Aber die Impressionen stimmen nicht ganz mit den möglichen Impressionen überein. Kann es sein, dass der Kunde noch eine Abstrafung für dieses Ranking hat? Normalerweise, wenn eine Abstrafung davor handelt, dann ist das eine manuelle Maßnahme. Das heißt, jemand auf unserer Seite vom Web-Spam-Team normalerweise greift der manuell ein und sagt, das ist jetzt ein Problem, dass die Links oder Website gesetzt worden sind. Das müsste man manuell ein bisschen zurückstufen oder anpassen in den Suchergebnissen. Aber wenn das gemacht wird, dann ist das immer sichtbar in Search Console. Das heißt, wenn in Search Console bei den manuellen Maßnahmen nicht steht, dann ist an und für sich das Ranking, dass diese Website hat, ist das normale algorithmische Ranking, wie das unsere Algorithmen an und für sich anschauen würden. Bezüglich Search Console mit den Impressionen ist es so, dass wenn man sieht, dass eine Seite unerwartet hoch rankt in Search Console, in Search Analytics, und man eine niedrige Impressionenzahl hat, dann kann es sein, dass diese Impression aufgrund von personalisierten Suchen vielleicht zustande kommt. Das heißt, wenn ich zum Beispiel ein sehr allgemeines Keyword habe und wo ich erwarten würde, dass die Gesamtimpressionen sehr hoch sind, meine Seite aber eine sehr niedrige Impression zeigt für dieses Keyword, aber ein unerwartet hohes Ranking, dann ist es wahrscheinlich so, dass wir aus Personalisierungsgründen diese Seite zu einigen Besuchern an dieser Position gezeigt haben. Aber dass die Mehrheit der Besucher, die diese Seite nicht an dieser Position in den Suchergebnissen sieht. Ich vermute, dass es ungefähr das, was da passiert. Bezüglich Disavow und Linkbuilding, was vielleicht früher gemacht worden ist, wichtig ist vielleicht auch da, dass mit dem Disavow werden natürlich diese Links ganz quasi entfernt aus unserem System, nicht mehr beachtet für das Ranking. Das heißt, wenn sie früher für das hohe Ranking verantwortlich waren und jetzt entfernt werden oder von unseren Algorithmen quasi ausgeschlossen werden sowieso, dann kann es durchaus sein, dass die Seite jetzt einfach an einer niedrigen Stelle rankt in den Suchergebnissen. Das ist anfühlig normal. Was man da am besten machen kann, ist ein bisschen schwierig zu sagen. Ich denke, das hängt ein bisschen seit Zelda ab. Ich würde vielleicht trotzdem mal untersuchen, ob es noch einige Links gibt, die man per Disavow ausschließen müsste und allen für sich sonst einfach quasi vorwärts schauen und nach vorne arbeiten und weiter an der Website am Gesamtbild entsprechend weiterarbeiten. Jetzt kommt noch eine Staging-Website-Frage. Welche Technologien oder herangehensweise empfiehlt es zu den Webmastern um eine Staging-Website gangbar zu machen, ohne dass sie im Google Index erscheint? Ja, es gibt da verschiedene Wege, wie man das machen kann. Es gibt da ganz unterschiedliche Ansätze. Manche machen das per Robots Text, dass sie zum Beispiel ein Subdomain ganz sperren. Andere machen das mit No-Index-Med attacks, dass zwar gekrawlt werden kann, aber dann doch nicht indexiert wird. Andere machen das vielleicht mit auch ein IP-Blog. Das heißt, dass man sagt, nur unsere IP-Adressen dürfen drauf zugreifen. Oder was man auch manchmal sieht, ist, dass das per server-side authentication gemacht wird. Das heißt, dass man sich mit einem Benutzernamen und Passwort anmelden muss, um auf diese Website zu geladen. Aus unserer Sicht gehen eigentlich all diese Varianten. Manche haben Vor-Nachteile. Zum Beispiel, wenn man nur mit dem No-Index arbeitet, auf einer Website, dann ist es so, dass wir trotzdem die Staging-Site unter Umständen crawlen. Vielleicht ist das ein Problem, vielleicht ist das weniger ein Problem. Wenn man mit Robots Text arbeitet, dann ist es so, dass wir Links, die auf diese Staging-Sites gehen, was wahrscheinlich selten der Fall sein wird, aber könnte ja passieren, dass wir die nicht verarbeiten können. Das heißt, wir sehen dann, dass es einfach per Robots Text gesperrt wird. Und dann indexieren wir unter Umständen die URL ohne die Inhalte zu sehen. Das heißt, wir wissen dann nicht, dass es eigentlich etwas ist, was versteckt werden sollte und entsprechend nicht sichtbar sein sollte. Was ich da empfehle, ist, dass man eher auf IP-Ebene arbeitet oder mit der Authentikation, das heißt, mit dem Benutzennamen und Passwort, weil da hat man dann trotzdem die Möglichkeit, die Robots Text-Datei sauber zu erstellen für die Staging-Website, dass man hat auch die Möglichkeit, sauber mit den Robots Mattertags auf den Seiten zu arbeiten, das auch selber zu kontrollieren. Weil was wir immer noch relativ häufig sehen, ist, dass man ein Staging-Website erstellt und dann die mitsamt der Staging-Robots-Text-Datei einfach live setzt und dann auf einmal ist die gesamte normale Website per Robots Text auch gesperrt. Oder die gesamte normale Website hat ein No-Index-Metertag drauf. Einfach, weil man vergessen hat, das entsprechend zu entfernen. Und mit der IP-Adresse oder mit dem Benutzennamen ist es sehr offensichtlich, dass man das vielleicht mitkopiert. Und da gibt es dann auch nur ein Ort, wo man das entsprechend entfernen muss und dann ist das auch gemacht. Bezüglich Testen ist es natürlich immer ein bisschen schwierig. Man möchte ja die Staging-Website auch ein bisschen testen, um zu kontrollieren, was da passiert. Eine Möglichkeit, die man machen kann, ist mit einem Art Proxy zu arbeiten. Das heißt, ich glaube, wir haben das irgendwo dokumentiert, mit NGROK. Weiß gar nicht, wie man das ausspricht. Aber es gibt da verschiedene Proxy, die man an für sich lokal laufen lassen kann, die dann eine öffentliche Hostname erstellen für die eigentliche Website. Und das kann man soweit, ich weiß, einrichten, dass es auch mit Benutzennamen und Passport dann entsprechend auf die Website zugreift oder einfach auf ein Localhost-Server zugreift, wenn man lokal etwas testen will. Und so kann man dann eine öffentliche Hostname erstellen für so etwas. Das mit Search Console testen, mit den verschiedenen Testing Tools, für Structure Data oder AMP oder was man testen will. Und danach kann man das abschalten und dann ist das an und für sich wieder weg. Das wäre vielleicht die einfachste Möglichkeit, so etwas zu machen. Es ist im Moment nicht so, dass man eine IP-Adresse für Googlebot angeben kann für die Testing Tools, um so quasi durch eine Späre durchzugehen. Wir haben einen sehr großen Online-Shop mit mehr als 2,5 Millionen Produkte. Die Product URLs liefern wir in Sitemaps, macht das aus Sinn oder soll man lieber auf das normale Crawling setzen. Wir haben nämlich festgestellt, dass Google einige Sitemaps noch nicht einmal monatlich abruft, sondern selten haben. Das ist natürlich, weil das Sitemap Index riesengroß ist. Wäre es denn sinnvoll, die Unmengen an Detail-Seiten in Sitemaps zu entfernen und nur die Struktur-Seiten, also Kategorieren zum Beispiel, drin zu lassen. Ja, ich denke, vielleicht im ersten Schritt ist es natürlich so, dass wir nicht alle Websites gleich stark crawlen und indexieren. Und wenn ich jetzt neue Seiten drauf lade, dann wird es wahrscheinlich so sein, dass wir diese Seiten eher langsam crawlen und vielleicht nicht einmal vollständig indexieren, einfach weil wir das Gefühl haben, lohnt sich das wirklich, so viel Aufwand zu betreiben für diese eine Website, für die wir nicht einmal wissen, ob sich das vielleicht für den Benutzer auch irgendwo Sinn macht. Das vielleicht mal vorne weg. Ich denke, wenn das jetzt eine bestehende Website ist, die schon lange indexiert ist und eigentlich gut soweit da steht in den Suchergebnissen, dann ist das wahrscheinlich weniger ein Problem. Aber einfach wenn man jetzt mit einer neuen Website anfängt, lohnt sich das irgendwie ein bisschen im Hinterkopf zu behalten, dass Google nicht einfach losgeht und Millionen von Seiten crawled und indexiert, nur weil sie irgendwie mal angegeben worden sind in den neuen Sitemap-Dateien. Bezüglich Crawling der Sitemap-Dateien, was ich da einfach machen würde, die einzelnen Sitemap-Dateien, wenn sie sich verändern auch per Ping an uns zu melden, das kann man ja allen für sich auch automatisieren und so kann man einerseits die Sitemap-Index-Dateien per Ping quasi an uns melden und andererseits auch die einzelnen Sitemap-Dateien, so können wir die ein bisschen schneller durcharbeiten. Ich würde auf jeden Fall mit der Sitemap-Datei weiterarbeiten. Ich denke, das hilft auf jeden Fall. Es macht es auch ein bisschen einfacher bezüglich der ganzen Problemdiagnose in Search Console. Wenn wir wissen, dass eine URL in der Sitemap-Datei ist, dann nehmen wir an, dass die vielleicht auch indexiert werden sollte und dann können wir das entsprechend auch ein bisschen hervorheben, wenn zum Beispiel Crawling-Fehler auftreten, solche Sachen. Von daher würde ich jetzt nicht die Sitemap-Datei umstrukturieren, nur dass da weniger URLs vorhanden sind in der Sitemap-Datei. Eine Sache, die wir auch immer wieder sehen, ist, weil zum Beispiel die Hauptzeit in einer Website eher häufiger gecrawlt werden, zum Beispiel die Startseite oder die größeren Produktekategorien in einem eCommerce Shop, lohnt es sich manchmal, dass man auch neue oder veränderte Produkte entsprechend ein bisschen höher in den Kategorienebenen auch verlinkt. Auf der Startseite den Shop auflade, das vielleicht auf der Seite oder unten oder sonst irgendwo entsprechend die neuen Produkte auch verlinkt sind. Einerseits macht das für Benutzer natürlich Sinn, die finden die neuen Produkte auch ein bisschen schneller. Für Googlebot macht das aber auch Sinn, weil wir sehen dann direkt beim Crawling von der Startseite, da sind jetzt zehn neue Produkte aufgelistet oder vielleicht noch ein Link zu weiteren Neuigkeiten und alle verarbeiten und können so die neuen Sachen ein bisschen schneller ins Index hineinnehmen. In der neuen Version von Search Console haben wir sehr viele URLs mit dem Hinweis indexiert, aber nur wenige Zugriffe. Was bedeutet das? Sind das schlechte URLs oder was könnte das bedeuten? Wir haben das in Search Console ein bisschen angeschaut und überlegt, wie könnte man das so gestalten, dass sich Webmasters auf diese Sachen konzentrieren können, die wirklich relevant sind und dass man sich ein bisschen weniger davon ablenken lässt, mit Sachen, die eigentlich vorhanden sind, aber nicht so kritisch sind. Und so haben wir da ein bisschen diese Einteilung gemacht und gesagt, die sind zwar indexiert, das heißt, vielleicht interessieren euch diese URLs, vielleicht können wir euch Informationen machen, aber es ist nicht so, dass das jetzt wirklich die wichtigsten URLs auf eurer Website sind oder zumindest laut unseren Untersuchungen und dementsprechend müsst ihr die nicht als erster Priorität anschauen, wenn irgendetwas schräg läuft mit diesen URLs. Und so haben wir das einfach versucht, ein bisschen einzuteilen. Ich weiß nicht, ob wir das längerfristig so beibehalten oder ob das einfach mehr Verwährung stiftet oder ob wir das in einem großen Haufen in einem großen Haufen sagen, all diese URLs sind indexiert. Wir schauen mal, wie das mit dem Feedback aussieht in Search Console. Sollte man ein No-Follow auf Social Share Buttons setzen, kann man machen, wenn man will, muss man nicht. Ich denke, das ändert in der Regel wenig, weil die Links per Robots Text blockiert werden, weil das so diese interaktive Links sind, die dann aufgehen, wo man sich entweder anmelden muss oder wo man quasi schon die Inhalte schon ein Fenster hervorgerufen kriegt, die man dann trotzdem noch abschicken muss. Und von dem her denke ich, ändert das eigentlich wenig, ob man No-Follow setzt oder nicht. Eine Frage zu Duplicate Content. Angenommen, eine e-Commerce-Site von Herstellern als Science. Wie bewertet dies Google? Nehmt die SEO-Relevanz des Shops ab. Da weniger unique Content oder hat diese Maßnahme kein Einfluss auf die SEO-Performance. Sie hat schon einen Einfluss, in dem Sinn, dass wenn jemand nach der allgemeinen Produktbeschreibung oder nach irgendetwas in der allgemeinen Produktbeschreibung sucht, dann nehmen wir in der Regel eine Einflussbeschreibung haben und suchen dann einen von diesen Außen und zeigen sie ihnen den Suchergebnissen. Und meistens hängt das ein bisschen davon ab, welches dieser Shops vielleicht die stärkere ist oder welches jetzt andere Faktoren hat, die da entsprechend zusammenpassen. Wenn das zum Beispiel ein Buch ist und wir wissen, dass ein Lokaler Laden das gleiche Buch hat, dann zeigen wir vielleicht eher die lokale Version oder gehen auch Sprache vielleicht, mit Sprache, wird das wahrscheinlich nicht so zusammenfallen, weil dann ist ja die Beschreibung nicht 1 zu 1 kopiert. Aber wir nehmen da die verschiedenen Faktoren zusammen und wählen dann einen von diesen Seiten aus. Das heißt, wenn ich jetzt eigene Produktbeschreibungen habe und das selber ein bisschen antasse, dann ist es so, dass wir die Seiten eigentlich separat in den Suchergebnissen zeigen können und dass wir dann nicht überlegen müssen, welches dieser Varianten die richtige ist, sondern wir können eigentlich immer Eure auch dazu zeigen. Vom Ranking her ist das schwierig zu sagen, vom Aufwand her ist das natürlich immer etwas, was da dazukommt und von dem her versuchen wir dann trotzdem mit den normalen Websites zu arbeiten, die auch kopierte Beschreibungen haben. Aber irgendwie gesagt, wählen wir dann in der Regel 1 von diesen Varianten aus. Darf ich kurz dazwischen fragen? Ja, genau. Auf die ganze Siorelevanz des Shops hat das keine Auswirkung. Das bezieht sich wirklich nur auf die Produktbeschreibung des Artikels. Das kann man schon so sagen. Genau, ja. Alles klar. Besten Dank. Ja. In einem Projekt haben wir unter zwei unterschiedlichen Domains Sprachvarianten für Spanisch und Argentinien und auf der anderen Seite Spanisch für Spanien. Für Spanien zu verhindern haben wir mit hreflang gearbeitet und kontrolliert, dass das stimmt. Dennis sagt Search Console, dass die beiden Seiten keine hreflang tags vorhanden sind. Heißt das, dass Google sie tatsächlich nicht erkennt und wir in die Gefahr einer Abstrafung wegen Duplicate Content laufen oder ist es im Zweifel nicht so schlimm? Also Abstrafung wegen Duplicate Content ist eigentlich nicht. Das ist etwas, was wir eher in Situationen machen, wo wir feststellen können, dass die gesamte Website wirklich einfach zusammenkopiert ist aus einer anderen Website oder aus verschiedenen anderen Websites und wirklich die gesamte Website keinen Mehrwert für das Internet eigentlich bringt. Wenn das zwei Websites sind, die für zwei unterschiedliche Länder sind oder unterschiedliche e-commerce-Sites sind, dann ist das aus unserer Sicht eigentlich total okay. Wir erkennen dann höchstens, dass die Inhalte gleich sind und wählen dann ein von diesen Varianten aus und zeigen die in den Suchergebnis. Was ich aber trotzdem vielleicht in einem solchen Fall machen würde, ist sicherstellen, dass der hreflang tag sauber gesetzt ist, dass der hreflang tag vielleicht auch möglichst weit oben im Head Teil der Seite vorhanden ist oder dass man mit der Sidemap Datei mit dem hreflang tag arbeitet, sodass wir wirklich auch diese tags finden können und auswerten können. Wenn man das jetzt neu gesetzt hat auf einer Website und das vielleicht jetzt noch nicht lange ist, seitdem er das eingebaut hat, dann kann es einfach eine gewisse Zeit gehen, bis wir das wirklich sauber verarbeitet haben. Das heißt, bei hreflang ist es immer so, dass wir den Rücklink auch finden müssen Das heißt, wir müssen beides dieser Seiten erstmal crawlen und indexieren und dann verarbeiten und dann sicherstellen, dass die Links wirklich aufeinander zeigen und wenn wir feststellen können, dass das das stimmt, dann können wir das entsprechend aufnehmen als ein Paar bei den hreflang Statistiken. Aber das kann, je nach Website kann das vielleicht einige Wochen gehen oder vielleicht auch einige Monate bis wir wirklich all diese Seiten und Paare verarbeitet haben. Mal schauen, wie und wo kann man geklonte Websites bei Google melden, sodass diese aus dem Index verschwinden. Bei einem unserer Projekte wurde selbst der Google Analytics Code kopiert, sodass nun verfälschte Daten im Konto erfasst werden. Ahnen für sich kann man das als normalen Websperm entsprechend melden bei uns. Was man auch machen kann unter Umständen wenn die gesamten Inhalte kopiert werden kann man vielleicht mit einem Rechtsanwalt das mal anschauen und überlegen, ob vom DMCA her irgendetwas machbar ist, dass man da vielleicht so direkt auf den Websitebetreiber ihm sagen kann ihr sollt das jetzt irgendwie unterlassen oder mit dem Hosting Provider mal sprechen und sagen, dass es unsere sind unsere kopierten Inhalte, die davon nicht so zeigen und das kann man uns dann auch melden. Was allerdings mit dem DMCA ist ist, dass das ganze pro Seite ist, das heißt pro URL und nicht für die gesamte Website. Das heißt, man kann nicht beim DMCA sagen, meine gesamte Website ist jetzt hier kopiert, sondern man muss die einzelnen Seiten entsprechend angeben. Man kann durchaus schon mehrere Seiten auch angeben und wir verarbeiten das dann entsprechend den normalen Prozess dort. Ich habe eine Designfragen zum Mobile First Indexing oh, das ist eine, sieht lang aus. Mal schauen. Zum Mobile First Indexing bei abweichenden URLs, also nicht responsive wie ähnlich müssen die Inhalte sein welche Abweichungen sind nicht okay was es mit anderen strukturierten oder equivalenten Inhalt, was wenn Bilder fehlen zum Beispiel an und für sich erwarten wir, dass die mobile Version equivalent ist vom Inhalt und von der Funktionalität her zur Desktop Version. Das ist etwas, was wir eigentlich auch mit dem normalen Mobile Friendly Verknüpfung quasi erwarten. Das heißt, dass wenn jemand auf die Desktop Version geht, sind da die gleichen Inhalte und die gleiche Funktionalität ist vorhanden wie auf der mobilen Version. Wenn die Texte ein bisschen anders sind, wenn die Texte ein bisschen gekürzt sind, wenn die Sidebar weg ist und ein anderes Element dieser Seite verschwinden, die nicht zum Hauptinhalt dieser Seite gehören ist das an für sich ganz okay. Wichtig ist einfach, dass man sich auch bewusst ist, dass mit dem Mobile First Indexing nehmen wir die mobile Version und nehmen die für die Indexierung und nicht mehr die Desktop Version. Das heißt, wenn in der mobilen Version zum Beispiel alle Bilder entfernt werden dann haben wir diese Bilder auf einmal nicht mehr und können die in der mobilen Version finden. Das heißt, es ist ein bisschen euch überlassen, was ihr indexiert haben wollt und wenn ihr die Sachen ganz aus der mobilen Version herausnehmt und wir die mobile Version nehmen für die Indexierung dieser Seiten, dann kann das sein, dass die Inhalte wirklich dann auch fehlen für das ranking. Wir haben festgestellt, dass bei den meisten Seiten es ist praktisch, aber es lohnt sich gerade, wenn man unterschiedliche URLs hat trotzdem mal zu kontrollieren. Wir bringen auf jeden Fall noch ein Blogpost mit verschiedenen Sachen, die man achten muss, damit man das selber ein bisschen testen kann, selber ein bisschen überlegen kann. Wir planen auch nicht von einem Tag auf den nächsten alles umzuschalten auf Mobile First Indexing, sondern wir testen die Seiten auch und wenn wir feststellen können, dass die einigermaßen okay sind, dann schalten wir die Schritt für Schritt dann entsprechend auch hoch. Das heißt, es ist nicht so, dass irgendwie der erste Dezember kommt und ihr müsst alles bereit haben, sondern wir versuchen das schon einigermaßen Schritt für Schritt zu machen. Was tun, wenn nicht alle Seiten mobile sind, wenn eine Seite keine mobile Version hat, dann indexieren wir die Version, das kann dann umschänden, die Desktop Version sein, das ist ahnen für sich okay. Wenn es keine 1 zu 1 Zuordnung zwischen Mobile und Desktop Seiten gibt, dann indexieren wir in der Regel ja beide Seiten. Das ist eigentlich jetzt auch schon der Fall. Das heißt, wenn wir mobile Seiten erkennen, die nicht mit dem Rail Canonical zur Desktop Seite verzeigen, dann indexieren wir die im Moment auch schon als separator URL und das wird dann entsprechend auch weiterhin so sein. Internal Links könnt ihr machen, wie ihr wollt. Normalerweise ist es so, dass die mobile Version natürlich Internal Links weiter zur mobile Version hat. Das ist ahnen für sich auch normal. Für das Crawling macht das ja auch Sinn, dass wir quasi innerhalb der gleichen Version alles Sachen finden können. Und dann noch zum ATREFLANG mit der mobile Version und Desktop Seite. Ja, wir haben da lange Diskussion intern gehabt, wie wir das am besten machen können. Und am Ende hat sich herausgestellt, dass es doch am klarsten für die meisten Webmaster ist, wenn wir wirklich die ATREFLANG Links im Reciprog machen. Das heißt, dass die ATREFLANG Links auf der mobilen Seite weiter zur mobilen Seite zeigen, sodass das eigentlich klar untereinander verbunden ist. Und auf der Desktop Version, Desktop zu Desktop, entsprechend mit ATREFLANG verbunden ist. Aber das natürlich vom Mobile zur Desktop und zurück entsprechend dieser Link über den Alternate Mobile und Rail Canonical besteht. Das heißt ATREFLANG ist dann auch wie die Internal Verlinkung innerhalb der gleichen Version gedacht. Das heißt, das was ich da damals in diesem Interview gesagt hat, ist ahnen für sich jetzt veraltet und nicht der Fall. Wir werden wir auf jeden Fall auch noch in der Blogpost entsprechend ein bisschen ausführlicher erklären, sodass man da nicht ganz überrascht ist, wie sich das so auf einmal anders herausstellt. Aber wir versuchen auch Seiten zu verarbeiten, die das jetzt nach diesem Schema gemacht haben, die vielleicht jetzt schon mit der Desktop Version die ATREFLANG Link gemacht haben. Aber am einfachsten ist es schon, wenn wir einfach sagen, innerhalb der gleichen Version sollen alle Links sein, das heißt die Internal Verlinkung sowie auch die ATREFLANG Verlinkung. Am allereinfachsten ist es natürlich auch, wenn man einfach sagt, wir stellen auf Responsive Design um und haben nur eine URL und dann hat man diese ganzen Schwierigkeiten nicht und muss sich da den Kopf nicht zerbrechen, welche URL mit welcher URL verbunden wird. Okay. Sieht aus, es sind dann noch zwei Fragen oder noch vielleicht mehrere. Ich muss allerdings ein bisschen früher Schluss machen, weil ich gerade weiterrennen muss. Schauen wir mal. Kann unser Caching Angabe beim Crawling von Googlebot ignoriert werden bzw. durch eigene Bewertungskriterien überstimmt werden, das heißt beurteilt Googlebot eigenständig ob und wie lange ein Resource gekashed werden soll. Ja. Wir caching ein bisschen anders als ein normaler Browser, weil Googlebot ist ja kein normaler Browser und kann Inhalte auch ein bisschen anders indexieren und quasi mit der gekaschten Version arbeiten. Das heißt, wir caching in der Regel ein bisschen länger als ein normaler Browser. Das heißt, die caching Angaben, die wir von euch kriegen, sind nicht immer so berücksichtigt. Was ich machen würde, wenn man jetzt zum Beispiel Embedded Inhalte verändert, wenn ich jetzt ein JavaScript Datei veränder oder CSS Datei oder Bilder dass man mit einem Tag an der URL arbeitet dass man zum Beispiel mit dem Fragezeichen und Version gleich so und so oder vielleicht mit der Datumsangabe von Veränderungsdatum entsprechend arbeitet. So dass wenn wir die Seite neu aufrufen sehen wir, dass dann neue Verweise sind auf neue URLs und die können wir dann neu holen und dann entsprechend neu auch caching. Noch eine Frage zum Thema Native Advertisement aus Google's Sichtlingen ist ganz klar zu lesen, dass Externe Links aus diesen Inhalten mit No Follow getkennzeichnet werden sollen besteht die Gefahr einer Abstrafung, wenn diese trotz Advertorial Kennzeichnung mit Follow Links auf Externe Links verweisen. Ja, kann sein. Das heißt, wenn wir erkennen können, dass da ein größeres Link Campaign gemacht wird und all diese Paid Posts oder Native Advertising oder wie sie entsprechend auch genannt werden und dann mit deinem Follow Link versehen sind, dann kann es sein, dass unsere Webspam Team das anschaut und sagt, da versucht jemand quasi mit bezahlter Werbung Links aufzubauen, die Page-Rank weitergebten und das ist aus unserer Sicht nicht okay und da kann es sein, dass sie dann auch entsprechend manuell eingreifen und sagen, da müssen wir irgendwie entsprechend manuell auch etwas machen, damit das keine Probleme verursacht in den Suchergebnissen. Okay. Das waren jetzt einige Fragen. Ich muss, wie gesagt, ein bisschen früher Schluss machen, aber wenn eine von euch noch eine letzte Frage hat, schauen wir schon, dass wir die noch hinkriegen können. Ja, okay. Ja, es ist nur eine Frage, ob es aktuell Probleme gibt. Und zwar, wir haben einen Moment rankt bei uns, ein einziger Seitentyp in Österreich rankt immer die DE-Version, seit ungefähr fünf Tagen ist es, obwohl alle anderen Seiten dasselbe H-Rank-Markup haben, auch technisch genau gleich sind. Ich wollte nur fragen, ob es da Datenproblemen gibt. Was manchmal passiert ist, dass wir denken, dass diese Seiten gleich sind und dass wir die entsprechend als eine Version indexiert haben. Und wenn die Seiten wirklich von Inhalt her 1 zu 1 identisch sind, dann würde ich auf so etwas tippen. An und für sich vom Ranking her sollte das keinen Einfluss haben, aber es ist natürlich dann die falsche Version, vielleicht der falsche Titel oder Description dabei. Das heißt, wenn das wirklich kritisch ist, dass sie getrennt werden sollten, würde ich schauen, dass wir auch die Inhalte ein bisschen unterschiedlich hart auf diesen Seiten. Okay. Dann Stefan, vielleicht noch ganz schnell. Ich würde es uns einfach um diesen Hängerort stellen. Okay. Dann vielen Dank fürs Kommen und richtig noch die nächsten Hangouts ein und dann sehen wir uns vielleicht dort nochmal. Okay. Tschüss allerseits. Tschüss.