Rendert KI JavaScript?

#Rendert KI JavaScript

Für Suchmaschinen-Ingenieure ist das keine neue Idee, doch bislang war es Argument statt Beweis. Jetzt wurde es direkt getestet, und der Beweis ist unbequem für die große Klasse von Websites, die als JavaScript-Anwendungen gebaut sind und ihre Inhalte im Browser zusammensetzen.

#So lief der Test zum JavaScript-Rendering durch KI

Der Test, durchgeführt von Andre Alpar und im Juni 2026 veröffentlicht auf Search Engine World, war einfach und schwer zu täuschen. Die Seite lieferte eine Köder-Referenznummer im rohen HTML aus. Die echte Nummer wurde erst durch externes JavaScript ersetzt, das von einem zweiten Endpunkt abgerufen wurde, und sie stand weder im HTML noch im Quelltext des Skripts. Jeder der zwölf Assistenten erhielt eine eigene, nirgends verlinkte, nicht erratbare URL, sodass sich jeder Serverzugriff genau einem Assistenten zuordnen ließ, und der Server protokollierte drei separate Ereignisse: den Seitenabruf, den Abruf der JavaScript-Datei und den Aufruf des Nummern-Endpunkts. Die Logik ist wasserdicht. Gibt man die echte Nummer zurück, hat man das Skript ausgeführt. Gibt man den Köder zurück, hat man nur das HTML gelesen.

Der Abruf wurde vom Nutzer ausgelöst. Alpar fügte jede URL von Hand in den Chat ein und bat den Assistenten, die Seite zusammenzufassen und die interne Referenznummer zu nennen. Der Test misst also, was passiert, wenn ein Mensch einem Assistenten einen Link gibt, und nicht, was ein Hintergrund-Crawler nach eigenem Zeitplan tut. Alpar benennt die Grenzen selbst: Es sei “ein Test mit einem Durchlauf und Live-Abruf: ein Prompt pro Assistent, festgehalten zu einem Zeitpunkt”, und Hintergrund-Crawler wie GPTBot und ClaudeBot “könnten sich durchaus anders verhalten” (eigene Übersetzung). Das Ergebnis ist eine scharfe Momentaufnahme des Live-Antwortpfads im Juni 2026, keine dauerhafte Eigenschaft der einzelnen Produkte.

#Welche KI-Assistenten lesen nur rohes HTML ohne JavaScript

In Alpars Test gaben diese Assistenten den Köder zurück, stützten sich also auf rohes HTML und führten das Skript nie aus:

• ChatGPT
• Claude
• Gemini
• Perplexity
• Meta AI
• Microsoft Copilot

Grok führte das JavaScript auf einem Knoten aus, gab aber dennoch den Köder zurück, sodass selbst dort, wo das Skript lief, der gerenderte Wert nicht in die Antwort gelangte.

Drei Details aus den Serverlogs schärfen das Bild. Unter den US-Systemen, die nicht renderten, war Microsoft Copilot das einzige, das die JavaScript-Datei herunterlud, und zwar über den Drittanbieter-Scraper Diffbot, rief den Nummern-Endpunkt aber nie auf und meldete den Köder. Gemini, das Alpar als Überraschung bezeichnet, weil es von Google kommt, renderte ebenfalls nicht. Perplexity antwortete, es könne die Seite nicht abrufen, obwohl sein Crawler sie mit HTTP 200 geladen hatte. Daher Alpars Rat: Vertrauen Sie dem Serverlog, nie der Darstellung des Chatbots, was er getan hat.

Glenn Gabe von GSQi stellte die Frage auf fünf Plattformen erneut und veröffentlichte das Ergebnis am 19. Oktober 2026. ChatGPT, Claude und Perplexity fielen in allen drei Tests durch. Gemini und Copilot bestanden die ersten beiden: eine Seite, deren gesamter Inhalt per JavaScript lädt, und eine Seite mit statischem Header und Footer, aber Inhalt aus JavaScript. Im dritten Test, einer Parallax-Seite auf WebGL-Basis, las Gemini den Inhalt, Copilot nicht. Gabe erklärt das direkt: “Gemini nutzt die Suchsysteme von Google und kann deshalb Inhalte sehen, die per JavaScript gerendert werden” (eigene Übersetzung). Den Erfolg von Copilot führt er auf dieselbe Weise auf die Suchsysteme von Bing zurück.

