SEO-Probleme nach einer WordPress-Migration beheben: Beginnen Sie mit der URL-Wahrheit

TL;DR: Ihre WordPress-Migration hat vermutlich nicht „das SEO ruiniert“. Sie hat nur die Spur zwischen alten URLs, neuen URLs, Redirects, Canonicals, Sitemaps, internen Links und inzwischen auch KI-Zitationen zerrissen. Die Reparatur beginnt also bei der URL-Wahrheit, nicht bei einem weiteren Plugin-Audit.

Die Migration hat Ihr SEO nicht getötet – die kaputte URL-Story schon.

Die meisten analysieren wordpress migration seo-Probleme von der falschen Seite. Sie fragen, ob WordPress, das neue Theme, der Hoster oder das SEO-Plugin den Einbruch verursacht hat. Manchmal ist eines davon beteiligt – meist, weil die URL-Kontinuität zerbrochen ist.

Bei mindnow habe ich WordPress-Migrationen gesehen, bei denen der Inhalt unverändert blieb und die Rankings trotzdem fielen, weil 600 alte URLs stillschweigend auf die Startseite zeigten. Das prüfe ich inzwischen, bevor ich irgendetwas auf seojuice.io oder vadimkravcenko.com anschaue.

Die schnellsten Erfolge sind meist langweilig: alte URL, neue URL, Statuscode, Canonical, Indexierbarkeit, Sitemap-Eintrag und interne Links. Genau in dieser Reihenfolge – nicht Titles, nicht Schema, nicht Core Web Vitals.

Joost de Valk, Gründer von Yoast SEO, fasste erfolgreiche Domain-Migrationen als „etwa 90 % Vorbereitung und 10 % Ausführung“ zusammen. Dieser Satz hilft auch nach einem schlechten Launch. Wurde die Vorbereitung vor dem Cut-over versäumt, ist die Reparatur eben nachgeholte Vorbereitung.

Die Aufgabe lautet: Beweisen, ob Google alte Nachfrage noch mit neuen Zielseiten verknüpfen kann. Wenn nicht, ist Copy-Rewriting Theater.

Zuerst den Einbruch klassifizieren, bevor Sie irgendetwas ändern

Nicht jeder Traffic-Verlust nach einer Migration hat dieselbe Ursache. Hoster-Umzug, Domain-Wechsel, Permalink-Änderung, Theme-Rebuild, CMS-Import oder Austausch des SEO-Plugins können alle denselben Chart produzieren: Organische Sitzungen runter, alle nervös.

Die erste Diagnose-Gabel ist simpel. Hat Google die URL verloren, misstraut es der neuen URL oder versteht es die Beziehung zwischen beiden falsch?

Schreiben Sie keinen Content um, bevor Sie wissen, ob Google die neue URL erreichen, verstehen und vertrauen kann. Ein Beitrag mit noindex braucht keine bessere Überschrift. Eine Produktkategorie, die auf die alte Domain canonicalisiert, braucht keinen längeren Text. Eine Landingpage, die auf die Startseite umleitet, braucht kein Schema-Markup.

Erst klassifizieren. Dann reparieren.

Baue die URL-Map wieder auf – auch wenn die Migration schon durch ist

John Mueller gab in den Google SEO Office Hours die klarste Version dieses Ratschlags, zitiert von Search Engine Journal:

„Ich denke, das Wichtigste ist wirklich, die einzelnen URLs zu verfolgen, sodass Sie eine klare Map haben, was vorher war und was künftig sein soll.“

„Einzelne URLs“ zählt bei WordPress. Das meint nicht nur Posts und Pages. WordPress erzeugt Oberflächen durch Themes, Plugins, Archive, Medien-Handling, Filter und alte Permalink-Fallbacks. Wer nur die sichtbare Menüstruktur migriert hat, hat wahrscheinlich die halbe Site übersehen.

WordPress-URL-Oberflächen, die oft vergessen werden

• Beiträge und Seiten
• WooCommerce-Produkt-URLs, Produktkategorien und der /shop-Basisslug
• Kategorien, Tags und Custom Taxonomies
• Autoren-Archive
• Datums-Archive, falls indexierbar
• Attachment-Pages und Media-URLs
• Archive von Custom Post Types
• Paginierte Archive
• Feed-URLs
• Alte ?p=123-Permalink-Fallbacks (ja, die funktionieren auf älteren Installationen noch)
• Varianten mit Slash / ohne Slash
• HTTP- zu HTTPS-Varianten
• www- zu non-www-Varianten
• Alte Staging- oder temporäre Host-URLs, die geleakt sind

