Sehen KI Crawler JavaScript Inhalte? So prüfen Sie Ihre Website

Kurz gesagt: Ihre Seite wirkt im Browser vielleicht perfekt, während ein Bot, der nur die erste HTML Antwort liest, eine leere Hülle sieht. Dieser Leitfaden zeigt Ihnen, wie Sie das Problem erkennen, welche Renderingmethode hilft und welche Fakten zuerst ins HTML gehören. Wie Google Skripte im Detail verarbeitet, erklärt unser Leitfaden zu JavaScript SEO.

Was unterscheidet rohes HTML von der gerenderten Seite?

Rohes HTML ist der Text, den Ihr Server in der ersten Antwort schickt. Fragt ein Browser oder ein Bot eine Seite an, erhält er zuerst genau das. Die gerenderte Seite ist dagegen der Zustand, den der Browser nach dem Ausführen der Skripte aufbaut. Beides kann übereinstimmen, doch bei Single Page Applications (SPA) weicht es oft stark ab.

Zum Beispiel enthält die erste Antwort einer Produktseite manchmal nur Titel, Menü und einen leeren Container. Produktname, Beschreibung und technische Daten kommen erst über eine separate Datenanfrage. Besucher merken davon nichts, denn der Browser füllt alles in einem Augenblick auf.

Ein Bot ohne Skriptausführung sieht allerdings nur die erste Antwort. Aus seiner Sicht enthält die Seite also kein Produkt. Ein KI Assistent kann nicht zusammenfassen, zitieren oder empfehlen, was sein Crawler nie gesehen hat.

Wie verarbeitet Google JavaScript Seiten?

Die Dokumentation zu den Grundlagen von JavaScript SEO beschreibt drei Phasen: Crawling, Rendering und Indexierung. Zunächst ruft der Googlebot die URL ab, sofern die robots.txt das erlaubt, liest das HTML und sammelt Links. Danach landet die Seite in einer Renderwarteschlange, in der ein Headless Chromium die Skripte ausführt.

Laut derselben Seite kann eine URL dort Sekunden oder länger warten. Schließlich indexiert Google die Seite auf Basis des gerenderten HTML. Anders gesagt: Google sieht JavaScript Inhalte meist, aber mit Verzögerung und einem zusätzlichen Schritt.

Trotzdem empfiehlt die Dokumentation serverseitiges Rendering oder Prerendering. Als Grund nennt sie die Geschwindigkeit für Nutzer und Crawler. Außerdem steht dort ausdrücklich, dass nicht alle Bots JavaScript ausführen können. Dieser Satz ist der Ausgangspunkt für jeden Plan, der KI Crawler betrifft.

Führen KI Crawler JavaScript aus?

Die ehrliche Antwort lautet: Für jeden Crawler wissen wir es nicht. Viele Anbieter schreiben in ihrer offiziellen Dokumentation nicht, ob ihre Bots Skripte ausführen. Die Crawlerdokumentation von OpenAI beschreibt zum Beispiel OAI-SearchBot, GPTBot und ChatGPT-User samt ihrer Aufgaben. Zum Renderingverhalten sagt sie allerdings nichts.

Betrachten Sie diese Lücke als Designregel und nicht als Rätsel. Die sichere Annahme lautet daher: Ein Crawler führt JavaScript womöglich nicht aus. Lassen Sie wichtige Fakten deshalb nie allein von Skripten abhängen. Auch der Hinweis von Google, dass nicht alle Bots JavaScript ausführen, weist in diese Richtung.

Zudem kann sich das Verhalten ändern. Ein Crawler, der heute keine Skripte ausführt, tut es später vielleicht, oder umgekehrt. Die richtige Strategie besteht also nicht darin, Botverhalten zu raten, sondern Inhalte unter allen Bedingungen lesbar zu halten. Die wichtigsten KI Crawler listen wir in unserem Leitfaden zu KI Crawlern auf.

Wie erkennen Sie, ob Ihre Website betroffen ist?

Der einfachste Test ist der Blick in den Seitenquelltext. Klicken Sie im Browser mit der rechten Maustaste auf die Seite und wählen Sie die Option zur Anzeige des Quelltexts. Diese Ansicht zeigt die erste Antwort des Servers. Sie unterscheidet sich vom Elementbereich der Entwicklertools, denn dieser zeigt den gerenderten Zustand.