Beide Ergebnisse können zugleich stimmen. Alpar gab jedem Assistenten eine frische, nirgends verlinkte URL, die keine Suchmaschine im Index hatte, also mussten Gemini und Copilot das rohe HTML abrufen wie alle anderen. Gabe testete bestehende Websites, die Google und Bing bereits kannten, sodass Gemini und Copilot auf die von der Suchmaschine gerenderte Fassung zugreifen konnten. Für eine neue Seite gilt, bis eine Suchmaschine sie gerendert hat, das Ergebnis vom Juni. ChatGPT, Claude und Perplexity lasen in beiden Tests nur das HTML.

#Welche KI-Assistenten JavaScript ausführen

Fünf Assistenten gaben die echte Nummer zurück und bewiesen damit, dass sie das Skript ausführten:

• DeepSeek, ERNIE, Qwen und Kimi, alle aus China
• Mistral, aus Europa

DeepSeek steht in dieser Liste für den Chat. Suganthan Mohanadasan prüfte einen anderen Weg desselben Anbieters, die Fetch API der DeepSeek-Suche, und beschrieb den Test am 19. Oktober 2026. Im Rendering-Test lud der Fetcher CSS, führte aber kein JavaScript aus, lud keine Bilder und löste den XHR-Beacon nicht aus, sodass Inhalte, die das Skript brauchten, im Ergebnis fehlten. Er gab sich als Firefox/149.0 aus dem Netz AS136907 (Huawei Cloud, Hongkong) aus, ohne jeden Hinweis auf DeepSeek, und rief URLs ab, die in der robots.txt gesperrt waren. Der ganze Test mit 110 Aufrufen kostete etwa 0,08 USD. Der DeepSeek-Chat und seine API zum Abrufen von Seiten sind schlicht zwei verschiedene Wege zu Ihrem HTML, und in diesen Tests führte nur der Chat das Skript aus.

JavaScript-Rendering durch KI findet also wirklich statt. Nur ist es für die großen westlichen Assistenten, auf die es europäischen Unternehmen tatsächlich ankommt, die Ausnahme beim Live-Abruf, und Gemini und Copilot sehen Inhalte aus JavaScript nur über den Index ihrer Suchmaschine. Die Trennung ist deutlich genug, um sie einzuplanen: Bauen Sie für die Assistenten, die Ihre Kunden nutzen, und die lesen heute HTML.

#Was die Vercel-Studie über KI-Crawler und JavaScript zeigt

Der Test vom Juni 2026 ist nicht die erste Messung in diese Richtung. Im Dezember 2024 veröffentlichte Vercel gemeinsam mit MERJ eine Analyse des KI-Crawler-Verkehrs im eigenen Netzwerk und kam zu dem Schluss, dass “derzeit keiner der großen KI-Crawler JavaScript rendert” (eigene Übersetzung). ChatGPT und Claude riefen zwar JavaScript-Dateien ab, 11,50 % beziehungsweise 23,84 % ihrer Abrufe, führten sie aber nicht aus. Im gemessenen Monat kam GPTBot auf 569 Millionen Abrufe, Claude auf 370 Millionen und PerplexityBot auf 24,4 Millionen, gegenüber 4,5 Milliarden für Googlebot über Gemini und die Suche zusammen. ChatGPT landete bei 34,82 % seiner Abrufe auf 404-Seiten, Claude bei 34,16 %.

Vercel nannte zwei Crawler, die rendern: AppleBot, über einen browserbasierten Crawler ähnlich wie Googlebot, und Gemini, weil es die Infrastruktur von Googlebot nutzt. Der zweite Punkt widerspricht Alpars Ergebnis von 2026, bei dem Gemini den Köder zurückgab. Die beiden Messungen betrachten unterschiedliche Pfade, das Crawling im Hintergrund in Vercels Netzwerk und einen Live-Abruf, den ein Nutzer-Prompt auslöst. Genau diese Lücke ist die Lehre: Ob Google Ihre Seite für den Index rendert, sagt wenig darüber aus, was Gemini liest, während es eine Frage beantwortet. Vercels Empfehlung deckt sich mit dem Rest dieses Artikels: Hauptinhalt, Metadaten und Navigation serverseitig rendern, clientseitiges Rendering für Funktionen behalten, die die Seite nur ergänzen.

