WordPress zu Headless Next.js migrieren: Eine schrittweise Migration ohne SEO-Autoritätsverlust

Ein mittelständisches europäisches Unternehmen, das zehn Jahre damit verbracht hat, Domänenautorität auf WordPress aufzubauen, nimmt Replatforming nicht auf die leichte Schulter. Die SEO-Zahlen sind real. Der organische Traffic konvertiert. Und irgendwo im letzten Jahrzehnt hat das Redaktionsteam tausend Beiträge, Dutzende von Custom Post Types und einen Plugin-Stack angesammelt, bei dem einem WordPress-Entwickler die Kinnlade runterklappt.

Das Argument für eine WordPress-zu-Next.js-Migration ist überzeugend: dramatisch schnellere Seiten, richtige React-Komponentenarchitektur, zuverlässige TypeScript-Typen, keine PHP-Plugin-Konflikte und die Möglichkeit, auf einem CDN-Edge-Netzwerk statt auf einem einzelnen Server in Frankfurt bereitzustellen. Aber das Misserfolgsmuster ist ebenso bekannt. Ein Team verbringt neun Monate mit dem Neuaufbau, launcht die neue Seite und beobachtet, wie ihre Rankings einbrechen, weil das Crawl-Budget verwirrt wird, sich die Hälfte der kanonischen URLs still geändert hat oder der neue Sitemap dreihundert Beiträge fehlen.

Es gibt einen besseren Weg. Dieser Beitrag beschreibt den schrittweisen Replatforming-Ansatz - Next.js via Reverse Proxy vor deine WordPress-Seite schalten, Routen Seite für Seite migrieren und die Legacy-Seite erst abschalten, wenn jede URL, jede Weiterleitung und jedes strukturierte Datenelement in der Produktion verifiziert ist. So vermeidest du einen SEO-Autoritätsverlust, wie ihn naive Neuaufbauten verursachen.

Warum naive Neuaufbauten Rankings zerstören

Bevor es in die Mechanik geht, lohnt es sich zu verstehen, was während einer Migration wirklich SEO-Schäden verursacht.

Der häufigste Killer ist eine URL-Änderung ohne Weiterleitung. Ein E-Commerce-Unternehmen baut seine Produktseiten neu auf und ändert /shop/produktname zu /products/produktname. Jeder externe Link, jedes Lesezeichen, jeder Google-Index-Eintrag führt jetzt auf eine 404 oder löst sich still auf eine andere URL auf, ohne 301. Die über Jahre aufgebaute Domänenautorität evaporiert, weil der Link-Graph, der auf die alten URLs zeigt, nirgendwohin Sinnvolles mehr führt.

Der zweite Killer ist Crawl-Verwirrung während des Übergangs. Google crawlt deine gesamte Seite nicht an dem Tag neu, an dem du launchst. Es hat ein Crawl-Budget und priorisiert URLs, die es schon gesehen hat. Wenn deine neue Seite die Sitemap-Struktur ändert, den XML-Sitemap temporär entfernt oder während eines stufenweisen Rollouts inkonsistente Canonical-Tags zurückgibt, verbringt der Crawler möglicherweise Wochen damit, die falsche Version deiner Inhalte zu indexieren.

Der dritte ist Core Web Vitals Regression. Viele Teams migrieren zu Next.js und erwarten Performance-Gewinne, erhalten sie aber nicht, weil sie zu viele Client-seitige JS-Bundles inline einbetten, die Bildoptimierung überspringen oder ein Drittanbieter-Tag auf jeder Seite laden lassen. Google verwendet Core Web Vitals nun als Ranking-Signal. Eine Migration, die CWV verschlechtert, kann Rankings drücken, selbst wenn alles andere korrekt läuft.

Alle drei Misserfolgsmuster sind mit dem inkrementellen Reverse-Proxy-Ansatz vermeidbar.

Die Reverse-Proxy-Architektur

Die Grundidee ist einfach: Next.js vor WordPress schalten, anstatt es auf einmal zu ersetzen. Deine Domain zeigt auf eine Next.js-Anwendung. Diese Anwendung behandelt die bereits migrierten Routen nativ. Für jede Route, die noch nicht migriert wurde, leitet sie die Anfrage transparent an das WordPress-Backend weiter.

