WordPress zu Headless Next.js migrieren: Eine schrittweise Migration ohne SEO-Autoritaetsverlust

Ein mittelstaendisches europaeisches Unternehmen, das zehn Jahre damit verbracht hat, Domaenauthoritaet 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 Beitraege, Dutzende von Custom Post Types und einen Plugin-Stack angesammelt, bei dem einem WordPress-Entwickler die Kinnlade runterklaeppt.

Das Argument fuer eine WordPress-zu-Next.js-Migration ist ueberzeugend: dramatisch schnellere Seiten, richtige React-Komponentenarchitektur, zuverlaessige TypeScript-Typen, keine PHP-Plugin-Konflikte und die Moeglichkeit, 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 Haelfte der kanonischen URLs still geaendert hat oder der neue Sitemap dreihundert Beitraege 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 fuer Seite migrieren und die Legacy-Seite erst abschalten, wenn jede URL, jede Weiterleitung und jedes strukturierte Datenelement in der Produktion verifiziert ist.

Warum naive Neuaufbauten Rankings zerstoeren

Bevor es in die Mechanik geht, lohnt es sich zu verstehen, was waehrend einer Migration wirklich SEO-Schaeden verursacht.

Der haeufigste Killer ist eine URL-Aenderung ohne Weiterleitung. Ein E-Commerce-Unternehmen baut seine Produktseiten neu auf und aendert /shop/produktname zu /products/produktname. Jeder externe Link, jedes Lesezeichen, jeder Google-Index-Eintrag fuehrt jetzt auf eine 404 oder loest sich still auf eine andere URL auf, ohne 301. Die ueber Jahre aufgebaute Domaenauthoritaet evaporiert, weil der Link-Graph, der auf die alten URLs zeigt, nirgendwohin Sinnvolles mehr fuehrt.

Der zweite Killer ist Crawl-Verwirrung waehrend des Uebergangs. 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 aendert, den XML-Sitemap temporaer entfernt oder waehrend eines stufenweisen Rollouts inkonsistente Canonical-Tags zurueckgibt, verbringt der Crawler moeglicherweise 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 ueberspringen 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 druecken, selbst wenn alles andere korrekt laeuft.

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. Fuer 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 unveraendert. Der Crawler sieht weiterhin gueltige 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 fuer den Proxy-Hop - in der Praxis vernachlaessigbar.

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 waechst im Laufe der Zeit, wenn Routen zu Next.js verschoben werden. Das WordPress-Backend wird zu einem rein internen Dienst - es verarbeitet keinen oeffentlichen Traffic mehr und muss nach Abschluss der Migration nicht mehr im Internet zugaenglich sein.

Die Treue von 301-Weiterleitungen erhalten

Wenn deine WordPress-Seite ueber die Jahre Weiterleitungen angesammelt hat - ob vom Redirection-Plugin, Yoast, .htaccess oder einer Kombination - muessen 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 vollstaendige 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,
    }))
  },
}

Fuer Seiten mit Hunderten von Weiterleitungen haelt dieser Ansatz die Liste pruefbar, versionskontrolliert und vom SEO-Team ueberprueifbar, ohne dass fuer jede Aenderung ein Entwickler benoetigt wird. Die Weiterleitsungstreue 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 unterschaetzen. 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 moeglicherweise 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 moechtest, 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 moeglicherweise weiterhin in WordPress bearbeiten moechte oder nicht.

Der Weg des geringsten Widerstands ist, WordPress als Headless-CMS zu behalten und CPTs ueber die WordPress-REST-API oder WPGraphQL zugaenglich zu machen. Deine Next.js-Seiten rufen zur Build-Zeit (fuer statische Inhalte) oder zur Anforderungszeit (fuer personalisierte oder haeufig aktualisierte Inhalte) von der WordPress-API ab. WordPress bleibt die redaktionelle Oberflaeche; 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 vollstaendig aus WordPress herauszumigrieren, tue es nach CPT statt alles auf einmal. Exportiere die Beitraege, importiere sie in den neuen Store, verifiziere, dass die kanonischen URLs unveraendert sind, dann entferne den CPT aus der Proxy-Konfiguration.

