Rendering SEO: Wie Google Ihre Inhalte verdaut

Dies ist eine Abschrift eines Gesprächs zwischen Bartosz Goralewicz, Martin Splitt von Google und Jason Barnard. Sie veranstalteten ein Webinar, um Rendering SEO in praktischer Hinsicht zu diskutieren. Sie können sich die Aufzeichnung des Webinars hier ansehen, aber da es so viele Informationen enthält, hoffen wir, dass Sie auch dieses Transkript hilfreich finden!

Bartosz: Heute werden wir uns das Rendering aus der Google-Perspektive ansehen, die sich ein wenig von dem unterscheidet, was wir in Chrome sehen, und daher ist Martin hier, um uns durch diese trüben Gewässer zu navigieren.

Und nur kurz, in unserer Recherche, und wieder, das kommt nicht von Martin, wir haben um 2011 angefangen, erste Erwähnungen von Rendering und Layout in Google-Patenten zu sehen. Und meine persönliche Theorie ist, dass das der Grund für Google Panda-Inhaltsqualitätsupdates und all diese wunderbaren Dinge ist begann ungefähr zu diesem Zeitpunkt zu geschehen.

Und es gibt viele neue Erkenntnisse, dies ist ein ziemlich neuer Bereich, wie Google sowohl das Layout als auch das Rendering betrachtet, und wir hoffen, dies hier mit Martin ein wenig freundlicher zu gestalten. Das ist also das Ziel heute – dies so einfach und benutzerfreundlich wie möglich zu machen.

Wie ich bereits erwähnt habe, konzentrieren sich die meisten Google-Patente, die wir zu diesem Thema gefunden haben, auf das Layout.

Das Layout scheint ziemlich wichtig zu sein, und wir wissen wahrscheinlich, dass Text, der über dem Falz erscheint, wichtiger ist, und es gibt viele Patente, die Ihnen sagen, dass einige Elemente der Seite eine etwas andere Rolle spielen als z , Anzeigen oder Text, der unterhalb des Seitenumbruchs angezeigt wird.

Das ist also einer, und wir haben uns jahrelang auf JavaScript-SEO konzentriert, wie Jason erwähnte, und als wir tiefer gingen, stellten wir fest, dass JavaScript-SEO hauptsächlich war: „Kann Google Ihre Inhalte richtig sehen, können Sie dieses JavaScript in HTML ändern“ und solche Dinge , aber als wir etwas tiefer tauchten, sahen wir, dass dies nur die Spitze des Eisbergs ist.

Viele der Aspekte, wie Google den Inhalt rendert und wie sie das Layout sehen, werden den größten Teil der SEO beeinflussen, die nach dieser ersten Phase des Crawlens, Renderns und Indizierens stattfindet.

Also verließen wir als Agentur den Bereich der JavaScript-SEO ein wenig und tauchten in die Rendering-SEO ein, die viel komplexer und aufregender ist. Trotzdem werden wir versuchen, es heute einfach zu halten. Jason, du musst darauf aufpassen.

Es gibt viele Dinge, die ziemlich spannend sind, wir werden wahrscheinlich keine genauen Antworten von Martin bekommen, er hasst diese Folie, es tut mir leid, Martin.

Es gibt Dinge, die Google erwähnt hat, wie sie Skripte unterbrechen, viele funky Kleinigkeiten, die interessant sind, aber nur um Ihnen für all die Leute zu sagen, die in technischer SEO nicht so weit fortgeschritten sind – warum Layout und Rendering SEO wichtig sind. Manchmal erfasst Google nicht die gesamte Seite, die Sie gepostet haben.

Wenn Sie also sehen, dass Ihre URL indexiert ist, bedeutet das nicht wirklich, dass Google das Ganze indexiert hat. Das kann an Rendering, Qualität, Technik liegen, da wird es dann richtig bunt und spannend.

Etwas, das ich erwähnen möchte, wenn wir heute sprechen, ist, dass es vier Schattierungen Ihrer Website gibt. Ohne es zu wissen, tarnen viele von uns den Inhalt, weil Ihr Inhalt jetzt auf Mobilgeräten mit JavaScript anders aussieht als ohne JavaScript, und das gilt heutzutage für die meisten Websites, also nicht nur für diese React- oder Angular-Websites, sondern auch für WordPress , Wix, vielleicht auch Duda und die meisten dieser einfacheren Frameworks. Wir haben auch das gleiche Problem mit Desktop. Es gibt also so viele verschiedene Möglichkeiten, wie Sie mit Inhalten interagieren können, und das liegt hauptsächlich am Rendering, wie dieser Code auf einem Endgerät gerendert wird.

Fangen wir ohne weiteres an. Wir haben Martin hier, also werde ich nicht zu viel Zeit in Anspruch nehmen.

Ich habe die erste Frage, nur um es irgendwie zu starten. Also Martin, kann mir das Rendern von SEO dabei helfen, einen besseren Rang zu erreichen? Ich nehme an, dass dies die erste Frage ist, die in jedem Kopf ist.

Ist es praktisch, ist es etwas, das uns Traffic, Leads, all diese lustigen und coolen Dinge bringt?

Martin: Ich meine, ich beantworte normalerweise keine Ranking-Fragen, hier mache ich eine Ausnahme.

Generell gesagt – nein. Aber speziell gesagt, wenn es ein Problem gibt, bei dem etwas Ihr Rendering unterbricht und der Inhalt nicht angezeigt wird, dann sieht der Googlebot den Inhalt nicht oder nicht richtig, dann, wissen Sie, kann Ihnen das tatsächlich im Sinne von schaden , sehen wir den Inhalt nicht.

Daher indexieren wir die Seite möglicherweise nicht. Oder wir indizieren die Seite, ordnen sie aber nicht für die Inhalte, die Ihnen wichtig sind. Also ja, am Ende kann es einen Unterschied machen und eine Wirkung haben – ja, natürlich.

Bartosz: Eine Sache, die ich tun möchte, bevor wir uns den Fragen des Publikums zuwenden, ist, wo sitzt das Rendering im ganzen Szenario?

Wir können uns schnell in ein Szenario versetzen, in dem zuerst das Huhn oder das Ei war, aber mein Verständnis davon war immer, dass Google eine Warteschlange erstellt und dann die Seite crawlt, rendert und offensichtlich optional indiziert – wäre das eine zu starke Vereinfachung?