Aus Googles Perspektive gibt es eine einzelne Website. Die URL-Struktur ist unverändert. Der Crawler sieht weiterhin gültige Antworten an jeder URL, die er indexiert hat. Aus der Nutzerperspektive laden migrierte Seiten deutlich schneller, da sie von Next.js mit voller App-Router-Optimierung bereitgestellt werden. Noch nicht migrierte Seiten laden von WordPress mit ein, zwei Millisekunden Mehraufwand für den Proxy-Hop - in der Praxis vernachlässigbar.

Im Next.js App Router lebt diese Proxy-Schicht in middleware.ts:

// middleware.ts
import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'

const MIGRATED_ROUTES = new Set([
  '/',
  '/about',
  '/services',
  '/blog',
])

const MIGRATED_PREFIXES = [
  '/blog/',
  '/services/',
]

const WP_ORIGIN = process.env.WP_ORIGIN // z.B. https://wp-backend.internal

export function middleware(request: NextRequest) {
  const { pathname } = request.nextUrl

  const isMigrated =
    MIGRATED_ROUTES.has(pathname) ||
    MIGRATED_PREFIXES.some(prefix => pathname.startsWith(prefix))

  if (isMigrated) {
    return NextResponse.next()
  }

  // Nicht migrierte Routen an WordPress weiterleiten
  const target = new URL(pathname + request.nextUrl.search, WP_ORIGIN)
  return NextResponse.rewrite(target)
}

export const config = {
  matcher: ['/((?!_next/static|_next/image|favicon.ico).*)'],
}

Dieser Code muss nicht raffiniert sein. Das migrierte Set wächst im Laufe der Zeit, wenn Routen zu Next.js verschoben werden. Das WordPress-Backend wird zu einem rein internen Dienst - es verarbeitet keinen öffentlichen Traffic mehr und muss nach Abschluss der Migration nicht mehr im Internet zugänglich sein.

Die Treue von 301-Weiterleitungen erhalten

Wenn deine WordPress-Seite über die Jahre Weiterleitungen angesammelt hat - ob vom Redirection-Plugin, Yoast, .htaccess oder einer Kombination - müssen diese vor Next.js portiert werden, bevor du jede Route umstellst.

Rate nicht, welche Weiterleitungen existieren. Exportiere sie. Das Redirection-Plugin hat einen JSON-Export. Deine Server-.htaccess kann geparst werden. Sobald du die vollständige Liste hast, lad sie in ein redirects-Array in next.config.ts:

// next.config.ts
const redirects = require('./redirects.json')

module.exports = {
  async redirects() {
    return redirects.map(({ source, destination, permanent }) => ({
      source,
      destination,
      permanent: permanent ?? true,
    }))
  },
}

Für Seiten mit Hunderten von Weiterleitungen hält dieser Ansatz die Liste prüfbar, versionskontrolliert und vom SEO-Team überprüfbar, ohne dass für jede Änderung ein Entwickler benötigt wird. Die Weiterleitungstreue vor jeder Routenmigration zu verifizieren, ist nicht verhandelbar - eine fehlende 301 ist in den Anwendungslogs stumm, aber in der Search Console sofort sichtbar.

Custom Post Types und ACF-Felder portieren

WordPress-Custom-Post-Types und Advanced Custom Fields sind der Teil der Migration, den Teams konsequent unterschätzen. Viele WordPress-Seiten haben ein Jahrzehnt redaktioneller Infrastruktur auf CPTs aufgebaut: Fallstudien, Teammitglieder, Produktspezifikationen, Veranstaltungslisten, Testimonials. Jeder hat einen Satz ACF-Felder, ein Template und möglicherweise eine benutzerdefinierte Abfrage, die eine Listenseite speist.

Die erste zu beantwortende Frage ist, ob du ein Headless-CMS (wie Contentful, Sanity oder Payload CMS) als neue Content-Schicht möchtest, oder ob du Inhalte direkt aus Next.js-Dateien oder einer eigenen Datenbank bereitstellst. Das ist keine rein technische Entscheidung - sie bezieht das Redaktionsteam ein, das möglicherweise weiterhin in WordPress bearbeiten möchte oder nicht.

