WordPress-zu-Next.js-Migration ohne Ranking-Verlust

Warum verlieren die meisten WordPress-zu-Next.js-Migrationen Rankings?

Nicht, weil Sie PHP gegen React getauscht haben. Weil sich an einem einzigen Tag sechs Signale ändern und niemand sie vergleicht: die URL, der Redirect-Pfad dorthin, die internen Links, die darauf zeigen, Titel und H1, ob der Textkörper im HTML steckt, und wie schnell der Server antwortet.

• Redirect-Ketten. Die alte URL leitet per 301 auf einen Slug weiter, der per 301 auf eine Trailing-Slash-Variante weiterleitet, die schließlich 200 liefert. Google folgt dem; fast sonst niemand. Redirect-Tests fanden, dass OAI-SearchBot und Claude-SearchBot eine Kette bei drei Hops abbrechen, GPTBot und PerplexityBot bei fünf, Googlebot bei zehn (CaptainDNS, 2026).
• Ein pauschaler Redirect auf die Startseite. Ein Redirect auf eine Seite, die kein enges Äquivalent ist, wird als Soft-404 behandelt: Das Ziel erbt nichts, die Quelle wird fallengelassen. Das sagt Google selbst in seiner Dokumentation zum Site-Umzug.
• Interne Links, die still verschwunden sind. Ein Theme liefert Hunderte, die nie jemand gezählt hat — Blöcke mit verwandten Beiträgen, Archive, Sidebars, Breadcrumbs, Pagination. Ein Rebuild liefert die Links, die ein Designer eingezeichnet hat. Seiten, die zwanzig bekamen, bekommen jetzt zwei — und ranken entsprechend.
• Umgeschriebene Titel und H1s. Ändern Sie an dem Tag, an dem sich jede URL ändert, auch noch jedes Titelmuster, werden Sie nie wissen, welche Änderung was bewegt hat.
• Textkörper, der erst nach der Hydration existiert. Googlebot rendert JavaScript; fast nichts sonst tut das. Instrumentierte Tests fanden, dass GPTBot bei rund 11,5 % der Anfragen JavaScript herunterlädt und ClaudeBot bei 23,8 % — und es nie ausführt (SearchOptimo, 2026). Text, der erst beim Mount geladen wird, ist Text, den Bing nicht liest.
• Langsame TTFB bei kaltem Cache. WordPress hinter einem Page-Cache antwortet in Millisekunden; eine Route, die bei Bedarf revalidiert und ein CMS auf einer kalten Instanz aufruft, braucht Sekunden, und die Crawl-Statistik verzeichnet das als steigende durchschnittliche Antwortzeit.

Nichts davon zeigt sich in einem Design-Review. Alles davon zeigt sich in einem Crawl-Diff — deshalb behandle ich einen Plattformwechsel als Migrationsprojekt.

Wie erstellen Sie zuerst eine vollständige URL-Inventur?

Nehmen Sie die Vereinigung von sechs Quellen, nicht nur eine. Die Sitemap listet, was WordPress Ihnen zeigen will; die Inventur listet, was tatsächlich etwas einbringt. Bei jeder Migration, die ich durchgeführt habe, war die Sitemap die kleinste der sechs Quellen.

1. Search Console → Leistung → Seiten, über die vollen 16 Monate. Ihre Liste rankender URLs und Ihre Vorher-Baseline: Klicks, Impressionen, Position, CTR.
2. Search Console → Seitenindexierung, jeder Status, einschließlich Gecrawlt — zurzeit nicht indexiert und Duplikat ohne vom Nutzer festgelegten kanonischen URL. Google kennt diese; Ihre Sitemap listet sie nicht.
3. Jede Sitemap, die WordPress veröffentlicht. Yoast und Rank Math teilen Beitrags-, Seiten-, Kategorie-, Tag-, Autor-, Produkt- und Anhang-Indizes auf. Gehen Sie /sitemap_index.xml durch; verlassen Sie sich nie auf eine einzelne Datei.
4. Ein vollständiger Crawl mit Screaming Frog oder Sitebulb: JavaScript aus, nofollow gefolgt, kein Limit. Exportieren Sie auch den Bericht zu internen Links — Sie brauchen den Link-Graphen, nicht nur Adressen.
5. Server-Logs, 30 bis 90 Tage, gefiltert auf Googlebot und Bingbot. Die einzige Quelle, die URLs findet, die immer noch gecrawlt werden, obwohl sie keinen eingehenden Link und keinen Sitemap-Eintrag haben.
6. Search Console → Links → Meistverlinkte Seiten. Externe Links zeigen auf URLs, die Ihr Crawler nie erreicht, und genau deren Redirects zählen am meisten.

