Eine der zentralen SEO-Entscheidungen in Next.js ist, wie jede Route gerendert wird. Manche Crawler führen JavaScript aus, andere stützen sich womöglich vor allem auf die ursprüngliche HTML-Antwort. Liegen die wichtigen Inhalte in dieser Antwort, verringert das die Abhängigkeit von den Fähigkeiten eines bestimmten Crawlers.
Eine praktische Regel:
- Statisch (SSG) – Marketingseiten, Dokumentation, Blog. Am schnellsten, am günstigsten, vollständig indexierbar.
- ISR (Incremental Static Regeneration) – Kataloge, Listings, alles, was sich stündlich/täglich ändert. Die Geschwindigkeit von Statik mit kontrollierter Aktualität.
- SSR (dynamisches Rendering) – personalisierte oder wirklich Echtzeit-Seiten. Indexierbar, aber mit langsamerer TTFB.
- CSR (nur Client) – Dashboards und das Innere von Anwendungen. Niemals für Inhalte, die indexiert werden sollen.
// app/blog/[slug]/page.tsx — ISR: statisches HTML, Regeneration stündlich
export const revalidate = 3600;
export async function generateStaticParams() {
const posts = await getPosts();
return posts.map((post) => ({ slug: post.slug }));
}
Prüfen Sie, was der Crawler bekommt – nicht, was Ihr Browser zeigt:
curl -s https://example.com/ihre-seite | grep -i "schluesselphrase"
Fehlen die wichtigen Inhalte in dieser Antwort, können Crawler, die die Seite nicht rendern, sie übergehen.
Vorsicht vor versehentlichem dynamischem Rendering. Der Einsatz von cookies(), headers() oder searchParams auf einer Seite schaltet sie still auf SSR um. Für SEO ist das nicht tödlich, kostet aber TTFB und Serverlast. Diese Fallen haben wir im Artikel Wie der Cache in Next.js mit dem App Router funktioniert ausführlich beschrieben.
Checkliste:
- Jede indexierbare Route ist SSG oder ISR; SSR nur dort, wo Personalisierung es verlangt
-
curlauf das rohe HTML bestätigt, dass der Hauptinhalt vorhanden ist - Keine
cookies()-/headers()-Aufrufe auf Seiten, die statisch sein sollten - Client-Komponenten dienen der Interaktivität, nicht dem Inhalt