 Okay, herzlich willkommen beim heutigen Google Webmaster Central Sprechstunden Hangout. Ich bin Johannes Müller, ein Webmaster Trends Analyst bei Google hier in der Schweiz und Teil von dem, was wir machen, sind solche Webmaster Hangouts mit Webmastern und Publisher, wie wir jetzt hier gerade im Hangout live drin sind. Wenn einer von euch möchte, könnt ihr gerne gerade mit den ersten Fragen loslegen. Wenn es irgendetwas gibt, womit ich gerade helfen kann, alles so schüchtern. Okay, kommt vielleicht noch. Ich hätte was. Okay, leg los. Also bei uns ist es tatsächlich so, dass wir seit wir auf HTTPS umgestiegen sind, also wir haben noch nicht alles umgestellt, aber ein paar Subdomains, dass die Crawl-Aktivitäten von Google extrem angestiegen sind, also es ist ein bisschen temporär, aber wir haben schon ordentlich viele Requestes auf unsere Maschinen und unser Schnittstellenpartner sagt, oh, das ist uns aber zu viel, das schaffen wir alles gar nicht und bricht dann so ein bisschen die API ab und was können wir da machen, sagen wir, so eine Art Google-DOS-Attacke. Okay. Ja, was da normalerweise passiert, ist, wenn wir eine solche größere Umstellung an der Website feststellen, dann crawlen wir ein bisschen schneller, damit wird die Veränderung ein bisschen schneller verarbeitet haben. Das ist wahrscheinlich das, was ihr jetzt da seht und einerseits crawlen wir natürlich die alten URLs, wir sehen dann die Redirects und dann crawlen wir die neuen URLs, wenn wir die dann noch renderen müssen, dann machen wir natürlich all die JavaScript-Aufrufe und solche Sachen auch noch dazu und meistens kann man ja dann den Cache von vorher nicht weiter verwenden von den Embedded URLs, also wenn JavaScript-Dateien da sind oder CSS-Dateien oder irgendwelche API-Antworten, dann kann man die alten Caches nicht mehr verwenden, weil sie ja neue URLs sind, jetzt neu mit HTTPS. Was man da machen kann, ist in Search Console bei dem Hilfezenter gibt es eine Möglichkeit in Formular auszufüllen über den Crawl-Rate, ich schick dir kurz mal den Link, es ist ein spezieller Antrag, den man stellen kann in quasi über Search Console, man muss die Website verifiziert haben und dann kann man an und für sich entsprechend angeben, welche Probleme man im Moment sieht, welche IP-Adressen von Googlebot eher problematisch sind, wenn das einzelne IP-Adressen sind, wie der Verkehr ist und was man gerne hätte. Und da schauen die Engineers vom Googlebot-Team an und antworten normalerweise innerhalb von ein, zwei Tagen drauf und können dann entsprechend die Aktivität von Googlebot entsprechend einstellen. Und manchmal können sie dann noch eine Antwort geben und sagen, das kommt wegen dem oder ihr macht da noch etwas falsch, das könnt ihr verbessern, manchmal stellen sie einfach die Crawling-Geschwindigkeit ein bisschen ein, so dass es ein bisschen besser läuft und im Laufe der Zeit sollte das eigentlich auch automatisch dann wieder angepasst werden, das heißt es ist eine temporäre Einstellung, die sie vornehmen und im Laufe der Zeit passt sich das dann wieder automatisch an und sollte dann auf den vernünftigen Pegel wieder zurückgehen. Okay, dann schaue ich dir mal rein. Vielen Dank. Ich habe nur gesehen, es ist für die nächsten 90 Tage laut Formular. Jawoll. Normalerweise pegelt sich das innerhalb von 40 Wochen oder zwei, sollte das so einigermaßen stabil werden und deswegen ist das Formular auch nur für 90 Tage, weil es kann sich ja auf dem Server eigentlich recht viel verändern und der Bedarf auf unserer Seite kann sich ja auch recht stark verändern und normalerweise nach 90 Tagen ist eigentlich eine ganz andere Situation wieder da. Wir kennen die Website, wir kennen den Server, wir wissen wie viel wir da schon einigermaßen crawlen können und dann sollte es eigentlich solche Probleme nicht mehr geben. Das ist eher problematisch, wenn man größere Umstellung macht, wenn man auf ein CDN wechselt oder eben wenn man ein Website Umzug macht, dann versuchen wir da ein bisschen mehr zu machen, als eigentlich sonst nötig wäre, einfach damit wir diese Veränderung schneller verarbeiten können. Alles klar, danke dir. Was kurze Zwischenfrage dazu, wenn man jetzt Server seitlich die Anfragen ein bisschen throtteln würde, hebt sich Googlebots das Budget dann für die Zukunft auf oder ist das verloren? Man kann mit zum Beispiel 503, kann man auf solche Anfragen auch antworten, was da normalerweise passiert ist, dass wir diese Anfragen versuchen, wir halt wieder neu irgendwann und im Laufe von dem Tag crawlen wir dann wahrscheinlich gleich wie wir sehen all diese Fehler und dann am Ende vom Tag passen wir die Crawling-Geschwindigkeit für den nächsten Tag entsprechend und so passt sich das an und für sich automatisch ein bisschen an, dass wir da ein bisschen zurück gehen mit der Crawling-Geschwindigkeit, wenn wir sehen, dass wir wieder mehr crawlen können, wenn der Server nicht mehr so mit 503 reagiert auf mehr Anfragen, dann versuchen wir das entsprechend auch wieder hochzuschrauben. Also es ist nicht so, dass man das aufsparen muss für irgendwie nächsten Monat, sondern das ist wirklich dann an und für sich pro Tag wird das eingeplant. Okay, danke. Okay, dann schauen wir mal die Fragen an, die da eingereicht worden sind. Wenn von euch zwischen euch noch Kommentare oder weitere Fragen dazu kommen, einfach nur loslegen. Würdest du folgenden Leitsatz für die Allgemeinheit unterschreiben? Ein No-Index-Verweis sollte niemals zusammen mit einem Canonical Tag verwendet werden. Gibt es da irgendwelche Ausnahmen? Ja, also bei uns ist hauptsächlich das Problem mit dem REL Canonical und dem No-Index in der Kombination, dass wir annehmen, dass mit einem REL Canonical meint der Wetmaster, dass diese beiden Seiten equivalent sind, dass wir die eine oder die andere Seite nehmen können für die Indexierung und das ändert an und für sich nichts. Wenn dabei aber eine Version mit No-Index-Tag ist und die andere ohne No-Index, dann ist in die Seite natürlich schon sehr stark unterschiedlich, weil eine kann indexiert werden, die andere nicht. Und dann ist es eigentlich nicht mehr ein Satz von Seiten, die wir für Canonical quasi zusammennehmen würden. Dann kann man ja nicht einfach beliebig zwischen der einen oder anderen URL wechseln, dann sind das ja eigentlich sehr unterschiedliche Seiten. Und deswegen sagen wir, dass man das eher nicht so kombinieren sollte, weil theoretisch könnte es passieren, dass wir mit dem Canonical Tag erst mal sagen, die Seiten sind equivalent und wir nehmen diese Seite aus diesem Satz von Seiten und das ist dann vielleicht die eine Seite, die No-Index hat und dann haben wir nichts von diesen Satz von Seiten indexiert. Das wäre wahrscheinlich nicht das, was ihr meint. In der Regel können wir solche Situationen auch abfangen und merken dann schon, dass das No-Index vorhanden also meint der Wetmaster wahrscheinlich, dass wir nicht diesen Canonical Tag an und für sich so trauen sollen, sondern dass da irgendwie versucht wird, andere Seiten zu indexieren. Das heißt, wenn ihr wirklich, wirklich wollt, dass bestimmte URLs nicht indexiert werden, würde ich nur No-Index nehmen. Wenn ihr hingegen einfach wollt, dass eine Version ausgewählt wird für die Suche, würde ich mit dem Canonical arbeiten und dann würde ich auch mit den anderen Canonicalization Methoden arbeiten, zum Beispiel redirects von der anderen Version, die interne Verlinkung sauber auf diese Version auch machen, Sidemaps intern entsprechend auch einrichten, dass diese Version eingereicht wird. All solche Sachen helfen uns dann, den Canonical auszusuchen, den ihr da wirklich gemeint habt. Und je klarer diese Signale sind, umso eher können wir den auch rollen und machen das entsprechend auch so. Wenn hingegen die Signale ein bisschen unklar sind, wenn der Canonical hierhin zeigt und die interne Verlinkung dahin und da ist noch ein No-Index dabei, dann ist es ein bisschen schwieriger für uns zu entscheiden, welche URL wir eigentlich nehmen sollen. Das heißt, ich würde jetzt sagen, in den meisten Fällen macht es keinen Sinn, das so zu kombinieren. Ich könnte mir vorstellen, dass es vielleicht irgendwelche Situationen gibt, wo man diese Kombination speziell auch für andere Suchmaschinen irgendwie verwenden möchte. Wenn man, ich weiß nicht mehr, dass andere Suchmaschinen mit dem REL Canonical nicht so gut klarkommen und dann eher aus irgendeinem Grund eine falsche URL nehmen, dann macht das vielleicht Sinn. Ich würde einfach das wirklich auch dann überwachen und überlegen oder aufpassen, dass dann nicht aussersehen, gar nichts indexiert wird, weil wir dann vielleicht ein No-Index-URL aus Canonical gewählt haben. Aus deiner Sicht macht es Sinn, wenn man die Staging-Domain nicht zugänglich für den Crawler macht mit IP-Blog und gleichzeitig mit No-Index-X-Robots-Tag und auch die No-Index-Robots-Metal-Tag verwendet. Oder was könnte man da am besten machen? Ich denke, es ist ein bisschen schwierig mit einem Staging-Domain, je nachdem, wie man das eingesetzt hat, wie man das machen kann intern. Wichtig für mich ist, dass ihr nicht ausversehen die falsche Version quasi freischaltet. Und je mehr ihr mit dem No-Index-Metal-Tag arbeitet oder Robots-Text oder mit dem X-Robots-Tag arbeitet, umso eher ist dann ein bisschen die Wahrscheinlichkeit, dass ihr diese Einstellung 1 zu 1 auf die Live-Site überträgt und dass ihr dann gar nicht merkt, dass ihr Google-Bot ausgesperrt habt. Und das sehen wir sehr oft, dass jemand, der die Staging-Version freischaltet und dann ist auf einmal per Robots-Text alles blockiert oder ist überall No-Index-Metal-Tag dabei. Und das ist, denke ich mal, nicht so angenehm für den Webmaster, bis man das überhaupt gemerkt hat und dann entsprechend auch behoben hat, kann das manchmal eine Woche oder zwei gehen. Hingegen, wenn man mit einem IP-Block arbeitet, dann ist es eigentlich von Anfang an sehr schnell klar, was da passiert. Das heißt, man sieht sehr schnell, ich kann darauf zugreifen, aber alle Kunden zum Beispiel können nicht mehr auf die Website zugreifen. Also habe ich da garantiert, irgendeine Einstellung falsch übertragen. Und dann sieht man sehr schnell, dass es falsch eingerichtet ist. Von dem her würde ich eher mit einem IP-Block arbeiten, also das Umgekehrte natürlich, dass man ein IP-Wide-List hat für die eigenen IP-Adressen, dass man die freischaltet, dass man das sieht oder dass man mit der server-sideigen Authentisierung arbeitet, sodass man quasi mit den Benutzernamen und Passwort sich da anmelden muss, um da hineinzukommen. Weil das sieht man ja auch sehr schnell auf der öffentlichen Website. Wenn man jetzt nicht mit diesen Einstellungen arbeiten kann, dann muss man halt schauen, ob solche Varianten übrig bleiben und dann muss man halt wirklich aufpassen, dass wenn man die Staging-Version freischaltet, dass man diese Einstellungen nicht weiter überträgt. Das heißt, dass man mit dem No-Index-Meditag aufpasst oder mit dem X-Robots-Tag aufpasst, dass man mit der Robots-Text-Datei aufpasst, dass wirklich alles sauber aufgeräumt ist, wenn man die Staging-Sites quasi freischaltet. Und auf jeden Fall, wenn man solche größere Umstellungen macht, würde ich mit Search Console mit Fetch and Render das anschauen, die Live-Version testen und das sieht man sehr schnell, klappt das oder klappt das nicht. No-Index sieht man natürlich nicht in der sichtbaren Version, aber zumindest Robots-Text kann man so schnell testen. Ist Text above the fold noch immer wichtig? Der Design-Trend ist ja seit einiger Zeit große Bilder und unten irgendwo Text. Wie sieht das aus? Ich denke, das Hauptproblem da ist, dass Benutzern nicht wirklich wissen, worauf sie gelandet sind, wenn sie dann durchklicken. Und wenn das beliebige Bilder sind, dann ist das natürlich, weiß man natürlich nicht, was das bedeutet. Wenn das hingegen Bilder sind, die zu den eigenen Inhalten auch wirklich passen, dann könnte ich mir schon vorstellen, dass das weniger problematisch ist. Die einzige Ausnahme, die wir haben, ist wirklich gezüglich einfach der Werbung above the fold. Das heißt, wenn above the fold hauptsächlich Werbung sichtbar ist und gar keine eigentlichen Inhalte, dann ist das natürlich ein besonders schlechtes User-Experience und das ist etwas, worauf wir zumindest auf der mobilen Version entsprechend auch ein bisschen achten. Aber wenn das Bilder sind, die wirklich zum Thema passen, die zu den einzelnen Seiten passen, dann sind das halt, ja, Design-Elemente, mit denen man arbeiten kann. Ob das jetzt die besten sind für die Benutzer oder nicht, das kann jeder selber für sich mit AB-Testing ausprobieren, aber zumindest von Google-Seite für SEO ist das weniger problematisch. Ich glaube, da kommt dann die Frage mit der HTTPS, mit dem Crawling, haben wir ja kurz angeschaut. Welche Rendering Engine kommt bei der Mobile First Indexierung zum Einsatz? Das ist die gleiche wie an und für sich die Desktop-Version, ich glaube Chrome 41, einfach mit den mobilen Einstellungen, das heißt mit dem kleineren Viewport und den Eigenschaften, die eher auf Mobilgeräten vorhanden sind. Sind AMP, Klein-Side-Rendered-Inhalte, zum Beispiel AMP-List und Server-Side-Rendered-Inhalte gleichwertig? Es hängt davon ab, wie man das implementiert, was man da macht. Wenn man mit Canonical AMP arbeitet, das heißt, man hat gar keine normale Website mehr, sondern nur die AMP-Version dieser Seiten, dann muss man natürlich darauf achten, ob diese Elemente auch wirklich gerendert werden können und dann kann man mit Fetch and Render in Search Console das relativ schnell testen und wenn sie gerendert werden können, ist das überhaupt kein Problem. Wenn sie nicht gerendert werden können, muss man sich halt überlegen, was man da entsprechend anpassen muss. Ich weiß jetzt nicht, ob gerade mit diesen AMP-Elementen irgendwelche Probleme bestehen. Ich weiß, dass da diverse Leute, die vorher auch in der Google-Suche gearbeitet haben, jetzt beim AMP-Team auch mithelfen. Von dem her vermute ich, dass sich auch solche Sachen auch geachtet haben, aber ich würde das auf jeden Fall immer selber auch testen. Wenn man nicht mit Canonical AMP arbeitet, wenn quasi die AMP-Version einfach zur normalen Version dazu quasi angeschlossen wird, dann ist es an und für sich egal, wie ihr das gestaltet auf der AMP-Version, weil dann ist ja die AMP-Version nicht das, was indexiert werden muss, sondern wir indexieren die normale Web-Version. Also um das nochmal zu verstehen, im Grunde die Inhalte werden gleichwertig ausgelesen. Also es gibt nicht zwei unterschiedliche Layer, dass man jetzt sagt, okay, Server-Side-Rendert ist jetzt ein Layer und ich habe eine Klein-Side-Rendert, einen zweiten Layer. Man kann sich das so vorstellen, dass es kleinzeitig gerendert wird und die Inhalte dann da gleichwertig ausgelesen werden. Fast, fast, ja, das heißt, was natürlich auf unserer Seite passiert ist, wir crawlen erst mal die normale Halt-Hart-TML-Version, das ist quasi die Server-Side-Rendert-Version und im zweiten Schritt machen wir dann das Rendering auf unserer Seite für solche Seiten und nehmen dann quasi anfühlt sich die endgültigen Elemente für die Indexierung entsprechend auf. Wenn da irgendwelche Links drin sind oder Bilder, die per Klein-Side-Rendering dazu gefügt werden, dann wird das einen für sich ganz normal weitergetragen. Aber sobald sie gerendert werden auf unserer Seite, wird nachher nicht spezielles mehr gemacht, das heißt, wir unterscheiden dann nicht mehr, wo sie ursprünglich herkommen, sondern behandeln sie gleichwertig wie alle anderen Elemente. Mir ist bei einem Test aufgefallen, dass wenn ich so eine Seite dann über Cache aufrufe, also die im Google indexiert wurde, dass es dann so ein cross-domain-scripting-error gibt. Ja. Das ist aber auch unbedenklich. Das ist unbedenklich. Das ist ein bisschen verwirrend, gerade mit JavaScript-Frameworks, weil wir caching die HTML-Version der Seite und wenn da Scripts drauf sind, die laufen können auf diesem anderen Hostname, dann können wir die auch entsprechend ausführen. Wenn da Scripts drauf sind, die wegen quasi cross-domain-Sicherheitselementen nicht laufen können, dann können wir die natürlich nicht ausführen. Das heißt, die gecaste Version sieht unter Umständen recht anders aus als die Version, die wir effektiv indexieren. Okay. Ganz schnellen Weg, wie man das auch testen kann, wenn man jetzt nicht Zugriff auf Search Console hat, ist mit dem Mobile-Friendly-Test. Da sieht man natürlich einfach die mobile Version, aber da werden auch die ganzen Inhalte so gerendert, wie Googlebot die rendern würde. Und da kann man dann relativ schnell feststellen, ob das jetzt ähnlich ist oder ob vielleicht den ganz leeren Seite einfach zurückgeholt wird von Googlebot, ohne dass man jetzt die Website neu verifizieren müsste. Guter Zeit. Danke. Okay. Und dann der letzte Teil der Frage, darf man mit ServiceWorker-Inhalte manipulieren? Kann man machen? Googlebot führt allerdings keine ServiceWorker aus. Das heißt, man muss einfach davon ausgehen, dass das, was mit dem ServiceWorker gemacht wird, für den Benutzer sichtbar ist, aber für die Indexierung nicht verwendet wird. Bei einem Kunden haben wir doppelte H1-Tags festgestellt, ein H1-Tag vom Mobile und ein für Desktop. Im CSS wird dann festgelegt, welche dargestellt werden soll. Ist das okay? Ja, kann man anfühlt sich so machen. Wir sehen wahrscheinlich beide H1-Tags und die Inhalte entsprechend und versuchen, die entsprechend aufzunehmen. Grundsätzlich ist das aber auch kein Problem. Man kann beliebig viele H1-Tags auf einer Seite nehmen. Es ist nicht so, dass wir da Sturr sagen, man darf nur eine Überschrift haben auf einer Seite, sondern gerade auch mit HTML5 ist es ja eigentlich auch gedacht, dass man mehrere H1-Tags verwendet auf einer Seite. Welche Vorteile bieten in Zukunft die Dot-com-Domains im SEO? An und für sich nichts Spezielles. Ich denke, bezüglich der Websuche allgemein oder bezüglich quasi den allgemeinen Umgang im Internet, sind das eher Aspekte, die Richtung Marketing gehen, das benutzt sich vielleicht ein Dot-com-Domain besser merken können, unter Umständen weiß ich nicht, aber zumindest auf Seiten von Google, von der Suchmaschine her ist es so, dass wir Dot-com-Domains den generischen Top-Level-Domains zuordnen und da gibt es eine ganze Menge und die ganzen neuen Top-Level-Domains sehen wir auch als generische Top-Level-Domains an, das heißt, man kann die Länderzuordnung selber machen, man kann mit Unterverzeichnissen oder Sub-Domains arbeiten für die Länderzuordnung und so das Geo-Targeting selber bestimmen und an und für sich unterscheiden wir da nicht zwischen Dot-com oder Punktnet oder auch den ganzen neueren Domains wie ich weiß nicht, Punkt Ninja habe ich gesehen, Punkt Guru, auch was vielleicht ein bisschen verwirrend ist, so Städte-Domains oder regionale Domains nehmen wir auch dazu, das heißt, wenn man Punkt Berlin hat, nehmen wir nicht automatisch an, dass was für Berlin ein Geo-Targeting da ist, sondern wir behandeln das wie jeder andere generische Top-Level-Domain. Das heißt, Dot-com würde ich jetzt nicht unbedingt sehen, als etwas, was man für SEO machen muss, sondern man muss sich das vielleicht eher im Rahmen vom allgemeinen Marketing überlegen, macht das Sinn mit Dot-com zu arbeiten, ist das etwas, was Benutzer in meinem Marktsegment erwarten oder vielleicht besser merken können oder kann ich mit einem lokalen Länder-Domain arbeiten oder nehme ich vielleicht einen ganz neuen Domain, irgendwas, was man sich noch besser merken kann, wo man vielleicht einen kürzeren Domain Namen kriegen kann, der vielleicht ein bisschen besser für die Werbung geeignet ist, all solche Sachen kommen ein bisschen dazu. Wie wichtig ist ein Content-Delivery-Network? Sollte man das für jede Website einsetzen oder welche Seiten, für welche Seiten empfiehlt sich das oder sollte man mit dem CDN von Google arbeiten oder von anderen? An und für sich, für SEO ist das irrelevant, das heißt, wenn wir eure Seiten crawlen und indexieren können, dann ist das für uns okay. Ob das von eurem Server direkt kommt, von einem CDN, den ihr betreibt oder mit denen ihr zusammenarbeitet oder ein Google-CDN ist, an und für sich, total irrelevant. Für Benutzer ist einfach ein CDN sehr praktisch, weil da oft die Website ein bisschen beschleunigt werden kann. Da kann man die Daten ein bisschen schneller ausgeben. Das Server muss das nicht immer verarbeiten. Man hat dann vielleicht auch regionale Stützpunkte, wo Benutzer direkt auf einen lokalen Server zugreifen können, statt dass sie immer direkt zu eurem Server geleitet werden müssen. Aber für Google, vom SEO-Standpunkt her, ist das an und für sich total egal, wie ihr dieses Hosting macht. Das einzige, was mit einem CDN manchmal dazu kommt, ist, dass wenn man wechselt von einem Hosting oder von einem CDN zu einem anderen CDN oder von einem CDN zur eigenen Hosting, dann merken wir, dass die Server-Infrastruktur sich stark verändert hat. Und dann ist Google-Baut meistens ein bisschen kritischer mit dem Crawling und crawlt eher ein bisschen langsamer, bis ein bisschen festgestellt werden kann, dass wir eigentlich wieder normal schnell crawlen können. Das heißt, was man meistens sieht, ist, dass die Crawling-Geschwindigkeiten ein bisschen zurückgeht, erst einmal, auch wenn der Server die Daten viel schneller ausgeben kann. Und dann im Laufe der Zeit wird das wieder erhöht, etwa auf das gleiche wie vorher wahrscheinlich. Und entsprechend sieht man dann einfach, wenn man die Grafiken anschaut oder die Server-Logs anschaut, sieht man, ah, Google-Baut crawlt jetzt weniger. Aber das ist nicht unbedingt ein Zeichen, dass irgendwas schief ist oder dass irgendwas kaputt ist, sondern dass es einfach das Google-Baut ein bisschen sicher sein möchte, dass bei einer größeren Serverumstellung, dass Google-Baut nicht noch neue Probleme verursacht, die der Server dann vielleicht gar nicht gut verarbeiten kann. Titel und Altattribute bei Bildern. Wenn sich nur einer der beiden setzen lässt, welchen würdest du vorrangig empfehlen? Ja, schwierig zu sagen, weil Titel ist auch für sich etwas, was beim Link dazu nimmt und Alt ist etwas, was man beim Bild, bei der Bild-Einbindung quasi verwendet. Das heißt, wenn ich jetzt nur Bilder in einer Seite einbinde, dann nehme ich die Altattribute. Wenn ich die Bilder als Enker nehme zu vielleicht einer größeren Bilder-Landing-Page, dann kann man mit dem Titelattribut arbeiten. Ich würde von dem her gerade für die Bildersuche, würde ich eher mit dem Altattribut arbeiten, weil das direkt wirklich auch mit dem Bildwerk bunt ist und nicht quasi kombiniert wird mit einem Link, der noch zusätzlich dabei ist. Aber ich denke, das muss man halt schauen, wie man das machen kann auf der eigenen CMS. Es ist ja dann nicht so, dass ein CMS einfach sagt, du darfst irgendwie ein von beiden wählen, aber nicht beide, sondern man hat entweder die Möglichkeit, diese zu setzen oder nicht zu setzen und dann nimmt man halt das, was man machen kann. Search Console Crawling kannst du uns bitte abrufen durch Google, das Search Console näher erläutern. Wenn die Teile der Seite trotz 200 dann nicht erreichbar waren, sollt man die Seite gleich nochmals abrufen oder wäre es wäre da die Empfehlung. Warum dauert das manchmal so lange? Ich denke, da sind zwei Aspekte, die da zusammenkommen. Da ist es manchmal nicht so einfach festzustellen, ob das jetzt auf der Server-Seite ist, quasi bei dir als Webmaster oder bei uns auf der Google-Seite. Etwas ist, weil manchmal klemmen bei uns die Systeme auch und dann geht dieser abruft euch Google irgendwie aus irgendeinem Grund, geht es halt nicht euch. Dann sagt man halt, ja, im Moment funktioniert das nicht, ist ein temporärer Fehler, probiere es einfach noch mal ein bisschen später. In der Regel ist es eher so etwas, dass man einfach dann halt ein paar Minuten wartet und dann probiert man es noch mal und dann kommt das durch. Und das würde ich jetzt nicht unbedingt als etwas Kritisches ansehen, das kann eigentlich immer wieder mal vorkommen. Beim normalen Webcrawling passiert das auch ab und zu, bloß machen es so viele Anfragen auf den Server innerhalb von Tag oder so, dass da die einzelnen, die nicht durchgehen, von unserer Seite her unproblematisch sind. Das Einzige, wo das vielleicht von eurem Server kommen kann, ist, wenn der Server wirklich so an seinen Limiten ist, dass wir das Gefühl haben, wir dürfen nicht mehr crawlen von diesem Server, weil sonst irgendwelche Probleme verursacht werden. Das merkt man aber meistens auch selber, wenn man mit der Website arbeitet, dass man sieht, die Website ist wirklich sehr langsam. Das heißt, selbst wenn man als Benutzer die Website anschaut, merkt man, jede Seite braucht es sehr lange zum Laden. Wenn man in Search Console die Crawl Statistiken anschaut, dann sieht man, die deutschendliche Zeit zum Crawlen ist relativ hoch. Wenn man verschiedene Websites hat, kann man das ein bisschen vielleicht einordnen. Meistens sind schnellere Websites zum herunterladen von einzelnen Ressourcen vom Server und wirklich sehr langsamer Seiten sind dann mehrere Sekunden. Tausende von Millisekunden werden da angegeben. Das ist dann vielleicht schon ein Zeichen, dass der Server vielleicht ein bisschen an seinen Grenzen ist und dass man sich da überlegen müsste, was könnte man machen, um diese Infrastruktur ein bisschen zu verbessern. Einerseits kann man natürlich mehr mit Caching arbeiten, mit ein bisschen sauberen Code, mit besseren Code, wenn man jetzt ein kompliziertes CMS hat. Andererseits kann man auch einfach zum Hoster gehen und sagen, ich hätte gern einen schnelleren Server. Das bezahlt man vielleicht ein bisschen mehr, aber dann hat man natürlich auch ein Server, der vielleicht einen deutlichen Schnitt schneller ist, mehr RAM, mehr Gefühligkeit, was auch immer da vielleicht geklemmt hat. Und das sind dann Sachen, die die Merkt Google baut dann auch. Wenn wir crawl und sehen, dass Server reagiert wieder schneller, dann können wir unser CrawlBudget an für sich schnell wieder anpassen und sagen, gut, das Server ist jetzt schneller. Wir versuchen ein bisschen mehr zu crawl und dann geben wir auch bei Abruf wie durch Google entsprechend auch ein bisschen mehr Toleranz und sagen, gut, ihr könnt da problemlos noch mehrere Seiten selber testen, weil wir wissen ja, dass wir nicht an die Grenzen von Server kommen, also ist das unproblematisch für uns. Das heißt, lang gesagt würde ich da vielleicht bei den Crawl Statistiken nachschauen, ob der Server allgemein eher langsam ist. Wenn er eher langsam ist, würde ich mir überlegen, was man da machen kann, um das zu verbessern. Wenn der Server dort eher schnell auf der schnellen Seite ist, dann waren das wahrscheinlich einfach irgendwelche temporären Fehler auf unserer Seite. Wie kann es sein, dass Google meine Unterseite mit dem Longtail Produkterfahrung, Produkterfahrungsberichte auf eintrannt, aber nicht mit dem Flora Produkterfahrungen. Ist Google doch nicht so schlau? Ich würde mal behaupten, Google ist noch lange nicht schlau genug. Es gibt immer etwas, was da verbessert werden kann oder was da verbessert werden sollte. Ob das jetzt der Fall ist mit diesem speziellen Query oder nicht, weiß ich jetzt nicht. Grundsätzlich ist es so, dass wir nicht irgendwelche Sprachmodelle bei uns implementieren, um die Sprache quasi auf einer theoretischen Ebene auseinanderzunehmen und zu sagen, ah, das ist jetzt ein Plural und das Singular. Also ist das genau das gleiche gemeint. Also müssten wir die Ergebnisse genau gleich herausliefern, sondern wir versuchen gerade so synonyme eher aufgrund von dem, wie Benutzere reagieren auf die Seiten zu lernen. Das heißt, wir lernen dann eher, dass dieses Wort eigentlich identisch ist wie das, weil Benutzer, die nach diesem Wort suchen, zufrieden sind wie mit den gleichen Ergebnissen wie mit den anderen. Und so können wir das ein bisschen automatisch lernen, ohne dass wir jede Sprache, alle Wörter irgendwie in einem Wörterbuch erfassen müssen und das manuell durchsortieren müssen. Das heißt, was da vielleicht passiert, ist entweder haben wir das noch nicht gelernt, dass diese beiden Suchbegriffe equivalent sind, oder es kann natürlich auch sein, dass Benutzern mit diesen Suchbegriffen tatsächlich etwas unterschiedliche suchen. Und manchmal ist das ein bisschen erstaunlich, aber das gibt es eigentlich immer wieder, dass Wörter, die sehr ähnlich sind oder wo man sagen würde aufgrund der Sprache, sollten sie eher identisch sein. Das Benutzer, die wirklich in anderen Arten verwenden und das dann entsprechend auch Sinn macht, dass man leicht unterschiedliche Suchegebnisse ausliefert. Seit Februar können wir kein Ranking mehr für unsere Kategorienseiten erzielen. Angezeigt werden meistens immer nur einzelne Produkte. Das Produkt wechselt von Zeit zu Zeit. Kannst du das mal anschauen. Also ich habe das kurz vorher ein bisschen angeschaut. Und was ich da gesehen habe, ist, dass zumindest die URLs, die da angeben worden ist, sich im Laufe der Zeit immer wieder leicht verändert hat. Und dass wir da entsprechend die ganzen Signale immer wieder erst mal neu überlegen mussten, neu quasi berechnen müssten aufgrund der Rest der Website und dann entsprechend auch weitergeben konnten an die neue URL. Das heißt, ich glaube seit Anfangjahr, wo ich das angeschaut habe, sind da drei oder vier Varianten dieser URL aufgetaucht. Und das hat sich dann immer wieder live verändert. Und natürlich jedes Mal, wenn man eine solche URL-Umstrukturierung macht innerhalb einer Website, meistens ist es ja nicht nur eine URL, sondern es sind dann mehrere URLs innerhalb der gleichen der ganzen Website, dann braucht es einfach Zeit, bis sich das wieder einpendelt. Und wenn man das einmal macht, dann muss man halt warten, bis das wirklich alles verarbeitet ist. Wenn man dann natürlich danach wieder das Gleiche macht, dann braucht es nochmal Zeit, bis es verarbeitet ist. Und wenn man es nochmal macht, dann braucht es einfach immer wieder ein bisschen mehr Zeit, bis wirklich alles verarbeitet ist. Das heißt, was ich machen würde in einem solchen Fall ist die URL möglichst lange wirklich beiderhalten. Und wenn man eine URL-Umstrukturierung plant, wenn ich jetzt zum Beispiel die URLs von Punkt HTML auf ohne HTML umwandeln möchte, dann würde ich einerseits damit rechnen, dass es sicher ein zeitlanger Schwankungen gibt, dass man da vielleicht nicht mehr so sichtbar ist in der Suche, bis das wirklich sauber verarbeitet ist. Manchmal kann das sogar mehrere Monate gehen. Andererseits wegen diesen Schwankungen würde ich mir überlegen, wie kann ich diese URL so umstrukturieren, dass ich wirklich längerfristig mit der gleichen URL möglichst lange weiterleben kann. Das heißt, wenn man eine solche Umstrukturierung macht, dass man sich vielleicht überlegt, wie kann ich die URLs so gestalten, dass sie nicht mehr vom CMS abhängt. Das heißt, wenn vorher mein CMS immer vom PHP verwendet hat, vielleicht macht es Sinn, dass man das PHP wegnimmt, damit man dann nachher auf irgendein anderes System wechseln kann, welches vielleicht nicht mit PHP funktioniert und die gleichen URLs weiterbehalten kann. Wirklich, wenn man eine Umstellung der URL-Struktur macht intern, dass man sich überlegt, welche Struktur kann ich nehmen, die in den nächsten fünf Jahren Größenordnung wahrscheinlich noch beibehalten werden kann. Und dementsprechend würde ich auch eine URL-Umstrukturierung nicht einfach so kurz machen, so quasi, wenn man von anderen SEO-Blogs liest, ah, mit einem Schrägstrich am Ende ist das besser als ohne Schrägstrich am Ende, dann würde ich das nicht einfach schnell umstellen, sondern dann würde ich wirklich erst mal in Ruhe das anschauen und überlegen, was macht wirklich Sinn längerfristig und kann ich mit Schwankungen leben, wenn sie jetzt auftauchen aufgrund einer solchen Umstellung. Wichtig ist natürlich auch, dass Google unterscheidet die URLs aufgrund von der absoluten URL, die angegeben worden ist. Das heißt, ob jetzt ein Schrägstrich am Ende da ist oder nicht, ist für uns, sind zwei unterschiedliche URLs oder mit Punkt-H-Themele oder ohne Punkt-H-Themele, das sind wirklich zwei unterschiedliche URLs und wir merken dann nicht quasi, ah, das ist fast das gleiche, also können wir das eigentlich so weiter verwenden, sondern wir müssen dann aufgrund von redirects von dem ganzen alten Version zur aktuellen Version kommen können und müssen das Ganze dann wirklich neu verarbeiten und manchmal geht das wirklich mehrere Monate, bis es sauber verarbeitet ist. Wir haben vor ein paar Tagen unser Eventportal von einer.net zu einer.de Domain umgezogen. Der Domainumzug wurde auch über die Funktionen Search Console bekannt gegeben. Nun tauchen im Bereich links zu ihrer Website über eine Million angebliche Backlinks vom alten Domain auf. Die werden alle weitergeleitet, ist das ein Problem, ist das problematisch? Manchmal passiert das. Das ist an für sich total unproblematisch, dass es gerade im Rahmen von einem Domainumzug kann es sein, dass wir das Gefühl haben, die alten URLs und die neuen URLs sind equivalent und dann sehen wir auf den neuen URLs links zu den neuen URLs und denken, ah, das ist das Ähnliche, wie wenn vom alten URLs ein Link auf die neuen URL wäre und zeigen das entsprechend so in Search Console. Das heißt, an für sich, wenn ihr sicher seid, dass das technisch sauber eingerichtet ist mit dem redirect, ist das vollkommen okay, könnt ihr das total ignorieren. Wir betreiben ein Eventportal mit deutschlandweiten Veranstaltungskalender. Alle Events sind über markupschema.org ausgezeichnet. Wir sehen allerdings nur 750 Elemente angezeigt in Search Console. Viele Seiten stehen auf No Index und dann hat es da so regionale Seiten mit verschiedenen Events drauf und man wird auf kein Eventsnabbet angezeigt. Normalerweise, wenn die Fragen so lang und detailliert werden, macht wahrscheinlich eher Sinn, dass man da im Hilfeforum vielleicht ein Thread aufmacht, um das ein bisschen genauer anzuschauen mit anderen zusammen. Im deutschen Hilfeforum sind da verschiedene Aktiv, die eigentlich sehr gut mit solchen Webseitproblemen zurechtkommen. Englischen Forum natürlich auch und da würde ich da zu einem Fall vielleicht eher dort mal nachfragen. Ein bisschen, was mit der Auffeld ist, gerade mit dem No Index, könnte ich mir schon vorstellen, dass da ein bisschen kompliziert wird für uns, weil wenn wir den Structured Data auf Seiten mit No Index sehen, können wir das natürlich nicht weiterverwenden. Wenn hingegen mit Rail Canonical zum Beispiel gearbeitet wird, dann können wir das eher auf den Canonical weitergeben und dort verarbeiten. Das ist mal die eine Sache. Die andere Sache ist mit quasi diesen Listen von Veranstaltungen, weiß ich nicht, gerade bei Eventmarkup, ob es da irgendwelche speziellen Policy-Sachen, die man vielleicht berücksichtigen müsste. Weil das sind ja unterschiedliche Events und normalerweise ist es so, dass wir auf einzelnen html-Seiten erwarten, dass das Structured Data auf das bezogen wird, was jetzt als Hauptelement von dieser Seite gesehen wird und wenn man verschiedene Sachen auf die gleiche Seite nimmt und die mit Markup versieht, könnte ich mir vorstellen, dass unsere Systeme da leicht verwirrt werden. Ich weiß allerdings nicht, ob gerade bei Events, ob das ein bisschen anders dort ist als zum Beispiel mit Reviews. Von dem her würde ich da wirklich im Hilfeforum nachfragen und schauen, was die anderen dazu meinen. Und da könnt ihr dann auch einzelne URLs angeben. Die Top Contributors im Hilfeforum können das entsprechend auch weitergeben an uns, dass wir das ein bisschen genauer anschauen. Aber wahrscheinlich müsste man da wirklich auch die einzelnen Suchanfragen mal angeben und die URLs angeben, wo ihr die Probleme seht. Ist es sinnvoll, unterschiedliche Inhalte auf Subdomains zu hosten? Also Shop auf www.carriereportal auf Careers und FAQ auf Ask. Profitieren die Subdomains voneinander oder konkurrieren sie, wie wäre es besser, alles auf www zu haben? Ja, ich weiß nicht, die Frage Subdomain oder Sub Directory, das ist glaube ich eine ewige Frage, die immer wieder aufkommt. Ich habe neulich beim Search Quality Team gerade wegen dem mal nachgefragt, weil ich gedacht habe, ich möchte einfach mal sicher sein, dass wir wirklich das Richtige auch sagen und aus ihrer Sicht ist es wirklich egal, welche Variante ihr nehmt. Ob ihr das auf Subdomains nehmt oder auf Subdirectories, das ist total euch überlassen. Manche unterscheiden das so quasi nach Branding, dass man sagt, das ist irgendwie gehört zu diesem Teilbereich und das möchte ich wirklich ganz abgegrenzt haben vom Rest meiner Website. Andere machen das vielleicht einfach aus technischen Gründen, dass sie sagen, mein CMS läuft auf www und ein anderes CMS muss ich separat auf dem anderen Subdomain hosten, auf dem anderen Server und da macht das vielleicht auch Sinn. Manchmal macht es auch Sinn, dass man alles auf www zusammen nimmt, einfach damit man das ein bisschen einfacher hat in der Wartung, weil gerade mit unterschiedlichen Subdomains müsst ihr auch die Einstellungen in Search Console separat vornehmen und entsprechend das ganze dort auch separat warten. Das heißt, für Crawling Fehler schauen, all die Sachen, die mit einer normalen Website verbunden sind, sieht man natürlich in Search Console dann separat. Das heißt, es ist ein bisschen mehr Aufwand, wenn man mit Subdomains arbeitet, als wenn man mit Subdirectories arbeitet. Manchmal ist es trotzdem unterm Strich einfacher, mit Subdomains zu arbeiten, ist an und für sich euch überlassen. Zwei Fragen bezüglich internen Links. Wenn ich mittels Logo auf meiner Startseite linke und dann auch noch auf der Unterseite, auf die Startseite mit dem Anchor Text verweise, werde im Anchor Text Link überhaupt noch einen Wert bemessen. Ja, wir sehen an und für sich beide Links und nehmen das entsprechend als Kontext für diesen Link auch noch dazu. Meistens ist das ja auch ganz normal, dass quasi der erste Link mit dem Logo direkt zur Startseite verlinkt wird. Dann hat man irgendwo noch einen anderen Link zur Startseite, vielleicht mit einem Text Anchor. An und für sich ist das eine normale Struktur. Haben Keywords im Futter einen negativen Einfluss auf SEO oder ist das nur, wenn man einen Link-Farm im Futter hat? Meistens, was ich sehe mit Keywords und mit diesen quasi Bündel an Links, den viele im Futter haben, ist, was da passiert ist, ist unsere Systeme, dass er als Keywords Stuffing anschauen und sagen, ja, da steht jetzt sehr viel da, aber das sind alles nur Keywords und wahrscheinlich müssen wir dem nicht so viel Wert bemessen. Das heißt, meistens ist es nicht so, dass man irgendein Vorteil daraus hat, wenn man jetzt irgendwie alles Mögliche untereinander verlinkt im Futter. Ähnlich wie das wäre, wenn man das einfach so in der Seite alles Mögliche quer verlinkt. An und für sich ist wahrscheinlich der Wert unterm Strich weniger, als wenn man das einfach so verlinkt, wie das für den Benutzer auch wirklich Sinn machen würde. Aber ob das jetzt negativen Einfluss insgesamt hat oder nicht, ist natürlich schwierig zu sagen, wenn wir erkennen können, dass es Keywords Stuffing ist, dann ignorieren wir das eher. Das heißt, es schadet dann an und für sich nicht. Aber es macht es natürlich so, dass die anderen Links, die da vorhanden sind, die eher relevant sein sollten, sind natürlich auch ein Teil von diesem Bündel auf einmal und den geben wir dann vielleicht nicht so viel Wert, wie man sonst geben würde. Von dem her würde ich wirklich schauen, dass man da ein bisschen sich überlegt, wie man das wirklich machen möchte und das so gestaltet, wie das auch wirklich Sinn machen würde für Benutzer und nicht nur auf Hinblick darin, dass Google Word auf einmal diese Seiten crawling geht und schneller indexieren geht, weil normalerweise finden wir diese Links ja sowieso und können die genug schnell auch sonst indexieren. Nach einem Domainwechsel habe ich die URLs der vorherigen Domain auf die neuen Domain weitergeleitet und da tauchen auch die Links vom alten Domain entsprechend auf. Eben wie gesagt, vorhin ist es an für sich normal, dass man da manchmal die Links vom alten Domain zum neuen Domain sieht. Für uns, was passiert mit den Links allgemein ist, dass wir die Links zwischen einzelnen Canonicals haben. Das heißt, wenn ein Link vorher auf die alte Seite verwiesen hat, quasi von extern auf die alte Seite, und wir mit dem Redirect erkennen können, dass eigentlich für diese alte Seite ist jetzt die neue Seite zuständig und das ist jetzt der Canonical, dann werden wir diesen Link entsprechend auch weiterleiten und sagen, dieser Link ist jetzt neu zwischen dieser externen Seite und diesem neuen Canonical. Und dementsprechend, wenn man in Search Console dann nachschaut, sollte man eigentlich auch auf dem neuen Domain die Links sehen, die ursprünglich zum alten Domain gezeigt haben. In der Regel braucht das ein bisschen Zeit, bis das alles verarbeitet ist, also sieht man das nicht von Anfang an, aber sagen wir mal nach einigen Wochen, sollte man da schon sehen, dass das entsprechend weiter gereicht worden ist. Wir empfehlen trotzdem, dass die wichtigen Links möglichst auch angepasst werden, dass sie direkt auf den neuen Domain gehen, einfach damit benutzen, ein bisschen schneller auf diese Seiten kommen, auch damit in Zukunft, wenn man dann jetzt nochmal einen Domain wechselt, irgendwann nach ein paar Jahren macht, dass man sich nicht allzu viele Sorgen wegen diesem Ur-Uhr-Domain auch noch machen muss. Mit dem Keyword Foto-Buch ranked seit einiger Zeit eine Firma mit drei Positionen auf Seite eins. Wir wissen, dass die Firma sehr stark ist und wahrscheinlich einen Bonus von euch bekommt, dennoch stehen andere Marken der Produkten in nichts nach. Was kann man machen, damit diese andere Website dann nicht so präsent ist in den Suchergebnissen? Grundsätzlich gesagt ist es bei uns eigentlich nicht so, dass Websites irgendein Bonus von uns bekommen, nur weil sie sehr stark sind, sondern das sind ganz normale organische Ranking-Algorithmen, die da im Spiel sind, die versuchen festzustellen, welche Seiten sind jetzt relevant für Benutzern, die nach diesen einzelnen Keywords suchen. Und manchmal ist es wirklich der Fall, dass wir einige Resultate von der gleichen Website zeigen oder von der gleichen Firma zeigen auf der gleichen Suchergebnisseite. Wir haben dann nicht irgendeine Obergrenze, wo wir sagen, das dürfen maximal zwei Ergebnisse von der gleichen Website erscheinen oder drei, sondern manchmal sind das wirklich mehrere. Manchmal ist das dann wirklich nur ein Eintrag von dieser Website und das versuchen unsere Algorithmen an und für sich automatisch zu machen. Wir machen da nichts manuell diesbezüglich. Das heißt, in einem solchen Fall, wenn man natürlich im Konkurrenz steht mit einer Website, die so sichtbeißen Suchergebnissen, ist es nicht so, dass man da mit den Google Engineers einfach sprechen kann und sagen kann, hey, könnt ihr die nicht ein bisschen herunterstufen oder ein bisschen weniger sichtbar machen, sodass andere auch eine Möglichkeit haben, da zu erscheinen, sondern man hat dann einfach wirklich einen stark umkämpften Markt und entsprechend muss man vielleicht auch selber überlegen, was kann man machen, dass man selber mehr sichtbeißen Suchergebnissen oder was könnte man vielleicht kreatives machen, damit man nicht mit diesem einzelnen Suchbegriff so stark konkurrenzieren muss. Manchmal sind das zum Beispiel Sachen, bezüglich Branding, die man machen kann, dass man vielleicht irgendwelche Werbekampagnen macht und sagt, statt Fotobuch sollt ihr nach, ich weiß nicht, Fotobuch XYZ suchen, weil das sind die besten Fotobücher. Das Leute dann wirklich auch gezielt nach eurer Marke suchen, weil gerade wenn jemand nach eurer Marke sucht oder nach einem Website nahmen, dann ist hier eigentlich klar, was sie suchen wollen und dann ist für unsere Algorithmen auch klar, ah, jemand sucht nach dieser Website, also wäre es ein Fehler, wenn wir nicht diese Website an erster Stelle zeigen würden oder vielleicht sogar mehr Positionen in den gleichen Suchergebnissen. Das heißt, ja, an und für sich gibt es ja keine Zauberlösung, es gibt einfach manchmal sehr stark umkämpfte Märkte und dann muss man vielleicht selber ein bisschen überlegen, wie kann man da auf reagieren, was kann man da machen, um trotzdem einigermaßen konkurrenzfähig zu sein. Wir ranken ab und zu mit dem Keyword Fotobuch, wie gesagt, Fotobuch auf Seite 1, im vierten Quartal des letzten Jahren deutlich besser als im aktuellen. Wie kommt es, dass das Ranking einer URL zu bestimmten Keywords starken Schwankungen unterliegt und was kann man tun, um das zu stabilisieren. Ja, das kann natürlich immer passieren, dass es Schwankungen gibt. Wir passen unsere Algorithmen an für sich immer wieder an und wir berechnen die ganzen Daten, mit denen die Algorithmen arbeiten, wieder neu von Zeit zu Zeit und da ist es an für sich normal, dass es Schwankungen gibt. Und gerade, wenn man jetzt über einen längeren Zeitraum hinweg das anschaut, wenn ich jetzt sage, dieses Jahr im Vergleich zu letzten Jahr, dann sind das sehr viele Sachen, die sich verändert haben auf unserer Seite in den Algorithmen, aber auch insgesamt im Internet und dann wäre es an und für sich fast unnatürlich, wenn genau das gleiche Ranking wie früher bestehen würde. Weil andere Websites passen sich an, arbeiten daran, dass sie immer, immer besser werden und dann muss man natürlich auch ein bisschen mitziehen und wirklich auch mit überlegen, was kann man machen, um noch relevanter zu sein, um noch interessanter für Benutzer zu sein in diesen Bereichen. Und das sind Sachen, die sind nicht sehr einfach manchmal. Manchmal sind das wirklich auch sehr schwierige Märkte. Für ein Österreich-Projekt ist HTTPS Domain.at angelegt worden und dann würde ich gerne quasi mit bevorzugten Domain arbeiten in Search Console, aber dann müsste ich die HTTPS Version auch noch verifizieren und die gibt es nicht mehr. Was kann man machen? Eine Sache, was man machen kann, ist, dass man per DNS Verification arbeitet, dann ist HTTPS oder HTTPS irrelevant, dann geht das auf jeden Fall. Das andere ist, dass man wahrscheinlich mit dieser bevorzugten Domain-Einstellung nicht unbedingt etwas machen muss. Wenn die Website wirklich seit Anfang an mit WWB oder ohne WWB vorhanden war, dann ist es ja auf unserer Seite nicht eine Frage, dass wir aus Versehen die falsche Version zeigen würden in den Suchergebnissen, sondern dann ist ja die richtige Version von Anfang an ganz klar. Und von dem her würde ich mir im ersten Moment nicht so groß den Kopf zerbrechen. Ich denke, das braucht ihr wahrscheinlich in diesem Fall nicht zu machen. Wenn ihr es trotzdem verifizieren wollt, würde ich mit der Domain-Verifizierung, also über DNS, das vielleicht anschauen. Manchmal ist das auch einfach eine gute Übung, dass man weiß, wie das funktioniert, damit im nächsten Fall, wenn jemand kommt und sagt, ich kann keine Mattertags setzen oder ich kann keine Datei auf meinem Server laden, dass man auch auf das zurückgreifen kann. Puh, immer noch mehr Fragen. Wahnsinn. Mal schauen, was mir noch schnell beantworten kann. Ich betreibe eine Reihe von Websites, die zusammen miteinander im gleichen Thema quasi arbeiten. Es ist kein Private-Blog-Network, aber halt eine Visible-Blog-Network, von dem Sie sehen, dass man diese Verknüpfungen nicht verstecken will und kann man die irgendwie den Quality-Rating mitteilen, dass Sie wissen, dass diese Websites zusammengehören. An und für sich muss man da nicht spezielles machen. Wir erkennen solche Situationen in der Regel schon und gerade im Vergleich zu einem Private-Blog-Network, wo da wirklich eigentlich sehr klar ist, was da passiert, ist das gerade mit einer Handvoll-Websites, da steht jetzt ca. 10 Websites, sehe ich da überhaupt kein Problem. Ich würde mir aber trotzdem überlegen, ob es Sinn macht, längerfristig das als 10 Websites zu betreiben oder ob es nicht vielleicht Sinn machen würde, eine stärkere Website daraus zu machen, einfach damit man weniger Arbeit mit der ganzen Verwaltung und mit dem Weiterführende Website hat und dass man wirklich ganz klar dann auch nicht überlegen muss, könnten diese Links vielleicht jetzt als Paid Links angesehen werden oder nicht, sind ja eigentlich beides meine Websites, sondern dass man wirklich auch klar einfach zwischen den einzelnen Teilen der gleichen Website sauber verlinken kann. Aber gerade mit 10 Websites würde ich das jetzt eh nicht so problematisch ansehen. Ja. So, ich habe noch ganz kurz eine Frage. Und zwar, wenn ich zu Meta-Tex und Resnip jetzt, wenn ich jetzt quasi die Meta-Description vorgebe und auch bei ItemProb die Description, wie hoch ist die Wahrscheinlichkeit, dass Google quasi sich trotzdem dann random Element raus sucht, um das als Description in den Organic Search Results anzugeben. Das heißt, hierantiert ersetzen von Meta-Tex oder Meta-Description 100-prozentige Vorgaben? Nein. Wir nehmen, ich glaube sowieso nur den Meta-Description, den Meta-Tag und den Structure Data nehmen wir nicht als Description für den Snippet und es ist eigentlich, ja, es ist normal, dass wir den leicht anpassen, je nach Suchanfrage auch. Das ist vielleicht etwas, worauf man achten muss. Wenn ich jetzt nur eine Seit-Anfrage mache, dann ist das Snippet, sag ich mal, unnatürlich, oder die Suche ist unnatürlich aus unserer Sicht und das Snippet entspricht dann nicht unbedingt dem, was Benutzer sehen würden. Das heißt, wenn ich in Search Console die Keywords anschaue und nach den Keywords dann auch suche, dann sieht man, welcher Snippet wirklich für diese Benutzer angezeigt wird. Okay, perfekt, danke sehr. Okay, wer hat noch eine letzte Frage? Schon, ich habe eine letzte Frage, wenn ich darf. Super, Niklas. Alles klar. Folgendes. Wir haben einen Kunden und dieser Kunden hat eine Seite mit bestimmten Overlays und diese Overlays werden über Hash angesprochen. Jetzt ist es so, entgegen unseren Erfahrungen und auch was man so über Crawling lesen kann, wurden jetzt diese Hash URLs indexiert. Also wir konnten wirklich ein Index eigenständiger Suchergebnisse finden. Jetzt ist die Frage, wenn jetzt Backlinks aufgebaut werden oder einfach Backlinks vorhanden, sind es die, die auf diese Hash URLs zeigen, welche URL wird einem Endeffekt dann gestärkt, tatsächlich die Page dahinter, also die ganz normale URL, oder die URL inklusive Hash? Das ist gerade die Frage, die wir haben. Ja, es ist sehr selten, dass wir die so indexieren, aber das kann vorkommen, wie jetzt da und wenn das vorkommt, dann werden die Links entsprechend auch auf diese Hash URL weitergegeben. Okay, alles klar. Das wird nicht aggregiert, irgendwie zu einer URL mit einem Hash-Varianten, sondern es geht, okay. Ich würde aber das Ganze vielleicht ein bisschen im Auge behalten, weil es kann sein, dass unsere Systeme irgendwann das Gefühl haben, wir brauchen das nicht unbedingt bei diesen Seiten und wir indexieren dann wirklich nur diesen Startteil der URL wieder. Aber wenn es im Moment funktioniert, ist schon mal praktisch für euch, wenn ihr eine Weiterleitung machen möchtet, also wenn ihr dann Redirect einrichten wollt von diesen Hash URLs, so ein sauberer URL-Struktur, müsst ihr das einfach per JavaScript machen. Okay, alles klar. Geht es hier noch eine zweite schnelle Frage aus, oder? Ein anderer Kunde hat eine Dot-Kom-Domain und die unterschiedlichen Länder und Sprachen werden über die Ur-Struktur abgebildet, also einfach über Subdirectories. Es sind insgesamt 52 Länder und deswegen haben wir uns entschieden, die hreflang Informationen in den XML-Seitmaps zu implementieren aufgrund PageSpeed. Jetzt ist es so und es ist auch schon sehr oft vorgekommen, dass trotz korrekter Implementierung in den USA beispielsweise die Canada Person ranked, was dann ja zu politischen Problemen führt für diesen Kunden. Wir haben sehr viele Signale überprüft, also angefangen von backlinks und Engagement-Signale und da scheint eigentlich alles zu passen. Auch die hreflang Informationen sind korrekt. Unsere Hypothese, meine Frage, wir haben uns ein bisschen die log files angesehen und konnten da feststellen, dass die XML-Seitmaps nicht so oft gecrawled werden wie andere Ressourcen. mag es vielleicht besser sein, dass wir die hreflang Informationen auch oder nur im Quellcode implementieren? Was meinst du, ist das Zweckscrawling einfach besser? Oder ist es so, dass hreflang sowieso wie Canonicals auch nur noch als Empfehlung gesehen werden und nicht mehr wirklich zu 100% berücksichtigt werden? Ja, alles ein bisschen. Also wenn es in der Sitemap vorhanden ist, können wir das Bein lesen, das Sitemap aufnehmen, aber wir verarbeiten das erst, wenn wir die Seite selber auch neu gecrawled haben. Das heißt, da ist sowieso schon ein bisschen Zusammenhang da. Das heißt, einerseits die Sitemap müssen wir zuerst crawlen und danach crawlen wir diese Seite. Meistens ist ja dann vielleicht auch ein Änderungsdatum in der Sitemap-Partei dabei, damit wir wissen, diese Seite müssen wir wirklich auch jetzt crawlen und dann wird es verarbeitet. Das heißt, eigentlich sollte es eigentlich fast keinen Unterschied geben, ob man jetzt den hreflang auf der Seite selber oder in der Sitemap-Partei einsetzt. Was beim hreflang ein bisschen noch dazukommt, ist, dass wir natürlich die einzelnen Paare erst mal crawlen und indexieren müssen. Das heißt, ein hreflang tag alleine reicht für uns nicht. Wir müssen das bestätigt haben von der anderen Seite und dann crawlen wir quasi zwei oder dreimal diese einzelnen Seiten erst mal durch, bis wir das wirklich verarbeitet haben. Das ist mal so eine zeitliche Verzögerung, die es da geben kann. Gerade wenn man eine größere Website hat, kann das natürlich einige Monate dauern, bis wirklich alles verarbeitet ist. Das andere, was oft bei hreflang noch passiert oder noch ein bisschen damit hineinspielt, ist, gerade wenn die Inhalte in der gleichen Sprache sind, dass wir annehmen, dass die Inhalte eigentlich identisch sind oder equivalent sind und dass wir die zusammenklappen können. Und dann kann es zum Beispiel so passieren, wie jetzt da, dass wir sagen, gut, die kanadischen Inhalte sind die gleichen wie die amerikanischen Inhalte. Also indexieren wir einfach eine Version dieser URLs und zeigen die dann entsprechenden Suchergebnisse und dann kann es sein, dass wir manchmal die falsche Version teilen. Das heißt, wichtig ist wirklich auch, dass die Inhalte unterschiedlich sind, wenn man mit dem hreflang arbeiten will. Alles klar. Ja, es wäre vielleicht ein Kompromiss, wenn ich kurz dazwischen fragen darf, dass man einfach nur wegen deutschen Varianten eben schweizdeutsch und deutschland unterscheidet und nicht da noch sämtliche andere Sprachen Ja, kann man zum Beispiel auch so machen, man kann mit dem hreflang die gleiche URL für verschiedenen Sprachen-Länder-Versionen angehen. Das man zum Beispiel sagt, jetzt alle europäischen Länder nehme ich jetzt dazu und einmal die Schweiz als nicht europäisches Land separat, und dass man quasi im hreflang sagt, jetzt Deutschland, Österreich, hierhin und die Schweiz da ein. Ganz kurz dazu, ich kenne auch eigentlich auch in den Search-Konsol-Untersuch an Fragen dann internationale Ausrichtung, dem unterverzeichnes.com.ca, die Gewichtung geben wie eine Generic, nee, wie eine Country-Core-Top-level-Domain. Das heißt, ich kenne auch quasi das Unterverzeichnis dahin pointen zu dem jeweiligen Land und kann doch dann, ja, sogar sehen, die Boundfeld auch verbessern. Ja, aber das ist natürlich nicht das Gleiche wie hreflang, das ist dann einfach quasi diese Länderausrichtung. Das heißt, wir zeigten eher in diesen Ländern, aber wir wissen dann nicht, dass sie equivalent sind, dass wir die richtige austauschen sollten. Okay. Aber gerade mit gleichsprachigen Inhalten, mit hreflang, weiß ich, dass das Team daran noch arbeitet und wenn ihr gute Beispiele habt, wo wir das falsch hinkriegen, auch wenn die Inhalte gleich sind, dass wir da die falsche Länder-Version zeigen, dann wäre ich froh, wenn ihr die mir zuschicken könntet, weil das hilft mir immer, wenn ich da Beispiele aus der Praxis bringen kann und nicht einfach sagen kann, könnte ja theoretisch passieren, dass wir das falsch kriegen, hilft immer ein bisschen bei den Gesprächen. Alles klar. Dankeschön. Okay, super. In zwei Wochen bin ich auf der SEO-Com in Salzburg. Wenn ihr da vielleicht auch da seid, sehen wir uns vielleicht in Person. Ich weiß nicht, ob wir da noch ein Hangout machen können, müssen wir schauen, wie zeitlich das klappt. Ansonsten sehen wir uns sicher in einem der anderen Hangouts wieder. Okay, vielen Dank fürs Kommen und hoffentlich bis sein nächstes Mal. Danke schön. Tschüss, danke. Bis allerseits. Ciao.