Was ist Rendern? Und warum ist das für SEO wichtig? [Alles auf Start 82]

6. April 2023 | Von in Podcast "Search Camp", SEO

Google rendert Seiten, denn nur so kann Google die richtigen Schlüsse aus den Inhalten ziehen und auf alle Inhalte korrekt zugreifen. Aber was ist das Rendern überhaupt? Aus welchen Gründen ist es wichtig? Und wo kann es dort zu Problemen kommen?

 

Hinweis: Von unserem Podcast "Alles auf Start" werden leider keine neuen Episoden mehr veröffentlicht (letzte Episode: Dezember 2023). Mehr SEO auf die Ohren? Dann können wir Dir natürlich unseren Podcast Search Camp empfehlen!

 

Was ist Rendern? Und warum ist das für SEO wichtig?

Heute kommt wieder eine Einsteigerepisode, und zwar vor allem deswegen, weil ich diese Frage sehr oft kriege und vor allem natürlich von Menschen, die jetzt nicht so in der Technik des Internets eingeweiht sind. Es gibt ja viele Leute, die eher einen redaktionellen Hintergrund haben zum Beispiel oder einfach insgesamt irgendwas gelernt haben, aber die eben nicht morgens schon mit Technik mit der Flasche großgezogen wurden, so wie ich es eigentlich bin. Und deswegen möchte ich dir heute das Thema Rendern näherbringen und vor allem, warum das für dich wichtig ist. Und was vielleicht auch da in den letzten Jahren so alles passiert ist.

 

Woraus besteht eigentlich eine Website?

Ich könnte mir vorstellen, wenn ich meine Kinder jetzt fragen würde, “Sag mal, woraus besteht eigentlich eine Webseite?”, würde ich ziemlich schräge Antworten kriegen. Wir benutzen zwar tagtäglich das Internet und das World Wide Web, aber wie das Ganze funktioniert, das wissen eigentlich nur wenige. Und deswegen auch diese Episode heute.

Also, wenn du auf eine Seite gehst, dann besteht die erstmal und primär aus dem HTML-Code. Das heißt, es gibt eine Programmiersprache, in der ist quasi alles hinterlegt, der ganze Text auf der Seite, aber auch der Seitentitel, die Meta Description und alles das, was so eine Seite eben ausmacht. Und das ist das, was Google sich primär anguckt.

Darüber hinaus gibt es in diesem HTML-Code, den man sich übrigens im Browser anzeigen lassen kann, gibt es auch Ressourcen, die angefragt werden. Und die wichtigste und sichtbarste Ressource sind sicherlich Bilder. Also eine Seite besteht ja nicht nur aus Text – ganz früher mal, ganz am Anfang – aber eben auch aus Bildern. Ressourcen sind Sachen, die zusätzlich zum HTML-Code geladen werden müssen.

Und da gibt es eben noch mehr. Da gibt es zum Beispiel Fonts. Das heißt, wenn ich möchte, dass meine Website so aussieht wie meine Broschüre, dann kann ich eben einen Zeichensatz auf Deutsch nachladen oder auch mehrere. Dann gibt es noch eine Ressourcenart, das sind CSS-Dateien. Cascading Style Sheets. Die sind dafür zuständig, dass die Seite richtig gelayoutet wird. Weil ohne CSS-Datei sähe eine Seite vollkommen langweilig aus, sie hätte einfach nur schwarzen Text und blaue Links und so, aber mehr jetzt auch nicht. So sehen Websites ja heute nicht mehr aus. Wenn man mal ein bisschen zurückguckt, so in die Anfangszeiten des Internets, da war das noch so, aber das haben wir heute nicht mehr. Das heißt, die CSS-Datei ist wichtig, weil sie beschreibt, wie eine Website gelayoutet wird.