Martin: Das ist etwas vereinfachend, aber im Grunde richtig. Wir erhalten also viele URLs und wir erhalten so viele URLs, dass wir sie aus offensichtlichen Gründen nicht alle gleichzeitig crawlen können. Ok, sollte ich nicht sagen, aus den offensichtlichen Gründen. Wir können aus Bandbreitengründen nicht immer alle URLs gleichzeitig crawlen, daher steht nur eine begrenzte Internetbandbreite zur Verfügung, die wir nutzen können.

Wenn Sie einen Onlineshop haben und morgen mit einer neuen Onlineshop-Website online gehen und eine Million Produkt-URLs haben, könnte Ihr Server abstürzen, wenn wir all diese URLs gleichzeitig crawlen, also müssen wir das über die Zeit verteilen , also gibt es eine Warteschlange zwischen der Entdeckung der URL und der URL, die tatsächlich gecrawlt wird.

Diese Warteschlange ist relativ transparent in dem Sinne, dass die Search Console Ihnen anzeigt, wann die URL zuletzt gecrawlt wurde, und sie ist auch in einer Weise transparent, die Ihr Server Ihnen mitteilt. Sie können überprüfen, wann die letzte Anfrage an diese URL von einem Googlebot-User-Agent und einer IP-Adresse erfolgt ist. Das ist also eine sehr transparente Warteschlange.

Was dann passiert, ist, sobald wir es gecrawlt haben, können wir uns den HTML-Code ansehen, den wir erhalten haben, wir können uns den HTTP-Status ansehen. Wenn es sich um einen 404-Status handelt, endet die Verarbeitung hier im Wesentlichen. Wenn es ein Robots-Meta-Tag gibt, das noindex sagt, dann endet unsere Arbeit auch hier.

Aber wenn wir eine Reihe von HTML-Inhalten erhalten und mit der Verarbeitung und dem Rest der Pipeline fortfahren können, stellen wir die Seite auch für die JavaScript-Ausführung in die Warteschlange, was wir als „Rendering“ bezeichnen würden. Die zweite Warteschlange ist sehr undurchsichtig, in gewisser Weise sieht man nicht wirklich, wie lange wir zum Rendern brauchen, wenn wir überhaupt rendern, wann wir rendern, wissen Sie nicht, und das ist nicht zufällig so, denn theoretisch sind wir es Betrachten Sie dies alles als einen Transaktionsprozess, im Eingang gibt es die URL, die wir entdeckt haben, und die Ausgabe davon ist ein indiziertes Dokument oder ein nicht indiziertes Dokument. So ziemlich das kann hier passieren.

Und es gibt nicht viel, was Sie beim Rendern wirklich tun können, um die Position der Warteschlange zu ändern oder herauszufinden, was gerendert wird oder was gerendert werden sollte. Sie sehen das auch in der Search Console, Sie sehen, was beim Rendern herauskommt, wenn Sie sich View Crawled Page ansehen , Sie sehen, was wir dort sehen würden. Es gibt also keine zusätzliche Warteschlange, die Sie übersprungen haben, und es gibt ein paar weitere Komplikationen, bei denen das vereinfachte Modell möglicherweise nicht unbedingt zutrifft. Aber Sie können davon ausgehen, dass der Fluss normalerweise entdeckt, gecrawlt, in die Warteschlange gestellt, gerendert, indexiert und dann möglicherweise später gerankt wird.

Jason: Das ist wirklich klar.

Bartosz: Ich möchte nur eine Sache klarstellen, weil Sie erwähnt haben, dass Sie, bevor dies online zu einem Thema wird, erwähnt haben, dass Sie die Seite rendern, und Sie haben auch JavaScript erwähnt, aber was ich aus unseren vorherigen Gesprächen gelernt habe, ist, dass es nicht nur um das Rendern geht JavaScript.

Martin : Oh ja, das stimmt.

Bartosz : Selbst wenn Sie also eine Nicht-Javascript-Website haben, also keine JavaScript-Zeile und keine Verweise auf externe Skripte vorhanden sind, sollten Sie sich auch um das Rendern kümmern.

Jason: Ich wollte gerade die Frage stellen: Wie viele von uns beschäftigen sich tatsächlich mit dem Rendern, weil diese Vorstellung, die Vorstellung, dass es nur JavaScript ist, uns alle betrifft …?

Martin : Ja. Alle Webseiten werden gerendert und Sie alle sind bis zu einem gewissen Grad besorgt, ja, das stimmt, das ist richtig.

Jason : Im Grunde genommen, wenn Sie kein JavaScript haben, müssen Sie sich darüber überhaupt Gedanken machen?

Martin : Da muss man sich nicht unbedingt Sorgen machen, aber man ist trotzdem davon betroffen. Es gibt immer noch mögliche Auswirkungen durch das Rendern.

Jason : Okay, brillant.

Martin : Das knüpft an das an, was Bartosz vorhin gesagt hat, wie der Text über dem Falz oder wo Google denkt, dass Ihr Hauptinhalt ist und solche Sachen.

Jason : Richtig, ja. Was genial ist. Ich meine, es heißt im Grunde, ein Teil des Renderns besteht im Grunde darin, zu verstehen, welche Rolle jeder Teil der Seite spielt. Bartosz zeigte uns einen Screenshot, bei dem einiges nicht indexiert war, einiges aus Werbung, einiges aus einer Kopfzeile und einiges aus der Fußzeile. Rendering ist der Punkt, an dem Google entscheidet, welche Rolle jeder Teil der Seite spielt, daher kann es diese Entscheidung treffen, ob es indexiert und priorisiert wird oder nicht, im Sinne von Bartosz – ist dies der Hauptinhalt?

Bartosz : Das ist alles richtig.

Jason : Aber im Grunde, wie entscheidet es?

Martin : Vielleicht müssen wir ein bisschen darüber reden, was Rendering wirklich ist? Denn ich bin mir nicht sicher, ob jeder weiß, was das bedeutet, oder? Sollen wir das tun?

Bartosz : Tut mir leid, Martin, das ist ein sehr guter Moment für alle Zuschauer, um all die Fragen zu jedem einzelnen Punkt zu stellen, den Sie gerade nicht verstanden haben.

Martin : Ja!

Bartosz : Wir haben bei Martin keine Ahnung, an welchem ​​Punkt wir das Publikum verlieren werden, aber was wir versuchen anzusprechen, um völlig transparent zu sein, das Feedback aus unserem vorherigen Gespräch war, dass wir manchmal ein bisschen zu geeky, zu nerdig wurden , also wollen wir es wirklich einfach machen.

Jason : Genial gesagt. Rendering definieren, was ist das, was ist der Prozess?

