Warum Google Domainmigrationen nach 4 Monaten zurücksetzt und wie man WooCommerce rettet

Der Wechsel einer Domain in einem aktiven WooCommerce-Shop gehört zu den technisch anspruchsvollsten Aufgaben im E-Commerce. Im Oktober 2026 wurde in den Google Search Central Foren und auf Search Engine Roundtable ein bemerkenswerter Fall dokumentiert: Vier Monate nach der vollständigen Einrichtung von 301-Weiterleitungen und der Bestätigung der Adressänderung in der Google Search Console begann die Suchmaschine plötzlich, organische Rankings und die Indexierung wieder auf die alte Domain zurückzuverlagern.

Viele Shop-Betreiber und Entwickler gehen fälschlicherweise davon aus, dass ein Domainumzug abgeschlossen ist, sobald die Search Console den Antrag bestätigt und erste Seiten der neuen Domain in den Suchergebnissen auftauchen. In der Praxis prüfen die Algorithmen von Google kanonische Signale fortlaufend. Sobald die technische Infrastruktur der neuen Domain Schwächen zeigt, kann die Suchmaschine die Migration eigenständig rückgängig machen.

Dieser Leitfaden analysiert die technischen Ursachen dieses Phänomens, deckt typische Fehlerquellen in WooCommerce-Datenbanken auf und beschreibt erprobte Verfahren zum Schutz vor drastischen Sichtbarkeitsverlusten.

#Warum Google nach einigen Monaten zur alten Domain zurückkehrt

Das Zurücksetzen einer Domainmigration ist kein zufälliger Fehler des Such-Crawlers, sondern das logische Resultat des Google Canonicalization Systems. Google betrachtet 301-Weiterleitungen und Anträge in der Search Console nicht als unumkehrbare Eigentumsübertragungen von Rankingsignalen. Die Suchmaschine stuft sie als starke Empfehlungen ein, die fortlaufend durch zahlreiche technische Parameter bestätigt werden müssen.

Wenn der Googlebot die alte Domain aufruft und einen Header vom Typ HTTP/1.1 301 Moved Permanently vorfindet, beginnt er mit der Übertragung von PageRank-Signalen auf die neue Zieladresse. Parallel dazu untersucht der Bot jedoch den Zustand der neuen Domain. Treten in den darauffolgenden Monaten technische Probleme auf:

1. Die neue Domain antwortet unter Last von Kunden und KI-Crawlern unregelmäßig mit Serverfehlern (Statuscodes 500, 502, 504).
2. Mehrere Unterseiten der neuen Domain liefern zwar den Status 200 OK, weisen jedoch leere Vorlagen oder PHP-Fehlermeldungen auf, was zu einer automatischen Einstufung als Soft-404 führt.
3. Die Tags rel="canonical" auf der neuen Website verweisen aufgrund fehlerhafter SEO-Plugins oder fest codierter Filter im Child-Theme fälschlicherweise auf die alte Domain.
4. Die interne Verlinkung (Hauptmenü, Fußzeile, Produktbeschreibungen, Brotkrümelnavigation) nutzt weiterhin Adressen der bisherigen Domain.
5. Das externe Backlink-Profil der neuen Domain bleibt minimal, während Caching-Fehler auf dem alten Server dazu führen, dass 301-Header verloren gehen.

Unter diesen Umständen sinkt der Vertrauenswert des Algorithmus in die neue Domain rapide. Wird eine kritische Schwelle der Unsicherheit überschritten, stuft der Googlebot die Migration als fehlerhaft oder vorübergehend ein und stellt schrittweise die Indexierung der ursprünglichen URLs wieder her.

#Wie Google kanonische Signale bei einem Domainwechsel bewertet

Die Kanonisierung in Suchmaschinen ist ein mehrstufiger Entscheidungsprozess. Er basiert nicht auf einer einzelnen Anweisung im HTML-Code, sondern vergleicht explizite Richtlinien mit dem tatsächlichen Verhalten der Infrastruktur.

#Welche kanonischen Signale über die Domain-Auswahl des Algorithmus entscheiden

Die folgende Übersicht zeigt die Gewichtung einzelner Signale bei der Bewertung durch den Googlebot:

Widersprechen sich diese Signale (wenn beispielsweise eine 301-Weiterleitung auf die neue Domain zeigt, das kanonische Tag im HTML-Code der neuen Domain jedoch zurück auf die alte Domain verweist), gerät der Algorithmus in einen Konflikt. Mit der Zeit setzt sich die Domain durch, die über die längere Historie und das stärkere externe Linkprofil verfügt.

