Vor drei Jahren habe ich den Blog eines Kunden mit 400 Beiträgen, 60.000 monatlichen organischen Besuchen und acht Jahren angesammeltem PageRank zu einem glänzenden Next.js-Frontend migriert. Innerhalb von sechs Wochen hatten wir 34% dieses Traffics verloren. Nicht weil die neue Site langsam war. Nicht weil der Content verschwunden ist. Weil ich bei vier spezifischen Dingen nachlässig war, die ich dir in diesem Beitrag zeige, damit du meinen Fehler nicht wiederholst.
Headless WordPress mit Next.js ist wirklich brillant für Performance und Developer Experience. Aber Google kümmert sich nicht um deinen Lighthouse Score, wenn deine Canonical Tags falsch sind, deine XML-Sitemap auf die alte Domain zeigt und deine strukturierten Daten irgendwo zwischen WPGraphQL und getStaticProps verdampft sind. Die Migration selbst ist der gefährliche Teil. Es richtig zu machen ist vor allem eine Frage der Disziplin, nicht der Magie.
---
Warum diese Migration SEO überhaupt zerbricht
Hier ist das Problem, das die meisten Tutorials übergehen: WordPress macht für dich eine Menge SEO-Schwerstarbeit, ohne dass du es merkst. Yoast oder Rank Math generiert deine Meta Tags. WordPress Core verwaltet deine Permalink-Struktur. Dein Theme gibt wahrscheinlich irgendwelche Schema-Markups aus. Deine XML-Sitemap wird jedes Mal automatisch neu generiert, wenn du etwas veröffentlichst.
Wenn du die Content-Schicht via WPGraphQL API in Next.js ziehst und sie von einem neuen Frontend aus servierst, wird die gesamte Infrastruktur zu deinem Problem, das du replizieren musst. Jedes. Einzelne. Teil.
Das andere Problem ist die URL-Struktur. Die meisten WordPress-Seiten haben /category/post-slug/ oder /year/month/post-slug/ oder einfach /post-slug/. Next.js gibt dir eine leere Leinwand für Routing. Diese leere Leinwand ist ein Ranking-Friedhof, wenn du sie nicht sorgfältig planst.
Die zwei Fehlermodi, die ich ständig sehe
Das erste sind Teams, die die URLs ebenfalls migrieren und trotzdem alles kaputtmachen, normalerweise weil Redirects inkonsistent angewendet werden oder die neue Sitemap live geht, bevor die Redirects aktiviert sind. Das zweite sind Teams, die die URL-Struktur absichtlich ändern (oft um sie zu bereinigen) und die Redirect-Zuordnung als Nebensache behandeln. Beides ist lösbar. Keines davon ist akzeptabel.
---
Audit, bevor du irgendetwas anfasst
Schreibe keine einzige Zeile Next.js-Code, bevor du ein vollständiges URL-Inventar hast. Ich benutze Screaming Frog, crawle die live WordPress-Site, exportiere jede indexierbare URL und kippe sie in eine Tabellenkalkulation. Bei einer 400-Seiten-Site dauert das vielleicht eine Stunde. Bei einer 4.000-Seiten-Site dauert es immer noch nur eine Stunde, weil das Tool es automatisch macht.
Das erfasst du:
- Jede kanonische URL, die derzeit indexiert ist
- Den HTTP-Status jeder URL (identifiziere 404er und 301er, die bereits existieren)
- Der Meta-Title und die Meta-Beschreibung für jede Seite
- Welche Seiten haben strukturierte Daten (nutzen Sie den Rich Results Test oder schauen Sie sich einfach den Quellcode an)
- Eingehende interne Links, damit du weißt, welche Seiten auf welche verlinken
Ziehen Sie auch Ihre Top 50 Seiten aus Google Search Console herunter, sortiert nach Klicks. Das sind diejenigen, bei denen Sie keinen Fehler machen dürfen. Markieren Sie diese im Spreadsheet. Behandeln Sie sie wie Produktionsabhängigkeiten.
Seahawk hatte Ende 2022 einen E-Commerce-Kunden -- ein 1.200-Produkt-WooCommerce-Store, der zu einer Headless-Lösung wechselt. Wir haben zwei volle Tage für das Audit aufgewendet, bevor wir Code geschrieben haben. Der Kunde dachte, wir verschwenden Zeit. Wir retteten seine 90.000 monatlichen organischen Sessions.
---
WordPress als echtes Headless CMS einrichten
Dieser Teil ist größtenteils unkompliziert. Installieren Sie WPGraphQL und stellen Sie Ihre Inhalte über die GraphQL API zur Verfügung. Es gibt aber ein paar Dinge, bei denen es sich lohnt, gezielt vorzugehen.
Halten Sie Yoast (oder Rank Math) auf der WordPress-Seite aktiv
Auch wenn du WordPress nicht mehr als Public Front-End nutzt, halte dein SEO-Plugin aktiv. WPGraphQL for Yoast SEO (oder die entsprechende Rank Math Extension) macht alle SEO-Meta, Titles, Descriptions, kanonische URLs, OG-Daten und Robots-Direktiven direkt über die GraphQL API verfügbar. Das heißt, du kannst sie von Next.js abfragen und genau so rendern, wie Yoast es beabsichtigt hat.
Das war die Lektion aus jenem 2019 Traffic-Einbruch, den ich erwähnt habe. Ich war davon ausgegangen, dass wir Titel aus dem Post-Titel + Site-Namen in Next.js neu generieren könnten. Das konnten wir. Aber Yoast hatte bei etwa 80 der Top-Performing Posts Meta-Titel manuell angepasst, und wir haben all das gelöscht. Acht Wochen zur Wiederherstellung.
Deaktiviere das WordPress Front-End sorgfältig
Sobald du Traffic auf Next.js leiten willst, soll WordPress NICHT gleichzeitig sein eigenes Frontend servieren. Duplicate Content in großem Maßstab. Die sauberste Methode ist, eine robots.txt auf deiner WordPress-Installation auf Disallow: / zu setzen, während deine Next.js-Site live geht, und dann irgendwann die WordPress-URL ganz zu firewalln, damit sie nur intern oder via VPN erreichbar ist.
Überspringe nicht den robots.txt-Schritt. Ich habe Teams gesehen, die WordPress auf CDN-Ebene blockiert haben und dann festgestellt haben, dass Googlebot eine gecachte Route hatte. Das dauert Monate zu bereinigen.
---
Die URL-Struktur exakt replizieren
Meine klare Standardempfehlung: Behalte deine URLs identisch. Gleicher Slug, gleiche Permalink-Struktur, gleiches Trailing-Slash-Verhalten. Je näher deine Next.js-Routes die WordPress-Routes spiegeln, desto weniger Redirects brauchst du, und desto weniger Risiko trägst du.
Next.js dynamic routes machen das einfach. Wenn deine WordPress-Posts unter /blog/[slug] leben, erstelle pages/blog/[slug].js. Fertig.
Wo es unordentlich wird, sind Kategorie-Archive, Autor-Seiten, Tag-Seiten und paginierte Archive (/blog/page/2/). WordPress generiert alle diese automatisch. In Next.js baust du sie selbst. Viele Teams deprioritisieren diese und wundern sich dann, warum die Crawl-Abdeckung gesunken ist.
Hier ist meine nummerierte Checkliste für URL-Parität:
- Einzelne Posts/Seiten, passe den Slug genau an, inklusive eventueller Subordner
- Category-Archive, erstelle /category/[slug]/ mit getStaticPaths, das alle Kategorien von WPGraphQL abruft
- Tag-Archive, das gleiche wie oben, überspringe diese nicht, wenn sie organischen Traffic generieren
- Author-Archive-Seiten: Schau zunächst in die Search Console; wenn sie null Klicks bekommen, kannst du sie mit 301 auf die Startseite umleiten
- Paginierte Archive, /blog/page/[num]/, sind es wert, erhalten zu bleiben, wenn du viele Posts hast
- Attachment-Seiten: leite sie fast immer mit 301 zum übergeordneten Post um; sie sind SEO-Ballast in WordPress
- Feed-URLs: /feed/ sollte mit 301 zu deinem neuen RSS-Feed umgeleitet werden, falls vorhanden, oder 410 zurückgeben, falls nicht
---
Redirects: Der Teil, den jeder unterschätzt
Falls du URLs änderst – ich würde dagegen argumentieren, aber manchmal ist es nötig – muss deine Redirect-Map vor dem Launch erstellt und in einer Staging-Umgebung getestet werden
In Next.js leben Redirects in next.config.js. Für kleine Seiten (unter 200 Redirects) ist das okay. Für größere Mengen: leg sie in einer JSON-Datei ab und import sie, oder nutze Middleware, um sie dynamisch zu handhaben. Vercels Edge Middleware ist hervorragend für große Redirect-Tabellen, weil sie vor dem Rendern der Seite läuft – null Latenz-Penalty
Das Format in next.config.js:
``redirects: [ { source: '/old-slug', destination: '/new-slug', permanent: true } ]``
permanent: true sendet einen 301. Nutze es für alle echten URL-Änderungen. Nutze 302 (temporär) nicht, es sei denn, du willst es tatsächlich rückgängig machen; Google behandelt sie sehr unterschiedlich
Testen Sie jeden Redirect vor dem Launch. Ich verwende ein einfaches Bash-Skript, das die Tabelle durchläuft und jeden alten URL mit curl aufruft, um auf eine 301-Antwort zum richtigen Ziel zu prüfen. Dauert zehn Minuten zu schreiben, erspart Stunden Panik nach dem Launch.
---
Meta Tags, Canonical URLs und Structured Data in Next.js
Hier verlieren die meisten Migrationen still Punkte. Der Inhalt ist da, die URLs funktionieren, aber die SEO-Signale sind falsch.
Meta Tags
Nutze next-seo. Das ist der Standard. Übergib ihm die Daten, die du aus WPGraphQL Yoast abgefragt hast. Deine _app.js bekommt eine DefaultSeo-Config, und jede Seite bekommt eine NextSeo-Komponente mit den seitenspezifischen Overrides. Nimm Title, Description, OG Title, OG Image, Canonical URL und Robots-Direktiven direkt aus der Yoast-GraphQL-Response – erfinde sie nicht neu
Eine Sache, die Menschen Probleme bereitet: Canonical URLs. In WordPress setzt Yoast Canonicals automatisch. In Next.js musst du das Canonical explizit übergeben. Wenn du das vergisst, rendert Next.js Seiten ohne Canonical-Tag, und wenn du irgendwo Query-Strings hast (Pagination, Filter), bekommst du schneller Duplicate-Content-Probleme, als du erwartest.
Strukturierte Daten
WordPress Themes und Plugins geben JSON-LD oft automatisch aus. Das verschwindet bei Headless. Du musst es neu aufbauen. Für Artikel nutze das Article-Schema. Für Produkte Product. Für lokale Unternehmen LocalBusiness. Ich schreibe diese als React-Komponenten, die Props akzeptieren und einen <script type="application/ld+json">-Tag zurückgeben. Eine Komponente pro Schema-Typ, wiederverwendet in der ganzen App.
Überprüfe jeden Schema-Typ, den du vorher im Rich Results Test hattest, vor der Migration. Dokumentiere sie. Erstelle sie neu. Teste die neuen mit dem gleichen Tool nach dem Launch.
Die XML Sitemap
Nutze keine statische Sitemap. Generiere sie dynamisch. Für kleine Seiten funktioniert getServerSideProps auf einer /sitemap.xml-Route. Für große Seiten mit Tausenden Posts: generiere die Sitemap zur Build-Zeit über ein Custom-Script und gib sie in den public/-Ordner aus. Vercel führt das bei jedem Deployment aus, deine Sitemap ist immer aktuell
Reiche die neue Sitemap-URL am ersten Tag nach dem Launch in der Google Search Console ein. Nicht am dritten Tag. Am ersten Tag.
---
Monitoring nach dem Launch (Das 90-Tage-Fenster)
Die Migration endet nicht beim Launch. Sie endet, wenn sich deine Rankings stabilisiert haben – laut Googles Dokumentation kann das überall zwischen ein paar Wochen und ein paar Monate dauern, abhängig von Crawl-Budget und Site-Authority
Was ich jeden Wochentag im ersten Monat überprüfe:
- Google Search Console → Coverage Report auf neue 404s oder 'Excluded'-URLs, die nicht ausgeschlossen sein sollten
- Search Console → Performance, vergleiche Klicks und Impressionen Woche für Woche für deine Top-50-Seiten
- Screaming Frog Re-Crawl der neuen Site, um interne 404s oder falsch konfigurierte Canonical Tags zu fangen
- Core Web Vitals – ja, eine Next.js-Website sollte schneller laufen. Aber kontrollier es mit echten Nutzerdaten (CrUX). Nicht nur mit Lighthouse.
Wenn du in den ersten zwei bis drei Wochen einen signifikanten Rückgang siehst, gerät nicht gleich in Panik. Es gibt fast immer kurzfristige Schwankungen, während Google erneut crawlt und neu indexiert. Worauf du achten musst, sind anhaltende Rückgänge nach Woche vier. Das ist das Signal, dass etwas strukturell nicht stimmt.
Ende 2022, anderes Projekt als das E-Commerce-Projekt, haben wir eine Next.js-Migration für einen SaaS-Blog durchgeführt und sind in Woche zwei um 20 % bei den Impressionen gefallen. Es stellte sich heraus, dass unsere dynamisch generierte Sitemap noindex-Seiten enthielt, weil wir die WPGraphQL-Abfrage nicht richtig gefiltert hatten. Wir haben das in vier Stunden behoben. Die Rankings haben sich in drei Wochen erholt. Das Monitoring hat das Ganze erfasst, bevor es sich verschärft hat.
---
FAQ
Wie lange dauert eine WordPress-zu-Next.js-Migration?
Ehrlich gesagt hängt es mehr von der Komplexität der Website ab als von der Anzahl der Beiträge. Eine 100-Seiten-Broschüren-Website mit sauberen URLs lässt sich in zwei bis drei Wochen ordnungsgemäß umsetzen. Ein 2.000-Beiträge-Blog mit benutzerdefinierten Post-Typen, ACF-Feldern und WooCommerce-Integration ist ein Projekt von mindestens sechs bis acht Wochen, wenn du die SEO-Arbeit ordnungsgemäß neben der Entwicklung machst. Lass dir von niemandem erzählen, dass das ein Wochenend-Job ist.
Soll ich den Pages Router oder App Router in Next.js verwenden?
Seit Mitte 2024 verwende ich standardmäßig den App Router für neue Projekte. Aber wenn dein Team sich beim Pages Router wohler fühlt und diese Migration zeitkritisch ist, nutze das, was ihr könnt. Die SEO-Auswirkungen sind minimal, beide unterstützen statische Generierung, serverseitiges Rendering und dynamische Routen. Das next-seo-Paket hat jetzt auch App-Router-Unterstützung.
Muss ich mich ganz von WordPress-Hosting verabschieden?
Nein. WordPress kann auf seinem bestehenden Host bleiben, WP Engine, Kinsta, Cloudways, was auch immer du nutzt, und dient rein als Content API. Das Next.js-Frontend deployed auf Vercel oder Netlify. Die beiden kommunizieren via HTTP. Manche Kunden bevorzugen das sogar, weil das Editorial-Team den WordPress-Admin behält, den es bereits kennt.
Was ist mit WordPress-Plugins, die SEO beeinflussen, wie Redirects, die in Redirection verwaltet werden?
Exportiere sie vor der Migration. Das Redirection-Plugin hat einen CSV-Export. Nimm alle bestehenden Redirects und füge sie in deine next.config.js oder Edge Middleware ein. Gehe nicht davon aus, dass sie automatisch mitgenommen werden, das tun sie nicht, weil sie in der WordPress-Datenbank leben und Next.js keine Ahnung von ihrer Existenz hat.
Wird mein Google-Ranking auf jeden Fall sinken?
Es gibt fast immer eine kurzzeitige Volatilität. Eine gut umgesetzte Migration mit null URL-Änderungen, korrekten Redirects (wo nötig), replizierter Meta und strukturierter Daten sowie einer erneut eingereichten Sitemap sollte sich innerhalb von vier bis sechs Wochen stabilisieren. Die Abfälle, die ich erlebt habe und Monate anhielten, waren alle auf spezifische technische Fehler zurückzuführen, nicht auf die Migration selbst.
---
Die Migration selbst? Das ist nicht das Problem. Das Problem ist die Disziplin. Jeden langweiligen, unspektakulären Schritt machen. Das Audit. Die Redirect-Zuordnung. Die Schema-Rekonstruktion. Bevor du Code schreibst, der clever wirkt. Machst du die Reihenfolge richtig, kommst du auf der anderen Seite raus mit einem schnelleren Frontend und denselben Rankings, mit denen du gestartet bist. Vielleicht sogar mit besseren Rankings, sobald die Core-Web-Vitals-Verbesserungen durchschlagen.