Vagabov Agency
SEO

Technisches SEO für Next.js: Core Web Vitals, Metadaten, Sitemap

Technisches SEO für Next.js: Metadaten, Bilder, Sitemap, JSON-LD und Core Web Vitals – sieben Punkte, die du im App Router prüfen solltest.

Tymur VagabovVagabov AgencyAktualisiert am 8 Min. Lesezeit
Technisches SEO für Next.js: Core Web Vitals, Metadaten, Sitemap
Inhalt · 9 Abschnitte

Next.js bringt für SEO viel mit: fertiges HTML vom Server, Metadaten pro Seite, automatisch optimierte Bilder. Eine gut rankende Website ist es damit noch nicht. Die Fehler passieren in den Details: ein Hero-Bild, das zu spät lädt, eine Sitemap voller Weiterleitungen, strukturierte Daten, die im ausgelieferten HTML fehlen. Hier sind sieben Punkte, die du prüfen solltest – egal, ob du selbst entwickelst oder deine Website betreuen lässt.

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

Mit dem App Router (stabil seit Next.js 13.4) rendert Next.js Seiten standardmäßig auf dem Server. Browser und Crawler bekommen sofort vollständiges HTML statt einer leeren Hülle, die erst per JavaScript befüllt wird. Das zählt für Google und für viele KI-Crawler, die kein JavaScript ausführen.

  • Server Components schicken kein eigenes JavaScript an den Browser. Das hält das Bundle klein.
  • Statische Generierung und ISR erzeugen Seiten vorab und aktualisieren sie zeitgesteuert oder auf Abruf – schnelle Antwortzeiten, ohne dass Inhalte veralten.
  • Streaming schickt das HTML in Etappen: Langsame Bereiche hinter einer Suspense-Grenze folgen in derselben Antwort, der Rest der Seite ist schon sichtbar.

Diesen Vorteil verschenkst du, wenn wichtige Inhalte erst im Browser per useEffect geladen werden. Dann steht im HTML nur ein Ladezustand. Alles, was ranken soll, gehört ins serverseitig gerenderte HTML.

1. Metadata API: Titel, Beschreibung und Canonical pro Seite

Meta-Tags definierst du im App Router pro Route: statisch mit export const metadata oder dynamisch mit generateMetadata, etwa für Blogartikel oder Produktseiten. Darauf kommt es an:

  • metadataBase im Root-Layout: Damit werden relative Pfade für Canonical und Vorschaubilder automatisch zu absoluten URLs.
  • Canonical auf jeder Seite: alternates.canonical legt die maßgebliche URL fest und verhindert Duplikate durch URL-Parameter oder doppelte Pfade.
  • Titel-Template: title.template im Root-Layout, etwa '%s | Firmenname', gibt allen Unterseiten ein einheitliches Format.
  • noindex bewusst setzen: Danke-Seiten oder interne Suchergebnisse bekommen robots: { index: false }.
  • params abwarten: Seit Next.js 15 ist params ein Promise – schreib const { slug } = await params;. Den synchronen Zugriff unterstützt Next.js 16 nicht mehr.

Open-Graph-Angaben sind kein Rankingfaktor, bestimmen aber, wie dein Link in WhatsApp, LinkedIn oder Slack aussieht – und damit, ob jemand klickt. Prüf das Ergebnis immer im Seitenquelltext (Rechtsklick → „Seitenquelltext anzeigen“), nicht in den Entwicklertools. Nur der Quelltext zeigt, was ein Crawler zuerst bekommt.

2. Bildoptimierung: der wichtigste Hebel für LCP

Der Largest Contentful Paint (LCP) misst, wann das größte sichtbare Element geladen ist. Auf den meisten Websites ist das ein Bild, oft das Hero-Bild. Für next/image heißt das:

  • Das LCP-Bild nicht lazy laden: next/image lädt Bilder standardmäßig lazy. Bis Next.js 15 hieß der Schalter dagegen priority, seit Next.js 16 ist er veraltet. Nutze preload oder – wie die Next.js-Dokumentation für die meisten Fälle empfiehlt – fetchPriority="high" bzw. loading="eager".
  • sizes angeben: Bei Bildern mit fill oder flexibler Breite nimmt der Browser ohne sizes volle Bildschirmbreite an und lädt oft eine viel zu große Datei. Ein Wert wie sizes="(max-width: 768px) 100vw, 50vw" behebt das.
  • Maße festlegen: Breite und Höhe oder ein Container mit festem Seitenverhältnis verhindern, dass das Layout beim Laden springt (CLS).
  • Formate: Standardmäßig liefert next/image WebP. Das meist noch kleinere AVIF schaltest du über images.formats in der next.config zu.
  • Externe Quellen: images.remotePatterns ersetzt das veraltete images.domains. Bilder hinter temporären Links, etwa direkt aus einem KI-Bildgenerator, verschwinden irgendwann – speicher sie lieber im eigenen Projekt.

