Die Überschrift von mir ist ein mieser Read-Bait (Du kannst hier ja nicht klicken). Die Aussagen von Martin Splitt in den JS SEO Office hours neulich (21.05.2021) haben die Welt weder verändert noch Hiobsbotschaften über den Web Rendering Service (WRS) offengelegt. Sie waren trotzdem sehr aufschlussreich und uns eine Erwähnung wert.
Besonders interessant (auch aus Sicht von Seoroundtable) ist die Erklärung zum WRS und wie Google diesen betreibt. Der WRS macht keine eigenen Requests für Ressourcen, sondern bekommt die Daten aus einer anderen Ebene:
"the WRS really is just the rendering service and then there's like a slightly bigger layer on top of it and that actually has prioritization, error retry, quality of service guarantees, caching and it also interacts with a crawling subsystem to actually fetch things."
Das klingt im Grunde nach Elementen eines Headless Browsers. Aber es wird ein paar Komplexitätsebenen mehr haben, als eine Selenium-Instanz.
Das kommt auch nicht überraschend, erklärt aber die Entkopplung von Request und Rendering-Ressourcen, die wir in Logfile-Analysen beobachten. Für SEOs bedeutet dies, dass das Caching mancher Ressourcen, die den Content beeinflussen, besonderes Augenmerk benötigen.
Weitere interessante Details, die Martin erwähnt:
- Rich Results, Mobile Friendly Test und URL-Inspection (Live Test) in GSC nutzen einen gemeinsamen Service (mit Namen SUIT) als Grundlage. Pagespeed Insights hat Martin nicht erwähnt und auch einen eigenen User Agent. Die sind also technisch auf einem anderen Fundament.
- Rich Result Test nutzt noch den Desktop Crawler für die Desktop Ansicht. Martin hat aber (natürlich) nicht eindeutig beantwortet, ob sich das auch auf die Suchergebnisse bezieht. Das würde in Zeiten von Mobile Only natürlich eigentlich wenig Sinn ergeben.
Nicht wirklich neu, aber gut wieder zu hören waren die folgenden Punkte:
- Auch Martin, der in Search Off the Record JavaScript fleißig verteidigt, rät von unnötigen Skripten ab. Löse ohne JS was Du ohne JS lösen kannst.
- Es gibt einen Geschwindigkeitsvorteil für das Entdecken neuer URLs, wenn die Links direkt im HTML stehen und nicht nachträglich per JavaScript eingefügt werden. Auf die Priorisierung bei Crawling und Indexierung wirkt sich das nicht aus. Aus unserer Sicht bleibt es dabei, wichtige Links müssen im Raw-HTML stehen.
- Widersprüche im Canonical zwischen rendered & unrendered HTML sorgen dafür, dass die Gewichtung des Signals abnimmt, und Google sich eher ein eigenes Canonical auswählt. Das gilt vermutlich nicht nur für das Canonical, sondern generell für alle Fälle, in denen wir Google "mixed Signals" senden.
- noindexed Seiten werden nicht gerendert. Index-Angaben gehören ins Raw-HTML. (Unser letztes Experiment dazu werden wir wohl noch mal prüfen müssen)
- Other Errors im GSC Live URL Test sind immer mal Stoff für Verwirrung. In der Regel aber nicht brisant, sondern entweder temporär oder von Google als Ressource bewusst nicht abgerufen. Bilder zum Beispiel wertet der Googlebot-Image aus. Der "normale" Googlebot liest nur die Alt-Texte. Diese Trennung bleibt weiter bestehen.
- Für Google/Martin Splitt sind, im Bezug auf Crawling Ressourcen, kleine Domains < 1.000.000 URLs.