WordPress Migration: Domain-Umzug in die eigene Web-App

Drei Jahre WordPress, zwei Domains, zwei Sprachen: Meine deutsche Website lief auf antonioblago.de, meine englische Web-App mit den SEO-Tools auf antonioblago.com. Im September 2026 habe ich beides zusammengeführt und die WordPress-Site komplett in die eigene Web-App umgezogen. Die unbequeme Wahrheit vorweg: Die Migration lief von der starken Domain in die schwache. Die .de brachte rund das Zwölffache der Klicks.^[5]

Dieser Artikel ist kein Tutorial für ein Migrations-Plugin. Er zeigt, wie eine WordPress Migration mit Domain-Umzug wirklich abläuft, wenn man sie ernst nimmt: welche Zahlen ich vorher erhoben habe, warum ich in Wellen statt mit einem Big Bang umgezogen bin, wie 867 Redirect-Regeln entstanden sind, was hreflang dabei erzwingt und was die Zieldomain heute bei PageSpeed liefert. Am Ende steht eine Checkliste mit zwölf Schritten, die du für deinen eigenen Umzug nutzen kannst.

Ausgangslage: warum weg von WordPress und was die Zahlen sagten

Der Grund für den Umzug war die Zweiteilung. Auf der .de lag der deutsche Blog mit Case Studies, Podcast-Folgen und Landing-Pages. Auf der .com lief die Flask-App mit den Analyse-Tools und einem englischen Blog. Zwei Systeme, zwei Hostings, zwei Bild-Ordner, zwei Login-Welten. Jede Änderung an Design, Consent oder Navigation musste doppelt gemacht werden.^[5]

Bevor ich irgendetwas angefasst habe, wollte ich wissen, was auf dem Spiel steht. Die Search Console über 365 Tage, Stand 18. August 2026:^[5]

Zwei Dinge fielen sofort auf. Erstens: Die Zieldomain hatte mehr verweisende Domains als die Quelle. Der Verlust an Autorität war damit kein Hauptrisiko. Zweitens: Der Traffic der .de hing an sehr wenigen Seiten. Vier URLs trugen rund 60 Prozent aller Klicks, die stärkste allein 1.431, die nächsten 1.002, 394 und 333.^[5] Diese vier URLs waren das gesamte Migrationsrisiko. Alles andere war Longtail.

Der blockierende Befund

Beim Abgleich der 137 migrationsrelevanten URLs mit der Datenbank der Web-App kam der eigentliche Schock: 76 deutsche Artikel lagen bereits als veröffentlicht in der Datenbank, wurden aber nie ausgeliefert, weil es schlicht keine /de/blog/-Routen gab. Die Blog-Routen filterten fest auf Englisch.^[5] Hätte ich die Redirects zuerst gesetzt, wäre jede Weiterleitung auf einer 404-Seite gelandet. Der Routenbau war damit die Voraussetzung der Migration.

Dazu kam eine Liste an Schäden, die schon vor jedem Umzug wirkten: deutsche Artikel mit deutschem Slug im englischen Blog, Trailing-Slash-Dubletten mit und ohne Schrägstrich, hreflang nur in eine Richtung, Entwürfe, die per Slug öffentlich abrufbar waren, und zwei Keyword-Seiten, die sich domainübergreifend selbst kannibalisierten.^[5] Das Aufräumen dieser Punkte wurde zur Welle 0.

Der Plan: Wellen statt Big Bang

Wer von der starken in die schwache Domain zieht, kann sich keinen Umzugstag leisten, an dem alles gleichzeitig kippt. Ich habe die 137 URLs deshalb nach Traffic gestaffelt und in Wellen geplant. Die Baseline kam zuerst: ein Search-Console-Export beider Properties über zwölf Monate mit 20.290 Zeilen, Backlink-Summaries und ein Inventar aller 134 Sitemap-URLs mit Statuscode.^[5] Ohne diese Zahlen kann man später nicht sagen, ob der Umzug Traffic gekostet hat oder ein Google-Update dazwischenkam.

