WordPress zu Next.js migrieren: Checkliste für KMU im Rheinland

Eine Migration von WordPress zu Next.js ist kein Big-Bang-Projekt, sondern eine planbare Sequenz aus vier Phasen. Wer sie sauber durchgeht, behält sein Google-Ranking, verbessert die Core Web Vitals um über 30 % und kürzt das laufende Wartungsbudget spürbar.

Für KMU im Rheinland – Leverkusen, Köln, Düsseldorf, Langenfeld – ist der Schritt besonders relevant: die SEO-Konkurrenz ist dort hoch, und jede Sekunde Ladezeit ist ein Faktor.

Was eine Migration konkret bringt

Drei messbare Effekte aus realen Projekten in NRW:

• Performance: LCP von 4 s auf unter 1 s, INP unter 50 ms. Lighthouse 100 ist realistisch erreichbar.
• Wartung: Schluss mit 30+ Plugin-Updates pro Monat. Die Angriffsfläche verschwindet.
• Sicherheit: Keine WordPress-CVE-Risiken mehr im Stack. Kein Schadensszenario "kompromittiertes Plugin".

Was Sie nicht verlieren: bestehende URLs, eingehende Backlinks, das aufgebaute Google-Ranking. Das zieht mit um, wenn die Migration sauber gemacht ist.

Die vier Phasen einer sauberen Migration

Phase 1: Audit & Inventar (1 – 2 Tage)

• Vollständige URL-Liste aus XML-Sitemap und Google Search Console
• Plugin-Inventar: welche werden tatsächlich genutzt, welche sind Karteileichen
• Funktions-Inventar: Shop, Buchungsformulare, Newsletter, Kommentare, Membership
• SEO-Snapshot: aktuelle Rankings, Top-Traffic-Seiten, Backlink-Profil

Phase 2: Content-Migration (1 – 3 Tage)

• Export über WordPress REST API oder WP CLI
• Bilder nach WebP / AVIF konvertieren, <Image />-kompatibel ausliefern
• Strukturierte Daten (Article, LocalBusiness, FAQPage) neu modellieren
• Medienbibliothek in den neuen Storage (S3, Cloudflare R2, Vercel Blob)

Phase 3: Next.js-Frontend neu bauen (10 – 20 Tage)

• Komponenten, die das alte Theme nachbilden oder gezielt verbessern
• Server Components als Standard, Client Components nur dort, wo Interaktivität nötig ist
• Lighthouse-CI in der Pipeline – jeder Pull Request misst sich am Schwellenwert
• Accessibility-Tests gegen WCAG 2.1 AA

Phase 4: Launch ohne Ranking-Verlust (1 – 2 Tage)

• 301-Redirects für jede alte URL – auch für Anhänge und datierte Permalinks
• sitemap.xml an Search Console übermitteln, alte URL-Patterns deindexieren
• DNS-Cutover mit Rollback-Plan: TTL vorab senken, Staging einfrieren
• Crawl-Test gegen die Live-Domain mit Screaming Frog oder Sitebulb

Häufige Fehler – und wie man sie vermeidet

• URLs verändern ohne Redirect: Klassiker. Jede /?p=123- und Permalink-Variante braucht ein 301.
• Bilder unverschlüsselt umziehen: EXIF-Metadaten enthalten teils Geo-Daten – DSGVO-Thema, bevor sie in den neuen Storage landen.
• Tracking nicht neu konfigurieren: Consent Mode v2, GA4 oder Plausible werden oft vergessen und liefern wochenlang Datenmüll.
• Vor dem Launch nicht crawlen: Staging-Domain mit Basic Auth schützen, dann mit Screaming Frog testen. Findet 80 % aller Redirect-Lücken in zehn Minuten.

Realistisch: Zeit, Aufwand, Risiko

Richtwerte aus realen Migrationen:

• Brochure-Site bis ~50 Seiten: 3 – 4 Wochen
• Site mit Online-Shop (WooCommerce): 6 – 8 Wochen
• Komplexe Custom-Funktionen, Membership, mehrsprachig: 10+ Wochen

Das Risiko liegt nicht in der Technik – die ist beherrschbar. Es liegt in der Planung. Wer die ersten beiden Phasen abkürzt, baut die nächste Site, ohne zu wissen, was die alte enthält.

Audit statt Bauchgefühl

Bevor über Aufwand und Budget entschieden wird, gehört eine Bestandsaufnahme auf den Tisch: vollständige URL-Liste, Plugin-Inventar, SEO-Equity. Aus diesen Zahlen wird ein Migrationsplan, kein Pauschalangebot.

Schreiben Sie mir Ihre aktuelle WordPress-Adresse – Sie bekommen ein konkretes Audit innerhalb von zwei Werktagen, kostenfrei. Termine vor Ort in Leverkusen, Köln oder Düsseldorf nach Vereinbarung, sonst per Video-Call.