Next.js SEO im App Router: Metadata, Sitemap und Canonicals richtig setzen

Next.js SEO im App Router ohne Rätselraten: Metadata-API, generateMetadata, sitemap.js, robots.js, Canonicals und Bilder – in der Reihenfolge, die Sichtbarkeit bringt.

Next.js gilt als SEO-freundlich, und das stimmt auch. Die Seiten werden auf dem Server gerendert, kommen als fertiges HTML beim Besucher an und laden schnell. Trotzdem sehen wir regelmäßig Next.js-Websites, die bei Google kaum auftauchen: Titel doppeln sich, die Sitemap ist leer, halbe Bereiche stehen auf „nicht indexieren“, oder der Text erscheint erst, wenn JavaScript geladen hat.

Dieser Guide zeigt dir, was du in einer Next.js-Website mit App Router wirklich einstellen musst, damit Google deine Seiten findet, versteht und ausspielt – in der Reihenfolge, in der es sich lohnt. Du bekommst:

• eine Kurzantwort für den schnellen Überblick und eine Einordnung, was technisches SEO für dein Unternehmen bedeutet
• eine Prioritätenliste: was zuerst, was später, was optional ist
• konkrete Anleitungen zu Metadata-API, generateMetadata, sitemap.js, robots.js und Canonicals
• die häufigsten Fehler beim Umstieg vom alten Pages Router und wie du sie erkennst
• fünf Prüfungen, die du in 20 Minuten selbst machen kannst, auch ohne Entwicklerkenntnisse
• eine ehrliche Einschätzung zu Aufwand und dazu, wann sich das Thema für dich nicht lohnt

Geschrieben ist der Artikel für Inhaber und Entscheider, deren Website auf Next.js läuft oder laufen soll, und für alle, die mit einer Agentur oder einem Entwickler über technisches SEO sprechen müssen, ohne selbst Code zu schreiben.

Kurzantwort: Was im App Router wirklich zählt

Für gutes Next.js SEO im App Router brauchst du fünf Dinge: Inhalte, die serverseitig im HTML stehen, Titel und Beschreibungen über die Metadata-API statt über alte Kopfbereich-Bausteine, eine automatisch erzeugte Sitemap über app/sitemap.js, eine robots.js, die auf der Live-Domain nichts Wichtiges blockiert, und einen Canonical pro Seite, der auf die eigene, saubere Adresse zeigt. Alles andere ist Feinschliff. Wer diese fünf Punkte sauber hat, hat den technischen Teil zu großen Teilen erledigt und kann sich um Inhalte kümmern.

Was technisches SEO für dein Unternehmen bedeutet

Technisches SEO klingt nach Entwicklerthema, ist aber in erster Linie eine Vertriebsfrage. Wenn Google eine Seite nicht findet oder falsch versteht, existiert sie für den Markt nicht. Das trifft nicht alle Seiten gleich: Es trifft meist genau die Seiten, die Anfragen bringen – Leistungsseiten, Standortseiten, Kontaktseite.

Drei typische Situationen aus der Praxis:

• Ein Handwerksbetrieb aus Magdeburg bekommt nach dem Relaunch keine Anfragen mehr über Google. Ursache: Die Sperre für die Testumgebung ist auf der Live-Website gelandet. Jede Seite sagt Google „nicht indexieren“.
• Eine Praxis hat auf jeder Unterseite denselben Titel. In der Suche sieht jeder Treffer gleich aus, niemand klickt. Ursache: Der Titel steht nur einmal zentral im Layout, die einzelnen Seiten überschreiben ihn nicht.
• Ein B2B-Unternehmen hat 40 Leistungsseiten, aber nur sechs davon sind indexiert. Ursache: Es gibt keine Sitemap und keine internen Links zu den restlichen Seiten. Google kennt sie schlicht nicht.

In allen drei Fällen ist der Inhalt gut. Das Problem ist die Auslieferung. Deshalb gehört technisches SEO an den Anfang eines Projekts, nicht ans Ende. Eine Korrektur nach dem Launch kostet mehr als eine saubere Einrichtung davor – und die Wochen ohne Sichtbarkeit bekommst du nicht zurück.

Tipp: Frag deine Agentur vor dem Launch nach drei Screenshots: der Seitenquelltext einer Leistungsseite, die aufgerufene Datei sitemap.xml und die Datei robots.txt der Live-Domain. Wenn diese drei stimmen, ist der gefährlichste Teil abgedeckt.

Die Reihenfolge: was zuerst, was später

Nicht jede Maßnahme hat denselben Effekt. Diese Reihenfolge hat sich in unseren Projekten bewährt:

Punkt 1 und 2 sind Pflicht. Punkt 3 bis 5 kosten wenig Zeit und bringen viel. Punkt 6 und 7 sind Feinschliff, der sich lohnt, sobald die Basis steht.

Schritt 1: Inhalte müssen ohne JavaScript im HTML stehen

Im App Router ist jede Seite zunächst eine Server Component: Sie wird auf dem Server zu fertigem HTML gerendert. Das ist der Normalfall und für SEO genau richtig. Zur Client Component wird eine Datei erst, wenn oben die Zeile mit dem Hinweis use client steht. Dann läuft der Baustein im Browser des Besuchers.

Das Problem entsteht, wenn diese Zeile zu weit oben steht – etwa in der Seitendatei selbst oder im Layout, das alle Seiten umschließt. Dann wird die gesamte Seite zum Browser-Programm, und Google bekommt zunächst eine fast leere Hülle.

So prüfst du das in einer Minute, ohne Entwicklerwerkzeuge:

1. Öffne eine wichtige Leistungsseite im Browser.
2. Rechtsklick, dann „Seitenquelltext anzeigen“ (nicht „Untersuchen“ – das zeigt den Zustand nach JavaScript).
3. Suche mit Strg+F nach einem typischen Satz aus deinem Fließtext.

Findest du den Satz, steht der Inhalt im HTML. Findest du ihn nicht, wird er erst im Browser erzeugt. Dasselbe gilt für Links: Deine Navigation und deine Handlungsaufforderungen sollten echte Links sein, keine Schaltflächen, die per JavaScript umschalten. Google folgt Links, nicht Klick-Ereignissen.

Welche Bausteine auf den Server gehören und welche wirklich Interaktion brauchen, erklärt der Artikel zu Server Components und Client Components im Detail.

Schritt 2: Titel und Beschreibung mit der Metadata-API

Im App Router setzt du Metadaten nicht mehr als Markup im Kopfbereich, sondern als Daten-Export. Next.js baut daraus das fertige HTML. Es gibt zwei Wege, und beide laufen auf dem Server:

app/layout.jsx              metadata: Vorlage für alle Titel, Standardtexte
app/seo/page.jsx            metadata: Titel und Beschreibung dieser Seite
app/blog/[slug]/page.jsx    generateMetadata(): Titel aus dem Artikel

Im Layout legst du die Grundlage fest: eine Titel-Vorlage, die den Firmennamen anhängt, eine Standardbeschreibung, die Basis-Adresse deiner Domain und die Vorgaben für Vorschaubilder in sozialen Netzwerken. Auf jeder einzelnen Seite überschreibst du dann Titel und Beschreibung.

Der häufigste Fehler an dieser Stelle: Der metadata-Export steht in einer Datei, die mit use client beginnt. Next.js ignoriert ihn dann ohne Fehlermeldung. Die Seite läuft, sieht gut aus, hat aber keinen eigenen Titel. Wenn dir in der Search Console „Doppelte Titel“ oder immer derselbe Treffer-Text auffällt, ist das fast immer die Ursache.

Tipp: Schreibe Titel für Menschen, nicht für Zähler. „Elektroinstallation in Magdeburg – Termin in 48 Stunden“ bringt mehr Klicks als „Elektro, Elektriker, Elektroinstallation Magdeburg Sachsen-Anhalt“. Der Titel ist der einzige Werbetext, den jeder Suchende sieht, bevor er klickt.

Schritt 3: generateMetadata für Blog, Shop und Standorte

Sobald Inhalte aus einem CMS oder einer Datenbank kommen, reicht ein fester Export nicht mehr. Dann brauchst du die Funktion generateMetadata. Sie bekommt die Adressbestandteile der aufgerufenen Seite, holt den passenden Datensatz und gibt Titel, Beschreibung, Canonical und Vorschaubild zurück.

Typische Anwendungsfälle:

• Blogartikel: Titel und Auszug kommen aus dem Artikel, das Vorschaubild ist das Titelbild.
• Produkte: Titel enthält Produktname und Kategorie, die Beschreibung den zentralen Nutzen.
• Standortseiten: Eine Vorlage, viele Orte – „Webdesign für Handwerksbetriebe in Magdeburg“, „… in Halle“, „… in Dessau“.
• Case Studies: Kundenprojekt als Titel, Ergebnis als Beschreibung.

Zwei Punkte, die in der Praxis oft schiefgehen: Wenn ein Datensatz nicht existiert, muss die Seite einen echten 404-Status liefern und nicht eine leere Seite mit Status 200. Und der Canonical muss zur endgültigen Adresse des Inhalts passen – nicht zur Vorschau, nicht zu einer alten Adresse aus der Migration.