1. Öffnen Sie den Seitenquelltext.
2. Suchen Sie nach einigen Wörtern aus Hauptüberschrift und erstem Absatz.
3. Prüfen Sie wichtige Fakten einzeln: Produktname, Erklärung des Preismodells, Adresse, Leistungsbeschreibung.
4. Notieren Sie jeden Fakt, den Sie nicht finden.

Wiederholen Sie den Test dann mit deaktiviertem JavaScript im Browser. Bleibt die Seite leer oder halb leer, erhält ein Crawler ohne Skriptausführung dieselbe Ansicht. Testen Sie außerdem Desktop und Mobilansicht getrennt, denn manche Websites laden mobil andere Komponenten. Dieser Check dauert zwei Minuten und ist oft schneller als ein komplettes technisches Audit.

Diese Prüfung neben Inhalten und Produkt für alle Vorlagen regelmäßig durchzuführen, fällt vielen Teams schwer. Deshalb beginnt unsere Arbeit im Bereich KI SEO mit einer Bestandsaufnahme des rohen HTML je Vorlage. Wenn Sie selbst vorgehen, folgen die nächsten Schritte derselben Reihenfolge.

Mit welchen Werkzeugen prüfen Sie gründlicher?

Der Quelltext ist schnell, deckt aber nur eine Seite ab. Für ein breiteres Bild kombinieren Sie mehrere Methoden:

• URL Prüfung in der Search Console: zeigt, wie Google die Seite gerendert hat, und eignet sich ideal für die Google Seite.
• Einfache Anfrage über die Kommandozeile: lädt die Seite ohne Skripte, sodass Sie die rohe Antwort speichern und durchsuchen können.
• Crawl mit deaktiviertem Rendering: crawlen Sie die ganze Website ohne JavaScript und vergleichen Sie das Ergebnis mit einem Crawl mit Rendering.
• Serverlogs: zeigen, welche URLs KI Crawler abrufen und welche Statuscodes sie erhalten.

Vorlagen mit großem Unterschied in der Wortzahl zwischen beiden Crawls bilden zum Beispiel Ihre Prioritätenliste. So erkennen Sie, wo sich das Problem häuft, ohne jede Seite einzeln zu öffnen.

Welche Fakten gehören für KI Crawler ins rohe HTML?

Sie müssen nicht alles auf einmal umziehen. Beginnen Sie mit den Informationen, die in KI Antworten am meisten nützen. Wir empfehlen diese Reihenfolge:

1. Seitentitel, Hauptüberschrift und einleitender Absatz.
2. Name des Produkts oder der Leistung, Nutzen und Zielgruppe.
3. Firmenname, Adresse, Telefon und Öffnungszeiten.
4. Antworten auf häufige Fragen.
5. Interne Links und die Hauptnavigation.
6. Strukturierte Daten, sofern sie zum sichtbaren Text passen.

Kontaktdaten verdienen besondere Sorgfalt. Sind Sie etwa umgezogen, sollte die neue Adresse im Unternehmensprofil und im rohen HTML Ihrer Website gleich lauten; die Profilseite behandelt unser Leitfaden zur Adressänderung im Google Unternehmensprofil. Achten Sie außerdem darauf, dass Text hinter Tabs oder Schaltern wie „Mehr anzeigen“ bereits in der ersten Antwort steht.

Eine weitere Falle: Manchmal steht der Inhalt zwar im Quelltext, aber nur in einem eingebetteten Datenblock statt als lesbarer Text. Auch dann ist Klartext in Überschriften und Absätzen die sicherere Wahl.

Was unterscheidet serverseitiges, statisches und clientseitiges Rendering?

Der Artikel Rendering on the Web auf web.dev definiert die Grundbegriffe. Serverseitiges Rendering (SSR) führt die Anwendung auf dem Server aus und schickt fertiges HTML an den Browser. Statisches Rendering erzeugt das HTML beim Build als eigene Datei je URL. Clientseitiges Rendering (CSR) baut die Seite dagegen im Browser per Skript auf.

