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

Ehrlich gesagt? Mostly weil Lighthouse nie ganz dort ankommt.

Ich habe viele Morgen damit verbracht, Gründern zu erklären, warum ihre liebevoll gebaute Elementor-Site in PageSpeed Insights hartnäckig bei 62 steckenbleibt, selbst nach drei Caching-Plugins, einem CDN und einem frischen Hosting-Wechsel. Es gibt eine Obergrenze. Du kannst eine klassische WordPress-Frontend in die niedrigen 80er treiben, wenn es dir wirklich wichtig ist, aber jedes Plugin-Update ist ein Regressionsrisiko und jede Page-Builder-Version bringt ein weiteres halbes Megabyte mit, das du nie angefordert hast.

Die Teams, die migrieren, fallen grob in drei Kategorien, und sie überlappen sich fast nie.

Der Performance-Bucket

Eine Serie-A-SaaS-Marketing-Website, derzeit auf WP Engine, zahlt für Elementor Pro plus drei Add-on-Pakete. Lighthouse 64 auf Mobile. INP bei 380 ms. Sie haben ein Content-Team, das zwei Posts pro Woche veröffentlicht, und ein Engineering-Team, das Onboarding-Flows deployen möchte, nicht WordPress-Patches. Der Next.js-Rebuild bringt sie auf 96, und die Engineers hören auf, wp-admin zu berühren.

Der Engineering-Bucket

Drei TypeScript-Engineers. Einer von ihnen ist für die Marketing-Website on call. Sie öffnen wp-admin einmal alle zwei Wochen und fluchen. Das ganze "Ist das PHP 7.4 oder 8.1, welche Version von WooCommerce hat uns die Agentur hinterlassen"-Spielchen ist eine Steuer auf Leute, die glücklich in Astro deployen würden mit der Hälfte der Kopfschmerzen. Migriert, gebt ihnen ein Next.js- oder Astro-Repo mit ordentlichem CI, und die On-Call-Rotation wird kleiner.

Der Security-Bucket

Seltener, aber entscheidender. Ein Board-Level-Mandat, dass öffentlich erreichbare Oberflächen kein PHP laufen sollten. Oder ein Security-Incident, bei dem ein gepatchtes Plugin drei Wochen zu spät deployed wurde. Headless WordPress auf einem nicht-öffentlichen Origin erfüllt die Policy, ohne das Editorial-Team zu zwingen, ein neues CMS zu lernen. Die wp.example.com geht private; das Front-End ist einfach eine Static Site auf Vercel. Die meisten Pen Tests werden uninteressant.

Drei. Wirklich drei, nicht die Marketing-Page-Art, die alle in den gleichen Scope zusammenfallen. Jeder passt zu einem anderen Team.

Path 1 — WordPress behalten, das Front-End ersetzen

Headless. WP bleibt die Editor-Oberfläche. Yoast macht weiter, was es in der Admin tut. ACF macht weiter, was es in der Admin tut. Die Public Site wird in Next.js oder Astro neu gebaut und zieht Content über WPGraphQL. Editoren bemerken den Migration Day kaum, außer dass die URL-Leiste die neue Front-End-Domain zeigt. Das ist der häufigste Path, den ich scope; etwa zwei Drittel der letzten Migrationen sind diesen Weg gegangen.

Wann ist es richtig: Das Editorial-Team ist glücklich in WordPress, das Engineering-Problem ist rein Front-End, und ihr wollt nicht zwölftausend Seiten Yoast-Metadaten migrieren.

Weg 2 — WordPress komplett verlassen

Migriere alles zu Sanity, Payload, Storyblok oder Contentful. Fahre WordPress beim Launch herunter. Neuere Codebasis, sauberes Content-Modell, kein PHP überall. Die Migrationskosten sind höher, weil du Content verschiebst, nicht nur das Frontend neu aufbaust. Es lohnt sich, wenn das Editorial-Team explizit aus WordPress raus will, oder wenn das Content-Modell mehr Strenge braucht, als ACF flexible content dir geben kann.

Wann es richtig ist: du willst wirklich ein anderes CMS, nicht einfach nur ein anderes Frontend.

Weg 3 — hybrid

Ein Teil des Contents bleibt in WordPress, ein Teil wandert woanders hin. Echtes Beispiel-Pattern: Blog bleibt in WP, weil das Editorial-Team erfahren ist und Yoast echte Arbeit leistet; Produktseiten wandern zu Payload, weil das Schema richtige Relations und Validierung braucht. Frontend ist eine Next.js-App, die von beiden Backends liest. Mehr Architektur, aber manchmal ist es die richtige Antwort.