Beginnen Sie mit Belegen, nicht mit Erinnerung. Exportieren Sie Landingpages aus Analytics. Exportieren Sie Top-Seiten aus der Google Search Console. Crawlen Sie die aktuelle Site. Ziehen Sie jeden Pre-Migration-Crawl heran, falls vorhanden. Fügen Sie Backlink-URLs aus Ihrem Link-Index hinzu, falls verfügbar. Dann alles in eine alte-zu-neue Map zusammenführen.

Ja, das ist der langweilige Tabellen-Teil – hier starten aber die meisten Recoveries (die Audits, die ich bei mindnow gerettet habe, führten immer zu einer fehlenden Spalte in irgendeinem früheren Sheet zurück). Spalten für alte URL, neue URL, HTTP-Status, Redirect-Ziel, Canonical-Ziel, Indexierbarkeit, Sitemap-Eintrag und Notizen. Gibt es kein Äquivalent, vermerken Sie das. Verstecken Sie es nicht hinter einem Homepage-Fallback.

Bei größeren Sites priorisieren Sie URLs mit Backlinks, Umsatz, organischen Klicks, Conversions oder KI-Zitationen. Ein totes Tag-Archiv von 2017 kann warten. Eine Produktkategorie, die Non-Brand-Sales brachte, nicht.

Redirects fixen, bevor Sie Titles, Copy oder Schema anfassen

In Googles offizieller Site-Move-Dokumentation steht:

„Behalten Sie die Redirects so lange wie möglich bei, in der Regel mindestens 1 Jahr.“

Dieser Satz gehört über jede WordPress-Migrations-Checkliste. Redirects verschwinden auf banale Weise. Jemand löscht den .htaccess-Block. Ein Redirect-Plugin wird beim Aufräumen deaktiviert. Ein Hoster-Umzug wirft Nginx-Regeln raus. Cloudflare-Page-Rules werden ersetzt. Die alte Domain läuft ab. Die Staging-Domain wird gelöscht. Niemand merkt es, bis die Search Console wie ein Tatort aussieht.

Ein Redirect hilft nur, wenn das Ziel dieselbe Intention bedient. Alter Blogpost → neuer Blogpost. Altes Produkt → gleichwertiges Produkt. Alte Kategorie → gleichwertige Kategorie. Alte Service-Seite → nächstbeste noch existierende Service-Seite. Ist das Ziel irrelevant, rettet der technische 301 den SEO-Wert nicht.

Wenn Sie einen Prozess brauchen, nehmen Sie diesen:

1. Alte URL-Liste crawlen und jeden Statuscode protokollieren.
2. Jede 3xx-Kette mit mehr als einem Hop markieren.
3. Jede alte URL markieren, die auf der Startseite landet.
4. Prüfen, ob die Zieldatei indexierbar ist.
5. Bestätigen, dass die Zielseite auf sich selbst oder das gewünschte Canonical verweist.
6. Hochwertige Redirects aus fragilen Plugin-Regeln in Server- oder Edge-Regeln verlagern, wo möglich.

Wenn Sie ein Plugin nutzen, exportieren Sie dessen Regeln, bevor Sie etwas ändern. Redirection, Rank Math, Yoast Premium und host-seitige Redirect-Panels können alle funktionieren. Das Problem ist meist die Zuständigkeit. Keiner weiß, welche Ebene maßgeblich ist.

Der Startseiten-Redirect ist kein Sicherheitsnetz

Googles Site-Move-Dokumentation warnt davor, viele alte URLs auf ein irrelevantes Ziel wie die Startseite umzuleiten, weil das als Soft 404 gewertet werden kann. In WordPress ist dieser Fehler verbreitet. Ein Admin sieht Hunderte 404 im Plugin und baut einen globalen Fallback auf /. Das Dashboard wirkt sauberer – der Such-Traffic wird schlechter.

Die Lösung ist langsamer, aber sicherer. Alte URLs auf das nächstbeste Äquivalent mappen. Gibt es kein Äquivalent, echten 404 oder 410 zurückgeben. Tote URLs ehrlich sterben lassen. Wichtige Seiten mit 1:1-Redirects schützen.

Besonders schmerzhaft ist das bei E-Commerce-Migrationen. Ein ausgelaufenes Produkt darf auf ein Ersatzprodukt oder die Elternkategorie umleiten. Ein gelöschtes Produkt ohne Ersatz verdient vielleicht einen 410. Ein gelöschtes Produkt, das auf die Startseite umleitet, lehrt Google nichts.