Hydration bedeutet, dass Skripte im Browser einem bereits gelieferten HTML Interaktivität hinzufügen. Der Inhalt steht also von Anfang an da, und Skripte beleben nur Schaltflächen und Formulare.

Welche Renderingmethode sollten Sie wählen?

Die Wahl hängt vom Seitentyp und Ihrer Technik ab. Eine einzige richtige Antwort gibt es nicht, aber eine Entscheidungsreihenfolge hilft:

• Ändern sich Inhalte selten, ist statisches Rendering die einfachste Lösung.
• Ändern sich öffentliche Inhalte häufig, passt serverseitiges Rendering.
• Betreiben Sie bereits eine SPA und dauert ein Umbau lange, überbrückt Prerendering die Zeit.
• Für Bereiche hinter einem Login ist clientseitiges Rendering unproblematisch, denn Crawler sollen diese Inhalte ohnehin nicht sehen.

Für Vue Websites erleichtert zum Beispiel ein Framework wie Nuxt das serverseitige Rendering, wie wir in unserem Beitrag zu Nuxt und Vue SSR erklären. Ein Frameworkwechsel ist allerdings eine große Entscheidung. Messen Sie zuerst, welche Vorlagen tatsächlich scheitern, und konzentrieren Sie sich dann nur auf diese.

Dokumentieren Sie außerdem die gewählte Regel. Kommt eine neue Vorlage hinzu oder ändert sich das Design, gilt dieselbe Regel: Wichtige Inhalte stehen in der ersten Antwort. Sonst macht eine kleine Änderung ein Jahr später die Arbeit unbemerkt zunichte.

Ist dynamisches Rendering noch eine Option?

Dynamisches Rendering liefert Bots vorab gerendertes HTML und Nutzern die normale JavaScript Anwendung. Der Artikel auf web.dev nennt es als Möglichkeit für Websites mit viel JavaScript. Allerdings verlangt dieser Ansatz Sorgfalt.

Bots und Nutzer müssen im Kern denselben Inhalt erhalten. Zeigen Sie Bots anderen Text, andere Preise oder versteckte Keywords, gilt das als Cloaking und kollidiert mit den Spamrichtlinien der Suchmaschinen. Dynamisches Rendering darf somit nur bedeuten, denselben Inhalt mit einer anderen Technik auszuliefern.

Zudem müssen Sie zwei Systeme pflegen. Veraltet der Cache, sehen Bots alte Inhalte. Langfristig ist der Wechsel zu serverseitigem oder statischem Rendering daher meist sauberer. Betrachten Sie dynamisches Rendering als Brücke für eine Übergangszeit.

Ein großer Onlineshop korrigiert zum Beispiel zuerst Kategorie und Produktvorlagen per Prerendering. Danach stellt er diese Vorlagen dauerhaft auf SSR um, sobald die neue Technik bereitsteht.

Kann JavaScript der Grund sein, warum KI Antworten Sie nicht zitieren?

Ja, das ist möglich, aber selten der einzige Grund. Ist Ihre Seite für einen Crawler ohne Skripte leer, kann der Assistent dahinter sie nicht zitieren. Andererseits führen schwache Inhalte, eine Sperre in der robots.txt, langsame Antworten oder klarere Antworten anderer Websites zum selben Ergebnis.

Gehen Sie deshalb der Reihe nach vor. Prüfen Sie erstens, ob der Inhalt im rohen HTML steht. Prüfen Sie zweitens, ob die robots.txt den betreffenden Crawler sperrt. Bestätigen Sie dann in den Serverlogs, dass der Crawler die Seite tatsächlich abruft. Schließlich bewerten Sie, wie klar Ihre Seite die Frage beantwortet.

Weitere mögliche Ursachen haben wir in unserem Beitrag dazu, warum KI Ihre Website nicht zitiert gesammelt. So trennen Sie das JavaScript Problem von anderen Ursachen und investieren Ihre Zeit an der richtigen Stelle.

Was verlangen die KI Funktionen von Google?

Laut der Dokumentation zu KI Funktionen haben AI Overviews und AI Mode keine zusätzlichen technischen Anforderungen. Eine Seite muss indexiert und für ein Snippet geeignet sein. Dieselbe Seite empfiehlt außerdem, wichtige Inhalte als Text anzubieten und das Crawling zu erlauben.