Wann es richtig ist: zwei wirklich verschiedene Content-Formen auf der gleichen Seite, und sie in ein CMS zu zwingen macht jemandem das Leben schlechter.

Hier leben oder sterben Migrationen, und es ist auch der Teil, bei dem Teams routinemäßig sparen. Ohne eine vollständige Map verlierst du Rankings am ersten Tag. Mit einer unvollständigen Map verlierst du sie langsam über sechs Wochen, während du dir selbst erzählst, der Rückgang sei nur Saisonalität.

Die Map wird aus drei unabhängigen Quellen gebaut, bevor irgendwelcher Code deployed wird.

1. Search Console Export — jede URL, die Google in den letzten 16 Monaten gecrawlt und als indexierbar erachtet hat. Das ist die kanonische Liste dessen, was Google derzeit auf deiner Domain zu finden erwartet.
2. Ahrefs oder Semrush Export — jede URL mit mindestens einer verweisenden Domain, sortiert nach Anzahl der verweisenden Domains. Das sind die URLs, bei denen die 301-Erhaltung am wichtigsten ist. Wenn du eine Seite mit 200 Backlinks zu einer 404 machst, hast du gerade 200 Backlinks weggeworfen.
3. WordPress Sitemap — dein aktueller XML-Sitemap-Export. Erfasst Seiten, die möglicherweise keine Backlinks oder organischen Traffic haben, aber immer noch in der Struktur vorhanden sind. Nützlich als dritter Durchgang, um alles zu finden, das die ersten beiden übersehen haben.

Drei Listen, dedupliziert, auf neue URLs gemappt, als 301s in vercel.json oder netlify.toml am Edge bereitgestellt. Keine 302s. Keine JavaScript-gesteuerten Weiterleitungen. Kein Meta Refresh. URLs, die wirklich eingestellt werden, bekommen 410. URLs, deren Slug sich geändert hat, bekommen 301. Der Build-Linter schlägt den Deploy fehl, wenn eine URL vor der Migration in der Map fehlt.

Ich habe eine Migration mit 5.000 Seiten beobachtet, die 60% ihres organischen Traffics in acht Wochen verloren hat, weil die Weiterleitungskarte zu 87% vollständig war und „der Rest ist nicht der Mühe wert." Die 13% waren der Mühe wert. Das sind sie immer.

Plugin-Audit am ersten Tag. Jedes aktive Plugin landet in einem von vier Buckets, und der Bucket entscheidet über die Arbeit.

Bleibt wie es ist

Plugins, die serverseitig laufen und niemals das öffentliche Front-End berühren. WP Migrate DB, BackWPup, serverseitige Analysen, Rollenverwaltung. Sie funktionieren weiter, weil ihr Job nichts damit zu tun hat, HTML für einen Besucher zu rendern. Etwa 20-25% der Plugin-Anzahl fällt normalerweise hier an.

Ersetzt durch Code

Plugins, die HTML oder JavaScript in das Front-End injizieren. Die meisten SEO-Plugins (die Metadaten-Transporte, die Front-End-Ausgabe ist benutzerdefiniert). Die meisten Form-Plugins (ersetzt durch Next.js Endpoints oder durch ConvertKit / HubSpot / Mailchimp). Die meisten Schema-Plugins (ersetzt durch handgeschriebene Templates, die sauberer JSON-LD ausgeben). Cookie-Banner werden in TypeScript neu geschrieben. Etwa 30-40% der Plugin-Anzahl.

Durch Service ersetzt

Plugins, die ein Drittanbieter-Tool umhüllen. Das HubSpot-Embed-Plugin wird zu einem HubSpot Forms API-Aufruf. Das Stripe-Zahlungs-Plugin wird zu Stripe Elements. Zapier und Make bleiben wo sie sind, weil sie ohnehin außerhalb von WordPress leben. Etwa 10-15% des Gesamtaufkommens.

Komplett entfernt

Plugins, die nur existieren, weil das WordPress-Frontend sie benötigte. Caching-Plugins (Vercel übernimmt das). Die meisten Security-Plugins (die öffentliche Angriffsfläche ist weg). Performance-Optimierungs-Plugins (jetzt ein Build-Zeit-Problem). Und die immer lustigen „Ich habe keine Ahnung, warum das hier ist, es ist seit zwei Jahren deaktiviert, aber wir haben es nie gelöscht"-Plugins. Plugin-Zahlen auf der WordPress-Seite sinken typischerweise um 70-80% nach der Migration. Das ist Teil des Erfolgs.

