 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 wir machen, sind solche Webmaster Hangouts, wo Webmaster und Webpublisher ihre Fragen zur Google Suche stellen können. Sind schon einige Fragen eingereicht worden, aber wenn einer von euch möchte, kann sie gerne schon mal loslegen. Ja, ich würde gerne. Okay. Und zwar habe ich vorhin eine Frage zu Ranking und der Qualität einer Seite. Ich habe vor, ich weiß nicht, vor ungefähr drei Monaten habe ich PDF-Dateien veröffentlicht auf einer CDN-Domain, also komplett unterschiedlich von unseren Shops, und habe diese nur mit einer Sidemap-Datei praktisch verlinkt. Also es gibt keine internen Links, es gibt doch keine externen Links, und diese Seiten ranken sehr gut. Jetzt habe ich so geschlussfolgert, dass, wenn man gut ranken möchte, dass man praktisch für ein Thema nur eine einzige Seite hat und es auch nicht unbedingt so notwendig ist, vernünftig, interne Links zu haben, ist das so korrekt eigentlich? Also guter Content, wichtig auf jeden Fall, und diese Thema-Geschichte halt, ne? Also eine Seite, ein Thema. Ich denke, man kann das nicht immer so vereinfachen, aber oft hilft uns das, wenn wir ganz klar wissen, worum es geht mit einer einzigen Seite. Ich denke, es ist ein bisschen schwierig, das zu verallgemeinern, wenn man jetzt PDFs auf ein CDN zum Beispiel irgendwo hat, ist das ein bisschen eine andere Situation als, wenn man eine normale Website hat mit der normalen internen Verlinkung und den normalen Website-Inhalt. Von dem her würde ich da jetzt nicht aufgrund von dieser speziellen Situation mit dem PDFs auf ein normaler Website irgendwie das verallgemeinern. Aber interne Links, wie wichtig sind die für das Ranking? Also, es ist auf jeden Fall wichtig. Was uns mit meinen internen Links brauchen wir für zwei, wahrscheinlich verschiedene Sachen, aber für zwei grundlegende Sachen. Einerseits müssen wir diese verlinkten Seiten irgendwie finden können. Wir müssen das irgendwie crawlen können. Mit einer Seitenabdatei kann man ein bisschen da nachhelfen, aber die richtige interne Verlinkung hilft uns auf jeden Fall viel mehr und funktioniert, sag ich mal weniger Fehler anfällig, wenn man da genau sieht, was passiert. Und sie hilft natürlich auch bei anderen Suchmaschinen. Dazu kommen die Ankertext, die man intern verwendet und ein bisschen der Kontext von den Seiten, die verlinkt sind intern und all die Sachen helfen uns schon ein bisschen mehr zu verstehen, worum es sich handelt mit diesen einzelnen Seiten, die dort verlinkt sind. Das heißt, ich vermute, wenn du einzelne dieser PDFs intern noch sauber verlinken würdest, wären sie wahrscheinlich noch sichtbar. Okay. Okay, alles klar. Dankeschön. Am Anfang von Sidemaps war das immer auch ein bisschen eine Frage. Müssten wir jetzt gar keine internen Links machen, weil wir können ja alles mit der Sidemapdatei angeben. Aber es ist wirklich so, dass Sidemaps helfen, uns diese URLs zu finden und zu aktualisieren. Aber am besten, wenn man wirklich eine saubere interne Verlegung hat. Okay. Möchtest du sonst noch jemand loslegen am Anfang? Okay, dann gucken wir mal. Darf ich noch was fragen, wenn niemand will? Es geht um die strukturierten Daten. Einige Daten bekommen wir hier vom Google nicht anerkannt. Das ist also bei Side-Patch fast allabere ich da. Moment mal, Moment mal, muss ich selber mal gucken. Ja, bei Schema-Org, Entschuldigung, ist mir gerade nicht einkommen. Bei Schema-Org ist es nicht, ist es da. Aber wenn ich das bei Test-Tool, beim Strukturierten, beim Google mache, dann wird das nicht manchmal anerkannt. Und das ist jetzt meine Frage, wie können wir da weitergehen? Und gleich auch die zweite Frage, ist es besser zum Beispiel zu der Frage von dem Vorgänger, dass wir die strukturierten Daten in dem Hauptkontent einbinden sollten oder reicht das aus, wenn ich das in den Futter einbilde oder wo auch immer? Mit dem Erkennen von den strukturierten Daten müsste man wahrscheinlich die Seiten genauer anschauen, dass man da wirklich mal sieht, was ist auf den Seiten drauf und was wird dann nicht erkannt. Wichtig ist vielleicht zu sagen, dass bei Schema-Org gibt es sehr viele verschiedene Sachen, die man quasi markieren kann. Wir verwenden nur einen ganz kleinen Teil davon. Das heißt, man kann sehr viel Marker reinbringen auf die Seiten. Aber vom Google-Suche-Seite verwenden wir nur einen relativ kleinen Teil davon, den wir effektiv darstellen können in den Suchergebnissen oder irgendwie weiter verwenden können, um diese Seite ein bisschen besseren Suchergebnissen zu zeigen. Dazu kommt ein bisschen auch, dass da teilweise sind da auch Voraussetzungen dabei, bei der Art und Weise, wie wir Schema.org Daten erwarten. Das sind manchmal solche Sachen wie, ist da ein Bild dabei oder nicht? Und wenn da kein Bild dabei ist, dann können wir das vielleicht nicht als ein Artikel zum Beispiel verwenden, weil wir zeigen die Artikel in so einem Onebox-Element, wo wir dann immer ein Bild dabei haben. Ich weiß jetzt nicht, ob das immer bei den Artikeln so ist. Aber für die einzelnen Arten von der Verwendung von Structuredata gibt es da so gewisse Einschränkungen und Voraussetzungen, die wir haben auf unserer Seite, die bei Schema.org nicht unbedingt vorhanden sind. Ja, alleine schon. Alleine schon. Die Bildgröße zum Beispiel, wo du jetzt mit Bild angefangen hast. Wenn ich das so mache wie bei Schema-Org, es ist richtig und wird von Bing erkannt und so, aber bei Google habe ich dann Probleme. Ich würde einfach schauen, dass du da die Bing erkannt und in der Verlasserzeit bei uns genau konzentriert sind. Letztlich schauen, dass die Elemente die notwendig sind. Okay, danke. Ja, manchmal ist das auch ein bisschen kritisch. Da hilft es vielleicht, wenn man einfach mal im Webmasterforum nachfragt und dann gibt es dann vielleicht jemand, der sich damit auskennt, mit dieser Art von Structuredata und kann da ein bisschen weiterhelfen. Das ist manchmal für uns ein bisschen schwierig auf unserer Seite. Jemand kommt mit einer ganz speziellen Art, dann weiß ich da meistens auch nicht gerade, wo man das liebt. Das andere bezüglich der Platzierung von den Structuredata, wenn man mit JSON-LD arbeitet, dann ist es ja ein Javascript für sich und das kann irgendwo platziert sein auf der Seite. Wenn man hingegen die einzelnen HTML-Elemente markiert und das so für Structuredata verwendet, dann ist es für uns wichtig, dass diese Elemente sichtbar sind auf der Seite. Das heißt, man kann dann nicht alles einfach in Futter verstecken und dort quasi noch mal hineinkopieren, sondern es muss sich dann wirklich auf die einzelne sichtbaren Elemente auf der Seite beziehen. Je nachdem, wie man das einbindet, heutzutage verwenden viele JSON-LD und das kann man dann eben auch auf der Seite einbinden. Ah, okay, wunderbar. Okay, dann schauen wir mal die Fragen an. Wenn ihr weitere Fragen oder Kommentare zwischen euch habt, einfach nur loslegen. Eine Frage zur Qualität. Google berechnet die Qualität von allen indexierten Seiten. Ein Konkurrent hat extrem langsamer Seite. Viele Produktvarianten sind nicht indexiert, obwohl sie viel werden könnten. Hilft Google den Webmaster und de-indexiert die Seiten selbst und die Qualitätsverbesserung. Nein, eigentlich machen wir das nicht. Das heißt, wenn wir Seiten indexieren würden, dann würden wir sie auch indexieren. Aber was ein bisschen dazu kommt, ist, wir indexieren noch lange nicht alle Seiten, die wir finden im Internet. Und da kann es durchaus sein, dass wir sehr viele Seiten zum Beispiel per Seitenabdeckteil finden oder per interne Verlinkung irgendwo finden und uns einfach denken, gut, es macht im Moment keinen Sinn, dass wir noch mehr Seiten von dieser Website indexieren. Und dementsprechend hauten wir uns da ein bisschen zurück. Und das hängt ein bisschen mit der Qualität zusammen. Das hängt mit verschiedenen anderen Faktoren zusammen. Es ist an und für sich normal, dass nicht alle Seiten von einer Website indexiert werden. Und gerade, wenn man ein Influenced-Base hat mit bezüglich URLs, das heißt, viele URLs, die in verschiedenen Kombinationen mit Parameter zusammengesetzt werden können, dann ist es eigentlich ganz normal, dass wir da ein Teil vielleicht indexieren, aber ein Teil dann nicht, weil wir denken, das macht vielleicht nicht so Sinn, wenn wir uns da allzu fest verlaufen, vielleicht in diese verschiedenen URL-Parameter haben. Und da kommt vielleicht das, was du da gesungen hast. Aber die Geschwindigkeit zählt hier denn auch, also wenn die Seiten acht Sekunden dauern, irgendwie um die zu laden, dann würde doch auch Google sangen, bis sie dann langsamer crawlen, nur die wichtigen Seiten und dann, ne? Ja, vielleicht, vielleicht. Wichtig ist da vielleicht zu sagen, wir schauen beim Crawling eher auf die Geschwindigkeit von den einzelnen HTML-Requests. Das heißt, wie lang braucht es, bis die HTML-Seite heruntergeladen werden kann. Und das beeinflusst dann einfach die Anzahl URLs pro Tag, die wir crawlen können von dieser Website. Bei den meisten Websites, die sag ich mal weniger, weiß ich nicht, wenn wir vielleicht weniger als 1 Mio. Seiten haben, sagen wir mal, als Obergrenze, kommen wir durchaus klar mit dem Crawling. Auch wenn der Server recht langsam ist, da können wir einigermaßen da durchformen und können die meisten Sachen mehr oder weniger actualisieren und eigentlich soweit gut aufwinden. Wenn der Server sehr langsam ist oder wenn es sehr viel mehr Seiten sind, dann kann es schon sein, dass wir sagen, wir begrenzen uns auf, ich weiß nicht, 10.000 Seiten am Tag auf diesem Server, weil wir möchten ihn ja auch nicht überlasten, nicht noch mehr Probleme verursachen. Und wenn deutlich mehr Seiten vorhanden sind auf der Website oder viele Veränderungen gemacht werden auf der Website, dann kann es schon sein, dass wir die gar nicht erst bringen. Der andere Faktor ist quasi, wie schnell eine Seite geladen werden kann im Browser, das beinhaltet auch ein bisschen, wie schnell der Server allgemein ist, aber auch, wie man die HTML-Seiten gestaltet hat, wie man das zusammengebaut hat. Das ist auf unserer Seite schon auch ein Ranking-Faktor, aber wahrscheinlich nicht unbedingt etwas, was die Anzahl Seiten, die indexiert werden von einer Website groß beeinflussen wird. Ich denke gerade, die zwei verschiedenen Arten von Geschwindigkeit sind etwas, was sehr viele ein bisschen vermischen. Das ist auch, sagt man von unserer Seite, nicht immer hundert Prozent klar, von dem her ist es immer gut, da genau nachzufragen, was ist da eigentlich gemeint, dass es quasi die Zeiten der Server braucht, um die Antwort zu liefern oder wie es braucht, um die Seite in einem Browser fahrzustellen. Eine Frage zur internationalen SEO. Zurzeit werden einige Seiten bei uns im Seitentitel in Deutschland und in anderen Ländern mit einem Titel Southern Africa war die angehängt in den Suchergebungsnähen. Wir gehen davon aus, dass der Crawler durch die Language Cookie verwirrt ist. Könnt ihr das bestätigen? Ich habe das kurz hier mal angeschaut, was da passiert und ich weiß nicht genau, wo das herkommt, aber ich habe das mal an das Team weitergegeben. Dass die da schauen können, dass das ein bisschen besser gemacht wird. Was da grundsätzlich passiert, ist, wir haben einerseits ein Titel, den wir versuchen zu finden, für die einzelnen Seiten und zum Teil dann auch ein Titel, den wir suchen zu finden, für den Website insgesamt. Und irgendwie ist der Southern Africa auch hineingebaut. Das heißt, es hat weniger mit dem hreflang zu tun, sondern einfach mit dem Verständnis von welcher Titel wo hingehören auf diesen Seiten. Manchmal kann man das beheben, indem man wirklich einen klarer, strukturierter Website hat, dass man die normal crawlen kann, dass wir die einzelnen Länderversion jeweils auch normal finden können. Ich vermute, in diesem Fall ist das eher eine Verwirrung einfach auf unserer Seite, die wir da vielleicht beheben können, die aber auf jeden Fall auch im Laufe der Zeit auch sonst von alleine beheben werden. Hallo, John. Ich mache mal nach mit dem Team, ob man das ein bisschen schneller hinkriegen kann. Hallo, John Moritz von Garmin hier. Vielen herzlichen Dank für die Beantwortung schon mal. Wir haben auch gesehen, also wir hatten teilweise sehr kurze Seitentitel. Wir haben mit längeren Seitentiteln, haben wir dann quasi Southern Africa aus dem Titel rauskatapultiert, rausgeschoben, ja, sowohl auf dem Desktopmobile haben wir noch ein paar Mehrzeichen zur Verfügung. Da mussten wir das dann auch. Hat auch geklappt. Also teilweise hatten wir sogar auf dem Desktop dann das rauskatapultiert, Mobile hatten wir es noch nicht. Trotzdem ist das natürlich wahrscheinlich nur Behebung der Symptome. Und ich kann mir vorstellen, dass das, wenn Google das so versteht, dass die Seite Southern Africa zugeordnet ist, dass die in Deutschland, Schweden, Österreich, Schweiz, Kanada haben wir es auch teilweise sogar in USA, dass sie da nicht sonderlich gut rankt oder zumindest nicht so ranken, so gut rankt, wie sie theoretisch ranken kann. Deshalb, ja. Das sollt eigentlich vom Ranking her keinen Einfluss haben. Okay. Einfach nur der sichtbare Titel, die wir da zeigen. Und das ist zum Beispiel nicht das Gleiche, wie wenn das direkt in den Seiten eingebunden wäre als Titel. Sondern es ist wirklich einfach eine Hilfe, die wir denken, macht Sinn für den Benutzer oder bei euch halt nicht so wahnsinnig viel Sinn macht, wenn Benutzer. Aber es bezieht sich nicht auf das Ranking. Wir haben teilweise Klickraten, Einbrüche natürlich von über 20 Prozent, weil die Leute denken, sie sind in Southern Africa und nicht in Deutschland dementsprechend. Wird mich super freuen, wenn er mich da auf dem Laufenden haltet. Krieg ich da auf dieser, auf der E-Mail Nachricht von euch oder? Wahrscheinlich nicht. Normalerweise, was mit solchen Fällen passiert, ist, dass wir da das mit dem Team besprechen und sie schauen danach, was da die optimale Lösung ist und versuchen, dass sie selber im Sprechendom zu setzen. Alles klar. Und normalerweise haben wir da kein Feedback zu euch. Alles klar. Danke trotzdem. Okay. Dann eine Frage zum Mobile First Indexing. Am 6. September wurde Mobile First Indexing bei uns aktiviert. Seitdem wurden sehr viele Canonicals wieder rausgenommen. Ich habe unsere Produktvarianten bei Canonical auf die Hauptprodukte verlinkt. Seit dem 6. Oktober habe ich den Produktvarianten nun auf No-Index gesetzt. Leider sehe ich da keine Auswirkungen. In den Server-Logs sieht es so aus, als ob Googlebot die Seiten crawled. Aber das klappt nicht so schnell wie vorher. An und für sich mit Mobile First Indexings sollte sich dann nichts verändern mit der Geschwindigkeit von der Verarbeitung von Mattertags. Das heißt, wir crawlen die Zeit einfach mit dem Smartphone-User-Agent und so, sobald sie wir crawled worden sind, können wir sie auch bearbeiten. Und wenn da in Boards Mattertags ein No-Index vorhanden ist, dann nehmen wir das so auf. Dann wird das nicht wie langsamer verarbeitet, als wenn das per Best-Up-Crawling verarbeitet wäre sonst. Ich vermute, dass es da eher einfach eine Frage ist von der Anzahl URLs und wie häufig wir die crawlen. Und dass es da dementsprechend einfach nur eine Frage der Zeit ist, bis sich das entsprechend ein bisschen breiter umgesetzt hat, in den Supergeist. Wenn du einzelne Fälle hast, wo du gesehen hast, dass sie wirklich aufgecrawled worden sind und trotzdem nicht rausfallen, kann ich die auf jeden Fall auf die Firma kurz nachschauen. Und mal schauen, was da jetzt aber herauskommt. Du kannst es aber auch selber testen mit dem Inspect URL Tool. Du kannst ja einerseits die aktuelle indexierte Variante anschauen und andererseits die Live-Version anschauen und dann sehen, ob Googlebot das so aufnehmen würde oder nicht. Bei uns werden so circa 1.000 Seiten pro Domain gecrawled ihren Tag. Weiß nicht, ob das jetzt, sogar in der Schweiz waren es sogar an einem Tag jetzt fast 10.000. Aber wie gesagt, also ich sehe jetzt, dass in der alten Search-Konsole wurden die indexierten Seiten zum 14. Oktoberhin korrigiert um 100. Also 100 sind weniger und ich habe wahrscheinlich 20.000 ausgeschlossen URLs insgesamt. Also ist nicht wenig. Also kann es auch sein, dass vielleicht Google erst mal denkt, das ist ein Fehler und braucht eine Bestätigung, also dass zwei Wochen lang vielleicht nur Index gesetzt ist. Sollte eigentlich nicht sein. Also es wird sofort ausgehen. Ja, es gibt Situationen, wo unsere Systeme mit der Verarbeitung ein bisschen nach sind, wo sie vielleicht versuchen, ein bisschen Sicherheitsabstand fast zu halten. Aber für die meisten Fällen sollte das eigentlich direkt bearbeitet werden. Ist es einfach in den Search-Konsole oder ist das insgesamt auch, was sie in den Suchergebnissen trotzdem weiterhin erscheinen? Ja, also in einer neuen Search-Konsole ist es halt noch nicht. Da ist noch gar nichts angekommen. In der alten kann man jetzt 100 weniger sehen. Suchergebnisse, also Zeitabfragen sind auch immer noch alle da. Ich weiß, die sind immer so ungefähr. Aber ja, also das Inspektor-Tool, das zeigt man halt auch. Klar, wenn ich dann Inspektor-Tool dann laufen lasse, dann zeigt er mir schon an. Live URL ist halt auf Nu Index. Aber ja, weiß ich auch nicht. Also seit dem Mobile First Index eigentlich, weil vorher habe ich Nu Index gemacht und dann ging das innerhalb von zwei Tagen, das dann auf einmal 400 Seiten raus waren halt. Ja, ich soweit ich weiß, sind die indexierten Informationen im Search-Konsole natürlich immer ein bisschen verspätet, aber es sollte eigentlich nicht allzu best verspätet sein. Ich kann da mal nachschauen. Wenn du mir einzelne URLs vielleicht mal schicken kannst oder ein Chatfeind tun kannst, dann kann ich die immer nachschauen, weil wir die gecrawled haben, wie lange es da gebaut hat, bis wir die dann effektiv fallen gelassen haben aus dem Internet. Ja, okay, eine Frage noch dazu. Wenn man jetzt viele Seiten des Off-Nu-Index setzt, wann wird die Qualität dann wieder neu berechnet? Passiert das laufend oder ist das da noch einmal im Quartal? Das passiert an und für sich laufend, aber gerade für eine größere Webseite braucht das einfach eine gewisse Zeit, bis wir das wirklich neu beurteilen können. Und das ist meistens nicht etwas, wo man, zeige ich mal, nach einer Woche oder so, keine größere Veränderung sieht, sondern das sind dann eher so quasi graduelle Veränderungen, die im Laufe von einer Monat ungefähr starten. Ja, und ein angenommenes Canonical gilt das auch als No-Index. Ist das dann raus aus der Qualitätsberechnung? Fahre Sie eine URL mit dem URL Canonical auf eine andere URL, ob das eine URL gezählt wird. Wir zählen nur die Canonical URLs, also nur diejenigen, die effektiv auf den Suchergebnissen erscheinen können. Okay, alles klar, Dankeschön. Okay, dann eine recht lange Frage. Kann man das zusammenfassen? Ich glaube, da ist es so, dass innerhalb von Kategorienzeiten werden die Produkte durch JavaScript eingebunden und erscheint so zu sein, dass diese Kategorienzeiten nicht besonders gut erscheinen in den Suchergebnissen. Das ist ein bisschen die Frage, was das kann man da machen. Was wir mir gefallen gibt es da. Ich weiß jetzt nicht genau, was ihr da schon verändert habt. Es klingt ja sowas so, irgendetwas mit der Art und Weise, wie diese Produkte eingebunden werden, sich da schon verändert wurde. Bezüglich JSON-LD-Markierung. Ich weiß nicht genau, was da genau gemacht worden ist. Im Grunde genommen ist es so, dass wir die Seiten irgendwie rendern müssen. Das heißt, wenn die Inhalte per JavaScript erstellt werden, also in diesem Fall die Produkte innerhalb dieser Framework-Seiten. Wenn die per JavaScript erstellt werden, müssen wir diese Seite rendern können. Das heißt, Googlebot muss irgendwie diese JavaScript ausführen können, muss all diese Produktlisten, die Produkte, die da drin sind, entsprechend finden können, gegebenenfalls mit einem Aufruf beim Server, um diese Information zu kriegen und baut dann von dem Schritt aus dann die Seite entsprechend auf. Das heißt, es sind da einige Schritte mehr vorhanden, als wenn mir jetzt alles direkt in der html-Seite eingebunden wird. Das heißt, es kann auch unter Umständen ein bisschen mehr schiefgehen, wenn da irgendetwas mit dem JavaScript so gestaltet ist, dass Googlebot was nicht sauber ausführen kann. Ein am einfachsten, wie man das testen kann, ist mit dem Mobile-Friendly-Test. Das sieht man ja sehr schnell, ein Screenshot von der mobilen Version von der Seite. Der wird erstellt mit Googlebot mit mehr oder weniger den normalen Einstellungen von Googlebot. Und das sieht man ja sehr schnell, dann werden diese Produkte aufgeführt oder werden die gar nicht aufgeführt. Wenn sie gar nicht aufgeführt werden, dann muss man da wahrscheinlich in JavaScript hineintauchen und schauen, was da genau schiefgeht. Im Mobile-Friendly-Test hat man auch die JavaScript-Consoles, da kann man das ein bisschen genauer anschauen. Wir haben auch verschiedene Informationen, wie man das testen kann in unseren Developer-Dokumentationen. Da würde ich in einem solchen Fall das vielleicht mal ein bisschen anschauen, überlegen, was man da recht anders machen müsste. Das andere, was da noch dazu kommt, ist, wenn die Produkte per JavaScript eingebunden werden, müssen wir einen Link auf diese Produkte trotzdem irgendwie noch finden können. Das kann per JavaScript gemacht werden, aber es sollte normaler HTML-Link sein. Also so ein A-Tag müsste da eingebunden werden unter Umständen per JavaScript. Das ist auch okay. Aber man sollte zum Beispiel nicht einen Dev-Erstellen mit einem Contrack-Handler, sondern es sollte wirklich ein normaler HTML-Link am Ende sein, den wir normal auch folgen können für normales Crowd. Und das ist eigentlich das Wichtige auch für uns da, dass wir da die Seite nach dem Rendern normal crowden können. Ich denke, das sind schon mal die wichtigsten Elemente da. Ein Element, den man da vielleicht noch berücksichtigen müsste, ist, dass dieses Rendering dauert teilweise ein bisschen länger als normales Crowding. Das heißt, je nach Website kann es lecker sein, dass es in ein paar Tage geht oder vielleicht in eine Woche oder vielleicht sogar länger, bis wir diese Seite gerendert haben. Das heißt, einfach für euch aus praktischen Gründen, wenn da etwas auf diesen Seiten ist, was schnell indexiert werden müsste, dann würde ich schauen, dass man das in das HTML einbindet und nicht nur mit der JavaScript-Version einbindet. Weil wie gesagt, JavaScript braucht ein bisschen länger, bis das alles verarbeitet wird. Und wenn es schnell indexiert werden soll, dann muss man das natürlich möglichst früh auch haben. Bei vielen e-commerce-Sites ist das wahrscheinlich nicht so kritisch, weil die Produkte wechseln ja nicht so schnell. Wenn man zum Beispiel ein Option-Website hat oder ein Immobilien-Website, wo die Produkte sich sehr schnell verändern, dann ist das wieder ein bisschen anders. Dann muss man natürlich ein bisschen mehr auf die Geschwindigkeit achten als auf die JavaScript-Seite. Bezüglich JSON-LD, JSON-LD ist etwas, was man verwenden kann, um uns strukturierte Daten zu geben, aber wir verwenden das nicht gleich wie zum Beispiel einen Link auf diesen Seiten. Das heißt, per JSON-LD kann man uns ein bisschen mehr Informationen da geben, aber es ersetzt eigentlich nicht einen normalen HTML-Link auf diesen Seiten. Von dem her, denke ich, kann man nicht unbedingt davon voran ausgehen, dass mit JSON-LD, das man so gesagt hat, wieder republikieren kann. Okay, dann schauen wir mal kurz die Fragen an. Kann die problematische Indexierung am JavaScript liegen? Unter Umständen haben wir kurz angeschaut. Das ist ein besser statisches Rendering, einführen anstelle vom JavaScript. Wie gesagt, wenn wir die Seiten rendering können, ist das schon mal wichtig. Wenn die Inhalte sich nicht allzu oft verändern, ist das auch okay aus unserer Sicht. Wenn sich alles sehr schnell verändert oder ihr JavaScript in einer Art verwendet, die Googlebot nicht versteht, dann macht es vielleicht Sinn, dass man mit Dynamic Rendering arbeitet. Das ist Server-Side Rendering für Googlebot oder für andere Suchmaschinen und die normale Klein-Side-Version für Nutzer. Was hat mehr Gewicht, JSON-LD oder Links? Zum Crawling brauchen wir wirklich die Links. Wie weit ist Google mit der Auswertung des JavaScript Rendering? Wie gesagt, wir sind da eigentlich schon recht weit, aber es ist trotzdem immer noch diese zeitliche Differenz. Und zum Teil halt auch die JavaScript-Funktionalität, die bei Googlebot im Moment nicht vorhanden ist. Wir haben auch eine JavaScript Working Group erstellt. Das ist eine halb private Google Group, wo sich verschiedene Leute treffen, die mit JavaScript Zeits arbeiten und gerade bezüglich Google-Suche Fragen haben. Da würde ich vielleicht auch mal vorbeischauen, wenn du nicht ganz sicher bist, ob das jetzt funktioniert, wie ihr das implementiert habt oder welche Richtung ihr da gehen soll. Meine Seite ist vom Design her nicht mehr zeitgemäß und auch nicht responsive. Deshalb möchte ich gerne ein Re-Launch machen. Allerdings scheint die Seite seit längerer Zeit unter einer Penalty zu leiten. Könntest du dir die Seite mal anschauen und mir so weit es geht, ein paar Hinweise geben, was man da quasi machen könnte. Also ich habe mir die Seite angeschaut. Ich denke, der Grundgedanke, dass man da das vielleicht modernisieren kann, ist sicher nicht schlecht. Was ich hingegen aber auch gesehen habe, ist, dass du tonweise ähnliche Websites hast. Und das ist etwas, was einerseits wahrscheinlich eher Probleme verursacht bei dir, als dass es dir groß weiter hilft. Weil die ganzen Werte, die du aufbaust auf diesen Seiten, ist natürlich in all diesen kleinen Inseln verteilt, auf all den verschiedenen Domänen. Und das macht es ein bisschen schwieriger zu erkennen, dass da wirklich etwas Sinnvolles und Hilfreiches ist, dass wir wirklich stark in Suchergebnissen zeigen müssten. Und von dem her würde ich da vielleicht eher anraten, zu überlegen, wie könnte man, wenn man jetzt ein Re-Launch sowieso machen möchte, wie könnte man das ein bisschen kombinieren, dass man wirklich wenige sehr starke Domains aufbauen kann anstelle von all diesen vielen kleinen Inseln, die du da aufgebaut hast. Und ich könnte mir auch vorstellen, dass das vom Qualität her, von unseren Qualitätsalgorithmen, dass sie das auch ein bisschen begrüßen würden, wenn sie da wirklich sehen würden. Da ist wirklich etwas Starkes und Tolles zusammengebaut. Und anstelle von, ja, das sieht aus wie da ein riesen Netzwerk von Websites, die alle miteinander irgendwie verlinkt sind und wo man nicht genau weiß, wie kann man dem wirklich trauen. Von dem her würde ich da neben ein, sagen wir mal, Re-Launch bezüglich den, sagen wir mal, dem Layout und so, würde ich mir auch gleich mal überlegen, wie kann man dieses Gesamtgebilde von all diesen Websites ein bisschen vereinfachen und ein bisschen so machen, dass das wirklich stärkere Sites sind und nicht allzu viele kleine Inseln. Und ich glaube, das würde wahrscheinlich auch die nächste Frage von dir betreffen. Bezüglich der anderen Website, über die Weiberfassnacht, da könnte ich mir schon auch vorstellen, dass eben dadurch, dass so viele verschiedene unterschiedliche Websites vorhanden sind und alle miteinander ein bisschen verlinkt sind, dass unsere Algorithmen dann nicht ganz sicher sind, wie sie mit diesen Websites einzeln umgehen sollen. Wie werdet Google eigentlich Linktexte innerhalb des Contents, wenn die verlinkte Wörter nur als Linktexte gesehen oder sind sie zugleich Wörter, die als Content gezählt werden? Ja, sie gelten für beides. Das heißt, einerseits ist das ein Enker für ein Link, andererseits ist es auch ein sichtbarer Teil von den Inhalten auf diesen Seiten. Das macht ja soweit auch Sinn, wenn man zum Beispiel einen Satz hat und einfach einzelne Wörter sind als Link zu anderen Teilen der Website da, dann ist dieser Satz gehört zu dieser Seite und dieser Enkertext, der gehört eher zu anderen Seiten noch dazu, aber da ist kurz noch ein Teil von dieser ursprünglichen Seite. Das heißt, diese verlinkten Texte gelten eigentlich für beide, beide Richtungen. Gibt es Statistiken bezüglich Nutzerverhaltens bei der Google Suche durch die Sprachangabe? Weiß ich nicht. Ich vermute, es gibt schon Statistiken irgendwo, aber ich bin mir jetzt nicht sicher, was da alles öffentlich ist. Ich weiß, es kommen da immer wieder Fragen, dies bezüglich, aber ich habe eigentlich noch nichts gesehen, was wir da groß öffentlich herausgegeben haben. Viele Seitenbetreiber entscheiden sich aktuell für Dynamic Serving ihre schwere JavaScript-lastige Seite von Google zu crawlen und indexieren zu lassen. Wie geht ihr mit den unterschiedlichen Ladezeiten und gegebenenfalls Darstellungsmöglichkeiten um und wie erfasst ihr diese? Angefühle sich klappt das in den meisten Fällen relativ gut. Das Dynamic Rendering, wie wir das nennen, ist angefühle sich eine Art von Dynamic Serving in dem, dass man da die Inhalte auf das Endgerät anpasst. Man kann das ja einerseits für mobile Geräte machen, dass man sagt, ich habe jetzt eine Version für Desktop und das ist die mobile Version davon. Das ist eine Art, Dynamic Serving zu machen. Für Googlebot ist das entsprechend ein bisschen anders, dass man sagt, Googlebot kommt vielleicht mit der Artbeweise vom JavaScript, wie ich das im Moment verwende, nicht klar. Deshalb gebe ich da eine statische HTML-Version zurück. Aus unserer Sicht, sofern die Inhalte equivalent sind, ist das total okay. Ist das nicht etwas, wo wir sagen würden, das gibt uns irgendwie Probleme oder das verursacht irgendwelche Schwierigkeiten bei der Indexierung oder bei der Erkennung von den Signalen. In den meisten Fällen klappt das eigentlich so weit gut. Bezüglich Ladezeiten ist es so, dass wir verschiedene Metricen nehmen für die Ladezeiten und in den meisten Fällen sollte das eigentlich so weit klappen. Es sollte ja eigentlich auch so sein, dass eine schwere, zweimal JavaScript-lastige Seite, wie jetzt da eine Frage, sollte trotzdem noch relativ schnell geladen werden können im Browser. Da gibt es ja verschiedene Techniken, wie man Seiten schnell machen kann und JavaScript ist nicht unbedingt das, was am meisten abwämsen wird. Was hältst du von Difftags? Ich frage mich eine relativ offene Frage. Sie sind normale HTML-Elemente. Eigentlich nicht starke Gefühle bezüglich Difftags. Die verwenden die meisten Websites ja. Eine Frage zur Verteilung von PageRank bei paginierten Seiten. Einen Job hat eine Jobkategorie mit insgesamt 100 Seiten, die links Artikel enthalten. Mit Rail Previous und Next wird gearbeitet. Ist dann quasi, denke ich mal, die Frage, wie klappt das mit den Links auf all diesen Seiten? Wenn man erst mal zur Seite 94 durchblättern muss, um einen Link auf ein Artikel zu finden. In den meisten Fällen klappt das eigentlich recht gut. In den meisten Fällen müssen wir auch nicht so weit durchblättern, um einen Link zu einem einzelnen Produkt zu finden, sondern es gibt ja verschiedene Kategorierungen. Oft sind diese Produkte innerhalb von verschiedenen Kategorien dabei. Wenn man zum Beispiel mit verwandten Produkten auch quer verlängt, dann gibt es ja verschiedene Wege, die wir nehmen können, um dieses Produkt zu finden. Und dann ist es nicht unbedingt so wichtig, dass jetzt auch Seite 1 oder Seite 94 von einer paginierten Liste vorhanden ist. Zumindest in den meisten Fällen, die ich angeschaut habe, ist es da unproblematisch, wie das so verlinkt ist. Klar, wenn ein Produkt nur von Seite 94 von einer langen Liste verlinkt ist, dann ist es ein bisschen schwieriger, uns zu sagen, dass es wirklich etwas Wichtiges für diese Website und dementsprechend kann es sein, dass wir da diese Seite vielleicht weniger häufig crawlen, vielleicht auch weniger Gewicht umgeben innerhalb der Website. Also die Sachen kommen ein bisschen dazu. Dann noch eine Frage wegen den Bananen auf Twitter. Das hat da eigentlich keinen besonderen Hintergrund. Ich glaube, ich habe mich irgendwann auf Google Trends mal angemeldet und gesagt, das wollen wir die Trends für Bananen schicken und da ist mal über Google Trends eine Nachricht gekommen, dass die Nachfrage nach Bananen stark gestiegen ist und das war nochmal lustig. Habe ich also reingetan, allen für sich sonst nichts. Cool. Wir haben eine Seite, die sich mit dem Thema wie bestimme ich meine Genesgröße beschäftigt, welche unter den Top 3 bei Google Rankt. Diese Seite erreicht unser Domain den meisten Traffic, hat allerdings eine hohe Absprungkarte, da User ihre Informationen finden und wieder verschwinden. Ja, Wort Nachteile. Durch eine genaue Maßnahme konnten wir die Bounce Rate von 92 Prozent auf 77 Prozent senken, allerdings ist das immer noch sehr hoch. So sollte man so eine Seite lieber deaktivieren und Google nicht das Signal einer hohen Bounce Rate zu geben, online lassen, da sie sehr viel Traffic erzeugt. Ich würde das eher einfach insgesamt anschauen für die Website und mir überlegen, sind diese Besucher, die über diese Seite kommen, wirklich für mich relevant, macht das Sinn, dass sie mit diesem Thema zu mir auf die Website kommen oder ist das quasi einfach lebensächlich oder lenkt das vielleicht sogar ab von meiner Tätigkeit innerhalb meiner Website. Ich würde mir da nicht allzu große Gedanken machen, wie Google darüber nachdenkt, gerade bezüglich Bounce Rate und so, sondern wirklich eher überlegen, macht das Sinn für meine Website, würde ich das so beibehalten oder nicht. Manchmal ist es ja ganz interessant, wenn man so ein bisschen leicht Themenfremde Seiten auch dabei hat, weil wir noch sehr trotzdem noch zur Website kommen und vielleicht so ein bisschen, was nicht, den Markennamen oder so sich merken und dann vielleicht wegen anderen Sachen auch mal zurückkommen. Manchmal sind die Inhalte aber so Themenfremde, dass sie wirklich nicht zusammenpassen, dass die Benutzer, die über diese Seite kommen, gar nichts mit dem Rest der Website zu tun haben und dann macht es vielleicht schon eher Sinn, dass man sich überlegt, kann man die vielleicht auslagern auf irgendwo anders hin, kann ich die vielleicht eher mein Blog nehmen statt auf meine normale Website oder macht es vielleicht sogar Sinn, dass ich die einfach ganz lösche, weil die Benutzer, die auf diese Seiten gehen würden, die wirklich von gar keinem Wert sind für den Rest meiner Website. Dann, eine Frage zu Lazy Loading. Wir setzen bei unseren Websites aus gestalterischen und performancegründen Lazy Loading bei Bildern ein. Wir setzen diese im Moment in zwei Varianten um. Okay, wir schauen. Bei Document Ready werden die Platzhalterbilder reingeladen, bei Window Load wird die Source der Image Tags mittels JavaScript, die vorgesehenen Bilder setzt. Oder zweite Variante. Könnt das bei diesen Varianten so Problemen, bei der Indexierung beziehungsweise beim Rendering der Seite auftreten? Schwierig zu sagen, ohne die Seiten genau anzusehen. Also was ich mir da, gerade bei Lazy Loading immer als Erstes überlegen würde, ist es überhaupt wichtig für mich, dass diese Bilder indexiert werden in Google Images. Wenn das zum Beispiel nur gestalterische Elemente sind innerhalb einer Seite, kreative Hintergrundsbilder, solche Sachen, die eigentlich in der Bildersuche nicht dazu dienen, dass wirklich relevante Besucher zu euren Seiten kommen, dann kann man sich natürlich sagen, sie sind nicht kritisch für die Bildersuche, also muss ich jetzt die nicht speziell einbinden, so dass die Bildersuche die auch wirklich finden kann. Ich denke, dass es mal die einfachste Unterscheidung, die man da machen kann, wirklich überlegen, würde jemand auf diese Bilderstoßen in der Bildersuche, der dann wirklich auf meiner Website etwas machen würde, was für mich relevant ist. Und dabei meine ich dann nicht, dass jemand auf dieses Bild herunterläten, sondern wirklich offiziert zu eurer Website kommt, um etwas zu machen. Wenn man zum Beispiel Möbel verkauft und man hat schöne Bilder von diesem Möbel, dann kann jemand über die Bildersuche sicher Möbel finden und dann zu euch kann man diese Möbel kaufen. Das ist eigentlich ein relativ normaler Prozess. Wenn hingegen diese Bilder wirklich nur als Hintergrundsbilder dastehen, als kreative Filmmaterial innerhalb einer Seite, dann sind das vielleicht nicht unbedingt solche Sachen, nachdem jemand in der Bildersuche suchen würde, um gezielt auf eurer Website etwas zu machen. Das macht es ein bisschen einfacher, weil wenn das wirklich nur kreative Bilder sind auf diesen Seiten, die nicht wirklich dazu dienen, Besucher über die Bildersuche zu euch zu bringen, dann müsst ihr euch nicht überlegen, wie man das für Googlebot einbinden kann für Lazy Loading, weil wenn das nicht 100% geklackt wird. Wenn es hingegen doch wichtig ist für eurer Seiten, dass diese Bilder geladen werden, dann würde ich auf jeden Fall kontrollieren, dass Googlebot diese Bilder als Image tags auch sehen kann. Das heißt, man kann das relativ einfach testen, indem man mit dem Mobile Friendly Test zum Beispiel diese Seiten öffnet und dann die gerenderte HTML Version anschaut und wenn man da dann nach unten lettert zu dem Teil, wo die Bilder geladen werden, müssten das sauberer Image tags sein mit einem Source Attribut mit einem Link auf die Image-Datei. Und wenn das so vorhanden ist, dann heißt es, dass Googlebot den JavaScript ausführen konnte und die Image Source URLs gesetzt hat sauber und entsprechend können wir dann auch für die Bildersuche diese Image tags sauber verwenden. Wenn das nicht klappt, gibt es zwei Möglichkeiten, die man machen kann. Einerseits über JSON-LD Structure Data, die Bilder uns bekannt geben. Andererseits mit einem NoScript Tag ein Platzhalter zu erstellen für diese Bilder als Alternative. Damit wir auf jeden Fall die Bilder kurz empfinden können, kann man das eben über den NoScript machen. Ich würde sonst keine Inhalte mit dem NoScript machen, weil Textinhalte und solche Sachen lassen wir in der Wege weg. Aber für Bilder ist es so, dass wir das als Alternative so verwenden können. Dann, eine kurze Frage. Bezüglich gestalterische Freiheit kann Googlebot Text, P-Tags und Bildelemente die Initial Opacity auf 0 sind und nach einer Viertelsekunde auf 1 gesetzt werden die Inhalte auf 1 gesetzt werden. Sobald ich weiß, sollte das klappen. Wichtig ist einfach, dass dieser Zeitrahmen von dem ein Bild oder ein Textelement von unsichtbar auf sichtbar gesetzt wird, relativ kurz ist. Damit wir das wirklich auch im Rendering immer sauber sichtbar sehen würden. So viel ich weiß, verwendet AMP zum Beispiel auch etwas Ähnliches, dass die Inhalte erstmal unsichtbar geladen werden und dann sichtbar geschaltet werden. Damit, ich glaube von Plackern her, dass das ein bisschen minimierfährt. Aber das ist, hand für sich, eine normale Technik, die man durchaus machen kann. Wichtig ist einfach, dass man diesen Zeitrahmen minimiert. Nicht, dass man sagt, nach 10 Sekunden werden die Inhalte sichtbar gemacht. Weil dann kann es natürlich sein, dass Googlebot 5 Sekunden abgewartet hat und jetzt nichts mehr. Und dann werden die Inhalte gar nicht ersichtbar gesehen. Bei einer neuen Seite wurden viele Portfolio-Seiten nicht indexiert. Eingereicht über sucht-console. Wie kann es sein, dass es nicht indexiert ist und trotzdem gefunden wird. Ich müsste da wahrscheinlich einige Beispie-Seiten haben. Wenn du da etwas Spezielles hast, einzelne URLs, die nicht funktionieren, die nicht als indexiert markiert werden, dann kann ich das ein bisschen genauer anschauen. Aber ohne Beispiel ist das ein bisschen schwierig. Okay, also das ist ja meine Frage. Und so geht es ja darum, dass ich ein Portfolio eingelegt habe und Hauptkategorie für Portfolio ist dann NRW und dann kommen die Städte NRW, was weiß ich hier, Cologne, Bonn und Hass nicht gesehen. Und diese kleinen Städte wurden nicht indexiert, aber diese Hauptkategorie mit dem Namen NRW wurde indexiert. Und wenn ich jetzt zum Beispiel Bonn XYZ suche, dann bekomme ich immer noch diese Hauptkategorie. Also ich bin nicht sauer auf meinen Rankings, sondern dass jetzt Cologne, Bonn und die anderen Städte nicht indexiert wurden trotzdem, trotzdem auf meiner Seite kommen. Das war mir ein bisschen Profi. Deswegen die Frage. Wir indexieren natürlich nicht alle Seiten, die befinden. Ich vermute, das fällt irgendwo dahinein, dass wir da entweder im Moment noch nicht ganz sicher sind, wie wir da umgehen sollen. Gerade wenn das sehr viele neue Seiten sind, dann ist das manchmal ein bisschen wieviel wir davon indexieren. Wenn das nur einzelne Seiten sind, dann kann es auch einfach aus technischen Gründen sein, dass wir noch nicht dazu bekommen sind, das sauber zu indexieren. Je nachdem, wie lange das schon ist, wie viele Seiten das betrifft, kann das so in einer oder anderen Richtung fallen. Kannst du noch kurz über den Schema Org Entschuldigung, Schema Org oder Spezifikation auf was sagen, vielleicht? Spekros Ich weiß ich jetzt nicht auswendig. Ich weiß, wir haben da ein bisschen mehr in der Dokumentation jetzt ausgebaut. Ich glaube, das ist aber speziell für Nachrichtenseiten, wenn ich mich nicht täusche. Dass man da einfach direkt angeben kann, welche Teil der Seite quasi gesprochen verwendet, und welche Teil der Seite normal HTML-Halfe ist. Meines Wissens ist das im Moment nur für Nachrichtenseiten und wahrscheinlich im ersten Moment, wie vieles erst mal auf Englisch. Aber ich müsste da auf die Dokumentation genauer anschauen. Noch eine Frage, wenn ich dich schon habe. Beim Search Console ist es so, dass wir, wenn wir in der Seite oder an Artikel teilen über Google Plus, dann bekommen wir irgendwann mal ein Backlink. Wir wissen ja, dass Google Plus demnächst nicht mehr existiert. Was passiert mit den Backlinks? Ich weiß es nicht. Je nachdem, was mit Google Plus am Ende passiert, ich weiß nicht was, was da die genauen Pläne sind. Kann es sein, dass es ähnlich wie der erst mal in einem starbischen Zustand versetzt wird? Und dann bestehen diese Sachen natürlich erst mal weiter. Es kann auch sein, dass sie irgendwie das Ganze ganz abschalten müssen und dann bestehen die auch nicht mehr. Meines Wissens sind die Links aus Google Plus ja auch alle mit No Follow. Von dem her hast du wahrscheinlich SEO-mäßig nicht wahnsinnig viel davon, wenn du diesen Link aus Google Plus hast. Ah ja, okay, danke. Okay, da sind gerade noch ein paar neue Fragen dabei. Unsere Seite hat im Verhalten Search Console mehrere 104 noch vieler angezeigt bekommen. In der 9 sind es nur 16. Kann ich davon ausgehen, dass die neue Version auch aktuelle Zahlen hat und sich das Problem so nicht gelöst hat? Ja und nein, ist ein bisschen schwierig genau zu sagen, weil die neue Version beschränkt sich eher auf die indexierten URLs beziehungsweise auch die URLs die indexiert wären, denn gegen die alte ist ja eine Liste von den Fehlern. Und bei der Liste von den Fehlern sind natürlich viele dabei, die eigentlich nie indexiert wären und dementsprechend die nie in den neuen Search Console so erscheinen werden. Und unser Ziel mit den neuen Search Console ist ja auch eher, dass man sich auf das konzentriert, was wirklich relevant ist in so einem Fall wie jetzt hier ist es wahrscheinlich so, dass wir gedacht haben, diese 16 Fehler, die wir da gefunden haben, die wir eigentlich indexiert würden, das ist eher das, was für euch relevant ist. hingegen die lange Liste von allen anderen 404 Fehlern, die wir mal gefunden haben, das ist wahrscheinlich eher etwas, was wir einfach pro forma euch geben würden und nicht unbedingt etwas, was ihr beheben müsst oder anschauen müsst. Ich denke, da ist es mit dem neuen Search Console ein bisschen, sag mal, praktischer gedacht, auch wenn es dann aussieht, dass da weniger Informationen da ist. Wir haben eine m.domain für unser mobiles Website und stehen nun vor der Frage, ob wir unsere mobilen Seiten unterschiedlichen hreflang Attributen auch in unser Signalt darstellen sollen. Zusätzlich zu unserer WBW Domain. Wenn ihr eine separate Mobile URLs habt und mit hreflang arbeitet, dann solltet ihr auf jeden Fall auch diese mobilen Version mit hreflang versehen und jeweils die einzelnen Versionen untereinander probieren. Das heißt die deutsche mobile Version mit solchen spanischen mobile Version per hreflang verlinken und die desktop deutsche Version mit der desktop spanischen Version per hreflang verlinken und nicht etwa fair, sondern wirklich mobile zu mobile und desktop zu desktop. Gerade für den Mobile Indexing ist es für uns wichtig, dass wir da die mobile Version sauber auch so verlinkt haben. Wir haben bei den Bildern auf der Website ein Alt, so wie ein Titletag gepflegt, ist ein Titletag bei Bildern noch notwendig. Meines Wissens verwenden wir für die Bildersuche also Altattribut und nicht bei dem Titelattribut. Titel ist glaube ich auch eher beim Link Element und nicht beim Bild Element, soweit ich mich erinnere. Wichtig für die Bildersuche sind natürlich auch der Teilnamen und Unterschrift, quasi unterhalb vom Bild, der Kontext vom Bild innerhalb der Seite, Titel auf der Seite, all diese zu. Aber man muss zum Beispiel nicht das was im Altattribut steht, mit dem Titelattribut kombinieren, sondern das sind separate Elemente. Manchmal macht es ja auch Sinn, dass man ein Titelattribut trotzdem verwendet, je nachdem wie das bargestellt wird im Browser, wie das weiter verwendet werden kann für Accessibility. Okay, und da haben wir euch geschafft. Ich kann mich noch ein bisschen erinnern, dass du mal gesagt hast, dass ihr irgendwie mit WordPress irgendwas machen wolltet 2018 oder 2019. Wie weit seid ihr damit? Weiß ich jetzt nicht, wie das genau da aussieht. Ich weiß, wie es sind jetzt an verschiedenen WordPress-Events auch gewesen und ein bisschen mehr mit der WordPress-Community zusammenarbeiten, aber was da konkret daraus wäre, weiß ich mal. Danke. Hallo. Hallo. Mein Mikro ging eben nicht. Ich wollte noch mal zu dieser Jason, die bzw. ja, was kript, Kategorie-Seite Sachen zurückkommen, weil wir da wirklich schon alles versucht haben. Wir haben die eingebunden, wir haben versucht, den Browser zu steuern, wir haben da schon statische Tests gemacht und so, das ist halt irgendwie alles, hat nicht so richtig funktioniert und jetzt ist halt einfach so die Frage, was sollen wir jetzt noch machen so, also wir haben schon wirklich alles versucht, nur die Kategorie-Seiten, die ranken halt einfach nicht, also es funktioniert halt irgendwie nicht und jetzt ist halt dann quasi, es wird schon immer gesagt, wir können das, aber überlegen uns halt schon, mal auf statisches Wendring. Okay. Kannst du mir vielleicht ein paar Beispiele zuschicken? Ja. Dann kann ich das ein bisschen hier mit dem Team auch mal genauer anschauen, weil wahrscheinlich ist das nicht unbedingt etwas, wo wir sagen können, allgemein muss man das so machen, sondern wirklich gezielt bei euch halt. Ja, genau, das wäre sehr nett. Okay. Cool. Super. Dann bedanke ich mich bei euch allen, laufe in den nächsten Wochen noch auf. Falls weitere Fragen kommen, könnt ihr auch gerne ins Webmaster Forum kommen und dann sehen wir uns vielleicht eines der nächsten Mal wieder. Tschüss allerseits. Danke auch bei Facebook. Danke. Ciao.