#Warum fehlerhafte rel-canonical-Tags Migrationen in Google zurücksetzen

In WooCommerce-Installationen erzeugen SEO-Erweiterungen wie Yoast SEO, Rank Math oder The SEO Framework kanonische Tags basierend auf den WordPress-Optionen. Wenn Entwickler zwar die Datenbank kopieren, aber im Child-Theme alte Filterregeln übersehen:

// Problematischer Filter in der functions.php des Child-Themes
add_filter('wpseo_canonical', function($canonical) {
    return str_replace('neuer-shop.de', 'alter-shop.de', $canonical);
});

In diesem Fall sendet jede Artikelseite des neuen Shops ein klares Signal an den Googlebot: Dieses Dokument ist nur ein Duplikat, das Original liegt auf der alten Domain. Nach dem Erfassen Tausender solcher Seiten folgt der Crawler dieser Vorgabe und entfernt die neuen URLs aus dem Suchindex.

#Welche Fehler bei 301-Weiterleitungen einen WooCommerce-Shop zerstören

Eine saubere Weiterleitungskonfiguration erfordert deutlich mehr Sorgfalt als einige pauschale Zeilen in einer .htaccess-Datei. Bei umfangreichen Online-Shops führen fehlerhafte Routing-Regeln zu gravierenden Indexierungsproblemen.

#Warum Weiterleitungsketten und CDN-Limits eine Rückkehr zur alten Domain auslösen

Moderne Edge-Netzwerke weisen spezifische Beschränkungen auf. Die Plattform Cloudflare Pages besitzt beispielsweise ein festes Größenlimit für die Konfigurationsdatei _redirects von 100 KB (etwa 2.000 bis 2.500 statische Regeln). Wird eine Datei mit 400 KB hochgeladen, bricht die Bereitstellung nicht ab, sondern schneidet Regeln oberhalb dieser Grenze kommentarlos ab.

Die ersten 2.000 Produkte leiten somit sauber mit dem Statuscode 301 weiter, während die übrigen 15.000 Kategorie- und Artikel-URLs einen 404-Fehler erzeugen oder auf die Startseite umgeleitet werden.

Ein weiteres häufiges Problem sind Weiterleitungsketten:

Alte URL -> Neue URL (HTTP) -> Neue URL (HTTPS ohne www) -> Neue URL (HTTPS mit www und Schrägstrich)

Laut Googles Dokumentation zu HTTP-Fehlern folgt der Googlebot beim Crawlen von Webinhalten höchstens 10 Weiterleitungsschritten, das URL-Prüftool folgt Weiterleitungen überhaupt nicht. Der Leitfaden zum Umzug einer Website empfiehlt zudem, Ketten zu vermeiden und jede alte URL direkt auf ihr endgültiges Ziel umzuleiten. Jeder Zwischenschritt ist eine zusätzliche HTTP-Anfrage, bevor der Inhalt erreicht wird, und das für jede URL im Katalog.

#Wie man facettierte Navigation und Filter-Parameter sauber weiterleitet

WooCommerce-Shops erzeugen über GET-Parameter unzählige URL-Varianten für Produktfilter:

• ?filter_farbe=schwarz
• ?filter_groesse=xl&min_price=100
• ?marke=hersteller-a

Ein typischer Architekturfehler besteht darin, jeden einzelnen Parameter statisch in Konfigurationsdateien abbilden zu wollen. Dies führt zu riesigen Tabellen, die Webserver überlasten. Die saubere technische Lösung nutzt dynamische Regeln in Nginx:

# Nginx-Konfiguration für die alte Domain mit Erhalt von Abfrageparametern
server {
    listen 443 ssl http2;
    server_name alter-shop.de www.alter-shop.de;

    ssl_certificate /etc/ssl/certs/alter-shop.crt;
    ssl_certificate_key /etc/ssl/private/alter-shop.key;

    # Exakte Weiterleitung 1:1 unter Beibehaltung von Pfad und Parametern
    location / {
        return 301 https://neuer-shop.de$request_uri;
    }
}

Durch die Verwendung der Variablen $request_uri wird eine Anfrage für https://alter-shop.de/kategorie/schuhe/?filter_farbe=schwarz direkt an https://neuer-shop.de/kategorie/schuhe/?filter_farbe=schwarz in einem einzigen Netzwerkschritt weitergeleitet.

#Wie man die WooCommerce-Datenbank ohne Verlust von Taxonomie-Relationen migriert

Die Datenbank von WordPress nutzt spezielle Speicherformate. Einstellungen, Layouts von Gutenberg-Blöcken und Produkt-Metadaten werden häufig als serialisierte PHP-Objekte abgelegt.

