Führen KI-Crawler JavaScript aus?

Nein — GPTBot, ClaudeBot und PerplexityBot führen kein JavaScript aus. Sie laden die rohe HTTP-Response und lesen den HTML-Quelltext. Was erst nach JavaScript-Ausführung sichtbar wird, existiert für diese Crawler nicht. Nur Googlebot hat eingeschränkte JS-Rendering-Fähigkeiten, aber auch er priorisiert statisches HTML.

Wie erkenne ich, ob meine Seite nur client-side gerendert wird?

Öffne deine Seite im Browser, klicke Rechtsklick → "Seitenquelltext anzeigen" (nicht Inspect/DevTools). Wenn du nur ein leeres oder wenige Zeilen HTML ohne Inhaltstext siehst, ist deine Seite CSR. Der Quelltext zeigt, was KI-Crawler sehen — nicht was dein Browser nach JS-Ausführung rendert.

Muss ich meine komplette App zu Next.js migrieren?

Nein. Du hast mehrere Optionen: (1) Static Pre-rendering mit react-snap oder Prerender.io — einfachste Lösung, keine Architektur-Änderung. (2) Next.js für öffentliche Seiten, bestehende SPA für Dashboard/App-Teil — hybride Architektur. (3) Prerender-Service wie Netlify oder Cloudflare Pages mit Build-Step. Eine vollständige Migration zu Next.js ist nur nötig, wenn du SSR-Features wie getServerSideProps oder API-Routes brauchst.

Welche Seiten müssen SSR-gerendert sein?

Alle öffentlichen, crawlbaren Seiten: Landing, Pricing, Feature-Seiten, Blog, Glossar, FAQ, About. App-interne Seiten hinter Login (Dashboard, Settings) brauchen kein SSR für GEO — KI-Crawler kommen dort nicht rein. Fokussiere SSR auf die Seiten, die in der Sitemap.xml stehen und von KI zitiert werden sollen.

Verbessert SSR auch das klassische Google-Ranking?

Ja. Obwohl Googlebot JavaScript rendern kann, gibt es eine "Crawl-Budget"-Problematik: Googlebot rendert langsam und priorisiert statischen HTML stark. Seiten mit serverseitig gerendertem HTML werden schneller und vollständiger indexiert. Core Web Vitals (LCP insbesondere) profitieren ebenfalls von SSR, da der Nutzer sofort Inhalte sieht ohne JS-Ladezeit.

GEO-Fehler #5 von 5Server-Side Rendering

Deine App sieht grossartig aus —
KI sieht nur ein leeres Div

GPTBot, ClaudeBot und PerplexityBot führen kein JavaScript aus. Eine reine React-SPA liefert ihnen <div id="root"></div> — und damit nichts. Kein H1, kein Text, kein JSON-LD. Du kannst alle anderen GEO-Optimierungen umsetzen: ohne SSR sind sie unsichtbar.

SSR-Status prüfen Migrationspfade

Was KI-Crawler von deiner SPA sehen

<!DOCTYPE html>
<html><head>
  <title>My App</title>
  <script src="/bundle.js">
</head><body>
  <div id="root"></div>
</body></html>

KI kann nichts extrahieren

Kein H1 · Kein Absatztext · Kein JSON-LD · Kein Meta-Inhalt · Keine Zitierbarkeit

Mit SSR: Vollständiger HTML-Content → KI zitiert, Google indexiert, Perplexity linked

Mechanismus

Wie KI-Crawler tatsächlich arbeiten

GPTBot, ClaudeBot und PerplexityBot sind HTTP-Clients, keine Browser. Sie laden HTML, CSS und manchmal Bilder — aber JavaScript wird nicht ausgeführt. Das ist kein Bug, das ist Design: Crawling-at-Scale mit JS-Rendering würde Milliarden an Rechenkosten bedeuten.

Crawler sind keine Browser

Ein Browser wie Chrome lädt HTML, parst CSS, führt JavaScript aus und wartet bis der DOM vollständig ist. KI-Crawler machen: HTTP GET → rohe HTML-Response lesen → fertig. Der gesamte JS-Schritt fehlt.

Geschwindigkeit ist der Grund

Perplexity crawlt täglich Milliarden von Seiten. Eine einzige Seite mit Headless-Chrome zu rendern kostet 500-2000ms und 100-200MB RAM. Bei Milliarden Seiten ist das schlicht unmöglich — also kein JS.

Googlebot ist die Ausnahme

Googlebot kann JavaScript rendern — aber mit Verzögerung und Budget-Limits. Seiten werden oft zuerst ohne JS gecrawlt (grüner Crawl) und erst später mit JS gerendert. SSR ist trotzdem immer besser.

Crawler

JS-Rendering

Crawl-Frequenz

Datennutzung

SSR nötig?

GPTBot (OpenAI)

Nein

2-4 Wochen

ChatGPT-Training + Browsing

SSR Pflicht

ClaudeBot (Anthropic)

Nein

2-6 Wochen

Claude-Training + Citations

SSR Pflicht