Core Web Vitals, die Rankings tatsaechlich 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 tatsaechlich 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 fuer das groesste 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, spaet ladende Web-Fonts oder dynamisch eingefuegte Banner und Cookie-Hinweise verursacht, die Inhalte nach dem Paint verschieben. In Next.js eliminiert explizites width und height bei jedem next/image die haeufigste CLS-Quelle. Fuer Fonts verwende next/font mit display: swap und aktiviertem Preload.

INP ersetzt seit 2024 First Input Delay und misst die Reaktionsfaehigkeit auf alle Interaktionen, nicht nur die erste. Exzessives Client-seitiges JavaScript ist die primaere Ursache fuer schlechten INP. Analysiere dein Bundle mit @next/bundle-analyzer und verschiebe oder entferne ruecksichtslos JavaScript, das nicht fuer das initiale Rendering benoetigt wird. Drittanbieter-Skripte - Analytics, Chat-Widgets, A/B-Test-SDKs - sind oft die schlimmsten Uebeltaeter und sollten mit strategy="lazyOnload" ueber next/script laden.

Die Cut-Over-Sequenz

Den endgueltigen Cut-Over zu timen - wenn das WordPress-Backend aufhoert, oeffentlichen 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. Fuehre den Cut-Over nicht durch, bis jede URL mit Indexierungsdaten in GSC ein 200 von der Next.js-Anwendung zurueckgibt.
2. Den Sitemap verifizieren, den Next.js generiert, und sicherstellen, dass er URL fuer URL mit dem WordPress-Sitemap uebereinstimmt. 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 zugaenglich sein wird), ist ein schwer zu diagnostizierendes Problem.
4. Das WordPress-Backend einfrieren bevor du es abschaltest. Stoppe neue Inhalte in WordPress, waehrend 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 fuer die ersten 30 Tage im Auge behalten. Crawl-Raten-Aenderungen, Impression-Einbrueche 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 zurueckfuehren, wenn in der Produktion etwas Unerwartetes auftaucht.

Was die Migration nicht behebt

Das Replatforming zu Next.js loest Performance-, Architektur- und Entwicklererfahrungsprobleme. Es behebt keine duennen Inhalte, keine doppelten Inhalte oder ein seit Jahren vernachlaessigtes 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 Autoritaetssignale 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 Plattformaenderung.

Wann externe Hilfe gefragt ist

Eine WordPress-zu-Next.js-Migration einer Seite mit etablierter SEO-Autoritaet ist kein Wochenendprojekt. Die Reverse-Proxy-Architektur ist einfach einzurichten, erfordert aber ueber Wochen der Route-fuer-Route-Migration anhaltende Detailgenauigkeit. Die Kosten eines Fehlers - ein verlorener Canonical, eine fehlende 301, eine CWV-Regression - koennen die Vorteile der neuen Plattform fuer Monate aufwiegen.

Wolf-Tech hilft mittelstaendischen europaeischen Unternehmen durch genau diese Art von Legacy-Code-Optimierung und digitaler Transformation. Wir haben dieses Playbook fuer Unternehmen mit fuenf Jahren SEO-Autoritaet und fuer solche mit fuenfzehn Jahren durchgefuehrt, in Maerkten, wo ein Ranking-Abfall von zehn Positionen ein materielles Umsatzereignis ist. Wenn du ein Replatforming-Projekt planst und eine externe Ueberpruefung deiner Migrationsstrategie moechtest, bevor du anfaengst, oder wenn du mitten in einer Migration steckst und etwas nicht wie erwartet laeuft, kontaktiere uns unter hello@wolf-tech.io oder besuche wolf-tech.io, um eine Beratung zu vereinbaren.