Das 180-Tage-Fenster der Change-of-Address

Das Change-of-Address-Tool in der Search Console hilft Google beim Site-Move, ersetzt aber keine Redirects. Laut Search Console Help verarbeitet das Tool die Signale 180 Tage lang nach Start der Migration (nicht für immer).

Nach diesem Fenster erkennt Google alte und neue Site nicht mehr als zusammengehörig, wenn die alte Site noch erreichbar ist. Die Praxis: Redirects müssen das Change-of-Address-Fenster überleben. Wird der alte Host in Monat 5 abgeschaltet, entsteht eine Klippe.

WordPress-Einstellungen prüfen, die leise jede Recovery blockieren

WordPress bricht selten nur eine Seite. Es zerbricht Templates. Diagnostizieren Sie nach Seitentyp, nicht per Zufalls-URL.

Beginnen Sie mit der offensichtlichen Einstellung, weil sie immer noch Schaden anrichtet: Einstellungen → Lesen → Suchmaschinen davon abhalten, diese Website zu indexieren. Staging-Sites haben das oft aktiv. Ein hektischer Launch nimmt es mit in die Produktion. Gleiches gilt für noindex-Regeln im SEO-Plugin, die vom Staging kopiert wurden.

Dann Canonicals prüfen. Ein Theme-Rebuild oder Plugin-Import kann Canonical-Tags auf die alte Domain, den temporären Host oder die falsche Sprachversion zeigen lassen. Das gerenderte HTML prüfen, nicht nur das Plugin-Feld. Cache kann alte Tags ausspielen, nachdem das Admin-Feld längst sauber wirkt.

Sitemaps verdienen dasselbe Misstrauen. WordPress-SEO-Plugins splitten Sitemaps nach Post-Typ und Taxonomie. Nach der Migration haben Sie vielleicht saubere Post-URLs in einer Sitemap und alte-Domain-Kategorie-URLs in einer anderen. Reichen Sie den Sitemap-Index ein und öffnen Sie dann die Child-Sitemaps manuell.

Robots.txt ist ein weiterer stiller Killer. /wp-content/ zu blockieren kann Google davon abhalten, CSS, JavaScript oder Bilder zu laden, die es zum Verständnis braucht. Ein Template-Pfad-Block kann ganze Gruppen treffen. Die gesamte Site zu blockieren passiert nach Staging-Launches immer noch. Ich habe es mehrfach gesehen.

Permalinks sind schlimmer, weil sie wie eine Content-Entscheidung aussehen. Von /%postname%/ auf /blog/%postname%/ zu wechseln, ohne Redirects, erzeugt eine URL-Migration in der Migration. Gleiches gilt für Category-Bases, das Entfernen des Trailing Slash, Änderungen an WooCommerce-Produkt-Basen.

Prüfen Sie außerdem Redirect-Reihenfolge, CDN-Regeln, Multilingual-Output, hreflang-Ziele, WooCommerce-Filter-URLs, Attachment-Pages, Pagination, Breadcrumbs und CPT-Archive. Ein falsches Template kann Hunderte URLs unterdrücken.

Wenn sich das wie eine Technical-SEO-Audit-Checkliste anfühlt: gut. Post-Migration-Recovery ist ein technisches Audit mit Zeitstempel und Verdächtigenliste.

Seiten zurückholen, die aus Googles Index verschwunden sind

Nehmen Sie eine wertvolle Seite, die Traffic verloren hat. Nicht zwanzig. Eine.

Erst die alte URL inspizieren. Liefert sie 301? Verkettet sie? Landet sie auf der richtigen neuen URL? Lädt das Ziel für Googlebot? Dann die neue URL inspizieren. Statuscode, Canonical, Robots-Direktiven, gerendertes HTML, interne Links, Sitemap-Eintrag und letztes Crawl-Datum bestätigen.

Nutzen Sie das URL-Prüftool der Search Console für die Live-URL, nicht nur für die indexierte Version. Die indexierte Version zeigt, was Google zuletzt gespeichert hat. Der Live-Test zeigt, was Google jetzt abrufen kann.

Dann nach Template skalieren. Hat ein migrierter Blogpost das falsche Canonical, haben es womöglich alle Blogposts. Ist eine Produktkategorie noindexed, sind es vielleicht alle. Ist ein Autoren-Archiv plötzlich indexierbar, erzeugt jedes Autoren-Archiv wieder Thin Pages.

Search-Console-Validierung ist langsam (Tage bis Wochen, nicht Stunden). Das bessere Frühsignal ist Crawl-Verhalten. Logs prüfen, falls vorhanden. Werden weiter Legacy-URLs abgefragt? Kommen Googlebot-Requests auf den Zielseiten an? Fallen 404s für wertvolle alte URLs?

