Rendering-Kochkunst: Dein Rezept vs. was Google daraus macht

Vor ein paar Monaten gab es einen spannenden Vortrag von Martin Splitt auf der SEOnthebeach zum Thema Rendering. Vor kurzem hat Martin in einer weiteren Session mit Duda, circa eine Stunde lang, Beispiele und Fragen zum Thema Rendering aufgeklärt.

Insgesamt fast 90 Minuten, die ich Dir kompakt zusammengefasst präsentieren möchte.

Rendering in a nutshell

Eine der wichtigsten Erkenntnisse (viele wissen das auch): Das HTML was wir schreiben, ist nicht das, was Nutzer\*innen am Ende sehen. JavaScript kann HTML verändern oder neues HTML hinzufügen.

Ganz einfach ausgedrückt bedeutet Rendering:

"Rendering is the process that turns hypertext into pixels."

Der Document Object Model Tree (kurz DOM tree), also das, was wir im Browser bei uns sehen (und in den DevTools abgebildet wird) ist ein "in progress Snapshot". Martin hat zwei bildliche Vergleiche gemacht.

1. Ein Kochrezept ist das Source/Raw HTML und der DOM/Rendered HTML ist das gekochte Rezept.

2. Jemand beschreibt ein Bild, das Du malen sollst. Das Bild ist fertig, da beschreibt der jemand, dass sich Dinge verändert haben, die Du jetzt anpassen musst.

Das ist genau das, was im Browser passiert, wenn sich der DOM verändert. Google ist relativ gut darin, mit JavaScript umzugehen. Wie wir von Johan gelernt haben, gilt das aber nicht für alle Suchmaschinen, wie zum Beispiel Bing.

Was wird am Ende als gerendertes HTML genommen?

Auf die Frage, welchen Teil des DOM Google verwendet, wurde deutlich, wie kompliziert das Thema ist. Es gibt zwar einen Timeout (Martin wollte keine genaue Zahl nennen), aber es ist ineffizient, auf Events zu warten.

Daher gibt es eine Event-Schlange (Event Queue). Wenn diese leer ist, dann wird das zu dem Zeitpunkt gerenderte HTML genommen. Wenn jemand Dir also ein Bild beschreibt und es immer wieder zu Veränderungen kommt, dann werden diese nach und nach gemalt – irgendwann ist hier aber Schluss. Dinge, die durch Klicks oder Scrolling ausgelöst werden, können dabei nicht verwendet werden – logisch, weil Crawler nicht klicken, scrollen oder anderweitig interagieren.

Oft ist bei derartigen Interaktionen, beispielsweise wenn Content erst durch einen Klick sichtbar beziehungsweise generiert wird, auch die Barrierefreiheit eingeschränkt. Die Elemente müssen mit einer Tastatur erreichbar und bedienbar sein.

Wenn Du mehr zum Thema Barrierefreiheit lesen möchtest: Sandra hat Dir erzählt, warum Barrierefreiheit gut für SEO und UX ist und ich habe mich einmal ausgelassen, warum Slider auch für die Barrierefreiheit oft ein Killer sind. Wir unterstützen Dich auch gerne bei einem Accessibility Audit, um Dich auf die bevorstehenden Veränderungen in 2025 vorzubereiten. Schreib' uns dazu einfach an!

Ebenfalls empfehlenswert: Derartige Inhalte lazy laden, da sie nicht direkt sichtbar sind. Das tut den Core Web Vitals gut und Du lädst keine unnötigen Ressourcen, wenn diese sowieso nicht gebraucht werden.

Malt Google auch die Pixel?

Nein, Google arbeitet nicht mit Pixeln und der Screenshot im URL Inspection Tool der Google Search Console ist zwar nett anzusehen, aber unwichtig. Martin betont mehrfach, dass es um das gerenderte HTML geht, das man bei einer URL-Prüfung in der GSC sehen kann.

