Einleitung
Schon seit Jahren versuchen Suchmaschinen und jetzt auch KI-Systeme, Webseiten zu verstehen – mitsamt all dem JavaScript, Lazy Loading und interaktiven Inhalten, die das moderne Web so komplex machen. Doch während Google mittlerweile erstaunlich gut darin ist, JavaScript zu interpretieren, sieht es bei den neuen LLM‑Crawling‑Systemen (Large Language Models) ganz anders aus. Viele dieser Bots stoßen schon bei simplen Skripten an ihre Grenzen.
Aus meiner Erfahrung ist das heute eine der größten Herausforderungen für SEOs: Wir wissen, dass Inhalte oft clientseitig gerendert werden, weil das für Entwickler bequemer ist, aber suchtechnisch kann das zum Desaster werden – vor allem, wenn du möchtest, dass dein Content nicht nur bei Google, sondern auch in generativen KI‑Modellen auftaucht.
In den folgenden Abschnitten zeige ich dir, warum das so ist, wie du technisch prüfen kannst, ob deine Seiten korrekt gelesen werden, und vor allem, wie du sicherstellst, dass Googlebot und LLM‑Bots wichtige Inhalte auch wirklich sehen können.
—
Wie Google JavaScript verarbeitet
Man kann sich den Crawlprozess von Google in drei groben Phasen vorstellen: **Crawling**, **Rendering** und **Indexierung**. Es sind zwar technische Details im Hintergrund, aber das Prinzip ist recht einfach, wenn man es einmal verstanden hat.
Crawling
Zuerst entdeckt Google neue URLs über Links oder XML‑Sitemaps und setzt sie auf eine Warteliste. Vor jedem Zugriff prüft der Googlebot, ob ein Crawl überhaupt erlaubt ist – etwa über deinen robots.txt‑Eintrag oder Metatags. Wenn dort ein Verbot steht, wird die Seite übersprungen. Ist sie freigegeben, zieht sich der Bot das HTML‑Gerüst.
Das ist der Rohzustand – noch ohne ausgeführtes JavaScript. In diesem Moment weiß Google meist nur, welche Basisstruktur die Seite hat, also Überschriften, Meta‑Title, ein paar Links – das war’s.
Rendering
Erst im nächsten Schritt wird der Code wirklich „ausgeführt“. Das passiert nicht immer sofort, denn Rendering kostet Rechenleistung. Google hat eigene Render‑Warteschlangen – bei großen Websites kann das durchaus verzögert passieren.
Wenn die Seite schließlich gerendert wird, läuft dein JavaScript, und Google sieht die vollständige DOM‑Struktur, also die Ansicht, die ein Browser nach dem Laden darstellen würde. Alle dynamisch eingespielten Inhalte erscheinen nun in voller Pracht.
Aber: Nicht jedes Skript wird korrekt verarbeitet. Zeitverzögerte Inhalte – etwa Text, der erst nach Nutzereingabe sichtbar wird – können vom Bot übersehen werden.
Indexierung
Nur was Google im Rendering erkennt und erlaubt ist, wird in den Index übernommen. Dann entscheidet der Algorithmus, wann und wie deine Seite in den Suchergebnissen auftaucht.
Spannend ist, dass Google trotz dieses recht ausgefeilten Prozesses weiterhin am liebsten „einfaches HTML“ serviert bekommt. Alles andere ist ein Risiko.
—
Was passiert mit versteckten oder interaktiven Inhalten?
Stell dir vor, du öffnest eine Produktseite und siehst nur eine kurze Beschreibung. Zusätzliche Infos stehen in Reitern oder in einem Akkordeon‑Element, das erst nach Klick aufklappt.
Klingt nach einem netten UX‑Feature – ist es auch. Nur: der Googlebot klickt nicht! Wenn der Text erst durch Nutzerinteraktion oder ein JavaScript‑Event geladen wird, kann er unsichtbar bleiben.
Die Lösung: Platziere die Inhalte trotzdem im ersten HTML‑Load im DOM. Sie dürfen visuell versteckt sein (z. B. `display:none` über CSS), aber im Quellcode sollten sie bereits existieren. Dann kann Google sie beim ersten Rendern lesen.
Man kann sich das vorstellen, als würdest du dem Bot die geschlossene Verpackung, aber den Inhalt schon mitgeben. Er muss also die Box nicht öffnen, um zu sehen, was drin ist.
—
Wie du sicherstellst, dass Google deine Inhalte lesen kann
Das Zauberwort lautet Server‑Side Rendering (SSR). Dabei wird die Seite nicht erst im Browser des Nutzers gebaut, sondern schon auf dem Server.
Dadurch entsteht fertiges HTML, das direkt an Besucher und Crawler geliefert wird – kein Warten auf JavaScript, kein Risiko, dass Inhalte verloren gehen.
Bei Client‑Side Rendering (CSR) dagegen kümmert sich der Browser um das Zusammenbauen. Das spart Serverressourcen, aber für SEO ist es ein zweischneidiges Schwert: Bots müssen mehr Arbeit leisten, Inhalte können zu spät oder gar nicht erscheinen.
Wenn du also Wert auf Sichtbarkeit legst, solltest du prüfen, ob dein Framework SSR unterstützt (React, Next.js, Nuxt u. Ä. bieten oft entsprechende Optionen). Schon das Umschalten kann Welten verändern.
—
Wie LLM‑Bots mit JavaScript umgehen
Hier wird’s richtig interessant – und ehrlich gesagt, auch ein bisschen wild. Es gibt **keinen einheitlichen Standard**.
Ein Googlebot gehört zu Google – klar. Aber OpenAI, Anthropic, Perplexity, Meta oder Apple betreiben ihre eigenen Crawler mit sehr unterschiedlichen technischen Ansätzen.
Was wir bis heute wissen: Nur ganz wenige dieser Bots führen tatsächlich JavaScript aus.
Studien, etwa von Entwicklern bei Vercel oder Analysen von Glenn Gabe, haben gezeigt:
– Bots von OpenAI, Anthropic, Perplexity oder ByteDance können kein JavaScript rendern.
– Nur wenige Ausnahmen wie Applebot oder Gemini (der auf Google‑Technologie basiert) schaffen es.
Das heißt im Klartext: Für die meisten LLMs bleibt deine Seite so sichtbar, wie sie im reinen HTML‑Code steht – ohne dynamische Nachlade‑Elemente.
Wenn du also Inhalte via React oder Vue erst clientseitig einspielst, sehen die meisten KI‑Crawlers: nichts.
Immer mehr Unternehmen testen inzwischen, wie ihre Website von LLM‑Bots interpretiert wird. Wer seine Marke in den Antwortboxen von ChatGPT & Co. finden möchte, sollte sich schleunigst um serverseitiges oder hybrides Rendering kümmern.
—
Interaktiver Content aus Sicht von LLMs
Hier gilt dasselbe Prinzip wie bei Google – nur strenger. Tabs, Akkordeons oder aufklappbare Sektionen, die ohne JavaScript erst erscheinen, sind für KI‑Bots meist unsichtbar.
Also: Platziere Texte, Beschreibungen und Einträge direkt im DOM. Nur so kannst du sicher sein, dass sie ausgelesen werden – egal ob für Search oder für ein LLM‑Training.
Visuell kann alles schön animiert bleiben; entscheidend ist, dass die eigentliche Information schon im Quelltext existiert.
—
Wie du JavaScript‑Probleme aufspürst
Ich verrate dir zwei einfache, aber sehr wirkungsvolle Methoden.
1. Kontrolliere den DOM über Developer Tools
Öffne Chrome, rechtsklick auf die Seite, **“Inspect”** wählen. Im Reiter „Elements“ siehst du den DOM‑Baum – also das, was nach Rendering vorhanden ist.
Wenn du dort gleich den Text findest, der dir wichtig ist (ohne dass du erst etwas anklickst), weißt du: Google und die meisten Bots sehen ihn ebenfalls.
Falls du ihn erst nach einer Interaktion findest, steckt er wahrscheinlich in JavaScript‑Funktionen – schlecht für Bots.
2. Nutze die Google Search Console
Dort kannst du eine URL testen („Inspect any URL“). Per „Live‑Test“ zeigt dir Google, wie es die Seite sieht. Wenn bestimmte Bereiche fehlen, ist das ein deutliches Zeichen dafür, dass sie clientseitig zu spät oder gar nicht geladen werden.
So etwas erkenne ich öfter bei Websites mit Cookie‑Bannern oder Lazy‑Loading‑Textmodulen.
—
Wie du prüfst, was LLM‑Bots tatsächlich lesen
Hier führt der einfachste Weg über – genau – die KI selbst. Frag ChatGPT oder Claude: „Lies bitte den Text auf dieser URL und sag mir, was du findest.“
Wenn die Antwort lautet, dass der Artikel nicht zugänglich ist oder dass Teile fehlen, weißt du Bescheid.
Ein anderer Trick ist, dir in Chrome den Quelltext anzeigen zu lassen (**STRG+U** oder Rechtsklick → „Seitenquelltext anzeigen“). Finde dort deinen Inhalt. Wenn er vorhanden ist, kann ihn theoretisch auch ein LLM lesen. Wenn du ihn nicht siehst, ist er erst per JavaScript nachgeladen – dann bleibst du unsichtbar.
—
Was das alles praktisch bedeutet
Die Welt der Crawler teilt sich derzeit in zwei Lager:
1. **Googlebot** – inzwischen wirklich gut im Rendern von JavaScript, aber trotzdem lieber auf serverseitige Inhalte eingestellt.
2. **LLM‑Bots** – junge Systeme ohne Rendering‑Power, die reines HTML bevorzugen.
Wenn du also KI‑Sichtbarkeit willst – also dass deine Marke, deine Antworten, dein Content in den Antwortfeldern von ChatGPT & Co. auftauchen – musst du deine Website so bauen, dass sie ohne JavaScript verstanden werden kann.
Dazu kommen noch Kleinigkeiten, die in der Praxis oft vergessen werden:
– Teste, ob dein Text wirklich in der ersten DOM‑Struktur erscheint.
– Vermeide, dass wichtige Inhalte nur über Klicks nachgeladen werden.
– Vertraue nicht darauf, dass alle Bots irgendwann „so schlau wie Google“ werden.
Ich persönlich glaube auch nicht, dass generative Suchsysteme jemals exakt wie Googlebot arbeiten werden – sie brauchen andere, effizientere Crawlstrategien. Und die meisten werden JavaScript weiterhin meiden, weil es zu teuer in der Verarbeitung ist.
—
Ein Fazit mit klaren Handlungsempfehlungen
– **Denke serverseitig:** Wenn möglich, nutze SSR oder zumindest statisches Pre‑Rendering deiner wichtigsten Seiten.
– **Vermeide dynamische Texte:** Alles, was für SEO oder KI relevant ist, gehört ins statische HTML.
– **Teste regelmäßig:** Sowohl mit Google Search Console als auch mit den Developer Tools – und hin und wieder direkt bei ChatGPT.
– **Plane langfristig:** Die Suchlandschaft wird sich in Richtung LLM‑gestützter Systeme verschieben. Wer früh sicherstellt, dass seine Website „lesbar“ bleibt, profitiert doppelt – bei Ranking und bei KI‑Antworten.
Aus meiner Sicht steht SEO heute an einem Punkt, an dem technisches Verständnis entscheidender ist als je zuvor. Marketing‑Texte allein reichen nicht; du musst wissen, wie dein Server antwortet, wie dein Framework rendert und wie ein Crawler wirklich „liest“.
Wenn du das beachtest, ist es fast egal, ob dein Traffic von Google oder einem KI‑Assistenten kommt – dein Inhalt findet immer seinen Weg zum Nutzer.
