SEO für Next.js: Rendering, Metadaten und Indexierung richtig umsetzen

Next.js ist eine sehr gute Grundlage für SEO, solange Ihre Seiten fertiges HTML ausliefern. Google soll Inhalte, Title, Description, Canonical und strukturierte Daten schon in der ersten Serverantwort finden und nicht erst, wenn im Browser JavaScript gelaufen ist. Laut der offiziellen Next.js-Lektion zu Rendering-Strategien liefern statische Generierung (SSG) und serverseitiges Rendering (SSR) genau dieses vorgerenderte HTML. Reines clientseitiges Rendering (CSR) wird für optimales SEO dagegen nicht empfohlen. Der Rest ist Handwerk: Metadata API, sitemap.ts, robots.ts, JSON-LD, Performance und eine saubere Prüfung der Indexierbarkeit. In diesem Leitfaden zeigen wir jeden Schritt für den App Router, mit Codebeispielen und den Fehlern, die wir in Audits am häufigsten finden.

Kurz gesagt

• Rendering entscheidet: SSG, ISR und SSR liefern Google fertiges HTML. Inhalte, die nur per CSR entstehen, sind für SEO die schwächste Wahl.
• Metadaten gehören in die Metadata API: Statische Seiten nutzen das metadata-Objekt, dynamische Seiten die Funktion generateMetadata. Dort setzen Sie auch den Canonical.
• Sitemap und robots.txt entstehen aus Code: Mit app/sitemap.ts und app/robots.ts bleiben beide Dateien bei jedem Deployment aktuell.
• JSON-LD muss im Server-HTML stehen: Strukturierte Daten, die erst nachträglich per JavaScript eingefügt werden, sind für Google riskant.
• Prüfen statt hoffen: Quelltext, URL-Prüfung in der Search Console und ein Crawl zeigen, was Google wirklich sieht.

Inhaltsverzeichnis

• Warum Next.js eine starke Basis für SEO ist
• SSR, SSG, ISR und CSR: Welches Rendering Google sieht
• Title, Description und Canonical mit der Metadata API
• Sitemap und robots.txt direkt aus dem Code
• Strukturierte Daten mit JSON-LD
• Ladezeit und Core Web Vitals
• Häufige SEO-Fehler in Next.js-Projekten
• Unsere Sicht: Next.js-SEO ist eine Frage der Priorisierung
• Next.js-SEO mit einem Ansprechpartner umsetzen
• Häufige Fragen zu SEO mit Next.js
• Quellen

Warum Next.js eine starke Basis für SEO ist

Viele Unternehmen kommen zu Next.js, weil ihre React-Anwendung bei Google kaum sichtbar ist. Eine klassische Single-Page-App schickt dem Crawler eine fast leere HTML-Hülle, und alles Weitere baut der Browser per JavaScript auf. Google kann JavaScript zwar rendern, aber das kostet Zeit und Ressourcen und geht nicht immer gut. Was dabei schiefgehen kann, haben wir im Beitrag zu SEO für React ausführlich beschrieben.

Next.js löst dieses Problem an der Wurzel. Die Next.js-Dokumentation zu Rendering-Strategien hält fest, dass Seiteninhalte und Metadaten für SEO beim Laden verfügbar sein sollten, ohne dass JavaScript ausgeführt werden muss. Das Framework macht genau das zum Standard: Im App Router sind Komponenten standardmäßig Server Components. Ihr HTML entsteht also auf dem Server oder beim Build.

Dazu kommen Bausteine, die sonst mühsam selbst gebaut werden müssten: eine eingebaute Metadaten-Verwaltung, Dateikonventionen für Sitemap, robots.txt und Open-Graph-Bilder sowie eigene Komponenten für Bilder, Schriften und Skripte, die Ladezeit und Layoutstabilität verbessern. Ein Selbstläufer ist Next.js trotzdem nicht. Eine falsch konfigurierte Seite rankt mit Next.js genauso schlecht wie mit jeder anderen Technik. Der Vorteil liegt darin, dass sich die richtigen Entscheidungen sauber im Code festhalten lassen.

SSR, SSG, ISR und CSR: Welches Rendering Google sieht

Die wichtigste SEO-Entscheidung in einem Next.js-Projekt ist die Rendering-Strategie pro Seitentyp. Sie bestimmt, was der Crawler beim ersten Abruf erhält.