Ein Mythos, der immer wieder zur Äußerung kommt, ist, dass Websites mit viel JavaScript langsamer indexiert werden können. Laut Martin sei das schon lange nicht mehr so. Das gilt aber, wie oben generell für JavaScript beschrieben, nur für Google und nicht für andere Suchmaschinen! Bei Google dauert es im Durchschnitt 5 Sekunden bis das Rendering einer URL beginnt. Eine Verzögerung, bis Google rendert, kann also auch mal etwas länger dauern (Minuten), aber auf keinen Fall Tage, Wochen oder Monate.

Werden KI-Inhalte Auswirkungen auf den Rendering-Prozess haben?

Auf die Frage, ob der Rendering-Prozess durch die Zunahme an mit künstlicher Intelligenz erstellten Inhalten angepasst oder vereinfacht werden müsste, schüttelt Martin den Kopf. Eine Qualitätskontrolle erfolgt in mehreren Schritten und schlechter Inhalt braucht kein ausgeführtes JavaScript, um als schlecht erkennbar zu sein.

Im Fall, dass diese Qualitätskontrolle greift, wird nicht gerendert. Das heißt, wenn das Source/Raw HTML nicht gut ist, findet kein Rendering statt. Martin sagt nicht genau, was Google unter schlechtem HTML versteht. Aber hier würde ich mich an den allgemeinen Richtlinien von Google und den Fragen für hilfreichen Inhalten orientieren.

Das, was im Source/Raw HTML gesendet wird, muss also bereits gut sein/die wichtigen Inhalte enthalten. Wenn da nichts drin steht, wird Google sich vermutlich denken, dass der Inhalt schlecht ist und so landest Du in "Crawled - currently not indexed".

Fun-fact: Falls das Source/Raw HTML leer ist, wird übrigens gerendert, weil wer weiß was nach dem Rendern da ist.

Es wurde nach Dynamic Rendering gefragt und Martin sagt, man kann theoretisch alles machen, spricht sich aber dagegen aus. Also lieber lassen.

Was ist, wenn eine Seite im Google Cache falsch dargestellt wird?

Eine interessante Frage der Zuschauer\*innen war folgende (von mir übersetzt):

"Ist es schlimm, wenn eine URL im Cache nicht richtig dargestellt wird?"

Martin sagt hier eindeutig nein. In vielen Fällen läge das zum Beispiel am Cross Origin Opener Policy HTTP Header. Ganz einfach beschrieben: Wenn ein Inhalt auf einer anderen Domain als auf der Ursprungsquelle eingebunden wird (beispielsweise als iFrame), dann darf dieser Inhalt nicht angezeigt werden.

In dem gezeigten Beispiel war dies der Fall. Auch hier erneut der Hinweis: Solange das gerenderte HTML bei der URL Inspection passt, ist alles gut.

Dinge, die im Google Cache angezeigt werden, liegen auf einer anderen Domain  (webcache.googleusercontent). 

Die wichtigsten Punkte

Als kurzes Resumé lassen sich folgende Punkte nochmal destilliert zusammenfassen:

• Was nach dem Rendern sichtbar ist, ist das, was indexiert wird.

• Achte daher auf große Unterschiede zwischen dem, was als Source/Raw HTML gesendet wird, und was am Ende nach dem Rendern rauskommt.

• Es dauert Sekunden oder Minuten, bis das Rendern von Google beginnt und nicht Stunden, Tage, Wochen oder Monate.

• Schlechtes HTML wird gar nicht erst gerendert.

• Teste immer mit der URL Inspection aus der Google Search Console, da es auf dieses HTML ankommt.

Falls Du das Gefühl hast, dass bei Dir bezüglich des Renderings irgendwas im Argen sein könnte, meld Dich gerne – gemeinsam kommen wir der Sache auf die Spur und gehen sicher, dass Google und/oder Bing keine Probleme mit Deiner Website haben.