 Okay, herzlich willkommen zum heutigen Google Webmaster Central Sprechstunden-Hangout oder zum zweiten heute. Mein Name ist Johannes Müller, ich bin Webmaster Transanalyst bei Google in der Schweiz und Teil von dem, was wir machen, ist solche Hangouts zusammen mit Webmaster und Leuten, die die Websites betreiben und vielleicht Fragen zur Google-Suche haben. Wie immer sind da schon einige Fragen eingereicht worden über die Google-Plus-Seite, aber wenn einer von euch loslegen möchte und mit den ersten Fragen anfangen möchte, seid ihr gerne dazu eingeladen? Ich hatte direkt mal eine Frage, die ich eigentlich gerade beim Publisher Hangout stellen wollte, aber war schon zu spät dafür. Ich bin jetzt von Hubert Bruder Media, explizit mein schöner Garten und wir haben den Fall, dass wir auf sehr, sehr viele Short-Tail-Suche an Fragen Doppelrankings haben. Also, wenn man jetzt eingibt Hortensien bei Google, dann ranken wir teilweise auf Platz 1 bis 4. Mit verschiedenen Sachen auf Platz 1 ist dann meistens diese Themenseite, die klassische Hubpage, die wir haben, die ist auch mit Content angereichert. Auf Platz 2 ist dann Hortensien schneiden, auf Platz 3 das Video und auf Platz 4 irgendwie eine spezielle Hortensie, Bauernhortensie. Siehst du das als Problem oder ist das irgendwie ein geiler Nebeneffekt jetzt einfach? Ich sehe das nicht als Problem. Ich denke, das kann es geben. Es hängt ein bisschen davon ab, wie gesucht wird, wonach gesucht wird, wie wir das zeigen können, aber das kann es euch ausgeben. Ich denke, für euch ist das nicht unbedingt schlecht, oder? Also, scheint es so, oder? Ja, da wollte ich mir sicher gehen, weil über Doppelrankings sagt man halt mal so, mal so, aber wir haben das wirklich sehr, sehr oft, aber es ist vielleicht auch der Konkurrettssituation geschuldet, sicherlich auch. Ich denke, das ist manchmal schwierig, aber das sind ja nicht Sachen, die ihr groß beeinflussen könnt, außer, dass ihr eine neue Index auf die Seiten nehmt und das macht wahrscheinlich auch keinen Sinn. Okay, Aska, vielen Dank. Also, wenn jemand keine Frage hat, dann würde ich dann gerne mal eine stellen. Also, ich habe eine Testseite und da geht es darum EMP. Ich habe jetzt die Beta-Version von WordPress EMP reingeladen und seitdem kriege ich bei der neuen, sagt schon hier, Search Console immer Fehlerangaben, die einfach nur Geld markiert sind. Und ich habe nur noch einen einzigen noch dabei, der ist dann auch rot und die EMPs, die ich vorher immer gemacht hatte, bevor ich installiert habe, waren alle okay. Woran kann das liegen? Schwierig sagen, ich weiß nicht genau, was du da installiert hast und wie das vorher eingerichtet war. Also irgendwann glaubst du mal, ein WordPress-Plug in EMP von Google als Beta 7.3 und den habe ich dann installiert, wo vorher war das 6.5 oder so und mit dem ist es alles gut gelaufen, mit dem Plug-in von Google und seitdem 7.3 mit Beta-Version läuft es ziemlich schlecht. Okay, ich würde da vielleicht schauen, wo man da Feedback zum Plug-in selber geben kann. Ich weiß nicht, ob Sie das auf GitHub haben oder irgendwo bei WordPress, wo die Plug-ins quasi registriert sind, aber ich würde da den Feedback dann bringen und dann vielleicht auch einzelne URLs angeben, die in Search Console als Fehler markiert sind, so dass jemand das mal anschauen kann. Schwierig zu sagen, was das genau sein könnte. Vielleicht ist das bekannt gewesen, anscheinend bin ich der Erste. Okay, es ist zumindest nicht bekannt. Vielleicht haben das andere auch schon gesehen. Aber wenn das ein breiteres Problem wäre, dann wäre das sicher was, woran das Team da auch interessiert wäre, da möglichst schnell eine Lösung zu können. Okay, nach den anderen Fragen habe ich noch eine Frage, aber jetzt gebe ich es mal frei. Okay, Johannes, wenn sonst keine Frage hat, kann ich? Leglos. Es ist so, ich betreue eine relativ große Firma, die international aktiv ist. Nennen wir sie einfach einmal ABC. Wir sind weltweit recht gut gerenkt. Das Einzige, wo wir nichts haben, weder Vertretung noch Partner, sonst noch was, ist Russland. Vor einigen Tagen hat uns Analytics und Alerts darauf hingewiesen, dass es jetzt eine Seite gibt, ABC.ru. Die Seiten von dieser Seite sind auch bei euch gut indexiert. Die ganzen Bilder und die ganzen Logos sind alle von unseren Seiten heruntergeklaut. Habe ich irgendeine Möglichkeit zu verhindern, dass die im Index so gut gefunden werden? Über das DMCA-Verfahren kann man manchmal so etwas quasi aufräumen. Ich kann euch dazu rechtlich gesehen keinen Tipps geben, wie ihr da rechtlich vorgehen könnt. Mir geht es rein darum, dass die so gut indexiert sind. Ja, aber das wäre vielleicht eine Variante. Da würde ich einfach mal mit einem Rechtsberater das kurz anschauen, ob das ein realistischer Weg ist, in so einem Fall, und gegebenenfalls das entsprechend einreichen. Wo kann ich das einreichen? Das gibt das DMCA-Formular. Das müsste man irgendwie aufhinden können. Das sind glaube ich die ersten paar Inhalte dazu. Alles klar. Dann ist mir noch aufgefallen, dass zwischen der neuen Search-Konsole und der alten Search-Konsole teilweise große Unterschiede sind. Speziell, wenn ich in der neuen bekomme, dass eine Seite nicht aufgerufen werden kann, dann wechseln sich aufrufen wie durch Google, der durchschwitzt sich in den alten Bereich und der zeigt mal an, dass alles in Ordnung ist. Kann ich sagen, dass das noch beim Einschwingen ist, das System? Was kann man da sagen? Ich vermute, dass es da bei den Indexierungsinformationen... Richtig. Wenn da steht, dass eine Seite wegen 404 quasi entfernt worden ist aus dem Index, dann haben wir da effektiv in 404 gesehen. Das heißt, möglicherweise ist es auch so, dass da einfach temporär in 404 zurückgegeben worden ist, oder das letzte Mal, als wir das versucht haben, zu crawlen. Ich würde da vielleicht mal ein Auge drauf behalten. Es sollte eigentlich nicht so sein, dass da 404 Fehler angegeben werden, die nicht wirklich ein 404 waren. Alles klar. Dankeschön. Dann gehen wir vielleicht mal die ersten paar Fragen durch, die eingereicht worden sind. Seitdem wir auf HTTPS migriert sind, wird unsere SideMap-Dateien nicht mehr angenommen. Wir haben mehrmals neu eingereicht und getestet. Das Status steht jedoch immer auf Pending. In Search Console gibt es folgenden Grund an, allgemeine HTTPS Fehler. Wir finden keine Ursache, warum die nicht gelesen werden kann, da die Fehlerbeschreibung auch nicht genug Kontext gibt. Ich müsste da wahrscheinlich ein bisschen genauer mal nachschauen, was das sein könnte, wo das genau herkommt. Wenn ich die Seite im Moment hier aufrufe mit Googlebot, funktioniert das. Und ich sehe auch bei uns im SideMap-System, dass das regelmäßig eingelesen wird und auch verarbeitet wird. Ich vermute, dass das eigentlich richtig funktioniert zum Großen und Ganzen, dass es einfach eins normale vielleicht Probleme gegeben hat und dass die Fehler dann entsprechend sichtbar sind in Search Console. Aber ich schau mir das nochmal genauer an, was da passiert ist. Habe ich einen Einfluss auf mein Crowd-Budget? Kann ich es erhöhen? Was ich vermute, links von außen sind gut, regelmäßig neue Inhalte posten ist gut, möglichst slacher Hierarchien ist gut, hat die SideMap einen Einfluss auf Crowd-Budget. Wir haben vor, ich weiß nicht, ein halben Jahr größten Ordner einen Blog-Post gemacht über den Crowd-Budget. Das würde ich auf jeden Fall mal anschauen. Da sind einige Informationen dabei, wie wir das anschauen. Einerseits sind es viele technischen Sachen, die zusammenkommen. Das heißt, wie schnell wir die Website im Allgemeinen crowden können, wie viel Fehler wir sehen beim crowd. Das sind so Anzeichen, die für uns dann kommen und sagen, wir müssen vielleicht ein bisschen weniger crowden. Auf der anderen Seite ist es natürlich so, dass nur, wenn eine Website schnell ist und wenig Fehler zurückgibt, heißt noch lange nicht, dass wir einfach beliebig viel indexieren oder beliebig viel crowden wollen, sondern wir möchten natürlich auch sehen, dass es sich effektiv lohnt, diese Inhalte zu crowden und zu indexieren. Das heißt, einerseits gibt es die ganzen technischen Sachen, die man machen kann, dass der Server schnell ist, dass die Linkstruktur möglichst einfach ist, dass wir möglichst wenig Duplikate finden beim Crowd. Das hilft uns auf jeden Fall. Andererseits ist natürlich auch wichtig, dass die Website wirklich auch sehr gut ist, dass wir wirklich auch sagen können, dass das lohnt sich für uns, wenn wir da möglichst viele oder möglichst alle Inhalte, die wir finden, auch crowden und indexieren können. Und das widerspiegelt sich manchmal nicht direkt in irgendwelchen direkt messbaren technischen Faktoren, sondern das ist einfach, glaube ich mal, das große Gesamtbild der Website im Allgemeinen. Was ist Deine Meinung zu HTTPS? Siehst Du diese etablierte Technologie an, die jede Website längerfristig verwenden sollte, um da vielleicht einen Ranking-Boost zu kriegen, wie mit HTTPS? Ich denke, das ist eigentlich eine Technologie, die sich soweit bewährt hat, die wahrscheinlich auch so oder in ähnlicher Form bestehen wird und die durchaus Sinn macht. Das heißt, man verwendet das ja in erster Linie zusammen mit HTTPS. Die meisten Browser verwenden HTTPS 2 nur, wenn HTTPS verwendet wird, einfach aus Sicherheitsgründen. Und dementsprechend würde ich da erstmal natürlich auf HTTPS wechseln, wenn ihr das noch nicht gemacht habt, aber mit HTTPS 2 kann man natürlich in den rechten Geschwindigkeitsvorteil auch noch herausholen, sofern der Server das entsprechend auch sauber unterstützt und sauber mithilft. Das heißt, mit HTTPS 2 ist es ja möglich, dass man mehrere Inhalte in gleichen Request holen kann, sodass man zum Beispiel eine HTML-Seite aufrufen kann und man bekommt dann gleich in der Antwort vom Server hier ist die HTML-Seite und hier sind alle Bilder und CSS-Dateien, die auch dabei erwähnt werden, sodass der Browser dann viel schneller dieser Seite aufbauen kann. Für Google Crawling ist das weniger kritisch. Wir crawlen ja die HTML-Seiten separat und nehmen die ganzen anderen Inhalte oft vom Cache auf unserer Seite. Das heißt, wir müssen eigentlich nicht mit HTTPS 2 crawlen, aber für Benutzer kann das natürlich einen sehr großen Unterschied geben. Was vielleicht noch zu sagen ist, gerade bezüglich Ranking Boost bei der Frage, ist, dass ich schätze, dass es wahrscheinlich kein HTTPS 2 Ranking Boost geben wird, weil das ist eigentlich einfach eine Technologie, die jeder verwenden kann, die nicht irgendwie besonders sichtbar ist für den Benutzer, sondern einfach dazu führt, dass sich Seite sehr schnell lädt und wir nehmen natürlich die Geschwindigkeit zum Teil als Faktor dazu und da ist es vielleicht indirekt dabei, aber es gibt viele Wege, wie man eine schnelle Seite machen kann. Das muss nicht unbedingt über HTTPS 2 geliefert werden. Muss man den Anchor Link über welche, die den Ad Server kommen, einen No-Follow einfügen. Also quasi Werbelinks, No-Follow haben müssen. Wenn man das so anschaut, ist natürlich schon klar, dass wir einen No-Follow sehen würden, wenn dieser Link nur da besteht, aufgrund irgendeinem Werberverhältnis mit der anderen Website, dann sollte das natürlich als No-Follow Link dabei sein. Auch wenn diese Werbung erst über irgendein Ad Exchange geladen wird und separat aufgeladen wird. Wichtig für uns ist vor allem, wenn wir die Seite Render und diese Werbung sehen, dass für uns auch klar ist, dass das eigentlich ein Werbelink ist und da keine Signale weitergeben. Das stört uns an und für sich nicht, wenn ihr Werbung habt. Das dürft ihr durchaus machen. Das macht natürlich auch Sinn. Irgendwie muss man ja diese Website irgendwie unterstützen können bzw. die Server bezahlen können. Wichtig ist für uns einfach, dass es für uns klar ist, dass dieser Link aus Werbegründen da ist. Siehst du potentielle Gefahren für das organische Ranking eines Shop-Systems, wenn dies entschließt, alle denkbaren Freitecks suchen, zu indexieren. Zum Beispiel Shop.ch, Bargezeichen suche gleich Schuhe und suche gleich A, suche gleich ABC oder macht das eher Sinn, das per No-Index auszuschließen. Wie kann man das am besten machen? Grundsätzlich ist es so, dass wir in den Webmaster-Guidelines haben, dass man Suchen nicht indexieren sollte. Das haben wir da aus zwei Gründen. Einerseits aus ganz einfachen technischen Gründen, weil wenn ihr alle möglichen Suchen indexieren lässt bzw. überhaupt crawlen lässt, dann crawlen wir unter Umständen unendlich auf eurer Website. Und das bringt euch relativ wenig und uns relativ wenig. Und das ist ja auch etwas aus technischen Gründen, dass man das irgendwie einschränken lässt. Andererseits ist es natürlich so, dass viele von diesen allgemeinen Suchsystemen, die geben Antworten zurück, die nicht wahnsinnig hohe Qualität haben, also nicht, dass eure Inhalte nicht von hoher Qualität sind, sondern dass einfach diese Seiten, die zurückgegeben sind, die werden natürlich gezielt auf diese Suchanfragen angepasst und die sind dann nicht allgemein qualitative Seiten, die für eure Website sprechen. Das heißt, wenn ich nach A suche, zum Beispiel, habt ihr vielleicht viele Produkte auf eurer Seite, die das Wort A drin haben oder ein Buchstaben A, aber das ist noch lange nicht eine Seite, deshalb eine Seite, die wirklich auch hochstehend ist und eine tolle Seite ist, die ihr so indexiert haben wollt. Und aus dem Grund macht es natürlich auch Sinn, sich die Seiten, zu denen ich stehen möchte, die ich effektiv indexiert haben möchte. You are this? May I ask you a question? It's in English, so that's fine for you. Okay. We also have an English hangout tomorrow. Make it easier. Is that better? Probably better in English. Yes. But if you have a short question, I'm happy to... Maybe you can help. I'm calling in from Send steps and we haven't had in, which is not... We cannot download this anymore in Chrome. Chrome says that it's blocked due to all kinds of issues. And this was okay for 10 years and now since the first of March it's changed. Do you know or have an idea how we can find somebody who can help us out why it is now blocked via Chrome or only by Chrome? I would post in the Webmaster Help Forum with the details of the URL that is there. So that people there can check it out, give you some tips there and pass that on to us if that's needed. Because sometimes there is something unique within a plugin or an add-on and that's useful to have in Chrome. Okay, clear. Thanks. Okay. Also, macht es Sinn bei einem ReLaunch einen großen Seite, die alte XML-Seitenapp auch 1-2 Wochen online zu lassen, damit der Crawler die Umleitungen und 404er schneller erkennt. Ist es sinnvoll während des ReLaunch 410 und nicht 404 mit einem ReLaunch zu lassen. Grundsätzlich, macht es Sinn, dass man diese redirects möglichst schnell an Google bekannt gibt. Wenn man ein größerer Strukturveränderung macht, wenn ich auf HTTPS wechsle oder von einem Domain zum anderen, dann hilft uns das ein bisschen schon. Allerdings ist es so, dass wir versuchen die Veränderungen stattfinden, damit wir da auch ein bisschen besser reagieren können. Das heißt, wenn wir sehen, dass viele eurer URLs sich verändert haben oder ein redirect jetzt haben, dann wird es wahrscheinlich so sein, dass wir dann versuchen, ein bisschen schneller zu crawlen. Wir versuchen dann möglichst alle alten URLs durchzugehen und auch zu crawlen, damit wir sicher sind, dass man eine SiteNet für die alten Seiten einrichtet. Aber es kann ein bisschen helfen, gerade wenn man das Änderungsdatum entsprechend setzt. Ich würde das als guten Practice anschauen, aber nicht als eine Notwendigkeit. Bezüglich 404 oder 410 ist es so, dass wir einen kleinen Unterschied machen zwischen 410 und 404, und es zieht sich in erster Linie darauf, wie schnell wir diese Seiten aus dem Index herausnehmen. Und gerade bei den meisten Seiten ist es dann eher ein Unterschied von vielleicht einer oder zwei Tagen. Bei einem relaunch oder bei einer größeren Veränderung einer Website ist dieser Unterschied natürlich minimal im Vergleich zum Gesamtablauf. Von dem her würde ich mir da nicht groß den Kopf zerbrechen. Wenn ihr 410 zurückgeben könnt, dann ist das auch okay. Wenn ihr 404 zurückgeben könnt, ist das sicher auch okay. Es ist sicher nicht etwas, wo ich sagen würde, da müsst ihr viel Zeit investieren, um den einen oder anderen Code zurückzugeben. Wenn es für uns klar ist, dass es eine Seite ist, die nicht mehr existiert, fällt sie dann aus dem Index heraus. Da hätte ich auch eine Frage zu John. Bei einem relaunch wenn man alte URL-Struktur die Seiten haben, also punkt html oder html hinten dran, wenn man dann den relaunch macht und möchte das nicht mehr nutzen, sollte man also auf jeden Fall die 301-2. Leitung dort machen, oder? Ja, auf jeden Fall. Da braucht man dann auch keine Angst haben, dass die Seite irgendwie an Wert bei Google verliert, also diesen Unterschied erkennt Google automatisch. Ja, also es ist einfach eine normale URL-Veränderung und das gibt es einfach ab und zu. Das ist eigentlich überhaupt kein Problem. Gerade solche URL-Veränderungen sinken manchmal ein bisschen trickreich für Webmaster, die neu anfangen, weil die denken dann schnell, das sieht man doch auf den ersten Blick, dass das die gleichen URLs sein sollten. Für uns sind das aber unterschiedliche URLs, auch wenn da zum Beispiel von html auf htm gewechselt wird und wir müssen wirklich klar redirects dann auch sehen, damit wir die ganzen Signale weitergeben können. Ihr bekommt ja auch sonst einen 404 zurück. Genau, genau. Wir können dann nicht groß raten und sagen, ah, das ist fast die gleiche URL. Also nehmen wir da die Signale weiter und richten das so ein, sondern wir müssen wirklich sehen, dass es jetzt eine URL, die ist nicht mehr existiert, wir müssen dann redirect sehen auf die neue, damit wir die Signale weitergeben können. Sonst müssen die neuen Seiten neu anfangen und oft heißt es, dass sie dann in den Suchergebnissen nicht so sichtbar sind. Okay, dann haben wir noch eine Frage vom News Hangout, bezüglich AMP. Mal schauen, ob ich da was dazu sagen kann. Wie wichtig ist die Performance vom AMP Artikeln, wenn es darum geht, in amp-spezifischen Ergebnissen ausgespielt zu werden. Reicht ein deutlich schlechterer Performance Score, zum Beispiel in Lighthouse um deutlich schlechterer Chancen zu haben, sind fehlende Videos oder Social Media Einwettungen in AMP schon abweichender Inhalt oder geht es bei der Thematik wirklich nur um Teaser Text in AMP, die zum Klick auf den Hauptartikel und in den Nicht-AMP-Version leiten sollten. Wichtig ist für uns, dass eigentlich die AMP-Seite ein vollständig equivalentes Ergebnis ist wie die normalen Seiten. Das heißt, wenn die Videos und die Bilder ein wichtiger Teil von den normalen Seiten sind, dann sollten die auch auf der AMP-Version vorhanden sein. Wenn hingegen Bilder und Videos ernebensächlich sind auf der normalen Seite, zum Beispiel im Sidebar irgendwo erwähnt werden, dann ist das weniger problematisch. Ebenso bezüglich Social Media Einwettungen, jetzt wenn ich irgendeine Instagram-Bilder noch dazu füge oder Twitter Einbau habe oder wenn ich Kommentar Möglichkeiten habe in der normalen Version, dann sind das alle Sachen, die man auf der AMP-Version auch haben möchte. Das heißt, das Ziel sollte eigentlich sein, dass Benutzer egal welche Variante sie aufrufen, dass sie da wirklich die vollständigen Möglichkeiten zur Verfügung haben, so dass es aus unserer Sicht wirklich ganz unproblematisch ist, wenn wir Benutzer auf die AMP-Version leiten, dann haben sie auch das volle Ergebnis und nicht eine abgespeckte Version, die wirklich nur ein Teil von der Funktionalität bietet. Sollte wirklich eigentlich das Gleiche sein. Bezüglich Performance, das heißt so die Geschwindigkeit her, meines Wissens wird das im Moment nicht berücksichtigt. Mit dem Speed Update beim Mobile wird das allerdings dann eher ein Thema sein, dass wir sagen, wenn wir die AMP-Version als mobile Version sehen, dann ist natürlich eine Frage, wie schnell diese AMP-Version dann auch wirklich beim Benutzer ist. Wenn das eine sehr langsame AMP-Seite ist, das kann man ja theoretisch auch machen, dann ist das halt eine langsame Seite, die beim Benutzer auch ankommt und dementsprechend kann das natürlich vom Mobile Ranking her ein Einfluss haben. Dann haben wir da eine Frage mit einem großen Szenario, indem die URLs mit einem Parameter nicht aus der internen Verlinkung entfernt werden können, weil diese für bestimmte Funktionen notwendig sind. Wenn die URL-Parameter vom Crawling ausgeschlossen werden sollen, welcher Weg ist für Google optimaler, URL-Parameter über Search Console zu konfigurieren, internal URLs mit nofollow zu sehen oder mit dem X-Robots tag zu versehen oder mit dem Canonical zu versehen oder was könnte man da machen. Quasi wenn man intern mit Parametern verlinken muss aus technischen Gründen, aber man möchte eigentlich eine saubere URL indexiert haben. Für uns kann man das entweder über die URL-Parameter-Steuerung machen, das ist eine Variante. Ich finde die Funktionalität sehr kompliziert und man kann sehr schnell Fehler machen, die man später schlecht findet. Das heißt, ich wäre da ein bisschen vorsichtig, da einfach diese Funktionalität da zu verwenden. Was ich eher machen würde, ist einfach mit dem REL Canonical zu arbeiten. Das heißt, wir können dann die URL mit dem Parameter Crawl. Wir sehen ein REL Canonical auf die saubere URL und können uns dann auf die saubere URL konzentrieren. Alles andere, das heißt, das mit No-Follow zu arbeiten oder mit dem X-Robots Tag zu arbeiten, das ist eher problematisch in dem Sinn, dass wir dann die interne Struktur nicht sauber erkennen können. Mit dem No-Index mit dem X-Robots Tag ist es dann natürlich auch so, dass wir die Seite selber nicht indexieren. Das heißt, wir finden dann vielleicht die Variante mit dem REL Canonical weiter. Wir sehen allerdings, das R soll nicht indexiert werden und dann, gut, lassen wir das sein und lassen dann auch alle Signale fallen, die mit dieser Seite zusammenhängen. hingegen mit einem REL Canonical können wir die Seite crawlen. Wir sehen, dass dann Canonical ist, können dann alle Signale auf die saubere Version weiterleiten. Das heißt, ich würde da entweder mit dem Canonical arbeiten oder vielleicht noch zusätzlich mit dem URL Parameter Tool arbeiten, wobei mit dem Parameter Handling Tool muss man einfach wirklich sehr sauber arbeiten und das auch so dokumentieren, dass ihr da später wiederfindet. Nicht, dass später jemand etwas an der Website machen muss und nichts davon wird indexiert, weil zufälligerweise der gleiche Parametername dort verwendet wird, wie ihr ausgeschlossen habt in diesem Tool. Wie viele Beiträge muss ich wöchentlich haben, um als Publisher zu erkennen zu werden? Weiß ich nicht, wie das bei Google News gehandhabt wird. Es gibt allerdings ein Google News Publisher-Hilfeform und da hab ich gesehen, dass man da nicht relativ gut Hilfe kriegt für solche Fragen, würde ich da vielleicht mal nachfragen. Ich weiß nicht, wo da genau die Kriterien sind, gerade speziell auf Google News, aber man kann natürlich auch in der Web-Suche erscheinen, wenn man jetzt nicht die Internet-Suchliste, die auf der Search-Results eingeblendet werden soll, funktioniert nicht, obwohl wir alle Maßnahmen dafür getroffen haben, was müssen wir machen, um dies freizuschalten. Ich vermute, das bezieht sich auf die Sightlink Searchbox. Es ist so, dass der Markup, den man da angeben kann in der Searchbox, ist etwas, das wir dann verwenden, wenn wir diese Searchbox zeigen würden in den Suchergebnissen. Das heißt, wenn wir diese Searchbox gar nicht zeigen, dann kann man durch diese Markup nicht diese Veränderung in den Suchergebnissen erzwingen, sondern wenn wir sie zeigen, können wir mit diesem Markup dann einfach eure Variante zeigen. Und was da relativ lange Zeit geht, bis wir das auch wirklich zeigen in den Suchergebnissen. Manchmal ist das mehrere Wochen. Das heißt, wenn ihr das implementiert habt, ist es nicht nur eine Frage vom Neukroll in der Homepage, sondern es geht einfach eine gewisse Zeit, bis wir das wirklich sauber verarbeitet haben und bis wir das dann auch so zeigen können, wie ihr das angegeben habt. Wenn ihr das schon seit einigen Wochen eingerichtet habt und das funktioniert nicht, dann könnt ihr mich vielleicht mal kurz kontaktieren über Google Plus oder vielleicht auch einfach im Hilfeforum einen Post machen, damit jemand anders das auch mal anschauen könnte. Wie relevant sind die News Keywords Tags noch? In Google-Dokumentation ist nichts mehr dazu zu finden. Wir verwenden die gar nicht mehr. Ich habe da beim Google News Team mal nachgefragt, ich glaube vor einer Woche oder so. Und das wird effektiv gar nicht mehr verwendet. Ich glaube, in einem der Beispiele im Hilfecenter werden die noch erwähnt, aber das sollte auch im Laufe der Zeit noch aufgeräumt werden. Ich glaube, die News Keywords und die Genre sind so die Attribute, die gar nicht mehr verwendet werden bei Google News, sondern wir versuchen da diese Information direkt aus den Seiten selber herauszulesen. Das heißt, es verursacht keine Probleme, aber wir verwenden sie einfach nicht mehr. Gibt es einen täglichen Zeitpunkt, an dem die Search Console-Daten aktualisiert werden? Nein, eigentlich nicht. Wir haben da diverse Prozesse, die quasi im Hintergrund immer wieder durchlaufen. Und weil das über das ganze Internet geht, kann es sein, dass ein Teil der Daten gewissen Zeit aktualisiert werden und ein Teil der Daten kommen wir später im Laufe vom Tag. Da ist es nicht so, dass wir an einem Tag quasi alles freischalten. Das würde ja dann auch bedeuten, dass wir quasi alle Daten doppelt haben müssten und dass wir zwischen der einen Version und der anderen Version einfach schalten könnten. Und für uns macht es mehr Sinn, dass wir diese Daten einfach Schritt für Schritt aktualisieren, sobald wir die Daten entsprechend zur Verfügung haben. Ist es möglich, die Ladezeit verbessern mit Google Maps auf einer Webseite? Weiß ich nicht, wie man das am besten handhaben kann. Da gibt es wahrscheinlich Tricks, die man machen kann mit Lazy-Loading, dass man die Karte erst dann lädt, wenn der Benutzer das wirklich auch offen hat. Aber die genauen Techniken weiß ich jetzt nicht, was man da machen könnte. Ich würde da vielleicht im Google Maps auch ein Developer-Forum hat oder ob das alles zum Beispiel auf Stack Overflow ist, würde ich mal danach fragen, wo andere Google Maps Entwickler entsprechend auch sind. Wahrscheinlich gibt es da schon einfache Möglichkeiten, die man machen kann. Verwertet ihr bei strukturierten Daten von Produktzeiten die Property Value Added Tax included? Puh, weiß ich nicht. Wenn wir das verwenden würden, dann wäre das auf jeden Fall ein Developer Documentation. Ich weiß nicht, also wenn ich direkt danach suche, sehe ich das eigentlich nur erwähnt beim Email Markup. Das heißt, wenn es wirklich nur beim Email Markup erwähnt ist, dann ist das wahrscheinlich etwas, was wir nicht für die Websuche zumindest verwenden. Allerdings mit vielen Sachen, die gerade im Bereich Structured Data sind, wir den Structured Data vielleicht nicht direkt auf den Seiten verwenden 1 zu 1 in irgendwelchen Suchelementen, aber manchmal hilft uns da schon die Seite ein bisschen besser zu verstehen. Ich vermute, mit diesem speziellen Property bringt uns das relativ wenig, wenn wir es sehen, dass das angegeben ist. Aber mit anderen Arten von Structured Data macht es halt manchmal auch Sinn, dass wir genau sehen, dass betrifft jetzt dieses Objekt, was vielleicht was beschrieben werden kann. Und das sind vielleicht Sachen, die nicht 1 zu 1 in der Suche weiterverwendet werden können, die uns aber helfen, die Seite besser zu verstehen. Wie kann man Low Quality und Thin Content Seiten identifizieren? Sind das Seiten, die für Suchabfragen mit hohen Suchvolumen auf den letzten Seiten oder gar nicht erscheinen? Soll man da mit dem hreflang arbeiten? Zum Beispiel die anderen Sprachversionen auf No Index setzen. Grundsätzlich würde ich sagen, dass man über die Google Suchen nicht direkt sehen kann, was Low Quality oder Thin Content Seiten sind, sondern das sind eher Merkmale, die ihr selber definieren müsst und selber irgendwie herausfinden müssten, was für euch das Sinn macht oder wie ihr das identifizieren wollt. Ich weiß einige machen das so, dass sie da schauen, wie Benutzer auf diesen Seiten reagieren, wie die Conversions jeweils sind, wenn Benutzer auf diese Seiten gehen. Das ist vielleicht eine Variante. Es gibt da verschiedene Wege, die man da einschlagen könnte, um ein bisschen herauszufiltern, wo sind jetzt vielleicht die Problembereiche meiner Webseiten, wo sind Bereiche, die eigentlich soweit okay sind. Und das ist sehr unterschiedlich von Website zu Website. Bezüglich No Index oder nicht, dass es anfüßig euch überlassen, ob ihr solche Seiten weiterhin indexieren wollt oder ob ihr sagt, die sollten gar nicht mehr in der Suche erscheinen mit No Index. Das ist anfüßig euch überlassen. Ich würde einfach davon abraten, blind nur auf die Impressions zu schauen, sondern nur weil eine Seite selten gezeigt wird heißt noch lange nicht, dass die Seite Low Quality ist. Vielleicht ist es einfach ein Nischenthema, was ab und zu gesucht wird, aber wo eure Seite durchaus sehr relevant sein könnte. Und von dem her würde ich nicht einfach auf den Traffic aus der Suche schauen und sagen, ah, da geht kaum jemand hin, deswegen nehme ich die Seite aus dem Index, sondern eher selber überlegen welche Merkmale könnte ich nehmen, um solche Seiten zu finden. Gerade bei einer größeren Website lohnt es sich vielleicht auf Zahlen zu schauen, die man irgendwie messen kann. Bei einer kleineren Website kennt ihr das wahrscheinlich auch selber schon, welche Seiten eher problematisch sind und welche Seiten eher gut sind. Wie wird near duplicate wie wird near duplicate Content auf No Index Seiten behandelt? Fallen No Index Seiten komplett bei der Bewertung raus? Ja, wir lassen die Seiten für sich aus dem Index heraus und wenn der Duplicate Content ist auf diesen Seiten, ist das eure Sache, es ist nicht unbedingt etwas, worauf wir achten werden. Das heißt, wenn etwas auf No Index ist, ist es auf No Index, das ist für uns aus total okay? Wir nehmen das dann einfach aus dem Index raus. Uch, und dann noch eine sehr lange Frage, wahrscheinlich ein bisschen schwierig, so live Hangouts durchzugehen. Bezüglich hreflang Attribute und X default. Uch, das muss ich mir wahrscheinlich in Ruhe mal anschauen. Was ich da vielleicht machen würde, ist die Frage im Hilfeforum mal zu posten. Möglichst auch mit effektiven URLs, dass jemand das mal anschauen kann, weil da haben sie eigentlich schon recht viele Erfahrungen mit solchen Themen und wenn es etwas problematisches ist oder wirklich unklar ist, dann kann man das vom Hilfeforum entsprechend an Google weiterleiten und die schauen das dann auch jeweils an. Aber so übern Live Hangout ist das schwierig, wenn das so riesige Frage ist. Okay, für ein Plattform wo man sich Seiten erstellen kann werden Subdomains für alle einzelnen Subdomains verwendet. Aktuell sind es ca. 50.000 Subdomains. Macht es Sinn, eine Sidemap zu erstellen wo alle Subdomains verwiesen wird. An sich sind alle Subdomains unabhängig voneinander. Man kann da durchaus mit einer Sidemap-Datei arbeiten. Wichtig ist einfach, dass die Sidemap-Datei muss natürlich pro Host eingereicht werden. Das heißt, dass man einfach blind eine Sidemap-Datei auf den Route-Domain quasi erstellen, welches für die Subdomains auch entsprechend gilt, sondern ihr müsst pro Subdomain diese Sidemap-Datei auch einreichen. Das kann man am einfachsten machen über die Robots Text-Datei, dass man da pro Subdomain ein Verweis auf ein Robots Text auf eine Sidemap macht. Das wird zum Beispiel so bei Blogger gemacht, bei einigen Systemen auch. John, kann ich noch eine Frage zwischendurchstellen? Ja, leg los. Geht es um die Suchergebnis-Listen. Seit Dezember habt ihr da mehr Zeichen zur Verfügung, zumindest auf den Desktop. Da habe ich jetzt Descriptions gesehen. Die waren 300 Zeichen lang ungefähr. Auf Mobile scheint das aber immer noch so bei 140 bis 160 Zeichen zu liegen. Ich glaube, das hat mit Pixeln zu tun mit der Schriftpröße, die ihr da nutzt. Man möchte das ja eigentlich als Webmaster ganz gerne ein bisschen beeinflussen, um vielleicht die Conversion die Klickrate zu erhöhen. Was kannst du dafür Empfehlung geben? Wie macht ihr es im Moment? Weil ich habe gesehen, dass ziemlich viel Text von den Seiten runtergezogen wird, statt den Description Text zu nehmen. Ja, was kann man da empfehlen? Ich würde grundsätzlich versuchen, die da einfach jeweils ein Description anzugebende jeweils Sinn macht. Was ich eher davon abraten würde, ist, dass man sich strategisch an die aktuellen Suchergebnisse ausrichtet. Weil die Suchergebnisse und der aufbauenden Suchergebnisse, das kann sich immer wieder verändern. Das heißt, es kann sein, dass wir jetzt längere Snippets bei Desktop haben. Vielleicht zeigen wir in einem späteren Moment beim Mobile und dann wieder kürzerer beim Desktop. Das kann sich eigentlich immer wieder verändern. Und von dem her würde ich mir überlegen, wie macht das Sinn, für euch allgemein die Snippets zu machen und dann vielleicht einfach ein System herausfinden, was allgemein funktioniert, was nicht nur auf die aktuelle Darstellungsart quasi davon abhängig ist. Vom Praktischen her ist es vielleicht auch etwas, womit ihr auch mal Tests machen könnt. Wie funktioniert das? Wenn ihr Seiten habt, die relativ häufig gezeigt werden in den Suchergebnissen, dass ihr da mal verschiedene Snippetarten austestet. Und man schaut, wie das am besten funktioniert mit dem Click-through Rate. Wie am besten Benutzer auch erkennen können, welche Inhalte auf der Seite sind, wie man da sich am besten präsentieren kann. Das heißt, ich habe eigentlich keine direkte Antwort, um zu sagen, ihr müsst jetzt 300 Buchstaben Snippets machen oder 200 irgendwas dazwischen, sondern es verändert sich einfach auch immer wieder. Und da müsst ihr selber halt ein bisschen überlegen und testen und schauen, wie es am besten funktioniert. Die Frage ist ja eher, weil die Seiten ranken ja, sollte man dann vielleicht die Description einfach weglassen um Google mehr Flexibilität bei der Auswahl des Snippets zu geben. Wenn man die Description mittlerweile ignoriert, dann braucht man sich vielleicht nicht mehr die Mühe machen, die passenden Texte zu formulieren, um wie bisher diese 160 Zeichen ungefähr einzuhalten. Einige Websites machen das, dass sie gar keine Description mehr angeben. Ich weiß nicht, ob das immer gut klappt, ob das immer gut mit den Conversions klappt. Vielleicht muss man sich auch überlegen, wo macht das am meisten Sinn, dass sich in eigenen Descriptions haben bei Seiten, die wirklich kritisch sind bezüglich Conversion, dass man da vielleicht eher sich die Mühe macht, wirklich von Hand etwas zusammenzustellen und bei allen anderen, dass man vielleicht sagt, irgendwas kommt da schon zusammen, was einigermaßen stimmt. Das ist auch gut genug. Da muss man vielleicht schauen. Aber ich denke, es wird sicher nicht so sein, dass wir sagen, wir benutzen die Description-Mattert gar nicht mehr, das müsste es gar nicht mehr angeben, sondern das wird wahrscheinlich weiterhin so sein, dass wir diesen Tag auslesen und wenn möglich, wenn er wirklich zu dieser Suchanfrage passt, versuchen wir den dann auch zu verwenden. Okay. Danke. Mal ganz kurz schauen, welche Fragen noch eingereicht worden sind. Dann können wir sonst zum offenen Teil auch übergehen. Laut Search Console heißt es, wenn man verifiziert ist für ein Domain, dann ist man automatisch verifiziert für alle Subdomains, wie funktioniert das. Die Domain-Verifizierung glaube ich, bezieht sich vor allem darauf, wenn man per DNS die Verifizierung macht. Und wenn man das so macht, dann ist natürlich schon klar, dass man den ganzen Domain quasi verwalten kann. Wenn man nur den root-Domain verifiziert, dann ist das nicht wirklich ein Zeichen, dass ihr alle Subdomains auch kontrolliert. Von dem her würde ich da diesen Unterschied anschauen. Und gerade mit 50.000 Subdomains ist es so, dass wenn ihr die einzeln einrichtet in Search Console, kann man die natürlich auch nicht in einem Konto einrichten, sondern man kann, glaube ich, nur 1.000 pro Konto eingeben. Das heißt, das ist ein bisschen schwierig. Da muss man sich dann schon überlegen, wie möchte man das am besten oder am praktischsten einrichten. In den Google Guidelines wird immer wieder von Trust und Autorität gesprochen. Wenn ich mir jetzt eine Website, wie Beispiel Apothekenumschau ansehe, kann man davon ausgehen, dass diese vermutlich eine höhere Autorität bei Google hat. Doch anhand welcher Merkmale misst Google das eigentlich ist, da habe ich keine genaue Antwort. Das heißt, das sind Sachen, die versuchen, wir auf verschiedenen Arten zu bestimmen. Es ist auch nicht so, dass wir eins zu eins versuchen, genau quasi Autorität zu bestimmen von einer Website, sondern wir versuchen einfach herauszufinden, wie und wo ist diese Website wirklich relevant? Und das hilft uns dann in der Suche. Aber es ist nicht so, dass wir schauen da in diesem Katalog nach oder nehmen diese fünf Zahlen und zählen sie zusammen und das gibt dann eine Zahl für die Autorität. Eine unserer Websites, eine SPAR, also Single-Page-App auf React-Basis rendert zurzeit sehr weniger Inca-Tags mit href Attributen im Content um mit begrenzten Frontaufwand die Verlinkung zu verbessern. Wäre eine Möglichkeit, die URLs per JSON-LD zum Beispiel Item List, ist das ein gangbarer, auch skalierbarer Weg oder sind echter anchor tags unumgänglich? Wir brauchen schon echte Links auf den Seiten, damit wir die auch sauber crawlen können. Das heißt, wenn die Seite gerendert ist, müssen wir wirklich Ar-Elemente mit diesem href-Link sehen, damit wir das auch so als Link verwenden können. Wenn ihr nur URLs einreichen wollt, würde ich das auf die Seitenapp-Datei machen. Aber es hilft uns schon sehr viel, wenn wir eine saubere interne Verlinkung haben. Dann können wir einerseits per Seitenapp die URLs finden, andererseits trotzdem auch noch über den normalen Crawl, die den ganzen Rest der Website finden. Ein großer Webseiten-Betreiber möchte ein A-B-Test mit einer kompletten neuen Webseite betreiben. Hierzu wird mittels ein Load-Balancer-Traffic eine neue Webseite weitergeleitet, circa 2-5%, um ein Belastungs- und Funktionstest durchzuführen. Auf beiden Webseiten wird die identische Robots-Text ausgeführt. Die neue Webseite ist komplett mit Meta-Robots-No-Index versehen. Die Indexierungsanweisung der alten Webseite bleiben unverändert. Wie sollten die empfohlen Indexierungsanweisungen aussehen, um den Google-Baten nicht zu verwehren? Ich vermute, wenn das per Load-Balancer gemacht wird, dann sind das die gleichen URLs, die ausgeliefert werden. Das heißt, zum Beispiel die Startseite wird einmal so ausgeliefert und dann in 2-5% der Fälle anders ausgeliefert. Und wenn ihr in einem solchen Fall mit No-Index arbeitet, dann haben wir das Gefühl, dass diese URL aus dem Index entfernt werden soll. Das heißt, wir beziehen diesen No-Index nicht auf die Inhalte, sondern auf die URL selbst. Wenn das die gleiche URL ist, die so ausgeliefert wird, dann ist vielleicht dann mal die Homepage zum Beispiel aus dem Index heraus, weil wir dann No-Index gesehen haben. Und das sind dann Sachen, die lassen sie sich sehr schlecht nachher diagnostizieren oder zu testen. Weil wenn ihr die Daten anschaut oder ihr ein Fetches Google macht, dann seht ihr vielleicht die Homepage und wenn wir Nachfragen sind, wir vielleicht in einem dieser 2-5% der Testfälle und sehen ein No-Index und sagen dann, gut, ihr wollt die nicht indexiert haben, dann nehmen wir sie raus. Das heißt, was ich machen würde in einem solchen Fall ist den No-Index weglassen, sondern normale Indexierung, wie das auf der Website halt wäre. So dass wir die beiden Varianten Unterumständen finden und sehen können wie wir das in diesem Fall zu indexieren können. Der einzige Unterschied, wo ich da vielleicht ein bisschen aufpassen würde, ist wenn ihr separate URLs verwendet für euer A-B-Test, wenn ihr zum Beispiel Test. meine Website.de habt, dann würde ich mit dem Canonical arbeiten und dann zurück auf die normalen Standardseiten verweisen. So dass man trotzdem diese Testseiten anschauen kann, aber wir wissen, die Haupturale sind eigentlich die Vorherrige, dass wir da zurückgehen können und für uns für das Indexierung auf die Haupturale konzentrieren können. Okay. Noch eine Frage zum Publisher Hangout. Wir liefern aus Ressourcengründen Seiten mit unterschiedlicher Geschwindigkeit an Google und den Nutzer aus. Der Benutzer kommt eine deutlich schneller Version unserer Seite als Google. Ist das für Google in Ordnung? Weiß nicht, das finde ich schade, wenn wir die langsame Seite kriegen und Benutzer kriegen, nicht schnelle Seite. Aber grundsätzlich könnt ihr das natürlich so machen, wenn das aus technischen Gründen so bei euch halt funktioniert, kann man das so machen. Wichtig ist natürlich, dass wenn die Seite quasi der html Antwort schon langsamer ist, als was Benutzer sehen oder langsamer als es sein könnte dass wir weniger Crawlen von der Webseite. Einfach aus dem Grund, dass wir euren Server nicht unnötig belasten wollen und dementsprechend wenn wir sehen, dass die Seite relativ langsam zurückkommt, dann denkt man gut, wir wollen da nicht nur zusätzlichen Ärger veranstalten, sondern wir crawlen dann halt ein bisschen weniger, sodass wir insgesamt weniger Serverzeit von euch abverlangen. Wenn wir umständen, wäre das vielleicht etwas, was da ein Einfluss hat. Wenn das nur ein Minim langsamer ist, ist das weniger problematisch. Eine andere Sache, die auch noch dazu kommen könnte, ist, wenn wir die Seiten renderen müssen und auf der Version, die wir bekommen sehr viel mehr zusätzliche Inhalte bekommen und dass es deswegen länger geht, bis wir die Seite renderen können, wenn die Inhalte in HTML dabei sind, ist das unproblematisch. Wenn ihr eine JavaScript Framework verwendet, dann ist es natürlich wichtig, dass wir die Seiten auch sauber renderen können. Aber ansonsten würde ich da jetzt nicht sagen, dass das ein großes Problem wäre. Ich vermute, dass, ja, ich denke längerfristig macht es eher Sinn, dass man sagt, gut, es kriegen alle die gleiche Seite in der Schwendigkeit, dass man da nicht so ein großer Unterschiede hat. Aber wenn das aus technischen Gründen erst mal so sein muss, dann, ja, damit können wir meistens schon sehen. Okay. Ich glaube, da haben wir so ziemlich alle Fragen durch. Was steht noch von euch aus an? Alle Klarheiten beseitigt. Okay. Gut, ja. Dann machen wir sonst hier eine Pause. Ich richte auf jeden Fall die nächsten Hangouts noch ein. Ich glaube, Morden ist noch einer auf Englisch. Und dann wahrscheinlich wieder in zwei Wochen machen wir wieder einen deutschen Hangout. Wenn ihr Fragen habt, könnt ihr euch gerne die Fragen noch da einreichen. In der Zwischenzeit sind wir natürlich auch im Hilfeforum oder auf Twitter oder Google Plus erreichbar, falls es irgendwas gibt, was dringend behandelt werden muss. Okay. Okay, super. Ganz tolle Seite, wo man immer direkt nachschauen konnte, wann das nächste Hangout stattfindet. Ich habe es früher als Bookmark. Es wäre schön, wenn die Seite mal, wenn es wieder so eine Seite gebe. Die gibt es wieder. Die heißt einfach anders. Ich glaube, das ist Google.com Webmaster und dann Kontakt. Nicht Kontakt. Irgendwie anders. Connect. Und ganz unten ist ein Kalender. Und den Kalender kann man auch, glaube ich, abonnieren. Kannst du das einmal posten? Ja, klar. Probier das mal rüber. Das sind alle möglichen Events dabei. Auch Konferenzen, wo wir dann hingehen. Falls ihr uns in Person auch mal sehen wollt. Habe ich einfach vergessen zu scrollen. Ja, das ist ein bisschen versteckt da. Da stimmt. Content above the fold. Genau. Ja. Genau. Also, was finde ich meine Frage zu der Setmap X? Meintest du, ihr werdet euch das nochmal anschauen? Und wie kannst du uns danach kontaktieren? Oder die Antwort einfach liefern? Einfachsten ist es, wenn ihr mir vielleicht die Nachricht schickt, dann kann ich da direkt auch antworten. Okay, also einfach auf deinem Profil. Genau. Okay, cool, danke. Super. Und jetzt sehen wir uns bei SNX, ne? Ja, in dem Fall. Cool, ciao. Okay, tschüss allerseits. Vielen Dank fürs kommen. Vielen Dank für die vielen Fragen. Und bis zum nächsten Mal.