Martin : Richtig. Wenn Sie sich HTML als Rezept vorstellen und alle Zutaten haben, dann haben Sie einen Haufen Text, Bilder, Zeug. Aber du hast es nicht wirklich im Rezept, das Rezept ist ein Stück Papier mit allen Anweisungen, wie man das Ding macht.

Die Ressourcen der Website sind die Zutaten, wie CSS, JavaScript-Dateien und die Bilder, die Videos, all das Zeug, das Sie laden, damit die Seite tatsächlich so aussieht, wie sie danach aussieht.

Die Website, die Sie kennen und in Ihrem Browser verwenden, sehen Sie in Ihrem Browser – das ist das letzte Gericht.

Rendern ist so ziemlich das Kochen, der Vorbereitungsprozess.

Crawling geht im Grunde nur in ein großes Rezeptbuch und holt eine Seite mit dem Rezept heraus und bringt das dann in unsere Reichweite, im Grunde stehen wir hier auf einem Küchentisch und warten nur darauf, dass das Kochen beginnt, und Crawling wird es im Grunde tun gib uns das rezept.

Und dann ist das Rendern der Prozess, bei dem das Rendern beginnt: „AHA, interessant! Crawler, kannst du mir diese 10 Zutaten besorgen?“, und der Crawler sagt bequem: „Ja, ich habe dir diese 10 Zutaten, die du brauchst“, und wir fangen an zu kochen, das ist Rendering.

Beim Rendern wird also das HTML analysiert. HTML, wenn es um Formular-Crawling geht, ist im Grunde nur eine Menge Text, praktisch formatiert, aber Text.

Um daraus eine visuelle Darstellung zu machen, die wirklich die Website ist, müssen wir sie rendern, was bedeutet, dass wir alle Ressourcen abrufen müssen, wir müssen grundlegend verstehen, was uns der Text sagt.

Z.B. Oh, hier ist also eine Überschrift, ok, dann ist dort ein Bild, neben dem Bild ist eine Menge Text und dann unter dem Bild ist eine weitere Überschrift, eine kleinere Überschrift, eine untergeordnete Überschrift, im Grunde eingerückt die Struktur des Inhalts, dann gibt es ein Video, dann gibt es unter dem Video mehr Text und im Text gibt es 3 Links, die hier, hier, hier gehen.

Und dieser ganze Montageprozess, dieses Verstehen, was es ist, und das Zusammenfügen zu einer visuellen Darstellung, mit der Sie in Ihrem Browserfenster interagieren können – das ist Rendering.

Und als Teil des Renderings führen wir in der allerersten Phase das JavaScript aus.

Da JavaScript im Grunde genommen ein Rezept innerhalb des Rezepts ist, kann JavaScript so lauten: „Jetzt hacke die Zwiebeln“. Sie haben also die rohen Zutaten, die Zwiebeln, aber Sie geben die Zwiebeln nicht als Ganzes in Ihr Gericht, Sie schneiden sie, und dafür wird das JavaScript benötigt.

Wenn ich also das JS nicht ausführe und nur die Ressourcen hole, komme ich möglicherweise nicht zu dem Schritt, in dem ich tatsächlich die Zwiebeln hacken oder ein Ei aufschlagen und es in etwas verquirlen muss, wer weiß.

Kannst du sagen, dass ich gerade zu Abend gegessen habe und jetzt wirklich hungrig bin? Es tut mir sehr leid!

Und die JavaScript-Ausführung ist nur ein Teil des Renderns, aber wenn die JavaScript-Ausführung beendet ist, oder wenn es keine JavaScript-Ausführung gibt, ist das auch in Ordnung, aber was dann passiert, das wir zusammenbauen, diese Kleinigkeiten herausfinden und wie wir es tun müssen, wie, baue sie auf der Seite zusammen und das führt zu etwas, das Layoutbaum genannt wird, und der Layoutbaum sagt uns, wie groß die Dinge sind, wo sie sich auf der Seite befinden, ob sie sichtbar oder nicht sichtbar sind, ob eine Sache hinter einer anderen Sache steht .

Diese Informationen sind für uns genauso wichtig wie die Ausführung des JavaScripts, da das JavaScript Inhalte ändern, löschen oder hinzufügen kann, die nicht im ursprünglichen HTML enthalten sind, wie es vom Server geliefert wurde.

Das ist also das Rendern in Kürze. Von „Wir haben etwas HTML“ bis „Wir haben möglicherweise eine Menge Pixel auf dem Bildschirm“. Das ist Rendern.

Bartosz : Ich möchte ein paar Dinge hinzufügen, die Martin nicht sagen wird, weil er bei Google arbeitet. Aus technischer SEO-Sicht betrachtet, ist Rendering ziemlich kostspielig – wie sich das genau auf Google auswirkt, ist ein großes Rätsel, und das ist etwas, wo wir weiter forschen, wir haben sogar ein separates Unternehmen gegründet, ein Tool, um das zu tun. Um es kurz zu machen, Rendering ist für Google, für mobile Geräte, ziemlich teuer. Wenn Sie wie ein Alcatel 1X, wie ein älteres Telefon, vielleicht ein billigeres Telefon haben, wird es mit Websites wie BBC, The Guardian, die viel JavaScript liefern, zu kämpfen haben. Das ist auch etwas, womit Google zu kämpfen haben wird. Aber lange Rede kurzer Sinn, Rendering ist teuer. Und unserer Erfahrung nach werden einige Skripte und einige Websites für Google nicht optimal gerendert und aus verschiedenen Gründen nicht richtig erfasst.

Und hier kommt Rendering SEO ins Spiel. Hier sprechen Sie mit Ihrem Entwicklerteam oder Tech-SEO-Team, das Erfahrung mit diesem Thema hat. Und Sie sagen ihnen, vielleicht werden meine Seiten nicht so schnell abgeholt, wie ich es gerne hätte.

Was wir ziemlich oft als Zeichen für Probleme sowohl beim Rendern als auch beim Indexieren sehen würden, ist zum Beispiel, dass Sie eine sehr dynamische Website haben, Sie haben eine Menge Javascript und Sie sehen, dass Ihre Inhalte sehr langsam erfasst werden. Sie veröffentlichen beispielsweise einen neuen Eintrag auf einer Immobilien-Website und sehen, dass Google ihn nach 3 Wochen abholt und Ihre Konkurrenten nach einem Tag abgeholt werden. Und das ist ein Szenario, in dem wir uns hinsetzen und untersuchen würden, was hier passiert, warum kämpft Google mit diesem Aspekt?

Was halten Sie von diesem Martin?

Martin: Ich mag die Frage, weil sie hier einen interessanten Moment schafft .

