Domainumzug von WordPress: Was Google noch Jahre später mitschleppt

Ein Umzug, den ich begleitet habe, sah auf dem Papier abgeschlossen aus: alte Domain stillgelegt, Weiterleitung auf die neue Adresse eingerichtet, neue Seite live. Ein Jahr später stand im Indexierungsbericht der Search Console eine Liste, die niemand erwartet hatte — darunter Adressen mit Warenkorb-Parametern aus einem Shop, den es längst nicht mehr gab.

Nichts davon war ein Fehler der neuen Seite. Es war das Erbe der alten.

Die pfaderhaltende Weiterleitung ist richtig — und sie liefert alles mit

Es gibt zwei Arten, eine alte Domain umzuleiten. Die eine schickt jeden Aufruf pauschal auf die neue Startseite. Die andere behält den Pfad bei: Was unter alte-domain.de/irgendwas lag, landet auf neue-domain.de/irgendwas.

Die zweite Variante ist in fast allen Fällen die bessere. Sie erhält den Zusammenhang zwischen alter und neuer Adresse, und Google kann die Autorität der alten Seite übertragen. Eine pauschale Umleitung auf die Startseite wird dagegen häufig wie eine Fehlerseite gewertet — der Nutzer landet nicht bei dem, was er gesucht hat, und das merkt auch eine Suchmaschine.

Der Preis dieser richtigen Entscheidung: Die neue Seite bekommt sämtliche Altlasten der alten geliefert. Jede Produkt-URL, jeder Feed, jede Kontaktseite mit .php am Ende, jeder Warenkorb-Link, den irgendwo noch ein Link ins Netz gesetzt hat.

Was WordPress und WooCommerce hinterlassen

Diese Adressen kamen bei besagtem Umzug wieder hoch, und sie sind typisch:

Alle diese Adressen wurden brav weitergereicht — und liefen auf der neuen Seite ins Leere oder im Kreis.

Die drei Fehlerbilder, die dabei entstehen

Weiterleitungsketten. Der Aufruf einer alten Shop-Adresse durchlief drei Weiterleitungen hintereinander, bis er am Ziel ankam. Jede einzelne war für sich richtig eingerichtet, historisch gewachsen aus verschiedenen Umbauten. In Summe ist das langsam, und Google folgt Ketten nur begrenzt weit. Die Lösung ist unspektakulär: Jede alte Adresse bekommt eine Weiterleitung direkt auf ihr endgültiges Ziel.

Parameter, die überleben. Die Weiterleitung nahm den Warenkorb-Parameter mit auf die Zielseite. Damit existierte dieselbe Seite plötzlich in mehreren Varianten — einmal sauber und mehrfach mit angehängtem Parameter. Das erzeugt Dubletten, die Google erst wieder auflösen muss. Beim Weiterleiten gehört der Parameter weggeworfen, wenn er am Ziel keine Bedeutung mehr hat.

Tote Produktseiten. Für ein eingestelltes Sortiment gibt es kein sinnvolles Ziel. Eine Weiterleitung auf die Startseite oder eine Dienstleistungsseite wäre eine Notlüge, die Google zuverlässig als solche erkennt. Die ehrliche Antwort ist hier 410 Gone: Das gab es, das gibt es nicht mehr. Damit verschwinden diese Adressen schneller aus dem Index als mit einem 404, das immer ein „vielleicht kommt es wieder” mitschwingen lässt.

Die Falle, in die fast jeder zweimal tappt

Der unangenehmste Befund war ein anderer. Im Bericht stand eine Zeile, die widersprüchlich klingt: „Indexiert, obwohl durch robots.txt blockiert.”

Der Hintergrund: Warenkorb, Kundenkonto und Anmeldeseite sollten nicht in den Index. Der naheliegende Griff ist die robots.txt — dort ein Disallow, fertig. Nur steuert die robots.txt das Crawling, nicht die Indexierung. Google hält sich an die Sperre und liest die Seite nicht. Die Adresse selbst kann trotzdem in den Index wandern, wenn irgendwo ein Link darauf zeigt. Sie erscheint dann ohne Beschreibung, und der Titel wird aus fremden Verlinkungen geraten — im ungünstigen Fall steht im Suchergebnis der Name eines fremden Unternehmens.

Und das eigentlich gesetzte noindex auf der Seite? Sieht Google nie. Es steht auf einer Seite, die es nicht lesen darf.

Die Regel dahinter lautet: Ein Ausschluss wirkt nur, wenn der Crawler ihn sehen darf. Wer eine Seite aus dem Index halten will, muss sie crawlbar lassen und ihr ein noindex mitgeben — entweder als Meta-Tag im Seitenkopf oder, wenn man an die Seite selbst nicht herankommt, als HTTP-Header X-Robots-Tag. Die robots.txt bleibt für das reserviert, wo es tatsächlich nichts zu indexieren gibt: Verwaltungsbereiche, Exportverzeichnisse, Systempfade.

Nachher: erst das Datum prüfen, dann reparieren

Ein Drittel der gemeldeten Probleme war bei genauem Hinsehen bereits erledigt. Der Indexierungsbericht nennt zu jeder Adresse ein Crawl-Datum, und bei mehreren lag dieses Wochen vor der letzten Korrektur. Google beschrieb also einen Zustand, den es nicht mehr gab, und wartete nur auf den nächsten Besuch.

Wer das übersieht, repariert Dinge zweimal — oder, schlimmer, baut eine funktionierende Lösung wieder um, weil der Bericht sie noch als Problem führt. Deshalb vor jeder Maßnahme: Crawl-Datum gegen das Datum der letzten Änderung halten.

Was nach so einem Aufräumen bleibt

Am Ende standen ein paar Zeilen in der Serverkonfiguration: eine Regel für die Warenkorb-Parameter, je eine für Shop-Einstieg und Feeds, ein 410 für die alten Produktpfade, ein X-Robots-Tag für die Kundenbereiche und eine robots.txt, in der nur noch Systemverzeichnisse stehen. Dazu ein sauberer 301 statt eines temporären 302 für die www-Variante, was gern übersehen wird, weil beides im Browser gleich aussieht.

Und die Erkenntnis, die den größeren Teil der Arbeit ausmacht: Ein Domainumzug ist nicht an dem Tag fertig, an dem die Weiterleitung steht. Er ist fertig, wenn die alten Wege alle irgendwo ankommen — oder ehrlich sagen, dass es sie nicht mehr gibt.