#Warum direktes SQL-Suchen-und-Ersetzen serialisierte PHP-Daten beschädigt

Ein serialisierter PHP-String enthält exakte Längenangaben für Textelemente. Ein vereinfachter Eintrag in der Tabelle wp_options verdeutlicht dies:

s:19:"https://alter-shop.de";

Der Wert s:19 signalisiert eine Zeichenkette von genau 19 Zeichen. Führt man eine direkte Ersetzung per SQL aus:

-- GEFÄHRLICHE SQL-ABFRAGE: ZERSTÖRT SERIALISIERTE DATENSTRUKTUREN
UPDATE wp_options 
SET option_value = REPLACE(option_value, 'alter-shop.de', 'neuer-online-shop.de');

Die neue Domain neuer-online-shop.de umfasst 20 Zeichen, der Längenwert in der Datenbank bleibt jedoch bei s:19. Beim Einlesen über die Funktion unserialize() scheitert der PHP-Parser an der fehlerhaften Längenangabe. In der Folge verschwinden Einstellungen von Zahlungsgateways, Versandzonen werden zurückgesetzt und Block-Layouts im Gutenberg-Editor brechen zusammen.

#Fertiges WP-CLI-Skript für den sicheren Domainwechsel in der Datenbank

Das empfohlene Werkzeug für Domainanpassungen in WordPress ist WP-CLI. Es liest serialisierte Werte in den Arbeitsspeicher ein, ersetzt Texte, berechnet Längenangaben neu und serialisiert die Daten vor dem Schreiben in die Datenbank korrekt.

Das folgende Bash-Skript automatisiert diesen Ablauf inklusive Datenbanksicherung und Cache-Bereinigung:

#!/usr/bin/env bash
# Sichere Domainmigration für WooCommerce mit WP-CLI
set -euo pipefail

OLD_DOMAIN="alter-shop.de"
NEW_DOMAIN="neuer-shop.de"
WP_PATH="/var/www/neuer-shop/public"

echo "=== Starte Datenbankmigration ==="

# 1. Sicherung der Datenbank vor der Modifikation
wp db export "${WP_PATH}/backup-pre-migration-$(date +%F).sql" --path="${WP_PATH}"

# 2. Testlauf zur Überprüfung gefundener Einträge
echo "Prüfe Ersetzungen im Testlauf (Dry Run)..."
wp search-replace "https://${OLD_DOMAIN}" "https://${NEW_DOMAIN}" \
    --all-tables \
    --dry-run \
    --path="${WP_PATH}"

# 3. Tatsächliche Ersetzung für vollständige HTTPS-Adressen
echo "Führe Suchen-und-Ersetzen für HTTPS aus..."
wp search-replace "https://${OLD_DOMAIN}" "https://${NEW_DOMAIN}" \
    --all-tables \
    --precise \
    --recurse-objects \
    --path="${WP_PATH}"

# 4. Ersetzung reiner Domainnamen ohne Protokoll unter Ausschluss der GUID
wp search-replace "${OLD_DOMAIN}" "${NEW_DOMAIN}" \
    --all-tables \
    --precise \
    --skip-columns=guid \
    --path="${WP_PATH}"

# 5. Aktualisierung der Permalinks in WooCommerce
echo "Erneuere Permalink-Strukturen..."
wp rewrite flush --hard --path="${WP_PATH}"

# 6. Leeren des Objekt-Caches (Redis / Memcached)
wp cache flush --path="${WP_PATH}"

echo "=== Datenbankmigration erfolgreich abgeschlossen ==="

Der Parameter --skip-columns=guid ist von zentraler Bedeutung. Gemäß den WordPress-Entwicklungsstandards dient die Spalte guid in wp_posts als unveränderlicher Identifikator für Feed-Reader und sollte bei Domainumzügen niemals überschrieben werden.

#Wie lange man die alte XML-Sitemap und den alten Server aktiv halten muss

Ein gravierender Fehler besteht darin, den alten Webserver abzuschalten oder die Domainregistrierung nach sechs Monaten auslaufen zu lassen.

Google Search Central empfiehlt eine Mindestdauer von 12 Monaten für die Aufrechterhaltung der Weiterleitungsinfrastruktur. Im E-Commerce ist es ratsam, die alte Domain und deren Weiterleitungen dauerhaft zu behalten. Eine abgelaufene Domain kann von Dritten registriert und für Spam-Netzwerke missbraucht werden, was historische Backlinks entwertet.

Auf der alten Domain sollte zudem eine dedizierte XML-Sitemap erreichbar bleiben, die alle bisherigen URLs auflistet:

<?xml version="1.0" encoding="UTF-8"?>
<!-- XML-Sitemap auf alter-shop.de mit weitergeleiteten URLs -->
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://alter-shop.de/produkt/business-notebook/</loc>
    <lastmod>2026-10-14</lastmod>
  </url>
  <url>
    <loc>https://alter-shop.de/kategorie/elektronik/</loc>
    <lastmod>2026-10-14</lastmod>
  </url>
</urlset>

Diese Datei wird in der Google Search Console für die Property der alten Domain eingereicht. Sie dient dem Googlebot als Verzeichnis aller Seiten, die regelmäßig geprüft werden müssen, um die Beständigkeit der 301 Moved Permanently-Meldungen zu bestätigen.

#Wie man Server-Logs analysiert und Indexierungsrückschritte in der Search Console erkennt

Das frühzeitige Erkennen von Auffälligkeiten verhindert Umsatzeinbußen. Wenn ein Migrationsprozess ins Stocken gerät, zeigen sich erste Anzeichen in den Serverprotokollen lange vor sichtbaren Rankingverlusten.

#Welche Anomalien im Indexierungsbericht der Search Console auffallen

In der Google Search Console sollten drei Berichte genau beobachtet werden:

1. Bericht Seitenindexierung der neuen Domain: Ein rascher Anstieg von Gecrawlt: zurzeit nicht indexiert oder Duplikat: vom Nutzer nicht als kanonisch festgelegt. Dies zeigt an, dass der Googlebot zögert, neue URLs in den Index aufzunehmen.
2. Leistungsbericht der alten Domain: Steigen die Impressionen der alten Domain nach Monaten minimaler Aktivität wieder an, liefert Google den Nutzern erneut alte Adressen in den Suchergebnissen aus.
3. URL-Prüfung: Testen zentraler Kategorieseiten. Weist das Feld Von Google ausgewählte kanonische URL die alte Domain aus, während Vom Nutzer festgelegte kanonische URL die neue Domain nennt, liegt ein aktiver kanonischer Konflikt vor.

#Wie man HTTP-Statuscodes in Cloudflare Logpush und Nginx überwacht

Die Auswertung der Zugriffsprotokolle zeigt das Crawling-Verhalten in Echtzeit. Mit folgendem Terminalbefehl lassen sich Anfragen des Googlebots auf dem alten Server analysieren:

# Nginx-Zugriffsprotokoll nach Statuscodes für Googlebot filtern
awk -F'"' '$6 ~ /Googlebot/ { print $1, $2, $3 }' /var/log/nginx/alter-shop.access.log \
  | awk '{ print $1, $6, $7 }' \
  | sort | uniq -c | sort -nr | head -n 30

Im fehlerfreien Zustand dürfen ausschließlich 301-Codes auftreten. Das Erscheinen von 200, 302, 404 oder 502 signalisiert Fehlkonfigurationen, die sofort korrigiert werden müssen.

#Was man mit internen Links in Gutenberg-Blöcken und ACF-Feldern tun muss

Eine häufige Ursache für Rückabwicklungen von Migrationen in WordPress sind verbliebene interne Links. Trotz der Ausführung von wp search-replace können alte Adressen in unüblichen Datenformaten wie Base64-Strings, JSON-Strukturen in wp_termmeta oder statisch verlinkten Vorlagen verbleiben.

Folgende Bereiche erfordern eine gründliche Prüfung:

• Navigationsmenüs: Unter Design -> Menüs kontrollieren, ob Menüpunkte des Typs Individuelle Links feste Verweise auf alter-shop.de enthalten.
• Block-Vorlagen (Full Site Editing): HTML-Dateien im Verzeichnis /templates und /parts auf statische Links zu Impressum, AGB oder Kontaktseiten prüfen.
• ACF Flexible Content: Komplexe Startseiten speichern Beziehungen häufig als Beitrags-IDs, doch in Fließtextfeldern des WYSIWYG-Editors finden sich oft manuell eingefügte Links zur alten Domain.
• Kassen- und Checkout-Erweiterungen: Sicherstellen, dass Module für Zahlungsmethoden keine alten Rückruf-URLs in ihren Einstellungen gespeichert haben.

Mit einem konsolenbasierten Crawler lässt sich der Quellcode des neuen Shops auf alte Verweise überprüfen:

# Durchsuchen des neuen Shops nach verbliebenen internen Links zur alten Domain
wget --spider --recursive --no-verbose --output-file=wget-scan.log https://neuer-shop.de || true
grep "alter-shop.de" wget-scan.log || echo "Keine direkten Links zur alten Domain gefunden."

