Lunover Engineering Notes

Next.js 16 SEO-Checkliste fuer Production

Eine production-taugliche Checkliste fuer Next.js 16 SEO: Metadata, Canonicals, hreflang, Sitemap-Hygiene, Robots-Regeln, Schema und Release-QA, die du automatisieren kannst.

March 5, 2026By LunoverWork with us

Next.js 16 SEO-Checkliste fuer Production

Technisches SEO ist vor allem operative Disziplin. Der schnellste Weg, Rankings zu verlieren, ist ein Release mit inkonsistenten Canonicals, duplizierten Metadaten oder einer kaputten Sitemap. Diese Checkliste richtet sich an Teams, die Marketing-Sites und Service-Websites mit Next.js 16 (App Router) bauen, besonders in mehrsprachigen Setups.

Wie "fertig" aussieht

  • Jede indexierbare Seite hat einen eindeutigen Title + Description, die zur Seiten-Intent passen.
  • Canonicals konsolidieren Duplikate (Host, Locale-Aliase, Trailing Slash).
  • hreflang zeigt nur auf echte Entsprechungen und enthaelt x-default.
  • Die Sitemap enthaelt nur canonical, indexierbare URLs und ein verlaessliches lastmod.
  • JSON-LD passt zu dem, was Nutzer wirklich sehen.
  • Du kannst all das im gerenderten HTML verifizieren.

1. Metadata gehoert der Route

Verlasse dich bei Kernseiten nicht auf ein einziges globales Default. Fuer jede indexierbare Route: pruefe, dass du generierst:
  • title
  • description
  • Canonical-URL
  • Open Graph / Twitter Image
Wenn du Next.js metadataBase nutzt, bevorzuge relative Werte im Code und lass Next daraus absolute URLs zusammensetzen. Beispiel-Pattern:
export const metadata = {
  metadataBase: new URL("https://www.example.com"),
  alternates: {
    canonical: "/services/web-development/",
    languages: {
      en: "/services/web-development/",
      de: "/de/services/web-development/",
      "x-default": "/services/web-development/",
    },
  },
  robots: {
    index: true,
    follow: true,
  },
};
Reference: Next.js generateMetadata / Metadata API.

2. Canonicals muessen stabil und eindeutig sein

Waehle eine Policy und setze sie konsequent durch:
  • ein Host (zum Beispiel www)
  • eine Trailing-Slash-Konvention
  • eine Default-Locale-Konvention
Dann redirecte alles andere permanent. Wenn deine Canonical-Policy "www + trailing slash + kein /en Prefix" ist, stelle sicher, dass diese nie als separate indexierbare URLs aufloesen:
  • https://lunover.com/...
  • https://www.lunover.com/en/...
  • https://www.lunover.com/... (ohne trailing slash)

3. hreflang darf nur echte Entsprechungen enthalten

hreflang ist nicht "URL uebersetzen". Es ist "aequivalente Seiten deklarieren". Regeln, die Cluster sauber halten:
  • Alternates nur fuer Locales angeben, in denen die Seite wirklich existiert
  • jede Locale-Variante muss sich selbst referenzieren und dieselbe Menge an Alternates nennen
  • x-default auf die Default-Sprache zeigen lassen
Reference: Google localized versions (hreflang).

4. Robots geht um Intent, nicht um Tradition

robots.txt steuert Crawling. Page-level noindex steuert Indexing. Nutze page-level noindex fuer Seiten, die nie in die Suche sollen:
  • Utility-Chat-Seiten
  • interne Tool-Seiten
  • temporaere Seiten, die du nicht indexieren willst
In Next.js Metadata ist das ein First-Class-Field:

5. Die Sitemap sollte langweilig und verlaesslich sein

Eine Sitemap ist kein Marketing. Sie ist ein Maschinen-Vertrag. Nimm nur auf:
  • Canonical-URLs
  • indexierbare URLs
  • korrektes lastmod
Google empfiehlt explizit, dass lastmod den letzten signifikanten Update widerspiegelt (Hauptinhalt, strukturierte Daten oder Links), nicht kosmetische Timestamp-Bumps. Reference: Google sitemap guidance.

6. Strukturierte Daten muessen zu dem passen, was Nutzer sehen

JSON-LD sollte aus derselben Quelle wie der Page-Content abgeleitet werden. Baseline-Schemas, die oft Sinn ergeben:
  • Organization (site-wide)
  • WebSite (homepage)
  • Service (service pages)
  • BlogPosting (articles)
Der Failure Mode, den du vermeiden willst: "Schema sagt A, Seite sagt B". Reference: Google structured data guidelines.

7. Interne Verlinkung ist Teil der SEO-Infrastruktur

Wenn technische Posts nie auf Service-Seiten verlinken, koennen Suchmaschinen Expertise schwerer mit kommerziellem Intent verbinden. Eine einfache Regel, die skaliert:
  • jeder technische Post verlinkt auf mindestens eine passende Service-Seite
  • jede Service-Seite verlinkt auf mindestens einen passenden technischen Post
Starte mit:

8. Release-QA (automatisierbar)

Bevor du deployest, verifiziere im gerenderten HTML:
  • Titles/Descriptions sind auf Kernseiten eindeutig
  • Canonical ist korrekt und absolut
  • hreflang-Set ist korrekt
  • robots Meta ist korrekt (insbesondere noindex)
  • Sitemap rendert und enthaelt erwartete URLs
  • Schema rendert und validiert
Behandle diese Checks als Deploy-Gates. SEO ist zu sensitiv fuer reines manuelles Spot-Checking.