Normalisieren Sie die sechs Quellen in ein Sheet, indiziert nach Pfad, bereinigen Sie Groß-/Kleinschreibung und Trailing Slash, und erfassen Sie pro URL: Statuscode, Canonical, 16-Monats-Impressionen, eingehende interne Links. Dieses Sheet ist die Migration.

Wie bauen Sie ein 1:1-301-Mapping, das nie kettet?

Eine Legacy-URL, eine Regel, ein Hop, ein 200. Das ist die gesamte Spezifikation. Schwierig wird es nur, weil WordPress URL-Formen erzeugt, die ein handgeschriebenes Mapping nie vorhersieht.

• /?p=123 und /?page_id=45 — permalink-unabhängige Formen, die weiterhin auflösen und immer noch in alten E-Mails und CRM-Vorlagen stecken.
• /category/…, /tag/…, /author/… — Archive, die oft Rankings halten und nach einem Rebuild kein offensichtliches Äquivalent haben.
• /feed/, /comments/feed/, /wp-json/…, /xmlrpc.php — maschinelle Endpunkte, die externe Dienste weiterhin abfragen.
• /some-post/amp/ — indexiert, falls das AMP-Plugin jemals aktiv war, egal ob sich noch jemand daran erinnert.
• Query-Strings: ?replytocom=, WooCommerce ?add-to-cart=, Elementor ?elementor-preview=. Die verwaisten Redirects — 200 bei WordPress, danach stiller 404.
• /wp-content/uploads/2019/06/photo.jpg und Anhangsseiten wie /some-post/photo/ — Bild-Rankings und dünn indexierte URLs.

Dann der Trailing Slash. WordPress liefert /about/; Next.js liefert /about und leitet die Slash-Form per 308 weiter. Bilden Sie nur die Quelle ohne Slash ab, und jeder alte eingehende Link erhält eine Zwei-Hop-Kette. Bilden Sie beide auf das endgültige Ziel ab, und testen Sie beide mit curl -I.

// next.config.ts — Next.js 16
import type {NextConfig} from 'next';

// Generated from the inventory sheet by a script, never typed by hand:
// { '/2019/06/old-post-slug': '/blog/new-post-slug', ... }
import {LEGACY_URLS} from './src/lib/legacy-urls';

const exact = Object.entries(LEGACY_URLS).flatMap(([from, to]) => [
  // permanent: true emits 308. Use statusCode when you want the literal 301
  // that old logs, analytics filters and link checkers expect — Google and
  // Bing treat 301 and 308 identically, but your tooling may not.
  {source: from, destination: to, statusCode: 301},
  // WordPress served the trailing-slash form. Send it straight to the final
  // destination so an old inbound link resolves in ONE hop, not two.
  {source: `${from}/`, destination: to, statusCode: 301}
]);

const nextConfig: NextConfig = {
  // Decide the slash policy once, here, so nothing adds an implicit hop.
  trailingSlash: false,

  async redirects() {
    return [
      // Exact matches first: a specific rule must always beat a pattern.
      ...exact,

      // Shapes, not pages.
      {source: '/category/:slug', destination: '/blog/topic/:slug', statusCode: 301},
      {source: '/:path*/amp', destination: '/:path*', statusCode: 301},
      {source: '/feed', destination: '/rss.xml', statusCode: 301},

      // Image URLs carry Google Images rankings of their own. They have file
      // extensions, so they never reach proxy.ts — handle them here.
      {
        source: '/wp-content/uploads/:path*',
        destination: '/media/:path*',
        statusCode: 301
      }
    ];
  }
};

export default nextConfig;

Ab etwa tausend exakten Regeln verschieben Sie das Lookup in proxy.ts — die Datei, die Next.js 16 von middleware.ts umbenannt hat. Ein Hash-Map-Lookup läuft in konstanter Zeit, und es ist der einzige sinnvolle Ort, um ?p=123 aufzulösen, weil dieses Mapping Daten sind, kein Muster.