Und dann gibt es noch JavaScript-Dateien. Das sind auch Ressourcen, die werden nachgeladen. Und da geht es um Programmierung. Und klassisch ist es ja so, klar, Websites entstehen oft programmatisch, aber das passiert auf dem Server. Und dann gab es – ich weiß noch, als das damals rauskam – kam jemand auf die – kam man auf die Idee, dass auch in dem Browser selber ein Programm ablaufen kann. Und das erleben wir zum Beispiel alle, wenn wir ein Formular ausfüllen, und – also ich tippe eine E-Mail-Adresse ein, und dann sagt er mir zum Beispiel über den grünen Haken auf einmal, Ja, diese E-Mail-Adresse ist korrekt. Und das wird eben zur Laufzeit gemacht. Und das macht eben JavaScript. JavaScript ist so ein kleiner Programmcode, der steht eben – steht da so rum, und der guckt dann immer nach, Ah, was hat das denn jetzt in das E-Mail-Feld eingetragen? Ist da schon noch ein Zeichen dabei? Aha, sieht gut aus, dann mach ich jetzt bitte einen grünen Haken dahin. Sowas passiert über JavaScript.

Früher war das alles nicht so. Also, was ich jetzt bis gerade beschrieben habe, ist ja quasi, wie das Web funktioniert. Das heißt, es gibt HTML-Code und Ressourcen. Und Google lädt ja Seiten runter, crawlt Seiten. Was sie früher gemacht haben: Sie haben nur den HTML-Code heruntergeladen. Da haben dann viele rumgetrickst, haben zum Beispiel gesagt, ja, ich mache zum Beispiel meine Hauptüberschrift, meine H1, die platziere ich im HTML-Code direkt an die erste Position, damit Google das als erstes sehen kann und gut bewertet. Optisch auf der Website war das aber gar nicht an der ersten Position, sondern dank dieser CSS-Dateien trenne ich mich dann halt davon und sage, Okay, diese Hauptüberschrift platziere ich aber eher weiter unten. Das waren so Tricksereien. Oder auch der berühmte weiße Text auf weißem Grund, das konnte man eben auch schön machen.

Das geht heute nicht mehr, denn Google rendert Seiten. Das heißt, Google lädt nicht mehr nur den HTML-Code, sondern Google macht das, was der Browser auch macht, wenn man eine Seite besucht. Er lädt alle Ressourcen, alle Bilder, CSS-Dateien, JavaScript-Dateien, alle Fonts. Und das hat natürlich erstmal einen höheren Aufwand. Also, früher war es einfach, nur den HTML-Code zu laden. Und es gibt ja durchaus Websites, die haben hundert Ressourcen. Das heißt, wenn Google eine Seite indexieren oder crawlen möchte, müssen sie eigentlich einen HTML-Code und hundert Ressourcen herunterladen. Und dann müssen sie das Ganze eben auch noch berechnen, weil dieses Rendern der Seite, das Ausführen von CSS, JavaScript, Fonts, und all dem, das braucht ja auch noch Rechenpower. Das heißt, das, was heute passiert, ist rechnerisch gesehen viel aufwendiger als das, was früher passiert ist. Und da fragt man sich: Warum macht Google das dann eigentlich? Und dafür gibt es zwei gute Gründe.

 

Grund #1: Google kann Erkenntnisse aus der grafischen Darstellung ziehen

Google weiß zum Beispiel, was an Text zum Beispiel ist oben, was ist unten. Oder was ist direkt sichtbar an Text und was nicht? Zum Beispiel, weil es in einem Tab ist, weil es in einem Akkordeon ist. Oder auch zum Beispiel, welches Textelement ist eigentlich groß, welches ist klein?

Das heißt, auch wenn ich eine Hauptüberschrift nicht als H1 formatiert habe, kann Google trotzdem Schlüsse ziehen, was denn meine Hauptüberschrift ist. Oder auch, welcher Text befindet sich eigentlich in der Nähe von Bildern? Weil das ist auch eine Information, die für die Bildersuche wichtig sein kann. Das heißt, aus dieser grafischen Darstellung kann Google Schlüsse ziehen, die durchaus wichtig sein können für Ranking-Entscheidungen, und deswegen tun sie das.

 

Grund #2: Die Existenz von JavaScript

Denn JavaScript ermöglicht ja zum Beispiel, dass Inhalte nachgeladen werden oder dass sie zum Beispiel auch direkt programmatisch generiert werden. Das heißt, wenn Google Inhalte nicht rendern würde, das heißt, sie würden keinen JavaScript-Code ausführen, könnten sie einige Inhaltsteile von einigen Websites nicht oder korrekt sehen.