#Rendert Google JavaScript anders als KI-Assistenten

Das ist der Einwand, der das ganze Gespräch entgleisen lässt, also begegnen Sie ihm direkt. Ja, Googlebot rendert JavaScript für den klassischen Suchindex. Das ist eine separate Pipeline vom Grounding für KI-Antworten, und im Test geht es um die zweite. Eine Seite kann in der klassischen Google-Suche bestens ranken mit Inhalten, die erst nach Ausführung von JavaScript existieren, und trotzdem unsichtbar sein, wenn ChatGPT oder Perplexity sie abruft, um eine Antwort zu erstellen. “Google rendert JS” als Beweis dafür zu nehmen, dass “KI rendert JS”, ist der Fehler. Die beiden Systeme verhalten sich unterschiedlich, und genau in dieser Lücke versickert die KI-Sichtbarkeit unbemerkt.

#Was Googles Dokumentation zu JavaScript-SEO über das Rendering sagt

Google beschreibt die eigene Pipeline in den Grundlagen zu JavaScript-SEO: JavaScript-Webanwendungen durchlaufen drei Phasen, Crawling, Rendering und Indexierung. Seiten warten in einer Rendering-Warteschlange, bevor ein Headless-Chromium ihr JavaScript ausführt, und laut Google kann eine Seite “einige Sekunden in dieser Warteschlange bleiben, es kann aber auch länger dauern” (eigene Übersetzung). Dieselbe Seite empfiehlt weiterhin serverseitiges Rendering oder Pre-Rendering, weil es für Nutzer und Crawler schneller ist und weil “nicht alle Bots JavaScript ausführen können” (eigene Übersetzung).

Dieser Satz ist die Brücke zu den KI-Assistenten. Google schreibt, dass man JSON-LD per JavaScript erzeugen und in die Seite einfügen kann, und Googlebot liest es nach dem Rendering-Schritt. Alpar testete eine Nummer im sichtbaren Text, keine strukturierten Daten, doch per Skript eingefügtes Schema erreicht einen Assistenten über denselben Mechanismus. Ein Assistent, der das Skript nie ausführt, sieht es also nie. Googles Dokumentation ist für Googlebot geschrieben. Die KI-Antwortschicht ist der Fall “nicht alle Bots”.

Googles eigene Seite zum dynamischen Rendering, zuletzt aktualisiert am 10. Dezember 2025, schließt die Abkürzung aus, Bots zu erkennen und ihnen eine serverseitig gerenderte Kopie auszuliefern, während Nutzer die clientseitige Version sehen. Google nennt das eine Notlösung und empfiehlt sie nicht, weil sie zusätzliche Komplexität und Ressourcen erfordert, und verweist stattdessen auf serverseitiges Rendering, statisches Rendering oder Hydration. Pre-Rendering beim Build, weiter unten erklärt, gehört zum statischen Rendering, also erhält jeder Client, ob Bot oder Browser, dasselbe HTML.

#JavaScript-Muster, die Inhalte vor KI verstecken

Das Risiko konzentriert sich auf eine wiedererkennbare Reihe von Mustern:

• Single-Page-Anwendungen, die eine fast leere HTML-Hülle ausliefern und die Seite im Browser zusammensetzen.
• Preise, Lagerbestände oder Spezifikationen, die nach dem Laden per JavaScript aus einer API eingefügt werden.
• Inhalte, die hinter clientseitigen Tabs, Akkordeons oder “Mehr laden” versteckt sind und erst bei Interaktion nachgeladen werden.
• Produkt- oder Leistungsbeschreibungen, die von einem Client-Framework ohne serverseitige Rückfalllösung gerendert werden.
• Rezensionen, Bewertungen und FAQ-Widgets, die als Drittanbieter-JavaScript eingebettet sind.

Wenn eines davon die Fakten trägt, die eine KI wiedergeben soll, setzen Sie Ihre KI-Sichtbarkeit auf ein Rendering-Verhalten, an dem sechs von sieben westlichen Assistenten gerade gescheitert sind.

#JavaScript-Inhalte für KI sichtbar machen