Laut Next.js eignen sich SSG und SSR gut für SEO. ISR erlaubt es, statische Seiten nach dem Build zu erstellen oder zu aktualisieren und so die Vorteile statischer Seiten auf Millionen von URLs zu übertragen. Für einen B2B-Shop mit Tausenden Artikeln oder eine Wissensdatenbank ist ISR deshalb oft der beste Kompromiss: schnell wie statisch, aber ohne kompletten Rebuild bei jeder Änderung.

Praxisregel für die Wahl

1. Alles, was ranken soll, wird vorgerendert. Leistungsseiten, Kategorien, Produkte, Ratgeber: SSG oder ISR.
2. SSR nur, wenn Aktualität pro Anfrage zählt. Zum Beispiel bei Verfügbarkeiten oder Preisen, die sich minütlich ändern.
3. CSR nur für Bereiche, die nicht in den Index sollen. Kundenportale, Konfiguratoren hinter Login, interne Tools.
4. Client Components gezielt einsetzen. Interaktive Elemente wie Filter oder Tabs dürfen Client Components sein. Der Kerninhalt der Seite sollte trotzdem serverseitig im HTML stehen.

Ein häufiges Muster in Audits: Ein Team markiert eine komplette Seite mit "use client" und lädt den Text per useEffect aus einer API. Technisch läuft die Seite, aber im Quelltext steht kein einziger Absatz. Für Google ist das wieder eine leere Hülle.

Title, Description und Canonical mit der Metadata API

Im App Router verwalten Sie Metadaten über die Metadata API von Next.js. Dafür gibt es zwei Wege: ein statisches metadata-Objekt oder die dynamische Funktion generateMetadata. Das frühere Hantieren mit eigenen Head-Komponenten oder Zusatzpaketen wie next-seo ist im App Router in der Regel nicht mehr nötig.

Statische Seiten

Für eine Leistungsseite mit festem Inhalt reicht das Objekt:

// app/leistungen/page.tsx
import type { Metadata } from 'next'

export const metadata: Metadata = {
  title: 'Technical SEO für B2B-Unternehmen',
  description: 'Indexierung, Performance und Architektur: priorisiert und messbar.',
  alternates: { canonical: '/leistungen' },
}

Dynamische Seiten

Für Blogartikel, Produkte oder Kategorien erzeugen Sie die Werte aus Ihren Daten:

// app/blog/[slug]/page.tsx
export async function generateMetadata({ params }) {
  const { slug } = await params
  const post = await getPost(slug)
  return {
    title: post.seoTitle,
    description: post.excerpt,
    alternates: { canonical: `/blog/${slug}` },
    openGraph: { title: post.seoTitle, images: [post.coverImage] },
  }
}

Worauf es bei den Metadaten ankommt

• metadataBase im Root-Layout setzen. Dann werden relative Canonicals und Open-Graph-URLs zur vollständigen Domain ergänzt.
• Title-Template nutzen. Im Root-Layout definieren Sie zum Beispiel title: { template: '%s | Firmenname', default: 'Firmenname' }. Jede Seite liefert nur noch ihren eigenen Teil.
• Jede indexierbare Seite bekommt einen eigenen Title und eine eigene Description. Doppelte Titles über Hunderte Produktseiten sind einer der häufigsten Befunde.
• Canonical immer selbstreferenzierend. Gerade bei Filter- und Sortierparametern (?sort=preis) verhindert der Canonical, dass Google Varianten als eigene Seiten behandelt.
• noindex bewusst setzen. Über robots: { index: false } in den Metadaten schließen Sie interne Suchergebnisse, Danke-Seiten oder Testseiten aus.

Sitemap und robots.txt direkt aus dem Code

Mit den Dateikonventionen app/sitemap.ts und app/robots.ts erzeugt Next.js beide Dateien programmatisch. Der große Vorteil: Die Sitemap entsteht aus denselben Daten wie Ihre Seiten und ist nach jeder Veröffentlichung automatisch aktuell. Niemand muss eine XML-Datei von Hand pflegen.

// app/sitemap.ts
import type { MetadataRoute } from 'next'