Vorschau und Entwürfe

Redakteure klicken auf Preview in wp-admin. WordPress erstellt einen JWT-Preview-Token. Das Next.js-Frontend liest den Token, ruft den Entwurf via WPGraphQL ab und umgeht den statischen Cache, dann wird er gerendert. Entwurfs-URLs sind signiert, niemals indexierbar, nie öffentlich gecacht. Die One-Click-Preview-UX bleibt genau wie sie war. Die meisten Redakteure bemerken den Migrationstag auf der redaktionellen Seite nie.

Kommentare, Revisionen, Rollen

Auf der Backend-Seite unverändert. Kommentare zu Beiträgen können WordPress-nativ bleiben und sich headless via WPGraphQL rendern, oder durch Disqus / Giscus / ein Custom-System ersetzt werden, falls dein Team das ohnehin wollte. Revisionen sind unverändert — jeder Beitrag hat immer noch seine vollständige Historie, zugänglich vom WordPress-Editor. Benutzerrollen, Berechtigungen, Multi-Author-Setups, alles erhalten.

Yoast und Rank Math

Beide transportieren. Yoast SEO für WPGraphQL exponiert jedes Feld — Fokus-Keyword, Meta-Title, Meta-Description, Canonical, OG, Twitter Card, Schema Breadcrumb — als abfragbares GraphQL. Rank Math hat das Äquivalent. Das Next.js Layout liest die typisierte Response und rendert Meta-Tags identisch mit dem, was Yoast oder Rank Math auf klassischem WordPress ausgegeben hätte. Editoren bearbeiten weiterhin in der gleichen Plugin-UI; die Migration ist von ihrer Seite unsichtbar.

Woche 1: Discovery und Scoping

Plugin-Audit. Content-Audit. Search Console + Ahrefs Export für die Redirect-Map-Quelle. Aktuelle Performance-Baseline. Entscheidung zwischen Weg eins, zwei oder hybrid. Output: schriftliches SOW mit Festpreis und Milestone-Payment-Plan. Am Ende der ersten Woche weißt du genau, wofür du bezahlst.

Wochen 2–4: Foundation

Repos in deinem GitHub, nicht unserem. Hosting in deinen Accounts. WPGraphQL (oder neues CMS) konfiguriert. Next.js oder Astro Scaffolding ausgeliefert. SEO-Linter und Redirect-Map-Ingestion installiert. Design Tokens migriert. Am Ende der vierten Woche ist die Foundation real und das Team liefert Pages ab.

Wochen 5–10: Build

Templates portiert, Seite für Seite. Tägliche Looms vom Lead Engineer in deinem Slack. Wöchentlicher Mid-Build Review Call. Tickets in Linear oder Jira oder was auch immer du bereits nutzt. Edge Cases werden erfasst, sobald sie auftauchen. Das ist die langweilige Mitte des Projekts, wo die meisten Code geschrieben werden.

Wochen 10–12: Pre-Launch QA

Manuelle Cross-Browser-Tests. Mobile Audit. Accessibility Audit bei WCAG AA. Real-Device Core Web Vitals (nicht Lab Lighthouse). SEO-Linter grün. Schema Validator grün. Redirect Map verifiziert URL-für-URL gegen Search Console Export. Der Cutover-Plan geschrieben und trainiert.

Woche 12: Launch

DNS-Umstellung in einem von dir gewählten Zeitfenster. Die meisten wählen Dienstag oder Mittwoch morgens, bei wenig Traffic. Das Frontend läuft bereits auf einer Staging-Domain; die Umstellung ist ein DNS-Flip. Engineering steht 24 Stunden lang bereit. Search Console wird mit der neuen Sitemap eingereicht. Ahrefs und GA werden annotiert.

Wochen 12–16: Hyper-Care

Täglich Search Console überwachen auf Index-Anomalien, Redirect-Chain-Warnungen, Schema-Fehler. Wöchentlicher Traffic-Vergleich gegen die Baseline. Bug-Fixes haben Vorrang vor Features. Nach Woche 16 ist die Website stabil, und wir übergeben entweder sauber oder wechseln zu einem laufenden Care-Plan.