 Okay, herzlich willkommen bei den heutigen Google Webmaster Essentials Sprechstunden Hangouts. Mein Name ist Johannes Müller, ich bin Webmaster Chance Analyst hier bei Google in der Schweiz. Und Teil von dem, was wir machen, ist solche Hangouts hier mit Webmaster, mit Publisher, alle diejenigen, die die Websites bereitstellen für die Google Suche. Wie immer, wenn ihr möchtet, kann einer von euch vielleicht gerade noch melden, wenn irgendwelche Fragen oder Sachen sind, die wir gerade am Anfang besprechen sollten. Ansonsten gehe ich diese anderen Sachen mal durch. Ja. Also ich hätte gleich eine Frage. Super. Ich hoffe, man kann mich gut hören. Ja. Wunderbar. Wir haben vor ein paar Tagen ein Portal gelauncht, wo es darum geht, dass andere Vertriebspartner über ein affiliate Link bestimmte Provisionen bekommen würden. Jetzt haben wir festgestellt, dass einige dieser Vertriebspartner unsere direkte Seite als iFrame oder in den Frameset eingebunden haben. Jetzt stellt sich uns die Frage, ist das in irgendeiner Art und Weise negativ für uns, sprich, das Liquid Content oder ähnliches, oder können Sie das einfach machen? Sieht vielleicht nicht schön aus und ist vielleicht technisch nicht schön umgesetzt. Aber generell erst mal für uns, Sie fragen, ob das negative Auswirkungen für uns haben kann oder hat. Sollte eigentlich machbar sein. Also inwieweit wir dann diese Seite als separator Seite indexieren oder wie weit wir einfach sagen, gut, eure Seite ist diejenigen, die eigentlich die Inhalte hat. Das ist die Seite, die wir indexieren. Das hängt von paar anderen Faktoren ab. Aber grundsätzlich hat das auf jeden Fall keinen Nachteil für euch. Macht es da denn eventuell Sinn auf diese anderen Domänen, vielleicht auch wie den Canonical Link zu setzen, der auf uns dann zeigt oder ich sage mal so als Vorsichtsmaßnahme, oder macht das eigentlich einen Unterschied? Sollte eigentlich keinen Unterschied machen. Was natürlich immer passieren kann, gerade in so einer Situation, wenn man mit Philly jetzt arbeitet, dass ihre Seiten vielleicht höher ranken als deine Seiten, aber da schlussendlich geht es ja euch darum, dass ihr die Produkte oder was ihr auch immer ihr verkauft irgendwie an den Mann bringen könnt. Und da kann es natürlich passieren, dass ein Vertriebspartner dann höher rankt als ihr. Also auch wenn die Seite wirklich nur als Iframe eingebunden ist, ohne eigene Inhalte? Theoretisch könnte das schon passieren. Ich denke, in den meisten Fällen wird das nicht so. Ah, okay. Wunderbar. Danke. Bitte. Okay. Irgendwelche weiteren Fragen, bevor wir loslegen. Sonst gehen wir da mal die Fragen durch, die schon eingereicht worden sind. Bezüglich den Single-Page-Applications ist das wichtig für Google Crawler, dass die push-state-geladenen URLs in Browser nicht nur ein JavaScript-Konstrukt sind, sondern auch tatsächlich eine gültige URL quasi zeigen. Ja, das ist für uns wichtig, aus einem ganz praktischen einfachen Grund, weil wir möchten ja Benutzer auf diese Seiten dann schicken können. Das heißt, wir möchten diese Seite irgendwie indexieren und dann Benutzer gezielt auf diese geladene Seite schicken. Und wenn ihr per JavaScript einfach die Inhalte austauscht, dann ist das ja immer die gleiche URL. Und da können Benutzer nicht gezielt auf eine Seite innerhalb von der Website schicken. Und von dem her ist es wichtig, dass, wenn man mit Single-Page-Apps arbeitet, dass man dann trotzdem URLs verwendet, die an für sich normale URLs sind, die man per Copy und Paste von einem Browser in anderen kopieren kann, die man da so auch erreichen kann. Gerade bezüglich den URLs habe ich in, ich glaube, September, Oktober herum ein Video aufgenommen bei AngularConnect, wo verschiedene Faktoren aufgezählt sind, auf die man achten müsste, gerade bei Single-Page-Applications, damit das wirklich auch mit der Google-Suche gut funktioniert. Das Ganze kommt an und für sich da zusammen, dass man per Fetch as Google in Search Console auch gezielt angeben, ein URL quasi reinkopieren kann und dass man die Inhalte dann auch direkt sieht in Search Console. Und wenn das klappt, dann ist eigentlich das meiste schon erledigt. Handhub, Google-Bord, 404 oder 410 Seiten unterschiedlich, wenn auch nur minimal, ja, leicht. Was für uns der Hauptunterschied zwischen 404 und 410 Seiten ist, ist, dass wir mit 410 eher erkennen können, dass die Seite wirklich permanent jetzt weg ist und da verschwindet die Seite ein kleines bisschen schneller aus dem Index. Praktisch gesehen gibt es da eigentlich keine großen Unterschiede sonst. Das heißt, wenn man eh darauf wartet, dass die Seiten neu gekrawlt werden, bis sie aus dem Index fallen, dann macht das für euch eigentlich keinen großen Unterschied, ob jetzt nur 404 oder 410 angegeben ist. Auf unserer Seite funktioniert das eigentlich so weit gut. Wenn ein Entwickler euch fragt und sagt, ja, ich könnte beide Codes angeben, welchen soll ich verwenden, dann kann man natürlich gezielt sagen 410, wenn es wirklich weg ist, 404, wenn man jetzt nicht ganz 100% sicher ist. Aber wenn ihr eine Website anschaut und die verwendet im Moment 404 und ihr denkt, ah, die Seiten sind wirklich weg, dann ist es nicht so, dass ich da jetzt sagen würde, man müsste das auf 410 umstellen oder dass man da irgendein Vorteil hätte, wenn diese Seiten eh schon aus dem Index gefallen sind, wenn man 410 angebt. Das heißt, die Unterschiede sind wirklich sehr minim. Und wenn man am Anfang sich überlegt, wie man das einsetzen soll, dann kann man natürlich das Richtigere wählen. Wenn man schon etwas gewählt hat, würde ich mir jetzt da nicht den Kopf zerbrechen. Gibt es SEO-technische Nachteile, wenn man von jQuery auf React.js umstellen möchte, hat Google Baut Schwierigkeiten beim Crawl von Single Page Applications. Ich weiß jetzt nicht genau, was man da natürlich alles umstellt. Grundsätzlich sind das ja zwei verschiedenen JavaScript-Frameworks. Und je nachdem, wie man die einsetzt, kann natürlich, können unterschiedliche Sachen passieren bezüglich der Seite, bezüglich den Inhalten, die da dargestellt werden. Von dem her ist es schwierig, das so zu verallgemeinern und zu sagen, ja, dieses Framework ist okay und das ist nicht so okay. Bezüglich Single Page Applications ist es natürlich so, dass wir die Seiten rendern müssen. Das heißt, wir müssen die so ausführen wie ein Browser. Und wenn wir das machen können, wenn wir das über die URLs, wie am Anfang beschrieben, wenn wir die Seiten so aufrufen können und die Inhalten lesen können, dann ist es anfühlt sich soweit okay. Wichtig ist vielleicht auch dabei zu erwähnen, dass viele der Tools, der SEO Tools, die sonst noch gibt außerhalb, können mit solchen gerenderten Seiten nicht so optimal umgehen. Das heißt, je nachdem, welche Tools ihr sonst noch braucht, müsst ihr vielleicht darschauen, wie man damit am besten umgehen kann. Mehr und mehr Tools können jetzt per Rendering die Seiten auch laden. Von dem her, denke ich, wird sich das weiter in die Richtung auch entwickeln. Wenn eine Website auf mobilen Endgeräten weniger relevanten Content und Verlinkungen anbietet auf der Desktop-Seite, wird diese Seite dann im Ranking fallen. Ich denke, im Moment ist es so, dass wir eh die Desktop-Version aus die indexierte Version verwenden. Von dem her ist es weniger so, dass da ein direkter Einfluss wäre. Aber indirekt kann es natürlich sein, dass Benutzer dann auch sagen, gut, ich verwende hauptsächlich mein Smartphone, um auf diese Seite zuzugreifen. Und die kann ich da nicht brauchen. Also empfehle ich sie nicht weiter an meine Kollegen. Das könnte vielleicht indirekt da eine Rolle spielen. Längerfristig, wenn wir zum Mobile-Index wechseln würden, dann ist es schon so, dass wir dann die mobile-Seite nehmen als Basis für die indexierte Version. Und wenn auf der mobilen Seite weniger Inhalte sind, dann haben wir weniger Inhalte, die wir für die Indexierung verwenden können, die wir für das Ranking verwenden können. Weniger heißt nicht unbedingt, dass die Seite jetzt schlechter ist, aber wir haben dann einfach weniger Inhalte, die zur Verfügung stehen. Wenn die Inhalte, die auf der mobilen Version fehlen, wichtig sind für die Seite, dann kann es natürlich sein, dass wir die Seite dann im Ranking entsprechend gar nicht richtig zeigen können, weil wir gar nicht mehr diese Inhalte haben. Zum Thema Backlinks, Qualität oder Quantität macht es einen Unterschied, ob ein Backlink einmal von einem Domain ausgeht oder je einmal auf beispielsweise 1000 Unterseiten. Grundsätzlich ist das für uns eigentlich sehr ähnlich. Das heißt, wir sehen, dass diese Links da sind. Wenn jetzt einmal ein Link von einer Webseite kommt, dann ist das vielleicht mal ein Link zumindest. Wenn wir sehen, dass dieser Link auf allen Seiten dieser Webseite ist, dann ist es nicht so, dass wir sagen würden, das sind jetzt irgendwie Tausende von Links, sondern sagen wir vielleicht ja, von dieser Webseite insgesamt geht da ein Link aus. Wir sehen, dass es auf allen Seiten eigentlich gleich ist. Von dem her ist es dann nicht so, dass wir sagen würden, das sind jetzt wie 1000 verschiedene Websites, die diese Seite empfehlen. Von dem her ist es dann ein bisschen ähnlich. Also ich würde mir da nicht groß den Kopf zerbrechen, wenn jemand vom Template aus ein Link auf eurer Webseite setzt, dann ist es vielleicht auf mehreren Seiten kopiert. Wenn jemand direkt innerhalb vom Text zu eurer Webseite verlinkt, dann ist es halt da direkt eingebunden. Das kann man ja nicht immer direkt steuern. Ich sehe eine Frage in Englisch, in der Chat. Ich würde dir den Hangout in Englisch joinen. This one is just in German, sorry. Beim Zusammenführen von zwei Webseiten, wie sie Google die Methode Webseiten mit zwei CMS-Systemen temporär zusammenzuführen, indem man beispielsweise Webseite B mit eigenen CMS in das Unterverzeichnis von A verschiebt und die XML-Seitmap entsprechend erweitert. Grundsätzlich ist die Art und Weise, wie ihr Webseites zusammenführt, eure Sache. Ob ihr da die CMS, quasi die Inhalte in ein CMS kopiert oder ob ihr eine Webseite aus Unterverzeichnis bei einer anderen hinein nehmt, das ist grundsätzlich euch überlassen. Aus unserer Sicht ist es einfach so, dass gerade beim Zusammenführen von zwei Webseiten ist es natürlich eine recht große Umstellung und da müssen wir dann erstmal die neue Webseite ein bisschen genauer verstehen. Und da ist es meistens so, dass es da schon größere Schwankungen gibt, bis sich das alles wieder ein bisschen eingependet hat. Das heißt, man spart nicht wirklich viel bezüglich Schwankungen, wenn man jetzt, sag ich mal, eine Webseite als Unterverzeichnis einfach hinein nimmt, weil wir müssen dann trotzdem erstmal erkennen können, ja, wie funktioniert diese gesamte neue Webseite und wie können wir mit diesen Signalen umgehen, wie verstehen wir den Kontext von den einzelnen Seiten da, wie das alles zusammengehören sollte. Von dem her ist es so, dass es vielleicht praktischerweise für euch einfacher so ist und das hat natürlich auch gewisse Vorteile, aber zumindest auf der SEO-Seite ist es eigentlich ähnlich, wie wenn man jetzt zwei Webseiten ganz zusammenführt. Bezüglich HTTPS Redirect gibt es noch ein Risiko von Traffic Verlust wegen eines 301 Redirects. Risiko gibt es natürlich immer, wenn man irgendwelche Veränderungen an der Webseite macht. Von dem her kann ich da nichts sagen. Es gibt garantiert kein Risiko, dass sich irgendetwas verändern wird. Manchmal ist es ja auch so, dass vielleicht verschiedene Sachen zusammenkommen. Dann stellt man auf HTTPS um und gleichzeitig wechselt einer unserer Algorithmen die Webseite neu ein und dann hat man auch das Gefühl, dass das irgendwie zusammenhängt. Grundsätzlich ist es aber so, dass unser System es sehr gut mit HTTPS Umstellungen jetzt umgehen kann. Ich würde nicht sagen, dass sie 100%ig immer perfekt und quasi auf die Minute solche Umstellungen verarbeiten können, aber zum großen Teil bei den meisten Websites, die wir jetzt beobachtet haben, das ist eigentlich sehr gut. Von daher würde ich mir da jetzt nicht irgendwie sorgen machen, dass Google das nicht richtig hinkriegt, weil wenn irgendetwas passieren würde, ist es in unserem Interesse, dass wir das auch möglichst schnell wieder zurechtbiegen können und da wäre ich natürlich froh, wenn ihr mir die Informationen auch zukommen lasst. Das geht dann da weiter. In Search Console muss man eine neue Property für HTTPS Version erstellen. Warum habt ihr das nicht wie WBW und nicht WBW quasi mit der Perfer Domain-Einstellung? Ja, auch WBW und nicht WBW muss man separat erfassen in Search Console. Wir haben da keine Einstellungen für HTTPS oder HTTPS. Aus dem einfachen Grund, dass wenn man diese Einstellungen falsch macht und wir die HTTPS Version indexieren, obwohl ihr da noch nicht so bereit seid, dann gibt das größere Probleme. Das heißt, der Besucher, die euch links anklicken, sehen dann vielleicht erst mal ein großes Warnfenster im Browser, dieses Zertifikat ist ungültig oder vielleicht ist das auf dem Server gar nicht richtig eingestellt und das ist natürlich ein größeres Problem, als wenn man einfach auf WBW oder nicht WBW geht und man sieht die gleichen Inhalte und der Server macht ja alles genau gleich. Und deswegen haben wir da eigentlich keine Einstellungen für HTTPS Ich könnte mir vorstellen, dass man in Zukunft vielleicht eine Art Wizard noch einbauen würde, dass man sagen kann, ich möchte auf HTTPS umstellen und dann geht es ähnlich wie beim Side Move kurz durch und kontrolliert gewisse Sachen und stellt sich ja, dass ihr die richtigen Versionen verifiziert habt in Search Console, dass die redirect vorhanden sind und dass das so ein bisschen einfacher geht. Aber eine einfache Einstellung quasi einfach HTTPS könnte ich mir vorstellen, dass wir das nicht so einfach zur Verfügung stellen. Einfach eben wie gesagt, weil da die Fehlerquote doch relativ hoch sein kann. Wenn man auf 301 verzichtet, kann es zu einem Duplicate Content Issue kommen, wenn Google die HTTPS Version trotzdem aufhängt. Nein. Auf jeden Fall gibt es keine Probleme bezüglich Duplicate Content. Auf jeden Fall, wenn wir beide Versionen wirklich separat indexieren, sehen wir ja auf Anhieb, dass das die gleichen Inhalte sind und so können wir dann sehr schnell sagen, ja, das ist das Gleiche, wir falten es zusammen, wir führen das aus einem URL auf bei uns im Index und vielleicht ist das HTTPS, das hängt ein bisschen davon ab, wie unsere Algorithmen das einstufen können. Kann ein und dasselbe Social Media Profile für mehrere verschiedenen Ländervarianten eine Website per JSON-LD verwendet werden. Beispielsweise facebook.com-google wird genutzt für google.com-de und Stich-en. Dabei hat jede Variante zum Beispiel ein eigenes Instagram Profil soweit ich weiß, sollte das überhaupt kein Problem sein, dass man da das gleiche Social Media Profile mit verschiedenen Websites verwendet. In vielen Fällen ist das ja auch normal, dass man vielleicht verschiedene Marken hat mit verschiedenen Websites, aber eigentlich verwenden sie jetzt von der Übergruppe, das Social Media Profile, vielleicht für Facebook oder Google Plus oder Instagram oder was auch immer und von dem her sollte das eigentlich kein Problem sein. Ich denke, so etwas kann man sehr schnell einfach kurz ausprobieren und auf jeden Fall wird das irgendwie die Website herabgestuft werden, wenn man die gleichen Profiles verwendet. Da sehe ich eigentlich gar keine Probleme. Wann kommt der Mobile Index? Ich denke, es wird noch mindestens 6 Monate stehen da. Ich weiß es ehrlich gesagt nicht. Ich denke, das hängt in erster Linie davon ab, wie unsere Tests verlaufen und das kann sein, dass es relativ schneller kommt, wenn wir denken, dass wir das alles eigentlich auf unserer Seite gut abfahren können. Es kann sein, dass es vielleicht ein bisschen länger geht, wenn wir das Gefühl haben, Webmaster müssen da zu einem gewissen Grad noch Einstellungen machen oder Änderungen vornehmen an ihren Websites, dann müssen wir natürlich ein bisschen mehr Zeit lassen, damit sie das auch wirklich auch gut machen können. Und das sind so Sachen, die müssen wir wirklich in Ruhe austesten und in Ruhe untersuchen. Wir haben das in erster Linie soweit im Voraus bekannt gegeben, damit Webmaster nicht ganz schockiert sind, wenn das wirklich kommt und wenn sie sehen, dass wir zwischendurch unsere Tests machen, dass sie da auch nicht gerade das Gefühl haben, jetzt gibt es eine wilde Umstellung, von der ich nichts verstehe. Von dem her ist es schwierig zu sagen, wann das kommt. Im Moment ist es sicher noch nicht so, dass wir genau wissen, was man alles umstellen müsste oder was wir alles auf unserer Seite umstellen könnten oder ob wir vielleicht eine kombinierte Version machen können oder ob wir irgendwie die Signale kombinieren können. Das wird sicher noch spannend, aber Zeitrahmen habe ich im Moment jetzt nicht. Gibt es eine Formel-Faustregel bezüglich Content-Aufteilung, Textbildverhältnis, insbesondere bei Mobile Friendly Text bei Bildern mehr als zum Beispiel 10 Röhrter enthalten und wird auch gecrawlt. Ja, wenn ein Alt Text vorhanden ist, dann nehmen wir das zur Seite dazu. Bezüglich Text- oder Bildverhältnis ist mir eigentlich nichts bewusst, wo ich sagen würde, dass man da mindest so viel Wörter auf einer Seite haben muss, wenn man jetzt noch Bilder dazu nimmt. Meines Erachtens ist das etwas, das wirklich sehr stark von euren Web Seiten abhängt und auch sehr stark davon abhängt, wie Benutzer mit euren Seiten umgehen, was sie auf den Seiten suchen. Wenn jemand gezielt nach Bildern sucht, dann ist es natürlich auch gut, wenn die Bilder auf eurer Webseite sind. Wenn jemand gezielt nach irgendwelchen Informationssucht, die im Text sind, dann ist es natürlich gut, wenn die auch irgendwie erwähnt werden auf den Seiten, damit wir das dann im Ranking für sich nicht viel bezüglich mobile friendly oder desktop-Version oder responsive, sondern man muss einfach irgendwie die Texte auf den Seiten haben, die die Benutzer auch suchen, damit wir die Seite auch sauberen Suchergebnissen bringen können. Bezüglich RSS-Feeds ist die Einbindung von RSS-Feeds auf einer Webseite vorteilhaft für das Ranking bei Google oder werden die Inhalte als fremde Inhalte gewertet. Gibt es andere Vorteile, wie zum Ausflugmens. Wir verwenden RSS-Feeds ähnlich wie SideMaps. Das heißt, wenn ihr uns die Änderungen, die neuen und geländerten Seiten per RSS-Feed schickt und das in Search Console angemeldet ist, dann können wir diese Seiten ein bisschen schneller crawlen und indexieren. Und das ist aus unserer Sicht sehr praktisch. Der große Unterschied zwischen RSS und SideMaps ist, dass in der Regel ist ein RSS-Feed eher die letzten Änderungen von einer Webseite und eine SideMap ist dann die gesamte Webseite. Manchmal kann man nicht die gesamte Webseite einfach so bereitstellen als SideMap und dann macht es Sinn, dass man vielleicht ein Teil der SideMap hat, die Änderung per RSS quasi so einreicht. Beim RSS kann man zudem auch mit PubSubHubbub arbeiten, um so die Änderungen wirklich quasi direkt an Google das noch ein bisschen schneller zu machen. Das meinte ich jetzt gar nicht mit der Frage. Es geht darum, ich habe einen Kunden, das eine Steuerberatungsgesellschaft und denen ist das angeboten worden, RSS-Feeds passend zum Thema Steuern und alles was mit Rechte um Steuern zu tun hat, auf ihrer Webseite zu veröffentlichen. Das sind dann quasi immer die kleinen Snippets, die dann auch irgendwelche anderen Webseiten verlinken. Es geht also nicht um die eigenen RSS-Feeds, sondern um die man veröffentlicht, sondern indem man fremde RSS-Feeds auf der eigenen Webseite neben dem Main-Content oder sogar auf einer separaten News-Seite anzeigt. Es wäre schön, wenn du dazu noch was sagen könntest. Und die sind quasi serverseitig eingebunden oder per JavaScript? Ja, ich weiß jetzt nicht genau, wie es bei denen funktioniert. Es kann ja auch sein, dass der HTML-Code steht. Aber es wechselt doch recht häufig. Mir ist dann aufgefallen, es gibt nur eine Seite, da sieht man dann von zwei Tagen die RSS-Feldung von verschiedensten Portalen und das ist nach einem Tag natürlich schon wieder weg. Also dann auch für die Suchergebnisse gar nicht mal so gut zu gebrauchen, sondern wenn man Suchergebnis hat, kriegt drauf und kriegt dieses Ergebnis nicht mehr zu sehen. Wichtig ist in solchen Fällen einfach, dass man wirklich eigene Inhalte noch dabei hat. Das heißt, dass die Webseite alleine auch steht und dass die RSS-Meldungen quasi wie im Sidebar einfach als Zusatzinformation da sind und eher für den Benutzer, wenn jemand eher auf die Seite kommt. Weil wie gesagt, wenn jemand nach diesen Inhaltensuch, die im RSS-Speed sind, dann versuchen wir ja auch eher, die Quelle zu zeigen und was wir sagen würden, diese Webseite ist jetzt relevant für dieses Thema, was beim Sidebar erwähnt wird, sondern diese Webseite ist für das Hauptthema dieser Webseite bekannt und das ist für uns dann auch okay. Und wenn auf dieser Seite noch Zusatzinformationen sind, ist das aus unserer Sicht okay. Stört auf jeden Fall nicht. Was einfach passieren könnte, ist, dass wir da ein bisschen mehr crawlen, weil wir das Gefühl haben, diese Webseite verändert sich ja ständig und in den meisten Fällen, gerade bei kleineren Webseiten, ist es ja nicht so, dass wir vom Crawling irgendwelche Probleme verursachen würden und von dem her würde ich mir da jetzt keine großen Gedanken machen, gerade wenn wir durch das zusätzliche Crawling keine Probleme verursachen, ist das eigentlich okay. Es ist nicht so, dass man einen SEO-Vorteil hat, wenn man häufiger gecrawlt wird. Genau, das war aber das Argument von den Dienstanbietern, mit passenden Themenrelevanten RSS-Feeds, könnt ihr eure Webseite aufwerten? Ja, ehrlich. Ja. Also ich meine, für Benutzung macht das vielleicht auch Sinn, dass man da mehr Informationen hat und auch zeigt, ich kenne mich mit diesem Marktsegment aus und hier sind die Nachrichten, die ich interessant finde. Das habe ich für euch quasi so zusammengestellt. Das macht ja vielleicht Sinn. Konzentrieren wir uns schon eher auf den Hauptteil dieser Seite. Okay. Wir haben da ein Problem. Die Seitenfrage zeigt quasi die falsche URL. Ich glaube, du hast auf Twitter auch mal geschrieben wegen dem. Wie ich das gesehen habe, also ich müsste vielleicht noch einmal kurz nachschauen, ist es so, dass die beiden Versionen, die da zusammen, die da verfügbar sind, sind ja die gleichen Inhalte an und für sich. Und auf unserer Seite, was wir da gemacht haben, ist dann das einfach zusammenzupacken und sagen, ja, das sind die gleichen Seiten. Also indexieren wir eine URL. Wir verstehen fast schon, dass da zwei URLs verständig stehen. Aber wir konzentrieren uns auf eine dieser Version. Wird bei der Google-Bildersuche nur das Bild aus dem Image Source Tag indexiert. Oder auch zusätzliche Bilder, die mit Picture und Source Set im HTML stehen. Gute Frage. Weiß ich jetzt nicht genau. Was wir auf jeden Fall noch zusätzlich indexieren, sind auch verlinkte Bilder. Das heißt, wenn ich mit einem AR-Tag auf einem JPEG oder irgendein anderes Bild verweise, dann nehmen wir auch an, dass das irgendwie zu dieser Seite gehört und wir das auch mit der Google-Bildersuche dazunehmen. Ich bin mir jetzt nicht hundertprozentig sicher mit Picture und Source Set auch alle diese URLs indexiert werden. Ich würde das vielleicht mit einer Testseite kurz ausprobieren und dann weißt du es auf jeden Fall hundertprozentig. Ich könnte mir vorstellen, dass wir die schon finden, aber ich bin jetzt ehrlich gesagt nicht hundertprozentig sicher. Wir haben es aktuell so eingerichtet, dass fortfolgende Ergebnisseiten Seite 2, 3 und 4 unserer Produktergebnis-Listen z.B. aller Wundreisen mit einem Canonical auf Seite 1 verweisen. Ist das der richtige Ansatz oder empfiehlst du uns eine andere Herangehensweise quasi mit Realm Next oder Realm Previous zu machen? Und dann kommen noch die verschiedenen Filtervarianten. Wie kann man da mit Canonical und Duplicate Content vermeiden, arbeiten? Schwierig zu sagen. Es ist auf jeden Fall kein Thema, wo ich sagen würde, es gibt eine Standardlösung, die müssen alle Websites zu machen. Es gibt da verschiedene Sachen, die zusammenkommen können. Einerseits, wenn die Seiten für sich separat stehen würden, wenn das wirklich eigenständige Seiten sind, die so indexiert werden sollten, dann kann man das mit Canonical machen. Wenn es darum geht, dass man nur ein Verweis hat auf die einzelnen Detailseiten, z.B. Produkte verlinkt von diesen Ergebnisseiten, dann kann man vielleicht schon mit dem Canonical arbeiten, solange wir auf jeden Fall einen Link zu diesen Produkten finden. Das heißt, wenn ein Produkt immer nur auf Seite 4 oder 5 ist in diesen Ergebnisseiten und per Canonical immer auf die Seite zu diesem einzelnen Produkt und dann wird dieses Produkt vielleicht nicht separat indexiert. Das ist vielleicht mal eine Sache, auf die man achten müsste. Da kann man auf jeden Fall mit REL Next und REL Previous auch arbeiten. Wir haben eine Blogpost und ich glaube auch im Hilfercenter eine relativ ausführliche Seite mal gemacht mit den verschiedenen Varianten, wie man damit umgehen könnte, gerade mit REL Latern. Bezüglich Duplicate Content würde ich mir da nicht zu groß den Kopf zerbrechen, weil das aus unserer Sicht ein technisches Problem in solchen Fällen und nicht eine Sache, wo wir sagen würden, die Qualität dieser Website ist jetzt schlechter, weil sie Paginierung verwendet oder dass jemand vom Website beim Team kommen würde und sagen würde, ja, das ist den Content, weil Seite 7 indexiert ist eine technische Sache für uns. Welche Seiten werden indexiert und welche Links finden wir auf diesen Seiten zu den einzelnen Detailseiten von diesen Listen aus? Da noch eine Frage zu Google Analytics. Da kann ich wahrscheinlich nicht groß helfen. Mal schauen, was da kommt. Da zwei Subdomains schreiben in dieselbe Google Analytics Property. Ja, mit Google Analytics kann ich leider nicht viel helfen. Da würde ich vielleicht in Google Analytics Hilfeforum mal nachfragen, ob da jemand mehr Informationen hat. Ich habe für meine zwei Seiten Content-Marketing-Aktion gemacht und diese wurde entsprechend auch im asiatischen und chinesischen sowie japanischen Raum verlinkt. Da meine Seite aber deutschsprachig ist, auf den Schweizer Markt fokussiert, frage ich mich, ob solche Links disavowed werden müssen oder ob Google dies eventuell aus BAM ansieht oder ob das schädlich ist. Aus unserer Sicht ist das total unproblematisch. Wenn das natürliche Links sind zu euren Seiten und sie halt von anderen sprachigen Websites kommen, ist das total möglich. Vielleicht verlinken die einfach auf eure Seiten so. Da würde ich mir deswegen keinen großen Gedanken machen. Wir haben eben platzierte Links sind, wenn ihr vielleicht mit einer SEO-Agenzie zusammengearbeitet habt und die haben gesagt, links in China sind besonders billig, wenn wir die kaufen und wir können die auf diese chinesischen Forum platzieren. Dann sind das natürlich einfach unnatürliche Links, egal welche Sprache die Websites sind. Dann würde ich vielleicht mit einem disavowed arbeiten bzw. vielleicht auch mit der SEO-Agenzie die Seite auf die Idee gekommen, dass ihr jetzt auf diesen chinesischen Forum diese Links platziert zum Beispiel. Aber wenn das ganz normale Websites sind die einfach auf eure Produkte verlinken, weil sie denken, diese Schweizer Produkte sind besonders cool oder die Bilder sind toll oder was auch immer oder sie kaufen es vielleicht sogar von euch dann ist das aus meiner Sicht überhaupt kein Problem. Eine Frage zur hreflang Implementierung. Wir betreiben im Deutschland-Österreich-Schweiz-Raum und die hreflang-Einträge wurden sauber gesetzt und mehrmals geprüft. Die Version für Österreich und Deutschland legen auf den .com-Domain und die Schweizer Version liegt auf einem eigenen CH-Domain. Seit Anfang Dezember zeigt uns Search Console keine hreflang-Tags mehr an und auch keine Fehler. Das heißt, alles ist auf null. Was machen wir da falsch? Das klingt komisch. Ich weiß jetzt nicht genau was das sein könnte. Am liebsten hätte ich da vielleicht diese Beispiele mal wenn du sie mir zuschicken könntest auf Google Plus oder auf Twitter zum Beispiel dann kann ich das hier mal anschauen. Was vielleicht sein könnte ist, dass man die falsche Version anschaut in Search Console. Das heißt, wenn vielleicht WBW vorhanden ist und wir indexieren alles mit WBW und ihr schaut euch die Nicht-WBW Version an in Search Console dann kann es sein, dass wir da keine Daten haben weil alles mit WBW indexiert ist. Vielleicht liegt so etwas vor vielleicht gibt es auch ein technisches Problem auf unserer Seite von dem her würde ich das vielleicht gerne mal anschauen und einfach sicherstellen dass das wirklich auch sauber läuft auf unserer Seite. Indexierung von Websites mit geschützten Inhalten. Ich möchte unterseiten mit Disclaimer und Overlay geschützten Inhalten indexieren wobei sich der User mit ja, ich bin ein Journalist, aber dann authentifizieren muss bevor der Body Inhalt sichtbar ist. Googlebaut selbst würde auch lediglich den Head-Bereich indexieren können mittels 403 werden die Fehler unterdruckt. Gefällt sowas Google gar nicht auf die Website oder ist dies eine akzeptable Methode. Grundsätzlich wenn Googlebaut die gleichen Sachen sieht wie der normale Benutzer, ist das aus unserer Sicht okay. In einem solchen Fall klingt das so, als ob Googlebaut natürlich gar keine Inhalte sehen würde und wenn das für euch so okay ist, wenn die Inhalte nicht indexiert werden, dann ist das für uns auch okay. Wenn es euch nur darum geht, dass diese Inhalte in der Suche erscheint, würde ich vielleicht einfach mit einem No-Index-Tag arbeiten. Dann muss man sich da nicht so viel Gedanken machen, was Googlebaut alles sieht. Wenn es für euch hingegen wichtig ist, dass diese Inhalte wirklich auch sichtbar sind in der Google-Suche, dann würde ich vielleicht mit anderen Methoden da arbeiten und dann vielleicht eher mit einem Burner arbeiten, so dass Googlebaut und die Benutzer die Inhalte trotzdem sehen können, aber dass diese quasi Zusatzinformation trotzdem für den Benutzer sichtbar ist, quasi eine Bestätigung, ja, ich akzeptiere oder wie man das halt machen möchte. Das heißt, ihr müsst euch ein bisschen überlegen, sollen die Inhalte indexiert werden oder sollen sie nicht indexiert werden? Wenn sie nicht indexiert werden sollen, kann man das sicher einfacher mit einem No-Index machen und wenn sie doch indexiert werden sollten, müsste man wirklich dafür sorgen, dass die Benutzer die Inhalte dann auch wirklich sehen können. Das ist eine Frage. Und zwar, wenn ich die Meta Description und den Type-Tag an Google übergebe, dass da ein Google auch genau diesen spezifischen Meta-Tag ausgibt in der Beschreibung. Das heißt, manchmal ist das so, wenn ich generell die Meta-Tags lernen lasse, dann nennt sich Google irgendein Bereich und gibt diesen dann als Description in der Specialized-Page an. Wenn ich jetzt selber eine Meta-Tag-Gesetze wie hoch Meta-Description-Tag-Setze ist und dann die Wahrscheinlichkeit, dass Google genau diesen tagt. Schwierig zu sagen. Hängt ein bisschen, was natürlich passiert, ist, dass wir je nach Suchanfrage diese Description auch anpassen können. Okay. Wenn jemand gezielt nach etwas sucht, was auch bei euch im Description-Meta-Tag dabei ist, dann nehmen wir das vielleicht schon eher. Wenn jemand gezielt nach etwas sucht, was eher im Haupttext dabei ist, dann nehmen wir vielleicht eher ein Teil aus dem Haupttext. Und da würde ich vielleicht auch schauen, wie das wirklich in der Suche auch erscheint. Das heißt, in Search Console mal nachschauen, welche Suchbegriffe auf diese Seite überhaupt führen und die Suchen da noch ausprobieren. Wenn man jetzt nur eine Seidabfrage macht, dann wird das nicht so dementsprechend, was Benutzer wirklich sehen. Okay, vielen Dank. Wir haben für unsere Website Mobile einen deutlichen Umgang. Ich weiß jetzt nicht genau, welche Website das ist. Geändert haben wir, dass wir Markup mit JSON-LD auch für die M-Punkt-Domain angegeben haben und wir haben AMP optimiert. Jetzt sehen wir mobile fast nur noch AMP-Partikel in den Suchergebnissen. Meine Frage verdrängt AMP die mobilen Suchergebnisse oder haben wir beim Markup ein Fehler oder sonst etwas falsch gemacht? Rail Canonical, Rail Alternate ist korrekt gesetzt. Grundsätzlich ist JSON-LD total okay. Da müsst ihr euch, solltet man da keine Sorgen machen, dass es gerade bei einer mobilen Seite ist, das ist eigentlich ganz okay. Bezüglich AMP und der mobilen Version ist es natürlich so, dass wir versuchen, die AMP-Version dann zu zeigen, wenn wir sehen, dass es ein Benutzer ist, der ein unterstütztes Gerät hat. Dann zeigen wir eher die AMP-Version, dass es ein Benutzer ist. Das heißt, es ist nicht unbedingt so, dass man dann mit AMP mehr Verkehr hat, sondern einfach der Verkehr, der sonst zur Smartphone-Version gegangen wird, geht natürlich zur AMP-Version. Wenn das jetzt so gesucht wird, dass wir die AMP-Version auch zeigen können im AMP Viewer. Von dem her könnte ich mir vorstellen, dass wenn man jetzt AMP und die Mobile-Version den Verkehr zusammenzählt, das vorher jetzt mit nur der Mobile-Version auch war. Aus unserer Sicht ist es eigentlich normal, weil es ist nicht so, dass wir dann noch einen Zusatzeintrag in den Suchergebnissen machen für die AMP-Seiten, sondern wir zeigen einfach anstelle von der Mobile-Version dann die AMP-Version, wenn wir wissen, dass das für den Benutzer so auch klappt. Da ist sich noch eine Frage im Chat. Hast du zu diesem Problem eine Lösung? Kannst du uns sagen, woran das liegt? Testet Google wieder etwas aus. Mal kurz rein schauen, was da so kommt. Also grundsätzlich ist es natürlich so, dass wir immer Sachen testen. Von dem her ist das schwierig zu sagen. Mal kurz schauen. Wie man das sehen kann, ist am Wochenende immer stark an Rankings gesunken. Wüsste ich jetzt nicht, dass wir da irgendein Wochenend-Algorithmus haben, welches quasi andere Ranking-Faktoren verwendet am Wochenende. Von dem her, denke ich, hängt das wahrscheinlich eher damit zusammen, wie Benutzer einfach suchen. Und wenn jemand gezielt weiter sucht auf den Seiten, dann sieht man natürlich trotzdem zeigen mit Impressions. Wenn jemand vielleicht nur die erste Seite der Suchergebnisse anschaut, in eure Website ist jeweils auf der zweiten Seite der Suchergebnisse, dann sieht man natürlich auch jeweils einen Rückgang dort mit der Anzahl Impressions. Aber ich müsste das vielleicht ein bisschen genauer anschauen, aber auf jeden Fall ist es nicht so, dass zumindest meines Wissens, dass wir irgendwie so ein Art und andere Suchergebnisse präsentiert als während der Woche. Mal schauen. Früher war es wichtig, relevanten Content links eher oben zu zeigen, grafisch am Bildschirm und auch im Source Code. Menus sollten relativ früh im Code angezeigt werden, wie ist es heute mit Mobile? Die Links im Mobile sind auf Mobile immer zuerst hidden, manchmal sogar auch außerhalb vom Bildschirm oder im Hintergrund. Weiß Google, dass diese trotzdem sehr relevant sind? Ja, wir können das trotzdem auf jeden Fall erkennen. Bezüglich der Position der Inhalte, Inhalt vom Source Code, ist es eigentlich auch schon seit einiger Zeit so, dass das eher irrelevant ist. Das heißt, ob ihr die Inhalte jetzt am Anfang vom HTML oder am Ende vom HTML und dann per CSS quasi darstellt, ist aus unserer Sicht total egal. Wichtig ist vielleicht einfach, dass wir irgendwo die Seite quasi abschneiden. Das heißt, wenn die HTML-Seite quasi der HTML-Source Code mehr, ich weiß nicht, ein paar Hundert Megabyte ist, dann kann es sein, dass wir irgendwo einfach abschneiden und sagen, gut, wir schauen uns erst mal die ersten paar Hundert Megabyte an und nehmen das für die Indexierung. In den allermeisten Fällen ist das überhaupt kein Problem, weil die Seiten sind ja nie so lange. Und von dem her Positionierung vom Text innerhalb vom HTML aus unserer Sicht total irrelevant. Ob das jetzt für Desktop oder für Mobile ist, spielt eigentlich keine Rolle. Bezüglich Links im Menüs, die vielleicht jetzt unsichtbar sind auf Mobile, ist das im Moment auf jeden Fall kein Problem, weil wir ja eher die Desktop-Version nehmen für die Indexierung. Mit dem Mobile-Index ist es auch so, dass wir gezielt entschieden haben, dass gerade auf Mobile-Version hat man natürlich weniger Platz im Bildschirm und da ist es für uns auch total okay, wenn Texte oder Links entsprechend auf Anhieb jetzt nicht direkt sichtbar sind, sondern dass man da vielleicht erstmal das Menu-Kopf drücken muss und dass dann diese Links erscheinen. Wichtig ist einfach, dass die diese Menu-Inhalte und die Links zu den einzelnen Items direkt geladen werden auf der Seite. Das ist wichtig, dass wenn ich auf den Menu-Kopf drücke, dass dann erst ein Ajax-Call gemacht werden muss zum Server und diese Inhalte dann gezielt abfragt vom Server und dann darstellt. Einerseits ist es natürlich von der Geschwindigkeit ein bisschen suboptimal. Andererseits ist es für Google-Words so, dass Google-Words nicht überall einfach hinklickt zum Schauen, was passiert, sondern in Google-Words nimmt die Seite, wie sie kommt und sucht dann da entsprechend die Links und das heißt, wichtig ist einfach, dass es wirklich auch geladen ist auf Anhalt. Und da ist glaube ich nochmal die andere Frage. Ja, ich glaube da und damit hätten wir alle Fragen soweit durch. Was gibt es noch von euch, was wir anschauen müssten? Wo sind vielleicht noch offene Fragen? Ja, ich hätte nochmal eine Frage zur internen Verlinkung auf einer Seite, weil ich meine, es waren ja auch mehrere Fragen zu One-Pagern. Ich hatte das jetzt auf einer Webseite gesehen und auch selber schon angewendet, dass man in der Desktop-Version, wenn man auf die Seite kommt, sofort Wartenzart für In-Page-Verlinkungen, so quasi mit denen man auf Ankerpunkte springen kann. Wird sowas auch von Google verarbeitet, also bewertet Google sowas quasi als positive Benutzerführung. Beispiel zwei. Meistens nicht. Meistens merken wir das nicht. In einigen Fällen, wenn wir erkennen können, dass die Seite wirklich sehr lang ist, dann kann es sein, dass wir diese Sprungpunkte erkennen und dass wir die dann auch in den Suchergebnissen zeigen. Man sieht das ja ab und zu für Wikipedia-Seiten, sehe ich das am häufigsten, dass wir sagen, das ist die Seite zu diesem Thema und mit diesen vielleicht zwei, drei Sprungpunkten kommt man dann gezielt zu einem bestimmten Teil der Seite. Aber das ist nicht so, dass wir dann sagen würden, diese Seite ist besser oder schlechter deswegen, sondern einfach, das macht es ein bisschen einfach für den Benutzer an diesen Teil dieser Seite hinzukommen. Okay, danke. Okay, weitere Fragen. Ansonsten bin ich nächste Woche an SMX München. Wenn einer von euch oder von den Zuschauern da ist, kommt doch mal vorbei und dann sehen wir uns vielleicht dort. Ich weiß nicht, ob sie in zwei Wochen wieder stattfinden, weil ich da vielleicht in Amerika noch bin, aber ich setze auf jeden Fall die nächsten auf, sobald ich genauer weiß, werden die Termine hinfallen. Okay, dann wünsche ich euch erstmal einen schönen Nachmittag und bedanke mich bei euch für die vielen Fragen und Kommentare. Ich schaue mir noch den Forum-Thread an, der da verlinkt ist und dann sehen wir uns das Tschüss, allerseits.