Denn wenn Sie darüber nachdenken, hat die Google-Suche in diesem Fall genau die gleichen Probleme wie ein echter Benutzer. Denn für einen realen Benutzer, selbst wenn Sie ein modernes Telefon verwenden, und auch ein wirklich schnelles und fantastisches und teures Telefon, bedeutet mehr Ausführung immer auch mehr Stromverbrauch.

Es gab Leute, die JavaScript das CO2 des Internets nannten. Ich finde das nicht ganz falsch. Das ist ein sehr schöner und passender Vergleich.

Hier ist die Google-Suche und hier sind die Benutzer, die Ihre Website tatsächlich verwenden, und wir sitzen im selben Boot. Je teurer Sie es machen, desto schlechter ist es für uns als Erfahrung. Die Google-Suche kümmert sich nicht wirklich darum, wir müssen nur in Ressourcen investieren, die wir brauchen, und wir nehmen viele Optimierungen vor, um sicherzustellen, dass wir so wenig Zeit und Energie wie möglich verschwenden. Aber natürlich, wenn Sie das optimieren, ist ein netter Nebeneffekt, dass Ihre Benutzer wahrscheinlich auch glücklicher sein werden, weil sie weniger Akku benötigen, ihr altes Telefon immer noch gut mit dem funktioniert, was Sie dort veröffentlichen, und sie werden in der Lage sein, zu konsumieren Ihre Webinhalte und vielleicht nicht die Ihrer Konkurrenten, weil Ihre Konkurrenten sich einfach nicht darum kümmern und tatsächlich etwas produzieren, das auf ihren Telefonen weniger bequem zu verwenden ist. Das ist also nicht etwas, bei dem Sie Google gegen UX ausspielen, das ist so etwas wie das gleiche Problem oder die gleiche Herausforderung, und wir alle stehen vor ihr, einschließlich der Google-Suche, also ist das eine nette Sache.

Jason : Aus meiner Sicht sagst du: Optimiere, mache es Google einfacher – was ist die Belohnung, die Google uns gibt? Ist es für Sie einfach schneller und Sie können gleichzeitig mehr tun?

Martin : Nicht wirklich, denn das Rendern findet außerhalb statt, das Rendern ist asynchron, das bedeutet, dass wir nicht warten, bis das Rendern stattfindet, und dann verarbeiten, sondern im Grunde versuchen, so viel wie möglich parallel zu machen. Wenn zum Beispiel strukturierte Daten im ursprünglichen HTML vorhanden sind, können wir sie direkt nach dem Crawlen abholen, während das Rendern stattfindet, sodass Sie dort geringfügige Vorteile erhalten. Sie könnten dort tatsächlich größere Vorteile erzielen.

Wenn Sie etwas haben, bei dem sich der Inhalt ständig ändert, dann stellen Sie das so früh wie möglich im Prozess zur Verfügung, und das Gleiche gilt für Canonicals, Titel, Meta-Beschreibungen, strukturierte Daten – so früh wie möglich, ist gut für Sie, wenn es um die Kommissionierung geht es häufiger oder schneller.

Jason : Ja, je früher es ist, desto wahrscheinlicher ist es, dass Sie es abholen, desto unwahrscheinlicher ist es, dass Sie vorbeikommen, bevor Sie dort ankommen.

Und Sie haben Schema-Markup erwähnt und Sie haben über den Layout-Baum gesprochen, und ich bin unglaublich fasziniert, weil Sie diesen Layout-Baum erhalten, Schema-Markup ist möglicherweise Teil dieses Layout-Baums, und Sie sagen im Grunde, das ist Schema, das ist das Anzeigen, das ist der Header, ist das richtig? Ist Schema ein Teil davon?

Martin : Schema ist kein Teil Ihres Layoutbaums, weil es kein visuelles Element ist. Alles, was visuell oder potenziell sichtbar ist, ist also Teil des Layoutbaums. Schema-Markup wäre nie sichtbar.

Es sind ein paar Bäume beteiligt und ich möchte nicht alle verwirren. Im Grunde passiert Folgendes: Sobald wir den Text haben, zerlegen wir ihn in einzelne Elemente und erstellen ein Dokumentobjektmodell – das ist das DOM, auf das sich die Leute beziehen. Das DOM ist im Grunde nur die Art des Browsers zu sagen: Ich habe also diesen Titel, der Text enthält, das ist ein weiterer Knoten in diesem Baum, und dann habe ich diesen Textblock hier, und innerhalb des Textblocks ist ein Link, der Text enthält Der Link, dann hier drüben ist ein Bild, und Sie wissen, das ist alles, was auf der Seite ist, und das schließt Schema-Markup sowie alle Meta-Tags und den Titel und alles ein.

Alles, was unsichtbar ist, wie Metainformationen, Schemata, JavaScript und CSS, ist nicht Teil des Layoutbaums. Das CSS wird indirekt durch seine Effekte ebenfalls in den Baum geparst. Zu guter Letzt gibt es auch ein CSSOM und das ist genau dasselbe wie für HTML, aber für CSS. Und es wird dem DOM zugeordnet, um das Erscheinungsbild zu erstellen, das Sie in CSS für die DOM-Elemente und für HTML-Elemente gestaltet haben. Aber an sich würde es nicht im Layoutbaum auftauchen.

Jason : Bartosz, du hast Elemente gezeigt, die nicht indiziert sind. Und das ist vermutlich der Layout-Baum, du triffst eine Entscheidung, bevor du zur Indizierungsphase kommst: „Wir wollen es nicht, es ist nicht interessant oder zu lang oder zu leicht.“ Verstehst du das Bartosz so?

Bartosz : Es gibt eine Reihe von Gründen, warum ein Teil des Inhalts möglicherweise nicht indexiert wird. Es ist nicht immer die Schuld des Renderns, es ist eine wichtige Sache, die man im Hinterkopf behalten sollte.

Manchmal ist das teilweise Rendern schuld. Wenn Sie sich Inhalte ansehen, die auf dem Desktop, aber nicht auf Mobilgeräten sichtbar sind, liegt das am Rendering, aber das Problem ist nicht, dass Google das falsch gerendert hat, das Problem ist, dass Sie nicht denselben Inhalt für Desktop und anzeigen für Mobilgeräte, was häufig vorkommt, beispielsweise für E-Commerce-Shops.