Anders gesagt behandelt Google JavaScript Inhalte in den KI Funktionen genauso wie in der normalen Suche. Gelingt das Rendering, fließt der Inhalt in die Auswahl ein. Scheitert es oder erscheint wichtiger Text erst nach einer Interaktion, besteht das Problem auch hier.

Zudem ist Google nicht Ihr einziges Ziel. Andere Assistenten haben keine vergleichbaren öffentlichen Zusagen zu ihren Crawlern gemacht. Folglich ist rohes HTML der gemeinsame Nenner für alle Oberflächen. Kurz gesagt: Was für Google funktioniert, ist auch für die anderen die sicherste Basis.

Wie wirken Lazy Loading und Infinite Scroll auf KI Crawler?

Lazy Loading lädt Inhalte erst beim Scrollen. Für Bilder ist das sinnvoll. Hängen jedoch Texte oder Produktlisten am Scrollen, erreicht ein Crawler, der nie scrollt, diese Inhalte nicht.

Infinite Scroll birgt ein ähnliches Risiko. Die ersten zehn Produkte einer Kategorieseite stehen vielleicht im HTML, der Rest kommt erst beim Scrollen. Ergreifen Sie in diesem Fall folgende Maßnahmen:

• Bieten Sie neben Infinite Scroll eine Paginierung mit eigener URL je Seite an.
• Binden Sie Textinhalte nicht an Lazy Loading und nutzen Sie es nur für Bilder.
• Halten Sie Text in Tabs und Akkordeons im ersten HTML und lassen Sie Skripte nur die Sichtbarkeit umschalten.
• Verwenden Sie für wichtige Links echte Linkelemente statt Schaltflächen mit Klickereignis.

Laden FAQ Antworten etwa erst nach einem Klick vom Server, sieht der Crawler die Fragen, aber nicht die Antworten. Damit verlieren Sie genau den Inhaltstyp, den KI Antworten am häufigsten zitieren. Dasselbe gilt für Bewertungen aus einem externen Widget, daher sollte zumindest eine Zusammenfassung im ersten HTML stehen.

Was passiert, wenn strukturierte Daten per JavaScript laden?

Manche Websites fügen strukturierte Daten nachträglich über einen Tag Manager oder ein Skript ein. Google kann sie beim Rendering lesen. Ein Crawler ohne Skriptausführung sieht nachträglich eingefügte Daten allerdings nie.

Geben Sie strukturierte Daten deshalb nach Möglichkeit serverseitig in der ersten HTML Antwort aus. Sie sollten außerdem zum sichtbaren Text passen; auch die Dokumentation zu KI Funktionen nennt diese Übereinstimmung als Empfehlung. Was Markup für die KI Sichtbarkeit realistisch leistet, beschreiben wir in unserem Beitrag zu strukturierten Daten für GEO.

Denken Sie daran: Strukturierte Daten ersetzen keinen sichtbaren Inhalt. Hat die Seite Markup, aber keinen Text, erhalten Nutzer und Bots ein unvollständiges Bild. Bringen Sie also zuerst den Text ins HTML und ergänzen Sie dann das Markup.

Welche Rolle spielen Performance und Crawleffizienz?

Schwere Skripte verstecken nicht nur Inhalte, sie verlangsamen auch die Seite. Die Dokumentation von Google nennt Geschwindigkeit als Grund für serverseitiges Rendering oder Prerendering. Eine langsame Seite wirkt auf einen Crawler mit Zeitlimit womöglich unvollständig.

Hängt außerdem der Inhalt jeder Seite an einer eigenen Datenanfrage, muss ein Crawler pro Seite mehrere Anfragen stellen. Auf großen Websites bremst das das Crawling. Daher erleichtert serverseitig vorbereitetes HTML Crawlern und Nutzern gleichermaßen die Arbeit.