export default async function sitemap(): Promise<MetadataRoute.Sitemap> {
  const posts = await getAllPosts()
  return [
    { url: 'https://www.beispiel.de', lastModified: new Date() },
    ...posts.map((p) => ({
      url: `https://www.beispiel.de/blog/${p.slug}`,
      lastModified: p.updatedAt,
    })),
  ]
}

// app/robots.ts
import type { MetadataRoute } from 'next'

export default function robots(): MetadataRoute.Robots {
  return {
    rules: { userAgent: '*', allow: '/', disallow: ['/konto/', '/api/'] },
    sitemap: 'https://www.beispiel.de/sitemap.xml',
  }
}

Zwei Punkte verdienen besondere Aufmerksamkeit. Erstens: Blockieren Sie niemals den Ordner /_next/. Dort liegen JavaScript, CSS und Bilder, die Google zum Rendern Ihrer Seiten braucht. Zweitens: In die Sitemap gehören nur URLs, die indexierbar sind, einen Statuscode 200 liefern und auf sich selbst kanonisiert sind. Eine Sitemap voller Weiterleitungen oder noindex-Seiten sendet widersprüchliche Signale. Mehr zur Steuerung des Crawlings lesen Sie in unserem Beitrag zur robots.txt für SEO.

Bei sehr großen Websites mit Zehntausenden URLs lohnt es sich, die Sitemap aufzuteilen, etwa nach Produkten, Kategorien und Ratgebern. Next.js unterstützt das mit der Funktion generateSitemaps. So sehen Sie in der Search Console auch getrennt, welcher Seitentyp Indexierungsprobleme hat.

Strukturierte Daten mit JSON-LD

Strukturierte Daten helfen Google, Ihre Inhalte einzuordnen: Organisation, Produkte, Artikel, FAQs, Breadcrumbs. Google empfiehlt dafür das Format JSON-LD. Laut der Google-Hilfe zu strukturierten Daten muss das Markup in der HTML-Datei stehen, die der Webserver zurückgibt. Es darf nicht erst nach dem Laden der Seite per JavaScript erzeugt werden.

Für Next.js heißt das: Bauen Sie das JSON-LD in einer Server Component. Sie erzeugen ein JavaScript-Objekt aus Ihren Daten und geben es als Skript vom Typ application/ld+json direkt in der Seite aus. Weil die Komponente auf dem Server rendert, steht das Markup im ersten HTML.

// in app/produkte/[slug]/page.tsx
const jsonLd = {
  '@context': 'https://schema.org',
  '@type': 'Product',
  name: produkt.name,
  description: produkt.kurzbeschreibung,
  offers: {
    '@type': 'Offer',
    price: produkt.preis,
    priceCurrency: 'EUR',
    availability: 'https://schema.org/InStock',
  },
}

Typische Fehler bei strukturierten Daten in Next.js-Projekten:

• Einbau über einen Tag-Manager oder eine Client Component. Dann fehlt das Markup im Quelltext.
• Daten, die nicht zum sichtbaren Inhalt passen. Preise oder Bewertungen im Markup müssen mit dem übereinstimmen, was Nutzer auf der Seite sehen.
• Ein globales Schema für alle Seiten. Das Organisations-Markup gehört ins Layout, Produkt- oder Artikel-Markup auf die jeweilige Seite.

Strukturierte Daten sind auch für die Sichtbarkeit in KI-gestützten Suchergebnissen relevant, weil sie Inhalte maschinenlesbar machen. Wie Sie sich dort aufstellen, beschreiben wir im Beitrag zu SGE SEO.

Ladezeit und Core Web Vitals

Die Core Web Vitals messen drei Dinge: wie schnell der größte sichtbare Inhalt lädt (LCP), wie schnell die Seite auf Eingaben reagiert (INP) und wie stabil das Layout beim Laden bleibt (CLS). Next.js nimmt Ihnen hier viel ab, aber nicht alles. Welche Rolle die Ladezeit für Ihr Ranking wirklich spielt, ordnen wir im Beitrag zu Seitenladezeit und SEO ein.

Die wirksamsten Hebel in Next.js-Projekten:

1. Bilder mit der Image-Komponente ausliefern. Feste Breiten und Höhen verhindern Layoutsprünge. Das Hero-Bild bekommt die Priorität beim Laden, alles darunter wird nachgeladen.
2. Schriften über next/font einbinden. Die Schriften werden selbst gehostet, und unschöne Sprünge beim Schriftwechsel entfallen.
3. Drittanbieter-Skripte zähmen. Chat-Widgets, Tracking und Consent-Banner sind oft die eigentlichen Bremsen. Mit der Script-Komponente laden Sie sie erst, wenn die Seite steht.
4. Client-JavaScript klein halten. Jede unnötige Client Component vergrößert das Bundle und verschlechtert die Reaktionszeit. Was keine Interaktion braucht, bleibt Server Component.
5. Caching und statische Auslieferung nutzen. SSG- und ISR-Seiten kommen aus dem Cache und erreichen kurze Serverantwortzeiten.

Messen Sie mit Felddaten echter Nutzer, nicht nur mit einem einzelnen Lighthouse-Lauf auf Ihrem schnellen Entwicklerrechner. Gerade im B2B wird viel über Smartphones recherchiert. Wie Sie das bei der Mobile-First-Indexierung berücksichtigen, lesen Sie in unserem Beitrag zu Mobile SEO im B2B.

Häufige SEO-Fehler in Next.js-Projekten

Aus technischen Audits kennen wir eine Reihe von Fehlern, die immer wieder auftauchen. Die meisten sind schnell behoben, wenn man sie einmal gefunden hat:

• Inhalte nur im Client: Texte, die per useEffect oder clientseitigem Fetch geladen werden, fehlen im HTML.
• Fehlende oder doppelte Metadaten: Viele Seiten erben den Title aus dem Root-Layout, weil generateMetadata vergessen wurde.
• Falsche Canonicals: Alle Seiten verweisen auf die Startseite, oder der Canonical zeigt auf die Vorschau-Domain des Hostings.
• Indexierte Staging-Umgebungen: Vorschau-Deployments sind öffentlich erreichbar und konkurrieren mit der Live-Seite.
• Soft-404-Fehler: Dynamische Routen liefern für nicht existierende Slugs eine leere Seite mit Status 200. Rufen Sie in diesem Fall notFound() auf, dann gibt Next.js einen echten 404-Status zurück.
• Weiterleitungsketten: Mehrere Redirects hintereinander, etwa von http auf https, dann auf www, dann mit Schrägstrich am Ende.
• Interne Links ohne echte Links: Navigation über onClick und router.push statt über die Link-Komponente. Google folgt nur echten href-Attributen.
• Blockierte Ressourcen: Eine robots.txt, die /_next/ sperrt, verhindert sauberes Rendering.

Wie diese Punkte bei JavaScript-Frameworks generell zusammenhängen, haben wir im Beitrag zu JavaScript SEO zusammengefasst.

So prüfen Sie die Indexierbarkeit Ihrer Next.js-Seite

1. Quelltext ansehen. Öffnen Sie die Seite, drücken Sie Strg+U und suchen Sie nach einem Satz aus dem Haupttext. Fehlt er, wird der Inhalt clientseitig erzeugt.
2. Metadaten im Quelltext prüfen. Title, Meta-Description, Canonical und robots-Tag müssen im Head stehen, mit den richtigen Werten.
3. URL-Prüfung in der Google Search Console nutzen. Der Live-Test zeigt das gerenderte HTML und einen Screenshot, also das, was Google tatsächlich sieht.
4. Indexierungsbericht auswerten. Achten Sie auf „Gecrawlt, zurzeit nicht indexiert“, Duplikate ohne vom Nutzer ausgewählte kanonische Seite und Soft-404-Fehler.
5. Die gesamte Website crawlen. Ein SEO-Crawler mit und ohne JavaScript-Rendering zeigt Unterschiede zwischen Roh-HTML und gerenderter Seite, Statuscodes, Weiterleitungen und Canonicals.
6. Sitemap gegen den Crawl abgleichen. URLs in der Sitemap, die nicht indexierbar sind, und indexierbare URLs, die in der Sitemap fehlen, sind beide ein Hinweis auf Handlungsbedarf.

Eine ausführliche Prüfliste mit Priorisierung finden Sie in unserer Anleitung zum technischen SEO-Audit.

Unsere Sicht: Next.js-SEO ist eine Frage der Priorisierung

In fast jedem Next.js-Projekt, das wir analysieren, ist die Technik gut, und trotzdem bleibt die Sichtbarkeit hinter den Erwartungen zurück. Der Grund ist selten das Framework. Es fehlt die Entscheidung, welche Maßnahme zuerst kommt.