Die Erfolgskriterien habe ich vorher festgeschrieben, damit ich sie mir hinterher nicht zurechtbiege: organische Klicks beider Domains zusammen nach zwölf Wochen bei mindestens 90 Prozent des Ausgangswerts, die fünf Top-URLs innerhalb von plus/minus zwei Positionen, keine 404-Fehler auf weitergeleiteten URLs in der Search Console, alle 76 deutschen Artikel erreichbar und indexiert.^[5]

Google selbst gibt zwei Leitplanken vor, die den Zeitplan bestimmen: Weiterleitungen sollen so lange wie möglich bestehen bleiben, in der Regel mindestens ein Jahr, damit alle Signale inklusive der Links Dritter auf die neuen URLs übertragen werden.^[1] Und beim Wechsel der Domain gehört eine Adressänderung in der Search Console für die alte Property dazu.^[10]

Die Technik hinter dem Umzug: Redirects, hreflang, Bilder, Hosting

867 Redirect-Regeln aus Crawl, Sitemap und Plugin-Export

Ein Redirect-Plugin in WordPress hätte mir nichts genützt, weil WordPress nach dem Umzug nicht mehr existiert. Die alte Domain zeigt per DNS auf einen eigenen, winzigen Redirect-Service: eine Flask-App hinter gunicorn auf Railway, die nichts anderes tut, als alte Pfade auf neue URLs abzubilden.^[6] Die Regeln erzeugt ein Generator aus drei Quellen: dem Export des alten SEO-Plugins, der Sitemap und einem vollständigen Crawl der alten Site mit 27.056 Links und 1.037 eindeutigen internen Pfaden.^[6]

Der Crawl war entscheidend. Die Plugin-Liste und die Sitemap kannten weder die Rechtsseiten noch die Autorenarchive noch die alten Kategorie-Präfixe, die WordPress live schon seit Jahren weiterleitete. Erst der Abgleich gegen den Crawl hat diese Lücken sichtbar gemacht. Das Ergebnis: 867 exakte Regeln plus drei Regex-Regeln.^[6]

Genauso wichtig wie die 301 ist die bewusste 410. Der alte Mitgliederbereich mit 137 Pfaden und 110 WordPress-Assets aus JavaScript, CSS und Fonts liefern absichtlich "Gone" statt einer Weiterleitung ins Nichts.^[6] Eine 301, die auf einer 404 endet, ist für Google schlechter als ein sauberes 410, weil sie Crawl-Budget in einer Kette verbrennt.

hreflang muss in beide Richtungen zeigen

Vor dem Umzug verwiesen die englischen Artikel auf der .com per hreflang auf ihre deutschen Originale, aber die deutschen Seiten auf WordPress verwiesen nicht zurück. Google ist dabei eindeutig: Wenn Seite X auf Seite Y verweist, muss Y auf X zurückverweisen, sonst werden die Annotationen ignoriert oder falsch interpretiert.^[2] Das Sprachpaar wurde also nie erkannt.

Im neuen System entsteht hreflang aus der Datenbank. Jeder deutsche Artikel ist über ein Feld mit seiner englischen Fassung verknüpft, das Template rendert daraus beide Richtungen und die Sitemap listet DE und EN automatisch. Am 3. September hatten alle 92 deutschen Artikel eine englische Fassung, die Paare waren vollständig.^[7] Dazu kommt die zweite Regel von Google: Jede Sprachversion muss sich selbst und alle anderen Versionen listen.^[2]

Bilder: was gespiegelt wurde und was 410 bleibt

Bilder werden bei Migrationen gern vergessen, obwohl sie in der Bildersuche und in Links Dritter stecken. Ich habe 349 Dateien aus dem alten Upload-Ordner lokal gespiegelt und ins Repository der Web-App gelegt.^[6] Von 572 im Crawl gefundenen Bild-URLs werden 234 exakt und 180 über ihre WordPress-Größenvariante per 301 auf das Original weitergeleitet. 173 bleiben 410: fast ausschließlich dekorative Theme- und Landing-Page-Assets, die auf der neuen Site nicht mehr existieren.^[6]

Hosting-Wechsel und DNS-Cutover