Es kann also eine Reihe von Gründen geben, manchmal nehmen wir an, und das müsste Martin entweder bestätigen oder dementieren, dass Google ein Element der Seite überspringt, das irgendwie nicht wirklich wichtig oder relevant für den Inhalt ist. Wenn Sie also Inhalte haben, ich denke, darüber haben wir beim letzten Mal gesprochen, Martin, über Hunde, und unten haben Sie eine Reihe von Fahrradanzeigen als „Ähnliche Artikel“, dann werden diese ziemlich oft von Google nicht erfasst. Und warum das passiert, liegt wahrscheinlich daran, dass Martin ein bisschen mehr Ahnung davon hat.

Martin : Das ist kein Rendern, das ist nur, dass wir den Inhalt analysieren. Ich weiß nicht, was wir öffentlich darüber gesagt haben, aber ich glaube, ich habe es in einer der Podcast-Episoden angesprochen – wir haben zum Beispiel eine Sache namens Centerpiece Annotation, und es gibt ein paar andere Anmerkungen, die wir dort haben, wo wir suchen am semantischen Kontext sowie möglicherweise am Layoutbaum.

Aber im Grunde können wir das schon aus der Inhaltsstruktur in HTML ablesen und herausfinden. „Nach all der Verarbeitung natürlicher Sprache, die wir an diesem gesamten Textinhalt, den wir hier bekommen haben, durchgeführt haben, sieht es so aus, als ob es hauptsächlich um Thema A geht – Hundefutter – und dann gibt es hier noch diese andere Sache, die Links zu verwandten zu sein scheint Produkte, aber es ist nicht wirklich Teil des Kernstücks, es ist hier nicht wirklich der Hauptinhalt, es scheint zusätzliches Zeug zu sein, dann gibt es eine Menge Boilerplates“, also haben wir herausgefunden, dass das Menü auf all diesen Seiten ziemlich gleich aussieht, und das sieht aus wie das Menü, das wir auf allen anderen Seiten dieser Domain haben, oder wir haben das schon einmal gesehen.

Wir gehen nicht einmal wirklich nach Domain oder „Oh, das sieht aus wie ein Menü“. Wir finden heraus, was wie ein Boilerplate aussieht, und das wird auch anders gewichtet.

Wenn Sie also Inhalte auf einer Seite haben, die nicht mit dem Hauptthema des restlichen Inhalts zu tun haben , schenken wir ihnen möglicherweise nicht so viel Beachtung, wie Sie denken. Wir verwenden diese Informationen immer noch für die Linkerkennung und die Struktur Ihrer Website und all das, aber wenn Ihre Seite 10000 Wörter über Hundefutter und 2000-3000 Wörter über Fahrräder enthält, dann ist dies wahrscheinlich kein guter Inhalt für Fahrräder.

Jason: Hilft Ihnen Semantic HTML5 in irgendeiner Weise?

Martin : Es hilft uns, aber es ist nicht das Einzige, wonach wir suchen, ja.

Jason : Richtig, okay. Es ist eine kleine Hilfe, aber es ist keine große Sache, für die wir unsere gesamte Website neu aufbauen sollten, weil Sie es erraten können.

Martin : Ja.

Bartosz : Also nur um dieses Thema zu schließen und weiterzumachen, manchmal werden Sie auch einen Teil dieses Inhalts sehen, wie verwandte Elemente – dies hängt ziemlich oft von JavaScript ab. Sehr oft auf viel JavaScript.

Sie wissen also, unserer Erfahrung nach, manchmal, wenn ein Element sehr schwer ist und nicht wirklich zum Wert der Seite beiträgt, wie wieder ein Karussell ähnlicher Artikel, manchmal technologiegetrieben ist, manchmal nehmen wir an, dass dies der Fall ist weil es eine Menge Rendering zu tun hat und am Ende keinen Wert hat.

Tun Sie das auch, wägen Sie das manchmal ab, haben Sie, das wird eine sehr schwer zu beantwortende Frage sein, haben Sie einen Algorithmus, der sagen wird, ok, das kostet eine Menge zu rendern, aber das bringt es nicht viel Wert, wir sollten es überspringen. Ist es etwas, worüber Sie sprechen können? Ich bin mir nicht sicher, ob dies eine Frage ist, die wir vermeiden sollten?

Martin : Das ist keine Frage, die wir vermeiden sollten, es ist eine interessante Frage.

Soweit ich das beurteilen kann, nein. Wir sind nicht so: „Oh, das ist schwer zu rendern, wir überspringen es, weil es nicht viel Wert hinzufügt“, das wäre eine interessante Heuristik, aber ich glaube nicht, dass wir das im Moment tun. Was wir jedoch tun, ist das schließlich, und ich sage schließlich, sehr spezifisch, und ich bin hier absichtlich vage, weil es keinen sehr klaren Grenzmoment gibt, und wenn es einen gibt, meine ich, gibt es einen, aber es ist ein Thema zu ändern, und ich möchte nicht, dass sich die Leute auf etwas konzentrieren, das keinen Sinn ergibt.

Es gibt einen Moment, in dem wir sagen: „Ok, das hat lange genug gerendert, ich denke, wir sind gut.“ Es gibt wieder eine Reihe von Heuristiken, aber im Grunde genommen würden wir es auch als zu lang betrachten, wenn ein echter Benutzer denken würde, „das ist zu lang“.

Also ja.

Bartosz : Also ich denke, für das Publikum, eine Sache, die ziemlich betont werden sollte, das ist etwas, worüber wir vor dem Webinar gesprochen haben, Sie haben ziemlich oft Ressourcen erwähnt. Um welche Ressourcen sollten wir uns Sorgen machen, um das Leben von Google einfacher zu machen?

Martin : Um ehrlich zu sein, würde ich mir hauptsächlich Gedanken über JavaScript-Dateien machen.

Bartosz : Nein, Ressourcen wie Serverressourcen. Letztes Mal hast du es ganz gut erklärt und ich denke, das würde dem Publikum einen Mehrwert bringen.

Martin: Was habe ich damals gesagt?

Bartosz: Du hast erwähnt, dass du dich nicht so sehr um RAM kümmerst, dass du dir zum Beispiel Sorgen um die CPU machst. Ich erinnere mich nicht, was Sie über die Lagerung gesagt haben, aber das war auch irgendwo in dem Gespräch. Aber meiner Meinung nach ist die CPU ein Schlüsselelement, auf das Sie im Moment achten sollten. Wenn Ihre Website also viel CPU-Zeit zum Rendern benötigt, sollten Sie sich dies ansehen und optimieren. Wäre das richtig?

Martin : Ja, jetzt weiß ich, wohin wir mit der Frage gehen, vielen Dank, dass du mir da draußen geholfen hast, Bartosz.

Ja, wie ich ursprünglich sagte, im Browser und in der Google-Suche wird der Text beim Rendern grob in Pixel auf dem Bildschirm umgewandelt.

