 Herzlich willkommen beim heutigen Google Webmaster Sprechstunden Hangouts. Mein Name ist Janis Müller, ich bin Webmaster Trends Analyst hier bei Google in der Schweiz. Und ein Teil von dem, was wir machen, ist mit Webmaster, mit Publisher sprechen, wie jetzt hier im Hangout und wie diejenigen, die alle möglichen Fragen schon eingereicht haben. Wie immer machen wir es vielleicht auch gerade so am Anfang, dass wenn eine von euch eine Frage hat, die ihr gerade stellen möchtet, dann schauen wir das doch gerade am Anfang an. Okay, sonst lege ich mal los mit der ersten Frage von Christian. Eine Frage bezüglich der Indexierung von Single-Page-Apps und der Einsatz von Angular. Google Page-State Insights zeigt uns für unsere Single-Page-App ein Verbesserungsvorschlag, der lautet JavaScript und CSS-Resourcen zu entfernen, wie das Rendering-Blockieren. Das betreffende JavaScript ist aber das, was die Seite rendered. Kann es sein, dass Page-Speed Insights noch nicht Single-Page-Apps und Angular klar kommt? Theoretisch kann das schon sein. Grundsätzlich ist es bei uns so, dass wir, wie Page-Speed Insights und Search Console, nicht an unsere Produkte ausrichten. Das heißt, wir versuchen, das möglichst neutral anzuziehen und die Seiten, die Frameworks, die Systeme, die da draußen sind, eigentlich so zu behandeln, wie jede andere Website, die auf uns zukommen würde. Und so ist es dann auch so, zum Beispiel, dass wir nicht Analytics oder Adsense oder so irgendwie ausklammern bei der Page-Speed Berechnung, sondern das sind Inhalt auf der Website wie jede andere. Und ebenso zeigen wir dann auch vielleicht Probleme oder Verbesserungsvorschläge an, die solchen Einsätzen dann auch entsprechend. Gerade bei Page-Speed Insights und Single-Page-Apps kann es natürlich schon sein, dass da ein bisschen was zusammenkommt, in dem Sinne, dass die Single-Page-Apps brauchen, ja, JavaScript, um die Seiten zu laden und Page-Speed Insights besucht, die Seiten so zu haben oder empfiehlt die Seiten so zu haben, dass sie eigentlich direkt laden, dass sie nicht über JavaScript laden, sondern dass sie direkt laden. Und da kommt wahrscheinlich dieser Unterschied her. Was ich da vielleicht mal anschauen würde, sind zwei Sachen. Einerseits haben wir jetzt gerade neu auf dem englischen Webmaster-Blog ein Beitrag gemacht über Progressive Web Apps, über die Indexierung. Und da sind eigentlich sehr viele Teile, sind genauso relevant für andere Single-Page-Apps. Also nicht nur für Progressive Web Apps. Und andererseits habe ich vor etwa vielleicht anderthalb Monaten eine Präsentation bei einer Angular-Conference gegeben über die Indexierung, gerade von Angular Websites. Und da ist ein YouTube-Video davon vorhanden, welches ein paar Tipps gibt, auf die man vielleicht achten müsste. Grundsätzlich könnte ich mir aber vorstellen, dass gerade bei Page-Speed Insights das wahrscheinlich auch nicht angepasst wird auf Single-Page-Apps, sondern dass da weiterhin solche Verbesserungsvorschläge auch gezeigt werden, auch wenn sie jetzt gerade für Single-Page-Apps nicht hundertprozentig relevant sind. Aber ich würde das jetzt nicht als Zeichen nehmen, dass das Google zum Beispiel in der Suche solche Seiten benachteiligt oder dass die schlechter wegkommen, sondern das sind einfach Verbesserungsvorschläge, die unsere Systeme da zusammen gebracht haben. Wenn die für euch nicht relevant sind, könnt ihr die natürlich auch beenden. Okay, danke. Okay. Dann haben wir da als nächstes eine Frage zu e-Commerce-Seiten. Wir sind eine traditionelle e-Commerce-Seite mit vielen Bildern und basierend auf unsere Erfahrung mit den Ladezeiten und der Website haben wir jetzt Lazy-Loading für die Bilder implementiert aus technischer Sicht funktioniert, dass indem wir das Source Attribut von allen Bindern durch ein Platzhalterbild ersetzen und das eigentliche Bild mit Datasource-Referenzier. Sobald das Bild im Viewport gescored wird, wird das entsprechend eingetauscht. Was müsste man da quasi machen, damit die Bilder dann trotzdem noch indexiert werden? Was bei uns da wahrscheinlich passiert, ist, dass wir diese Seiten renderen auf unserer Seite mit Googlebot und wir schauen wahrscheinlich einfach den oberen Teil der Seite an und wenn durch das Rendern diese Bilder ausgetauscht werden durch die entsprechenden richtigen Bilder, dann könnten wir die eigentlich indexieren, dann sollten wir die auch in der Bildersuche normal bringen können. Wenn hingegen diese Bilder erst geladen werden, wenn jetzt weiter nach unten gescored werden zum Beispiel, dann kann es durchaus sein, dass wir nie diesen Bildverweis da sehen und so könnte es theoretisch sein, dass wir diese Bilder oder die, die jetzt so quasi nicht nachgeladen sind für Googlebot, auch in der Bildersuche nicht sauber bringen können. Da gibt es vielleicht zwei Hauptvarianten, die man da machen könnte. Einerseits kann man das so machen, dass man die Bilder auch per Link einbindet. Das heißt, dass man zum Beispiel beim Lazy Loading zwar einfach das leere Platzhalterbild zeigt, aber dann auch ein Link auf die Bildartei direkt da einbaut. So können wir dann entsprechend auf diese Bilder trotzdem in der Bildersuche bringen. Andererseits könnte man das natürlich so machen, dass die wichtigsten Bilder auf der Seite trotzdem normal geladen werden. Das heißt, wenn ich jetzt eine Kategorienseite habe und das sind hunderte Produkte, dann macht es da vielleicht Sinn, dass man die per Lazy Loading einbindet. Wenn ich entgegen auf einer einzelnen Produkte seite bin, dann macht es wahrscheinlich eher Sinn, dass wir die Bilder direkt auch haben, beziehungsweise dann wird es wahrscheinlich auch so sein, dass wir das Bild beim Render direkt von Anfang an schon sehen. Und so zwischen diesen beiden Varianten entweder, dass es quasi verlinkt wird oder anderseits so, dass man unterscheidet zwischen den wichtigsten Bildern auf der Seite und den, sag ich mal, sekundären Bildern auf der Seite, sollte das eigentlich einigermaßen klappen. Wir haben gute redaktionelle Artikel, welche wir auf zwei unterschiedlichen URLs veröffentlichen. Einer redaktionellen Webseite ohne Produkte und einer e-Commerce-Webseite mit Produkten können kanonische URLs mit unterschiedlichen Domains verwendet werden beziehungsweise ist die sinnvoll und falls nein, wie sollte man das sonst machen? Ja, man kann mit dem Rail Canonical so arbeiten. Man kann problemlos, wenn das die gleichen Inhalte sind auf unterschiedlichen Websites mit dem Rail Canonical sagen, dass es die Version, die ich so indexiert haben möchte und so versuchen wir dann auch die Signale entsprechend weiterzugeben, dass wir die Version dann auch sauber indexieren. Das kann sein, dass das nicht immer, immer klappt beziehungsweise wenn ich mit einer Side-Up-Frage frage, dann kann es sein, dass wir dann trotzdem die anderen noch zeigen. Einfach, weil wir wissen, du suchst gezielt nach diesen URLs, wir wissen zwar, dass eigentlich sind die Inhalte und deinem anderen URL indexiert, aber wenn man gezielt danach sucht, dann zeigen wir die Halt, weil wir denken, dass das möchte ich benutze. Aber grundsätzlich lässt sich das problemlos machen mit Rail Canonical über verschiedene Domains, über verschiedene Arten von Webseiten hinweg zu arbeiten. Werdet Google Accordions und Tabbing Navigation als Hidden-Content an, sprich ist dies negativ. Wie sieht es aus, wenn ich mit der Class Hidden, oder XS, von Bootstrap arbeite und damit Tabelle bei Mobile Devices verstecke, für Desktop Devices aber Anzeige. Grundsätzlich ist es so, dass wir stellen ja vielleicht mal längerfristig um auf ein Mobile First Indexing und da wird das vielleicht ein bisschen anders sein. Bei Desktop ist das aber so, dass wenn Inhalte nicht sichtbar sind beim Laden der Seite, dann nehmen wir an, dass sie nicht die primären Elemente sind einer Seite und dann kann es sein, dass wir in der Suche die ein bisschen abwerten. Wir indexieren die dann trotzdem noch, wenn man gezielt danach sucht, zeigen wir die trotzdem an, aber wir denken, die sind wahrscheinlich nicht das Wichtigste auf dieser Seite. Für Navigation ist das überhaupt kein Problem. Meistens sucht man ja nicht nach dem Menu, sondern nach den Inhalten auf den Seiten. Für die Navigation verwenden wir diese links dann trotzdem noch weiter. Wenn das Inhalte sind, die zum Beispiel beim Laden der Seite von Anfang an nicht sichtbar sind, dann eben wie gesagt, denken wir, das sind vielleicht nicht die primären Inhalte. Auf Mobile sieht das ein bisschen anders aus, hauptsächlich dadurch, dass man auf Mobile einfach viel weniger Platz zur Verfügung hat und dass man dann vielleicht ein bisschen kreativer arbeiten muss mit Accordions, mit verschiedenen Möglichkeiten, die Inhalte aufzuklappen und da ist es im Moment so, dass wir denken, dass wir die Inhalte trotzdem normal voll zählen werden. Aber ich vermute, dass, da versuchen wir da noch durch unsere Experimente erst mal festzustellen, genau wie wir das machen können am besten, wie das am besten für den Benutzer funktioniert und wie wir das Webmaster entsprechend auch erklären müssen, damit sie das richtige machen. Zwei Fragen zu Intrusive Interstitials, dies bezüglich Veränderungen 2017. Wenn ein Intrusive Interstitial Ad von Google erkannt wird, verliert nur die spezielle Seite oder die ganze Website im Ranking. Im Moment ist geplant, dass das nur bezogen auf die Seite ist und dass wir dann einfach denken, diese Seite ist wahrscheinlich nicht mobile-friendly. Also mit Seite meine ich die einzige URL, wo man jetzt ist, also nicht die ganze Website, sondern einfach diese einzelnen Adressen, die man aufmacht. Das heißt, wenn man das auf unterschiedlichen Seiten unterschiedlich machen möchte, dann muss man damit einfach rechnen, dass je nachdem werden diese Seiten dann unterschiedlich gehandelt. Wenn du Publisher wärst und die Refinanzierung teilweise Überwerbung stattfindet, wie risikorbereit wärst du, wenn künftig ein Verbenerkunde an Intrusive Ads festhalten will, ja, schwierig zu sagen. Ich denke, da muss man immer ein bisschen abwägen, was am besten, da allgemein ist für die Webseite, für die Benutzer natürlich auch. Ich denke, als Benutzer, wenn ich jetzt nicht aus Publisher sich das anschaue, sondern als Benutzer sich, dann sind diese Interstitials wirklich ärgerlich für mich auf mobile und sind oft auch ein Grund, dass sich dein Websites wirklich aktiver auch vermeidet. Und wenn man natürlich als Publisher das Gefühl hat, dass andere Benutzer vielleicht ähnlich denken, dass sie dann auch weniger oft auf diese Website gehen, dann hat man vielleicht kurzfristig ein Vorteil von diesen Interstitials, in dem das Benutzer auf die Werbung klicken. Langfristig ist es aber so, dass das Benutzer sind, die gar nicht eure Inhalte mehr sehen, die entsprechend gar keinen Grund mehr haben, zu euch zurückzugehen, weil sie sehen ja eure Inhalte gar nicht von Anfang an. Sie können sie ja gar nicht anschauen, wenn sie von Anfang an mit einem Interstitial konfrontiert werden, welches die Benutzer voran das hinsteckt. Das heißt, wenn man längerfristig denkt, dann macht es wahrscheinlich eher Sinn zu überlegen, ja, wie kann ich meine Benutzer binden? Wie kann ich denen zeigen, dass ich wirklich gute Inhalte habe, die sie weiter empfehlen würden, wo sie auch dann selber quasi wieder zurückkommen würden? Und wie kann ich das natürlich mit der Finanzierung irgendwie vereinbaren, sodass ich trotzdem genug kriege, um meine Website sauber und gut zu betreiben? Aber ich denke, wenn man die Benutzer schon von Anfang an abblockt und sagt, ja, geht doch lieber woanders hin, dann ist es natürlich nicht so längerfristiges Denken, wie wenn man, wenn man irgendwie mit dem Benutzer etwas, sagen wir mal, positives zusammen erst mal macht. Ich habe bisher umlauten in URL-Familien, wenn ich nun bei Keyword Planner Keyword Checker habe ich verschiedene Suchvolumen. Wenn man zum Beispiel Flüge mit UE und Flüge mit Umlaut bei Suche-Eingebe, hat man nicht den gleichen Ergebnis. Warum? Was ist auch eine gute Frage. Grundsätzlich ist es so, dass wir versuchen natürlich, die Suchbegriffe entsprechend zu verstehen. Wir schauen aber auch die einzelnen Wörter an, wenn die anders geschrieben werden, also mit UE und einmal mit Umlaut zum Beispiel, dann nehmen unsere Systeme an, dass das vielleicht auch unterschiedliche Wörter sind, die auch unterschiedliche Bedeutungen haben. Im Laufe der Zeit lernen die oft, dass das vielleicht synonyme sind, dass es eigentlich das gleiche Wort ist oder fast das gleiche Wort ist und dass sie ähnlich das zusammenklappen können. Aber das sind Sachen, die verändern sich auch im Laufe der Zeit und von dem her würde ich für einfach weiterhin vielleicht offen sein und überlegen, ja, wie Suchen benutze und was müsste ich machen, damit meine Seiten da auch gefunden werden. Bezüglich Umlauten in der URL selber würde ich einfach bedenken, dass der Einsatz von Keywords in der URL ist wahrscheinlich nicht das Wichtigste, was ihr machen könnt. Es wird nicht so sein, dass wenn ihr einfach ein Umlaut in der URL hinein nehmt, dass automatisch diese Seiten für diese Wörter im Ranking höher erscheinen, sondern für uns sind die Keywords in der URL ein sehr, sehr, sehr kleiner Anfaktor. Das heißt, ich würde da jetzt nicht die URLs verändern, sodass sie diese Keywords extra drin haben. Ich denke für Benutzern macht es manchmal Sinn, dass man URLs hat, die verständlich sind. Aber für die Suche würde ich jetzt nicht gezielt einfach nur die Keywords in die URLs hineinstecken. Ich hätte eine Frage bezüglich der Strukturierung von Content. Ist es besser ein Thema erschöpfend auf einer Seite zu behandeln oder diesen auf mehreren Artikeln und Seiten zu splitten? Beispiel Thema Einführung in Android. Grundsätzlich ist das etwas, was ihr eigentlich herausfinden müsst, was am besten für euch funktioniert. Aus der Suche-Seite ist es so, dass beide Arten von Websites eigentlich einen Grund haben, da zu sein und entsprechend auch in der Suche repräsentiert werden, solche, die eher längere Inhalte haben und solche, die vielleicht mehrere unterschiedliche Inhalte haben, die insgesamt dann auch wieder mehr zusammen eingehen. Manchmal macht es Sinn, dass man die Themen vielleicht ein bisschen begrenzt, dass man einfach gezielt eine Seite hat zu einem Thema. Dann weiß man natürlich auch ein bisschen mehr, was Benutzer wirklich interessiert, weil man sieht, man dann, ah, die gehen gezielt auf diese Seite mit, ich weiß nicht, Benutzer-Oberfläche allgemein oder Einstellungen oder wie man mit der Play Store umgeht ein. Und so kann man natürlich auch ein bisschen von den Benutzern lernen und merken, ja, ich müsste vielleicht mehr Inhalte in diese Richtung haben oder mehr Inhalte in diese Richtung haben. Für die Suche hingegen können natürlich beide Varianten relevant sein, entweder die längeren Inhalte oder auch die kürzeren Inhalte. Und das ist eher etwas, was ich mit eurem Benutzern halt anschauen würde. Man kann natürlich auch AB-Tests machen und so ein bisschen herausprobieren, herauspuzzeln, welche Art von Inhalten für euch relevant ist und was bei euch am besten funktioniert. Eine bestehende Domain verfügt über Backlicks, deren Inhalt für die neue Webseiten nicht mehr relevant ist. Sollte man die neue Domain nutzen oder besser die ältere Domain nutzen, die irrelevanten und die irrelevanten Backlink-Ziele per 410 entwerten, schwierig zu sagen. Manchmal hat ein Domain so eine komplizierte Geschichte dahinter, dass es sich vielleicht nicht lohnt, das zu versuchen, irgendwie aufzuräumen. Oft ist es so, dass man das trotzdem einigermaßen aufräumen kann und weiterarbeiten kann. Aber manchmal ist es halt wirklich so, dass da so viel Komisches getrieben worden ist in der Vergangenheit, dass das schwierig ist, das erstmal alles wieder aufzuräumen. Das heißt, wenn jemand nach dem Domain sucht und das kommt, ich weiß nicht, alle möglichen irrelevanten Seiten erstmal in den Suchergebnissen, dann sieht das für Benutzern vielleicht ein bisschen komisch aus, zum Beispiel. Von dem her kann ich jetzt nicht sagen, ob man jetzt einen neuen Domain benutzen soll oder einen älteren Weiterverwenden soll. Ich denke, wenn man einen älteren Weiterverwendet, würde ich auf jeden Fall das Ganze ein bisschen recherchieren und überlegen, was nehme ich in Kauf, wenn ich jetzt auf den älteren Domainnamen setze und kann ich damit leben. Ist das für mich okay so? Was muss ich vielleicht aufräumen? Was kann ich überhaupt aufräumen? Wie viel Zeit muss ich ins Aufräumen investieren bezüglich oder wie viel Zeit müsste ich in das Aufbauen von einem neuen Domain vielleicht investieren und wo macht das am meisten Sinn? Bezüglich Backlinks und Backlinks quasi entwerten entweder über den Disavow-Tool zum Beispiel oder in dem, dass man die Backlink-Ziele quasi aus dem Index fallen lässt mit 404 oder 410. Das sind beides Varianten, die man machen kann. Wenn man die Backlink-Ziele mit einem 404 oder 410 aus dem Index entfallen lässt, dann lassen wir diese Links auch entsprechend fahren. Dann sind sie zwar noch auf dem Internet, aber wir verwenden die nicht. Das funktioniert allerdings nur, wenn die Ziele wirklich auf spezielle Unterseiten waren. Wenn diese Links auf die Homepage alle gehen, dann kann man natürlich nicht auf der Homepage 410 zurückgeben oder 404 zurückgeben, weil dann kommen die Benutzer auch nicht mehr auf die Webseite hinein. Bewertet Google die Validierung von SSL-Zertifikaten. Ich möchte unsere neue Webseite über HTTPS ausliefern, welcher Domainvalidierte, Organisationsvalidierte und erweiterte, validierte SSL-Zertifikate oder werden die unterschiedlich bewertet? Nein, wir entscheiden dann nicht, oder unterscheiden dann nicht zwischen den verschiedenen Arten von Zertifikaten. Wenn dieses Zertifikat in einem modernen Browser funktioniert, dann ist das aus unserer Sicht okay. Wir haben eine Produktwebsite vor einiger Zeit auf Englisch gelanscht. Nach und nach haben wir die Inhalte in weitere Sprachen übersetzt und veröffentlicht. Die Texte werden per Script ausgetauscht und sind alle über, auch über, separate Links erreichbar. Für die Hreflangtags sind auch immer gesetzt. Xdefault ist aber auf Englisch geblieben. Als die fünfte Sprache übersetzt und released war, haben wir in der internationalen Ausrichtung das Land auf nicht gelistet gesetzt. In den sonst englischen Content Keywords haben wir nun aber die Worte wie C und und und der spanische. Ist das bedenklich? Und wenn ja, wie kann man dies aus dieser Liste wieder entfernen? Ich würde mich nicht auf die Content Keywords quasi konzentrieren. Das sind an und für sich alle Inhalte, die wir von dieser Webseite durch Crawling schon gefunden haben. Und da sind verschiedene Sprachvarianten dabei. Das sind vielleicht auch Begriffe dabei, die für euch nicht so relevant sind. Nur weil sie da gelistet werden, heißt nicht, dass sie aus unserer Sicht relevant sind, sondern es heißt eigentlich nur, wir haben sie gefunden auf eurer Webseite. Und das ist ja eigentlich auch ein gutes Zeichen. Wir werden wahrscheinlich im Laufe der Zeit die Content Keywords Funktion aus Search Console entfernen, einfach weil das zu viele entsprechend auch verwirrt hat. Bezüglich der Austauschen der Texte per Script, wenn das per JavaScript gemacht wird, würde ich einfach wirklich kontrollieren, dass das sauber von Googlebot erkannt wird. Das heißt, dass Googlebot die verschiedenen Sprachversionen einzeln aufrufen kann und die Sprachversionen auch einzeln auch sehen kann. Was zum Beispiel problematisch wäre, ist, wenn Googlebot, natürlich wenn Googlebot aus Amerika kommt, immer die englische Version sieht, auch wenn Googlebot jetzt mal die spanische oder die französische Version ansteuert. Das wäre aus unserer Sicht problematisch, in dem Sinne, dass wir dann einfach nur die englische Version indexieren würden und die anderen gar nicht sehen würden, weil die werden uns ja dann gar nicht gezeigt. Wenn hingegen per Script, dass quasi serverseitig einfach ausgetauscht wird über eine separate URL, dann sieht ihr relativ schnell in Fetch as Google in Search Console, dass die verschiedenen Sprachversionen aufrufbar sind und das sollte dann eigentlich auch schon klappen. Bezüglich X-Default könnt ihr das setzen wie ihr wollt. Ihr könnt Englisch nehmen, ihr könnt Deutsch nehmen. Das ist euch ganz überlassen. Wir binden Produktbeschreibungen anderer Anbieter auf unserer Seite ein, da wir aber nicht mit diesen, sondern nur mit unseren eigenen Inhalten ranken wollen. Wir den Kunden aber trotzdem zeigen müssen, laden wir diese per Ajax nach, der HTTP-Header, der Antwort enthält X-Robots No Index und die Inhalte sind im cached-Seite auch schon nicht mehr zu finden. Leider findet man die Inhalte aber noch, wenn man nach den Textinhalten sucht. Was kann man da quasi machen? Vielleicht vorweg, der HTTP-Header X-Robots No Index funktioniert nur für die HTTP-Seite, die indexiert wird. Das heißt, wenn das Inhalte sind, die eingebunden werden in einer Seite, sei das per Ajax oder wenn das zum Beispiel Bilder sind, die eingebunden sind oder iFrames, dann wird das nicht verwendet. Das heißt, das bringt in euren Fall wahrscheinlich nichts. Im cached ist es so, dass wir den JavaScript nicht ausgeführt haben. Das heißt, die gcached-Seite wird der normalen HTML-Seite entsprechend, wo dann diese Inhalte vielleicht jetzt nicht dabei sind. Was man machen könnte, in einem solchen Fall, ist die Ajax-Gurals per robots.txt blockieren. Dann ist es so, dass Benutzer dieser Seite trotzdem noch laden können. Die Ajax-Gurals können trotzdem noch nachgeladen werden im Browser. Für Googlebot wird es aber so sein, dass wir diese Ajax-Gurals nicht sehen können. Und dementsprechend, wenn wir diese Ajax-Responses gar nicht sehen können, können wir die auch nicht indexieren. Und so sollten die dann auch beim Auffinden jetzt nicht mehr vorhanden sein. In den meisten Fällen würde ich vielleicht aber auch sagen, dass das wenig ausmacht. Wenn das jetzt zum Beispiel generische Produktebeschreibungen sind, die ihr einfach auch noch dazu nehmt, dann wird es meistens so sein, dass eure Seiten nicht für diese Produktebeschreibung ein erster Steller ranken, weil wir einfach verschiedene andere Seiten auch haben, die die gleichen Inhalte verwenden. Das beeinflusst eure Seite, aber nicht negativ bezüglich der anderen Inhalte, die auf eurer Seite sind. Das heißt, wenn ihr einfach die generischen Produktebeschreibungen auch dabei habt, dann sollte das eigentlich nicht einen negativen Einfluss auf dem Rest der Website haben. Das heißt, vielleicht könnt ihr euch das ganze komplizierte mit dem Ajax und Robots Text und so sparen und einfach die Inhalte direkt so einbinden, ohne dass es groß problematisch ist. Manchmal gibt es natürlich auch vielleicht Lizenzgründe oder Policygründe, warum man sagt, gut, wir dürfen diese Sachen nicht indexiert haben. Das ist natürlich anders. Ich habe eine Frage kurz im Forum gepostet. Ein Kunde von mir hat im Basistemplate Bewertungen per JSON-LD somatisch ausgezeichnet. Die Bewertung bezieht sich auf die gesamte Domäne und nicht auf ein einzelnes Produkt. Ich denke mehr oder weniger ist das okay, oder müsste man das ändern. Aus unserer Sicht ist es so, dass wir Bewertungen pro Produkt sehen möchten. Das heißt, wir möchten wissen, dass diese Bewertung sich wirklich auf das Produkt bezieht und dementsprechend wäre es wahrscheinlich nicht sinnvoll, dass man einfach die allgemeine Firmenbewertung als Produktbewertung markiert auf den Seiten. Das heißt, was ich da vielleicht machen würde, ist einfach den JSON-LD Markup rausnehmen, die Structured Data für diese Firmenbewertungen rausnehmen. Ihr könnt die Bewertungen trotzdem auf euren Seiten belassen, so dass sie sichtbar sind für Benutzer, weil für Benutzer ist das manchmal auch sehr hilfreich. Ich würde es einfach nicht als Structured Data markieren für JSON-LDs. Und wenn ihr vielleicht später dann die einzelnen Produkte bewerten könnt, dann wäre das vielleicht etwas, was man markieren könnte, aber nicht eine Firmenallgemeine Bewertung so markieren. Wenn man eine Seite A, B und C hat, welche 1 zu 1 sind gleichen Inhalt haben, die ist aber technisch wegen einem Filter erforderlich, ist, wie ist es am besten, duptliche Content zu vermeiden? Variante A auf Index Follow lassen, B und C ebenfalls auf Index, aber mit Canonical auf A oder Seite A mit Index Follow und B und C einfach auf No Index Follow. Man kann beides mit dem Canonical oder mit dem No Index arbeiten. Das sind beides Möglichkeiten, die man verwenden kann. Was einfach passiert mit dem No Index, ist, dass wir links auf diese Seite entsprechend verlieren, bzw. wir wissen dann nicht, wie das zusammengeklappt werden soll. Mit einem Canonical sagt ihr uns, diese beiden Seiten sind equivalent. Ihr habt diese einfach lieber. Das heißt, wenn jemand auf die andere Seite verweist, per Link zum Beispiel oder wenn wir andere Signale haben auf diese Seite, können wir das zusammenklappen und dann können wir eine stärkere Seite machen. Wenn hingegen die anderen Seiten einfach auf No Index gesetzt werden oder per Robots Text blockiert werden, dann wissen wir nicht, was wir damit machen sollen. Wir können dann schon intern die Links weitergeben, wenn dann noch ein Follow auf der Webseite ist, aber wir können die dann nicht zusammenklappen und sagen, das ist jetzt eine starke Seite zu diesem Thema. Das heißt, wenn das wirklich Duplicate Content ist, würde ich eher mit dem Canonical arbeiten. Wenn das einfach Inhalte sind, die ihr nicht indexiert haben möchtet, dann könnt ihr vielleicht mit dem No Index arbeiten, dass es anfühlt sich euch da überlassen. Ich habe eine Frage in Bezug auf die sinnvolle Verwendung der Funktion URL entfernen in Search Console. Bei einem Redesign wird immer empfohlen, dass alle wichtigen URLs, sofern sich die URL Struktur geändert hat, mittels 301 weitergeleitet werden bei Websites, die aber aus vielen Tausenden Seiten besteht. Ist das zum Teil sehr zeitaufwendig, alle URLs weiterzuleiten? Wenn ich bei Google Analytics schaue und einfach die wichtigsten URLs weiterleite, reicht das quasi oder muss ich wirklich alle weiterleiten? Aus unserer Sicht macht das wirklich Sinn, so weit wie möglich alle weiterzuleiten. Manchmal kann man das ja auch mit einem Muster irgendwie zusammenklappen. Ich würde wirklich schauen, dass so weit wie möglich wirklich alles weitergeleitet wird. Wenn man das gar nicht machen kann, wenn man das zum Beispiel alles von Hand weiterleiten muss und man nicht immer eine equivalente Seite hat, dann muss man halt damit leben. Dann ist es halt so, dass man sich enger auf die wichtigsten Seiten konzentrieren muss, dass man sagt, das sind wirklich die Seiten, die weitergeleitet werden müssen. Und die anderen, was da wahrscheinlich passiert, ist die alten fallen erst mal raus aus dem Index und es geht eine gewisse Zeit bis die neuen dann wieder dazukommen. Was ich da einfach machen würde, ist diesen Vorgang vielleicht natürlich durchlaufen zu lassen. Einfach auf der Webseite schauen, dass die 404 Seite wirklich auch freundlich ist, dass Benutzer, wenn sie auf die 404 Seite kommen, irgendwie weiterkommen und zum Rest der Webseite finden. Die URL-Entfernungsfunktion braucht ja in so einem Fall eigentlich nicht. Die URL-Entfernungsfunktion ist nur dafür da, dass Außensuchergebnissen, was die gezeigt werden, dass da diese URLs entfernt werden und nicht dargestellt werden. Das heißt, mit der Indexierung hat das gar nichts zu tun. Das verändert die Indexierung dieser URLs nicht, das beschleunigt nicht die Veränderung da, sondern es ist wirklich nur, dass ihr sagt, diese Inhalte habe ich entfernt und ich möchte es so schnell wie möglich, dass sie in der Suche auch entfernt werden. Und in der Zeit, in der sie aus der Suche entfernt werden, kann Google natürlich dann durch Crawling und Indexing das entsprechend verarbeiten und dann auch aus dem Index fallen lassen. Aber gerade bei Redesigns, eben wie gesagt, würde ich möglichst alle URLs weiterleiten, sofern das irgendwie machbar ist. Eine, da haben wir die Single-Page-Up-Frage. Wir haben eine .com und eine .de-Webseite. Die .com leitet halt 301s auf .de weiter. Seit einiger Zeit taucht aber nun die .com wieder auf. Obwohl wir einen 301s da haben, was kann man da machen? Ich habe das mal angeschaut mit dem Team und ich habe im Moment keine beste, gute Antwort da. Aus meiner Sicht ist das etwas, was wir ein bisschen besser behandeln müssten. Von dem her ist es nicht so, dass ihr gezielt etwas anders machen müsst, sondern dass wir das vielleicht ein bisschen besser anschauen müssen auf unserer Seite und dass ein bisschen besser entsprechend auch berücksichtigen müssen, was ihr auf eurer Seite habt. Grundsätzlich ist es aber so, dass dieser Wechsel von .com oder .de zum Beispiel in diesem Fall kein Einfluss auf das Ranking der Website hat, sondern eigentlich nur ein Einfluss auf die URL hat die dargestellt wert für den Benutzer in den Suche ergeben ist. In zahlreichen unserer Länder stehen wir seit dem 11. Oktober eine drastische Abnahme von Kilowide, welche pro Tag heruntergeladen werden. Auch scheint sich die Zahl der pro Tag gecrawlten Seiten seit diesem Zeitpunkt kontinuierlich zu senken. Kann ein CDN Switch hier etwas mit zu tun haben? Ja, könnte sein. Was im Grunde genommen gibt es da verschiedene Faktoren, die zusammenkommen bezüglich dem Crawling auf unserer Seite. Was auf unserer Seite passiert, ist, dass unsere Systeme automatisch versuchen, sich anzupassen auf euren Server und die Kapazitäten, die die euer Server hat. Und so, wenn wir jetzt größere Veränderungen sehen, bezüglich des Hostings, wenn ihr zum Beispiel auf ein CDN wechselt, wenn ihr von einem CDN auf einen anderen wechselt, dann kann es sein, dass unsere Algorithmen zunächst einmal sagen, oh, da hat sich etwas größeres verändert, gehen wir erst mal auf Nummer sicher und crawlen weniger. Und im Laufe der Zeit, wenn wir sehen, dass der Server wirklich diese Leistung bringen kann, wenn wir sehen, dass die Antworten relativ schnell kommen, dann können wir diese Geschwindigkeit wieder ein bisschen hochsteuern. Das passiert natürlich in beide Richtungen. Wenn wir sehen, dass wir zu viel crawlen, dass so, dass der Server langsam wird, dass die Antworten später kommen, dass vielleicht Serverfehler häufiger kommen, dann schalten wir ein bisschen zurück und crawlen weniger. Wenn wir sehen, dass der Server die Leistung gut verträgt und wenn wir merken, dass wir mehr crawlen würden, wenn wir die Möglichkeit hätten, dann versuchen wir dann entsprechend auch mehr zu crawlen. Gerade bei einem CDN wechseln eben ist das schon so, dass unsere Systeme erst mal auf Nummer sicher gehen und weniger crawlen. Was man machen kann, ist im Hilfecenter ist ein Link für Fehler von Googlebot Crawling zu melden, weiß ich jetzt nicht genau, wie das heißt auf Deutsch. Da im Hilfecenter, das ist auf der Seite, wo man die Crawl-Reinstellung machen kann im Hilfecenter, dass ein Link zu einem Formular, welches sie ausfüllen könnt, das geht direkt an das Googlebot Team, welches dann die Crawl Geschwindigkeiten ein bisschen auch steuern kann. Und so wenn ihr zum Beispiel sieht, dass Googlebot viel weniger crawlt, dann könnt ihr da kurz das Formular einreichen und sagen, hey, vielleicht habt ihr irgendwas falsch eingeschätzt oder vielleicht habt ihr nicht gemerkt, dass unser CDN jetzt viel besser ist als vorher, könnt ihr vielleicht mit dem Crawlen oder wenn es etwas gibt, was ihr crawlen wollt, könnt ihr auch ein bisschen mehr crawlen. Und in der Regel wird das innerhalb von paar Tagen bearbeitet. Wichtig ist vielleicht da, das bezieht sich nur auf das Crawling, nicht auf die Indexierung, nicht auf das Ranking, das heißt nur, weil etwas mehr gecrawled wird, wird es auch nicht höher in den Rankings dargestellt, wenn ihr Ranking Probleme habt, Ranking Schwierigkeiten, dann kann das Googlebot Team da eigentlich nichts waren. Wie bewertet Google das Laden von Bildern, die nicht auf der Seite angezeigt werden? Ich lese in letzten Tagen dauernd von Bootstrap hidden, Stich XS, welche Display nun für Viewports unter 768 Pixel hat. Auf mancher Website sehe ich, dass in Verbindung mit diesen CSS-Regeln zwei unterschiedliche Bilder geladen werden. Das geht doch viel besser mit dem Picture Element. Ja, man kann natürlich mit dem Picture Element arbeiten. Wichtig, ich denke gerade bei Bildern ist es, dass wir einfach erkennen können, dass das Bild eingebunden wird auf dieser Seite. Das heißt, wenn zum Beispiel ein Link auf ein Bilddatei da ist, dann ist es aus unserer Sicht schon mal ein Zeichen, dass wir das für die Bildersuche irgendwie kombiniert verwenden können. Wenn wir hingegen gar nichts als Verweis auf dieses Bild sehen, dann kann es sein, dass wir dieses Bild in der Bildersuche nicht bringen können. Bei vielen Websites, bei vielen Bildern ist das vielleicht auch egal. Vielleicht sind das Bilder, die nur für das Layout verwendet werden, die gar nicht in der Bildersuche erscheinen müssen und da müsst ihr euch dann vielleicht auch gar nicht den Kopf zerbrechen, ob das jetzt so oder so oder so eingebunden werden soll. Sondern das sind dann vielleicht einfach Sachen, die wir für die Bildersuche nicht verwenden müssen. Die Bildersuche hat an und für sich keinen Einfluss auf die normale Websuche. Das heißt, nur weil wir die Bilder nicht erkennen auf einer Seite, heißt nicht, dass wir diese Seite weniger in der normalen Websuche zeigen würden. Für eine Kundenseite haben wir nun M-Pensionen für die News Artikel erstellt und die Indexierung läuft bestens auf die ersten Besucher, würden schon registriert. Ist in Social Counsel künftig eine Auswertung des M-Traffics geplant in Analytics, ist aktuell nur die aufgerufenen Unterseite sichtbar und eine Einschätzung der verwendeten Keywords nur grob möglich, bezüglich einschätzbar. Ja, wir versuchen da das ein bisschen auszubauen in Search Analytics, dass wir das ein bisschen besser zeigen können, was in den meisten Fällen aber gemacht werden kann. Es ist ja so, dass in vielen Fällen ist es so, dass die M-Version einer Seite einen speziellen URL-Muster verwendet. Das heißt, vielleicht ein spezielles Subdomain oder ein Fahrt oder ein Parameter in der URL dabei. Und ihr könnt in Search Console, könnt ihr einen Filter setzen für die Seite. Das heißt, ihr könnt einen Filter setzen, um für diesen Teil von der URL zu suchen und so gezielt dann nur diese AMP-Seiten darstellen lassen mit den Impressions und Clicks. Das sieht ihr dann auch die Keywords, die zu Impressions geführt haben. Und so könnt ihr das ein bisschen besser einschätzen, wie das funktioniert im Moment. Meines Wissens ist gerade mit AMP in den normalen Suchergebnissen ist das im Moment noch ein bisschen in Bearbeitung und noch nicht vollständig überall ausgerollt. Ich weiß nicht, was da die kurzfristigen Pläne sind, längerfristig wird das natürlich schon überall er sichtbar sein. Wir haben für Desktop und Mobile zwei getrennte Webseiten mit eigener URLs, aber ähnlichen Inhalt. Die jeweilige Desktop-Website zeigt ein Alternatag auf die mobile Seite, die dazu gehörige Mobile Seite hat ein Canonical auf die Desktop-Seite. Seit dem letzten Penguin Update haben wir folgende Probleme. Die Desktop-Seite wängt stetig gut. Die mobilen Seite schwankt. Wenn die mobilen Seite gut rankt, dann mit der mobilen Domain. Gelegentlich verschwindet die mobilen Seite jedoch komplett aus dem Index und die Desktop-Seite wird natürlich schlecht, weil nicht mobile optimisiert, gerankt. Machen wir bei unserem Setup etwas falsch beziehungsweise wohl und kann das liegen. Schwierig zu sagen, das klingt an erster Linie nach einem technischen Problem, dass wir entweder diese Links zwischen diesen beiden Seiten nicht sauber erkennen können. Das kann unter Umständen sein, weil wir vom Crawling oder Indexing her diese Seiten nicht sauber sehen. Ich würde in einem solchen Fall vielleicht im Hilferforum nachfragen und schauen, ob das vielleicht jemand mal anschauen kann und überlegen kann, ob da etwas technisch gesehen falsch eingebunden ist. Grundsätzlich sollte das jetzt nicht mit dem Penguin Update zusammenhängen. Das sollte nicht von normalen Qualities oder Ranking Updates irgendwie zusammenhängen, sondern wenn die mobilen Seite ganz verschwindet aus den Suchergebnissen und nicht mehr da verbunden wird, dann ist das in erster Linie eher ein technisches Problem. Würde ich jetzt mal schätzen. Falls ich eine separate Mobile Website unter m.domain.com betreibe und die gegenseitige Anverweis per Canonical Alternate vorhanden ist, benötigt dann dennoch bei Mehrsprachigkeit und Mobile First Index hreflang für die Desktop, wie auch für die mobile Website. Oder reicht es aus, wenn ich hreflang für die Desktop-Variante implementiert habe. Das ist eine gute Frage. Da habe ich im Moment noch keine perfekte Antwort. Bisher haben wir natürlich immer gesagt, es reicht aus, wenn ihr die Desktop-Seiten verlinkt habt, weil das ist ja die Canonical Version. In Zukunft, wenn wir auf die mobile Version als Canonical setzen, dann kann es natürlich sein, dass wir eher den hreflang bei der mobilen Seite suchen. Ich denke, wenn man auf Nummer sicher gehen möchte und weiß, dass man jetzt wenig Zeit hat, da irgendwelche Veränderungen zu machen, dann würde ich den hreflang einfach auf beide Varianten nehmen. Das wird auf jeden Fall funktionieren. Das wird auf jeden Fall, sollte das keine Probleme verursachen. Wir werden aber auch da schauen, dass wir da ein bisschen genauere Hinweise geben können, wie man das am besten macht. Wir müssen das selber noch ein bisschen weiter experimentieren und schauen, was wirklich am besten auch funktioniert, wo es einerseits für die Benutzer sauber funktioniert, wo andererseits es auch für die Webmasse keine größeren Umstellungen mit sich bringt. Idealer Weise würde ich sagen, wäre es toll, wenn wir einfach die bestehenden Einstellungen und Varianten so weiter behalten könnten. Ich weiß nicht, ob das wirklich so machbar sein wird. Wie kann ich herausfinden, unter welchen E-Mail-Adresse der Hauptinhalter einer Domain in einer Google Search Console läuft, wenn ich nur Ansprechpartner habe, die anscheinend delegierte Inhalter sind? Einerseits als Externer lässt sich das nicht herausfinden. Das heißt, ich kann nicht für irgendein beliebigen Domain sagen, wer ist jetzt der Registrier für Inhaber in Search Console. Ich möchte denen jetzt ein E-Mail schicken und irgendein Vorschlag unterlegen. Das kann man als Externer nicht machen. Wenn das jetzt deine eigene Website ist, kann man diese Website einfach noch mal neu verifizieren. Und so wenn man jetzt neu als Hauptinhalter dabei ist, dann kann man die anderen Inhaber alle auch auflisten und so sieht man dann entsprechend auch, wer wie verifiziert ist. Das geht aber wie gesagt wirklich nur dann, wenn man diese Website selber auch verifizieren kann. Wichtig ist da vielleicht auch, dass bei Search Console ist es anders als in Analytics. In Search Console ist es so, dass keine Daten verloren gehen, wenn man jetzt mit einem neuen Konto verifiziert. Das heißt, wenn ich mal vergessen habe, welches Konto ich für die Verifizierung verwendet habe, dann kann ich einfach ein neues nehmen. Dann ist das eins zu eins eigentlich wieder so, wie es vorher war. Dann ist es nicht so, dass irgendwelche Daten verloren gegangen sind durch diese neue Verifizierung. Wir haben einige Hundert Firmen aus einer bestimmten Branche, die sich bei uns präsentieren. Wenn wir jetzt den Title Tag nicht statisch präsentieren, sondern den dort den Firmenamen aus der Datenbank herauslesen und auch die Description Tags, die jedem Unternehmen individualisieren, hilft uns erst beim Ranking. Ja, im Prinzip ist das natürlich schon eine gute Sache. Ich weiß jetzt nicht, welche Art von Website das ist, aber wenn ihr unterschiedliche Seiten habt für unterschiedliche Inhalte und ihr habt eine Datenbank, die dahinter steckt, die diese Inhalte zusammenstellt, dann würde ich auf jeden Fall schauen, dass Titel und Beschreibung entsprechend angepasst sind an die Inhalte. Das macht in erster Linie natürlich Sinn für den Benutzern, wenn in den Suchergebnissen der Titel auch sauber dargestellt werden kann. Wenn die Beschreibung wirklich auch zu den Inhalten passt, ist das eine gute Sache. Das ist weniger eine Frage dann bezüglich statisch oder dynamisch oder über die Datenbank oder nicht, sondern das sind eigentlich einfach Seiten, wo die Titel und die Beschreibungen und die Inhalte angepasst sind an dieses Thema. Das ist eigentlich immer eine gute Praxis. Okay, da ist noch eine lange Frage in Chat bezüglich Absprungrate. Nun ist es so, dass ich eine Seite habe, auf der die Benutzer Besucher eine Umrechnung vornehmen können. Jetzt habe ich zwei Varianten dieses Rechners entwickelt. Eine, die per JavaScript die Eingabe direkt umrechnet und eine Rechner, der erst nach dem Blick auf berechnen das Ergebnis ausgibt. Nun habe ich beide einmal getestet und die Absprungrate ist in die Höhe gesprungen. Bei der zweiten Variante wird die Seite ja neu geladen und somit nicht mehr direkt als Absprung gewertet, wenn ein Besucher die Seite wieder verlässt. Jetzt bin ich natürlich etwas paranoid, inwiefern ist das problematisch. Ich habe Angst, den modernen Rechner online zu lassen. Ich würde mir da jetzt keine großen Sorgen machen. Ich denke, das bezieht sich ja in erster Linie darauf, was jetzt in Analytics zusammengerechnet wird. Das heißt wie Analytics die Absprungrate bestimmt und da könnte man vielleicht auch das so machen, dass man diesen Rechnerknopf dann in Analytics entsprechend auch markiert, so dass man das ein bisschen genauer untersuchen kann, wie viele Leute jetzt wirklich auf meiner Seite kommen und wieviel führen meinen Rechner aus, beziehungsweise wieviel kommen auf meiner Seite und machen gar nichts, die entsprechend dann wirklich ein Absprung sehen. Aber das bezieht sich alles eher auf Analytics und nicht wirklich auf die Suche und von dem her ist das etwas, was du problemlos, dass man es selber testen kannst beziehungsweise anders auch markieren kannst auf den Seiten, so dass du das anders auch tracken kannst. Okay, weitere Fragen. Womit kann ich noch helfen? Nichts mehr. Ja, hallo John. Ja, hallo. Und zwar, wir haben eine alte Seite mit Inhalten auf eine neue Seite 301 weitergeleitet, nun ranked aber immer noch die alte Seite und die neue Seite taucht gar nicht auf. Woran kann das liegen? Schwierig zu sagen. Was auf unserer Seite da wahrscheinlich passiert ist, dass wir die alte Seite und die neue Seite verbinden und wir wissen, die gehören zweimal zusammen und besuchen aus diesen Satz von Seiten dann ein canonical aus, den wir darstellen können in der Suche und das ein redirect ist natürlich schon ein sehr starkes Signal für uns, ist aber nicht das einzige Signal, was wir verwenden. Wenn zum Beispiel intern immer noch auf die alte Seite verlinkt wird oder extern auf die Seite verlinkt wird oder mit Sidemaps auf die alte Seite verlinkt wird, dann sind das alles Sachen, die auch zusammenkommen können und so kann es sein, dass wir die alte Seite trotzdem in Suche ergebnissen zeigen. Vom Ranking her ist es eigentlich egal, wir tauschen dann einfach nur die URL aus. Vom Praktischen her, wenn ihr wirklich haben wollt, dass die neue Seite dargestellt wird in Suche ergebnissen, würde ich einfach schauen, dass wirklich alle Signale klar auf die neue Seite zeigen. Das heißt auch mit Royal Canonical arbeiten, die interne Verlinkung sauber anpassen, dass die wirklich auf die neue Seite zeigt, Sidemaps anschauen, dass das wirklich auch alles auf die neue Seite zeigt. Vielen Dank. Okay, weitere Fragen. Was gibt es noch? Ich hatte noch eine Frage gestellt. Ich hatte noch eine Frage gestellt vor drei Wochen. Da ging es um die domain gmx.de bzw. gmx.net. Wir hatten ja das Problem, dass bei der Suche nach gmx manchmal die domain gmx.de in den Suche ergebnissen erschienen ist, wobei eigentlich unsere Hauptdomain gmx.net ist. Da wolltest du noch mal schauen, ob du da noch irgendwas herausfinden kannst. Hast du da noch irgendwelche neuen Erkenntnisse? Im Moment habe ich da nichts Neues. Das ist ähnlich wie eine andere Frage, die heute gekommen ist, auch mit gmx.de und gmx.com, wo unsere Algorithmen das Gefühl haben, sie können das jetzt besser machen, aber wo solche Verlierungen eigentlich noch dazu bekommen sehen. Gerade, ich weiß nicht, was, vielleicht in den letzten drei, vier Wochen so größten Orten haben wir das gesehen. Aber ich schau das noch mit dem Team an. Ich hoffe, dass wir das ein bisschen ausbügeln können. Okay, cool. Danke. Wenn sonst keine weiteren Fragen sind, können wir natürlich hier schließen. Ich bin nächste Woche an der SEO-Com in Salzburg. Falls ihr auch da seid, kommt doch mal vorbei. Da sehen wir uns auch in Person. Und ansonsten stelle ich noch die nächsten Hangouts auf, damit ihr auch weitere Fragen dort hineinbringen könnt, dass wir es nächstes Mal sehen können. Okay, dann vielen Dank fürs Kommen. Vielen Dank für die vielen Fragen. Und dann sehen wir uns vielleicht entweder in Salzburg oder beim nächsten Hangout wieder. Danke. Tschüss allerseits. Tschüss.