Ein gutes Beispiel sind die Einkaufswelten in Shopware 5. Das sind so Elemente, die kannst du oben platzieren mit Bildern, und da kann auch eine Hauptüberschrift rein und so, und wenn man sich das mal anguckt, dann wirst du sehen, dass im HTML-Code eigentlich keine H1, keine Hauptüberschrift drin ist. Nach der Ausführung von JavaScript ist da aber auf einmal eine. Weil eben diese Einkaufswelten werden per JavaScript nachgeladen. Und deswegen nochmal, wenn Google diese Seite nicht rendern würde, würden sie sehen, da ist ja gar keine Hauptüberschrift drauf, aber da ist einer drauf. Ich sehe sie ja im Browser, sie steht nur im initialen HTML-Code nicht drin. Deswegen spricht man übrigens auch immer von zwei Arten von HTML-Code. Es gibt quasi den HTML-Code vor dem Rendern, und es gibt den HTML-Code nach dem Rendern.

 

Was kann dabei schiefgehen?

Das Rendern ist wichtig, und es gibt Fälle, in denen das Rendern nicht korrekt funktioniert. Und dann haben wir natürlich Probleme. Und deswegen würde ich euch immer empfehlen, das Rendern einmal zu prüfen. Und das geht über die Google Search Console. Da gibt es einen Punkt, der heißt “URL-Prüfung”. Da könnt ihr eine konkrete Seite reinstecken. Es geht immer nur für eine konkrete Seite, nicht für die gesamte Website. Das heißt, ihr macht das typischerweise für alle Seitentypen, die ihr so habt. Also Startseite, Kategorieseite, Newsseite, Blogseite, was auch immer.

Und dann gibt es oben einen Button, der heißt „Live URL testen“. Und wenn man da draufklickt, läuft Google in der Sekunde los und rendert die Seite. Das dauert so ein bis zwei Minuten, und danach bekommt man eine Sache, einen Screenshot. Das heißt, ich sehe quasi, wie sieht die Seite in einem mobilen Browser aus? Leider bekomme ich den nicht komplett, sondern ich kriege so typischerweise, ich glaube, es sind zwei Handy-Höhen, die ich da kriege, das heißt, wenn ich eine lange Seite habe – und das hat man in der mobilen Darstellung eigentlich immer – dann habe ich eben das Problem, dass ich nicht bis ganz unten scrollen kann. Aber ich kann ein paar Millimeter weiter scrollen. Und da kann ich erstmal einen Eindruck kriegen, ob meine Seite korrekt dargestellt wird.

Und vor allem zeigt Google mir in diesem Live URL testen auch alle Ressourcen an. Und da gibt es leider manchmal ein Problem, denn Google schafft es leider nur selten, alle Ressourcen zu laden innerhalb dieses Testes. Das muss nicht schlimm sein, aber für diesen Test ist es schlimm, weil er dann relativ aussagekräftig ist – unaussagekräftig. Was, so sehen wir es, neben allen Ressourcen steht ein Grund, warum diese geladen wurde oder nicht geladen wurde. Und da darf nicht – also, wichtige Ressourcen dürfen nicht per Robots.txt gesperrt sein. Heißt zum Beispiel, ein Bild sollte nicht per Robots.txt gesperrt sein. Ein Font sollte nicht gesperrt sein. Eine relevante JavaScript-Datei sollte nicht gesperrt sein. Und vor allem niemals, niemals nicht, sollte man CSS-Dateien sperren, denn dann kann es passieren, dass Google meine Seite eben nicht korrekt darstellen kann, dass Google vielleicht sogar feststellt, meine Seite ist gar nicht mobiltauglich, und das wäre natürlich sehr, sehr schade, weil das hätte wirklich sehr negative Auswirkungen auf meine Rankings.

Man darf natürlich trotzdem Ressourcen sperren, aber das sollte eben nur Ressourcen sein, die nicht für das Rendern wichtig sind. Zum Beispiel klassisch so ein Tracking Code. Also du hast irgendeinen Code eingebunden, damit irgendwo irgendwas getrackt wird. Ja, ist vollkommen egal. Das ist für die Darstellung der Seite nicht wichtig. Ist sogar fast gut, wenn das ganze gesperrt ist, damit da keine falschen Zahlen auflaufen. Also wichtig ist, ihr dürft Ressourcen sperren für Suchmaschinen über die Robots.txt, aber nichts, was wichtig ist für die Darstellung der Seite. Und vor allem eben nicht CSS-Dateien.

 