Der Weg des geringsten Widerstands ist, WordPress als Headless-CMS zu behalten und CPTs über die WordPress-REST-API oder WPGraphQL zugänglich zu machen. Deine Next.js-Seiten rufen zur Build-Zeit (für statische Inhalte) oder zur Anforderungszeit (für personalisierte oder häufig aktualisierte Inhalte) von der WordPress-API ab. WordPress bleibt die redaktionelle Oberfläche; Next.js wird zur Rendering-Schicht.

// lib/wp-api.ts - Custom Post Type via WPGraphQL abrufen
export async function getCaseStudies(): Promise<CaseStudy[]> {
  const res = await fetch(process.env.WP_GRAPHQL_ENDPOINT!, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      query: `
        query GetCaseStudies {
          caseStudies(first: 100) {
            nodes {
              id
              title
              slug
              acfCaseStudy {
                client
                industry
                outcome
                techStack
              }
              featuredImage {
                node { sourceUrl altText }
              }
            }
          }
        }
      `,
    }),
    next: { revalidate: 3600 },
  })
  const { data } = await res.json()
  return data.caseStudies.nodes
}

Wenn du dich entscheidest, Inhalte vollständig aus WordPress herauszumigrieren, tue es nach CPT statt alles auf einmal. Exportiere die Beiträge, importiere sie in den neuen Store, verifiziere, dass die kanonischen URLs unverändert sind, dann entferne den CPT aus der Proxy-Konfiguration.

Core Web Vitals, die Rankings tatsächlich verbessern

Der gesamte Sinn des Wechsels von WordPress zu Next.js sind schnellere Seiten. Aber schnellere Seiten verbessern Rankings nur, wenn du die Metriken optimierst, die Google tatsächlich misst: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) und Cumulative Layout Shift (CLS).

LCP ist fast immer das Hero-Bild auf der Seite. Verwende next/image mit dem priority-Prop für das größte Above-the-Fold-Bild in jedem Template. Lass das nicht als Nachgedanken stehen - ein einzelner Template-Typ (Blogbeitrag, Produktseite, Fallstudie) mit einem nicht optimierten LCP-Bild zieht den Durchschnitt deiner gesamten Kategorie nach unten.

import Image from 'next/image'

// In deinem Blogbeitrag-Template
<Image
  src={post.featuredImage.url}
  alt={post.featuredImage.alt}
  width={1200}
  height={630}
  priority // LCP-Bild - sofort laden
  sizes="(max-width: 768px) 100vw, 1200px"
/>

CLS wird typischerweise durch Bilder ohne explizite Abmessungen, spät ladende Web-Fonts oder dynamisch eingefügte Banner und Cookie-Hinweise verursacht, die Inhalte nach dem Paint verschieben. In Next.js eliminiert explizites width und height bei jedem next/image die häufigste CLS-Quelle. Für Fonts verwende next/font mit display: swap und aktiviertem Preload.

INP ersetzt seit 2024 First Input Delay und misst die Reaktionsfähigkeit auf alle Interaktionen, nicht nur die erste. Exzessives Client-seitiges JavaScript ist die primäre Ursache für schlechten INP. Analysiere dein Bundle mit @next/bundle-analyzer und verschiebe oder entferne rücksichtslos JavaScript, das nicht für das initiale Rendering benötigt wird. Drittanbieter-Skripte - Analytics, Chat-Widgets, A/B-Test-SDKs - sind oft die schlimmsten Übeltäter und sollten mit strategy="lazyOnload" über next/script laden.

Die Cut-Over-Sequenz

Den endgültigen Cut-Over zu timen - wenn das WordPress-Backend aufhört, öffentlichen Traffic zu verarbeiten - erfordert Abstimmung zwischen deinem Entwickler, deinem SEO-Team und deinem Hosting-Setup.

Die Sequenz, die das Risiko minimiert:

1. Alle Routen migrieren durch den Reverse Proxy und jede einzelne in der Search Console verifizieren. Führe den Cut-Over nicht durch, bis jede URL mit Indexierungsdaten in GSC ein 200 von der Next.js-Anwendung zurückgibt.
2. Den Sitemap verifizieren, den Next.js generiert, und sicherstellen, dass er URL für URL mit dem WordPress-Sitemap übereinstimmt. Verwende ein Diff-Tool. Fehlende URLs vor dem Cut-Over sind behebbar; fehlende URLs, die nach dem Cut-Over entdeckt werden, haben bereits Signale an Google gesendet.
3. Canonical-Tags auditieren bei jedem Template. Der Canonical sollte immer auf die Produktionsdomain mit dem korrekten Slug zeigen. Ein falsch konfigurierter Canonical, der auf die WordPress-Backend-URL zeigt (die bald nur noch intern zugänglich sein wird), ist ein schwer zu diagnostizierendes Problem.
4. Das WordPress-Backend einfrieren bevor du es abschaltest. Stoppe neue Inhalte in WordPress, während du die letzte Charge von Routen migrierst. Ein Inhalts-Freeze von 24-48 Stunden ist akzeptabel; wochenlange Abweichungen zwischen dem WordPress-Entwurf und dem Next.js-Build sind es nicht.
5. Deployen, Search Console beobachten und CWV in Real-User-Monitoring für die ersten 30 Tage im Auge behalten. Crawl-Raten-Änderungen, Impression-Einbrüche und CWV-Regressionen sind alle in GSC innerhalb von Tagen nach dem Launch sichtbar.

Schalte DNS nicht um und nehme das WordPress-Backend dann sofort vom Netz. Behalte es mindestens 30 Tage lang intern als Fallback. Die Proxy-Konfiguration kann eine Route innerhalb von Sekunden zu WordPress zurückführen, wenn in der Produktion etwas Unerwartetes auftaucht.

Was die Migration nicht behebt

Das Replatforming zu Next.js löst Performance-, Architektur- und Entwicklererfahrungsprobleme. Es behebt keine dünnen Inhalte, keine doppelten Inhalte oder ein seit Jahren vernachlässigtes Backlink-Profil. Teams verwechseln manchmal "unsere WordPress-Seite ist langsam und knarrt" mit "unsere SEO-Strategie ist unterdurchschnittlich" und erwarten, dass die Migration beides behebt. Sie wird die technischen Signale beheben. Die Inhalts- und Autoritätssignale erfordern separate Arbeit.

Wenn deine Seite erhebliche Probleme mit doppelten Inhalten hat - Canonical-Verwirrung durch WordPress-Kategorien, Tags und Archivseiten, die mehrere Pfade zum selben Inhalt erzeugen - ist die Migration eine Gelegenheit, das zu bereinigen. Der Next.js-Sitemap sollte nur kanonische URLs enthalten. Aber die Bereinigung selbst ist redaktionelle Arbeit, keine Nebenwirkung der Plattformänderung.

Wann externe Hilfe gefragt ist

Eine WordPress-zu-Next.js-Migration einer Seite mit etablierter SEO-Autorität ist kein Wochenendprojekt. Die Reverse-Proxy-Architektur ist einfach einzurichten, erfordert aber über Wochen der Route-für-Route-Migration anhaltende Detailgenauigkeit. Die Kosten eines Fehlers - ein verlorener Canonical, eine fehlende 301, eine CWV-Regression - können die Vorteile der neuen Plattform für Monate aufwiegen.

Wolf-Tech hilft mittelständischen europäischen Unternehmen durch genau diese Art von Legacy-Code-Optimierung und digitaler Transformation. Wir haben dieses Playbook für Unternehmen mit fünf Jahren SEO-Autorität und für solche mit fünfzehn Jahren durchgeführt, in Märkten, wo ein Ranking-Abfall von zehn Positionen ein materielles Umsatzereignis ist. Wenn du ein Replatforming-Projekt planst und eine externe Überprüfung deiner Migrationsstrategie möchtest, bevor du anfängst, oder wenn du mitten in einer Migration steckst und etwas nicht wie erwartet läuft, kontaktiere uns unter hello@wolf-tech.io oder besuche wolf-tech.io, um eine Beratung zu vereinbaren.