 Okay, willkommen beim heutigen Google Webmaster Essentials-Sprechstunden-Hangout. Mein Name ist Johannes Müller, ich bin ein Webmaster Trends-Analyst hier bei Google in der Schweiz. Und Teil von dem, was wir machen, ist mit Webmaster und Publisher zu sprechen, wie jetzt hier im Hangout. Einige von euch haben schon Fragen eingereicht, die schauen wir auf jeden Fall mal an. Aber wenn einer von euch möchte, könnt ihr gerade loslegen und die ersten Fragen schon mal stellen. Alle erst noch still, okay. Wenn ihr zwischendurch Fragen habt zu den Fragen oder zu den Antworten, einfach nur losreden. Wir werden sicher auch ein bisschen Zeit haben für eure Fragen gegen Ende vom Hangout, weil sonst noch irgendwas aufkommt im Laufe vom Hangout. Okay, fangen wir mal an. Es hat das negative Auswirkungen auf die organischen Rankings, wenn Zeiten als nicht sicher in Chrome markiert werden. Vielleicht nur kurz zum Hintergrund. Nicht sicher ist eine Markierung, die in der neuen Version von Chrome gezeigt wird. Ich glaube Version 56, was gegen Ende Januar überall in der Standard-Version vorhanden sein wird. Und das wird gezeigt auf Seiten, die auf HTTP sind, die ein Formular oder ein Feld für ein Passwort oder eine Kreditkartennummer haben. Das heißt, wenn Chrome erkennen kann, dass da ein Passwort gefragt wird oder eine Kreditkartennummer eingegeben werden kann und das Ganze auf HTTP ist, so dass die Übertragung in dem Fall dann nicht wirklich verschlüsselt wäre, dann wird das so dargestellt oben neben der Adresse. Das heißt, wenn man das vermeiden möchte mit den eigenen Zeiten, würde ich einfach sicherstellen, dass man entweder diese Felder entfernt von diesen Seiten, wenn man zum Beispiel eine Loginfunktion hat, die aber eigentlich gar nicht braucht, dass man die von diesen Seiten entfernt oder dass man halt auf HTTPS wechselt, so dass die Übertragung dann entsprechend auch verschlüsselt ist. Ein Wechsel auf HTTPS macht meiner Meinung nach sowieso Sinn früher oder später. Von dem her ist das etwas, was man sowieso in Betracht ziehen könnte und das ist immer eine gute Sache. Bezüglich den negativen Auswirkungen, im Moment ist es so, dass wir das nur in Chrome teilen. Vorne vor der Adresse steht dann vielleicht nicht sicher. Das hat keinen Einfluss auf die organischen Suchergebnissen. Ich denke, das wird zumindest in der näheren Zukunft auch so bleiben. Wir haben einen kleinen Ranking-Boost für HTTPS-Seiten allgemein und da sieht man dann vielleicht eher den Unterschied. Wobei dieser Ranking-Boost für HTTPS-Seiten, der ist wirklich eher auf der kleinen Seite und nicht etwas momentan automatisch auf der ersten Seite der Suchergebnisse springt. Von dem her ist wahrscheinlich wird das so bleiben, dass zumindest mittelfristig auch das weiterhin nur in Chrome so dargestellt wird. Es ist ja auch so, dass die Seite an für sich nicht schlechter ist. Deswegen ist es einfach, dass wenn man Daten eingebt, muss man sich wirklich überlegen. Sind das wirklich Daten, die ich so übertragen möchte, unverschlüsselt über das Internet? Ab wann ungefähr können wir mit der Umstellung auf die Mobile First-Indexierung rechnen? Im Moment haben wir da kein Datum, welches wir angeben können. Wir sind mit dem Team noch dran, verschiedene Experimente auszuwerten. Im Moment sind das wirklich sehr, sehr kleine Experimente und wir möchten einfach sicherstellen, dass damit diesen Experimenten, die wir machen, das auf jeden Fall gut funktioniert, beziehungsweise wir möchten halt feststellen, was müssen wir auf unserer Seite ändern, was müssen wir in unseren Empfehlungen ändern, damit man da überhaupt weitergehen kann mit den Experimente und vielleicht ein bisschen größere Experimente machen und vielleicht mit ein Prozent der Websites, dass man das so Schritt für Schritt mal anschauen kann. Aber wir geben da auf jeden Fall Bescheid, wenn es ein bisschen näher ist, wenn wir unseren Empfehlungen ein bisschen ausgearbeitet haben, sodass ihr auch gezielt etwas machen könnt. Grundsätzlich ist es meiner Meinung nach am besten für uns, wenn wir nicht erwarten müssen, dass Websites große Änderungen machen müssen. Das heißt, wenn wir möglichst mit den gleichen Websites weiterarbeiten können, weil wir können ja auch nicht sicherstellen, dass alle Webmaster gleich umstellen, wenn es dann auch wirklich so weit ist. Und wir möchten auch nicht Webmaster immer quasi mal dahin schicken, mal dahin schicken, sondern es ist auch gut, wenn man mal Zeit hat, sich auf die eigene Website sonst zu konzentrieren. Ist es geplant, dass die Sicherheitsmeldungen Chrome auch auf Seiten ohne Login-Möglichkeit angezeigt werden? Ich weiß nicht, was die Pläne sind von der Chrome-Seite. Ich könnte mir schon vorstellen, dass sie irgendwann, vielleicht mal mittelfristig, längerfristig diese Warnung allgemeiner Fahrt-TP-Seiten darstellen würden. Ich weiß allerdings nicht, was da der Zeitplan ist oder wie diese nächsten Schritte quasi kommen können. Und von dem her kann ich da eigentlich keine Versprechungen machen. Ich weiß, in der Nachricht, die wir verschickt haben, haben wir auch erwähnt, dass es sein kann, dass wir da in diese Richtung auch weitergehen werden. Wenn man daran interessiert ist, wie sich das entwickelt, bezüglich Chrome, würde ich auf jeden Fall beim Chrome-Blog mich da vielleicht anmelden und wirklich sicherstellen, dass man all die Blog-Posts auch kriegt, dass man das dann auch sieht. Wenn das in Beta-Channel zum Beispiel vorhanden ist und dann kann man sich ja ungefähr ausrechnen, wann ist das etwa im Stable-Release auch dabei? Ähnlich haben wir das ja mit dieser Umstellung gemacht. Ich glaube, die wurde im Sommer irgendwann vom letzten Jahr zum ersten Mal erwähnt und entsprechend haben sie jetzt bis jetzt quasi daran gearbeitet, das so zu machen, dass es wirklich auch sauber funktioniert. Wir betreuen eine internationale Seite mit mehrsprachigen Content. Beim Aufruf der Domain wird vom Route-Verzeichnis auf das jeweilige Sprachverzeichnis mittels IP-Erkennung weitergeleitet. Man wird dann quasi auf DE-AT umgeleitet, wenn man merkt, also wenn der Server merkt, dass jemand aus Österreich auf Deutsch sucht. Warum erkennt das Google nicht? Das ist doch ganz offensichtlich. Die Schwierigkeit hier ist, dass Google für den größten Teil aus Amerika crawlt. Das heißt, die Googlebot IP-Adressen werden in der Regel als amerikanische IP-Adressen erkannt. Das heißt, Googlebot, wenn es die Website ansteuert, wird dann wahrscheinlich eher immer auf die Englischsprachigen Version weitergeleitet. Und so sieht es dann für uns aus, als ob die Homepage auf eine englische Homepage weiterleitet. Wir erkennen gar nicht, dass andere Benutzer vielleicht etwas anderes sehen würden. Und von dem her ist es so, dass wir für die Indexierung, nehmen wir halt an, ja, das wird auf diese Seite weitergeleitet, also nehmen wir diese Inhalte und zeigen, wie ihnen einen Sucher geben müssen. Und so ist es dann für sich normal, dass wir das so zeigen würden. Was man machen kann, ist, mit dem hreflang zu arbeiten, ich bin jetzt nicht sicher, dass es da auch erwähnt, dass ihr mit dem hreflang arbeitet, aber was man machen müsste in einem solchen Fall, ist nicht nur die einzelnen Sprachversionen markieren, sondern auch die Homepage und die Homepage als X-Default markieren. So dass wir wissen, in diesem Satz von Seiten gibt es einerseits die Homepage, die immer eine Weiterleitung macht und andererseits die verschiedenen Sprachversionen, also Deutsch für Österreich, Deutsch für Deutschland, vielleicht eine Englische noch dazu. Und so können wir innerhalb von diesem Satz dann die richtige Version darstellen. Und was dann auch passieren wird, ist wahrscheinlich, wenn jemand aus Deutschland sucht, dann wissen wir, die deutsche Version von dieser Homepage ist diese Seite und kann dann die Seite gezielten Suchergebnissen zeigen mit den eigenen Titel und Descriptionen im Snippet entsprechend auch. Das heißt, wichtig ist wirklich, dass man mit dem X-Default arbeitet. Wichtig ist auch, dass man sicherstellt in Search Console, dass die verschiedenen hreflang Versionen erkannt werden. Das wirklich auch klar ist, dass wir diesen Satz von Seiten sauber erkennen können. Wir haben eine Blogpost gemacht vor vielleicht einem Jahr über die richtige Version der Homepage für Google, wo ein bisschen auch auf diese X-Default-Varianten eingeht. Das würde ich auf jeden Fall mal aussuchen. Wenn du das nicht findest, lasst vielleicht ein Kommentar beim Posting hinten oder ping mich kurz auf Twitter und dann kann ich das für dich raussuchen und dir den Link dazuschicken. Die Art von Redirect, da ist eigentlich egal, ob das mit 301 oder 302 gemacht wird. 302 ist technisch gesehen richtiger und für uns auf der Google-Seite ist es eigentlich egal. Aber wichtig ist wirklich, dass man mit dem X-Default arbeitet, dass man die einzelnen Sprachversionen auch sauber markiert, dass man mit dem Canonical von diesen Versionen arbeitet und dass die hreflang Markierungen so angegeben sind, dass sie sauber gelesen werden können. Das heißt, dass sie wirklich klar im Head dabei sind. Ich hatte noch vier kurze konkrete Fragen zur Umstellung von HTTPS auf HTTPS. Vielleicht allgemein, wenn es so kurze Fragen sind, macht es meistens mehr Sinn, wenn man die einzelnen Kommentare hineingebt, dann sind die ein bisschen besser zu finden. Was muss ich in Google Analytics anpassen für eine solche Umstellung? Soweit ich weiß, muss man nicht spezielles in Google Analytics machen. Ich bin allerdings kein Analytics-Experte. Meines Wissens geht Analytics ja auf die Version, die der Benutzer gerade benutzt, im Browser. Und wenn man auf HTTPS wechselt, dann ist es ja immer noch die gleiche Website mit dem gleichen Tracking Code. Dann sollte es da eigentlich weiterhin funktionieren. Es kann sein, dass wenn man etwas Spezielles eingerichtet hat in Analytics eine irgendwelche Filter, dass man das vielleicht überprüfen müsste. Wenn jemand mehr Informationen zur Analytics-Umstellung hat, vielleicht auch mal einen kurzen Link schicken, dann kann ich das entsprechend weitergeben an die nächsten Fragen. Welche Anpassungen sind in der Search Console vorzunehmen? Muss ich einen Neu-Ural-Eintragen anlegen? Ja, ich würde auf jeden Fall in Search Console die HTTPS-Version auch verifizieren, sodass wir wissen, dass die beiden vorhanden sind, dass wir auch quasi in Meldungen direkt an die HTTPS-Version weiterschicken können, wenn wir etwas an die AdNAS verschicken müssen. Man muss keinen Side-Move-Einrichten in Search Console, das kann man für HTTPS-Umstellungen auch nicht machen. Die Sign-Up-Datei, wenn die auch weiterleitet und die neue Sign-Up-Datei auch ültig ist auf HTTPS, dann sollte das eigentlich unproblematisch sein. Versteht Google, dass die serverseitigen 301-Weiterleitungen kein relaunch sind, sondern lediglich eine Umstellung von HTTPS auf HTTPS sind. Die URLs bleiben ja unverändert. Wichtig ist vielleicht da zu sagen, dass die URLs doch anders sind. Das sind andere URLs. Wenn man ein Protokoll wechselt, dann ist es eine andere URL. Das heißt, aus unserer Sicht ist es nicht automatisch gegeben, dass nur weil der Pfad und der Hostname gleich sind, dass es die gleichen Inhalte sind, sondern wir müssen wirklich erkennen, dass es eine Verschiebung von dieser URL auf die andere URL ist, auch wenn der Rest an und für sich gleich aussieht. Für uns ist es auf jeden Fall einfacher, wenn sich sonst nichts ändert mit dem Rest der Website. Aber es ist trotzdem eine Situation, wo wir die einzelnen URLs neu crawlen müssen, den redirect sehen müssen und dann die neue Version sauber indexieren können. In der Regel geht das inzwischen recht schnell. Mit HTTPS-Umstellung haben wir inzwischen recht viel Erfahrung. Da würde ich jetzt nicht die gleichen Schwankungen erwarten, wie wenn ich jetzt die Website neu relaunche und alle URLs verändere, also die URL-Struktur innerhalb der Website oder wenn ich von einem Domain zu einem anderen wechsle, sondern mit HTTPS auf HTTPS geht das in der Regel sehr unproblematisch. Wenn ich eine One-Page-Website mit HTML und JavaScript habe und ich die Inhalte per Ajax-Nachlage dabei werden Fragments, also mit diesem Fundzeichen in Menü verwendet, und der URL steht dann hinten dran, auch jeweils ein Fragment mit dem Namen vom Inhalt, ist das ein Problem? Gibt es da Nachteile? Ja, das ist unterm Schänden problematisch. In der Regel indexieren wir die URLs ohne diesem Fragment. Das heißt, wenn du mit diesem Fragment über JavaScript Inhalte nachlädst, die nicht auf der Seite vorhanden sind sonst, dann kann es durchaus sein, dass wir die nicht für die Indexierung verwenden. Das heißt, ich würde da auf jeden Fall überlegen, wie könnte man eine andere URL-Struktur verwenden, die nicht mit dem Fragment zu arbeiten? Mit HTML5 kann man ja über die History-API auch recht gut arbeiten. Dort kann man normale URLs verwenden, die man auch über JavaScript ansteuert. Mit solchen URLs können wir die eigentlich normal indexieren. Wir können die Seiten dann renderen, das JavaScript ausführen und entsprechend die Inhalte dann auch wirklich so indexieren. Aber alles, was mit dem Fragment ist, in der Regel wird das auf unserer Seite ignoriert. Und da kann es durchaus sein, dass wir Inhalte von einer solchen Webseite verlieren und die nicht in der Suche darstellen können. Bugs in den Suchergebnissen kann es auch geben. Auch wir sind da nicht immun gegen Fehler in unseren Programmen. Wir haben jetzt mehrfach beobachtet, dass eine Seite, die mal in den Top 10 war, plötzlich nicht mehr auf der ersten Seite zu finden ist, klickt man dann auf Seite 2, findet man das Ergebnis dort nicht wieder. Bis dahin ist alles soweit normal. Wenn man dann jedoch zurück auf die erste Seite bleibt, findet man plötzlich die gesuchte Seite auf der Position 10 oder höher. Hier wäre es interessant zu wissen, wie solche Fälle zustande kommen und was man als Webmeister dann machen kann. Ich müsste da das irgendwie vielleicht nachstellen können. Wenn ich das irgendwie nachstellen kann, wenn du mir Beispiels Suchergebnisse schicken kannst, wo du das so siehst, dann kann ich das auf jeden Fall an das Team weiterleiten. Das klingt eher nach irgendeinem Fehler im UI und nicht nach etwas, was quasi in der Suche gezielt so gemacht wird. Und von dem her könnten da schon Bugs auf unserer Seite sein. Es kann auch einfach sein, dass die Webseite allgemein im Ranking her ein bisschen schwammt und dass sie mal auf der ersten Seite ist, mal auf der zweiten Seite und je nachdem, wie lange man wartet zwischen beiden Blättern, dann springt es mal auf die erste Seite, obwohl es eigentlich vorher auf der zweiten Seite war. In der Regel sind solche Schwankungen eher selten. Das heißt, so Schwankungen, die man quasi gleich live beim Suchen erlebt. Es ist eher normal, dass die Seiten dann einfach im Laufe der Zeit über mehrere Tage hinweg mal eine Position ein bisschen verringern. Aber wenn du mir das irgendwie Suchergebnisse schicken kannst, wo man das nachstellen kann, wo man das wirklich auch so sehen kann, dann wäre ich dir sehr dankbar und dann kann ich das sich auch an das Team mal hier weitergeben, damit wir schauen können, was funktioniert auf unserer Seite vielleicht nicht ganz optimal. Aber auf jeden Fall ist es nicht etwas, in der Suche so, sag ich mal gezielt, für das Ranking machen würden, um Benutzer zu verwehren, weil das würde ja nicht wirklich Sinn machen. Kann es vorkommen, dass man im Rahmen einer Umstellung auf HTTP, auf HTTPS mit Rankingverlusten konfrontiert wird oder darf dies eigentlich nicht sein, wenn man Grundlegendes beachtet? Theoretisch kann es schon sein, dass es zumindest Schwankungen gibt, wenn man bei einer solchen Umstellung macht, wie bei jeder Website-Umstellung. Die meisten Fälle, die ich neuerdings gesehen habe, mit Schwankungen, gerade bei einer solchen Umstellung, sind eher, allerdings, normale Schwankungen, die wir sowieso hätten, auch von der Website jetzt geblieben wäre auf HTTP. Es kann aber durchaus sein, dass es bei einer solchen Umstellung mit Schwankungen zustande kommen, ist nicht ganz ausgeschlossen. Ich denke, auf jeden Fall wird es so sein, dass man kurzfristig Schwankungen haben wird, vielleicht ein paar Tage. Wenn es länger als ein paar Tage ist, dann klingt das ein bisschen komisch. Dann wäre ich froh, wenn man mir vielleicht mal die Beispiel URL schicken könnte. Dann kann ich das hier auch mal anschauen und mit dem Team besprechen, ob das normal ist oder ob da vielleicht irgendetwas schiefgeht. Bezüglich Sidemap-Datei bei einer URL-Umstellung, in einem solchen Fall von HTTP auf HTTPS, macht es Sinn, dass man die alte Sidemap-Datei nochmals einreicht mit neuen Änderungsdaten der einzelnen URLs, sodass wir die alten URLs ein bisschen schneller neu crawlen. Das ist ein bisschen, sag ich mal, verwehrend oft, weil eigentlich mit einer Sidemap-Datei sollte man ja die URLs einreichen, die man effektiv indexiert haben möchte. Bei einer Umstellung hilft uns das aber, die effektiv indexierten URLs ein bisschen schneller zu finden und dann längerfristig kann man natürlich die alte Sidemap-Datei wieder rausnehmen. Ich möchte gerne wissen, was dazu führen kann, dass eine bestehende Radgeber-Website kontinuierlich über 3 oder 4 Jahre oder mehr hinweg massive Ansichtbarkeit eingüst. Da gibt es verschiedene Sachen, wo die gemacht worden sind. Das Löschen von Tiny Content, also so Tag-Seiten ist es nachteilig, wenn man jeden neuen Blog-Eintrag auf verschiedenen Social-Media-Sites quasi weiter verlinkt. Wie viel Einfluss hat die Wahl das Designs auf das Ranking, welche Faktoren bleiben möglicherweise übrig und was kann man da machen? Grundsätzlich ist es an und für sich, ah, du bist im Hangout, super. Du sagst 3,4 Jahre, nicht 3 bis 4 Jahre. Weil wenn es 3 bis 4 Jahre sind, würde ich sagen, das ist normal, dass sich das Ecosystem ein bisschen verschiebt im Laufe der Jahre, dass eine Website, die früher vielleicht sehr relevant war, vielleicht im Laufe der Jahre weniger relevant wäre, einfach weil sich alles ein bisschen verschiebt. Bei einem 3,4 Jahr ist das immer noch möglich, aber wahrscheinlich nicht so direkt nachvollziehbar. Bezüglich den einzelnen Punkten da, das Löschen von, sag ich mal, dünnen Content-Seiten, denke ich, macht auf jeden Fall Sinn, weil dann können Suchmaschinen sich eher auf die wirklich relevanten Inhalte haben. Ich denke, das macht auf jeden Fall Sinn, gerade wenn ich jetzt mal annehme der Ratgeber-Website, dass da vielleicht viel user-generated Content dabei ist, gerade mit user-generated Content kann man natürlich sehr schnell viele URLs generieren, die nicht so viel wertvollen Inhalte haben. Dass man da das ein bisschen konzentriert auf die Seiten, das hilft auf jeden Fall unseren Algorithmen besser, sich auf die Sachen zu konzentrieren, die wirklich für euch auch wichtig sind. Bezüglich das Teilen von Inhalten auf Social-Media, aus unserer Sicht ändert das an und für sich nichts, weil diese Links in der Regel no follow haben. Bezüglich eine Website insgesamt, macht das wahrscheinlich schon Sinn. Wenn da Benutzer sind, die diese Links sehen, wenn die Website kommen, dann sind es ja Traffic-Quellen, die mehr in eurer Kontrolle sind und das macht auf jeden Fall Sinn. Wenn hingegen niemand auf diesen einzelnen Social-Media-Channels vorhanden ist, der da wirklich auf die Links geht, dann zumindest von der Webmaster-Seite her, denke ich, macht das wahrscheinlich weniger, dass man sich da die Mühe macht, weil wenn niemand auf diese Links geht, wenn wir einen no follow haben, dann kommt ja kein zusätzlicher Verkehr über diese Links hinein. Aber in der Regel, wenn Benutzer da sind, die diese Inhalte schätzen, die zu eurer Website kommen, dann würde ich das weiterhin so machen. Wie viel Einfluss kann die Wahl des Designs auf das Ranking haben? Das Design hat in den meisten Fällen kein oder wenig Einfluss auf das Ranking, zumindest nicht direkt, weil wie kann man das am besten sagen? Zumindest eine Möglichkeit besteht natürlich beim Design, dass wir die interne Verlinkung zum Beispiel besser erkennen können, dass wir besser erkennen können, welche Inhalte wirklich relevant sind für die einzelnen Seiten. Von dem her kann Design schon ein Einfluss haben, aber es ist nicht so, dass wir erkennen können, dass es jetzt ein schönes Design oder ein weniger schönes Design oder ein altes Design, neues modernes Design, das erkennen wir nicht, sondern wir kennen einfach, was da vorhanden ist auf diesen Seiten, welche Inhalte, wie wir diese Inhalte hinauslesen können, wie die Website intern verlinkt ist. Von dem her ist es nicht so, dass quasi das Aussehen vom Design für uns in erster Linie relevant ist. Zumindest ist das nicht etwas, was wir direkt sehen würden. Wir sehen aber manchmal, dass das indirekt ein Einfluss hat. Das heißt, wenn Benutzer auf eure Website kommen und die denken, diese Website ist nicht mehr so relevant, das ist aus dem letzten Jahrhundert irgendwie sieht das aus, dann sehen wir halt auch oft, dass Benutzer nicht mehr auf diese Websites verlinken und dann indirekt können wir das natürlich schon auch in den Suchergebnissen so berücksichtigen. Aber es ist nicht so, dass unsere Algorithmen gezielt das Design untersuchen und sagen, dass es jetzt modern oder schön ist und dass sie das irgendwie bewerten. Sondern wir konzentrieren uns einfach auf die interne Verlinkung, auf die Art wie diese Inhalte dargestellt werden. Da hat das Design kleinen Einfluss, aber nicht wirklich im Großen. Welche Faktoren bleiben möglicherweise übrig, die die komplette Zeit Domain betreffen können? Es ist schwierig zu sagen, ich denke gerade bei so einer kontinuierlichen Veränderung sind das wahrscheinlich Sachen, die einfach kontinuierlich sich ein bisschen aufsameln. Und Sachen, das sind dann vielleicht kleine Sachen, die im Laufe der Zeit von unseren Algorithmen, wo wir einfach es geführen, ja, das ist vielleicht doch nicht mehr so die beste Seite zu diesem Themen, dass es einfach quasi Schritt für Schritt sich ein bisschen verändert. Und ähnlich wie am Anfang erwähnt, kann es einfach auch sein, dass sich das ganze verändert hat, indem das Benutzer vielleicht anders suchen, dass Benutzer vielleicht andere Sachen selber schätzen, dass Benutzer in dem entsprechend dann auch indirekt weniger auf solche Websites empfehlen. Und da ist es wahrscheinlich also ich kenne jetzt die Webseiten nicht eher so, dass es keinen technischen Grund gibt, sondern dass man einfach über die Benutzer quasi indirekt vielleicht nicht mehr so optimal platziert ist. Und was man da eher machen könnte, ist vielleicht mit Benutzern AB-Tests machen, dass man auch wirklich ein Usergroup vielleicht erstellt und dann einzelne Designvarianten oder Strukturvarianten mal durchgeht und überlegt, wie kann ich meine Webseite so gestalten, dass Benutzer da richtig reagieren? Oder worauf reagieren vielleicht Benutzer nicht mehr so relativ im Moment? Und wie kann ich sich erstellen, dass meine Webseite, meine Inhalte weiterhin in der Zukunft auch relevant sein wird? Und manchmal kommt man auch aus solchen Gesprächen heraus und denkt, ja, vielleicht ist das, was ich jetzt zehn Jahre so gemacht habe, doch nicht mehr relevant in der heutigen Zeit und ich muss mir etwas ganz anderes überlegen. Vielleicht kommt man dabei heraus und denkt, ah, das sind Sachen, die ich total vergessen habe, und habe das eigentlich irgendwie verdrängt und vernachlässig, dass man daran arbeiten kann. Aber das ist dann eher etwas, wo, wenn es keine technischen Gründe gibt, muss man wirklich mit den Benutzern schauen und überlegen, wie kann man sicherstellen, dass das weiterhin eine relevante Destination bleibt? Ich würde gerne wissen, was man bei mehrsprachigen internationalen Websites achten muss. Wir haben da diverse Posts darüber gemacht. Auch im Hilfezentrum ist eigentlich recht viel Informationen dazu und ich glaube, irgendjemand hat auch zu einem der früheren Hangouts mal verlinkt, wo ich eine ganze Präsentation mal gemacht habe über das Thema. Ich denke, da gibt es viel zu tun. Das sind viele interessanten Bereiche, an denen man arbeiten kann bei internationalen und mehrsprachigen Websites. Da gibt es sehr viel Detailarbeit, wo man wirklich dann genau arbeiten muss. Von dem her finde ich das ein total spannendes Thema, aber nicht etwas, wo man in 5 Minuten schnell alles erfassen kann und dann genau weiß, was man machen muss. Sondern da lohnt es sich wirklich, sich sauber einzuarbeiten, dass man die Details ein bisschen auch besser kennt. Ja, da sind die verschiedenen Links. Gott schau, wir betreiben ein Portal, auf dem wir Produkte- und Dienstleistung stationärer regionaler Händler aggregieren, ca. 14.000 Seiten über 6 separate Site Maps zur Indexierung in Search Console sind jedoch nur 30% der URLs indexiert. Was kann man da machen? Mit Subdomains arbeiten oder die Priorität anpassen in Rich Card zu arbeiten. Ich denke, grundsätzlich ist es mal wichtig zu wissen, dass wir nicht garantieren, dass wir alle Seiten einer Website indexieren. Und für uns ist wirklich wichtig, dass die einzelnen Seiten einer Website wirklich auch von der Qualität her hochwertig sind, dass sie auch einzigartig sind, dass es sich wirklich für uns lohnt, unsere Systeme darauf zu konzentrieren und zu sagen, wir indexieren diese Seiten, weil das wirklich etwas ist, was im Internet bisher gefehlt hat. Wenn man hingegen jetzt nur Inhalte von bestehenden Websites weiter aggregiert, ich weiß jetzt nicht, ob das in dem Fall wirklich die Situation ist, aber wenn man jetzt nur bestehende Sachen aggregiert und zusammenfasst mit vielleicht eine leicht angepassten Variante, dann ist das für unsere Systeme nicht unbedingt etwas, wo wir sagen würden, dass sich jetzt wirklich 100.000 von Seiten neu zu indexieren und die in den Suchergebnissen darzustellen, weil diese Informationen haben wir eigentlich schon. Von dem her würde ich an erster Stelle wirklich sicherstellen, dass diese Seiten, die ihr da einreicht, wirklich auch relevant sind, dass die Seiten sind mit Inhalten, die es so vorher jetzt nicht im Internet gibt, dass man wirklich auch sicher ist, dass Benutzer suchen, nicht dass bestehende Inhalte neu angepasst werden und man die so indexieren möchte, weil das ist für beide Seiten anfühlt sich mit Zeitverschwendung. Bezüglich der Sitemap-Datei, wichtig ist für uns vor allem die URL und das Änderungsdatum. Die anderen beiden Felder, die Priorität, sowie die Aktualisierungs-Häufigkeit, die Change-Frequency, sind auf unserer Seite eher ignoriert über die Suche. Das heißt, wir möchten einfach sicherstellen, dass wir neue URLs, geänderte URLs, möglichst schnell finden können. Die Priorität lasst mir weg, weil wir gemerkt haben, dass die eigentlich nicht so hilfreich ist beim Erkennen von neuen und geänderten Seiten und die Änderungsfrequenz ist ja sowieso beim Änderungsdatum mit dabei. Von dem her haben die beiden Felder anfühlt sich weglassen. Wichtig ist wirklich Änderungsdatum und URL. Wichtig ist auch, dass die URL übereinstimmt, mit der die Seite anfühlt sich auch indexiert wird. Das heißt, wenn man mit Canonical arbeitet, wenn man mit Redirects arbeitet, dass man wirklich die saubere, quasi indexierbare URL angibt in der Sitemap-Datei, weil wir eine leicht andere Variante schon indexiert haben, dann zählt das im Sitemapsreport und wird dann indexiert. Aufteilungen Subdomains ändern dafür sich nichts. Bezüglich Rich Cards an und für sich sind das Sachen, die dann nach der Indexierung passieren. Das heißt, die Information über Verfügbarkeit und Preis in den Rich Cards, das ist etwas, was erst dann passiert, wenn wir die Seiten effektiv indexiert haben. Von dem her würde ich mich jetzt ein bisschen konzentrieren. Ich würde auch sicherstellen, dass wir wirklich erkennen können, dass diese Website, dass es sich lohnt, den Rest zu indexieren. Dass man da wirklich auch daran arbeitet, dass das Ganze, was man da anbietet, wirklich auch für den Benutzer Sinn macht, dass wir erkennen können, das ist etwas, was wir vollständig indexieren müssen, weil wir sonst Informationen einfach nicht haben, die Benutzer suchen. Wir schauen kurz in den Chat. Wir werden Accordions und Tabs bewertet. Nicht sichtbar bei Inhalt ranked oder ranked nicht. Bezüglich Accordions und Tabs, wenn das Informationen sind, die nicht sichtbar sind, wenn wir die Seite laden, dann ist es so, dass wir in den Desktop Suchergebnissen, die eher als weniger wichtig einschätzen. Das heißt, wir indexieren die Inhalte. Wenn jemand gezielt danach sucht, dann haben wir die, aber es ist für uns nicht ein Teil von Hauptinhalt von dieser Seite. Das heißt, es kann sein, dass es weniger stark ranked, dass es vielleicht im Snippet nicht verwendet wird, solche Sachen. Beim Mobile First Index wird das wahrscheinlich geändert, weil wir einfach wissen, dass gerade auf mobilen Websites kann man natürlich nicht alles auf Anhieb sichtbar machen. Man muss manchmal mit solchen Methoden wirklich gute Websites machen. Ein Kunde betreibt eine große Website mit 100.000 URLs im Index. Die mobile Variante befindet sich im Verzeichnis mobil und dann entsprechend auch so verlinkt. Die mobile Variante läuft aus Single-Page-App mit AngularJS und beinhaltet nur ein Bruchteil der Information der Desktop-Variante. Keine Titel-Descriptions, Markup, hreflane usw. Wie sollen wir damit umgehen mit dem Mobile First Index? Ja, gerade bei der Umstellung auf Mobile First würde ich da wirklich schauen, dass die ganzen Metadaten auch auf der mobilen Seite vorhanden sind. Das heißt, insbesondere Titel-Descriptions, wenn man anderen Markup-Hards, Structured-Data würde ich auf jeden Fall auf der mobilen Version auch verwenden, auch hreflane, dass es sauber verlinkt ist, dass wirklich diese ganzen Informationen auch auf der mobilen Version sind. Ob das mit Single-Page-App gemacht wird oder mit einer normalen statischen Website ist an und für sich euch überlassen. Ich würde einfach sicherstellen, dass Googlebot die Seiten sauber renderen kann. Das heißt, In Search Console mit Fetch as Render die mobilen Version auch mal prüfen und wirklich sicherstellen, dass da die Inhalte zumindest geladen werden, dass es sauber sichtbar ist für den Benutzer, nicht, dass es einfach eine leere Seite ist. Wir haben gesehen, dass zum Beispiel manche Single-Page-Apps mit Angular verwenden Service-Workers und die erwarten, dass die Service-Worker funktionieren und Googlebot verwenden zum Beispiel kein Service-Worker. Und da ist es einfach wirklich wichtig, dass man, sag ich mal, ein Failsafe hat, sodass, wenn gewisse JavaScript-APIs nicht vorhanden sind, dass es dann geladen wird, nicht, dass JavaScript dann abricht und sagt, oh, jetzt weiß ich nicht, was ich machen soll und der Rest wird dann nicht mehr geladen. Folgende Änderung habe ich Oktober 2016 vorgenommen. Unsere Website haben wir Part 2.TPS umgestellt, eine mobile Version eingerichtet auf dem mobilen Subdomain. Welche Anpassungen muss ich in Search Console vornehmen? Wichtig ist, dass die verschiedenen Versionen einfach registriert werden in Search Console, dass die verifiziert sind, die mobile Version, die HTTPS Version, sodass wir wirklich auch sauber die Daten darstellen können in Search Console. Für die mobile Version haben wir noch ein Sitemap eingereicht. Die Ansa-Seiten mit strukturierten Daten ist eher gering. Ja, jetzt kommt da noch alles zusammen. Bezüglich der Indexierung und den Informationen da. Ich würde, wenn man jetzt in Search Console das anschaut, die Daten, würde ich mich auf die Canonical Version konzentrieren. Das heißt, das wird ja dann die desktop HTTPS Version sein und nicht bei der mobilen Version nachschauen, weil die mobile Version ist ja eigentlich vom Prinzip her Canonical. Das sollte ja auch der Canonical Tag auf die Desktop Version verweisen, sodass wir die Desktop Version sauber indexieren können und dementsprechend werden eigentlich die meisten Daten bei der Desktop Version vorhanden sein. Ich denke gerade bei einer Website Umstellung kann es natürlich sein, dass, kurzfristig, mittelfristig bei der mobilen Version auch Daten vorhanden sind, aber längerfristig sollte das alles auf der Desktop Version vorhanden sein in Search Console. Bezüglich den Keyword Not Provided, nämlich an, ist das in Analytics. Das ist anführlich normal. Das ist mit der Umstellung der Suche auf HTTPS werden diese Suchkeywords nicht mehr an Analytics weitergegeben. Man sieht sie dann nur noch in Search Console bei den Search Analytics-Angaben. Wir hatten den Fall bzw. der Fall von Properties in Search Console. Ich habe einen Kunden mit einer IP-Adresse für ein Web-House. Auf dem Web-House liegen 3 TLDs und eine Geoabfrage. Und die werden dann quasi weitergeleitet. Und dann für jedes Land gibt es eigene Properties. In Analytics sind Filter vorhanden. Wie lege ich das in Search Console an? Alle TLDs haben die gleiche IP-Adresse. Aus unserer Sicht ist die IP-Adresse irrelevant, wenn das unterschiedliche Länder TLDs sind, dann kann man die einfach so in Search Console eintragen, dann muss man keine weiteren Einstellungen vornehmen. Dann kann man ja auch die Länder zuordnen nicht angeben. Wenn das generische Top-Level-Domain sind, zum Beispiel .com, .net oder auch .eu, ist aus unserer Sicht ein generischer Top-Level-Domain, dann kann man die Länderzugehörigkeit in Search Console angeben für das Geotargeting. Wenn das aber schon Länder-Country Codes sind, dann ist das aus unserer Sicht alles okay. Und eben wie gesagt, IP-Adresse würde ich mir da überhaupt keine Sorgen machen. Manche Websites verwenden eigene IP-Adresse. Manche sind auf ein Content Delivery Network und da hat man nie eine Ahnung, welche IP-Adresse da verwendet wird. Und das sollte aus unserer Sicht alles funktionieren. Ah, noch eine Frage. Mir fällt letzter Zeit auf, dass Google die vorhandenen Pixel-Dreite in den Suchergebnissen nicht ausnutzt. Und hierbei ist es nicht wichtig, welcher Content für den Snippet verwendet wird. Das heißt, manchmal wird das ausgefüllt, manchmal nicht. Warum ist das so? Ich denke, das ist einfach vom UI her in den Suchergebnissen. Also nicht unbedingt etwas, was der Sucher selber in den Suchergebnissen, sondern einfach weil wir merken, manchmal kann man mehr darstellen im Snippet, manchmal kann man weniger darstellen im Snippet und dann wird das so an und für sich algorithmisch angepasst. Ich würde gerne, wenn noch etwas Zeit ist, nochmal auch die Ranking-Verluste eingehen und kurz zur Erklärung der Situation. Ich habe also über mehrere Jahre hin diese Ratgeber-Webseite aufgebaut und mich dabei sehr genau an die Guidelines gehalten, die Webmaster reden, die Google herausgegeben hat und war auch sehr erfolgreich. Und irgendwann kam die Wende, ohne dass ich an dieser Strategie etwas geändert habe und ich Stochere seit einem Dreivierteljahr im Trüben und weiß nicht was möglicherweise ich falsch gemacht haben könnte ohne dass es mir bewusst war. Ich habe halt dann, weil ich diese Accordions hatte, ich erst das erziehen im Verdacht und ich habe alles, ganz viele verschiedene Dinge ausprobiert. Es ist aber immer weiter nach unten gegangen und halt nicht an den bekannten Termin, sondern kontinuierlich. Und ich suche tatsächlich nach diesem globalen Ding was ich übersehe, meinen blinden Fleck den ich übersehe. Kannst du vielleicht den Link beim Chat reinschreiben? Da kann ich mal kurz nachschauen, weil ich habe mir noch ein bisschen Zeit normalerweise ist es schwierig da einzelne Websites direkt anzuschauen weil das einfach ausgrund einer Zeit nicht so gut klappt. Manchmal findet man auch nicht auf Anhieb etwas, was ich da machen kann. Aber ich schaue mir das vielleicht mal kurz an. Vielleicht spricht da irgendwie grad irgendwas ins Auge von unserem Tool meistens ist es aber so, dass grad wenn das jetzt so kontinuierliche Veränderungen sind, dann ist es sehr schwierig festzustellen was das sein könnte. Was ich normalerweise mache, nur vom Ablauf her oder was ich empfehle für Webmaster ist, dass man sich ein Zeitrahmen vor der Veränderung, ein Zeitrahmen nach der Veränderung genauer anschaut und dann vielleicht auch schaut welche Arten von Suchanfragen sind da gekommen, welche Arten von Zeiten haben damals oder waren damals im Ranking sichtbar und so kann man da manchmal irgendwelche Muster herausholen beziehungsweise vielleicht sieht man, dass einzelne Arten von Zeiten technisch jetzt nicht mehr vorhanden sind oder no index haben oder dass sie einfach vielleicht jetzt nicht mehr so relevant sind in den Suchergebnissen oder vielleicht, dass man merkt, dass man früher für eher allgemeinere Suchergebnissen in den Ranking sichtbar war, als eigentlich für eine solche Website normal wäre. Aber das ist natürlich schwierig zu machen, wenn das im Laufe von, ich weiß nicht, einem Jahr oder so ist da sieht man das nicht wirklich auf Anlieb. Hast du das so mal angeschaut von den Suchergebnissen her? Hast du da vielleicht noch Daten von früher, wo man das ein bisschen vergleichen könnte? Nein, habe ich nicht. Okay. Was man da vielleicht machen kann, ist, dass man zumindest, aufgrund von den Serverlogs, das auch mal anschauen kann und dass man sich überlegt, welche Arten von URLs haben damals Verkehr aus der Suche gekriegt und dass man das vielleicht so ein bisschen überlegen könnte, was hat sich da verändert in der Suche, was hat sich vielleicht bei den Benutzern verändert oder auf meiner Webseite verändert, sind das noch die gleichen Arten von Zeiten, die quasi Vergebnissen vorhanden sind? Auffällige Änderungen habe ich da nicht gefunden. Ich sehe da auf Anlieb jetzt nicht wirklich etwas, was ich da groß hervorheben könnte. Ach Gott, schau, da ist natürlich schwierig zu sehen, was jetzt im Laufe von ja, sich alles verändert hat. Und gerade wenn das eher kontinuierliche Veränderungen sind, dann wird das noch schwieriger sein, da irgendetwas gezieltes zu finden. Soweit ich hier erkennen kann, vom Crawling und vom Indexing her, sieht das soweit anfühlt sich normal aus. Wir können da relativ gut die Inhalte crawlen, die sind relativ gut indexiert. Von dem her würde ich da eher auf entweder ein allgemeines Qualitätsproblem vielleicht tippen. Das heißt, dass man vielleicht mit der Website von der Qualität her einfach nicht ganz mitgehalten hat mit allen anderen, die jetzt für solche Suchbegriffe in den Suchergebnissen erscheinen. Oder einfach vom Benutzerverhalten her, dass Benutzer vielleicht allgemein weniger so suchen, wie sie früher gesucht haben. Aber das ist jetzt schwierig so für mich, sag ich mal, auf Anhieb zu sagen. Eine Sache, die ich sehe, ist, dass wir vom Crawling her eher am Limiten sind. Das heißt, dass wir nicht viel mehr crawlen können. Ich vermute, das hängt ein bisschen damit zusammen, dass wir ein bisschen mehr Zeit brauchen, um die Website zu crawlen. Das heißt, wir sehen da oft um die 500 bis 1000 Millisekunden pro URL, bis wir die Inhalte effektiv haben. Wenn die Website sich schnell verändert, wenn schnell Inhalte dazu kommen oder verschwinden, wenn das z.B. ein eher richtigen Nachrichten Website geht, dann wäre das vielleicht etwas, was man mal adressieren könnte. Wenn die Website in der Regel eher statisch bleibt, das heißt, wenn wir die einzelnen Seiten nicht täglich crawlen, dass das nicht so problematisch ist, dann ist das vielleicht weniger relevant. Aber so auf Anhieb sehe ich da jetzt nichts, was was ich da wirklich hervorheben könnte. Leider. Beziehungsweise zumindest ist es dann auch nicht etwas, was man wirklich verpasst hat. Ich sehe, ihr habt irgendwann auf HPTV umgestellt? Ja. Das war jetzt im Ende Dezember habe ich den umgeschaltet. Also vor dem Wintergrund, dass ich sowieso nicht gerengt werde, habe ich gedacht, dann könnte ich das doch gleich mal machen. Dann hat man wenigstens das erledigt. Und von der URL-Struktur sind das die gleichen noch oder hat sich das auch ein bisschen verändert? Das habe ich auch zwischenzeitlich geändert, weil ich hatte eine flache URL-Struktur und hatte den Verdacht gehabt, dass thematisch unterschiedliche Seiten die zusammengehören vielleicht sinnvollerweise in einem Directory zusammengefasst werden sollte. Hat aber kein Unterschied gebracht. Ich sehe auch, die alten URLs werden weitergeleitet, von dem her sollte das eigentlich soweit so klappen. Wenn du einen Link vielleicht zu deinem Forum-Thread noch hängen könntest, dann kann ich schauen, ob ich dann später vielleicht noch ein bisschen Zeit herum ein bisschen genauer reinzuschauen und vielleicht noch ein oder anderen Kommentar dazu hinterlassen. Aber ich vermute, es ist schwierig, weil wenn es etwas ist, was wirklich so im Laufe vom Jahr sich kontinuierlich verändert hat, dann wird es nicht so die eine Zeile im HTML sein, die man verändern muss, sondern es ist eher etwas Allgemeineres, wo man dann ein bisschen, vielleicht mit Benutzern wirklich auch mal überlegen muss, wie kann ich da ein Benutzergruppe mal zusammenstellen und wirklich mal gezielt einzelne Abläufe und dann halt der Webseite durchgehen und man schauen, macht das Sinn, mache ich da irgendetwas grundlegend falsch, passt das mit dem überein, was man sonst zum Internet findet zu diesen Themen oder ob man da vielleicht andere Anpassungen noch machen müsste. Aber ich schaue mir das mal nachher noch ein bisschen an. Ja, gute Frage. Ich hätte auch mal eine Frage, ich weiß nicht, hat man mich? Ja, und zwar auf jeder Seite Containers, die auf jeder Seite gleich sind. Der Futter ist seitbar, macht es dann Sinn, diese Container auf NoIndex und NoFollow zu setzen, sodass quasi der Googlebot eher den relevanten Links, die im Inhalt stehen folgt und nicht versehentlich anderen Verlinkungen, die weiter unten stehen im Futter oder in der Seitbar. Das ändert allen für sich nichts. Das heißt, wir erkennen da automatisch, dass das ein Teil von Boilerplate ist. Wir nennen das Boilerplate, das ist etwas, was einfach dupliziert ist über die Website auf verschiedenen Seiten und wir sehen, dass dann automatisch als nicht Hauptinhalt an. Das heißt, man muss da nicht mit NoFollow arbeiten, mit NoIndex kann man ja sowieso nicht mehr, das ist ja ein Bereich der Website. Man kann ja dann nicht sagen, dieser Bereich oder diese Diff oder Table quasi auf NoIndex setzen. Und von dem her würde ich das einfach so lassen, wie das auf der Website kommt. Das ist für uns okay. Okay, dann hätte ich ergänzt noch eine Frage. Wir haben einen Kunden, die machen Handy Reparatur Service und jetzt sollen wir quasi für jeden Gerätetyp, den wir reparieren weiter machen, oder die Schäden aufgeführt werden. Jetzt geht es darum, die Schäden sind eigentlich immer gleich beschrieben, aber es gibt natürlich für jeden, ich sag mal Gerätebesitzer, der jetzt Marke Modell und dann die Reparatur sucht, diese eine Seite, wo eben alle Fragen beantwortet werden und die Dienstleistung angeboten werden. Muss man da Angst haben von Duplicate Content Penalties? Duplicate Content wahrscheinlich nicht, aber es könnte sein, dass vom Web Spam Team, dass sie das anschauen und denken, das sind Doorway Pages. Das heißt, wenn die Seiten an und für sich keinen eigenen Wert haben, dann generiert ihr all diese Seitenvarianten. Wir crawl und indexieren die und denken dann an und für sich, ja, die sind vielleicht auch nicht so relevant. Das heißt, was ich da vielleicht eher machen würde, ist vielleicht verschiedene Gerätetypen zusammen passen, auf einer Seite nehmen, so dass man wirklich eine gezielte Seite hat für diese Art von Gerät und dass man da wirklich auch eine stärkere Seite hat, die den Suchergebnissen eher relevant ist, im Vergleich zu mal diesen verschiedenen Hunderten oder Tausend Varianten, die dann wirklich nur die Produkte nochmal ein bisschen anders haben. Okay, vielen Dank, weil das spart uns ja auch eine Menge Arbeit bei der Stellung der Seiten. Okay, weitere Fragen wenn noch irgendwas ist. Ansonsten könnt ihr natürlich weiterhin auch im Hilferforum posten und ich setze auf jeden Fall die nächsten Hangouts noch auf und dann sehen wir uns vielleicht in einem der zukünftigen Hangouts wieder. Okay. Dann hätte ich noch einmal ganz kurz was. Es wird ja immer wieder gesagt man könnte Fragen direkt stellen vielleicht mal die URL auch für das Hilferforum, dass es das richtige Hilferforum ist. Das ist direkt da im Chat. Peter hat jetzt da auch hin verlinkt. Also normalerweise wenn man ein Wetmaster Hilferforum sucht, dann kommt das direkt. Okay, alles klar, danke. Ob er wirklich da auch, ja genau. Nicht, dass unser eigenes Forum nicht rankt. Ja. Okay. Okay, gut. Dann wünsche ich euch noch einen schönen Nachmittag und dann sehen wir uns vielleicht in einem der nächsten Hangouts wieder. Tschüss allerseits.