// src/proxy.ts — Next.js 16 renamed middleware.ts to proxy.ts.
import {NextResponse, type NextRequest} from 'next/server';
import {LEGACY_URLS, LEGACY_POST_IDS} from '@/lib/legacy-urls';

export function proxy(request: NextRequest) {
  const {pathname, searchParams} = request.nextUrl;

  // /?p=123 and /?page_id=45 — the ID form WordPress never stops serving.
  const id = searchParams.get('p') ?? searchParams.get('page_id');
  const byId = id ? LEGACY_POST_IDS[id] : undefined;

  // Slash-insensitive key so /about/ and /about hit the same entry, and both
  // land on the destination in a single hop.
  const key = pathname.length > 1 ? pathname.replace(/\/$/, '') : pathname;
  const destination = byId ?? LEGACY_URLS[key];

  if (destination) {
    return NextResponse.redirect(new URL(destination, request.url), 301);
  }

  return NextResponse.next();
}

export const config = {
  // Never run the map over assets or route handlers: a redirect rule that
  // catches /_next/static is an outage, not a ranking problem.
  matcher: ['/((?!api(?:/|$)|_next/|_vercel/|.*\\..*).*)']
};

Wie übertragen sich Titel, Canonicals und Schema ohne Drift?

Als Export, nicht als Neuschrieb. Yoast und Rank Math speichern Titel und Beschreibungen pro Beitrag in wp_postmeta, erreichbar über die REST-API oder eine einzige SQL-Abfrage. Dieser Export wird zu einer Fixture, die der Build ausliest, sodass generateMetadata denselben String zurückgibt, den die alte Seite zurückgab, Zeichen für Zeichen. Verbessern Sie den Text erst danach, wenn der Effekt zuordenbar ist.

• Setzen Sie `metadataBase` im Root-Layout auf den absoluten Produktions-Origin. Ohne das lösen Canonicals und Open-Graph-URLs gegen den jeweils ausliefernden Host auf — auf Staging bedeutet das Canonicals, die auf die Staging-Domain zeigen. Der klassische Weg, sich selbst eine Stunde nach dem Launch zu deindexieren.
• Canonicals müssen absolut, selbstreferenziell und auf dem ausliefernden Host sein. Google gleicht eine Abweichung notdürftig aus; Bing nicht. Widersprüchliche Canonicals sind eine dokumentierte Ursache dafür, dass Bing die falsche URL oder gar nichts indexiert (Microsoft Q&A, 2026).
• Robots-Direktiven in beide Richtungen prüfen. Was noindex war, bleibt noindex; dringender noch: nichts anderes wird es. Ein staging-weites noindex, das in Produktion ausgeliefert wird, ist die häufigste Einzelursache für kompletten Traffic-Verlust.
• Strukturierte Daten müssen übereinstimmen oder besser werden. Yoast erzeugt einen @graph mit Organization-, WebSite-, WebPage-, BreadcrumbList- und Article-Knoten. Liefern Sie nur Organization aus, haben Sie die Breadcrumb-Rich-Results sitewide verloren. Vergleichen Sie Alt gegen Staging im Rich Results Test.
• hreflang, falls die Website es nutzt. Jedes Alternate reziprok, mit Selbstreferenz und x-default.

Was passiert mit internen Links, Bildern und Alt-Text?

Sie werden zur Build-Zeit über dasselbe Mapping neu geschrieben, das die Redirects steuert, sodass kein interner Link auf eine URL zeigt, die weitergeleitet werden muss. Extrahieren Sie beim Export jedes <a href> aus post_content, lösen Sie jedes über das Mapping auf, schreiben Sie es um, und crawlen Sie Staging danach erneut, um sicherzustellen, dass interne 3xx-Antworten null sind. Ein Link ohne Mapping ist ein Mapping-Fehler — reparieren Sie das Mapping, nicht den Link.

Vergleichen Sie dann Link-Anzahlen, nicht nur Gültigkeit. Verbinden Sie den Staging-Bericht zu eingehenden Links mit demselben Bericht der Live-Website. Eine URL, die zwanzig interne Links hatte und jetzt einen hat, hat das verloren, was sie ranken ließ, und kein Redirect gibt das zurück. Löschen Sie Kategorie- und Tag-Archive, müssen Sie die Links ersetzen, die sie trugen — ein Themen-Hub, einen Block mit verwandtem Content, ein Footer-Verzeichnis. Sich dagegen zu entscheiden ist legitim. Es nicht zu bemerken nicht.