Bei Standortseiten gilt außerdem: Sie brauchen eigenen, echten Inhalt. Dieselbe Seite fünfzehnmal mit ausgetauschtem Ortsnamen ist für Google erkennbar und bringt selten Rankings. Jede Standortseite braucht einen eigenen Bezug: Referenzen aus dem Ort, Anfahrtsweg, Ansprechpartner, typische Aufträge.

Schritt 4: sitemap.js und robots.js statt Handarbeit

Next.js kann beide Dateien selbst erzeugen. Du legst im app-Verzeichnis eine Datei sitemap.js an, die eine Liste aller indexierbaren Adressen mit Änderungsdatum zurückgibt. Beim Aufruf von sitemap.xml liefert Next.js daraus die fertige XML-Datei. Dasselbe Prinzip gilt für robots.js und die daraus erzeugte robots.txt.

Der Vorteil gegenüber statischen Dateien: Neue Blogartikel, Produkte oder Standortseiten erscheinen automatisch in der Sitemap, sobald sie veröffentlicht sind. Niemand muss daran denken.

Drei Stolperfallen, die uns regelmäßig begegnen:

1. Alte Dateien im Ordner public. Liegt dort noch eine sitemap.xml oder robots.txt aus der Vorgängerversion, gewinnt diese Datei. Die dynamische Variante wird nie ausgeliefert. Lösung: alte Dateien löschen.
2. Die Sperre aus der Testumgebung geht live. Wer die Testumgebung über robots.js sperrt, muss diese Regel an eine Umgebungsvariable koppeln. Sonst ist nach dem nächsten Deployment die ganze Website gesperrt.
3. Die Sitemap enthält weitergeleitete Adressen. Nach einem Relaunch bleiben oft alte Pfade in der Liste. Google meldet das als Fehler und crawlt langsamer.

Was robots.txt und Sitemap grundsätzlich leisten – und was nicht –, erklärt der Artikel zu Robots.txt, Sitemap und Indexierung.

Schritt 5: Canonicals – eine Adresse pro Inhalt

Ein Canonical sagt Google: „Diese Adresse ist die richtige Version dieses Inhalts.“ Im App Router setzt du ihn über das Feld alternates im metadata-Export oder in generateMetadata. Zwei Regeln reichen für die meisten Unternehmenswebsites:

• Jede indexierbare Seite bekommt eine Selbstreferenz auf ihre eigene, saubere Adresse.
• Der Canonical ist immer absolut, also mit https und der Hauptdomain, nicht als relativer Pfad.

Wichtig ist die Abgrenzung: Canonicals lösen keine Domain-Probleme. Wenn deine Website sowohl mit als auch ohne www erreichbar ist, gehört das über Weiterleitungen gelöst, nicht über einen Canonical. Wie du die Hauptvariante festlegst, welchen Statuscode du dafür nutzt und wie du Weiterleitungsketten vermeidest, steht ausführlich im Artikel zu Canonicals, Redirects und der richtigen Domain-Variante.

Schritt 6: Bilder, Schriften und der erste Eindruck

Ladezeit ist kein reines Ranking-Thema, sondern ein Abschluss-Thema: Wer wartet, springt ab. Die drei häufigsten Bremsen in Next.js-Projekten:

• Das Hero-Bild. Es ist fast immer das größte Element und bestimmt den LCP, also den Zeitpunkt, an dem der Hauptinhalt sichtbar ist. Zielwert sind 2,5 Sekunden oder weniger. Die Bildkomponente von Next.js liefert moderne Formate aus und skaliert automatisch – aber nur, wenn Größenangaben und Priorität stimmen.
• Schriften. Werden Webfonts von einem fremden Server geladen, blockieren sie oft das Rendern. Next.js kann Schriften lokal einbinden und beim Bauen optimieren.
• Fremde Skripte. Chat-Fenster, Bewertungs-Widgets, Tracking und Einwilligungsbanner summieren sich. Jedes Skript kostet Ladezeit, besonders auf Mobilfunkverbindungen.

Für jedes Bild gehören Breite und Höhe fest hinterlegt, damit beim Laden nichts verspringt – das ist der CLS-Wert, Zielbereich 0,1 oder darunter. Welche Größen, Formate und Einstellungen dafür nötig sind, steht im Artikel zu LCP und Bildern in Next.js.

Typische Fehler beim Umstieg auf den App Router

Beim Wechsel vom alten Pages Router tauchen immer dieselben Muster auf. Diese Liste ist sortiert nach Häufigkeit in unseren Audits:

Ein Muster fällt auf: Fast alle diese Fehler sind unsichtbar. Die Website sieht im Browser völlig normal aus. Deshalb gehört nach jedem Deployment ein kurzer technischer Check dazu – und nicht nur ein Blick auf die Startseite.

Fünf Prüfungen, die du selbst machen kannst

Für diese Checks brauchst du keine Entwicklerkenntnisse. Rechne mit 20 Minuten.

1. Seitenquelltext: Rechtsklick auf einer Leistungsseite, „Seitenquelltext anzeigen“, mit Strg+F nach einem Satz aus deinem Text suchen. Steht er drin, ist alles gut.
2. Titel je Seite: Öffne fünf verschiedene Unterseiten und schau in den Browser-Tab. Fünf verschiedene Titel sind richtig, fünfmal derselbe ist ein Fehler.
3. Sitemap: Rufe deinedomain.de/sitemap.xml auf. Sind alle wichtigen Seiten enthalten? Fehlen neue Artikel?
4. Robots: Rufe deinedomain.de/robots.txt auf. Steht dort eine generelle Sperre, ist deine Website für Google unsichtbar.
5. Search Console: Nutze die URL-Prüfung für deine drei wichtigsten Seiten. Google zeigt dir, ob die Seite indexiert ist, welche Adresse als kanonisch gilt und wann sie zuletzt gecrawlt wurde.

Ein einzelner Statuscode lässt sich im Terminal in einer Zeile prüfen:

curl -I https://22orbit.de/webdesign

Die Antwort zeigt dir den Statuscode und bei einer Weiterleitung auch das Ziel – ohne dass du die Seite im Browser öffnen musst.

Aufwand, Kosten und was realistisch möglich ist

Bei einer bestehenden Next.js-Website ist ein technischer SEO-Check überschaubar: Die Prüfung dauert wenige Stunden, die Korrektur von Metadaten, Sitemap, robots.js und Canonicals liegt meist im Bereich von ein bis drei Arbeitstagen. Teuer wird es nur dann, wenn die Seite falsch gebaut ist und große Teile als Browser-Programm laufen. Dann ist es ein Umbau, kein Fix.

Bei einer neuen Website ist das alles Teil der normalen Umsetzung. Unsere Starter-Website beginnt bei 1.499 €, die Hero-Website bei 3.900 €, jeweils netto und zahlbar monatlich über zwölf Monate oder einmalig mit 10 % Rabatt. Metadaten, Sitemap, robots, Canonicals und optimierte Bilder gehören dabei zum Standard und werden nicht extra berechnet.

Was du realistisch erwarten kannst: Eine technisch saubere Website wird zuverlässig indexiert und lädt schnell. Rankings entstehen daraus aber erst in Kombination mit Inhalten, die eine echte Frage beantworten, und mit internen Links, die Themen verbinden. Wie du das strukturierst, steht im Artikel zu internen Links und Topic Clustern.

Wann sich der Aufwand für dich nicht lohnt

Ehrlich bleibt ehrlich: Nicht jedes Unternehmen braucht diesen Aufwand.

• Dein Geschäft läuft rein über Empfehlung und du hast keine freien Kapazitäten. Dann ist eine schnelle, saubere Website völlig ausreichend, Feinschliff bringt nichts.
• Deine Website hat fünf Seiten. Ein durchdachtes Cluster aus Standortseiten und Artikeln ist dann überdimensioniert. Eine gute Startseite, eine Leistungsseite und eine starke Kontaktseite reichen.
• Es gibt kaum Suchnachfrage für deine Leistung. Dann sind Empfehlungen, Netzwerk oder Social Media der schnellere Weg – ein fester Posting-Rhythmus bringt in dem Fall mehr als ein Canonical.
• Deine Website läuft auf WordPress und funktioniert. Ein Wechsel nur wegen Next.js lohnt sich selten. Die Abwägung steht im Vergleich WordPress oder individuelle Website.

Nächster Schritt

Wenn du es selbst angehen willst: Arbeite die Prioritätenliste von oben nach unten ab. Prüfe zuerst robots.txt und Indexierung, dann den Seitenquelltext, danach Titel und Beschreibungen. Allein diese drei Schritte beheben die meisten Probleme, die wir in Audits finden.

Wenn du willst, dass jemand draufschaut: Wir prüfen deine Next.js-Website auf Metadaten, Indexierung, Canonicals, Sitemap und Ladezeit, priorisieren die Punkte nach Wirkung und setzen sie auf Wunsch direkt um. Du bekommst eine verständliche Liste, keine Werkzeug-Ausgabe zum Selbstübersetzen.

• SEO und technische Optimierung
• Webdesign und Websites mit Next.js
• Erstgespräch vereinbaren