Ein Audit, das 80 Punkte auflistet, hilft einem Entwicklungsteam wenig. Es braucht eine klare Reihenfolge: Erst das Rendering der umsatzrelevanten Seiten absichern, dann Metadaten und Canonicals, dann Sitemap und strukturierte Daten, dann Performance. Genau so arbeiten wir: mit einer klaren Priorisierung statt einer generischen To-do-Liste.

Unser Vorteil ist, dass wir technisches SEO und moderne Webtechnologien wie React und Next.js zusammendenken. Wir sprechen die Sprache Ihrer Entwickler, wir lesen Code und wir formulieren Empfehlungen so, dass sie direkt in Tickets übernommen werden können. Unterstützt von AI-gestützten, datenbasierten Workflows prüfen wir große Seitenbestände effizient und messen Ergebnisse an KPIs, die für Ihr Geschäft zählen.

Und weil Sie einen festen Ansprechpartner haben, geht nichts zwischen Agentur, Entwicklung und Marketing verloren. Next.js gibt Ihnen das Werkzeug. Wir sorgen dafür, dass es in die richtige Richtung arbeitet.

Aliniyaz

Next.js-SEO mit einem Ansprechpartner umsetzen

Sie haben eine Next.js-Website und wollen wissen, welche Maßnahmen bei Ihnen den größten Effekt bringen? Mit unserem Einstiegspaket SEO Foundation ab 999 € einmalig bekommen Sie einen strukturierten Start: Analyse, klare Prioritäten und konkrete Empfehlungen für Ihr Team, ohne lange Vertragsbindung.

Für die laufende Betreuung gibt es SEO Essentials ab 999 € pro Monat, SEO Growth ab 2.999 € pro Monat und SEO Partner ab 4.999 € pro Monat. Alle Pakete finden Sie auf unserer Seite mit den SEO-Preisen und Paketen. Wenn Sie vor allem Rendering, Indexierung und Performance angehen wollen, lesen Sie mehr über unser Technical SEO für Unternehmen.

Häufige Fragen zu SEO mit Next.js

Ist Next.js besser für SEO als eine reine React-App?

In der Regel ja, weil Next.js Seiten per SSG, ISR oder SSR vorrendert und Google fertiges HTML erhält. Eine reine React-App mit clientseitigem Rendering liefert zunächst nur eine leere Hülle. Entscheidend ist, dass Sie die vorgerenderten Strategien für alle Seiten nutzen, die ranken sollen.

Brauche ich im App Router noch ein Paket wie next-seo?

Meist nicht. Die eingebaute Metadata API deckt Title, Description, Canonical, Open Graph und robots-Angaben ab. Zusatzpakete stammen vor allem aus der Zeit des Pages Routers.

Ist SSR oder SSG die bessere Wahl für SEO?

Beide liefern Google vorgerendertes HTML und eignen sich gut. SSG und ISR sind meist schneller, weil die Seiten aus dem Cache kommen. SSR lohnt sich, wenn Inhalte bei jeder Anfrage aktuell sein müssen.

Wie erkenne ich, ob Google meine Next.js-Seite richtig rendert?

Prüfen Sie zuerst den Quelltext auf Ihren Haupttext und Ihre Metadaten. Danach zeigt der Live-Test der URL-Prüfung in der Google Search Console das gerenderte HTML. Abweichungen zwischen beiden weisen auf clientseitig erzeugte Inhalte hin.

Wie lange dauert es, bis technische Verbesserungen wirken?

Das hängt davon ab, wie oft Google Ihre Seiten crawlt und wie groß die Änderungen sind. Behobene Indexierungsfehler zeigen sich oft schneller als Ranking-Effekte. Eine seriöse Ranking-Garantie kann niemand geben, deshalb messen wir den Fortschritt an klar definierten KPIs.

Quellen

• Next.js: SEO Rendering Strategies
• Next.js: Metadata and OG images
• Google-Hilfe: Unterstützte Attribute und Werte für strukturierte Daten

Empfehlungen

• SEO für React: So werden React-Websites bei Google sichtbar
• JavaScript SEO: So werden dynamische Websites sichtbar
• Technical SEO: Technik, Indexierung & Performance