Der letzte Teil gilt nicht für die Google-Suche. Google Web Rendering Service, der Teil der Google-Suche, der tatsächlich rendert, kümmert sich nicht um Pixel, also malen wir nicht die eigentlichen Pixel. Wenn Sie also etwas sehen, das sehr teuer ist, erkläre ich Ihnen das gerne Das führt zu Verwirrung, wenn Sie etwas haben, das sehr teuer ist, brauchen Sie sich darüber keine Sorgen zu machen, da wir keine tatsächlichen GPUs verwenden, um tatsächlich Pixel zu malen, also kümmern wir uns nicht um alles, was mit Farbe zu tun hat.

Teure Layouts sind knifflig, und mit Layouts meine ich speziell die Layoutarbeit, die im Hauptthread passiert – denn das kostet CPU-Zeit und CPU-Zeit ist das Kostbarste für uns. Speicherplatz und Arbeitsspeicher, nicht so kritisch, soweit ich das von den heutigen Websites beurteilen kann, sind sie meistens teuer, weil sie CPU-Ressourcen in Anspruch nehmen.

Jason : Und auch hier eine Frage, um voranzukommen: Je öfter Sie eine bestimmte Art von Website sehen, wird es einfacher, sie zu rendern? Oder hat die Verwendung einer Plattform wie Duda oder WordPress keine Konsequenzen? Hilft das oder ist es komplett über den Tellerrand hinaus?

Martin : Es könnte helfen oder auch nicht. Der Grund dafür ist, dass das Schöne an Plattformen theoretisch darin besteht, dass Sie diese Optimierung kostenlos erhalten, wenn sie die eigentliche Plattform optimieren. Sie müssen eigentlich nichts dagegen tun, das ist also schön. Wenn Sie Ihr eigenes Ding bauen, müssen Sie die Optimierungsarbeit leisten, und niemals fällt Ihnen eine Optimierung magisch in den Schoß und die Dinge werden besser. Aber das gilt für so ziemlich jedes vorgefertigte oder Open-Source- oder gemeinsam genutzte, öffentlich genutzte CMS oder Plattform. Auf der anderen Seite tragen Plattformen, weil sie so breit und allgemein gehalten sind, oft viel Ballast mit sich herum, nur weil einige Websites möglicherweise eine bestimmte Funktionalität verwenden, und wenn Ihre Website dies nicht tut, dann trägt sie tatsächlich dieses Gewicht immer noch, und das ist vielleicht nicht so toll.

Jason : Ist es für mich als Webmaster oder Entwickler wichtig, das tote Gewicht zu entfernen, auch wenn es nicht nur darum geht, es loszuwerden, damit es nicht im Weg steht?

Martin : Entschuldigung, kannst du das noch einmal an mir vorbeiführen?

Jason : Du hast über das tote Gewicht gesprochen, wenn ich es entfernen kann, ist das ein phänomenaler Gewinn für mich?

Martin: Ja, aber die Sache mit Plattformen ist, dass man normalerweise nicht …

Bartosz : Also, ich denke, wir können auch einen kleinen Schritt zurück zum Crawler-Budget machen, das erwähnt wurde. Eine Sache beim Rendering ist also, dass wir manchmal, sagen wir, so etwas nicht betrachten, wenn wir uns das Crawler-Budget ansehen, und wir als SEOs, dass es nicht nur um die Haupt-HTML-Datei geht, sondern ob Sie ein JavaScript haben Datei, die erweitert wird, die verarbeitet wird und etwa 10 weitere Dateien anfordern wird, das sind alles, wie ich es verstehe, diese gehen auch in das Crawler-Budget.

So wie ich das sehe, ist es sehr sinnvoll, die Anzahl der Anfragen zu reduzieren. Natürlich ist dies etwas komplexer, als nur die Anzahl der Anfragen zu reduzieren und eine riesige Datei zu erstellen, aber es ist sehr wertvoll, sowohl den Code, die Anzahl der Anfragen als auch das Gewicht zu vereinfachen – im Grunde die Kosten für das Rendern.

Wie Sie bereits erwähnt haben, Martin, sind einige der Websites echte Fresser. Sie brauchen also eine Menge Ressourcen, um diese durchzugehen. Und bei diesen Ressourcen geht es nicht nur um das Rendern, wie ich sehe. Es sind auch Hunderte von Anfragen, eine Datei ändert die andere Datei. Auch dies muss schwer maßstabsgetreu wiederzugeben sein.

Martin : Das Gute daran ist, dass der Web-Rendering-Dienst die Crawling-Infrastruktur verwendet, um Ressourcen abzurufen, was bedeutet, dass er eine Infrastruktur verwendet, die speziell zum Crawlen des Webs in großem Maßstab entwickelt wurde.

Der Netzwerkteil ist also nicht der schlechteste. Was knifflig ist, ist das in Ordnung, also, ok …

Hier kommt ein weiteres Problem oder eine weitere Herausforderung hinzu, nämlich die Herausforderung des Timings und der Größenordnungen.

Wenn Sie ein Computerprogramm schreiben, neigen Programme dazu, eines von zwei Dingen zu tun: Sie sind entweder CPU-gebunden oder sie sind IO-gebunden. Was bedeutet das?

Wenn ich ein Programm habe, das nur Zahlen verarbeitet, gebe ich zwei Zahlen ein und es tut etwas. Nehmen wir an, wir versuchen, Pi so genau wie möglich zu berechnen, also wollen wir zur Billionstel-Stelle von Pi gelangen.

Das ist eine Operation, die nur Rechenarbeit in der CPU erfordert. Die CPU ist für das Rechnen mit Zahlen gebaut, also wird sie das wirklich schnell machen, aber unser Programm wird das sein, was man CPU-gebunden nennt.

Das bedeutet, wie schnell das Programm läuft und wie lange das Programm braucht, um seine Aufgabe zu erfüllen, hängt davon ab, wie viel CPU-Ressourcen Sie darauf werfen können, was im Allgemeinen vorhersehbarer ist als etwas, das IO-gebunden ist.

Was bedeutet IO-gebunden?

IO-gebunden bedeutet, wenn ich sage „Schreib mir ein Programm, das alle Dateien auf meiner Festplatte oder auf dieser CD-ROM oder diesem USB-Laufwerk auflistet.“

Dieses Programm muss nicht mehr einfach durch die CPU laufen und wird im Grunde nur Zahlen zur CPU umdrehen. Aber jetzt ist es tatsächlich so, mein Programm fragt ein externes Stück Hardware ab, mit extern meine ich außerhalb der CPU.