Das Mittel ist die Regel, die das klassische SEO seit einem Jahrzehnt wiederholt: Bringen Sie die tragenden Fakten in serverseitig gerendertes HTML. Statische Seitengenerierung und serverseitiges Rendering erfüllen sie beide. Das Framework spielt keine Rolle, entscheidend ist, wo das HTML zusammengesetzt wird. Rendern Sie den Inhalt auf dem Server, liefern Sie ihn in der ersten Antwort aus und lassen Sie JavaScript ihn anreichern, statt ihn zu liefern.

Ihre eigene Website prüfen Sie in einer Minute. Rufen Sie eine Seite ohne Browser ab und lesen Sie, was zurückkommt:

curl -s https://ihre-website.example/ihre-seite/ | less

Wenn Überschriften, Fließtext, Preise, Spezifikationen und das Schema.org JSON-LD alle in dieser rohen Antwort stehen, können KI-Assistenten sie lesen. Ist die Seite eine dünne Hülle, die sich erst nach dem Skript füllt, ist das Ihr Problem, und jetzt sehen Sie es.

#Welche User-Agents KI-Assistenten beim Abruf von Seiten nutzen

Die Anbieter dokumentieren getrennte Agenten für Training, Suchindexierung und vom Nutzer ausgelöste Abrufe, und die robots.txt-Regeln unterscheiden sich:

• OpenAI: GPTBot crawlt Inhalte, die zum Training von Basismodellen verwendet werden können, OAI-SearchBot entscheidet, ob eine Website in Suchantworten von ChatGPT erscheinen kann, und ChatGPT-User ruft Seiten für Nutzeraktionen ab. ChatGPT-User wird nicht für automatisches Crawling verwendet, und weil seine Aktionen vom Nutzer ausgehen, gelten robots.txt-Regeln möglicherweise nicht. Jede Einstellung ist unabhängig, und laut OpenAI dauert es etwa 24 Stunden, bis eine robots.txt-Änderung in den Suchergebnissen ankommt.
• Anthropic: ClaudeBot sammelt Trainingsdaten, Claude-SearchBot indexiert für die Suchqualität, und Claude-User ruft Seiten ab, wenn ein Mensch Claude eine Frage stellt. Anthropic gibt an, dass seine Bots robots.txt respektieren, und veröffentlicht die IP-Liste seiner Crawler.
• Perplexity: PerplexityBot zeigt Websites in der Perplexity-Suche an und dient nicht dem Modelltraining. Perplexity-User unterstützt Nutzeraktionen und ignoriert robots.txt in der Regel, weil ein Nutzer den Abruf angefordert hat.
• Google: Google-Extended ist ein Produkt-Token für robots.txt, kein eigener Crawler. Es steuert die Nutzung für das Training von Gemini und für Grounding, hat keinen eigenen HTTP-User-Agent und beeinflusst weder die Aufnahme noch das Ranking in der Google-Suche.

Keine dieser Seiten verspricht JavaScript-Rendering. In einem zweiten Experiment, zu robots.txt, stellte Alpar fest, dass nur 3 von 12 Assistenten eine gesperrte URL in Ruhe ließen: ChatGPT als ChatGPT-User, Claude als Claude-User und Perplexity als Perplexity-User. Gemini kam mit einem nackten User-Agent “Google”, Copilot über Diffbot mit einer gewöhnlichen Chrome-Kennung, und Grok, DeepSeek, Qwen und Kimi mit gefälschten Browser-User-Agents. Die praktische Folge für das Rendering: KI-Assistenten lässt sich per User-Agent-Erkennung keine verlässliche Sonderversion vorgerendert ausliefern. Das HTML, das alle bekommen, muss die Fakten tragen.

#Wie WordPress Inhalte ohne JavaScript für KI ausliefert

Ein klassisches WordPress-Theme steht von Haus aus auf der sicheren Seite: PHP baut die Seite auf dem Server, sodass Beiträge, Produktbeschreibungen und Preise aus der Datenbank im HTML stehen, bevor irgendein Skript läuft. Das Risiko entsteht, wenn Inhalte in clientseitige Widgets wandern, in Blöcke, die Daten nach dem Laden über die REST-API holen, oder in ein Headless-Frontend, das nur im Browser rendert.