Bilder tragen zwei Werte: das Ranking der Bild-URL in Google Images und den Alt-Text, der das Seitenthema beschreibt. Halten Sie /wp-content/uploads/… erreichbar oder leiten Sie es per 301 auf die neuen Asset-URLs weiter. Ziehen Sie den Alt-Text aus dem Meta-Key _wp_attachment_image_alt, statt ihn neu einzutippen, und setzen Sie explizites width und height bei jedem next/image, damit Sie kein Ranking-Problem gegen ein Layout-Shift-Problem eintauschen.

Wie beweisen Sie Parität auf Staging, bevor DNS umgestellt wird?

Crawlen Sie beide Websites und vergleichen Sie Spalte für Spalte: derselbe Crawler, derselbe User Agent, dieselbe Rendering-Einstellung, HTTP-Auth für Staging. Verbinden Sie die Exporte über das zugeordnete URL-Paar. Das Ergebnis ist eine Zeile pro URL mit einem Delta pro Spalte, und jedes Delta ungleich null wird behoben oder erklärt.

#!/usr/bin/env bash
# One hop, one 200, correct destination — for every row in the map.
# redirect-map.csv holds: old_path,new_path
# A URL whose path does not change should not be in the map at all.

BASE=https://staging.example.com

while IFS=, read -r old new; do
  read -r status hops final <<<"$(curl -sS -o /dev/null -L \
    -w '%{http_code} %{num_redirects} %{url_effective}' "${BASE}${old}")"

  if [ "$status" != "200" ] || [ "$hops" != "1" ] || [ "${final%%\?*}" != "${BASE}${new}" ]; then
    printf 'FAIL %-44s status=%s hops=%s landed=%s\n' "$old" "$status" "$hops" "$final"
  fi
done < redirect-map.csv

Wie sieht das Runbook für den Launch-Tag aus?

1. 1

   T-24 Std. — DNS-TTL senken, Content einfrieren

   TTL auf 300 Sekunden setzen, damit ein Rollback nur Minuten dauert. Alles, was nach dem finalen Export veröffentlicht wird, existiert auf der neuen Website nicht.

2. 2

   T-1 Std. — Paritäts-Diff erneut ausführen

   Content und Code haben sich seit dem letzten Lauf beide verändert. Gehen Sie von nichts aus, was Sie heute nicht neu gemessen haben.

3. 3

   T-0 — Umschalten, von außen verifizieren

   Rufen Sie 50 Ihrer Legacy-URLs mit den höchsten Impressionen von einer Maschine ab, die die Website nie gesehen hat, und stellen Sie sicher, dass ein Hop zu einem 200 führt — nicht vom Browser, in dem Sie die ganze Woche getestet haben.

4. 4

   T+15 Min. — robots.txt, Sitemaps, Firewall

   Bestätigen Sie, dass die Produktions-robots.txt nicht das Deny-all von Staging ist, reichen Sie neue Sitemaps in Search Console und Bing Webmaster Tools ein, und setzen Sie die Bot-Regeln des Hosts in den reinen Log-Modus. Anagram-Crawlbarkeitsdaten von 2026 fanden, dass 17,6 % der Top-Websites, die GPTBot in robots.txt erlauben, ihm in der Praxis 403 liefern — und ein verwaltetes WAF-Regelwerk ist typischerweise die Ursache.

5. 5

   T+1 Std. — die alte Sitemap live lassen

   Liefern Sie sie mit den alten URLs noch ein paar Wochen weiter aus, wenn Sie noch Kontrolle darüber haben. Googles Leitfaden zum Site-Umzug sagt, das beschleunigt das Auffinden der Redirects.

6. 6

   T+2 Std. — Analytics, Tags, Conversions

   GA4, GTM und Ad-Pixel feuern auf den neuen Templates mit denselben Event-Namen. Tracking-Parität ist Teil der Migrationsparität.

7. 7

   T+24 Std. — erster Blick auf die Crawl-Statistik

   Search Console → Einstellungen → Crawling-Statistiken. Steigende erfolgreiche Anfragen, kein Ausschlag bei 404 oder 5xx, Antwortzeit im Bereich vor dem Launch.