Die CPU muss die Festplatte, das CD-ROM-Laufwerk, den USB-Stick, egal, fragen, um die Daten zu erhalten, und die Daten müssen an einem Ort abgelegt werden, an dem die CPU darauf zugreifen kann, dann liest die CPU sie und macht eine Entscheidung auf der Grundlage der gefundenen Daten.

Im Grunde liest es das erste Verzeichnis und findet die erste Datei im Verzeichnis, liest es, die Datei kommt zurück, jetzt muss es die zweite Datei lesen … Und das ist, was IO – Input-Output – gebunden ist.

The choking factor, the thing that determines how fast something can be done here is no longer the CPU, it's the input-output, how long does this take.

The fastest is… if you talk to what is called a CPU cache, that memory that's usually inside what we would call the CPU, the central processing unit, the second fastest is if you read from local memory, from RAM. The next fastest would be a local SSD drive. And so on and so forth.

Network, unfortunately, is thousands and thousands of times slower than any of these local file accesses and these are a thousand times slower than memory access, and that's thousands of times slower than the access of the cache in the CPU.

And be careful, when I say cache, I mean a very specific tiny type of memory chip.

There is another cache, which we are using because we are IO-bound, as you can imagine, we have to fetch the resources. So it's not about the CPU or executing the JavaScript.

What takes a lot of time is going to the network and fetching the JavaScript from your server and getting that back, that is always going to be thousands of times slower than having it stored somewhere on a, let's say, hard drive, on an SSD drive somewhere in our data center.

So, we have a completely different cache, not the cache I mentioned earlier, that's a CPU internal bit and piece and we don't care about that.

We have a cache where basically whenever our crawler infrastructure fetches a resource, we store it on a drive inside our data center. So we are reducing these thousands of thousands of seconds down to a few seconds. And the problem is that if you split up your application across lots of files, let's say, a dozen files, a dozen of JavaScript files specifically, then we have to fetch all of these, now we only have to fetch these once probably and we can cache them.

But what if these files constantly change? Then we can't cache them. What's worse is, you may think “Oh, that's just one big file and all of it is in one file and that's better to cache!” No!

Because if you split it up the right amount, let's say instead of dozens of files, you now have 4 files, and from these 4 files only 2 change on a daily basis or on a weekly basis, then we can use the cache for at least the other files that never change. Good job.

But if you have all of this in one big file and it will constantly change and we can never make use of our cache. So we always have to go through the much slower network – that's a consideration that's very tricky to navigate.

And I can't give you hard and fast rules or numbers for it either.

It's a case-by-case basis, you wanna figure out how much of the stuff really has to change a lot, what other stuff is kind of stable and doesn't change as much, you wanna separate these two things.

Jason : Does that also mean that the network, the slowness of the network if you're pulling in files from different sites? That also?

Martin : Yes.

Jason : Which brings us to the question from Simox Cox, which is aimed at you, Martin: what can we do to help render Google's own scripts, analytics, and fonts?

Martin : You don't have to worry about analytics, because as far as I'm aware we are skipping analytics, with fonts, I think we are skipping them as well.

Jason: So we don't have to worry about them from the rendering perspective.

Martin: No, not from the rendering perspective, let's stick with that.

Bartosz : Just to add to that, one thing, at least to my knowledge, that you don't have to worry about with that is image fetches. That's why it's worth having image dimensions in the code because WRS – Web Rendering Service – also doesn't request images.

If you think about that, if you have a lean website of just HTML, CSS, like a lean JavaScript file, this does the trick. In our experience, this can improve rendering, indexing, crawling quite a bit just by cleaning up, a little bit of code-housekeeping, let's call it that.

Jason : You said about images though, it's very interesting because from a rendering, and getting the layout tree perspective, setting the size of the image or specifying is phenomenally important, and most lazy developers like myself don't bother doing it.

Bartosz : So, if you do that, according to my knowledge, Google doesn't have to request those files. So that's quite cool because you also cut the time of those requests, and you make Google's job a bit easier. Let's go to other questions.

Jason : Johann had a question: Is the rendering stage mandatory for a page to get indexed or could it be considered for indexing without the rendering stage?

Martin : It could hypothetically happen, but in practice it normally doesn't.

Jason: So all pages need rendering, with 1 or 2 exceptions, but none of us are likely to be concerned by that specific exception.

Bartosz: So I'm assuming this comes from those two waves of indexing. So Martin, what's the status on that right now? It's complicated as far as I can remember.

Martin : So I joined Google in April 2018, I remember that. Once I did my onboarding, Google onboarding, all of that lovely, cuddly nice time that you get when you get onboarded at Google, once that was over I sat down at my desk, and then I talked to John, Maria, Tom, and eventually, they were like, “We're prepping for Google I/O” and I saw the slide deck and I looked at two waves of indexing and I said to John, “Are you sure we wanna go with that?”, and he's like, “Yes, I think that makes it clearer, what happens”, and I'm like, “Yes, okay, I can see that it's a nice and easy explanation.”

And at least I, I know that John wasn't surprised, but I was surprised by the conclusions people drew from that.

And I was like oh God, okay, lesson learned here, that was an oversimplification. It was making what happens behind the scenes to simple and it implied a bunch of stuff that were not meant to be implied, for instance there's like “Yeah, things get indexed without the rendering happening, and then the rendering happens afterwards and changes the indexing.”

Jason: But that isn't the case?

Martin: It can be in certain cases, but it's very rare. It's also my fault because I looked at it and I said, okay, that's good.

Bartosz: To be fair, we saw, and everyone in the community dealing with JavaScript saw, quite often JavaScript would change metadata. Why you'd do that is beyond me.

Anyhow, sometimes you have one title, or one meta description with JavaScript disabled, without rendering, and you have a different one when Google renders.

And we saw websites when different pages were indexed differently. And that's why many people in the SEO community were like, okay, this page is waiting for the second wave of indexing.

Anyhow, Jason, let's go with another question.

Jason: No, right, the question you were asking there, people rewriting titles, for example, people do it with Google Tag Manager because they can't get their hands on their titles because they can't get the access to it.

That is a phenomenal problem for you guys. I mean, what you're saying is, from what I understand, sometimes you pick up the original one, sometimes you pick up the one inserted by Google Tag Manager.

Martin: Yeah, yeah.

Bartosz: And this goes beyond just meta title and description. You will see JavaScript rewriting the links, rewriting the whole structure, breadcrumbs, and with this happening, this must be really difficult to index that page and crawl that page quickly and efficiently.