3. Sitemap und robots.txt: Crawlbarkeit sauber steuern

Next.js erzeugt keine Sitemap von allein. Du legst eine Datei app/sitemap.ts an, die alle URLs zurückgibt – bei Blogs und Shops dynamisch aus deinen Daten –, und analog app/robots.ts. Typische Fehler:

  • Falsche URLs: In die Sitemap gehören nur indexierbare Seiten mit Status 200 – keine Weiterleitungen, keine 404- und keine noindex-Seiten.
  • Änderungsdatum immer „jetzt“: Wer bei jedem Build new Date() als lastModified einträgt, meldet Änderungen, die es nicht gibt. Google nutzt das Datum nur, wenn es zuverlässig stimmt. Trag das Datum der letzten inhaltlichen Änderung ein.
  • priority und changeFrequency: Beide Werte ignoriert Google laut eigener Dokumentation. Du kannst sie weglassen.
  • /_next/ blockiert: Ein Disallow: /_next/ in der robots.txt sperrt CSS, JavaScript und alle über next/image optimierten Bilder. Google braucht sie, um die Seite zu rendern – die Regel gehört raus.

Verweise in der robots.txt auf die Sitemap und reiche sie zusätzlich in der Google Search Console ein. Dort siehst du auch, welche URLs Google gefunden, aber nicht indexiert hat.

4. Core Web Vitals: INP ist der kritische Wert

Google bewertet die Nutzererfahrung mit drei Kennzahlen aus echten Besuchen. Maßgeblich ist das 75. Perzentil: Drei von vier Seitenaufrufen sollten im grünen Bereich liegen.

MetrikWas sie misstGut
LCP (Largest Contentful Paint)Ladezeit des größten sichtbaren Elementsbis 2,5 Sekunden
INP (Interaction to Next Paint)Reaktion auf Klicks, Tippen und Tastatureingabenbis 200 Millisekunden
CLS (Cumulative Layout Shift)Verschieben des Layouts während des Ladensbis 0,1

INP hat im März 2024 den alten Wert FID (First Input Delay) abgelöst. Bei React- und Next.js-Seiten wird er schnell zum Problem: Hydration und große Client-Komponenten blockieren den Main Thread, und die Seite reagiert verzögert auf Eingaben. Was hilft:

  • Server Components als Standard: Was nicht interaktiv sein muss, bleibt eine Server Component und braucht keine Hydration.
  • 'use client' möglichst tief setzen: Markiere den Button als Client Component, nicht die ganze Seite.
  • Schweres später laden: Karten, Charts, Video-Player oder Chat-Widgets lädst du mit next/dynamic erst, wenn sie gebraucht werden.
  • Teure Updates entkoppeln: Aufwendige State-Updates, etwa das Filtern langer Listen, markierst du mit useTransition als nicht dringend. Eingaben, die Suchanfragen auslösen, entprellst du.
  • Drittanbieter-Skripte ausmisten: Tag Manager, Chat-Tools und Tracking bindest du über next/script mit passender Strategie wie lazyOnload ein – und nur die, die du wirklich brauchst.

Zur Einordnung: Core Web Vitals sind ein Signal unter vielen, hilfreicher Inhalt zählt mehr. Gute Werte machen eine schwache Seite nicht zur Nummer eins. Schlechte Werte können dich aber Besucher kosten, die abspringen, bevor die Seite reagiert.

5. Strukturierte Daten: JSON-LD gehört ins Server-HTML

Mit JSON-LD beschreibst du Suchmaschinen, worum es auf einer Seite geht: dein Unternehmen (Organization, LocalBusiness), Artikel (BlogPosting), die Navigation (BreadcrumbList) oder Produkte. Das hilft beim Verständnis und ist Voraussetzung für bestimmte Rich Results. Erwarte aber nicht zu viel: Seit 2023 zeigt Google FAQ-Rich-Results nur noch für bekannte Websites von Behörden und aus dem Gesundheitsbereich, die HowTo-Darstellung wurde ganz eingestellt.

