Hinweis: Dieser Beitrag gehört zur Wissensrubrik Technisches SEO ist tot. Lang lebe die maschinelle Lesbarkeit. im Mehrklicks-Wissensportal.
Die Inhalte beschreiben Methoden und Strukturen, mit denen wir Marken für KI-Systeme wie ChatGPT, Perplexity und Google AI Overviews sichtbar machen.
Eine thematische Einordnung und die operative Umsetzung findest du auf der Seite Agentur für KI-Sichtbarkeit.
Ich erinnere mich an das Meeting mit einem neuen Kunden. Ein Vorzeigeunternehmen, die digitale Speerspitze seiner Branche. Ihre Webseite: eine Augenweide. Gebaut mit React, interaktiv, blitzschnelle Übergänge – ein Traum für jeden User. Dann öffnete ich den Quellcode. Gähnende Leere. Ein simpler HTML-Container und ein Verweis auf ein massives JavaScript-Bundle.
Für uns Menschen sah die Seite perfekt aus. Für eine Maschine war sie eine leere Hülle. Bei Google hatte sie es mit viel Aufwand und Geduld irgendwie geschafft, zu ranken. Doch in ChatGPT, Perplexity und Co. existierte sie nicht. Die Marke war für die neue Generation von Empfehlungs- und Antwortmaschinen vollkommen unsichtbar. An diesem Tag wurde mir klar: Die Ära des Client-Side-Renderings (CSR) ist vorbei.
Um zu verstehen, warum so viele moderne Webseiten für KI-Systeme ein blinder Fleck sind, hilft ein kurzer Blick zurück. Die meisten interaktiven Webseiten werden heute mit JavaScript-Frameworks wie React, Vue oder Angular gebaut. Ihr Ansatz, das sogenannte Client-Side-Rendering, war revolutionär: Der Server schickt nur eine minimale HTML-Struktur an deinen Browser (den Client). Der Browser lädt dann das JavaScript, führt es aus und „baut“ die Webseite erst dort zusammen.
Das Ergebnis sind oft hochdynamische, App-ähnliche Erlebnisse. Aber es hat einen fatalen Preis: Die Maschine, die deine Seite analysieren soll, erhält im ersten Moment nur ein leeres Dokument. Sie muss warten, hoffen und interpretieren.
Genau hier trennt sich die Spreu vom Weizen. Die Alternative heißt Server-Side-Rendering (SSR). Bei diesem Ansatz erledigt der Server die ganze Arbeit. Er baut die komplette, fertige HTML-Seite zusammen und schickt sie an den Browser. Was der Browser empfängt, ist sofort vollständig, lesbar und verständlich.
Der Unterschied ist nicht nur technisch, er ist fundamental:
Links siehst du, was eine Maschine bei CSR zuerst bekommt: eine leere Schachtel mit einer Bauanleitung (JavaScript). Rechts hingegen liefert SSR das fertige Produkt.
Jetzt sagst du vielleicht: „Aber meine React-Seite rankt doch bei Google!“ Das stimmt. Google hat über Jahre hinweg enorme Ressourcen investiert, um JavaScript-lastige Seiten zu verstehen. Der Googlebot führt einen zweistufigen Prozess aus: Zuerst crawlt er das rohe HTML, Tage oder Wochen später kommt ein Renderer und versucht, das JavaScript auszuführen. Dieser Prozess ist langsam, fehleranfällig und ressourcenintensiv.
Diese Geduld haben die Crawler der neuen KI-Systeme nicht. GPTBot (OpenAI), ClaudeBot (Anthropic) und andere sind auf Effizienz getrimmt. Sie führen in den meisten Fällen kein JavaScript aus. Sie lesen, was der Server im ersten Moment liefert. Wenn das eine leere Seite ist, ist dein Inhalt für sie nicht existent.
Für sie sieht deine teure, moderne Webseite so aus:
Das ist der Kern des Problems. Während du noch für den alten Googlebot optimierst, hat sich das Spielfeld längst verändert. Es geht nicht mehr nur um Google, sondern um [INTERNAL LINK: die Wahrheit über KI-Sichtbarkeit: Warum SEO tot ist]. Sichtbarkeit entsteht heute in einem Ökosystem von Maschinen, von denen die meisten keine Zeit für deine JavaScript-Experimente haben.
Sogar Google rät in seiner offiziellen Dokumentation auf web.dev zu Server-Side-Rendering oder Static Site Generation (SSG) für die beste Performance. Warum? Weil CSR inhärente Nachteile hat, die weit über das reine Crawling hinausgehen.
Langsamere Ladezeiten: Bei CSR muss der Nutzer warten, bis das JavaScript geladen, geparst und ausgeführt wurde, bevor er den ersten Inhalt sieht. Das führt zu schlechten Werten bei wichtigen Kennzahlen wie dem First Contentful Paint (FCP). Eine SSR-Seite liefert den Inhalt sofort.
Das „Hydration“-Problem: Selbst wenn die CSR-Seite im Browser aufgebaut ist, ist sie oft nicht sofort interaktiv. Ein Prozess namens „Hydration“ muss erst die Events an das HTML binden. Diese Verzögerung kann frustrierend sein und wird von Maschinen als weiteres negatives Signal gewertet.
Fehleranfälligkeit: Wenn das JavaScript aus irgendeinem Grund fehlschlägt – sei es durch ein Netzwerkproblem oder einen Bug im Code –, bleibt die Seite einfach leer. Bei SSR ist der Inhalt immer da, selbst wenn die interaktiven Elemente später nicht laden.
Diese technischen Nachteile sind nicht nur für Nutzer spürbar. Für Maschinen sind sie rote Flaggen, denn eine langsame, unzuverlässige Seite ist keine vertrauenswürdige Quelle. Deine Marke muss aber für Maschinen lesbar und verlässlich sein. Das ist die Grundvoraussetzung, um als relevante Wissenseinheit wahrgenommen zu werden – [INTERNAL LINK: Wie du deine Marke maschinenlesbar machst].
Die Entscheidung für oder gegen eine Rendering-Methode ist keine reine IT-Diskussion mehr. Sie ist eine strategische Entscheidung über die Zukunftsfähigkeit deiner digitalen Präsenz. Wenn deine Inhalte nicht im ersten Request als vollständiges HTML verfügbar sind, baust du eine unnötige und gefährliche Barriere zwischen dir und den Systemen auf, die über deine Sichtbarkeit entscheiden.
Moderne Frameworks wie Next.js (für React) oder Nuxt.js (für Vue) haben dieses Problem längst gelöst und machen die Implementierung von SSR einfacher als je zuvor. Es gibt heute keine Ausrede mehr, eine rein Client-Side-gerenderte Seite für inhaltsgetriebene Projekte zu bauen.
Am Ende geht es darum, dass deine Inhalte nicht nur für Menschen, sondern auch für Maschinen sofort und unmissverständlich zugänglich sind. Nur so können deine Inhalte als klare Entitäten ([INTERNAL LINK: Was ist eine Entität? Einsteiger-Guide]) erkannt, kontextualisiert und in den Antworten von KI-Systemen empfohlen werden. CSR ist das technische Äquivalent zu einer verschlossenen Tür, während SSR der offene, einladende Eingang ist.
Beim Client-Side-Rendering schickt der Server eine fast leere HTML-Datei an den Browser des Nutzers. Der Browser lädt dann eine JavaScript-Datei, die die Webseite direkt im Browser des Nutzers aufbaut. Der Nutzer sieht Inhalte erst, nachdem das JavaScript vollständig ausgeführt wurde.
Beim Server-Side-Rendering wird die komplette, fertige Webseite bereits auf dem Server erstellt. Der Browser erhält eine vollständig gerenderte HTML-Seite. Das hat zwei entscheidende Vorteile: Der Inhalt ist sofort sichtbar (bessere Performance für Nutzer) und für jede Maschine (Crawler, Bots) sofort lesbar, ohne dass JavaScript ausgeführt werden muss.
Das hängt davon ab, wie du das Framework einsetzt. Eine Standard-Installation von „Create React App“ oder Vue CLI erzeugt eine reine CSR-Anwendung. In diesem Fall bist du höchstwahrscheinlich betroffen. Wenn du jedoch ein übergeordnetes Framework wie Next.js (für React) oder Nuxt.js (für Vue) verwendest, nutzt du wahrscheinlich bereits SSR oder SSG und bist auf der sicheren Seite.
Google hat über ein Jahrzehnt in einen aufwendigen JavaScript-Rendering-Dienst investiert, um CSR-Seiten indexieren zu können. Dieser Prozess ist jedoch langsam und nicht garantiert. Die meisten anderen Crawler, insbesondere die von KI-Unternehmen wie OpenAI, verzichten auf diesen ressourcenintensiven Schritt. Sie lesen nur das, was der Server direkt ausliefert.
Ja, absolut. SSG ist eine hervorragende Alternative. Dabei werden alle Seiten deiner Webseite bereits zum Zeitpunkt der Entwicklung (Build Time) als fertige HTML-Dateien erstellt. Das bietet die beste Performance und perfekte maschinelle Lesbarkeit. SSG ist ideal für Inhalte, die sich nicht ständig ändern, wie Blogs, Dokumentationen oder Marketing-Seiten. SSR ist besser für hochdynamische Inhalte, die sich bei jeder Anfrage ändern können (z. B. personalisierte Dashboards).
Die Wahl der richtigen Rendering-Methode ist aus dem Keller der IT-Abteilung auf die Tische der Strategen gewandert. Client-Side-Rendering war ein interessantes Experiment, aber für jede Marke, die im Zeitalter der KI relevant bleiben will, ist es eine Sackgasse.
Nur was eine Maschine im ersten Moment lesen kann, existiert für sie. Server-Side-Rendering ist keine Option mehr – es ist das Fundament, auf dem jede zukunftsfähige Content-Architektur aufgebaut sein muss. Alles andere ist die bewusste Entscheidung für die Unsichtbarkeit.