Was sind Render-Blocking Resources?

So, das war etwas, was ich euch mitgeben wollte. Jetzt, wenn ihr Lust habt, habe ich noch ein bisschen kurzes Zusatzwissen für euch, nämlich ich habe ja gesagt, wenn ihr demnächst auf die Party geht, wo ihr mit Sicherheit den Stich mit macht, ist das Thema Render-Blocking Resources. Dann seid ihr die absoluten Könige. Hat nicht direkt was mit dem Thema zu tun, aber wo wir schon mal über Resources sprechen. Ich habe ja gesagt, so eine HTML-Seite lädt verschiedene Ressourcen runter. Und es gibt zum Beispiel ein Tool, mit dem man sich das ganze sehr schön darstellen lassen kann, und das ist WebPageTest.org. Das kostet nichts, und da seht ihr ein sogenanntes Wasserfalldiagramm. Das heißt, der – das Programm zeigt euch dann an, was wird eigentlich alles geladen vom Server? Und das ist manchmal wirklich sehr erschütternd, wenn du das siehst. Zum Beispiel hatten wir mal den Fall, da wurden fast 300 Ressourcen geladen. Und je mehr Ressourcen geladen werden, desto langsamer ist natürlich der Ladevorgang an sich. Also, das kann ich euch nur mal empfehlen. WebPageTest.org. Ist im letzten Jahr einmal komplett überarbeitet worden, das heißt, wer das schon mal gesehen hat, sieht jetzt ein bisschen anders aus, kann aber immer noch das gleiche und ist immer noch ein geniales Tool.

Und wenn ihr das euch anguckt, dieses Wasserfalldiagramm, wo alle Ressourcen aufgelistet werden untereinander, werdet ihr sehen, dass einige Ressourcen vorne ein X haben, und das sind sogenannte Render-Blocking Resources. Und das heißt, das Rendern beginnt erst, wenn diese Ressourcen geladen wurden. Beispiel CSS-Datei. Das Rendern fängt erst an, wenn alle CSS-Dateien geladen wurden. Das macht auch vollkommen Sinn, weil das Rendern erfordert CSS-Dateien, und ja, anders geht es nicht. Das heißt, das sind eben Sachen, die halten das Rendern auf, und deswegen sind sie so kritisch für das Thema Page Speed Optimierung. Denn je mehr solche Ressourcen ich habe, die das Rendern aufhalten, desto länger dauert meine Seitenladezeit. Oder das, was Google sich anguckt, um es jetzt ein kleines Bisschen zu vereinfachen. Wenn jetzt irgendwo ganz unten auf der Seite irgendein Bild fehlt oder wenn das spät geladen wird, vollkommen egal, das Rendern geht ja auch ohne dieses Bild. Bilder halten das Rendern nicht auf. CSS-Dateien aber schon.

Und auch bei JavaScript Dateien, da ist es ein bisschen unterschiedlich. Es gibt nämlich Synchrone und Asynchrone. Also ich kann – im HTML-Code kann ich hinterlegen, ob diese JavaScript-Datei asynchron ist, oder Defer gibt es auch als mögliches Attribut, und dann hält es das Rendern eben auch nicht auf. Das heißt, wenn ich zum Beispiel so ein Facebook-Widget einbaue, dann sollte ich immer darauf achten, dass das asynchron eingebunden werden kann. Dann geht es nämlich nicht zu Lasten meiner Ladezeit, weil es dann keine Render Blocking Resource ist.

Mehr zu diesem Thema:
Nächste Events

Nächste Webinare

Alle kommenden Webinare

Nächste Seminare

Alle kommenden Seminare

The following two tabs change content below.
Avatar-Foto
My Instagram profile

Markus Hövener

Markus Hövener ist Gründer und SEO Advocate der auf SEO und SEA spezialisierten Online-Marketing-Agentur Bloofusion. Als geschäftsführender Gesellschafter von Bloofusion Germany ist er verantwortlich für alle Aktivitäten in Deutschland, Österreich und der Schweiz. Markus Hövener ist Buchautor, Podcaster und Autor vieler Artikel und Studien rund um SEO.

Markus hat vier Kinder, spielt in seiner Freizeit gerne Klavier (vor allem Jazz) und genießt das Leben.

Kommentieren