Bewusst ausgelassen: das Adressänderungs-Tool. Es gilt nur, wenn sich die Domain selbst ändert.

Was überwachen Sie 30 Tage nach dem Launch?

Täglich in Woche eins, danach zweimal wöchentlich, immer gegen die Baseline, die Sie vor dem Launch exportiert haben. Die Aufgabe ist, normales Re-Crawl-Rauschen von einem echten Problem zu trennen.

• Seitenindexierung. Achten Sie auf Gründe, nicht auf Summen. Steigt Seite mit Weiterleitung, ist das korrekt — Google arbeitet sich durch Ihr Mapping. Steigt Nicht gefunden (404), heißt das, Sie haben eine URL-Form übersehen. Duplikat, Google hat einen anderen kanonischen URL ausgewählt heißt, Canonicals und Redirects widersprechen sich.
• Crawling-Statistiken. Die durchschnittliche Antwortzeit ist Ihr TTFB-Signal. Steigt sie, lässt die Revalidierung Crawler für Cache-Misses bezahlen; verschieben Sie teure Routen auf statische Generierung.
• Performance, Seite für Seite gegen den 16-Monats-Export. Vergleichen Sie jede neue URL mit ihrem zugeordneten Vorgänger, nie mit der Gesamtsumme der Website — Summen verstecken eine Seite, die alles verloren hat, hinter einer Seite, die gewonnen hat.
• Bing Webmaster Tools. Verifizieren Sie die Property vor dem Launch, sonst verbringen Sie die kritische Woche blind. URL-Prüfung an zehn zugeordneten URLs, Sitemap auf dem richtigen Host erneut einreichen, und lesen Sie den AI-Performance-Bericht, den Microsoft am 9. Februar 2026 gestartet hat — die einzigen First-Party-Daten zu Zitaten durch Antwortmaschinen.
• Logs erneut. Bot-Zugriffe nach Statuscode nach Tag. Feuert ein 301 nach dem ersten Monat immer noch tausende Male pro Woche, verlinkt bei Ihnen selbst noch etwas auf alte URLs.

Ein Einbruch in den Wochen eins und zwei ist normal, während das Mapping neu verarbeitet wird. Nicht normal ist, wenn sich die Impressionen erholen, während die durchschnittliche Position schlechter bleibt als die Baseline: Die URLs wurden gefunden, aber die Seiten werden anders bewertet. Das deutet eher auf Content-, Titel- und H1-Änderungen hin als auf Redirects.

Wie sah das bei einer echten Migration aus?

Die Migration, auf die ich mich am häufigsten beziehe, war kein WordPress. Es war der PHP-Laravel-Monolith hinter Thrifty in den VAE, den ich als Senior Developer bei Thrifty Car Rental UAE auf Next.js umgezogen habe. Im selben Zeitraum wurde das .NET-Backend hinter Dollar durch sechs gemeinsam genutzte Node.js-Microservices ersetzt. Anderer Quell-Stack, identisches Verfahren, und der Grund, warum ich ihm vertraue: kein Ranking-Verlust.

Die Teile, die die eigentliche Arbeit leisteten, waren unglamourös. Die Inventur kam aus Search Console, den Plattform-Sitemaps und den Server-Logs — die Logs brachten Query-String-URLs ans Licht, die die alte Anwendung jahrelang still ausgeliefert hatte. Redirects wurden aus diesem Sheet generiert, nicht von Hand geschrieben. Metadaten kamen als Export herüber, sodass Titel am ersten Tag identisch waren. Das Launch-Gate war der Paritäts-Diff mit einer schriftlichen Liste erlaubter Deltas. Dieselbe Methode steckt hinter Cariva, 326 serverseitig gerenderten SEO-Seiten — serverseitig gerendert, damit der Text im HTML steht, für Bing und für Crawler, die nie JavaScript ausführen.

Wenn Sie das für Ihre Website wollen, ist das der Service SEO-sichere Migration und Rebuild, und das meiste von dem, was Next.js-Entwicklung in der Praxis bedeutet. Jedes Projekt beginnt mit einem ersten Projektgespräch: Ich crawle, was Sie haben, und sage Ihnen, wo das Risiko liegt. Schicken Sie mir die Domain.