Wie JavaScript die Ladezeit beeinflusst und wie Sie optimieren, zeigt unser Leitfaden zur JavaScript Performance. Kurz gesagt löst schnelles, fertiges HTML zwei Probleme zugleich. Eine Seite mit Inhalt in der ersten Antwort zeigt Besuchern außerdem früher etwas Sinnvolles, was auch der Conversion helfen kann; betrachten Sie das jedoch als möglichen Nebeneffekt, nicht als Versprechen.

Wie stören robots.txt und Ressourcensperren das Rendering?

Laut Google rendert Google auf Seiten, die die robots.txt sperrt, kein JavaScript. Ebenso kann selbst ein rendernder Crawler die Seite nicht fertigstellen, wenn Sie Skriptdateien oder Datenendpunkte sperren. Diesen Fehler übersehen viele.

1. Prüfen Sie, dass die robots.txt keine Ordner mit Skripten und Stylesheets sperrt.
2. Stellen Sie sicher, dass der Datenendpunkt für Seiteninhalte erreichbar bleibt.
3. Bestätigen Sie, dass CDN und Firewallregeln legitime Crawler nicht blockieren.
4. Steuern Sie Bots, die Sie ausschließen möchten, bewusst und namentlich.

Liefert eine Sicherheitsregel unbekannten User Agents etwa eine leere Antwort, sieht ein Crawler nichts, selbst wenn Ihr rohes HTML perfekt ist. Schauen Sie deshalb über den Seitencode hinaus auch auf Server und CDN Einstellungen. Diese liegen oft bei verschiedenen Personen, also holen Sie alle an einen Tisch.

Welche Websitetypen trifft das Problem besonders oft?

Nicht jede Website trägt dasselbe Risiko. Aus unserer Praxis sind manche Typen stärker betroffen:

• Firmenwebsites als SPA: Jede Seite öffnet mit derselben leeren Hülle, und Inhalte folgen später.
• Baukastenseiten mit schweren Erweiterungen: Manche Blöcke geben Text nur per Skript aus.
• Headless Shops: Produktdaten stammen aus einem separaten Dienst, und eine falsche Einstellung lässt die erste Antwort leer.
• Buchungs und Terminseiten: Leistungsbeschreibungen erscheinen oft in einem Widget.
• Filialfinder: Die Adressliste erscheint nur über die Karteninteraktion.

Allerdings bedeutet die Zugehörigkeit zu einer Gruppe nicht automatisch ein Problem. Viele moderne Frameworks bieten SSR standardmäßig an. Testen Sie daher, statt zu verallgemeinern. Steht der Inhalt im Quelltext, müssen Sie sich keine Sorgen machen. Fehlt er, genügt oft die Korrektur der einen verantwortlichen Komponente.

Was sagen Sie Ihrem Entwicklungsteam?

Marketing und Entwicklung sprechen oft verschiedene Sprachen. Der Satz „Die KI sieht uns nicht“ gibt Entwicklern keine klare Aufgabe. Formulieren Sie stattdessen eine konkrete, prüfbare Anforderung.

1. Listen Sie betroffene Vorlagen mit Beispiel URLs auf.
2. Nennen Sie die Felder, die jede Vorlage in der ersten HTML Antwort enthalten muss: Überschrift, Beschreibung, Preiserklärung, Adresse, FAQ Antworten.
3. Legen Sie den Abnahmetest fest: Diese Felder bleiben mit deaktiviertem JavaScript lesbar.
4. Stellen Sie klar, dass Design und Interaktion bleiben und sich nur die Auslieferung der Inhalte ändert.
5. Vereinbaren Sie vorab, welchen Test Sie nach der Korrektur gemeinsam durchführen.

So wird aus einer vagen SEO Korrektur eine prüfbare Entwicklungsaufgabe. Zudem kann das Team die passende Lösung für seine Technik wählen. Ein Team entscheidet sich für SSR, ein anderes stellt eine Vorlage auf statische Erzeugung um. Entscheidend ist, dass die Seite den Abnahmetest besteht. Ergänzen Sie außerdem eine Priorität, damit zuerst die Vorlagen mit dem meisten Traffic an die Reihe kommen.

Wie prüfen Sie die Korrektur?