Rankings erholen sich meist gruppenweise. Wenn reparierte Produktkategorien wieder gecrawlt werden und Impressionen zurückkehren, wenden Sie dieselbe Reparatur auf die restlichen Kategorien an. Hören Sie auf, Unrelateds zu ändern, während die erste Reparatur noch verarbeitet wird.

KI-Zitationen erzeugen jetzt ein zweites Migrationsproblem

Joost de Valk brachte es knapp auf den Punkt:

„Es gibt kein Change-of-Address-Formular für ein Modell, das ein Jahr vor Ihrem Umzug fertig trainiert wurde.“

Google kann Redirects crawlen. Die Search Console kann einen Site-Move verarbeiten. LLMs und KI-Antwort-Engines können jedoch alte Hostnamen oder URLs in Trainingsdaten, Retrieval-Indizes, Partner-Indizes oder gecachten Citation-Layern behalten. Ein sauberer 301 hilft Google, überschreibt aber nicht jede alte Zitation irgendwo anders.

Die Lösung ist kein Zauber. Redirects am Leben halten. Alte URLs zum bestmöglichen neuen Match auflösen lassen. Hochautoritäre Profile, Quellseiten, Organisation-Schema, sameAs-Verweise, XML-Sitemaps und interne Links aktualisieren. Wo möglich, Zitationen auf Plattformen anpassen, die KI-Systeme häufig einlesen.

Das ist für WordPress wichtiger, als viele zugeben (ich lag damit jahrelang falsch). Viele Migrationen verlassen sich auf Plugin- oder Hoster-Regeln, die nach drei Monaten entsorgt werden. Wenn KI-Zitationen noch auf alte URLs zeigen, sind diese Redirects die Brücke. Wird die Brücke gekappt, wird die Zitation zur Sackgasse.

Für angrenzende Aufräumarbeiten lesen Sie die SEOJuice-Guides zu Redirect-Ketten und 301-Redirects, XML-Sitemap-Best-Practices und Canonical-Tag-Fehlern.

Ein 14-Tage-Reparaturplan für WordPress-Migration-SEO

Sie können eine chaotische Migration retten, ohne alles auf einmal zu fixen. Die Reihenfolge zählt mehr als der Tool-Stack.

Tag 0 bis 1: Blutung stoppen

• Eigentum an alter Domain, altem Hoster, DNS, CDN und Search-Console-Properties sichern.
• Redirect-Kontrolle wiederherstellen, bevor Content editiert wird.
• Catch-all-Redirects zur Startseite deaktivieren.
• Versehentliche noindex-Tags und Robots-Blocks entfernen.
• Saubere Sitemap-Indizes der neuen Site einreichen.
• Stichprobe alter High-Value-URLs manuell testen.

Wenn Sie die alte Domain nicht mehr kontrollieren, wird Recovery schnell härter. Kontrolle zurückholen, bevor über Title-Tags diskutiert wird.

Tag 2 bis 4: Map wieder aufbauen

• Die alte-zu-neue URL-Tabelle erstellen.
• URLs mit Backlinks, organischen Klicks, Umsatz, Conversions und KI-Zitationen priorisieren.
• URLs nach Typ separieren: Posts, Pages, Produkte, Kategorien, Tags, Medien, Archive, Feeds.
• Redirects in Batches fixen, beginnend mit den wertvollsten Gruppen.
• Jeden Batch nach Deployment retesten.

Vertrauen Sie nicht „Alle Redirects erfolgreich importiert“. Crawlen !

Tag 5 bis 7: Templates reparieren

• Canonicals nach Seitentyp auditieren.
• Robots-Direktiven und noindex-Regeln prüfen.
• Titel, Headings, Schema, Breadcrumbs und interne Links durchsehen.
• Pagination- und Archiv-Templates prüfen.
• Hreflang-Ziele kontrollieren, falls relevant.
• WooCommerce-Kategorie-, Produkt- und Filter-Verhalten testen.

Hier zahlt sich auch ein WordPress Technical SEO Review aus. Sie suchen Template-Level-Fehler, nicht Einzelfälle.

Tag 8 bis 14: Recovery beweisen

• Search-Console-Coverage und Crawl-Statistiken beobachten.
• Logs nach Googlebot-Aktivität auf Legacy-Redirects prüfen.
• Rankings nach URL-Gruppe tracken, nicht nur nach Keyword.
• Analytics-Landingpages vor und nach der Reparatur vergleichen.
• Änderungen an Redirects, Templates und Sitemaps dokumentieren.