Parallel zur Inhaltsmigration ist die Web-App selbst umgezogen, von PythonAnywhere zu Railway. Erst Staging als separate Instanz mit Kopie der Datenbank, dann am Abend des 3. September der DNS-Wechsel für www.antonioblago.com.^[7] Zwei Tage später, am 5. September, folgte der zweite DNS-Cutover: antonioblago.de und www.antonioblago.de zeigen seitdem auf den Redirect-Service.^[6]

Ein Detail, das mich fast erwischt hätte: Die deutsche Startseite. Solange /de auf der .com noch per 301 auf WordPress zeigte, hätte der Cutover eine Redirect-Schleife erzeugt, .de auf .com/de auf .de. Deshalb musste die deutsche Startseite auf der Zieldomain live sein, bevor die alte Domain umgeleitet wurde.^[7]

PageSpeed: von 58 über 73 auf 94

Eine Migration ist die beste Gelegenheit, Performance-Schulden zu bezahlen, weil man ohnehin jede Zeile des Layouts anfasst. Die alte WordPress-Site lag bei PageSpeed mobil bei einer Leistung von 58.^[12] Der Lighthouse-Ausgangswert der Zieldomain vom 6. August 2026, gemessen mit Moto-G-Power-Profil und langsamem 4G, war ernüchternd: Leistung 73, Barrierefreiheit 88, Best Practices 81, SEO 100. First Contentful Paint 3,8 Sekunden, Largest Contentful Paint 4,9 Sekunden. Total Blocking Time 0 ms und CLS 0,001 waren dagegen perfekt.^[4] Das gesamte Defizit lag im Netzwerk-Wasserfall vor dem ersten Pixel, nicht in JavaScript oder Layout.

Was den Unterschied gemacht hat

Die Befunde vom August lesen sich wie eine Checkliste typischer Altlasten: eine Redirect-Kette von der nackten Domain über einen unverschlüsselten http-Zwischenstopp zur www-Variante, 395 Millisekunden, bevor ein Byte HTML kam. Zehn render-blockierende Stylesheets, drei davon komplett unbenutzt. Zwei blockierende Scripts im Head. cache-control: no-cache auf allen eigenen Assets. Ein LCP-Bild ohne modernes Format und ohne Preload. Keine Resource Hints für sechs Fremd-Domains. Und sämtliche Security-Header fehlten, was allein den Best-Practices-Score auf 81 drückte.^[4]

Die Reihenfolge der Abarbeitung folgt dem, was Lighthouse selbst empfiehlt: kritische Ressourcen inline, nicht kritische verzögern, Unbenutztes entfernen.^[9] Konkret wurden die Stylesheets zu einem minifizierten Bundle, die Fonts liegen lokal und werden für den sichtbaren Bereich vorgeladen, das Hero-Bild bekam responsive Varianten und ein Preload, die statischen Assets lange Cache-Zeiten.^[4] Ein Punkt ist bewusst offen geblieben: Die Redirect-Kette der nackten Domain ohne www läuft weiter über zwei Sprünge, weil sie beim DNS-Anbieter konfiguriert wird und nicht im Code. Wer die Adresse direkt eintippt, zahlt diese 395 Millisekunden noch. Nichts davon ist Raketentechnik. Es ist die Art Arbeit, die in einem gewachsenen WordPress-Theme mit fünf Plugins nie jemand macht, weil jedes Plugin sein eigenes CSS mitbringt.

Was nach dem Umzug noch aufgefallen ist

Mit dem DNS-Cutover beginnt die Phase, in der echte Nutzer die Fehler finden. Drei Beispiele aus der ersten Woche.

Google Analytics lief seit der Einbindung nie. Die Tags waren mit der Cookiebot-Konvention eingebunden, type="text/plain" data-cookieconsent="statistics". Mein Consent-Manager ist aber CCM19, und der wertet diese Attribute nicht aus. Er erwartet seinen eigenen Script-Loader mit type="text/x-ccm-loader" und einer Gruppe, die im Backend an die jeweilige Einbindung geknüpft ist.^[11] Dazu kam, dass CCM19 mit defer geladen wurde und Skripte nur beim Parsen beobachtet. Ergebnis: Selbst nach "Alles akzeptieren" blieb das GA4-Tag Text. Aufgefallen ist das erst, als ich die Cookies der Seite mit einem echten Browser durchgespielt habe, einmal mit Ablehnen, einmal mit Akzeptieren.^[8] Die Lehre: Consent-Einbindungen testet man mit einem echten Klick im Browser.