Jason: So maybe we can change that to the question about, when a page changes overtime with the JavaScript even as it's loading which is the case with the meta title I just gave, how much of a problem is that for Google, so we're turning that into a more general question?

Martin: Sorry, can you run that past me again?

Jason: The fact that as the page, the page loads and things change before the users even interact with it, because you coded the things in to override because you're not very good at your job. How much of a problem does that cause?

Martin: Unless you have proof that it really is a problem for you, I wouldn't worry about it.

Normally it shouldn't be that much of a problem because normally, the clearly better content and information should definitely be there after rendering and might or might not be there previous to rendering.

What is tricky is when that's not the case, one, and the other thing is coming back to what I said earlier, the earlier you can get us data, the better, and I'll append to that.

Because when you think about it, if we were having a conversation, and I tell you oh, by the way, the restaurant to the left is terrible and the restaurant on the right is really, really good, but then 10 seconds later I'm like, no, actually, the restaurant on the left is amazing, the restaurant on the right I wouldn't bother with.

What do you do with that? That's kind of the same, if I have a title and a canonical at the beginning of the process and then that changes, then which one is the right one? How do we find out?

Bartosz: One thing to remember is, if you're leaving that decision to crawlers, and I'm not only talking about Google, because that also goes to Twitter, Facebook, Bing, all the other creatures of the web, if you leave that decision to Google, you create like a layer of chaos in your structure.

Because you don't know which pages are gonna be picked up which way, and even if just some of them won't be picked up properly, which again, sorry Martin, probably I'm not helping, but we're seeing a lot of cases where the signals from your end, so you have one version with HTML, one version with JavaScript – oversimplifying – then we're seeing different artifacts when this website is being crawled and rendered and indexed.

And I think this is proper development, this is something we need to, that's why we try to talk about these topics with Martin quite a bit, because this is something in the gray area between SEOs and devs.

Because, you know, it's a very difficult topic right now, is this something that technical SEOs should focus on? Not all companies have the luxury of technical SEOs in-house. Or is it something that the dev team should worry about? I guess the main topic is to look into that.

We have a tool – What Would JavaScript Do? – and if you google the tool, you can see, okay, which elements of the page are being changed with JavaScript. So this is very simple, just do that, look into those elements, just match those two and you're good. Even if you have to depend on JavaScript.

Martin: To be the devil's advocate for the developers, if all you have is client-side rendering and there are situations where you might for some reason have to do that, then it's not super easy to provide something server-side first, like in the initial HTML, and then updating something that is missing or that's very generic into something more specific and more high-quality, with JavaScript, is still a good thing over not doing it at all.

I'm not saying it's good, I'm not saying it's optimal and I absolutely 100% agree with Bartosz that you should make it match, but if you really can't, it is a way of doing things, it's just more shaky and error-prone than if you can avoid that.

Jason : One question many people are asking is, do authoritative sites get more “rendering” resources from Google or it doesn't matter?

Martin: No. You have to have this one meta tag, meta cheese=”” and then your favorite cheese, if it's the right kind of cheese and it changes weekly, then you get more rendering resources from John personally.

Bartosz: To support Martin's statement, being 100% serious right now, we're seeing websites, like home pages of newspapers, of huge eCommerce stores where you'd see main content not being picked up and we're seeing small websites indexed properly with similar technological stack, so I have to confirm, we're also not seeing like huge websites or heavily linked websites having some kind of benefit.

(…)

Bartosz : In general, something that we talked about with Martin. Rendering is so crucial with all the websites pushing so much JavaScript right now. And I guess, Martin, what would be…

Is there any way we can make rendering more interesting, more sexy in a way as SEO community?

I think this is something we talked about it so many times. We both know that rendering is so important and for the first time Google is not that black box anymore, we have so much data, Martin is available with all the answers, just… Not too many people seem to care about it.

We launched the Rendering SEO manifesto like June last year, I was thinking this would change the industry, I was thinking, this was gonna be this explosion within the industry, but this is not being picked up. And Martin, is there anything we as SEOs can do to push the envelope on this one?

Martin : That's again a tricky one because technically, I spoke to the rendering team about this, and they're like, “We like that rendering is not sexy”, and I'm like “Yeah, but there are people very worried about it and there is a bunch of stuff where you can miss out.”

I would just love people to experiment more. There are a few people in the community that are experimenting a lot, Giacomo Zecchini being one of them, I know that Dave Smart is experimenting a lot. And it's just really, really cool to see people experimenting and telling me what they're observing and checking in why what they're observing is what they're observing.

Ich gebe Ihnen ein sehr einfaches Beispiel. Adam Gent war der erste, der sehr öffentlich darauf hinwies, dass sie vom Googlebot unterstützte Funktionen beim JavaScript-Rendering sehen, die vorher nicht unterstützt wurden, also war er derjenige, der uns öffentlich bei der Einführung des immergrünen Googlebot erwischt hat, und das hat mich dazu gebracht sehr glücklich. Weil ein paar Leute gerade gefragt haben, wann es kommt, und ich kann es nicht wirklich sagen, weil wir offensichtlich nichts im Voraus ankündigen können, weil sich die Ankündigung zeitlich verschieben könnte oder es ein Problem damit geben könnte. Aber wenn jemand sagt: „Hey Martin, wir sehen dieses Ding. Was geht hier vor?“, dann kann ich sagen, sehen Sie, das ist, was gerade passiert, wir erhöhen den Prozentsatz der Renderings, die den immergrünen Googlebot verwenden. Und diese Seite, die Sie gerade dort hatten, war eine, die tatsächlich den neuen Evergreen Googlebot gesehen hat.

Ich glaube, es war Giacomo Zecchini, der mich auf ein seltsames Verhalten von Webworkern aufmerksam gemacht hat, was wirklich interessant ist, weil ich lange mit dem Rendering-Team darüber gesprochen habe und sie sagen: „Niemand benutzt es, komm darüber hinweg es!" und jetzt fangen die Leute an, es zu benutzen, und ich denke, wir müssen uns das ansehen.

Es gibt so viele interessante kleine Überraschungen, die normalerweise keine Rolle spielen, sie haben keinen großen Einfluss auf das Ranking oder die Indizierung oder was auch immer, aber es ist interessant, sie zu beobachten.

Und ich würde mich freuen, wenn mehr von den Geeks da draußen sich uns anschließen und einfach herumspielen und erkunden würden.

Jason: Das gilt für alle Aspekte von SEO. Je mehr wir experimentieren und erforschen und teilen, desto mehr lernt unsere Community, aber desto mehr erfährst du darüber, wie wir dies angehen und wie du uns helfen kannst, uns selbst zu helfen.