Wiederholen Sie nach der Änderung dieselben Tests. Prüfen Sie, ob wichtige Fakten im Quelltext stehen, ob die Seite ohne JavaScript lesbar bleibt und ob ein Crawl ohne Rendering jetzt höhere Wortzahlen zeigt. Danach sehen Sie mit der URL Prüfung in der Search Console, was Google rendert.

Auf der KI Seite brauchen Sie Geduld. Crawler müssen die Seite erneut besuchen, und Antworten der Assistenten ändern sich nicht sofort. Beobachten Sie in dieser Zeit die Crawlerbesuche in den Serverlogs und stellen Sie Ihre ausgewählten Fragen in festen Abständen.

Halten Sie die Ergebnisse in einer einfachen Tabelle fest: Datum, URL, gefundene Felder im Quelltext und Crawlerbesuche. Einen schnellen Überblick liefert unser Tool zur Prüfung der KI Sichtbarkeit. Kein Werkzeug garantiert jedoch, dass eine Seite in einer KI Antwort erscheint. Die technische Korrektur öffnet die Tür; Inhaltsqualität und Quellenvielfalt entscheiden, ob Sie hindurchgehen.

Reicht Lesbarkeit für eine Empfehlung?

Nein. Wenn Sie das JavaScript Problem lösen, können KI Crawler Sie lesen, empfehlen Sie aber nicht automatisch. Für Empfehlungen brauchen Sie zudem unabhängige Nennungen, echte Bewertungen und einheitliche Markendaten.

Stellen Sie sich beide Aufgaben als Glieder einer Kette vor. Das erste Glied ist technischer Zugang: Inhalt im HTML, Crawler nicht gesperrt, Seite schnell. Das zweite Glied ist Vertrauen: Andere Quellen sagen dasselbe über Sie. Fehlt eines, reißt die Kette.

Das zweite Glied behandeln wir in unserem Leitfaden zu Bestenlisten der KI. Mit der technischen Basis aus diesem Beitrag können Sie dort weitermachen. Also gilt: Werden Sie zuerst lesbar und gewinnen Sie dann Vertrauen, denn Inhaltsarbeit auf einer Seite, die kein Crawler sieht, bleibt unsichtbar.

Was prüfen Sie diese Woche?

Die folgende Checkliste teilt die Korrektur in kleine Schritte:

1. Wählen Sie Ihre fünf wichtigsten Vorlagen: Startseite, Leistung, Produkt, Kategorie, Blog.
2. Öffnen Sie jeweils den Quelltext und suchen Sie wichtige Fakten.
3. Rufen Sie jede Seite ohne JavaScript auf und notieren Sie Lücken.
4. Führen Sie einen Crawl ohne und einen mit Rendering durch und vergleichen Sie die Wortzahlen.
5. Prüfen Sie robots.txt, CDN und Firewallregeln.
6. Planen Sie, welche fehlenden Fakten in welcher Reihenfolge ins rohe HTML wandern.
7. Wiederholen Sie nach der Korrektur dieselben Tests und halten Sie die Ergebnisse fest.

Ein Beispielszenario: Ein Dienstleister stellt fest, dass seine Leistungsbeschreibungen nur per Skript laden. Er stellt die Leistungsvorlage auf SSR um, schreibt die FAQ Antworten ins HTML und beobachtet die Crawlerbesuche in den Logs. Spätere Prüfungen zeigen dann, was die Änderung bewirkt hat.

Mit wem sollten Sie diese Arbeit angehen?

Bei einfachen Websites können Sie die Tests selbst durchführen, und für die ersten Prüfungen brauchen Sie kein kostenpflichtiges Werkzeug. Renderingmethode ändern, Vorlagen umbauen und Ergebnisse verfolgen kostet allerdings Zeit von Entwicklung und SEO. Die Brücke zwischen beiden Teams ist oft der schwierigste Teil.

Die GEO Optimierung von Talha Aslan und Team verbindet Bestandsaufnahme des rohen HTML, Empfehlung zum Rendering, Prüfung des Crawlerzugangs und Messung in einem Plan. Rankings oder Zitate garantieren wir nicht. Stattdessen legen wir offen, was wir ändern, warum, und welche Kennzahl wir beobachten. Egal welchen Weg Sie wählen: Wichtige Fakten im HTML sind für jede KI Oberfläche ein solider Start.