 Okay, willkommen allerseits zum heutigen Google 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 Webmaster Hangouts, wo ihr Fragen einreichen könnt zu beliebigen Webmasters sucheähnlichen Themen und wir versuchen da Antworten herauszufinden. Wie immer sind ja schon einige Fragen eingereicht worden über die Google Plus Seite. Wenn einer von euch loslegen möchte und die ersten Fragen schon in Personen stellen möchte, könnt ihr auch das gerne jetzt schon machen. Ansonsten fangen wir einfach mit den Fragen mal an. Und wenn ihr zwischen euch Kommentare oder weitergehende Fragen zu einzelnen Themen habt, einfach nur loslegen oder auch auf dem Google Plus Droid weitere Kommentare hineinnehmen. Okay, wo fangen wir da an? Sollte Start Kategorie oder Produktdetail Seite am häufigsten gecrawled werden. Inwiefern können wir beeinflussen beziehungsweise die Crawl Priorität setzen? Schwierig zu sagen. Wir versuchen, das Crawling von einzelnen Seiten automatisch anzupassen aufgrund von verschiedenen Kriterien. Einerseits versuchen wir festzustellen, welche Seiten sich am häufigsten verändern, damit wir wirklich auch sicher sind, dass wir diese Veränderungen möglichst schnell aufnehmen können und möglichst schnell im Index aufnehmen können. Andererseits versuchen wir festzustellen, welche Seiten am wichtigsten sind für eine Webseite, damit wir auch sicher sind, dass Inhalte, die da kurzfristig erscheinen, dass wir die auch recht schnell indexieren können. Das sind so grundlegend mal die zwei Varianten, wie wir das versuchen festzustellen. Und von dem her kann es natürlich sein, dass je nachdem ein von diesen Art von Seiten dann häufiger gecrawled wird oder nicht, Normalerweise ist es so, dass wir eher die Homepage einer Webseite und die Kategorienseiten, dass wir solche Seiten eher häufiger crawlen, weil da sind in der Regel, werden die neuen Inhalte schnell dort veröffentlicht. Wir finden die Links zu den einzelnen Detailseiten von dort aus relativ schnell und können dann nachher auch die Detailseiten holen. hingegen die Produktdetailseiten, die verändern sich ja in der Regel nicht so schnell. Das heißt, wenn ein Produkt einmal aufgenommen ist mit einem gewissen Preis im System, dann ist es ja nicht so, dass wir täglich da neue Änderungen haben an diesen Produktseiten. Es kommen vielleicht Bewertungen dazu, vielleicht verändert sich der Preis ab und zu, aber es ist nicht so, dass wir wirklich unsere Hauptzeit vom crawlen her auf solche Detailseiten konzentrieren müssen. Zumindest nicht bei den meisten Websites. Es kann natürlich sein, dass irgendetwas auf eurer Webseite ein bisschen speziell ist, dass die Detailseiten doch die wichtigsten Seiten sind, oder dass auf gewissen Detailseiten da die Veränderungen sehr schnell kommen und dass wir das irgendwie merken können und dass wir dann diese Detailseiten am häufigsten crawlen. Ähnlich ist es ja zum Beispiel auch, wenn man eine Side-Abfrage macht für eine Webseite, dann bringen wir in der Regel die Homepage an erster Stelle, es kann auch sein, dass wir einen von den Catering-Seiten vielleicht an erster Stelle nehmen oder dass wir einen von den Detailseiten an erster Stelle nehmen. Auch das ist eigentlich ganz normal. Das hängt ein bisschen davon ab, wie wir versuchen festzustellen, was sind halt die wichtigsten Seiten auf einer Webseite. Die Reihenfolge in der Side-Abfrage hat eigentlich mit dem Crawl nichts. Direkt zu tun, aber es geht ein bisschen ähnlich in die gleiche Richtung. Bezüglich wie man das beeinflussen kann oder wie man da Prioritäten setzen kann, am einfachsten für uns ist einfach eine saubere Side-Struktur, dass wenn wir die Webseite crawlen, dass wir da möglichst schnell feststellen können, was sind jetzt die wichtigsten Seiten innerhalb von dieser Webseite. Das heißt, die interne Verlinkung in erster Linie. Das heißt, so sehen wir sehr schnell, wo die Startseiten sind, wo die Hauptkategorien sind und können da ein bisschen weiter gehen. Was uns auch hilft, bezüglich der Erkennung von Änderungen, ist zum Beispiel in einer Side-Map-Partei, dass man da das Änderungsdatum von den einzelnen Seiten angebt. Okay, wir haben viele Fahrzeugprodukt-Dekal-Seiten. Welche Headlines sollte man da am besten verwenden? Entweder mit mehr Information oder weniger Information. Für uns, zumindest auf der Such-Seite, ist das eher etwas, was euch überlassen ist. Das heißt, ihr könnt schauen, was für euch am besten Sinn macht für eine Seite das Titel, andererseits für die einzelnen Überschriften auf der Seite. Und wir versuchen das dementsprechend weiter zu verwenden. Wir nehmen solche Überschriften eher zum Erkennen, worum handelt es auf dieser Seite. Und wenn da Überschriften dabei sind, die aussagekräftig sind, dann helfen die uns. Wenn die Überschriften weniger aussagekräftig sind, dann helfen die uns ein bisschen weniger. Und von dem her würde ich da eher vielleicht schauen, was für die Benutzer Sinn macht. Also, wie erkennt Benutzer am ehesten, worum es sich handelt auf dieser Seite? Okay, und kurz auf Zwischenfrage. Wir haben jetzt nichts zu befürchten, wenn ganz viele Unterseiten die gleiche H1-Überschrift in dem Fall hätten. Nein, das soll da eigentlich kein Problem sein. Also ich würde in solchen Fällen, würde ich vielleicht einfach mal losgehen und AB-Tests machen und schauen, wie das bei den Benutzern ankommt. Vielleicht sieht man etwas, vielleicht merkt man, das ist total egal. Dann muss man sich dann nicht groß Gedanken drüber machen. Okay, gut, danke. Eine Frage zur internen Verlinkung. Wir hätten Navigationslinks, die mit einem Mousover eingebunden werden von Google gefolgt und indexiert. Werden die als versteckte Links bewertet und dementsprechend weniger relevant eingestuft. Ich vermute, das hängt ein bisschen davon ab, wie das mit Mousover gemacht wird. Das heißt, auf unserer Seite, was passiert mit normalen Hard-Termal-Seiten oder mit Zeiten, die JavaScript verwenden, dass wir die Seite erstmal aufbauen, wie das in einem Browser wäre und dass wir aufgrund von dem, was da dargestellt wird, dann versuchen, die Inhalte und die Links entsprechend herauszulesen. Und wenn jetzt zum Beispiel die internen Verlinkung da ist, eigentlich schon eingebunden ist und mit dem Mousover wird es ja einfach sichtbar gemacht oder unsichtbar gemacht, dann ist aus unserer Sicht kein Problem. Dann finden wir ja diese Links, dass ein A-Element mit diesem href-Altribut da mit einer URL angegeben, die wir da normal verfolgen können. Dann ist das überhaupt kein Problem. Wenn hingegen mit dem Mousover das so gemacht wird, dass der Link erst dann aufgebaut wird in dieser Seite. Das heißt, wenn die Seite geladen ist, sind diese Links gar nicht da im Browser. Dann ist es so, dass wir wahrscheinlich diesen Link gar nicht sehen. Das heißt, Googlebot geht nicht hin und überlegt sich, wo könnte jetzt Navigation sein und emuliert quasi ein Browser, ein Benutzer, der auf diese Seite geht mit der Mous und überall ein bisschen mit der Mous quasi drüberfahren zum Schauen, was passiert, sondern wir schauen die Seite so an, wie sie geladen wird. Und am einfachsten kann man das vielleicht auch selber in einem Browser versuchen, nachzustellen, indem das man die Seite lädt und dann mit InspectElement, so die Dormansicht von dieser Seite aufmacht und dann mit Ctrl-F nach dieser URL sucht, die man da so verlinkt hat. Und wenn man diesen Link zu dieser URL findet, dann in der Regel sind das Sachen, die wir dann auch direkt sehen, wenn Googlebot die Seite rendered, wenn hingegen dieser Link erst sichtbar ist, sobald man mit dem Mousover auf diese Seite geht, dann ist das seit was was Googlebot wahrscheinlich nicht findet auf einer Seite. In den meisten Fällen wird das so gemacht, dass mit dem Mousover eigentlich das nur eingeblendet oder ausgeblendet wird, und von dem her ist das kein Problem. Problematisch mit einem Mousover, welcher erst die Inhalte reinlädt, ist natürlich auch, dass das Ganze ein bisschen langsamer geht und dementsprechend wird das seltener auch so gemacht. Leider können die Vorhandkündigungen für die Hangouts nicht mehr aufgerufen werden. Ja, der Kalender ist in Überarbeitung. Ich hoffe, das kommt jetzt bald wieder, aber da scheinen sich einige Probleme ein, ja, eingebaut zu haben. Auch bei uns passiert das. In der Zwischenzeit würde ich einfach auf der, Google Webmasters, Google Plus-Seite in den einzelnen Kategorien jeweils nachschauen. Man kann da auch sich anmelden, dass man alle Posts direkt per E-Mail kriegt, damit man die entsprechend auch nicht mehr verpasst. Ich würde gerne gleich noch eine Frage stellen. Okay. Weil ich gerade mit einem Systemadministrator, das bezüglich noch diskutieren bin, in der Google Search-Konsole steht ja drinnen, dass gewisse Sachen, wie Skrips und so, gesperrt sind. Und eben dahin, als von Google, ich kann die Seite nicht zu lesen, wie diese einen Besucher zum Sehen bekommt. Und der Techniker möchte das nicht freischalten, weil er sagt, das braucht Google ja alles nicht. Okay. Da ich denke, das hängt ein bisschen davon ab, was das genau ist. Wir machen die, die brauchen wir effektiv nicht. Zum Beispiel Tracking-Pixels brauchen wir oft nicht. Oder wenn Werbung per Iframe eingebunden wird, dann kann das solch auch sein, dass wir das gar nicht brauchen und dass das ganz normal gesperrt sein kann. Wenn hingegen über diese Skrips wirklich auch Inhalte eingebunden werden, dann ist es schon wichtig, dass wir die irgendwie crawlen können, damit wir die auch beeinbinden können. Ein Beispiel, ist zum Beispiel, dass man eine Karte hat mit den verschiedenen Filialen einer Firma und die Filialen werden per JavaScript eingeladen in dieser Karte. Und wenn wir diese JavaScript-Dateien nicht laden können, dann können wir natürlich auch nicht sehen, was die Links zu den einzelnen Filialen sind und dementsprechend das so weiterverfolgen. Aber eben, wie gesagt, wenn das nur Tracking-Pixels sind, wenn das Elemente sind, die gar nicht relevant sind zum Aufladen dieser Seite, kann man das durchaussperren. Ich würde das einfach auch direkt im Browser selber testen, indem man diese Skrips irgendwie nicht lädt, dass man vielleicht eine Kopie dieser Seite macht und einfach diese Skrips oder die eingebundenen Dateien ganz weglässt, einfach zur Sicherheit, dass durch das weglassen, diese Skrips nicht irgendwelche weiteren Probleme eingebunden werden. Manchmal ist es ja zum Beispiel so, dass man ein jQuery-Skript hat und man denkt, ja, jQuery braucht ja Google nicht, die Inhalte sind auf der Seite. Wenn aber jQuery irgendwo auf der Seite verwendet wird und deswegen JavaScript quasi stehen bleibt mit einem Exception, dann können wir der Rest der Seite auch nicht richtig laden. Und das würde ich einfach sicherstellen, dass das wirklich funktioniert. Okay, danke. Super. Ist es möglich, AMP-Traffic auch in Search Console zu sehen? Ja, das sieht man direkt in Search Analytics kann man nachschauen, welche AMP-Seiten entsprechend Impressions und welche Clicks gekriegt haben, damit man das ein bisschen nachvollziehen kann. Je nachdem, wie man die Webseite eingerichtet hat, wenn man jetzt die AMP-Seiten auf ein Unterdomain hat, auf ein Subdomain oder wenn man die mobilen Seiten auf ein Subdomain hat, muss man halt schauen, welche Variante man in Search Console einrichten muss dafür. Aber grundsätzlich sind die da. Einige habe ich gesehen, filtern das indem sie per URL, zum Beispiel nach diesem Ampteil in der URL, das Ganze filtern. Andere nehmen die, wie heißt das, die Search Features Filter, den man da einstellen kann, wo man sagen kann, welche Art von AMP-Display an und für sich verwendet wurde. Eine Frage zum Canonical Tank. Gibt dieser Linkjuice weiter, wie eine 301 weiter Leitung? Auch über andere Domains sind weg. Ja, grundsätzlich funktioniert das so, dass an und für sich, wie bei einer 301 Weiterleitung oder wie bei irgendeiner Weiterleitung, ist es so, dass wir den Canonical Tank verwenden, um festzustellen, welche URL Canonical ist für diese Inhalte, die da gezeigt werden. Das heißt, praktisch gesehen, ist es so, dass unsere Systeme erkennen können, dass da verschiedene URLs vorhanden sind, die die gleichen Inhalte bringen. Und wir möchten einfach sicherstellen, dass wir eine von diesen URLs nehmen können und die URLs so indexieren und alle Signale, die wir haben, auf diese URL konzentrieren können. Und das machen wir einerseits durch Canonical Tank, durch Weiterleitungen, durch interne Verlinkung, durch Side Maps. All diese Methoden nehmen wir, um festzustellen, welches dieser URLs der Canonical ist für dieses Stück Inhalt. Und das geht auch über Domains hinweg. Manchmal ist es ja auch sinnvoll, wenn ich jetzt zum Beispiel verschiedene Länderdomains habe und ich sage, das ist jetzt eigentlich nur die Seite, die ich indexiert haben möchte. Oder wenn man verschiedene vielleicht Markenseiten hat und man hat eine Seite, die man wirklich geteilt haben möchte über diese verschiedenen Websites, aber man möchte sie in dieser Variante indexiert haben, dann kann man das so angeben. Und von dem her sind all diese Methoden an Canonical an und für sich sehr ähnlich, indem das die Signale, die wir haben, werden konzentriert auf die URL, die man angegeben hat. Wichtig für uns ist natürlich, dass diese Signale, die wir kriegen, zusammengefasst und schauen das Gesamtbild an und versuchen dann aufgrund vom Gesamtbild eine Entscheidung zu treffen. Und wenn die Signale nicht ganz direkt sind oder ein bisschen unterschiedlich sind, dann ist es manchmal schwierig, dass wir die Entscheidung herausfinden, die ihr haben wollt. Das heißt, wenn zum Beispiel ein Canonical Tag auf eine URL zeigt, aber diese Seite und das Sidemap-Datei ist dann noch eine andere angegeben, dann gibt es da verschiedene Varianten, die wir wählen könnten als Canonical und vielleicht nehmen wir eine Variante, die ihr jetzt nicht gewollt habt. Wenn hingegen all diese Signale auf das gleiche zeigen und wenn wir wirklich sicher sein können, dass das jetzt wirklich der Canonical ist, den wir dafür verwenden sollen, dann ist es meistens schon so, dass wir dem auch folgen Wichtig ist diesbezüglich vielleicht auch einfach zu sagen, dass selbst wenn wir den falschen Canonical nehmen, also ein Canonical, der nicht dem entspricht, was bei euch im REL Canonical angegeben ist, dann ändert das Ranking eigentlich nicht. Das heißt, die Inhalte werden dann einfach unter dieser URL indexiert oder unter dieser URL sind aber die gleichen Signale und vom Ranking her ergibt es dann auch wieder eine gleiche Bild. Fragen zum Thema Disavow? Der Disavow-Datei ist es so, dass man da angeben kann, dass man nicht mit links zur eigenen Website irgendwie zusammen gezogen werden möchte, dass die quasi getrennt behandelt werden sollten auf unserer Seite. Werden Disavow the backlinks, die aus Google-Sicht nicht schädlich sind, auch entwertet? Ja, wenn die bei euch in der Disavow-Datei sind, dann ignorieren wir diese Links für eure Website, egal was quasi der Hintergrund dafür ist. Ich finde das einerseits praktisch, weil so könnt ihr wirklich auch ganz klar sagen, mit denen links möchte ich nichts zu tun haben, egal was Google Algorithmen dazu denken würden. Sollte man Domains, die mittlerweile per 301, 410 oder 500 der Status Code liefern, außer Disavow-Datei entfernen, man kann das machen, man muss das aber nicht. Wenn in der Disavow-Datei URLs vorhanden sind, die nicht mehr so indexiert sind oder nicht mehr so gekraut werden, dann ist das aus unserer Sicht okay, die stören nicht, die werden einfach nicht bearbeitet, man muss das nicht entfernen. Man kann das durchaus entfernen, wenn man will, aber man muss das nicht. Wichtig ist vielleicht dies bezüglich auch, dass wir solche Domains, die eine Weiterleitung haben oder die jetzt nicht mehr existieren oder in 500 der Status Code haben, nicht von einem Tag auf dem anderen aus dem Index herausnehmen, das heißt alle Links entfernt von dieser Domain, sondern wir machen das je nachdem wie wir halt crawlen, in dem dass wir da Schritt für Schritt haben, wo wir Fehler gesehen haben, die dann aus dem Index herausnehmen. Das heißt, wenn ich jetzt heute ein Domain auf 404 stelle, dann ist es nicht so, dass morgen alle Links, die von diesem Domain waren, jetzt aus unserem System entfernt worden sind, sondern das geht wirklich Schritt für Schritt voran und von dem her finde ich es nicht unproblematisch oder finde ich das vielleicht sogar eine gute Idee, wenn man die Disavow-Datei ein bisschen quasi auch diesen alten älteren Sachen noch weiterhin dass man die beibehält. Wie gut kommt der Crawler zu Recht, wenn die gesamte Seite mittels JavaScript aufgebaut wird? Meistens relativ gut. Manchmal ist es ein bisschen schwierig. Das heißt, wir haben da verschiedene Informationen schon mal rausgegeben, wie Googlebot Seiten aufbaut. Ganz neulich auf der Developer- Seite haben wir Informationen auch dazu, was Googlebot an und für sich macht, wenn eine Seite aufgeladen wird, wie diese Seiten gerendert werden, welche Chrome-Version da intern ungefähr verwendet wird, welche Funktionen auf unserer Seite nicht unterstützt werden. Der Großteil der Seiten, die mit einem JavaScript- System können wir problemlos renderen. Es gibt gewisse Sachen, wo wir an unsere Grenzen kommen, beziehungsweise die wir einfach aus Policy Gründen nicht unterstützen. Eine Sache ist zum Beispiel ein Service Worker. Das heißt, wenn eurer Website ein Service Worker braucht, um überhaupt zu laden, wenn das gebraucht wird, dann kann es sein, dass wir die Seite nicht renderen. Deswegen auch, dass man sogenanntes Feature Detection verwendet im JavaScript, dass man einfach testet, unterstützt der aktuelle Browser diese Funktion. Wenn ja, dann verwende ich sie. Wenn nein, dann nehme ich etwas anderes, was vielleicht ähnliche Funktionalität hat. Eine ähnliche Funktionalität wird auch gemacht, indem man mit Polyfills arbeitet. Das sind kleine Scripts, die man einbindet auf der Seite, eine Funktion vom aktuellen Browser wie emulieren. Mit solchen kommt man eigentlich relativ gut zurecht. Man kann Seiten selber auch recht schnell testen, indem man in Search Console mit Fetch and Render die Seite einfach aufruft und dann sieht man sehr schnell, was hat Google Board rendering können in Fetch JavaScript, was hat nicht funktioniert und so kann man das einigermaßen entsprechend auch optimieren und verbessern. Für externe Seiten einfach mal überschlagsmäßig anschauen möchte, dann kann man auch mit dem Mobile Friendly Test arbeiten. Dort wird auch mit Google Board gearbeitet, wird an und für sich das gleiche Rendering gemacht, wie Google Board normalerweise macht, einfach in Form eines Mobilgeräts und da sieht man auch einfach den Screenshot von dieser Seite, wie das von Google Board gerendert wird. Was sicherlich viele Blogger interessiert, wie viele Beiträge sollte man in einer Liste pro Seite anzeigen? Ist es tendenziell besser mehr Artikel anzutiesen oder eher weniger? Das ist an und für sich vollkommen euch überlassen. Das könnt ihr mehr machen, ihr könnt weniger machen. Ich denke, das sind Sachen, die kann man auch ein bisschen testen und eher auf Benutzerbedürfnisse eingehen als auf Suchmaschinen. Was ich einfach machen würde, ist, gerade wenn ihr wenig Kommentare auf eurem Blogpost habt, einfach sicherstellen, was ihr eher mit einem Teaser arbeitet, auf dieser Zusammenfassungsseite als mit den gesamten Beitrag, so dass wir wirklich auch erkennen können, welche Inhalte unterschiedlich sind auf dieser Kategorienseite im Vergleich zur einzelnen Blogpost. Das heißt, wenn die ganze Inhalte jeweils in der Kategorienseite auch dabei ist, dann wissen wir nicht, warum folgt mir überhaupt die einzelne Blogpost-Zeichen in den Suchergebnissen, das sind ja eigentlich die ganzen Inhalte auch schon dabei. Wenn hingegen wirklich deutlich mehr Inhalt auf der Blogpost-Seite ist, als auf dieser Kategorienseite, dann ist es für uns klarer, da ist ein Link auf dieser Blogpost, hier sind eigentlich die ganzen Inhalte. Das heißt, dass man für diese Inhalte dann in den Suchergebnissen entsprechend auch zeigen. Und eben, wenn man viele Kommentare hat, dann ist das eigentlich automatisch auch so, weil diese Kommentare sind ja in der Regel nicht auf der Kategorienseite. Wenn man wenig Blogpost-Kommentare hat, dann würde ich einfach mit Teaser arbeiten, dass man wirklich diesen Unterschied auch entsprechend hat. Aufgrund der angekündigten Warnungen in Chrome, kommt quasi die Frage wegen Sichtbarkeitsverlust. Wie sieht das aus? Vielleicht grundsätzlich zu dem ist zu sagen, dass wir in der Suche für das Ranking da keine Veränderungen vorhaben, bezüglich dieser Anpassung in Chrome, sondern dass es wirklich einfach eine Sache in Chrome, etwas, was Benutzer sehen würden in Chrome, wenn sie mit Chrome kommen. Und von dem her ist es nicht so, dass ihr aus SEO-Gründen auf harte TPS wechseln solltet, aber es macht in vielen Teilen auch Sinn. Die Warnung in Chrome ist nicht so, dass die ganze Seite blockiert wird, sondern relativ dezent. Das heißt, wenn jemand etwas eingebt, dann sieht man das. Und wenn man denkt, damit können die Benutzer auch leben, ob ihr euch überlassen, ob ihr alles schnell auf harte TPS umstellen wollt, oder ob ihr das Schritt für Schritt machen wollt, vielleicht ein bisschen später, das anfühle ich euch überlassen. Einfach nur zur Sicherheit, damit das auch wirklich klar ist. Bezüglich einer Umstellung, wenn man doch eine Umstellung machen möchte, ich finde das eine gute Sache. Ich denke, harte TPS ist sicher das, was längerfristig jeweils relevant sein wird. Ich denke, da gibt es kein Wandel mehr zurück zur harte TPS-Seiten. Von dem her macht das immer Sinn, dass man dies eine Umstellung macht. Unsere Systeme sind recht gut darauf ausgerüstet auf eurer Umstellung. Und in der Regel, wenn man sich an die Anweisungen hält, die wir im Hilfesenter haben, dann sollte man da eigentlich keine großen Schwankungen sehen in der Suche. Man kann nicht sagen, welche Schwankungen bis da alles umgestellt ist. Aber mittelfristig bzw. relativ schnell sollte das eigentlich unproblematisch sein, dass man schnell auf harte TPS wechseln kann, wenn man das machen möchte. In Search Console haben wir die Empfehlung, dass man beide Properties, also die harte TPS und die harte TPS-Version jeweils verifiziert, einfach damit man sicher ist, dass man die Varianten bekommt, die vielleicht für einen von diesen beiden Varianten geeignet sind. Das heißt, wenn zum Beispiel Crawl-Failer einfach in einer Variante auftreten, damit man das wirklich auch sieht, nicht, dass man die irgendwie verpasst und dass man dann gar nicht merkt, dass die Website nicht mehr so läuft, wie sie eigentlich laufen sollte. Ich arbeite bei einer Marketing-Agentur für Apps. Ein Konkurrent in unserem Feld hat Fake-Seiten erstellt, die alle Firmen auf unserem Gebiet bewertet. Die Bewertungen sind grundsätzlich nicht schlecht, aber natürlich ist seine eigene Seite immer am besten dargestellt. Was kann man da machen? Grundsätzlich aus unserer Sicht ist das nicht unbedingt etwas, wo wir einschreiten würden, wo wir sagen würden, das sind falsche Inhalte, die würden wir aus den Suchergebnissen herausnehmen, und wir versuchen, dass er einfach dem Web ein bisschen zu überlassen. Wir versuchen schon auch in unseren Rankings festzustellen, welche Seiten sind wirklich relevant, und meistens passiert es so, dass solche Seiten dann als weniger relevant angesehen werden, weil sie halt auch beim Benutzern entsprechend weniger gut ankommen und entsprechend auch weniger weiter empfohlen werden. Vom dem her pendelt sich das in vielen Fällen einfach ein. Ich kann das trotzdem mal anschauen mit unserem Team auf unserer Seite, wenn du mir die Links mal zuschicken willst oder die Suchergebnisse, die du so siehst, dann kann ich das mit unserem Team mal hier anschauen, ob da irgendetwas ist, was wir auf unserer Seite anders machen müssten, oder ob das von unseren Algorithmen her sich eigentlich eintendeln sollte. Würdest du empfehlen, eine große Menge Seiten Content komplett zu entfernen, zum Beispiel um CrawlBudget zu sparen, oder weil es ein schlechter Signal für Googlebot ist, oder ist es ausreichend ein No-Index Follow Tag zu setzen. Grundsätzlich kann man das machen, wie man will. Bei den meisten Websites ist es so, dass wir mit den CrawlBudget nicht Probleme haben. Das heißt, wir können die meisten Websites gut Crawlen und haben da genug Spielraum, um ein bisschen duplicate Content zu crawlen. Bei den meisten Websites ist es auch normal, dass wir eine gewisse Menge von duplicate Content einfach finden und das ist aus unserer Sicht kein großes Problem. Problematischer Wert, wenn man jetzt wirklich eine sehr große Website hat oder wenn man einen sehr langsamen Server hat, der wirklich Mühe hat, wenn wir zum Beispiel mal ich weiß nicht, 1.000 Seiten am Tag crawlen müssen statt 1.000 Seiten am Tag. Bei einer sehr großen Website würde ich auf jeden Fall überlegen, wie man mit duplicate Content am besten umgehen kann. Dass man intern die links sauber hält, dass intern die URLs auch sauber sind, dass man da wirklich möglichst schnell die eigentlichen Inhalte findet. Bei einer kleineren Website die auf einen langsamen Server ist, würde ich vielleicht eher empfehlen, dass man sich überlegt, wie kann man die Website insgesamt ein bisschen schneller machen, so dass dieses duplicate Content-Problem nicht so problematisch ist, weil es kann natürlich auch auf unserer Seite sein, dass wir auf einmal mehr crawlen möchten oder es kann sein, dass auf einmal zehnmal mehr Benutzer kommen und da muss eure Website ja auch dem irgendwie standhalten. Das heißt aus praktischen Gründen könnte man schon das eine oder andere machen. Ich würde einfach gerade bei kreinerln Websites würde ich empfehlen, dass man einfach mit der Infrastruktur arbeitet und das wirklich auch sauber ein bisschen aufstorgt. Bezüglich Noindex Follow Tag ist es so, dass wir die Seiten natürlich trotzdem crawlen müssen, um diesen Metatag zu finden. Das heißt, vom Crawl Budget her in ersten Moment ändert das eigentlich relativ wenig. Im Laufe der Zeit wissen wir dann zwar schon, dass ein Noindex auf dieser Seite die müssen wir vielleicht nicht so häufig crawlen oder vielleicht ist es sogar etwas ähnliches wie ein Soft 404, dass wir sagen, gut, wir können die ganz aus dem Index kippen und müssen die gar nicht mehr crawlen, aber es ist eigentlich kein klares Zeichen für uns, dass diese Seite nicht gecrawlt werden soll. Das heißt, kurzfristig ändert das gar nichts. Was besser ist, in einem solchen Fall, dass man so schnell canonical arbeitet, dass man uns ganz klar sagt, diese Seite müsste man so nicht crawlen, sondern man könnte direkt den canonical Seite crawlen und sehen wir direkt auch diese Verwendung zwischen der einen quasi Duplicat und mit dem Original. Da würde ich er das empfehlen. Ich habe in den letzten Wochen mehrfach eine Seite über das Spam Formular gemeldet wegen Rich und da passiert einfach nichts. Was kann man da machen? Schwierig zu sagen. Einerseits ist es so, dass vom Web Spam Team her die Spam Reports natürlich auch priorisiert werden müssen und manche Sachen werden schneller behandelt, manche Sachen spart man vielleicht auf. Andere Sachen verwendet man um unsere Algorithmen im Allgemeinen einfach zu verbessern. Das heißt, nur weil man etwas gelöscht hat, heißt nicht unbedingt, dass da direkt am nächsten Tag darauf reagiert wird und dass das umgesetzt wird und die Seite gelöscht wird oder die Rich Snippets gelöscht werden, sondern das ist an und für sich eine Hilfe für uns, dass wir die Algorithmen verbessern können in erster Stelle und in solchen Fällen, wo wir wirklich das Gefühl haben, dass da grundlegend ein größeres Problem vorhanden ist, dass wir algorithmisch nicht so einfach werden würden, würde man da manuell dann entsprechend einem Ausnahmertreffen. Das heißt, in einem solchen Fall, wenn man da jetzt mehrfach eine Seite schon eingereicht hat, dann würde ich das eher sein lassen mit dem Rich Snippets Spam Formular, weil dann haben wir unsere Web Spam Team Mitarbeiter, die diese Seite ja schon mal angeschaut und schon mal einigermaßen eingestuft, was man da machen möchte da, ja, die könnte man das am besten machen. Einerseits, eben wie gesagt, solche Sachen werden dann verwendet, um die Algorithmen zu verbessern, dass wir das allgemein automatisch nicht mehr so darstellen. Wenn man da, darauf nicht warten will oder nicht darauf warten kann, dann könnt ihr mir natürlich das schon auch mal direkt zuschicken, dann schaue ich das mal hier an, aber in der Regel, wenn das Web Spam Team die Seiten verwendet ist, dann haben sie das schon selber eingestuft. Dann ist das nicht etwas, wo ich kommen würde und sagen würde, ihr habt das so für später aufgehoben, aber eigentlich müsstet ihr das jetzt sofort machen, weil jemand mir das im Hangout gesagt hat. Manchmal ein bisschen schwierig, verstehe ich schon. Ein Doppelkart aus dem Gruppenchat macht es Sinn, auf einer Shop Kategorie Seite individuelle Produkte zu erstellen, also nicht einfach nur die ersten Zeilen aus Produktbeschreibung zu übernehmen oder ist das egal. Grundsätzlich ist das egal. Zumindest aus Seite der Suche, vom Crawling Indexing Ranking her, ist das grundsätzlich egal. Ich denke, wenn man ein bisschen Unterschiede hat in den Links zu den einzelnen Seiten, zum Beispiel intern jetzt, dann hilft uns das ein bisschen mehr das Gesamtbild von diesen Produktzeiten zu sehen. Aber das wird wahrscheinlich nicht so sein, dass wir dann diese Seiten auf einmal einfach höher ranken. Von dem her würde ich das eher auf die Benutzerbedürfnisse vielleicht anpassen und wirklich mit Benutzern mal mal testen und schauen, was funktioniert, was funktioniert nicht so gut. Wie verstehen Sie am schnellsten, was hinter dieser Detailseite ist, wenn man die Kategorienseite aufmacht? Eine Frage zur Indexierung Steuern bei Onlineshops. Es kommt ab und an vor, dass eine indexierte Shop Kategorie weniger Produkte hat als normal. Zum Beispiel, wenn jetzt nur fünf Produkte oder weniger in eine Kategorie vorhanden sind, sollte man die Kategorie auf New Index setzen oder nicht, oder wie, wie geht man das? Grundsätzlich ist es so, dass wenn man eine Seite auf New Index setzt und danach wieder indexieren lässt, dann können wir eigentlich in der Regel die Signale relativ schnell wieder aufbauen und die Seite relativ schnell wieder an gleich oder ähnlicher Stelle in den Suchergebnissen zeigt. Das heißt, dieser Wechsel zwischen New Index und Index ist aus unserer Sicht weniger problematisch. Das ist also mein Problem mit einer Kategorieseite, die wenig Produkte hat. Aus unserer Sicht ist eigentlich nur etwas problematisch, wenn eine Kategorienseite gar keine Produkte hat. Weil dann sieht es aus wie eine Soft 404-Seite. Wenn wir die Seite aufrufen und da steht dann keine Produkte vorhanden zu diesem Thema, dann denkt wir, diese Seite können wir ganz jetzt relativ schnell, dass wir sagen, gut, wir crawlen diese Seite einfach auch weniger häufig, weil das ist eigentlich eine 404-Seite. Da steht ja, dass da nichts vorhanden ist, also können wir die ein bisschen zurückstufen auf unserer Seite. Das heißt, ich würde weniger darauf achten, ob jetzt 5 Produkte oder 2 Produkte da sind, sondern eher diesen Unterschied zwischen 5 Produkten und gar keine Produkten den versuchen abzufangen und die Seiten dann entsprechend auf New Index und alles, was dazwischen ist, ich meine zwischen 1 und ich weiß nicht wie viele Produkte, wo ihr ihre Grenze setzen wollt, ist an und für sich euch überlassen. Manchmal macht es für benutzer Sinn, dass eine Kategorienseite trotzdem vorhanden ist, auch wenn nur 1 oder 2 Produkte da sind, hängt ein bisschen davon ab, wie ihr das eingerichtet habt im Shop. Wir sind derzeit dabei, individuellen Content auf Produktebene einzupflegen, Produktbeschreibungen, bisher wurden hauptsächlich die Beschreibungen der Hersteller übernommen. Nun können wir leider nicht mehr tausende Produkte auf einmal mit neuen Content ausstatten. Macht es Sinn, dort erstmal die Beschreibung der Hersteller stehen zu lassen oder die Beschreibungen zu entfernen, bis wir etwas Neues gefunden haben. Ich würde in einem solchen Fall die Beschreibung der Hersteller erstmal übernehmen. Aus unserer Sicht, was da passiert, ist, wir indexieren diese Seiten normal. Wir sehen ja, dass der Rest dieser Webseite also dieser Produkte-Seite ist ja an für sich eigenständig. Das heißt, sie ist ja auf eurem Shop, ihr habt vielleicht Informationen zu eurem Shop, eure Adresse, all solche Sachen geben uns Zusatzinformation und deswegen indexieren wir erstmal diese Seite. Und dann im zweiten Schritt, wenn jemand nach diesem Produkt sucht, dann sehen wir einerseits, dass jemand nach diesem Produkt allgemein sucht, dann sehen wir all diese Varianten, die die gleiche Hersteller-Beschreibung haben und würden die eher zusammenklappen und sagen, das ist jetzt ein Ergebnis in unseren Suchergebnissen. Und aufgrund von den anderen Faktoren, die wir vielleicht vorhanden haben, versuchen wir dann festzustellen, welches dieser einzelnen Shops jetzt die relevanteste für diesen Benutzer ist. Und das kann zum Beispiel sein, aufgrund vom Standort vielleicht weitere Informationen, die der Benutzer angegeben hat in der Suche. All solche Sachen können dann trotzdem relevant sein. Das heißt, man verliert an und für sich nicht, wenn man erstmal mit der Default-Beschreibung arbeitet. Man gewinnt aber dann trotzdem ein bisschen was, wenn man mit einer eigenen Beschreibung dann später nacharbeitet. Bezüglich der Prioritisierung von der selbstgeschriebenen Beschreibung, würde ich einfach auf das schauen, wo man am ehesten vielleicht der Besucher erwartet oder am ehesten Suchenden erwartet, wo man Impression zieht in den Suchergebnissen, dass man sich auf die wichtigsten Sachen erst mal konzentriert und dann Schritt für Schritt den Rest dann auch ausbaut, wenn man dazu noch Zeit hat. Seit knapp einem Jahr arbeitet unser Team an vielen verschiedenen Kategorienzeiten, die sehr ausführlich und umfangreich recherchiert und verfasst sind. Nicht zu trotz zu ranken diese Seiten furchtbar schlecht. Was kann man da quasi machen? Schwierig zu sagen, ohne die Website direkt zu sehen. Was sicher wahrscheinlich helfen würde, ist, dass man wirklich auch diese Seiten intern sehr stark verlinkt. Dass man wirklich auch klar Google ein Signal gibt, das sind jetzt wichtige Seiten auf unserer Website. Was wahrscheinlich auch hilft, ist, wenn man sieht, dass diese Seiten bei Benutzern gut ankommen, dass man auch empfiehlt, dass sie auf diese Seiten verlinken oder dass sie diese Seiten auch weiter empfehlen können. Manchmal kann man das mit einem Widget auf einer Seite machen, dass man das relativ einfach macht für Benutzer, das z.B. weiterzugeben auf Social Media oder selbst irgendwie einzubinden. All das hilft uns ein bisschen festzustellen, wo sind für sich die wichtigsten Seiten in einer Website? Trotzdem ist es aber nicht so, dass nur weil gute Inhalte vorhanden sind auf einer Website, dass die automatisch an erster Stelle steht. Das heißt, es sind da sehr viele Faktoren, die wir nehmen für das Crawling, Indexing und Ranking und da kann es durchaus sein, dass die Inhalte vielleicht sehr gut sind. Die anderen Signale, die wir haben, sagen uns dann vielleicht eher, andere Seiten sind auch sehr gut und vielleicht ranken wir dann die anderen Seiten eher an erster Stelle als eure Seiten. Das heißt, gute Inhalte sind auf jeden Fall ein wichtiger Grundstock für eine Website, die auf die kann man ja dann auch aufbauen. Aber sie sind keine Garantie, dass nachher diese Seite auch wirklich an erster Stelle in den Suchergebnissen ersichtlich ist. Sondern das sind dann Sachen, die brauchen dann halt auch ein bisschen Zeit und wo man dann vielleicht auch irgendwie Benutzer jeweils erst mal motivieren muss, dass sie zu eurer Website kommen, vielleicht über andere Mittel und dann so entsprechend dann weiter aufbaut. Internationale SEO wir haben eine .com-Seite und die jeweiligen Länder-Version zum Beispiel .com, .de, .de oder .de, .at und so weiter angelegt. Wir haben nun das Problem, dass Content für .de, .at, also auf Google.de sichtbar ist. Wir haben alle Länder-Seiten in Search Console angelegt und die das jeweilige Land hinterlegt. Die Landsprach-Version haben wir auch angelegt. Age of Langtags werden ebenfalls herausgerendet. Was können wir noch tun? Schwierig zu sagen, was genau passiert. Wenn du mir ein Beispiel schicken möchtest, kann ich das auch mal hier genauer anschauen. Es gibt da zwei Varianten, die manchmal auftreten. Einerseits kann es sein, dass wir die Seiten zusammengeklappt haben, weil wir gesehen haben, das sind eigentlich genau die gleichen Inhalte für Deutschland und für Österreich zum Beispiel, wenn wir sehen, das sind beide Seiten in Deutsch und es gibt auch für sich keinen nennenswerte Unterschiede zwischen dann sag mal gut, wir klappen diese zusammen und indexieren einfach eine Variante und dementsprechend kann es dann sein, dass man auf Google.de sucht und wir finden die österreichische Variante, weil das die Variante ist, die wir gefunden haben. Was man da machen kann, ist einfach sicherstellen, dass die Seiten wirklich auch unterschiedlich sind. Dass wenn wir die Seiten nebeneinander anschauen, dass wir sehen, dass es wirklich für Deutschland, das ist wirklich für Österreich, dass da entsprechend genügend Unterschiede zumindest vorhanden sind, dass wir das automatisch auseinanderhalten können. Eine andere Sache, die geledentlich auch auftritt, ist, dass wir einfach sehen, dass eine Variante viel, viel stärker ist als die andere. Das sehen wir oft, zum Beispiel, wenn eine sehr starke amerikanische Website auf einmal eine deutsche Seite dabei hat und mit hreflang das sauber verlinkt hat, dann kann es trotzdem sein, dass wir die amerikanische Variante vielleicht in den Suchergebnissen zeigen, weil wir einfach gesehen haben, dass es jetzt wirklich sehr stark und sehr klar für uns, dass diese Variante ist wirklich die stärkste Variante oder die stärkste Variante bei Weitem und dass wir die dann entsprechend zeigen in Suchergebnissen. Das heißt, hreflang hilft uns, um eine wichtige Wahl zu treffen. Es kann aber trotzdem sein, dass wir diese Wahl überschreiben und dann trotzdem die andere Variante zeigen in den Suchergebnissen. Das könnte vielleicht in diesem Fall auftreten, wenn zum Beispiel die Website für Österreich seit vielen Jahren aufgebaut wurde. Wenn das wirklich die Website ist, die an aller stärksten ist und ihr jetzt neu eine Seite für Deutschland dazugefügt habt, dann ist es nicht automatisch so, dass die deutsche Seite dann immer in Deutschland entsprechend erscheint. Muss ich auf Page Browser-Seiten ein Canonical auf Seite 1 setzen, wenn man quasi so paginierte Seiten hat. Grundsätzlich würde ich das nicht machen. Aus dem einfachen Grund, dass die Seiten sind ja nicht equivalent. Das sind ja nicht die gleichen Inhalte auf Seite 1 wie auf Seite 2. Und dementsprechend, wenn unsere Systeme das anschauen, dann kann es durchaus sein, dass sie sagen, ah, da ist ein Canonical gesetzt auf Seite 1, aber eigentlich sind da ganz andere Inhalte auf Seite 2 und dann ignorieren wir halt den Canonical. Das heißt, grundsätzlich denke ich, wäre das zumindest aus theoretischer Sicht wäre das falsch. Ich weiß, viele Websites machen das trotzdem und unsere Systeme können in der Regel damit auch umgehen. Es ist nicht so, dass man wirklich etwas verliert. Problematisch ist es höchstens, wenn einzelne Produkte auf Seite 2 verlinkt werden und nie von Seite 1. Wenn wir wirklich auf Seite 1 konzentrieren und einzelne Produkte auf Seite 2 verlinkt werden, dann finden wir diesen Link zu diesen einzelnen Produktzeiten unter Umständen dann nicht mehr oder können das, wenn wir den Gesamtwebsite anschauen und die Linksintern anschauen, dann kann es aus unserer Sicht so aussehen, also ob diese Produktzeiten gar nicht so wichtig sind, weil intern werden die gar nicht richtig verwendet und dementsprechend können wir die ganz rauslassen vielleicht. Wenn hingegen ihr die Kategorien so eingerichtet habt, dass Produkte vielleicht auf mehreren Kategorien vorhanden sind und dass jedes Produkt auf jeden Fall auf einer Seite ist, die ein Canonical hat auf sich selbst oder zumindest so indexierbar ist, dann sehe ich da eigentlich keine großen Probleme. Angenommen, es befinden sich einige hunderte oder tausende URLs in Google's Index, die aber intern nicht mehr verlinkt sind, also über den Board nicht mehr gecrowt werden können, wie bekomme ich die schnellstmöglich aus dem Index, ohne es manuell über Search Council machen zu müssen. In der Regel crawlen wir eigentlich jeder URL, die bei unserem Index ist, ab und zu wieder. Das heißt, wenn eine URL jetzt in 404 zurückgibt, dann irgendwann crawlen wir die wieder und nehmen die dann entsprechend aus dem Index heraus. Es kann einfach sein, dass es dann vielleicht ein paar Monate geht, bis wir die wieder gecrowt haben. Aber in der Regel versuchen wir zumindest alle Halbjahr, alle URLs, die bei uns im Index sind, einmal wieder zu crawl und wenn die dann Fehler geben, lassen wir die fallen. Man kann das ein bisschen steuern oder ein bisschen schneller hinkriegen, indem man die zum Beispiel in eine Sign-App-Datei hinein nimmt, dass man sagt, ich nehme die jetzt in der Sign-App-Datei hinein, ich weiß, dass die alle 404 zurückgeben, aber dadurch, dass sie in der Sign-App-Datei sind, mit einem neuen Änderungsdarkum geht Google da jetzt erstmal hin, crawlt diese Seiten, sieht, dass dann 404 ist und lässt sie dann ein bisschen schneller falten. John? Ja. Die geben kein 404 aus. Also, die geben kein 404, sollen aber nicht dem Index sein. Dann mache ich dann einen No-Index-Seit drauf. Ja, aber mit einem No-Index und die Sign-App-Datei hinein geht auch. Aber dann dauert es ja doch, kannst ja doch schon, du sagst, der Bot kommt da ab und zu oder crawlt, gelegentlich dann auch mal, denn dauert es ja doch ein bisschen länger. Ja, eben, wenn man das jetzt einfach natürlich lässt, dann geht das sicher eine Weile, je nachdem, welche Seiten das sind. Eben mit einer Sign-App-Datei mit dem aktuellen Änderungsdatum für die einzelnen URLs sollte das ein bisschen schneller gehen. Okay, alles klar, danke. Dann sehe ich da noch eine letzte Frage. Gibt es irgendeinen Anhaltspunkt für uns, welche Inhalte für Featured Snippets verwendet werden? Wir haben einige Ergebnisse, aber leider werden teilweise erst die zweiten oder dritten Absätze ausgegeben. Bei der Sprachausgabe zum Beispiel fängt Google Home nun mitten im Rezept an und nicht zu Beginn. Weiß ich nicht. Das machen wir an und für sich algorithmisch, wie eigentlich mit jedem Snippet. Zumindest aus unserer Sicht haben wir da gezielt keine Hinweise für Featured Snippets, weil wir eigentlich natürlichen Websites erkennen möchten und eigentlich die Inhalte natürlich von einer Seite herauslesen möchten. Was man da vielleicht machen könnte, ist einfach mit dem HTML zu arbeiten und sich zu überlegen, wieso ist jetzt Google da verwert und fängt am falschen Ort, zeige ich mal an, mit dem Featured Snippet und was könnte man da machen, um das zu verbessern? Gerade bei Rezepten kann man natürlich auch mit den Markup arbeiten. Also mit Structuredata, das man da gezielt angebt, das ist die Beschreibung, das sind die Inhaltsstoffe, das sind quasi die anderen Kennwerte für dieses Rezept. Und das so zumindest Google das auch als Rezept aufnehmen kann und so entsprechend auch ein bisschen einfacher in einem schöneren Format in den Suchergebnissen bringen kann. Ich glaube für Recipes haben wir auch diese sogenannten ein bisschen anderes Format haben, wo dann vielleicht auch das Bild dabei ist, wo einige Eckdaten auch dabei sind und da würde ich dann eher auf so etwas steuern, als mit dem HTML da versuchen, den Featured Snippet zu optimieren. Okay. Ich glaube, da haben wir es geschafft. Gibt es von euch noch irgendwelche Fragen? Keine Fragen? Okay. Dann habe ich vielleicht noch eine Anregung, vielleicht eher allgemein. Was ich vielleicht an eurer Stelle oder mich jetzt gezielt euch persönlich also an allgemein an SEO oder Webmaster-Stelle mal machen würde, ist mir mal überlegen, gerade mit Voice-Suchen, mit Google Home, mit Alexa, was könnte man machen mit der eigenen Website oder mit dem Website von Kunden, damit die auch relevant sind, wenn eine Antwort per Voice kommt. Es gibt zum Beispiel die Möglichkeit mit api.ai mal ein bisschen zu spielen und zu überlegen, was für Anfragen könnte man abfangen, was könnte man vielleicht für Benutzer gut abfangen und dann vielleicht könnte man sich auch überlegen, wie könnte ich das entsprechend auch monetisieren. Gibt es da Möglichkeit, und dass man die Dienstleistungen vielleicht ein bisschen besser per Voice zugänglich macht. In die Richtung wird es auf jeden Fall ein bisschen weitergehen. Ob das anhält, bis auf Avic, weiß ich nicht, aber zumindest was ich da gesehen habe, es ist, dass die ganzen Voice-Interactions, die kommen mehr und mehr, und als SEO ist man vielleicht da ein bisschen besser geeignet, fast als andere sich zu überlegen, wie könnte man da profitieren, wie könnten einzelne Arten von Websites da ein Vorteil auch herausholen. Okay, dann sage ich jetzt erstmal Tschüss, vielen Dank fürs Kommen, vielen Dank fürs Einreichen von vielen Fragen und ich richte die nächsten Hangouts wahrscheinlich gegen Freitag wieder ein. Falls noch weitere Fragen kommt, könnte die da reinnehmen oder natürlich auch im Hilfeforum posten. Das sind auch immer viele, die gute Antworten geben können. Dann schönen Nachmittag noch und bis zum nächsten Mal. Tschüss allerseits.