#Wie man in 7 Schritten vorgeht wenn Google die Domainmigration rückgängig macht

Sollte Ihr Shop von einer Rückabwicklung betroffen sein und die alte Domain erneut in den Suchergebnissen erscheinen, empfiehlt sich dieser systematische Ablauf:

+-------------------------------------------------------------------+
|               NOTFALLPLAN BEI ZURÜCKGESETZTER MIGRATION           |
+-------------------------------------------------------------------+
                                  |
                                  v
         [ SCHRITT 1: HTTP-Header prüfen und 301-Schleifen lösen ]
                 (Jede alte URL muss sauber mit 301 antworten)
                                  |
                                  v
        [ SCHRITT 2: Canonical-Tags auf der neuen Domain prüfen ]
               (Keine Seite darf auf die alte Domain verweisen)
                                  |
                                  v
       [ SCHRITT 3: Soft-404-Fehler im Produktkatalog beheben ]
               (Ausverkaufte Artikel müssen Status 200 liefern)
                                  |
                                  v
      [ SCHRITT 4: Interne Links in der Datenbank bereinigen ]
               (Menüs, ACF-Felder, Widgets und Vorlagen prüfen)
                                  |
                                  v
         [ SCHRITT 5: XML-Sitemaps aktualisieren und einreichen ]
               (Aktive Sitemaps auf alter und neuer GSC-Property)
                                  |
                                  v
       [ SCHRITT 6: Adressänderung in der Search Console erneuern ]
               (Antrag nach Fehlerkorrektur erneut einreichen)
                                  |
                                  v
      [ SCHRITT 7: Externe Signale für die neue Domain stärken ]
               (Google Unternehmensprofil, Social Media anpassen)

1. HTTP-Header überprüfen: Prüfen Sie mit cURL, dass jeder Pfad der alten Domain ohne Umwege mit dem Statuscode 301 auf das Pendant der neuen Domain leitet. Vermeiden Sie Zwischenschritte über HTTP oder abweichende Schreibweisen.
2. Kanonische Tags korrigieren: Kontrollieren Sie den Quellcode auf der neuen Domain. Das Tag rel="canonical" muss exakt mit der aktuellen URL übereinstimmen und korrekte HTTPS-Angaben enthalten.
3. Soft-404-Fehler abstellen: Prüfen Sie in der Search Console gemeldete Seiten ohne Inhalt. Ausverkaufte WooCommerce-Artikel sollten mit Status 200 OK, Hinweisen zur Verfügbarkeit und Alternativprodukten ausgeliefert werden statt mit leeren Seiten.
4. Datenbankbereinigung wiederholen: Führen Sie wp search-replace mit den Parametern --precise und --all-tables aus, um sicherzustellen, dass keine alten Adressen in Theme-Optionen oder Inhalten verbleiben.
5. Duale Sitemaps verwalten: Stellen Sie sicher, dass die Sitemap der neuen Domain nur saubere 200 OK-URLs enthält und die Sitemap der alten Domain alle weitergeleiteten Adressen aufführt.
6. Adressänderung neu beantragen: Sind seit dem ersten Antrag 180 Tage vergangen, reichen Sie die Adressänderung in der Search Console nach Beseitigung aller Fehler erneut ein.
7. Externe Signale aktualisieren: Passen Sie Verlinkungen im Google Unternehmensprofil, auf Social-Media-Kanälen und in Branchenverzeichnissen an, um klare Signale für die neue Adresse zu setzen.

#Technisches Fazit für Software-Architekten und Shop-Betreiber

Das Zurücksetzen einer Domainmigration durch Google ist ein deutliches Warnsignal: Die Algorithmen haben Diskrepanzen zwischen dem geplanten Domainwechsel und dem tatsächlichen Zustand der technischen Infrastruktur festgestellt.

In modernen E-Commerce-Architekturen basiert eine erfolgreiche Migration auf technischer Präzision:

• Weiterleitungen müssen direkt in einem einzigen Schritt erfolgen und Filter-Parameter beibehalten.
• WordPress- und WooCommerce-Datenbanken müssen über WP-CLI aktualisiert werden, um serialisierte PHP-Objekte zu schützen.
• Kanonische Tags und interne Links müssen ab der DNS-Umstellung ausnahmslos auf die neue Domain verweisen.
• Die alte Domain, das SSL-Zertifikat und die zugehörige XML-Sitemap müssen für mindestens 12 Monate aktiv bleiben.

Durch die konsequente Einhaltung dieser Vorgaben verhindern Sie eine Rückabwicklung der Indexierung und sichern die Umsätze Ihres Online-Shops langfristig ab.