Wenn Traffic auf reparierten URL-Gruppen steigt, dieselbe Lösung skalieren. Wenn nichts passiert, keine wilden Edits – Map erneut prüfen.

Was Sie nach einer schlechten WordPress-Migration nicht tun sollten

Installieren Sie nicht drei weitere SEO-Plugins. Sie schaffen überlappende Canonicals, doppelte Sitemaps und Redirect-Regeln ohne Eigentümer.

Leiten Sie nicht jeden 404 auf die Startseite. Google hat klar gesagt, dass irrelevante Massen-Redirects als Soft 404 gelten können.

Ändern Sie nicht erneut die Permalink-Struktur, weil die aktuelle „schöner aussieht“. Saubere URLs sind nutzlos, wenn sie ständig wechseln.

Schreiben Sie keinen Content um, bevor Zugriff, Redirects, Canonicals und Indexierbarkeit repariert sind. Content-Qualität kompensiert keinen kaputten Pfad.

Löschen Sie alte Redirects nicht, weil „Google das bestimmt schon verstanden hat“. Google selbst empfiehlt, sie so lange wie möglich zu behalten, in der Regel mindestens ein Jahr.

Vertrauen Sie nicht dem Ranking der Startseite als Beweis, dass die Migration passt. Brand-Recovery kann Template-Collapse verdecken. Prüfen Sie die Landingpages, die früher Non-Brand-Traffic brachten.

Wenn alte URLs nicht erklären können, wohin sie gingen, hat Google keinen Grund zu raten.

FAQ

Wie lange dauert die SEO-Recovery nach einer WordPress-Migration?

Kleine Fixes zeigen Crawl- und Impression-Änderungen oft binnen Tagen. Ranking-Erholung dauert länger, weil Google alte URLs neu crawlen, Redirects verarbeiten, Canonicals updaten und Vertrauen in den neuen URL-Satz aufbauen muss. Bei größeren Sites denken Sie in Wochen, nicht Stunden.

Sollte ich nach der WordPress-Migration meine Sitemap erneut einreichen?

Ja, aber erst, wenn sie sauber ist. Eine Sitemap voller alter-Domain-URLs, noindex-Seiten oder Canonical-Mismatches verlangsamt die Diagnose. Öffnen Sie den Sitemap-Index und die Child-Sitemaps manuell, bevor Sie einreichen.

Reichen 301-Redirects aus, um Rankings zu bewahren?

Sie sind nötig, aber nicht das ganze Paket. Das Ziel muss relevant, indexierbar, intern verlinkt, korrekt canonicalisiert und in sauberen Sitemaps vorhanden sein. Ein 301 auf eine schwache oder irrelevante Seite kann trotzdem Traffic verlieren.

Was, wenn ich meine WordPress-Permalink-Struktur geändert habe?

Behandeln Sie es wie eine URL-Migration. Erstellen Sie eine Map von jedem alten Permalink zum neuen Ziel. Schließen Sie Category-Bases, Slash-Verhalten, Produkt-Basen, Pagination und alte ?p=123-Fallbacks ein, falls sie noch auflösen.

Kann ich den alten Host nach der Migration löschen?

Nur, wenn Redirects anderswo gehandhabt und getestet werden. Viele Sites verlieren Traffic, weil der alte Host der einzige Ort für Redirects war. Vor dem Abschalten alte URLs crawlen und sicherstellen, dass sie noch korrekt auflösen.

Fazit: Das Reparatur-Playbook hätte die Launch-Checkliste sein sollen

Eine WordPress-Migration-Recovery ist nicht glamourös. Sie besteht aus URL-Buchhaltung, Redirect-Disziplin, Template-Checks und Geduld. Dieselbe Checkliste, die den Einbruch repariert, hätte vor dem Launch existieren müssen.

Bei seojuice.io gilt dieselbe Regel: Langweilige URL-Kontinuität schlägt heroisches Aufräumen. Nutzen Sie diesen Artikel zweimal – einmal zur Reparatur der aktuellen Migration und einmal, bevor die nächste live geht.

Brauchen Sie Hilfe beim Finden des Bruchs?

Wenn Ihre WordPress-Migration organischen Traffic gekostet hat und die Ursache unklar bleibt, beginnen Sie mit der URL-Map und dem Redirect-Audit. SEOJuice hilft, die Panik in eine Repair-Queue zu verwandeln – und anschließend in eine Launch-Checkliste für die nächste Migration.