Unsere Seite basiert auf React mit clientseitigem Rendering. Wir haben großartige Inhalte, aber eine miserable Sichtbarkeit in der KI.
Was passiert:
Mein Verdacht: AI-Crawler führen kein JavaScript aus und sehen daher nur leere Hüllen.
Fragen:
Suche Entwickler-Lösungen dafür.
Dein Verdacht stimmt. Die meisten AI-Crawler führen KEIN JavaScript aus.
Wie verschiedene Crawler mit JS umgehen:
| Crawler | JavaScript-Ausführung | Was sie sehen |
|---|---|---|
| GPTBot (ChatGPT) | Nein | Nur Raw HTML |
| PerplexityBot | Nein | Nur Raw HTML |
| ClaudeBot | Nein | Nur Raw HTML |
| Google-Extended | Nein | Nur Raw HTML |
| Googlebot | Ja | Gerenderte Seite |
Warum das wichtig ist: Wenn dein Inhalt durch clientseitiges JS gerendert wird, sehen AI-Crawler:
<div id="app"></div>
Nicht den eigentlichen Inhalt.
Die Lösungs-Hierarchie:
Deine React-App kann all das umsetzen. Mit Next.js ist SSR/SSG recht einfach.
SSR/Next.js-Umsetzung für AI-Sichtbarkeit:
Grundvoraussetzung: Inhalt muss in der initialen HTML-Antwort stehen. getServerSideProps oder getStaticProps in Next.js sorgt dafür.
Zusätzliche Optimierungen:
Schema im servergerenderten HTML
// In der Page-Komponente
<script type="application/ld+json">
{JSON.stringify(schemaData)}
</script>
Kritische Inhalte früh im DOM
robots.txt erlaubt AI-Bots
User-agent: GPTBot
Allow: /
User-agent: PerplexityBot
Allow: /
Schnelle Initialantwort
Testen:
curl -A "GPTBot" https://deineseite.com/page
Ist der Inhalt in der Antwort, passt es. Wenn nicht, funktioniert SSR nicht richtig.
Migration lohnt sich. Wir haben Kunden gesehen, die nach SSR-Implementierung von 0 auf signifikante AI-Sichtbarkeit gestiegen sind.
Wir haben genau diese Migration gemacht. Hier die Praxiserfahrung:
Vorher (React SPA):
Nachher (Next.js SSR):
Tipps zur Umsetzung:
App Router mit Server Components verwenden Standard ist SSR – Inhalte funktionieren direkt
Datenbeschaffung serverseitig
// Läuft auf dem Server, Inhalt im HTML
async function Page() {
const data = await fetch('...');
return <Article data={data} />;
}
Kein ‘use client’ für Inhalts-Komponenten Client-Komponenten nur für Interaktivität
Metadata API für SEO/AI
export const metadata = {
title: '...',
description: '...',
};
Migrationsaufwand: Ca. 3 Wochen für eine mittelgroße Seite. Jede Stunde wert.
Ergebnis: Erste AI-Zitate innerhalb von 6 Wochen nach SSR-Launch.
Wenn Migration nicht möglich ist, ist Prerendering eine Option:
Was Prerendering macht:
Beliebte Dienste:
Implementierung: Middleware erkennt Bot-User-Agents und leitet an Prerender-Service weiter.
Vorteile:
Nachteile:
Wann nutzen:
Wann NICHT nutzen:
Prerendering ist eine Übergangslösung, keine ideale Langzeitstrategie.
Framework-Optionen für AI-freundliche Seiten:
| Framework | Standard-Rendering | AI-Sichtbarkeit | Aufwand |
|---|---|---|---|
| Next.js | SSR/SSG | Exzellent | Mittel |
| Nuxt.js | SSR/SSG | Exzellent | Mittel |
| Gatsby | SSG | Exzellent | Niedrig |
| Remix | SSR | Exzellent | Mittel |
| SvelteKit | SSR/SSG | Exzellent | Niedrig |
| Pure React | CSR | Schlecht | - |
| Pure Vue | CSR | Schlecht | - |
| Angular | CSR (Standard) | Schlecht | - |
Empfehlung nach Situation:
Für AI-Sichtbarkeit funktioniert alles mit SSR/SSG. Reines Client-Rendering hingegen nicht.
Hybrides Rendering für komplexe Apps:
Die Herausforderung: Manche Teile deiner App BRAUCHEN clientseitiges Rendering (Dashboards, interaktive Tools). Aber Inhalte benötigen SSR.
Lösung: Hybrides Rendering
Inhaltsseiten: Volles SSR
Interaktive Features: Clientseitig
Next.js App Router macht das leicht:
Beispielstruktur:
// Seite wird servergerendert
export default function Page() {
return (
<>
<ServerRenderedContent /> {/* Das sieht die KI */}
<ClientInteractiveWidget /> {/* Das muss KI nicht sehen */}
</>
);
}
Das Prinzip: Alles, was von KI gesehen werden soll: Server-rendern. Alles andere: Clientseitig ist okay.
Testen, ob deine Inhalte AI-sichtbar sind:
Methode 1: Quelltext anzeigen
<div id="root"></div> = AI sieht ihn nichtMethode 2: JavaScript deaktivieren
Methode 3: curl-Test
curl -A "GPTBot" https://deineseite.com/page | grep "dein Inhalt"
Kommt der Inhalt zurück, ist alles okay.
Methode 4: Google Rich Results Test
Nach SSR-Umsetzung: Alle Tests nochmal durchführen. Inhalt muss überall sichtbar sein.
Tipp: Monitoring einrichten, um Regressionen zu erkennen. SSR kann unbemerkt ausfallen.
Performance-Aspekte bei SSR:
SSR erhöht die Serverlast:
Strategien zur Minderung:
Statische Generierung wo möglich
Incremental Static Regeneration (ISR)
Edge-Rendering
Caching-Ebenen
Das Trade-off: SSR kostet mehr Compute, bringt aber AI-Sichtbarkeit. Für die meisten Unternehmen lohnt sich das Investment.
Monitoring: TTFB nach SSR-Einsatz beobachten. Wenn zu langsam, laufen Bots evtl. vor Content-Übergabe in ein Timeout.
Das bestätigt das Problem und liefert klare Lösungen. Unser Maßnahmenplan:
Sofort (diese Woche):
Kurzfristig (nächstes Quartal):
Umsetzungsansatz:
Technische Entscheidungen:
Testplan:
Wichtigste Erkenntnis: Clientseitiges Rendering = unsichtbar für AI. SSR/SSG = sichtbar. Die Migration ist für AI-Sichtbarkeit unumgänglich.
Danke an alle – der Weg ist jetzt klar!
Get personalized help from our team. We'll respond within 24 hours.
Verfolgen Sie, ob Ihre Inhalte von AI-Plattformen gefunden und zitiert werden – unabhängig von Ihrem Tech-Stack.
Community-Diskussion zur Optimierung von Single Page Applications für KI-Suchmaschinen. Reale Lösungen, damit JavaScript-lastige Websites für ChatGPT, Perplexit...
Community-Diskussion über das JavaScript-Rendering von KI-Crawlern. Entwickler teilen Erfahrungen mit React, Next.js und anderen JS-Frameworks für KI-Sichtbarke...
Community-Diskussion über Pre-Rendering für KI-Sichtbarkeit. Entwickler teilen Erfahrungen mit JavaScript-Frameworks und der Zugänglichkeit für KI-Crawler.