Für Interaktivität hat WordPress eine Lösung, die den Inhalt auf dem Server lässt. Die Interactivity API, eingeführt mit WordPress 6.5, nutzt Direktiven im Markup eines Blocks, und ihre serverseitige Verarbeitung der Direktiven lässt WordPress das initiale HTML mit dem richtigen Zustand erzeugen. Die Funktion wp_interactivity_process_directives findet die Direktiven und schreibt das Markup mit der HTML API anhand von Anfangszustand und Kontext um. Im Beispiel aus dem Handbuch verlässt eine Liste mit data-wp-each und data-wp-text den Server als gewöhnliche Listeneinträge, in denen die Obstnamen bereits stehen und keine Direktiven mehr übrig sind. Die Seite kommt vollständig an, JavaScript ergänzt danach das Verhalten, und ein Assistent, der rohes HTML liest, sieht dieselbe Liste wie ein Besucher. Das Handbuch nennt den Grund selbst: Der Ansatz bewahrt “die SEO- und Performance-Vorteile des traditionellen serverseitigen Renderings von WordPress” (eigene Übersetzung).

#Statisches HTML mit Astro für KI-Sichtbarkeit

Wir sind hier nicht neutral, denn wir sind diese Wette bewusst eingegangen. wppoland.com läuft auf Astro, das Seiten zur Build-Zeit zu statischem HTML rendert und sie vom Edge ausliefert. Alles, was zählt, steht in der rohen Antwort: der Fließtext, jede Überschrift, das FAQ und das Schema.org JSON-LD. Wir haben es genauso geprüft wie der Test, indem wir das rohe HTML statt der gerenderten Seite lasen, und der Inhalt ist vollständig da, bevor eine einzige Zeile unseres JavaScripts läuft. JavaScript auf unseren Seiten ist Anreicherung, nie die Quelle des Inhalts.

Das ist dieselbe Schlussfolgerung, zu der wir auf dem langen Weg in Inhalte an KI-Agenten ausliefern gekommen sind: sauberes, serverseitig gerendertes, semantisches HTML plus Schema ist das eine Signal, das sowohl klassische Crawler als auch KI-Systeme tatsächlich konsumieren. Dieser Test ist der bislang sauberste Beweis für diese Position. Er ist auch der Grund, warum ein GEO- und LLMO-Programm damit beginnen muss, wie die Seite gerendert wird, und nicht mit cleveren Metadaten, denn Metadaten, die ein Assistent nie ausführt, liest er auch nie.

#Serverseitiges und clientseitiges Rendering erklärt

Für Leser, die ein Unternehmen führen statt einer Build-Pipeline:

• Serverseitiges Rendering / statische Generierung - das HTML der Seite wird auf dem Server (oder zur Build-Zeit) zusammengesetzt und kommt vollständig in der ersten Antwort an.
• Clientseitiges Rendering - der Server schickt eine fast leere Hülle, und das JavaScript des Browsers baut die Seite danach auf.
• Grounding - wenn ein KI-Assistent echte Seiten abruft, um eine Antwort auf Fakten statt auf Erinnerung zu stützen.
• Hydration - JavaScript, das Interaktivität an bereits gerendertes HTML anhängt; sicher, weil der Inhalt vorher schon da war.
• Pre-Rendering - eine clientseitige Anwendung wird beim Build ausgeführt, um ihren Anfangszustand als statisches HTML festzuhalten, so die Definition im web.dev-Leitfaden Rendering on the Web. Derselbe Leitfaden hält fest, dass Crawler JavaScript verstehen können, “aber beim Rendering oft Einschränkungen haben” (eigene Übersetzung).

#Lohnt es sich, auf JavaScript-Rendering durch KI zu warten

JavaScript-Rendering durch KI-Assistenten wird sich im Laufe der Zeit wahrscheinlich verbessern, und die chinesischen Assistenten plus Mistral zeigen, dass es technisch Routine ist. Aber Sie dürfen nicht für die Assistenten publizieren, die Sie sich wünschen. Sie publizieren für die, die Ihre Kunden nutzen, und im Juni 2026 lesen die größten westlichen Assistenten rohes HTML und hören dort auf. Die sichere, langweilige, jahrzehntealte Antwort erweist sich auch für KI als die richtige: Liefern Sie Ihre Fakten in HTML aus, das der Server bereits gerendert hat, und behandeln Sie alles, was erst nach JavaScript erscheint, als Inhalt, den die KI nicht sehen wird.