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.Drupal-to-WordPress migration to a cheap dev shop, the site went live on a Friday, and by Monday their organic traffic had dropped 67%. Gone. Six years of SEO equity, just... evaporated. No redirects. Thousands of broken URLs. Google's crawl budget torched.
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.Drupal to WordPress migrations fail on URL mapping and taxonomy translation, not the CMS swap; ship a complete redirect map and transport metadata to keep rankings.
Ich habe diese Art von Desaster mehr Male repariert, als ich zählen mag. Nach über 12.000 Migrationen bei Seahawk Media kann ich dir mit einiger Sicherheit sagen: Der technische Wechsel von Drupal zu WordPress ist tatsächlich der einfache Teil. Die SEO-Preservation ist der Ort, an dem alles schiefgeht – und wo es absolut nicht schiefgehen muss.Seahawk Media, I can tell you with some confidence: the technical move from Drupal to WordPress is actually the easy part. The SEO preservation is where everything goes wrong -- and where it absolutely doesn't have to.
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./content/our-services/web-design becomes/our-services/web-design or even/web-design on WordPress, depending on how you set permalinks. Those are different URLs. Google sees them as different pages. Without a redirect, the old one is dead.
Und es sind nicht nur 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 völlig in der falschen Kategorie. Ich habe eine Drupal-basierte News-Website gesehen, auf der alle 800 „article"-Knoten als Standard-WordPress-Posts importiert wurden und die benutzerdefinierte 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.every structural decision you make in WordPress before the migration directly affects which redirects you'll need after it. Get the architecture right first. Redirects are a patch, not a 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.Screaming Frog set to crawl up to 500,000 URLs (the paid version). Export everything: URLs, status codes, title tags, meta descriptions, H1s, canonical tags, inbound internal links, word counts.
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.protected URLs. Lose rankings on any of these and the client will notice.
Worauf ich speziell achte:
- Duplizierte Inhalte, die bereits auf der Drupal-Website existieren (behebe das vor der Migration, nicht danach) already existing on the Drupal site (fix it before migrating, not after)
- Dünne Inhaltsseiten unter 200 Wörtern, die für nichts ranken – diese können konsolidiert oder gelöscht werden, statt sie zu migrieren under 200 words that rank for nothing -- these can be consolidated or deleted rather than migrated
- Nicht-standardmäßige URL-Muster wie /node/1234 URLs, die Drupal manchmal zeigt, selbst wenn Pathauto aktiv ist like
/node/1234URLs that Drupal sometimes exposes even when Pathauto is active - Taxonomie-Archivseiten, die ranken – /tags/, /category/, /topic/-Pfade mit tatsächlichen Search Console-Impressionen that rank --
/tags/,/category/,/topic/paths that have actual Search Console impressions
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.and redirect the old paths, you've just thrown away passive traffic.
---
Schritt 2: URL-Zuordnung – Das Spreadsheet, das niemand erstellen möchte
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.exact match,redirect needed,consolidate, or delete.
Für eine 300-Seiten-Website dauert das einen halben Tag. Für eine 8.000-Seiten-Website – die Seahawk 2021 für einen Kunden aus dem Hochschulbereich bearbeitet hat – braucht ein Team von drei Personen 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.If Drupal has
/blog/how-to-fix-crawl-errors, make WordPress use the same slug. Most of the time you can. The permalink settings in WordPress Settings → Permalinks let you match whatever pattern Drupal was using. - Leite nie zur Startseite um. Faule Entwickler machen das. Es zerstört Link Equity und verwirrt Nutzer. Jede alte URL bekommt ein spezifisches Ziel.Lazy devs do this. It kills link equity and confuses users. Every old URL gets a specific destination.
- Vorsicht vor paginierten URLs. Drupal-Paginierung sieht wie ?page=1 aus. WordPress verwendet /page/2/. Ordne diese zu oder lass sie als 404er (was normalerweise okay ist – paginierte Seiten haben selten nennenswerten Link-Equity, aber überprüfe das erst in der GSC).Drupal pagination looks like
?page=1. WordPress uses/page/2/. Map these or leave them as 404s (which is usually fine -- paginated pages rarely hold meaningful link equity, but confirm in GSC first). - 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.Things like
/search?keys=wordpressdon't need redirects./events?date=2023-06might, depending on whether those pages rank.
---
Schritt 3: Content-Migration -- Drupal zu WordPress und was tatsächlich 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.FG Drupal to WordPress plugin does the heavy lifting for most migrations. It connects directly to your Drupal database, pulls nodes, users, taxonomy terms, and media. For Drupal 7, it works brilliantly. For Drupal 9/10, you'll need the premium version, which is about €99 last time I checked. Worth every penny versus manual 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 benutzerdefinierte Seiten-Layouts/Abfragen. Du wirst diese in WordPress mit Plugins wie WPGridBuilder oder einfach mit benutzerdefinierten WP_Query-Schleifen neu aufbauen -- these are custom page layouts/queries. You'll rebuild these in WordPress using plugins like WPGridBuilder or just custom WP_Query loops
- Webforms -- ordne diese manuell Gravity Forms oder WPForms zu; die Logik wird nicht übertragen -- map these to Gravity Forms or WPForms manually; the logic doesn't transfer
- Komplexe Field-Gruppen -- Drupals Field API unterstützt einige wirklich merkwürdige Datenstrukturen. Du musst diese als CSV exportieren und über WP All Import importieren -- Drupal's Field API supports some genuinely weird data structures. You'll need to export these to CSV and import via WP All Import
- Block-Content-Regionen -- Drupals Block-System ist nicht vergleichbar mit WordPress-Widgets/FSE-Blöcken. Das ist eine Designentscheidung, keine Migration -- Drupal's block system is nothing like WordPress widgets/FSE blocks. Design decision, not a migration task
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.Redirection plugin for smaller sites (under ~1,000 redirects) and.htaccess rules for anything larger on Apache, or nginx.conf blocks on 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.RewriteRule blocks, and drop them into.htaccess before go-live. Takes 20 minutes. Saves hours of debugging a sluggish site post-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.redirect chains. If Drupal already had redirects in place (many mature Drupal sites do, via the Redirect module), you need to find those and collapse the chain. A → B → C needs to become A → C.Google's own documentation is pretty clear that chains slow down PageRank transfer, even if they don't eliminate it.
---
Schritt 5: Nach dem Launch -- Das 72-Stunden-Fenster
Starten Sie am Dienstag oder Mittwoch. Niemals Freitag. Ich habe das 2018 bei einem Kunden auf die harte Tour gelernt -- wir haben eine Migration mit 1.200 Seiten am Freitagnachmittag gestartet und um 18 Uhr eine fehlkonfigurierte Permalink-Struktur entdeckt. Bis Montag hatte Google bereits eine Welle von fehlerhaften URLs gecrawlt und indexiert.
Das überwache ich in den ersten 72 Stunden:
- GSC Coverage-Report -- beobachte einen Anstieg von 404ern. Einige sind zu erwarten (alte Drupal-Systempfade). Ein Anstieg bei deinen Money Pages ist es nicht. -- watch for a spike in 404s. Some are expected (old Drupal system paths). A spike across your money pages is not.
- Screaming Frog-Neuabfrage -- crawle die live WordPress-Site am Morgen nach dem Launch. Vergleiche die URL-Anzahl mit deinem Pre-Migration-Baseline. -- crawl the live WordPress site the morning after launch. Compare URL count to your pre-migration baseline.
- Redirect-Stichproben -- teste manuell deine 20 höchsten Traffic-URLs von Drupal aus der GSC. Gib sie in einen Browser ein. Landen sie dort, wo sie sein sollten? -- manually test your 20 highest-traffic Drupal URLs from GSC. Paste them into a browser. Do they land where they should?
- Canonical-Tags -- überprüfen Sie, dass WordPress auf jeder Seite das richtige Canonical ausgibt. Yoast und Rank Math machen das automatisch, aber prüfen Sie trotzdem nach. -- confirm WordPress is outputting the right canonical on every page. Yoast and Rank Math both do this automatically, but check anyway.
- XML-Sitemap-Übermittlung -- reichen Sie die neue Sitemap sofort in der GSC ein. Warten Sie nicht darauf, dass Google sie findet. -- submit the new sitemap in GSC immediately. Don't wait for Google to find it.
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.submit the old Drupal XML sitemap in GSC as well, after launch, pointing at the old domain or subdomain if you kept it up temporarily. This tells Google exactly which old URLs to crawl, follow the redirects, and update its index faster.
---
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-Positionsänderungen -- nutzen Sie Ahrefs oder Semrush, um Keyword-Positionen 30 Tage vor der Migration mit 30 Tagen danach zu vergleichen. Geringe Schwankungen (5–10 Positionen) bei einigen Begriffen sind zu erwarten. Ein Rückgang von 30+ Positionen bei einem primären Keyword erfordert eine Untersuchung. -- use Ahrefs or Semrush to compare keyword positions 30 days pre-migration vs. 30 days post. Expect minor fluctuation (5-10 positions) on some terms. A drop of 30+ positions on a primary keyword needs investigation.
- Backlink-Ziele -- wenn Sie externe Backlinks zu spezifischen Drupal-URLs hatten, überprüfen Sie, dass diese URLs sauber weitergeleitet werden. Der Bericht „Lost Backlinks" von Ahrefs zeigt dies auf. Fehlerhafte Backlink-Ziele sind Linkequity, die Sie aktiv verlieren. -- if you had external backlinks pointing to specific Drupal URLs, check that those URLs are redirecting cleanly. Ahrefs' Lost Backlinks report surfaces this. Broken backlink targets are link equity you're actively haemorrhaging.
- Page-Speed-Regression -- WordPress-Sites sind manchmal langsamer als gut optimierte Drupal-Sites. Führen Sie ein Lighthouse-Audit auf Ihren 5 wichtigsten Seiten durch und vergleichen Sie mit Ihrem Pre-Migration-Baseline. -- WordPress sites are sometimes slower than well-tuned Drupal sites. Run a Lighthouse audit on your 5 most important pages and compare to your pre-migration baseline.
- Indexierungsrate -- wie viele Ihrer eingereichten URLs sind indexiert? Nach 30 Tagen sollten mindestens 80 % Ihrer Hauptinhaltsseiten indexiert sein. Weniger als 60 % deuten auf ein Crawlability-Problem hin (überprüfen Sie robots.txt und stellen Sie sicher, dass Sie Googlebot in WordPress-Einstellungen → Lesen nicht versehentlich blockiert haben). -- how many of your submitted URLs are indexed? At 30 days, you want at least 80% of your main content pages indexed. Anything under 60% suggests a crawlability problem (check robots.txt and make sure you didn't accidentally block Googlebot in WordPress Settings → Reading).
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.noindex by a misconfigured Yoast bulk action during migration. Caught at 30 days: fixable in an afternoon. Caught at 6 months: probably a ranking hole you're still trying to fill.
---
FAQ
Wie lange dauert eine Migration von Drupal zu WordPress wirklich?
Hängt vollständig von Seitengröße und Content-Komplexität ab. Eine 50-Seiten-Broschüren-Site: 2–3 Tage inklusive QA. Ein 5.000-Seiten-Nachrichtenarchiv mit benutzerdefinierten Content-Typen: 6–10 Wochen. Die SEO-Arbeit -- Audit, URL-Mapping, Redirect-Implementierung, Post-Launch-Monitoring -- addiert typischerweise 30–40 % zum Kern-Development-Estimate hinzu. Lassen Sie sich von niemandem etwas 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 Sie leistet. Ziehen Sie Ihre GSC-Daten. Jeder Content mit null Klicks über 16 Monate und ohne Backlinks ist eher ein Kandidat für Löschung als für Migration. Das Migrieren von dünnem, niedrigwertigem Content bläht Ihre WordPress-Site auf und kann das Crawl-Budget verwässern. Seien Sie rigoros. Löschen Sie aber niemals eine URL, die externe Backlinks hat, auch wenn die Seite selbst schlecht ist -- leiten Sie sie zu etwas Relevantem 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.GeneratePress for its clean markup and minimal overhead, or Kadence if the client wants more design flexibility. Avoid page-builder-heavy themes that output 400KB of unused CSS on every page load.
Brauche ich einen Entwickler oder kann ich das selbst machen?
Für eine kleine Site unter 50 Seiten mit einfachem Content und keinen benutzerdefinierten Post-Typen? Sie können wahrscheinlich mit FG Drupal to WordPress und dem Redirection-Plugin auskommen, wenn Sie die Schritte oben befolgen. Für alles Größere oder alles mit CPTs, komplexen Taxonomien oder einem bedeutsamen bestehenden SEO-Footprint -- holen Sie sich einen Developer. Die Kosten für die Behebung einer verpfuschten Migration sind immer höher als die Kosten für das korrekte Durchführen beim ersten Mal.
---
Die Migration selbst ist vielleicht 40% der Arbeit. Die anderen 60% sind die SEO-Infrastruktur, die du drumherum aufbaust – die Zuordnung, die Redirects, das Monitoring, die Geduld, die Daten 30 Tage lang zu beobachten, bevor du den Erfolg verkündest. Ich habe wunderschön gebaute WordPress-Sites in der Suche abschmieren sehen, weil die Redirect-Arbeit schlampig war, und ich habe zerzauste, kaum gestylte WordPress-Installationen alle Rankings halten sehen, weil die URL-Map akribisch war.
Mach die langweiligen Dinge richtig. Der Rest folgt in der Regel von selbst.