PerplexityBot

Nein

1-7 Tage

Echtzeit-Suche + Quellen

SSR Pflicht

Google-Extended

Eingeschränkt

Täglich

Gemini + AI Overviews

SSR Pflicht

Googlebot

Ja (verzögert)

Täglich

Search-Index + Rankings

Was KI-Crawler wirklich sehen

Der Unterschied ist nicht subtil. CSR liefert eine Hülle, SSR liefert Inhalt.

Client-Side Rendering (CSR)

Was KI-Crawler sehen

1. HTTP Request

GET /produkt

2. Server Response

<!DOCTYPE html>
<html>
<head><title>App</title></head>
<body>
  <div id="root"></div>
  <script src="/bundle.js"></script>
</body>
</html>

3. JS wird geladen

bundle.js (2.4 MB)...

4. React rendert

KI-Crawler wartet nicht

Ergebnis: KI sieht leeres HTML

Keine Texte, keine Produkte, kein Content — nur <div id="root">

Server-Side Rendering (SSR)

Was KI-Crawler sehen

1. HTTP Request

GET /produkt

2. Server rendert React

Node.js + React → HTML

3. Vollständiges HTML

<h1>Pantra — GEO-Audit</h1>
<p>Analysiere wie gut ChatGPT,
Perplexity und Claude deine
Site zitieren...</p>
<meta name="description"
  content="..."/>

4. KI crawlt sofort

Vollständiger Text lesbar 

Ergebnis: KI sieht vollständigen Content

Jede H1, jeder Absatz, jedes JSON-LD ist lesbar

Warum SPAs trotzdem erfolgreich wurden

React, Vue und Angular wurden nicht als SEO-Tools gebaut — sie wurden als App-Frameworks gebaut. Ein CRM, ein Dashboard, ein Projektmanagement-Tool braucht kein SEO. Deshalb ist CSR der Standard für Apps.

Das Problem entsteht, wenn SaaS-Produkte dieselbe CSR-Architektur für ihre öffentlichen Marketing-Seiten nutzen. Dort braucht es SEO und GEO — und dort versagt CSR.

Die Lösung ist fast immer eine hybride Architektur: SSR für öffentliche Seiten (Landing, Pricing, Blog, Docs), CSR für die App selbst (Dashboard, Settings, User-Bereich). Next.js macht genau das möglich.

Der GEO-Kostenrechner

GEO-Potenzial mit CSR0-5%

Mit Static Pre-rendering40-60%

Mit SSR (Next.js SSG)70-85%

Mit SSR + Q&A + JSON-LD85-100%

GEO-Potenzial = Anteil der optimierten Signale, die KI-Crawler tatsächlich sehen können

Diagnose

Wie erkenne ich, ob meine Seite CSR ist?

Die schnellste Methode ist "View Source": Im Browser Rechtsklick → "Seitenquelltext anzeigen". Das zeigt den rohen HTML-Code, den der Server liefert — exakt das, was KI-Crawler sehen.

Nur wenige Zeilen HTML im SourceCSR-Signal

{"<div id="root">"}oder {"<div id="app">"} ohne InhaltCSR-Signal

Mehrere {"<script src="/bundle.js">"} TagsCSR-Signal

H1, Absatztext im Quelltext sichtbarSSR-Signal

Meta-Description mit echtem InhaltSSR-Signal

JSON-LD {"<script type="application/ld+json">"} vorhandenSSR-Signal

Terminal — CSR-Detection
# Methode 1: curl — sieht was KI-Crawler sehen
$ curl -s https://deine-site.com | grep -o '<h1.*>.*</h1>'
# Wenn leer → CSR. Wenn H1-Text erscheint → SSR
# Methode 2: Googlebot-Simulation
$ curl -A "Googlebot/2.1" -s https://deine-site.com | wc -c
# CSR: ~2000 Bytes (leeres HTML). SSR: 20000+ Bytes
# Methode 3: View Source im Browser
Rechtsklick → "Seitenquelltext anzeigen"
CSR: <div id="root"></div> oder <div id="app"></div>
SSR: Vollständiger HTML-Content sichtbar
# Schnell-Check: React DevTools
React DevTools Browser Extension installieren
CSR-Apps werden rot markiert. SSR-Roots grün.

Lösungen

4 Migrationspfade — von einfach bis vollständig

Du musst nicht alles auf einmal migrieren. Wähle den Pfad, der zu deinem Zeitplan, Budget und Tech-Stack passt.

Static Pre-rendering

Aufwand: Niedrig

Generiere statische HTML-Dateien aus deiner bestehenden React-App beim Build-Schritt. Keine Architektur-Änderung nötig.

react-snapPrerender.ioPuppeteer

GEO-Verbesserung85%

Limit: Dynamischer Content (personalisiert, user-spezifisch) nicht abdeckbar.

Ideal für: Marketing-Sites, Landing Pages, Dokumentation

Next.js App Router

Aufwand: Mittel

Migriere öffentliche Seiten zu Next.js Server Components. Dashboard und App-Teil bleiben in bestehender SPA. Hybride Architektur.

