Inhalt ohne JavaScript lesbar

Der Hauptinhalt Ihrer Seite – die Absätze, Überschriften, Tabellen und Preise, wegen derer Besucher kommen – muss im HTML enthalten sein, das Ihr Server bei der ersten Anfrage zurückgibt. Verbesserungen per sind in Ordnung. Inhalte, die erst nach Ausführung von JavaScript erscheinen, sind für die meisten KI‑Crawler unsichtbar – und damit auch für die Assistenten, die daraus zitieren.

Im Folgenden nehmen wir an, dass Fernwood seine Marketing‑Site als Single‑Page‑App neu aufgebaut hat. Im Browser wirkt sie vollständig. Der Seitenquelltext zeigt jedoch ein nahezu leeres <div id="root"></div>. Genau diese leere Hülle erhalten GPTBot, ClaudeBot, PerplexityBot und ähnliche Crawler.

Warum das funktioniert

Klassische Suchmaschinen haben dieses Problem weitgehend gelöst: Google rendert JavaScript vor dem Indexieren. Antwortmaschinen jedoch nicht. Die Crawler, die ChatGPT, Claude, Perplexity und ähnliche Systeme versorgen, holen in der Regel nur die rohe HTML‑Antwort und hören dort auf – sie warten nicht auf die Hydration Ihres Frameworks, führen Ihr Bundle nicht aus und folgen keinen clientseitigen Routen. Silktides eigener Crawl‑Vergleich (gerenderte Seite vs. rohes HTML) beruht genau auf diesem Verhalten; siehe Inhalt ohne JavaScript.

Der Ausfall ist leise und vollständig:

Eine Seite, die bei Google gut rankt, kann in KI‑Antworten vollkommen fehlen, weil die Assistenten den Text nie erhalten haben.
Jede andere AEO‑Investition auf dieser Seite – strukturierte Daten, maschinenlesbare Datumsangaben, Answer‑first‑Schreiben – ist wertlos, wenn der Crawler den Inhalt, den diese Signale beschreiben, nie sieht.
Auch menschliche Besucher sehen bei fehlgeschlagenen oder blockierten Skripten dieselbe leere Hülle, und der First Contentful Paint leidet selbst dann, wenn die Skripte schließlich doch erfolgreich sind.

Dies ist ein Problem der Seitenarchitektur, kein Problem der Seitenbearbeitung. Das manuelle Beheben einer einzelnen URL repariert nicht die Vorlage, die die nächsten hundert erzeugt.

So prüfen Sie, was ein Crawler sieht

Bevor Sie etwas ändern, verifizieren Sie das Problem. Drei Wege, vom stärksten zum schwächsten:

Silktides Check. Inhalt ohne JavaScript vergleicht den sinnvollen Body‑Text der gerenderten Seite mit dem rohen HTML, das beim Crawlen erfasst wurde. Es markiert Seiten, bei denen der rohe Text sowohl unter ~10\u00a0% des gerenderten Textes liegt als auch absolut gesehen winzig ist – eine echte leere Hülle, nicht nur eine Seite mit etwas Enhancement.
Quelltext anzeigen, nicht DevTools „Elements“. Im Browser zeigt „Seitenquelltext anzeigen“ das, was der Server gesendet hat. Das Elemente‑Panel zeigt den DOM, nachdem JavaScript gelaufen ist. Steht Ihr Artikeltext in Elemente, fehlt aber im Seitenquelltext, sehen Crawler, die JS überspringen, ihn nicht.
Ohne Browser abrufen. Aus dem Terminal: curl -sL https:\/\/fernwood.example\/pricing | head. Oder nutzen Sie einen reinen Textbrowser. Fehlt die Preistabelle in dieser Ausgabe, fehlt sie auch dem Crawler.

Bestätigen Sie außerdem, dass der Crawler überhaupt zugelassen ist – eine perfekte HTML‑Antwort ist nutzlos, wenn robots.txt den KI‑Crawler blockiert oder eine Firewall ihn de facto aussperrt (KI‑Crawler in der Praxis blockiert).

So beheben Sie das Problem

Wählen Sie den Ansatz, der zu Ihrem Stack passt. Alle drei führen zum selben Ergebnis: Die erste HTML‑Antwort enthält den Inhalt.

1. Serverseitiges Rendering (SSR)

Der Server rendert jede Seite bei der Anfrage zu HTML; JavaScript hydriert anschließend für Interaktivität. Das ist der Standardpfad für Frameworks, die ihn bereits unterstützen:

Next.js – verwenden Sie den App Router mit Server Components oder getServerSideProps / getStaticProps im Pages Router. Liefern Sie keine reine Client‑Wurzel aus, die Inhalte erst nach dem Mount abruft.
Nuxt – Universal/SSR‑Modus (Standard), nicht ssr: false.
Remix, SvelteKit, Astro (SSR‑Modus) und Entsprechungen – gleiche Idee: Die Dokument‑Antwort enthält den Body‑Text.

Daumenregel: Wenn ein useEffect / onMounted‑Fetch den Artikel erst auf die Seite bringt, verlagern Sie diesen Datenabruf auf den Server.

2. Statische Seitengenerierung (SSG)

Bauen Sie Seiten zur Veröffentlichungszeit als reines HTML vor. Ideal für Inhalte, die sich nicht pro Besucher ändern – Blogposts, Dokus, Marketingseiten, Preise. Astro, Eleventy, Hugo, Next.js output: 'export' und Nuxt generate erzeugen Dateien, die ein Crawler ganz ohne JavaScript lesen kann.

SSG ist für Marketing‑ und Content‑Sites meist der günstigste Quick‑Win: keine Renderkosten pro Anfrage, und das HTML auf der Platte ist genau das, was der Crawler erhält.

3. Prerendering als Brücke

Wenn Sie das Framework noch nicht ändern können, kann ein Prerendering‑Dienst oder Build‑Schritt Crawlern (und oft Erstbesuchern) einen gerenderten HTML‑Schnappschuss ausliefern, während die SPA für interaktive Sitzungen weiterläuft. Behandeln Sie dies als Brücke, nicht als Ziel: Aktualität der Snapshots, Cache‑Invalidierung und authentifizierte Routen werden jeweils zu eigenem Wartungsaufwand. Beheben Sie den Rendermodus, sobald es möglich ist.

Googles eigene Hinweise zur JavaScript‑SEO und web.devs Rendering im Web decken dasselbe Spektrum ab – SSR, SSG und progressive Verbesserung – aus Sicht der Suchmaschine.

Was im ersten HTML stehen muss

Nicht jedes Pixel. Der Inhalt, den ein Zitat wiedergeben würde:

Der Artikel‑ bzw. Seiteninhalt – Überschriften, Absätze, Listen, Tabellen.
Preise, Limits und andere Fakten, die Assistenten wiederholen sollen.
Strukturierte Daten in einem <script type="application\/ld+json">‑Block im initialen HTML – JSON‑LD, das erst nach der Hydration injiziert wird, ist so unsichtbar wie der Fließtext.
Kanonische URL, Titel und Meta‑Description im <head>.

JavaScript darf weiterhin Menüs, Personalisierung, Diagramme, die eine bereits vorhandene Tabelle ergänzen, und progressive Funktionen übernehmen. Silktides Check ist bewusst großzügig beim Thema Enhancement: Seiten, die ihren Hauptinhalt als HTML ausliefern und Verhalten obendrauf legen, bestehen.

Häufige Fehlerbilder

Reine Client‑SPAs – Create React App, Vite‑SPAs und ähnliche Setups, die eine leere Hülle ausliefern und Routen im Browser abrufen. Die Lösung ist SSR/SSG, nicht noch mehr Client‑Code.
Inhalte hinter „Mehr laden“ oder Tabs, die nie im HTML erscheinen. Wenn Abschnitt drei nur per Klick erreichbar ist, der ihn nachlädt, erreichen Crawler Abschnitt drei nie. Bevorzugen Sie echte URLs oder liefern Sie den Inhalt in der initialen Antwort mit.
„In Google funktioniert es, also passt es.“ Das Rendern durch Googlebot ersetzt nicht die Lesbarkeit für KI‑Crawler. Bei Google zu bestehen und bei GPTBot zu scheitern ist eine häufige, unsichtbare Trennung.
Den Crawler blockieren und JavaScript die Schuld geben. Prüfen Sie immer Zugriff von KI‑Crawlern und effektive Erreichbarkeit parallel zu dieser Technik.

Wie Silktide hilft

Inhalt ohne JavaScript markiert indexierbare Seiten, deren rohes HTML im Vergleich zur gerenderten Seite nur eine leere Hülle ist.
Zugriff von KI‑Crawlern und KI‑Crawler in der Praxis blockiert decken das verwandte Scheitern ab: Der Crawler erhält das HTML gar nicht erst.

Wenn Silktide Ihre Inhalte ohne JavaScript nicht lesen kann, können es auch die Assistenten nicht, von denen Sie zitiert werden möchten.