Vor drei Jahren rief mich ein Kunde an einem Donnerstagnachmittag in absoluter Panik an. Er hatte eine Drupal-zu-WordPress-Migration an ein billiges Dev-Shop vergeben, die Website ging Freitag live, und bis Montag war der organische Traffic um 67 % gesunken. Weg. Sechs Jahre SEO-Kapital, einfach... verdampft. Keine Redirects. Tausende kaputte URLs. Googles Crawl-Budget zerstört.
Wichtigste Erkenntnisse: Drupal-zu-WordPress-Migrationen scheitern an der URL-Zuordnung und Taxonomie-Übersetzung, nicht am CMS-Wechsel selbst; liefern Sie eine vollständige Weiterleitungskarte und transportieren Sie Metadaten, um Rankings zu halten.
Ich habe diese Art von Bruchstellen mehr oft repariert, als ich zählen möchte. Nach über 12.000 Migrationen bei Seahawk Media kann ich dir mit einiger Sicherheit sagen: Der technische Umzug von Drupal zu WordPress ist eigentlich der einfache Teil. Die SEO-Erhaltung ist dort, wo alles schiefgeht, und wo es absolut nicht schiefgehen muss.
Das ist das Playbook, das ich befolge. Jedes Mal.
---
Warum Drupal-zu-WordPress-Migrationen ein SEO-Minenfeld sind
Drupal und WordPress generieren URLs unterschiedlich. Drupals Standard-Pfadsystem, kombiniert mit Modulen wie Pathauto, produziert oft URL-Strukturen, die null Übereinstimmung mit dem haben, was WordPress standardmäßig generiert. Ein Drupal-Node unter /content/our-services/web-design wird zu /our-services/web-design oder sogar /web-design auf WordPress, je nachdem wie du Permalinks einstellst. Das sind unterschiedliche URLs. Google sieht sie als unterschiedliche Seiten. Ohne einen Redirect ist die alte URL tot.
Und es geht nicht nur um URLs. Drupals Taxonomie-System wird auf WordPress-Kategorien und Tags abgebildet, aber nicht perfekt. Custom Content Types in Drupal werden zu Custom Post Types in WordPress, und wenn du diese CPTs nicht vor der Migration erstellst, landen deine Inhalte in der falschen Kategorie. Ich habe eine Drupal-gestützte News-Site gesehen, bei der 800 „article"-Knoten alle als Standard-WordPress-Posts importiert wurden und die Custom-Archivstruktur überschrieben haben, auf die ihre interne Verlinkung angewiesen war.
Das ist der Punkt, den die meisten Entwickler übersehen: Jede strukturelle Entscheidung, die du in WordPress vor der Migration triffst, beeinflusst direkt, welche Umleitungen du danach brauchst. Bekomme die Architektur zuerst richtig hin. Umleitungen sind ein Pflaster, kein Plan.
---
Schritt 1: Pre-Migration-Audit – Wisse, was du verschiebst, bevor du es verschiebst
Rühre die Drupal-Installation nicht an, bis du einen vollständigen Crawl der Live-Website hast. Ich nutze Screaming Frog eingestellt auf das Crawlen von bis zu 500.000 URLs (die kostenpflichtige Version). Exportiere alles: URLs, Status-Codes, Title-Tags, Meta-Beschreibungen, H1s, Canonical-Tags, eingehende interne Links, Wortanzahlen.
Hole dir auch deine Google Search Console-Daten. Filtere nach Klicks der letzten 16 Monate (nicht 3, nicht 6-16, weil du saisonale Inhalte erfassen möchtest). Exportiere jede URL, die mindestens einen Klick erhalten hat. Das sind deine geschützten URLs. Verlierst du Rankings bei einer dieser URLs, wird es der Kunde bemerken.
Worauf ich speziell achte:
- Duplizierte Inhalte, die bereits auf der Drupal-Website existieren (behebe das vor der Migration, nicht danach)
- Dünnbesiedelte Content-Seiten unter 200 Wörtern, die für nichts ranken, können konsolidiert oder gelöscht werden, statt sie zu migrieren
- Nicht-standardmäßige URL-Muster wie /node/1234 URLs, die Drupal manchmal zeigt, selbst wenn Pathauto aktiv ist
- Taxonomie-Archivseiten, die ranken, /tags/, /category/, /topic/-Pfade, die tatsächliche Search-Console-Impressionen haben
Diese letzte Kategorie erwischt die Leute ständig. Drupal-Taxonomie-Term-Seiten ranken oft für Long-Tail-Queries. Wenn du keine entsprechenden WordPress-Taxonomie-Archive erstellst und die alten Pfade nicht redirectst, hast du gerade passiven Traffic weggeworfen.
---
Schritt 2: URL-Mapping – Die Tabelle, die niemand bauen will
Langweilig? Ja. Nicht verhandelbar? Auch ja.
Erstelle eine URL-Zuordnung in Google Sheets (oder Airtable, wenn du das bevorzugst, ich habe beide genutzt). Spalte A sind alle Drupal-URLs. Spalte B ist die entsprechende WordPress-URL, zu der sie aufgelöst wird. Spalte C ist ein Status: exact match, redirect needed, consolidate, oder delete.
Für eine 300-Seiten-Site dauert das einen halben Tag. Für eine 8.000-Seiten-Site, die Seahawk 2021 für einen Higher-Education-Client bearbeitet hat, dauert es ein Team von drei etwa vier Arbeitstage plus einen sehr mühsamen Freitagabend. Es lohnt sich jedes Mal.
Ein paar Regeln, die ich befolge:
- Bewahre Slugs, wo möglich. Wenn Drupal /blog/how-to-fix-crawl-errors hat, lass WordPress denselben Slug verwenden. Meistens geht das. Die Permalink-Einstellungen in WordPress Settings → Permalinks ermöglichen dir, jedes Muster zu verwenden, das Drupal hatte.
- Leite nie zur Startseite um. Faule Entwickler machen das. Es zerstört Link Equity und verwirrt Nutzer. Jede alte URL bekommt ein spezifisches Ziel.
- Pass auf paginierten URLs auf. Drupal-Paginierung sieht so aus: ?page=1. WordPress nutzt /page/2/. Mapp diese oder lass sie als 404s stehen (was normalerweise in Ordnung ist, paginierte Seiten behalten selten nennenswerte Link-Equity, aber bestätige das vorher in GSC).
- Dokumentiere Query-Strings separat. Dinge wie /search?keys=wordpress benötigen keine Weiterleitungen. /events?date=2023-06 könnte es brauchen, je nachdem, ob diese Seiten ranken.
---
Schritt 3: Content-Migration – FG Drupal to WordPress und was wirklich passiert
Das FG Drupal to WordPress Plugin macht die schwere Arbeit bei den meisten Migrationen. Es verbindet sich direkt mit deiner Drupal-Datenbank, zieht Nodes, User, Taxonomie-Terms und Medien. Bei Drupal 7 funktioniert es hervorragend. Bei Drupal 9/10 brauchst du die Premium-Version, die zuletzt etwa 99 € gekostet hat. Jeden Cent wert gegenüber manueller Migration.
Das Plugin handhabt gut:
- Node Body Content (inklusive eingebetteter Bilder, wenn du den Media Path richtig konfigurierst)
- Taxonomie-Begriffe auf WordPress-Kategorien/Tags gemappt
- Basis-Custom Fields, wenn du im Premium Tier bist
Was es nicht bewältigt und was du manuell korrigieren musst:
- Drupal Views – das sind Custom-Page-Layouts/Queries. Diese wirst du in WordPress mit Plugins wie WPGridBuilder neu aufbauen oder einfach mit benutzerdefinierten WP_Query-Loops.
- Webformulare, diese manuell auf Gravity Forms oder WPForms abbilden; die Logik lässt sich nicht übertragen
- Komplexe Feldgruppen, Drupals Field API unterstützt einige wirklich merkwürdige Datenstrukturen. Sie müssen diese als CSV exportieren und via WP All Import importieren
- Block-Inhaltsbereiche, Drupals Block-System ist nichts wie WordPress-Widgets/FSE-Blöcke. Designentscheidung, keine Migrationsaufgabe
Das eine, das ich nach FG Drupal to WordPress immer mache: eine Zeilenanzahl ausführen. Wie viele Nodes waren in Drupal? Wie viele Posts/CPT-Einträge sind jetzt in WordPress? Sie sollten übereinstimmen (minus allem, das du absichtlich ausgeschlossen hast). Eine 3%-Abweichung bei einer Site mit 5.000 Nodes sind 150 fehlende Seiten. Geh und finde sie.
---
Schritt 4: Umleitungen implementieren, ohne deinen Server zu zerstören
Sobald die URL-Map erstellt ist und der Inhalt in der WordPress-Staging-Umgebung live ist, werden Weiterleitungen eingerichtet. Zwei Tools: das Redirection Plugin für kleinere Seiten (unter ~1.000 Weiterleitungen) und .htaccess-Regeln für alles Größere auf Apache, oder nginx.conf Blöcke auf Nginx.
Warum die Aufteilung? Das Redirection-Plugin verarbeitet Umleitungen über PHP, was einen Server-Hit für jede Umleitungsprüfung bedeutet. Bei 5.000 Umleitungen mit 50.000 täglichen Seitenaufrufen ist das echter Overhead. Server-seitige Umleitungen sind um eine Größenordnung schneller.
Bei großen Migrationen exportiere ich die URL-Map aus Google Sheets, schreibe schnell ein Script um die RewriteRule Blöcke zu generieren, und füge sie in .htaccess vor dem Go-Live ein. Dauert 20 Minuten. Spart Stunden beim Debugging einer trägen Seite nach dem Launch.
Eine Sache, an die Leute nicht denken: Redirect-Ketten. Falls Drupal bereits Weiterleitungen hatte (viele etablierte Drupal-Sites tun das, über das Redirect Modul), musst du diese finden und die Kette zusammenfassen. A → B → C muss zu A → C werden. Googles eigene Dokumentation ist ziemlich klar, dass Ketten den PageRank-Transfer verlangsamen, auch wenn sie ihn nicht eliminieren.
---
Schritt 5: Nach dem Launch, Das 72-Stunden-Fenster
Starten Sie an einem Dienstag oder Mittwoch. Niemals Freitag. Ich habe das die harte Tour mit einem Kunden 2018 gelernt – wir haben eine 1.200-Seiten-Migration Freitagnachmittag live genommen und um 18 Uhr eine falsch konfigurierte Permalink-Struktur entdeckt. Bis Montag hatte Google bereits eine Welle kaputter URLs gecrawlt und indexiert.
Das überwache ich in den ersten 72 Stunden:
- GSC Coverage Report, achten Sie auf einen Anstieg bei 404ern. Einige sind zu erwarten (alte Drupal-Systempfade). Ein Anstieg über Ihre Money Pages hinweg ist das nicht.
- Screaming Frog neu crawlen, crawlen Sie die Live-WordPress-Site am Morgen nach dem Launch. Vergleichen Sie die URL-Anzahl mit Ihrem Pre-Migration-Baseline.
- Redirect-Stichproben, testen Sie manuell Ihre 20 wichtigsten Drupal-URLs aus GSC. Fügen Sie sie in einen Browser ein. Landen sie dort, wo sie sollen?
- Canonical Tags, bestätigen Sie, dass WordPress das richtige Canonical auf jeder Seite ausgibt. Yoast und Rank Math machen das automatisch, aber prüfen Sie trotzdem.
- XML-Sitemap-Einreichung, reichen Sie die neue Sitemap sofort in GSC ein. Warten Sie nicht, bis Google sie findet.
Eine Sache, die ich mache und die die meisten überspringen: Reiche nach dem Launch auch die alte Drupal-XML-Sitemap in der GSC ein und verweise dabei auf die alte Domain oder Subdomain, falls du diese temporär noch aktiv hältst. Das teilt Google genau mit, welche alten URLs gecrawlt werden sollen, den Redirects zu folgen und seinen Index schneller zu aktualisieren.
---
Schritt 6: Die 30-Tage-SEO-Gesundheitsprüfung
Eine Migration ist nicht mit dem Go-Live beendet. Die Aktualisierung des Index braucht Zeit. Das schaue ich mir nach 30 Tagen an:
- Ranking-Positionen-Veränderungen: Nutze Ahrefs oder Semrush, um Keyword-Positionen 30 Tage vor der Migration mit 30 Tagen danach zu vergleichen. Erwarte bei einigen Begriffen geringfügige Schwankungen (5-10 Positionen). Ein Rückgang von 30+ Positionen bei einem primären Keyword erfordert Untersuchung.
- Backlink-Ziele: Wenn du externe Backlinks auf spezifische Drupal-URLs hattest, prüfe, dass diese URLs sauber weitergeleitet werden. Der Lost Backlinks Report von Ahrefs zeigt das auf. Kaputte Backlink-Ziele sind Link-Equity, die du aktiv verlierst.
- Page-Speed-Regression: WordPress-Sites sind manchmal langsamer als gut abgestimmte Drupal-Sites. Führe ein Lighthouse-Audit auf deinen 5 wichtigsten Seiten durch und vergleiche es mit deinem Pre-Migration-Baseline.
- Indexierungsrate: Wie viele deiner eingereichten URLs sind indexiert? Nach 30 Tagen solltest du mindestens 80% deiner Hauptinhaltsseiten indexiert haben. Weniger als 60% deuten auf ein Crawlability-Problem hin (prüfe robots.txt und stelle sicher, dass du Googlebot nicht versehentlich in WordPress-Einstellungen → Lesen blockiert hast).
Seahawk hatte letztes Jahr einen Fintech-Client, bei dem die 30-Tage-Prüfung zeigte, dass 340 Produktseiten versehentlich auf noindex gesetzt worden waren durch eine falsch konfigurierte Yoast-Massenmaßnahme während der Migration. Gefangen nach 30 Tagen: in einem Nachmittag behebbar. Gefangen nach 6 Monaten: wahrscheinlich ein Ranking-Loch, das du noch immer zu füllen versuchst.
---
FAQ
Wie lange dauert eine Migration von Drupal zu WordPress wirklich?
Hängt ganz von der Größe und Komplexität der Site ab. Eine 50-Seiten-Broschüren-Site: 2-3 Tage inklusive QA. Ein 5.000-Seiten-Newsarchiv mit benutzerdefinierten Content-Typen: 6-10 Wochen. Die SEO-Arbeit, das Audit, das URL-Mapping, die Redirect-Implementierung, die Post-Launch-Überwachung – das addiert typischerweise 30-40% zur eigentlichen Entwicklungsschätzung. Lass dir da nichts anderes erzählen.
Werde ich Rankings nach einer Migration von Drupal zu WordPress verlieren?
Kurzfristige Schwankungen sind normal und fast unvermeidlich. Wenn Sie URL-Mapping, Redirects und Canonical-Tags korrekt gemacht haben, stabilisieren sich die meisten Rankings innerhalb von 6–12 Wochen. Die Sites, bei denen ich permanente Verluste gesehen habe, hatten alle das gleiche Problem: entweder keine Redirects oder Mass-Redirects zur Homepage. Machen Sie die Arbeit. Die Rankings kommen zurück.
Sollte ich alle Drupal-Inhalte migrieren oder neu anfangen?
Hängt davon ab, was der Content für dich leistet. Zieh deine GSC-Daten heran. Jeder Content mit null Clicks über 16 Monate hinweg und ohne Backlinks ist eher ein Kandidat für Löschung als für Migration. Dünne, minderwertige Inhalte zu migrieren bläht deine WordPress-Site auf und kann dein Crawl-Budget verwässern. Sei rücksichtslos. Aber: Lösche nie eine URL, die externe Backlinks hat, auch wenn die Seite selbst Müll ist – leite sie auf etwas Relevantes weiter.
Welches WordPress-Theme sollte ich nach einer Drupal-Migration verwenden?
Ehrlich gesagt hat die Theme-Wahl fast keine SEO-Auswirkung, wenn du gut strukturiertes HTML verwendest und die Page Speed im Griff hast. Ich setze standardmäßig auf GeneratePress wegen seines sauberen Markups und minimalen Overheads, oder Kadence, wenn der Client mehr Design-Flexibilität will. Vermeide Page-Builder-lastige Themes, die auf jedem Seitenaufruf 400KB ungenutztes CSS ausgeben.
Brauche ich einen Entwickler oder kann ich das selbst machen?
Für eine kleine Site unter 50 Seiten mit einfachem Content und ohne Custom Post Types? Du kannst wahrscheinlich mit FG Drupal to WordPress und dem Redirection Plugin zurechtkommen, wenn du die obigen Schritte befolgst. Für alles Größere, oder alles mit CPTs, komplexen Taxonomien oder bedeutsamen SEO-Fußabdrücken: Hol dir einen Developer. Die Kosten, eine verhunzte Migration zu reparieren, sind immer höher als die Kosten, es richtig zu machen.
---
Die Migration selbst ist vielleicht 40% der Arbeit. Die anderen 60% sind die SEO-Infrastruktur, die du drumherum aufbaust, das Mapping, die Redirects, das Monitoring, die Geduld, die Daten 30 Tage lang zu beobachten, bevor du Sieg erklärst. Ich habe wunderbar gebaute WordPress-Sites in der Suche absacken sehen, weil die Redirect-Arbeit schlampig war, und ich habe ramschig aufgebaute, kaum gethemte WordPress-Installs jedes Ranking halten sehen, weil das URL-Map akribisch war.
Mach die langweiligen Dinge richtig. Der Rest folgt in der Regel von selbst.