Migrations-SEO: der Umstieg auf Next.js ohne Traffic-Verlust

Die meisten Traffic-Katastrophen stammen nicht von Google-Updates – Teams bescheren sie sich beim Plattformwechsel selbst. Eine Migration im Blindflug kann 30–70 % des organischen Traffics kosten, und die Erholung dauert Monate. Nach Lehrbuch durchgeführt, bringt sie einen kleinen, kurzen Einbruch, auf den oft ein Wachstum folgt (Next.js gewinnt in der Regel bei Rendering und Geschwindigkeit).

Regel null: Ändern Sie nur eine Variable auf einmal

Die riskantesten Migrationen ändern Plattform, URL-Struktur, Design und Inhalt gleichzeitig – sinkt der Traffic, kann keiner sagen, welche Änderung ihn gedrückt hat. Entzerren Sie das zeitlich: Migrieren Sie die Plattform bei eingefrorenen URLs und Inhalten, bestätigen Sie die Stabilität über einige Wochen, entwickeln Sie dann Design und Inhalte auf dem neuen Stack weiter.

Vorher: ein Inventar aufbauen

Sie bewahren nichts, was Sie nicht gemessen haben. Erfassen Sie pro URL:

Einen vollständigen Crawl der alten Website (Screaming Frog oder ein Skript über die alte Sitemap).
Top-Seiten aus der Search Console (12 Monate Klicks) und Top-Conversion-Seiten aus der Analytics – sie bekommen manuelle Aufmerksamkeit.
Die am häufigsten verlinkten Seiten (GSC → Links oder Ahrefs) – geht die Weiterleitung einer Seite mit 200 verweisenden Domains verloren, verbrennen Sie Jahre an Autorität.
Aktuelle Titles, Descriptions, Canonicals, hreflang, strukturierte Daten – die Basis für die Parität.

Die Weiterleitungsmap ist die Migration

Ändern sich URLs überhaupt, erhält jede alte URL eine Ein-Sprung-308/301 auf das exakte neue Gegenstück – nicht auf die Startseite (Massenweiterleitungen auf die Startseite behandelt Google als Soft-404):

// next.config.mjs — zuerst Musterregeln, eine ausdrückliche Map für Ausnahmen
async redirects() {
  return [
    { source: "/shop/:category/:slug", destination: "/products/:slug", permanent: true },
    ...explicitMap.map(({ from, to }) => ({ source: from, destination: to, permanent: true })),
  ];
}

Ketten sind verboten: Hatte die alte Website bereits Weiterleitungen, lenken Sie deren Quellen ebenfalls direkt auf die endgültigen URLs. Alles aus dem Thema zu Weiterleitungen gilt hier doppelt.

Staging: Paritätsprüfung, kein „nach Augenmaß"

Halten Sie das Staging außerhalb des Index: HTTP-Auth verlangt nicht, sich auf eine noindex-Einstellung zu verlassen, die versehentlich in die Produktion gelangen könnte.
Vergleichen Sie Alt und Neu für die Top-Seiten per Skript: Title, Description, Canonical, hreflang, H1, JSON-LD, Antwortcode. Auch die Rendering-Parität: curl auf das HTML des Stagings und bestätigen Sie, dass der Inhalt serverseitig gerendert wird.
Testen Sie die Weiterleitungsmap vor dem Start am vollständigen Inventar der alten URLs, nicht an einer Stichprobe.

Starttag und die Wochen danach

Reichen Sie die neue Sitemap in der Search Console ein; die Weiterleitungen der alten URLs liefern Sie unbefristet aus (Jahre, nicht Wochen).
Beobachten Sie die Server-Logs auf 404-Fehler des Googlebots – jeder ist eine Lücke in der Weiterleitungsmap; beheben Sie sie in der ersten Woche täglich.
Rechnen Sie mit einem Crawl-Anstieg und Positionsschwankungen über 2–6 Wochen – Google bewertet die Website neu; machen Sie nicht in Panik alles rückgängig.
Alarmschwellen: Ein anhaltender Rückgang von >20 % auf umsatzrelevanten Seiten nach der dritten Woche verdient eine Untersuchung (Monitoring-Einrichtung), keine Hoffnung.

Checkliste:

URL-Inventar mit markierten GSC-Top-Seiten und den am häufigsten verlinkten
Ein-Sprung-Weiterleitungsmap, die 100 % der alten URLs abdeckt, vor dem Start getestet
Staging hinter Autorisierung; Parität von Meta/Schema/Rendering pro Top-Seite verglichen
Plattform bei eingefrorenen URLs und Inhalten migriert; Design später
Nach dem Start: tägliche Durchsicht der Googlebot-404-Fehler, Weiterleitungen bleiben jahrelang aktiv