Feedback von außen ist Gold. Zwei Kollegen aus CRO und UX haben auf LinkedIn sieben Punkte notiert, die ich nach Monaten am eigenen Layout nicht mehr gesehen habe: absteigende Balken auf den Vorschaubildern der Case Studies, die wie ein Abwärtstrend wirkten; ein Sprachhinweis, der das Dropdown-Menü verdeckte; siebenmal "Mehr erfahren" als Linktext auf einer Seite; ein Raster, das auf großen Monitoren nur die halbe Breite nutzte; drei schwebende Elemente, von denen keines zum Kontakt einlud; ein blasses Favicon; ein Haupt-CTA, der mobil im Burger-Menü verschwand.^[8] Alle sieben sind inzwischen umgesetzt, und die Case-Study-Bilder zeigen jetzt den tatsächlichen Uplift, etwa "+364 %" oder "1,2 Mio. €", statt einer generischen Grafik.

Alte Links verstecken sich in Modulen. Die Podcast-Übersicht verlinkte jede Folge noch auf die alte Domain, weil das Modul seine Daten aus der WordPress-Schnittstelle zog. Die Folgen lagen längst im neuen Blog. Jetzt kommt die Liste aus der eigenen Datenbank, inklusive englischer Fassung und automatischer Erkennung neuer Folgen.^[8] Solche Stellen findet kein Redirect-Check, weil die Links technisch funktionieren, sie laufen nur über einen unnötigen Umweg.

Checkliste: WordPress Migration in zwölf Schritten

1. Baseline sichern. Search Console beider Properties über zwölf Monate exportieren, Backlink-Profil und URL-Inventar mit Statuscodes ablegen.^[5]
2. URLs nach Traffic zuordnen. Welche URL hat schon ein Gegenstück in der neuen Umgebung, welche braucht Inhalt, welche darf sterben?^[5]
3. Routen vor Redirects. Jedes Weiterleitungsziel muss mit 200 antworten, bevor die erste 301 live geht. Das ist die Voraussetzung für alles Weitere.^[5]
4. hreflang beidseitig. Jede Sprachversion listet sich selbst und alle anderen, sonst ignoriert Google die Annotation.^[2]
5. Die alte Site komplett crawlen. Plugin-Export und Sitemap kennen weder Rechtsseiten noch Legacy-Pfade. Der Crawl schon.^[6]
6. 410 bewusst setzen. Was keinen Nachfolger hat, bekommt "Gone", keine Weiterleitung auf eine 404.^[6]
7. Bilder vor dem DNS-Wechsel sichern. Danach ist der alte Server weg und mit ihm jede Rettungsmöglichkeit.^[6]
8. Staging vor Produktion. Die neue Umgebung mit einer Kopie der Daten hochfahren und alle Gates durchlaufen, bevor DNS angefasst wird.^[7]
9. Startseite der Zielsprache zuerst. Sonst droht die Redirect-Schleife zwischen alter und neuer Domain.^[7]
10. Adressänderung in der Search Console für die alte Domain einreichen und die Redirects mindestens ein Jahr halten.^[1][10]
11. Consent mit echtem Klick testen. Ablehnen, akzeptieren, neu laden, Cookies und Requests vergleichen. Der Scanner des Consent-Tools sieht nur, was ausgeführt wird.^[8]
12. Nach zwölf Wochen messen. Klicks gegen die Baseline, Top-URLs gegen ihre alten Positionen, 404-Bericht der Search Console.^[5]

Fazit