Der Fallstrick in Next.js: JSON-LD gehört als normales <script type="application/ld+json"> direkt in Seite oder Layout, befüllt mit JSON.stringify. So zeigt es auch die Next.js-Dokumentation, inklusive Maskierung des Zeichens <, falls Inhalte aus einem CMS kommen. Bindest du JSON-LD dagegen über die Komponente next/script ein, kann es erst nach der Hydration im Dokument landen. Crawler, die kein JavaScript ausführen, sehen es dann nie.

Auf unserer eigenen Website ist genau das passiert: Im Code war das JSON-LD vollständig, im ausgelieferten HTML fehlte es. Prüf deshalb den Seitenquelltext oder teste die URL mit dem Rich-Results-Test von Google. Und halte die Daten schlank – lieber eine saubere Organization-Angabe, auf die andere Seiten verweisen, als dieselbe Firma mehrfach mit leicht unterschiedlichen Daten.

6. Mehrsprachigkeit: hreflang nur, wenn es Varianten gibt

Wer Kunden in Deutschland, Österreich und der Schweiz mit denselben deutschen Seiten anspricht, braucht kein hreflang. Die Angabe ist nur nötig, wenn es mehrere Sprach- oder Länderversionen derselben Seite gibt – etwa Deutsch und Englisch oder eine eigene Schweizer Version mit Preisen in Franken.

  • Routing: Der App Router hat kein eingebautes i18n-Routing, die alte i18n-Option gilt nur für den Pages Router. Üblich ist ein dynamisches Segment wie app/[lang]/. Die Spracherkennung übernimmt die Middleware, die seit Next.js 16 proxy.ts heißt.
  • hreflang: Über alternates.languages in der Metadata API verweist jede Sprachversion auf alle Versionen, sich selbst eingeschlossen. Für die Standardversion ergänzt du x-default.
  • Keine automatische IP-Umleitung: Der Googlebot crawlt überwiegend von US-Adressen aus und sähe womöglich nur eine Version. Besser sind feste URLs pro Sprache und eine sichtbare Sprachauswahl.

7. Monitoring: echte Nutzerdaten statt nur Laborwerte

Lighthouse und die Laboransicht von PageSpeed Insights messen unter künstlichen Bedingungen – gut zum Debuggen, aber nicht das, was Google bewertet. Für die Core Web Vitals zählen Felddaten aus dem Chrome User Experience Report (CrUX), also Messungen echter Chrome-Nutzer. Du findest sie in PageSpeed Insights und im Bericht „Core Web Vitals“ der Search Console, allerdings nur für Seiten mit genug Traffic.

Für die eigene Diagnose lohnt sich Real-User-Monitoring: mit dem Hook useReportWebVitals aus next/web-vitals, der LCP, INP und CLS an dein Analytics-Tool schickt, oder mit Vercel Speed Insights, wenn deine Seite auf Vercel läuft. Diese Daten fließen nicht in CrUX ein und wirken nicht direkt aufs Ranking. Dafür zeigen sie dir früher und genauer, welche Seite oder welches Gerät Probleme macht – auch bei Unterseiten, für die Google noch keine Felddaten hat. Warum Ladezeit fürs Geschäft zählt, liest du im Beitrag über schnelle Websites.


Fazit: Next.js ist eine starke Basis – die Details entscheiden

Next.js nimmt dir beim technischen SEO viel ab. Die letzten Schritte musst du aber bewusst gehen und regelmäßig kontrollieren, denn ein Update, ein neues Widget oder ein zusätzliches Skript kann gute Werte schnell wieder verschlechtern. Die Kurzfassung zum Abhaken:

  • Titel, Description, Canonical und JSON-LD stehen im Seitenquelltext.
  • Das LCP-Bild lädt sofort, alle Bilder haben Maße und passende sizes.
  • Die Sitemap enthält nur indexierbare URLs mit echtem Änderungsdatum.
  • Die robots.txt blockiert /_next/ nicht.
  • 'use client' steht nur dort, wo Interaktion nötig ist.
  • Du schaust regelmäßig in die Felddaten der Search Console oder deines eigenen Monitorings.

Wenn du wissen willst, wo deine Website technisch steht, oder eine neue Seite auf sauberer Basis planst, sprich mich im kostenlosen Erstgespräch an.

Teilen