Von WordPress zu Next.js migrieren: Schritt-für-Schritt-Guide 2026

WordPress betreibt 2026 immer noch 43% des Webs, doch die Grenzen zeigen sich schnell: mäßige Out-of-the-box-Performance (typisch TTFB 600-1500ms), große Angriffsfläche (43% der Web-Hacks zielen laut Sucuri 2024 auf WordPress), Plugin-Abhängigkeit, versteckte Update-Kosten. Für viele KMUs, die wir bei OptionWeb betreuen, lautet die Frage nicht mehr 'sollen wir migrieren?', sondern 'wie migrieren wir, ohne SEO zu verlieren?'. Hier das vollständige Playbook aus 30+ Migrationen.

1. Warum migrieren (und wann nicht)

Migration lohnt sich in 4 Fällen: geschäftskritische Performance (E-Commerce, aggressives Lead-Gen), ohnehin geplantes großes Redesign, Tech-Team, das aus der Legacy-Plugin-Hölle raus will, oder Bedarf an internationaler Skalierung (natives Next.js i18n schlägt WPML/Polylang).

Nicht migrieren, wenn: nicht-technisches Redaktionsteam ohne CMS-Alternative, Budget < 10.000 €, Redesign nur, um 'modern zu sein' (echter Grund unsichtbar), oder Site mit >100 kritischen Plugins ohne Next.js-Pendant.

2. Vorabaudit der WordPress-Site

Das Audit ist der am meisten vernachlässigte und kritischste Schritt. Diese Phase überspringen = garantierter SEO-Verlust und Bugs in Produktion.

Tools für ein vollständiges Audit:

• Screaming Frog SEO Spider — Crawl aller URLs (kostenlos bis 500 URLs, £159/Jahr darüber). CSV-Export von URLs, Statuscodes, Meta-Tags, H1, internen Links.
• Google Search Console — Export der 1000 leistungsstärksten Queries + Landingpages. Identifiziert URLs, die unbedingt erhalten werden müssen.
• Wayback Machine — Historischer Snapshot der Site als Design- und Content-Referenz.
• WordPress phpMyAdmin — Inventur von Custom Post Types, Meta-Feldern, Taxonomien, Kommentaren.
• Google Analytics 4 — Top-50 Seiten nach Sessions, Nutzerverhalten, Bounce Rate. Diese Seiten müssen nach der Migration unbedingt funktionieren.

Audit-Lieferungen: Excel-Tabelle mit allen URLs (alt + neu), Liste kritischer Plugins mit Next.js-Alternativen, Medien-Inventar (Gesamtgröße, Formate), Liste externer Integrationen (Zahlung, CRM, Mailing, Chat), Skizze der neuen URL-Struktur.

3. Content-Export

Drei Methoden je nach Volumen und Komplexität:

Bei OptionWeb kombinieren wir WP REST API (strukturierter Content) + Node.js-Skript für parallelen Medien-Download. Beiträge werden je nach Zielarchitektur in MDX oder JSON konvertiert. Rechne mit 1-2 Tagen für 500 Beiträge.

import fs from 'node:fs/promises';
import path from 'node:path';

const WP_API = 'https://votre-site.com/wp-json/wp/v2';

async function fetchAllPosts() {
  const allPosts = [];
  let page = 1;
  while (true) {
    const res = await fetch(`${WP_API}/posts?per_page=100&page=${page}&_embed`);
    if (!res.ok) break;
    const posts = await res.json();
    if (posts.length === 0) break;
    allPosts.push(...posts);
    page++;
  }
  return allPosts;
}

const posts = await fetchAllPosts();
await fs.writeFile('content/posts.json', JSON.stringify(posts, null, 2));

4. Ziel-Architektur Next.js

Empfehlung 2026 für die Migration WordPress → Next.js: App Router + statischer Export. Vorteile: Deployment auf jedem Server (kein Node.js nötig), TTFB im Millisekundenbereich, immun gegen WordPress-Lücken, unbegrenzte Skalierbarkeit.

/** @type {import('next').NextConfig} */
const nextConfig = {
  output: 'export',
  images: { unoptimized: true },
  trailingSlash: true,
  i18n: undefined, // gérer via app/[lang]/ pour static export
};
export default nextConfig;

Empfohlene Ordnerstruktur:

• app/[lang]/ — Mehrsprachige Routen, page.tsx, [slug]/page.tsx, blog/page.tsx, blog/[slug]/page.tsx
• content/ — JSON oder MDX des migrierten Contents, mit Zod-Schema für Build-Validierung
• components/ — React-Komponenten (ersetzen Gutenberg-Blöcke)
• public/ — Aus wp-content/uploads/ migrierte Medien
• lib/ — Utilities (Markdown zu React, hreflang-Map etc.)

5. UI-Redesign und Komponenten

Fehler #1: das WordPress-Theme pixelgenau zu klonen versuchen. Lang, langweilig, und die Chance verpasst.

Empfohlener Ansatz: Wireframes je Seitentyp neu aufsetzen (Homepage, Service-Seite, Blogartikel, Kontakt usw.), mit Tailwind-Komponenten oder eigenem Design-System (shadcn/ui, Radix Themes) neu gestalten, moderne Animationen ergänzen (Framer Motion), mobile-first arbeiten.

6. Weiterleitungen 301 (SEO erhalten)

Der kritischste Punkt jeder Migration. Eine einzelne wichtige URL falsch weitergeleitet = verlorene Google-Positionen. Strikte Vorgehensweise:

1. Alle WordPress-URLs auflisten (Screaming Frog oder Google Analytics)
2. Nach organischem Traffic über 12 Monate sortieren (Fokus auf Top-80% des Traffics)
3. Jede alte URL der neuen Next.js-URL zuordnen
4. 301 in .htaccess (Apache) oder Next.js Rewrites + Cloudflare konfigurieren
5. Jede Zuordnung mit curl -I oder Screaming Frog im Redirect-Check-Modus testen
6. Neue Sitemap am Tag des Deployments an die Search Console senden
7. 404 in der Search Console 4-6 Wochen lang überwachen, fehlende Weiterleitungen ergänzen

RewriteEngine On

# Redirections 301 anciennes URLs WordPress
Redirect 301 /?p=123 /fr/article-titre-canonique/
Redirect 301 /category/seo /fr/blog/?cat=seo
Redirect 301 /author/admin /fr/equipe/

# Pattern WordPress permalinks date-based
RewriteRule ^([0-9]{4})/([0-9]{2})/([0-9]{2})/([^/]+)/?$ /fr/blog/$4/ [R=301,L]

7. Deployment und Validierung

Typischer Deployment-Plan:

Gemessene Gewinne nach der Migration

Typische Kennzahlen aus 30+ OptionWeb-Migrationen (KMU-Sites, 50-500 Seiten):

• TTFB — WordPress 600-1500ms → Next.js static 30-80ms (durch 10 geteilt)
• Lighthouse Performance — WordPress 45-65 → Next.js 95-100 mobil
• Lighthouse SEO — WordPress 85 (häufig) → Next.js systematisch 100/100
• Hosting-Kosten — Geteiltes WordPress 15 €/Monat → statischer Export auf CDN 5-10 €/Monat (Cloudflare Pages, Vercel free, Netlify free)
• Sicherheitslücken — Angriffsfläche durch ~50 geteilt (kein WP-Admin, keine DB, keine PHP-Ausführung)
• Organischer Traffic — +10 bis +30% über 3-6 Monate dank CWV-Gewinnen (Google-Ranking-Signale)