Next.js 16React Server ComponentsApp Router

GEO-Verbesserung100%

Limit: Erfordert Refactoring der Route-Struktur und Daten-Fetching.

Ideal für: SaaS-Produkte mit öffentlichem Marketing + privatem Dashboard

Prerender-CDN-Service

Aufwand: Niedrig

Cloudflare Workers oder Vercel Edge Middleware fängt Bot-Requests ab und liefert vorgerenderte HTML-Version. Transparentes Pre-rendering.

Cloudflare WorkersPrerender.ioNetlify

GEO-Verbesserung80%

Limit: Content-Update-Delay: Gecachte Version kann veraltet sein (TTL konfigurierbar).

Ideal für: Bestehende SPAs ohne Migrations-Budget

Nuxt / SvelteKit

Aufwand: Hoch

Full-Rewrite in einem SSR-fähigen Framework. Optimal für langfristige GEO-Strategie, aber kurzfristig teuerste Option.

Nuxt 3SvelteKitRemix

GEO-Verbesserung100%

Limit: Vollständiger Stack-Wechsel — nur für Greenfield oder mit ausreichend Zeit.

Ideal für: Vue/Svelte-Teams mit SSR als strategischem Ziel

Next.js App Router

SSR mit Next.js: der empfohlene Migrationspfad

Next.js 16 mit App Router ist der de-facto Standard für SSR in der React-Welt. Die meisten Lovable-, Bolt- und v0-generierten Apps sind Next.js — SSR ist ein Konfigurationsschritt, keine Migration.

Server Components (Standard in App Router)

app/produkt/page.tsx

// Kein 'use client' → Server Component
// Wird auf dem Server gerendert 

export default async function ProduktPage() {
  // Direkt Datenbank-Calls im Server
  const data = await getProduktData()

  return (
    <main>
      <h1>{data.title}</h1>
      <p>{data.description}</p>
    </main>
  )
}

export async function generateMetadata() {
  return {
    title: 'Produkt | Pantra',
    description: 'Konkrete Meta-Beschreibung...'
  }
}

Keine Konfiguration nötig: App Router-Seiten sind standardmässig Server Components. Kein "use client" = SSR.

Static Site Generation (SSG) — schnellste Option

app/blog/[slug]/page.tsx

// generateStaticParams = SSG
// → HTML bei Build generiert, blitzschnell

export async function generateStaticParams() {
  const posts = await getAllPosts()
  return posts.map(p => ({ slug: p.slug }))
}

export default async function BlogPost({
  params
}: { params: { slug: string } }) {
  const post = await getPost(params.slug)

  return (
    <article>
      <h1>{post.title}</h1>
      {/* Vollständiges HTML beim Crawl  */}
    </article>
  )
}

SSG ist optimal für Blog, Docs, Landing Pages: Pre-gerendert bei Build, via CDN, sofortiger Crawl-Zugriff.

Welche Strategie wann?

Static (SSG)

Blog, Docs, Landing, FAQ — Content ändert sich selten

Server (SSR)

Personalisierte Seiten, Realtime-Daten, User-spezifischer Content

ISR

E-Commerce, Newsportale — oft aktuell, aber nicht jede Request

Common Mistakes bei der Migration

"use client" überall

Macht den Vorteil von Server Components zunichte

Alle Seiten SSR

SSG ist für statischen Content immer performanter

Client-State im Server

useContext, useState gehören in Client Components

Quick Wins ohne vollständige Migration

react-snap

npm i -D react-snap → Build-Step generiert statisches HTML

Prerender Middleware

Vercel/Cloudflare erkennt Bots → liefert gecachtes HTML

OG-Tags serverseitig

Nextjs + express für nur /og/* Routen SSR-fähig machen

Zeitplan

Was passiert nach der SSR-Umstellung?

Sofort

HTML sichtbar

Alle KI-Crawler können deinen Content lesen. JSON-LD, Meta-Tags, H1-Struktur — alles crawlbar.

1-3 Tage

PerplexityBot crawlt

Perplexity crawlt sehr häufig und nimmt neue SSR-Seiten schnell auf. Erste Indexierung wahrscheinlich.

2-6 Wochen

GPTBot + ClaudeBot

OpenAI und Anthropic crawlen alle 2-6 Wochen. Danach kann dein Content in neuen Antworten erscheinen.

2-3 Monate

Google AI Overviews

Google AI Overviews reagiert langsamer — aber mit vollständigem HTML sind alle Voraussetzungen erfüllt.

Pantra SSR-Detection

SSR-Status in 60 Sekunden prüfen

Pantra erkennt beim GEO-Audit automatisch, ob deine Seite server-side gerendert wird, und welcher Content für KI-Crawler sichtbar ist. Inklusive konkretem Migrationspfad wenn nötig.

SSR vs CSR Detection

JS-Abhängigkeiten prüfen

Sichtbarer Content-Anteil

Empfohlener Migrationspfad

Kostenlos scannen

CHF 79/Mo · Kein Trial nötig