 Okay, herzlich willkommen beim heutigen Google Webmaster Central Sprechstunden Hangout. Mein Name ist Johannes Müller, ich bin Webmaster Trends Analyst hier bei Google in der Schweiz. Und Teil von dem, was ich mache, ist solche Webmaster Hangouts mit Webmaster und Publisher, die jetzt hier im Hangout oder solche, die auch Fragen einfach gestellt haben, um möglich solche Fragen zu beantworten und natürlich auch weitere Informationen von unseren Websearchteams entsprechend weiterzugeben. Wie immer, wenn einer von euch möchte, könnt ihr gerne mit den ersten Fragen loslegen. Ansonsten schauen wir dann einfach die Fragen, die schon vorher eingereicht worden sind. Keine Lust auf eine erste Frage, das ist auch okay, kein Problem. Okay, wenn irgendwie zwischen euch was aufkommt, wo ihr Fragen habt oder weitere Informationen möchtet, einfach nur nachhaken. Okay, die erste Frage ist wegen hreflang. Das ist, glaube ich, immer wieder ein Thema, welches aufkommt. Gerade in Bezug jetzt eine Webseite hier, die für Deutschland, Österreich und die Schweiz verschiedene Versionen hat und die entsprechende einige Versionen so entsprechend markiert hat mit hreflang. Und da steht, das sind zum Beispiel in Spanien, wenn man auf Deutsch sucht, sieht man dann die Schweizer Webseite statt die X default Webseite, also die deutsche Webseite für Deutschland an und für sich. Und quasi, was man da machen könnte, ob das in den Fall verarbeitet ist, ob da irgendein Problem ist. Ich habe das kurz angeschaut mit den Seiten, die da angegeben worden sind und das sieht bei uns eigentlich soweit korrekt verarbeitet aus. Das heißt, was ich gesehen habe, ist einerseits indexieren wir die verschiedenen Sprachvarianten, also die verschiedenen Ländervarianten in diesem Fall für Deutschland, Österreich und die Schweiz. Das kann man relativ gut selber auch kontrollieren, einfach mit einer Infoabfrage, also Info, Doppelpunkt und dann die URL. Dann sieht man sehr schnell, ob wir diese URLs zusammengefaltet haben in einer Version oder ob sie auch wirklich einzeln indexiert sind. In diesem Fall sind sie auch für sich einzeln indexiert. Ich habe jetzt da nur einige Seiten angeschaut, ich habe nicht die ganze Webseite so kontrolliert. Ich denke, das lohnt sich eigentlich nur zu machen, wenn man wirklich gezielte Probleme sieht. Aber in diesem Fall sind sie wirklich einzeln indexiert. Wenn ich intern nachschau, sehe ich auch, dass wir den HFLang sauber verstanden haben von diesen Seiten, dass wir ihn am richtigen Ort gefunden haben, dass da zum Beispiel nichts im Head oben vorne noch dabei war, welches Problem er verursacht hat. Und für sich ist das soweit korrekt da implementiert. Also nicht unbedingt eine Frage von der Implementation hier. Was aber einfach immer passieren kann, ist, dass man irgendwie auf die falsche Version trotzten kann. Und das kann sein über die Suche. Das kann zum Beispiel sein, wenn wir aus irgendeinem Grund vermuten, dass eine von diesen Varianten ist, die wirklich wichtigste Variante und die zeigen wir dann vielleicht auch in anderen Ländern. Es kann natürlich auch sein, dass irgendjemand sonst wie einfach auf die Webseite kommt von irgendeiner x beliebigen Quelle. Und solche Situationen müsste man eigentlich immer abfangen mit irgendeiner Art von Backupplan an und für sich. Was wir da empfehlen, ist, dass man zum Beispiel per JavaScript das kontrolliert. Also wie die Benutzeinstellungen einerseits kontrolliert, vielleicht, wenn ihr wollt, die Sprache kontrolliert, andererseits auch den Standort von Benutzer, wenn ihr das bestimmen könnt. Und dann per JavaScript einfach oben ein Banner entsprechend einlenden. Und dann könnt ihr da zum Beispiel stehen, wir sehen, du kommst aus der Schweiz, wir möchten dir quasi unseren Schweizer Shop empfehlen. Oder wir sehen, du kommst nicht aus der Schweiz, möchtest du vielleicht lieber unseren EU Shop besuchen. Der Vorteil von einem solchen Banner ist, dass es an für sich die Indexierung nicht stört. Das heißt, wenn ich mit einer Weiterleitung arbeite, dann kann es hier sein, dass Googlebot auch diese Weiterleitung sieht und entsprechend diese Weiterleitung folgt. Und dann kann es passieren, dass wir diese Seiten gar nicht indexieren. Und das ist eigentlich unsere Empfehlung da. Man muss eigentlich, gerade bei internationalen Websites, muss man immer davon ausgehen, dass irgendwie könnten die Besucher auf die falsche Version kommen. Das kann natürlich auch über die Suche sein. Das kann zum Beispiel auch sein, dass wir in den hreflangtag mal falsch verstanden haben und da irgendwie auf die falsche Version weiterleiten. Und von dem her, wenn ihr ein Backup-Plan habt, dann ist alles quasi, was da schiefgeht, nicht so besonders schlimm, weil die Besucher dann immer noch den Weg zur richtigen Website finden. Beziehungsweise, sie können auch selber entscheiden. Will ich jetzt zur Schweizer Version gehen oder nicht? Oder vielleicht möchte ich mir jetzt, ich weiß auch nicht, die Produktauswahl in Spanien mal anschauen, obwohl ich jetzt nicht in Spanien bin und das vielleicht nicht bestellen kann, wäre das vielleicht auch eine Variante. Dann haben wir eine Frage mit ganz viel indexierten Seiten. Und in Search Console steht bei 300 Seiten etwa, dass die gesendete URL nicht als kanonisch ausgewählt wurde. Was bedeutet das? Was kann man da machen? An und für sich, was das für uns bedeutet, ist, dass wir zum Beispiel über eine Signup Datein, eine URL gefunden haben, die wir von euch verstehen, also etwas, was ihr indexiert haben möchtet, aber wo wir dann im Nachhinein festgestellt haben, wahrscheinlich ist damit eine andere URL gemeint. In vielen Fällen ist es ja so, dass wir verschiedene URLs finden, die zum gleichen Ziel gehen und die, an und für sich, die gleichen Inhalte zeigen oder vielleicht fast die gleichen Inhalte zeigen. Und in solchen Fällen ist es ja so, dass wir dann, was ich bei Komutter geht, so lang, soweit in dieser Maße. Hintergrundsgeräusch, kurz stumm schalten. Eben, was dann passiert, ist, wir sehen, dass diese Seiten duplikate sind und versuchen, eine URL auszusuchen, die wir für die Indexierung verwenden. Und dafür umnehmen wir einen Sidemapslitalien, htftln kommt unter Umständen auch dazu, http, https kommt ein bisschen dazu. Die kürzeren URLs werden meistens ein bisschen bevorzugt, wenn wir die effektiv so vergleichen können. Und all diese Sachen kommen ein bisschen zusammen und unsere Systemen versuchen, an festzustellen, was ist jetzt die richtige URL, die wir zeigen sollten für diesen Satz von Seiten, die wir gefunden haben. Und es kann durchaus vorkommen, dass wir ein URL canonical auf diesen Seiten sehen und dass wir dann trotzdem sagen, alles andere deutet auf ein anderer URL hin. Also nehmen wir diese andere URL als canonical. Und damit ihr ein bisschen Feedback von uns kriegt, diesbezüglich, versuchen wir das in SearchCancel auch zu zeigen. Das heißt, wir sehen, eigentlich möchte der Webmaster wahrscheinlich uns irgendein Signal geben und sagen, das ist die URL-Variante, die indexiert werden soll. Unsere Systeme wählen trotzdem etwas anderes. Und dann lassen wir den Webmaster erstmal wissen, irgendwas ist da vielleicht schief. Irgendwie passen diese Signale vielleicht nicht zusammen, vielleicht gibt es da Probleme mit der internen Verlinkung, vielleicht ist in der Signup-Datei sind beide Varianten aufgeführt. Vielleicht ist da mit Redirects oder mit dem Parameter-Tool diese Sachen können dazu führen, dass wir dann im Ende vielleicht drei oder vier verschiedene Varianten gefunden haben und dann irgendwann eine Wahl halt treffen müssen. Und was ich da jetzt in diesem Fall machen würde, ich denke, im ersten Fall, im ersten Moment ist das nicht kritisch. Das heißt eigentlich nur, dass wir eine andere URL ausgewählt haben von eurer Website. Vom Ranking her ist das eigentlich genau gleich. Wir haben einfach irgendeine andere ausgewählt und zeigen die. Wenn das für euch problematisch ist, wenn ihr zum Beispiel die URLs anschaut und denkt, ja, das ist wirklich ein schrecklicher URL, die möchte ich so nicht in den Suchergebnissen sehen, dann würde ich einfach schauen, dass wirklich alle Signale innerhalb von eurer Website auf die URL Hinweisen, die ihr wirklich indexiert haben möchte. Dass ihr da vielleicht auch wirklich links wirklich alle auf die richtige Version zeigen, ob mit dem URL Canonical wirklich sauber gearbeitet wurde, ob da vielleicht andere Verweise sind auf die falsche Version und je mehr ihr diese Signale auf das Richtige hindeuten könnt, umso eher können wir das dann auch so übernehmen und das dann so auch entsprechend zeigen. Wie gesagt, im Ranking sollte das eigentlich nicht verändern. Wenn wir die Inhalte indexiert haben, haben wir sie halt mit dieser URL oder mit der anderen URL indexiert. Die Signale können dann entsprechend bei dieser URL sein. Die können dann auch weitergeleitet werden auf die andere URL, wenn die Signale, wenn alle unsere Informationen auf die andere URL auch einmal zeigen, deuten würden. Also von dem her ist es im ersten Moment nicht kritisch, aber wenn das für euch ein Problem ist, würde ich mal schauen, ob man das irgendwie aufräumen kann oder verbessern könnte. Okay, dann eine Frage zu 301, 2. Leitungen. Sieht es aus, dass sie da verschiedene Weiterleitungen schon gemacht haben und dass das da an für sich über die Jahre sammeln sich natürlich solche Redirects an und wenn man die Logs anschaut, dann sieht es aus, dass Google dort immer noch die alten URLs ab und zu crawled und vielleicht hat das ja einen Einfluss, was könnte man da machen? Aus unserer Sicht ist das total unproblematisch. Wenn wir die alten URLs crawlen und ein Redirect sehen, ist das für uns eigentlich alles okay, dass es nicht ein Zeichen, dass irgendetwas falsch ist oder dass ihr das irgendwie besonders aufräumen müsst, oder dass das vielleicht ein Low Quality Website ist, ist ein für sich normal, dass wir auch die alten URLs ab und zu mal wieder kontrollieren und wenn wir sehen, dass eine Weiterleitung da ist, ist das für uns total okay und kann man da entsprechend auch folgen. Wir brauchen da vielleicht zwei oder drei Stufen hintereinander kommen, wenn man verschiedene Revamps gemacht hat von einer Website und das hat sich über die Jahre hinweg angesammelt, das ist vollkommen okay. Idealerweise hat man ein Redirect von der Ursprung URL direkt zum Ziel. Ich weiß einfach aus praktischen Gründen, kann man das natürlich nicht immer machen, wenn man jetzt ein, ich weiß nicht, verschiedene Revamps gemacht hat in die Jahre dann irgendwann hat man halt diese Redirects und die kann man dann nicht direkt zum Endziel bringen, eins zu eins und von dem her ist das an für sich okay. Also ich würde da jetzt nicht künstlich versuchen, das eben zu blockieren, mit Robots Text oder vielleicht ein 200er Code zurückzugeben oder 404. Aus unserer Sicht sind Redirects vollkommen okay und verursachen auch keine Probleme. Bezüglich Crawl Budget ist oft glaube ich ein Thema und was da noch dazukommt weiß ich nicht ob das jetzt in der Frage aber doch. Auch dabei ist aus unserer Sicht haben die wenigsten Websites irgendwelche Probleme mit dem Crawl Budget, das heißt gerade wenn man einen mittelgroßen Website hat, sage ich jetzt mal ein bisschen weiß ich jetzt nicht, mach mal, erfinde ich jetzt mal eine Nummer irgendwie 100.000 Seiten ist das aus unserer Sicht überhaupt kein Problem mit Crawl Budget, wir können eine Website mit so viel Seiten locker in entsprechenden Rahmen jeweils neu Crawl, in vielen Fällen können wir mehr als 1000€ am Tag Crawl und dann haben wir das im schlimmsten Fall, wenn wir alles neu Crawl müssen, haben wir das auch in einigen Tagen deug. Und von dem her würde ich mir wegen Crawl Budget keine Sorgen da machen und mit Crawl Budget ist es auch so, dass wir ein Serverseite in Redirect finden und den direkt folgen können bis zu fünf Schritten folgen wir den direkt beim Crawl, dann ist das an für sich keine weiter Eintrag im Crawl Budget bei uns das heißt, wir sehen dann einfach eine Seite haben wir schlussendlich geprawt, das waren 4 oder 5 Redirect die dazu geführt haben aber es war eine Seite und so können wir das an für sich direkt so weiter verarbeiten also es ist nicht so, dass diese Redirect dann noch mehr Probleme verursachen als wenn das separate Seiten wären aber wie gesagt, bei den meisten Websites ist das überhaupt kein Thema an SMX hast du gesagt, dass Noindex Follow wie ein 404-Seite behandelt wird das heißt, dass Links auf diesen Seiten nicht gefolgt werden was soll man mit paginierten Seiten zum Beispiel machen ja eben was vielleicht kurz zurück zum Noindex Thema allgemein auf unserer Seite, wenn wir sehen, dass eine Seite längerfristig ein Noindex hat, nehmen wir an, dass die Seite wirklich nicht indexiert werden soll und behandeln sie eigentlich wie eher wie eine soft 404-Seite und das sieht man oft auch in Search Console, wenn man bei den Soft 404-Fehler nachschaut sieht man oft, dass wir da vielleicht auch Seiten dabei haben, die auf einen Noindex haben und aus unserer Sicht ist es eigentlich okay normalerweise ist es auch unproblematisch bezüglich paginierten Seiten, weil wir trotzdem zu den ganzen Zielseiten irgendwie kommen und von dem her ist es eigentlich weniger problematisch wir haben bei uns im Hilferzenter, glaube ich Informationen über paginierte Seiten mit REL Next, REL Previous arbeiten kann, mit REL Canonical arbeiten kann man kann sich natürlich auch überlegen dass man einfach eine gewisse Menge von Seiten crawlen lässt und dann mit Noindex, Nofollow arbeitet das kann man auf jeden Fall auch so machen die URL-Parameter-Tour kann man auch nehmen für paginierte Seiten gerade, weil man Parameter hat in der URL Kann ich etwas fragen? Ja, klar Also, meine Deutsch ist nicht sehr gut aber ich sollte nicht warten auf die englische Zeit bei SMX München haben wir über Sitespeed gesprochen und ich wollte sicher sein dass ich richtig verstanden habe ich glaube, du hast gesagt dass jetzt Google nützt Chrome User Experience Report für Sitespeed zu bewarten ist das richtig? Wir verwenden verschiedene Sachen, die da zusammenkommen und das kann, ich glaube und beinhaltet auch die Chrome User Experience Report Daten das sind ja, ich glaube, verschiedene Metriken auch aufgeführt die hilfreich sind gerade beim Vergleich aber das sind natürlich niemals alle Websites dabei wir müssen da verschiedene Metriken trotzdem zusammennehmen um einigermaßen ein Gesamtbild von einer Website zu sehen Aber Chrome User Experience Report ist benutzt, ja und ist auch für den Ranking Signal So weit ich weiß verwenden wir da schon, ja aber eben wie gesagt, das ist ein von verschiedenen Varianten wie wir da Speed messen gerade für den Mobile Ranking Aber es wird Leute erklären, dass Dinge wie HTTP2 und Service Work ist, das deine Seite schneller machen Sie sind auch bei Google bemerkt oder wie sagt man Jawohl, auf jeden Fall, ja Okay, super, Dankeschön Bitte, dein Deutsch ist ganz gut Meine Frau sagt anders Ha, super Cool, okay Dann irgendwie ist jetzt alles unscharf Okay, kommt wieder Okay, WordPress erstellt automatisch Tankseiten für jedes Keyword und Kategorieseiten für jede Kategorie Hier werden bestehende Beiträge sortiert, ist es erstens ideal aufgrund von Duplicate diese Bereiche zu indexieren, oder was sollte man tun und indexiert sind, sollte man auf 404 zurücksetzen An und für sich könnt ihr die so indexieren lassen das hilft uns ein bisschen den Kontext von den einzelnen Seiten zu verstehen In den meisten Fällen ist es allerdings nicht so, dass diese Tank- und Kategorieseiten wirklich gute Landing-Bages sind für die Suche, von dem könnte man sich natürlich auch überlegen die einfach auf No Index zu setzen und sich auf die Sachen konzentriert die wirklich indexiert werden sollten aber das hängt ein bisschen von eurer Webseite ab wie ihr das handhaben wollt und für manche macht es vielleicht Sinn, dass man mit sauberen Kategorieseiten arbeitet für andere hat man da vielleicht alles mögliche angesammelt und die Kategorieseiten sind eigentlich nicht so wahnsinnig hilfreich Okay, dann eine Frage bezüglich Google News, wir ranken immer wieder bei Google News mit relevanten Artikeln zu den jeweiligen Keywords, allerdings in den News Karo Selbert eine völlig artikelfremde Überschrift angezeigt Ich glaube, die hast du mir auch mal zugeschickt Ich habe das mit dem Team hier mal angeschaut und im Moment ist es so, dass sie da nicht hundertprozentig herausfinden können, wo das herkommt Wir haben das aber bisher jetzt nur von dir gehört Das heißt, was ich da machen würde ist einfach sobald du so etwas wieder siehst, möglichst schnell mir eine Nachricht schicken, dass ich das möglichst im Team quasi auch zeigen kann wenn es live ist, damit sie das genau untersuchen können Wir haben gesehen, sobald man ein bisschen wartet, pendelt sich das wieder wichtig ein und das ist dann ein bisschen eine Frage Haben wir da vielleicht eine falsche Version gecrawlt, haben wir einen Vertauschung sonst wie gehabt beim Crawling oder beim Indexing oder ist es irgendetwas anderes bei uns in den Systemen was da vielleicht Probleme verursacht? Aber je eher wir das live auch nachstellen können, umso eher können wir da vielleicht ein bisschen genauer sagen, ah, das ist vielleicht von dieser Sidemap Datei oder das ist etwas auf unserer Seite, was wir beheben müssen ist ein bisschen schwierig zu sagen Kannst du etwas über den Google vor Update von Anfang März berichten? Eigentlich habe ich da nicht spezielles zu sagen, das sind solche Updates machen wir immer wieder wo wir unsere Algorithmen neu beurteilen, wo man vielleicht die Hintergrundstaten neu berechnen das passiert in vielen Fällen passiert das eher fließend dass man da kein direkten Übergang sieht in manchen Fällen sieht man ein Übergang, dass da verschiedene Algorithmen vielleicht zusammengekommen sind und dass wir das jetzt die Relevanz ein bisschen anders berechnen oder beurteilen solche Sachen können irgendwie manchmal zusammenkommen und dann hat man an einem Tag das Gefühl, ah, jetzt hat sich ganz viel geändert, dabei sind es eigentlich nur einzelne kleine Sachen, die zusammengekommen sind Ist es aus Sicht von Google okay, wenn Text per CSS innerhalb der Seite ausgeblendet wird das Hidden Content angesehen verstößt somit gegen die Webmaster-Rechtlinien und da ist da noch ein Beispiel angegeben ich habe das Beispiel mal angeschaut und ich finde das eigentlich nicht so toll gelöst was da passiert ist, dass man per CSS einfach ein kleines Fenster quasi hat für Inhalte und dass man den vollen Beitrag an und für sich da drin darstellen lässt und was dann passiert ist für normale Benutzern, sieht man diese kleine Fenster, vielleicht zwei, drei Zeilen von den Inhalten und je nachdem sucht man sie, können den ganzen Text dann entsprechend auch sehen und einerseits ist das denke ich aus Geschwindigkeitsgründen wahrscheinlich nicht ganz optimal weil ihr sendet diesen riesen Artikel jeweils zu allen Benutzern für all diese Beiträge die in diesen Listen drin sind das braucht einerseits Zeit und ein bisschen Platz andererseits ist das natürlich auch verwirrend für Benutzern wenn sie nach einem Text suchen und dann im Snippet würden sie z.B. sehen, ah das ist auf dieser Seite drauf dann klicken sie da drauf und finden diesen Text eigentlich gar nicht das ist ein bisschen verwirrend ich weiß nicht wie weit da das WebSpan-Team eingreifen würde in einem solchen Fall, weil es ist ja nicht so, dass da irgendwelche total fremden Texte irgendwie versteckt werden oder aus groben SEO Gründen wahrscheinlich da gemacht sind sondern man hat da einfach irgendwie eine Abkürzung halt genommen und gesagt gut, statt diesen Text selber abzuschneiden lassen wir das einfach per CSS und Browser machen aber ich finde das jetzt nicht optimal so ich würde das jetzt nicht so selber umsetzen oder so weiter empfehlen ja, danke und da noch eine kurze Nachfrage theoretisch, wir wegen MobileFest responsive das auf einem riesen 100 Zoller mit 8K Auflösung wenn es da doch angezeigt werden würde wäre es dann konform ähm ich denke dann eher, aber das hängt natürlich davon ab wo der Durchschnitts Benutzer dann am Ende liegt wenn das für den Durchschnitts Benutzer wirklich einfach nie sicher ist wenn jetzt wie in diesem Fall sind es glaube ich zwei Zeilen die sind zichtbar und man hat dann, ich weiß nicht, 40, 50 Zeilen Text dahinter dann finde ich das ein bisschen übertrieben oder unneutig zumindest ich, soweit ich das aus unserer Sicht von den Algorithmen beurteilen würde wahrscheinlich würden wir das eher in Richtung Keyword Stuffing anschauen und dann eh sagen, gut, das sind so viele Keywords auf diesen Seiten, wir wissen nicht wie wir das überhaupt einstufen sollen aber von dem her hat man eigentlich also würde ich es schätzen keinen richtigen Vorteil davon aus SEO Gründen das zu machen sondern man hat einfach diese Menge an Daten die man wirklich dann jeden Benutzer zuschickt und das ist an und für sich aus meiner Sicht unnötig ich würde da schon irgendwie schauen dass man das wirklich auch auf das Relevante beschränkt und dass man möglichst vielleicht auch eine Möglichkeit im Benutzer gibt diese Daten auch anzuzeigen wenn die gesucht werden wie das erweitern kann und ein größeres Fenster hat in diese Inhalte hinein beziehungsweise dass man halt wirklich hat einfach auf die einzelnen Beiträge verlinkt sodass wir die dort entsprechend finden können und die dann gezielt zeigen können in den Suchergebnissen John, ich würde da auch gerne kurz zu fragen und zwar haben wir eine Komponente gebaut in unserem CMS wo man den Text an einer bestimmten Stelle quasi beendet und dann hat man den Extended Text der per Klick also weiterlesen oder so aufgeklappt wird dann wird natürlich wenn Googlebot kommt nicht aller Text gerendert also weil der ersten Klick notwendig wird würden denn die sag ich mal aufklappbaren Texte auch mit indexiert so ähnlich wie bei einem Accordion ich denke das ist die Komponente die sonst alle kennen nur man hat immer Accordion halt immer nur einen Satz stehen oder eine Überschrift und bei das ist dann so dass das effektiv erst vom Server nachgeladen wird wenn man aufklickt oder ist schon aufgeladen auf der Seite ist schon im html mit drin wenn das so im html drin ist sehe ich da keine Probleme also dann nicht nachladen sondern wirklich schon bereitstellen aber halt nicht irgendwie verstecken künstlich verkleinern genau, ja ok, danke ok, mal schauen was für Fragen wir noch haben wir haben schon noch Zeit für eure Fragen auch wenn andere Sachen noch dazu kommen wir stellen gerade unsere strukturierten Daten vom Microdata auf JSON-LD um und haben jetzt im Moment beide Formate auf der Seite ist es quasi ein Problem müssen wir da das zurückstufen auf nur eine Version aus unserer Sicht ist das weniger problematisch wenn beide Varianten da sind sie sollten einfach übereinstimmen nicht dass in der einen Variante steht vielleicht fünf Sternen in der anderen steht vier Sterne dann wissen natürlich unsere Systeme nicht was sie damit machen sollen ich würde aber längerfristig schon versuchen auf möglichst eine Variante einfach das zurückzuschneiden damit man wirklich auch die Sicherheit hat dass man das sauber implementiert hat und dass man auch genau weiß wo man Fehler suchen muss und die eventuell auch korrigieren muss wir haben Tausende von Crawling-Failern ich glaube wie geht das im letzten Jahr hatte Googlebot durch einen technischen Fehler meinerseits mehrere Tausend Seiten der Suche geschnappt und jetzt sind die wahrscheinlich alle 404 oder 410 ist das ein Problem muss man da irgendwas machen aus unserer Sicht ist das total unproblematisch es ist total normal dass eine saubere Website die 404 zurückgeben die 410 zurückgeben wir probieren die trotzdem weil wir einfach sicherstellen wollen dass wir nichts verpasst haben aber wenn wir dann Crawling-Failer sehen ist das für uns total okay wir können damit leben wir wissen dass wir diese Seite nicht so indexierten sollen und das ist alles okay für uns auf jeden Fall nicht verstecken per robots Text umwandeln 404 oder 410 ist total okay für uns der Unterschied zwischen 404 und 410 bezieht sich in erster Linie darauf wie schnell das verarbeitet werden bei einem 404 schauen wir oft die Seite vielleicht ein, zwei Mal noch an um sicherzustellen dass es wirklich längerfristig 404 ist bei 410 geht das ein kleines bisschen schneller wenn das jetzt älterer Crawling-Failer sind endet das überhaupt nichts für euch ob ihr 404 oder 410 haben weil die haben wir ja schon irgendwie verarbeitet und die gehört aus dem Index heraus genau dann zum Thema hreflying xdefault bei einem Projekt liegen viele Sprach- und Landvariationen vor und es besteht nicht die Möglichkeit das Route Verzeichnis als xdefault anzugeben könnte man da zeichnet mal zusammengefasst könnte man einfach die englische Version zum Beispiel als xdefault machen das kann man auf jeden Fall machen also zwischen diesen ganzen Sprach- und Ländervarianten könnt ihr problemlos eine von diesen Varianten als xdefault zusätzlich definieren das heißt es kann eines sein die ihr sowieso schon markiert habt für Englisch oder für ein bestimmtes Land oder für eine gewisse Kombination und dass ihr einfach sagt das ist auch mal eine Default-Variante das könnte zum Beispiel sein um irgendwie ein Standard herauszufinden das ist für euch Standard für Benutzern aus anderen Ländern vielleicht sagt ihr auch einfach gut die englische Version ist diejenige die bei uns alle sowieso verstehen oder eher verstehen würden dann nimmt man vielleicht die Version aber das ist an für sich total euch überlassen wie ihr das einrichten wollt wir nehmen den xdefault in erster Linie dann wenn wir einfach keine weitere Zuordnung finden die da entsprechend passt und wie schon bei der ersten Frage da gesagt ich würde auf jeden Fall schauen dass ihr eben einen Backup habt dass ihr zum Beispiel mit dem Banner arbeitet auch auf der xdefault Version einfach um sicher zu sein dass falls jemand mit einer Sprach- oder Ländervariante auf diese Seite kommt für die ihr schon ein Ziel eigentlich hättet dass ihr den Benutzern eher dahin schicken könnt okay wir haben viele Produktvariationen die keine Rankingrelevanz haben die Produktnamen allerdings schon also irgendein Name und ein Farben zum Beispiel oder Farbvariation jetzt wir ranken mit dem Keyword und die unterschiedlichen Farben sollten mit einem Canonical ausgezeichnet werden was würde da zum Beispiel passieren mit dem Canonical aus unserer Sicht was da passiert mit dem Canonical ist dass wir uns dann eher einfach auf die Canonical URL konzentrieren das heißt eben wie gesagt wenn alle Signale zusammenkommen wir diese URL auch als Canonical nehmen und wir nehmen dann die Inhalte von den anderen Seiten nicht dazu das heißt wenn ihr zum Beispiel mit diesem Keyword eine Seite für schwarz habt und das Wort schwarz gar nicht auf der Hauptproduktseite erwähnt dann kann es sein dass wir dieses Produkt indexieren und gar nicht wissen dass da irgendwie die Kombination schwarz und dieses Produkt irgendwie verfügbar wäre und das wäre dann vielleicht problematisch das heißt ihr müsst einfach gerade wenn ihr verschiedene Variationen habt und das auf einer Hauptseite quasi per Canonical weiterleitet müsst ihr einfach auch wirklich schauen dass diese verschiedenen Variationen zumindest erwähnt werden damit wir wissen dass wir alle Informationen haben die zu diesem Produkt gehören und von dieser Canonical Landing Page kann man dann immer noch zum Beispiel auf die schwarz oder die rot oder die grüne Variante entsprechend auch wechseln das ist denke ich mal das Wichtigste dass man einfach weiß dass wir für die Inhalte wirklich nur die Canonical Seite dazu nehmen bezüglich Page Rank und Links auf unserer Seite wenn wir verschiedene Urals haben und davon ein Canonical aussuchen geben wir alle Signale entsprechend weiter an das Canonical das heißt wenn Links zu diesen verschiedenen Fahrvarianten vorhanden waren klappen wir das entsprechend dann zu dieser Hauptvariante zusammen ähnlich wie eine Weiterleitung wir planen einige Bereiche im Menu erst nach einem Click wir planen diese Bereiche zum Beispiel Catalog Bestellung Special bilden den Großteil des Quellcodes welche Vor- und Nachteile könnte das wir unsere Seite haben ja ich denke wichtig ist einfach zu wissen dass wir die Inhalte indexieren die wir beim Laden der Seite vorfinden das heißt wenn die Inhalte nicht direkt sichtbar sind ist das mehr oder weniger dass sie sollten auf der Seite irgendwie geladen sein also im Dom wenn man das im Browser aufmacht sollten die geladen sein das heißt wenn es bestimmte Bereiche gibt innerhalb der Seite die erst vom Server geladen werden nachdem man draufgeklickt hat ist die Chance sehr groß dass wir nicht wissen, dass wir da klicken müssen und das Google Wort gar nicht weiß dass da weitere Inhalte nachgeladen werden vom Server in den meisten Fällen mit Menus ist das weniger problematisch weil die lassen sich ja schnell im Source Code mit liefern die brauchen auch nicht wahnsinnig viel Platz manchmal ist es aber so dass man zum Beispiel mit Tabs arbeitet auf einer Seite und dass man mit einem zweiten Tab anklickt dann wird das nachgeladen und innerhalb einer gleichen URL werden dann diese Inhalte dann entsprechend dargestellt und für Google Wort weiß nicht wo man klicken kann und weiß entsprechend auch nicht was danach passiert das heißt diese Inhalte die nachgeladen werden, die sehen wir gar nicht und können sie entsprechend auch nicht indexieren John, da hätte ich noch Frage zu man könnte ja diese also diese Menupunkte, das haben wir nämlich jetzt auch gemacht in der Navigation um nicht zu viele Hierarchien zu haben in der Navigation haben wir mal wir sagen dann nicht Rändern zum Beispiel dritte, vierte Ebene genauso gut könnte man dann ja auch per CSS mit Displanern arbeiten Google Wort müsste es sehen, aber der User sieht es in dem Moment nicht und dann halt für diese Klasse dann entsprechend per Jahr was könnte vielleicht eingreifen dass sie dann doch sichtbar werden nach dem Klick oder das kann man auch jeden Fall machen bei die technische Lösung wenn man das so macht oder per CSS das quasi einfach umschaltet auf Hover oder was auch immer ist das total unproblematisch aber wenn das erst vom Server geladen werden muss nachdem jemand da klickt dann sehen wir das natürlich nicht und manchmal ist es auch so dass man einfach sagt gut das sind Zusatzpunkte die sind nicht kritisch, wenn das zum Beispiel Special sind oder irgendwelche Aktionen die einfach zeitlich begrenzt sind die sowieso irgendwo in der Navigation verlinkt sind dann so lange man damit okay ist, dass die nicht so indexiert sind, kann man das auch einfach so lassen. Da hätte ich jetzt nochmal ein Zusatzfall, man kann ja auch diese Seiten die dann eigentlich erst nach dem Klick für den User sichtbar werden sollen, kann man ja trotzdem wenn sie indexiert werden sollen in der Sitemap mit liefern in der Sitemap XML dann kann man sicherstellen, dass die auch trotzdem vom Google Crowd werden. Ja das kann man machen, wenn das normale URL sind also normale HTML Seiten wenn die Daten zum Beispiel per JSON geliefert werden oder irgendein anderes Format an dem Browser, an das JavaScript, dann entsprechend verarbeitet werden und dann erst dargestellt werden dann macht das natürlich wenig Sinn aber wenn das normale HTML Seiten sind, ja, kann man auf jeden Fall machen. Okay, dann für Speed wieder zum Speed, für den Speed habt ihr verschiedene Testing Tools, Page Speed Insights, Test My Side und Lighthouse und alles Mögliche noch dazu und warum und für wen gibt es so viele verschiedene Tools und welchen Tools wir mal verwenden. Ja denke, dass es immer eine Frage, die aufkommt. Wir haben immer wieder intern auch Diskussionen, ob man das nicht zusammenklappen könnte und einfach eintun machen könnte für all diese Sachen. Ich denke, es ist ein bisschen schwierig, weil die einzelnen Tools schauen oft Geschwindigkeit in verschiedenen Arten an und eben wie der Chrome Usability Report den Tom angesprochen hat vorhin sind da verschiedene Varianten wie man Speed bestimmen kann für eine Website und nicht jede Variante ist jetzt wirklich das kritisch für alle Websites. Das heißt, wenn man das genau nehmen will, ist es für den Webmaster eigentlich wichtig, dass man einerseits diese Tests mal macht und dann aber auch versteht, was bedeuten die Auswertungen, die da kommen. Bedeutet, dass das ich jetzt ein Problem habe, wie schlimm ist das Problem, ist das jetzt kritisch oder nicht. Gerade mit Page Speed Insights war es ja so, dass wir, ich weiß nicht, ob das immer noch so ist, aber dass man da einen Score zurück kriegt, dann steht dann drin irgendwie eure Seite ist jetzt 70 von 100 und irgendwie muss man das ja dann auch beurteilen können und überlegen ja, ist das jetzt kritisch, ist das weniger kritisch. Mit Test My Side haben wir das ein bisschen angeschaut, in dem das man da auf Vergleiche machen kann. Das man sagen kann, gut, das sind jetzt meine Hauptkonkurrenten und ich möchte jetzt mal sehen, wie der Vergleich ist von meiner Seite zu diesen anderen und dann sieht man sehr schnell schon ein bisschen mehr in Hinblick auf wie schnell sind die anderen. Kann ich zum Beispiel da immer noch schneller sein, bin ich da eigentlich die langsamste Website unter diesen Konkurrenten oder bin ich da eigentlich relativ gut im Rennen. Ich denke, das hilft auch ein bisschen, dass man das so anschaut. Aber eben die einzelnen Tests und die Testwerte muss man ein bisschen auch überlegen und versuchen zu verstehen, wo die herkommen, was da genau gemessen wird und wie das für eure Seiten entsprechend relevant sein kann. Wir versuchen mit diesen Tests in erster Linie euch einfach ein Gefühl dafür zu geben wie könntet ihr das zum Beispiel messen oder wie könntet ihr mit Zahlen arbeiten, wenn ihr die Geschwindigkeit einer Website anschaut, statt nur gefühlsmäßig die anzuklicken und denken, ja, eigentlich doch relativ schnell. Heute ein bisschen langsam, aber wenn man keine Zahlen dazu hat dann lässt sich das schon schlecht vergleichen, denke ich. Bezüglich Adsense und Maps ich denke, das kommt auch immer wieder auf als Thema, das man zum Beispiel sagt, ja, ich nehme jetzt Adsense von euch oder verwendet den Google Maps Plugin und auf einmal ist mein Page viel schlechter als vorher, könnt ihr das nicht einfach ausklammern, weil das kommt ja auch von Google. Aus unserer Sicht versuchen wir diese Testing Tools so zu machen, dass sie neutral sind möglichst. Dass wir dann nicht speziell darauf eingehen, welche Art von Werbung ihr zum Beispiel einbindet, sondern das werden wir sehen, dass die Seite einfach nicht mehr so schnell ist, wie sie früher mal war, dass wir das euch auch einfach sagen. Und dann ist es aus unserer Sicht in erster Moment egal, woher das kommt. Wenn ihr das anschauten seht, das sind die Google Werbe Blöcke, die da drin sind, die das Ganze viel zu langsam machen, dann könnt ihr aufgrund von dem dann natürlich auch weiterschauen und überlegen, macht das Sinn, dass man vielleicht weniger Blöcke einbauen oder kann man diese Blöcke anders einbinden. Kann man die vielleicht im Layout so einbauen, dass die Seite nicht neu berechnet werden muss, wenn die nachgeladen werden. All solche Sachen kann man natürlich dann genauer anschauen. Und das sind, eben aus unserer Sicht, ist es so, dass wir da möglichst das nicht einfach austammen wollen und sagen ja, das sind Google Sachen, die sind schon gut, sondern dass wir euch das Gesamtbild halt zeigen, wie das beim Benutzer natürlich auch so ankommt. Warum Mobile First, wenn es keine Auswirkungen auf das Ranking hat? Ja, ich denke bei vielen Seiten hat es wenig Auswirkungen auf das Ranking, bei einigen jedoch schon. Und das ist etwas, das wir gerade mit Mobile Friendly haben wir das zum Teil relativ zum Teil halt gesehen, das Websites gesagt haben, gut, ich mache eine Mobile Friendly Version, meine Website, aber die ist so abgespeckten, so vereinfacht, dass sie eigentlich zwar die Tests und die Kriterien erfüllt, aber eigentlich nicht wirklich brauchbar ist für Benutzer. Und dem wollten wir natürlich ein bisschen entgegenwerken, dass wir das, was ihr Mobile Benutzer zeigt, ist halt auch das, was wir so indexieren. Das heißt, wenn für euch irgendwelche wichtigen Informationen da sind, sorgt dafür, dass sie wirklich auf der mobilen Version vorhanden sind. Und viele Websites haben dieses Problem nicht. Die arbeiten mit einem sauberen responsive Design und da funktioniert das sehr gut mit der Funktionalität her. Ich denke, wenn man ein bisschen mit den Websites arbeitet, dann hat man das ja eigentlich auch relativ schnell und kann neue Websites so gestalten, dass sie problemlos mobile und desktop funktionieren, aber gerade bei einigen älteren Websites, wo dann die mobile Version quasi im Nachhinein einfach noch dazu gebastelt wurde, jetzt gut gesagt, da sehen wir halt schon die Probleme, dass die mobile Version wirklich nicht so bauchbar ist wie die normale desktop Version. Kann ich da nochmal nachhagen? Ja. Kann man mich gut verstehen? Ja. Das ist im Grunde natürlich klar, was du sagst. Nur, dass sie jetzt von der Logik her das ganze Prinzip umdreht. Bisher stand sozusagen desktop im Vordergrund und jetzt sind es eben die Mobilgeräte. Das Problem, was ich sehe, ist sozusagen im Content Bereich. Also, das heißt, die User Experience oder die Erwartung, die die User haben an Informationen, sind auf den beiden verschiedenen Geräten oder auf diesen Geräte Klassen ja verschieden. Und bisher, ja, ich meine, es gibt auch so ein Response of Content, wenn man so will. Ja, also viele wollen an Mobilgeräten nicht so lange lesen. Ja, wenn man die Seiten aufmacht, sind die viel kompakter sozusagen, das heißt, es sind endlos lange Seiten oft, wenn man sozusagen eine normale Inhaltsseite hat, dann sind die auf Mobilgeräten oft sehr, sehr lang. Insofern liegt es ja nahe, die User Experience insofern zu verbessern, als dass man versucht, Dinge kompakter zu machen, zusammenzufassen, kürzer zu machen. Und wenn man das jetzt sozusagen auch als responsive versucht zu machen, dann läuft es ja auch das hinaus, was wir eben schon als Problem hatten, dass man sozusagen bestimmte Inhalte dann ausblendet. Dann hast du natürlich gesagt, man kann das eben machen, in dem man eben sagt, man blendet es ja aus, man muss sie dann ja trotzdem nachladen, auch wenn man sie über CSS, oder nicht nachladen, sondern man muss sie mitladen, auch wenn man sie über CSS dann angesteuert. Das heißt, das ganze Problem ist ja schon flexer, als einfach nur zu sagen responsive CSS Design irgendwie, und dann hat man es mehr oder weniger gelöst. Man muss ja an User denken und die User haben eben schon unterschiedliche Erwartungen. Insofern ist natürlich die Frage, also dieser Mobile First Index ist das denn eben auch das, was in Zukunft die Grundlage für das Ranking sein wird? Ja. Okay, das heißt, was man auf Inhaltsseite jetzt macht und die User Experience für Mobile-Geräte-Besucher zu verbessern, wird dazu führen, dass das die Grundlage für zukünftige Rankings auch im Desktop-Bereich ist. Genau, ja. Okay, das ist natürlich schon wichtig zu wissen. Es gibt ja schon auch viele Projekte, oder einige Projekte noch, die eben vorrangig am Desktop sozusagen ihre Benutzer haben. Weiß ich nicht, also es ist ja oft von den Inhalten abhängig. Ja, also ich denke, wenn man wirklich starker Unterschiede hat zwischen Mobile und der Desktop-Version, würde ich die einfach nicht zusammenhängen. Und würde ich dann einfach nicht sagen, das ist jetzt die Mobile-Version von dem, sondern dass man wirklich auch zwei separate URLs hat, die man indexieren lassen kann. Und dann hat man das Problem natürlich weniger, weil dann können Benutzer trotzdem auf die Mobile-Version gehen. Man kann ja vielleicht auch mit einem Burner oder irgendwas arbeiten und sagen, wir haben die vereinfachte Version für Mobile-Benutzer hier. Und dann sind es ja auch eigentlich nicht die gleichen Inhalte. Jetzt im schlimmsten Fall gesagt, wenn ich jetzt alles auf irgendwie ein Abschnitt zurück begrenzen kann und in der Desktop-Version habe ich da eigentlich seitenweise Informationen, weil das eigentlich ein wissenschaftlicher Bericht ist oder so etwas, dann sind es ja eigentlich nicht vergleichbare Inhalte. Und dann macht es auch Sinn, dass man sagt, gut, ich habe zwei URLs, die ich so separate indexieren lasse. Ich denke, das macht nicht in allen Fällen Sinn. Manchmal sind ja die Unterschiede eher klein oder eher subtil und da muss man vielleicht auch selber schauen, wo man da die Grenze ziehen möchte, wie man das handhaben will. Aber wenn sie wirklich sehr unterschiedlich sind, würde ich sie separat indexieren lassen. Man kann problemlos auch sagen, gut, ich habe jetzt nur eine Desktop-Version von dieser Seite und jetzt nur eine Mobile-Version von dieser Seite. Das funktioniert ja auch für sich auch. Also, ob das nochmal ganz kurz für mich nachvollziehbar zu machen. Das heißt, wenn ich ein Artikel hätte, irgendwie die Relativitätstheorie von Albert Einstein, dann würde ich da einmal einen sehr langen Artikel drüber verfassen, der sozusagen für ein Desktop optimiert ist und dann mache ich einen zweiten Artikel, der heißt dann Relativitätstheorie kurz und bündig. So optimiert, dass er für Mobile benutzt hat. Und Google wird dann sozusagen von alleine rausfinden, dass das kurz für die Mobile gedacht ist und der lange für die Desktop benutzt oder gibt es auch schon eine Möglichkeit, das Google anzuzeigen? Wir sehen das natürlich über die Mobile-Friendliness. Das heißt, wenn jemand allgemein nach diesem Keyword sucht, und wir wissen, die Seite ist jetzt Mobile-Friendly und die andere ist nicht Mobile-Friendly, dann versuchen wir das mit dem Ranking natürlich schon nicht so hinzukriegen. Ich denke, das ist aber nicht unbedingt etwas, was ich jetzt wirklich allen so empfehlen würde, sondern ich denke, längerfristig wird es auch so sein, dass einfach immer mehr Benutzer auf ein Mobile-Gerät wirklich auch die vollen Inhalten erwarten und dass sie da wirklich auch alles nachlesen können. Beziehungsweise, dass man zumindest einen Link zu den vollen Inhalten dort hat und sagt, so weitere Informationen gibt es jetzt da. Ich weiß, ja, es ist manchmal ein bisschen schwierig. Ich denke, der Übergangszeitraum gibt es jetzt die paar Jahre, wo wir sagen, ja, es gibt solche, die machen fast alles auf Desktop und solche, die machen fast alles auf Mobile und die haben unterschiedliche Erwartungen. Ich denke, das wird im Laufe der Jahre schon in Richtung Mobile gehen. Aber wie ihr das Hand habt in diesem Zwischenraum, ja, es gibt verschiedene Sachen, die man hat machen können. Aber es ist nicht so, dass wir versuchen euch, alles in die Mobile-Variante reinzubringen. Sondern wenn ihr denkt, das macht Sinn, separat zu haben, dann könnt ihr das auf jeden Fall machen. Okay, vielen Dank. Ich würde da auch gerade noch mal rein fragen, weil gestern ein Kunde von mir direkt sagte, was ist damit Seiten, die jetzt überhaupt keine Mobilversion haben, fliegen jetzt komplett raus aus dem Index, verschwindet der Desktop-Index oder können die weiterhin ranken, weil Google einfach noch sagt, ja, ihr habt noch Zeit, ja, solche Seiten tauchen ja momentan auch auf mobilen Endgeräten in den Suchergebnissen auf. Haben natürlich unheimlich viel Content, wenn das Seoprojekte waren, wo ziemlich viel Interessantes zu einem Thema geschrieben wurde. Das wäre jetzt mal wichtig zu wissen, weil welches Interesse haben dann solche Webseitenbetreiber, eine responsive Seite zu machen? Wir zeigen trotzdem noch normale Desktop-Seiten auch an. Es ist an und für sich etwas, was auch auf normalen Mobilgeräten passiert. Das heißt, wenn ich auf eine Desktop-Only-Seite gehe, funktioniert die ja durchaus noch auf dem Mobilgerät. Man kann mit Zoom und so, dann trotzdem noch die Inhalte lesen, indexiert werden sie auf jeden Fall. Interessant war auch, also ich mit dem Engineering-Team für Mobile First gesprochen habe, einen von den Arten von Seiten, die besonders gut gehen mit Mobile First Indexing, sind die ganzen uralten Seiten, die mit Frontpage oder GeoCities mal erstellt worden sind und sich nie mehr verändert haben, die funktionieren ja überall, die sind vielleicht nicht optimal für Mobilgeräte und die sind nicht mobile friendly, aber vom Indexing her funktioniert das problemlos. Da verändert sich ja dann überhaupt nichts auf der Mobilversion, haben wir die genau die gleichen Inhalte, die Überschriften, die Bilder, alles finden wir ja da trotzdem noch. Warte mal. Weil ich gehe einen Schritt weiter, es geht in dem Fall um die, du wirst ja, die wird aufgefallen sein, dass immer mehr Leute das Design verenden, dass eine Startzeit ein ausfüllendes Bild hat. Das heißt, eBuff Default ist noch ein Bild und vielleicht ein Link. Wie siehst du das jetzt in Hinsicht auf die Crawlbarkeit, auf die Qualität, weil eBuff Default ja eigentlich gar nichts da ist. Außer Stimmung. Für den meisten Fällen ist das so unproblematisch. Gerade bei einer Homepage hat man natürlich eine gewisse Stimmung, die man auch übermitteln möchte. Es geht ja nicht nur um Information. Auf Produkteseiten im Gegend macht das natürlich schon, eher sind, dass man das zeigt, wonach die Besucher suchen. Das heißt, wenn jemand gezielt nach einer Stimmung spielt, dann gehört ja das ganze Stimmungsbild rund um die Firma ein bisschen dazu. Dann gezielt nach Information oder nach einem Produkt sucht, dann möchte man natürlich möglichst schnell diese Informationen haben. Und da würde ich dann vielleicht das halt ein bisschen auch minimieren, dass da wirklich nur die Startseite mit einem großen Stimmungsbild gefüllt ist und dass man erstmal nach unten scrollen muss, um zu sehen, ah, da kann ich jetzt meine Schuhe kaufen. Das denke ich, je nach Art von Seite entsprechend auch anders angehen. Okay, danke. Da habe ich tatsächlich gleich noch wieder eine Frage, wenn ich das Wort Bilder höre. Ja, natürlich. Ich habe das von euch jetzt nicht explizit gelesen, aber in der Konsequenz heißt ja Mobile First auch, dass man eigentlich auf HTML5 umsteigen muss und mit dem PictureTech arbeiten sollte, wo verschiedene Bildgrößen von vornherein ausgeliefert werden, die für das jeweilige Endgerät optimiert sind. Kann man machen. Im klassischen Responsive Design ist es ja oft so, dass quasi eine große Version oder eine mittelgroße Version geladen wird, die dann auf einem Desktop angezeigt werden kann und die wird dann einfach nur über Width und High sozusagen verkleinert für die Mobile Ansicht, ist aber natürlich ladetechnisch eigentlich blödsinnig, weil man muss immer das große Bild mitladen, auch wenn man es gar nicht angezeigt bekommt. Ich glaube, die werden nicht nachgeladen. Also, ich... Also, wenn man ein Bild hat, wenn es mal eine eine Source gibt, was sozusagen dann skaliert wird, dann wird natürlich nur diese eine Bildvariante geladen und die könnte aber natürlich auch für Mobilgeräte nur die Hälfte der Größe haben und es würde trotzdem angezeigt, wie man sich das denkt. Das heißt, im Grunde in der Konsequenz müsstet ihr doch empfehlen HTML5 und Picture Element verwenden für Bilder. Kann man auf jeden Fall machen. Kann weiß ich, aber ob man es machen soll, also ich würde es empfehlen, ich weiß einfach, es ist schwierig immer umzusetzen. Gerade wenn man jetzt eine ältere Website hat, all die Bilder neu zu verarbeiten, die verschiedenen Größen herzustellen und das sauber einzubinden, das ist sehr schwierig. Wenn man jetzt mit einem neuen Website arbeitet, mit einem CMS, welches da die Bilder schon von Anfang an sauber versteht, welches diese Sachen dann auch von alleine erstellt, würde ich auf jeden Fall empfehlen. Gerade mit älteren Seiten müssen wir einfach mit dem auch umgehen können, was wir da geliefert kriegen und da ist es ein bisschen schwierig manchmal. Okay, mal ganz kurz schauen, was noch bei den Fragen da dabei sind. Ach, das ist möglich und auch. Machen wir es vielleicht einfach, wenn von eurer Seite noch irgendwas Besonderes da ist, legt einfach mal los. John? Ja. Geht das Mikrofon? Ja. Ich habe noch eine Frage zu diesem Canonical Tech. Du hast ja gerade ausgeführt, dass man diese Produktvarianten auf einer Hauptseite leiten kann. Was ist denn jetzt konkret, wenn du eine Produktvariante hast und du hast noch eine Beschreibung, zum Beispiel, schwarze Schnürsenkel und schulschwarz. Wenn jetzt die schwarzen Schnürsenkel gar nicht vorkommen auf der Hauptseite, also bei uns ist es so, wir verlinken auf diese einzelnen Produktvarianten von der Hauptseite, aber steht jetzt kein konkreter, also keine konkrete Beschreibung noch bei. Dann geht das verloren. Und die Titel, die würden auch verloren gehen. Alles, was quasi mit dem Canonical weitergeleitet wird auf einer anderen URL, dann beschränken wir uns für die Indexierung wirklich nur auf die Canonical URL. Okay, alles klar. Okay, danke. Nehmen wir mal die letzte Frage, die da noch da ist, sind da noch einige, die ich jetzt da einfach mal überspringen. Ihr könnt die gerne in den nächsten Hangout wieder reinnehmen, kommen wir vielleicht schneller dazu. An der SMX war noch etwas über die Crawlbarkeit und Indexierbarkeit von JavaScript-Frameworks. Gibt es da faroisierte Frameworks oder rendering Techniken bei bestimmten Frameworks, die Google gerne hat? Was kann man dazu sagen? Ja, das ist jetzt gerade die wenigste Frage zum Ende noch mit der wenigsten Zeit übrig. Wie kann man das sagen? Aus unserer Sicht haben wir durch das quasi durch den ganzen Feedback, den wir gekriegt haben über JavaScript-Sites, haben da verschiedene Sachen gesehen, die bei uns noch nicht ganz optimal sind. Gerade bezüglich Geschwindigkeit von Indexieren, von den Inhalten und das sind Sachen, wo wir im Moment noch ein bisschen daran arbeiten. Wir versuchen da weitere Richtlinien zu erstellen, wie man das am besten angehen kann, als Webmaster, dass man da ein bisschen mehr weiß, in welche Richtung man gehen kann, gerade wenn man mit diesen modernen Frameworks arbeiten möchte, weil man hat natürlich viele Vorteile mit diesen modernen Frameworks, dass sie einerseits schnell für Benutzer sind, andererseits für die Entwicklungen auch relativ schnell sind und da möchten wir schon sicherst stellen, dass in der Suche das auch sauber so bearbeitet werden kann. Und im Moment haben wir da einige Informationen darüber, wie wir bei uns das Rendering machen, wie wir diese Seiten versuchen zu verarbeiten. Aber wir möchten uns eigentlich noch ein bisschen ausbauen, dass wir das wirklich ein bisschen klarer erklärt haben an Google Iow sprechen wir ein bisschen darüber, aber ich denke im Laufe des Jahres gibt es da immer weitere Informationen noch dazu. Also gerade für JavaScript Frameworks, denke ich, wird es da immer mehr geben. Im Moment ist es allerdings wirklich so, dass man auch ein bisschen mehr Arbeit hat, bis man das wirklich auch sauber hinkriegt. Okay, ich glaube zeitlich sind wir jetzt gerade dran und da kommt wahrscheinlich schon gleich für das Zimmer hier. Von dem her möchte ich mich bei euch erst mal bedanken fürs Kommen, für die vielen Fragen und hoffentlich sehen wir uns wieder in einem von den nächsten Hangouts. Danke dann, tschüss. Tschüss allerseits.