SSR vs CSR für AI-Crawlability – wir haben gewechselt und sahen eine 2-fache Verbesserung bei AI-Zitaten. Hier sind die Daten

Ich habe an Crawler-Infrastruktur gearbeitet. Ich erkläre, warum das passiert.

Wie verschiedene Crawler mit JavaScript umgehen:

Warum AI-Bots oft auf JS verzichten:

1. Skalierung – Billionen Seiten zu rendern ist teuer
2. Geschwindigkeit – JS erhöht die Latenz
3. Zuverlässigkeit – JS kann scheitern, Timeouts passieren
4. Einfachheit – HTML-first ist einfacher

Die praktische Auswirkung:

Wenn Ihre Inhalte JavaScript benötigen, um angezeigt zu werden, sind sie möglicherweise nicht im AI-Trainingsdatensatz enthalten. Für deren Modelle existieren sie wortwörtlich nicht.

SSR löst das vollständig.

HTML in der Antwort = garantierte Zugänglichkeit.

Statische Seitengenerierung (SSG) ist für AI-Sichtbarkeit sogar noch besser.

Warum SSG gewinnt:

• 100% der Inhalte sind HTML
• Kein Server-Side Rendering notwendig
• Blitzschnelle Ladezeiten
• Perfekte Cachebarkeit
• Maximale Zugänglichkeit für Crawler

Was wir nutzen:

• Hugo für die Marketingseite (5.000 Seiten)
• Build bei Bereitstellung
• Weltweit per CDN verteilt

AI-Crawlability: 100%

Jede Seite ist reines HTML. Jeder AI-Bot hat Zugriff auf alles.

Der Kompromiss:

SSG eignet sich für Inhalte, die sich nicht pro Anfrage ändern. Für dynamische Inhalte (User-Dashboards, Personalisierung) braucht man SSR oder Hybrid.

Unsere Empfehlung:

• Marketing-Inhalte → SSG
• Blog/Dokumentation → SSG
• E-Commerce → SSR
• Apps → Hybrid (SSR für kritische Inhalte, CSR für Interaktionen)

Wählen Sie das passende Werkzeug für jeden Inhaltstyp.

Performance-Perspektive auf SSR für AI:

Core Web Vitals Verbesserungen:

SSR verbessert typischerweise:

• LCP (Largest Contentful Paint) – Inhalte schneller sichtbar
• FID/INP – Weniger JS blockiert den Main Thread
• CLS – Layout stabiler

Warum das für AI zählt:

1. Google nutzt CWV als Ranking-Faktor
2. Bessere UX-Signale = mehr Autorität
3. Schnellere Seiten = besseres Crawler-Erlebnis

Unsere Kundendaten:

Die Korrelation bei AI-Sichtbarkeit:

Seiten mit besseren CWV haben tendenziell mehr AI-Zitate. Vermutlich weil:

• Gleiche Qualitäts-Signale
• Besseres Crawler-Erlebnis
• Höhere Gesamt-Autorität

SSR ist ein Win-win: bessere Performance UND bessere AI-Zugänglichkeit.

Enterprise-Perspektive auf Rendering-Architektur:

Die Komplexität:

Große Seiten haben gemischte Anforderungen:

• Marketingseiten (Content-Fokus)
• Produktkatalog (dynamische Daten)
• Nutzerkonten (personalisiert)
• Dokumentation (Referenzinhalte)

Unser hybrider Ansatz:

Seitentyp              → Rendering-Strategie
Marketing              → SSG (Build-Time)
Blog/Doku              → ISR (inkrementell statisch)
Produktseiten          → SSR (dynamische Daten)
Benutzer-Dashboard     → CSR (authentifiziert)

Implementierung mit Next.js:

// Marketing - getStaticProps (SSG)
// Produkte - getServerSideProps (SSR)
// Dashboard - nur clientseitig

AI-Sichtbarkeit je Bereich:

Die wichtigste Erkenntnis:

Rendering-Strategie auf den Inhalt abstimmen. Nicht alles braucht SSR, aber kritische Inhalte schon.

So prüfen Sie Ihr Rendering für AI:

Schnelltest:

1. JavaScript im Browser deaktivieren
2. Seite laden
3. Sind die Inhalte sichtbar?

Wenn nein → AI-Bots sehen sie vermutlich auch nicht.

Technischer Audit:

curl -A "custom-bot" https://ihreseite.de/seite | grep "Ihr Inhalt"

Wenn Inhalt nicht in der Antwort → Problem.

Tools:

• Chrome DevTools → JS deaktivieren
• Google Search Console → URL-Inspektion
• Screaming Frog → JavaScript-Rendering-Modus
• Am I Cited → AI-Sichtbarkeits-Korrelation

Das Muster, das wir sehen:

Seiten mit CSR haben oft:

• Gute Google-Rankings (rendert JS)
• Schlechte Bing-Rankings (JS-Unterstützung variiert)
• Schlechte AI-Zitate (Bots rendern kein JS)

Wenn Ihre Google-Rankings nicht zur AI-Sichtbarkeit passen, könnte das Rendering die Ursache sein.

Framework-Empfehlungen für AI-freundliches Rendering:

Beste Wahl für SSR:

Für statische Seiten:

Migrationspfad-Empfehlungen:

Von React SPA → Next.js (einfachste Migration) Von Vue SPA → Nuxt (einfachste Migration) Von Grund auf → Astro (flexibelste Lösung) Inhaltslastig → Hugo oder 11ty (schnellste Builds)

Der häufigste Fehler:

Fügen Sie Prerendering nicht nur nachträglich hinzu. Planen Sie die Inhaltsarchitektur von Anfang an für SSR.

Tolle Diskussion. Hier mein Fazit:

Das Rendering-Entscheidungs-Framework:

Für AI-Sichtbarkeit brauchen Sie HTML-Inhalte, die ohne JavaScript zugänglich sind.

Optionen nach AI-Zugänglichkeit:

1. SSG (Static Site Generation) – Am besten. 100% HTML bei Build-Zeit.
2. SSR (Server-Side Rendering) – Exzellent. HTML bei jeder Anfrage generiert.
3. ISR (Incremental Static Regeneration) – Sehr gut. Hybrid-Ansatz.
4. Dynamisches Rendering – Gut. SSR für Bots, CSR für Nutzer.
5. CSR mit Prerendering – Okay. Benötigt Konfiguration.
6. Reines CSR – Schlecht. Viele AI-Bots können Inhalte nicht erreichen.

Migrations-Prioritäten:

1. Inhaltsseiten (Blog, Doku, Marketing) – Höchste Priorität
2. Produkt-/Leistungsseiten – Hohe Priorität
3. Kategorie-/Listen-Seiten – Mittlere Priorität
4. Nutzerbezogene Seiten – N/A (nicht für AI relevant)

Technische Checkliste:

• Inhalte sichtbar bei deaktiviertem JS
• curl-Antwort enthält Inhalte
• Crawl-Tools zeigen vollständige Inhalte
• Am I Cited zeigt AI-Sichtbarkeit
• Keine Hydrations-Unstimmigkeiten

Unsere 2-fache Verbesserung kam durch nur eine Änderung: Inhalte im HTML-Response statt via JavaScript zugänglich machen.

Wenn Sie trotz guter Inhalte keine AI-Zitate erhalten, prüfen Sie Ihr Rendering.

Danke an alle für die technischen Einblicke!