Eine WordPress Migration von der starken in die schwache Domain ist eine Frage der Vorbereitung. Der Umzugstag selbst waren zwei DNS-Einträge. Die Arbeit davor waren die Baseline, 76 fehlende Routen, 867 Redirect-Regeln, 92 hreflang-Paare und die Performance-Schulden, die im alten System nie jemand bezahlt hätte. Die mobile Leistung ist von 58 auf der WordPress-Site auf 94 gestiegen, dazu kommen je 100 Punkte für Barrierefreiheit, Best Practices und SEO.^[12][3]

Ob der Umzug organisch gehalten hat, entscheidet sich nicht in Woche eins. Das Erfolgskriterium sind 90 Prozent der Klicks nach zwölf Wochen und die fünf Top-URLs innerhalb von zwei Positionen.^[5] Die Zahlen dazu liefere ich in einem Folgeartikel, mit derselben Baseline und derselben Messmethode.

Quellen

1. Google Search Central: Site move with URL changes. "Keep the redirects for as long as possible, generally at least 1 year." developers.google.com, abgerufen am 11.09.2026.
2. Google Search Central: Localized versions of your pages (hreflang). "If page X links to page Y, page Y must link back to page X ... those annotations may be ignored or not interpreted correctly." developers.google.com, abgerufen am 11.09.2026.
3. PageSpeed Insights, Mobil, https://www.antonioblago.com/, Bericht vom 11.09.2026, 16:40 Uhr: Leistung 94, Barrierefreiheit 100, Best Practices 100, SEO 100. Eigene Messung. pagespeed.web.dev.
4. Lighthouse-Analyse und Maßnahmenplan der Zieldomain vom 06.08.2026 (Moto-G-Power-Profil, langsames 4G): Leistung 73, Barrierefreiheit 88, Best Practices 81, SEO 100; FCP 3,8 s, LCP 4,9 s, TBT 0 ms, CLS 0,001. Eigene Messung, dokumentiert im Projekt-Repository.
5. Migrationskonzept antonioblago.de nach antonioblago.com vom 21.08.2026 mit Ausgangslage aus der Google Search Console (365 Tage, Stand 18.08.2026), Backlink-Daten aus DataForSEO, URL-Zuordnung, Wellenplan, Erfolgskriterien und Baseline-Export (02.09.2026). Eigene Auswertung, dokumentiert im Projekt-Repository.
6. Redirect-Service und Crawl-Abgleich, Stand 05.09.2026: Screaming-Frog-Crawl der alten Site (27.056 Links, 1.037 eindeutige Pfade), Redirect-Map mit 867 exakten Regeln und 3 Regex-Regeln, Bilderspiegel mit 349 Dateien, DNS-Cutover der alten Domain. Eigene Auswertung, dokumentiert im Projekt-Repository.
7. Arbeitsstand 02. bis 03.09.2026: deutsche Blog-Routen und 12 gespiegelte Landing-Pages, deutsche Startseite auf der Zieldomain, 92 deutsche Artikel mit englischer Fassung, Hosting-Wechsel von PythonAnywhere zu Railway mit DNS-Cutover. Eigene Dokumentation im Projekt-Repository.
8. Arbeitsstand 10. bis 11.09.2026: Consent-Analyse per Browser-Automatisierung (Ablehnen und Akzeptieren im Vergleich), Umsetzung des LinkedIn-Feedbacks, Umstellung der Podcast-Übersicht auf die eigene Datenbank. Eigene Dokumentation im Projekt-Repository.
9. Chrome for Developers, Lighthouse: Eliminate render-blocking resources. "Reduce the impact of these render-blocking URLs by inlining critical resources, deferring non-critical resources, and removing anything unused." developer.chrome.com, abgerufen am 11.09.2026.
10. Google Search Console-Hilfe: Change of Address tool. support.google.com, abgerufen am 11.09.2026.
11. PageSpeed Insights, Mobil, antonioblago.de (WordPress) vor dem Umzug: Leistung 58. Eigene Messung; Barrierefreiheit, Best Practices und SEO wurden dort nicht dokumentiert.
12. CCM19 Dokumentation: Cookies & Einbindungen, Abschnitt Script-Loader (type="text/x-ccm-loader", data-ccm-loader-src, data-ccm-loader-group). docs.ccm19.com, abgerufen am 11.09.2026.