Eine WordPress-Rubrik umbenennen: Welche Adressen brechen und welche Weiterleitungsregeln die Lücke schließen

Eine Rubrik besitzt einen Anzeigenamen und einen Slug, den Bestandteil lesbarer URLs. Eine reine Namensänderung lässt Adressen normalerweise unverändert. Ein anderer Slug kann Archive, Feeds und bestimmte Beitragsadressen verändern. Den Umfang bestimmt die Permalink-Struktur.

Welche Adressen ändern sich?

Bei /%category%/%postname%/ geht eine ausgewählte Rubrik in die Beitragsadresse ein. Bei mehreren Rubriken beginnt der Kern normalerweise mit der niedrigsten Rubrik-ID; der Filter post_link_category kann die Auswahl ändern. Die Zuordnung zur umbenannten Rubrik beweist daher noch keine Adressänderung. Ein Eltern-Slug kann auch den hierarchischen Archivpfad einer Unterrubrik ändern, ohne den eigenen Slug der Unterrubrik anzupassen. Rubrikbasis, Sprachpräfix und Installationsverzeichnis spielen ebenfalls eine Rolle. Abfragebasierte Rubriklinks können die Rubrik-ID behalten.

Eine Migrationsliste hält betroffene Beitrags- und Rubrik-IDs mit tatsächlichen alten URLs fest. Nach der Änderung liefern get_permalink() und get_term_link() die Vergleichsziele. Bestehende Feeds, Seitenzahlen und jede Sprachfassung benötigen eigene Einträge oder Prüfungen.

Automatische Erkennung deckt nicht alles ab

redirect_canonical() kann einen Beitrag unter einem veralteten Pfad erkennen und zur aktuellen Adresse weiterleiten. Routing, Abfragevariablen, Sichtbarkeit und Filter beeinflussen das Ergebnis. Die Zielsuche bei 404 kann standardmäßig sogar einen teilweise passenden Beitrags-Slug verwenden. Erkennung garantiert weder vollständige Abdeckung noch das beabsichtigte Ziel.

Eine Slug-Änderung löscht die Rubrik nicht. Der alte Archivpfad kann trotzdem 404 liefern, während Plugins oder andere Routen anders reagieren. Eine ausdrückliche Alt-Neu-Zuordnung mit Prüfung, ob das Ziel den vorgesehenen Beitrag oder die vorgesehene Rubrik zeigt, ist verlässlicher als eine Annahme.

Eine Präfixregel braucht einheitliche Pfadenden

Eine Präfixregel ersetzt den Anfang eines Pfads. Die Regel passt, wenn die danach folgenden relevanten Pfadteile unverändert bleiben. Ändert sich auch der eigene Slug einer Unterrubrik, braucht dieser Pfad zuerst eine speziellere Regel. Das Beispiel setzt Apache ab 2.4.57, mod_rewrite und eine erlaubte .htaccess im Dokumentwurzelverzeichnis voraus. Eine Installation unter /blog/, eine Rubrikbasis oder ein Sprachpräfix erfordern angepasste Muster und Ziele.

RewriteEngine On
RewriteRule ^wordpress-hacks/tutorials-old(/.*)?$ /wordpress-plugins-tricks/tutorials-new$1 [R=301,L,B,BNP,BNE=/,NE]
RewriteRule ^wordpress-hacks(/.*)?$ /wordpress-plugins-tricks$1 [R=301,L,B,BNP,BNE=/,NE]

Die optionale Slash-Gruppe erfasst die alte Archivwurzel mit oder ohne abschließenden Slash, aber nicht /wordpress-hacks-other/. Die Unterrubrikregel steht zuerst. L beendet den aktuellen Regeldurchlauf.

Apache dekodiert den geprüften Pfad. B kodiert erfasste Sonderzeichen erneut, BNP verwendet %20 für Leerzeichen, BNE=/ erhält Trenner. Hier verhindert NE ein zweites Kodieren der vorbereiteten Ausgabe; NE allein schützt kodierte Eingaben nicht. Ohne neue Zielabfrage bleibt die ursprüngliche Abfrage ohne QSA erhalten. QSA verbindet eine vorhandene mit einer neu vorgegebenen Abfrage.

Tests mit Apache 2.4.68 umfassten Archivwurzeln, Feeds, Seitenzahlen, Unterrubrikwechsel, UTF-8, Leerzeichen, ein kodiertes Rautezeichen und wiederholte Abfrageparameter. Kodierte Slashes bleiben unter der Standardrichtlinie abgewiesen. Ungewöhnliche Bestands-URLs benötigen weiterhin eigene Tests. Die Regel leitet auch erfundene Pfadenden weiter: Ein 301 beweist kein vorhandenes Ziel. Bei uneinheitlicher Zuordnung sind genaue URL-Paare geeigneter. Neue Beiträge ausschließlich unter neuen Adressen benötigen keine Einträge für nie vorhandene alte URLs.

Das gespeicherte Migrationsskript dieser Website vom 2. September 2026 enthält zwölf Regeln: Eltern- und Unterrubrikpfade, jeweils mit und ohne Rubrikbasis, verteilt auf drei Sprachen. Diese Anzahl beschreibt nur diese Konfiguration.

Platzierung, Ketten und Prüfung

Spezielle Unterrubrikregeln stehen vor allgemeinen Elternregeln. Nach einem weiteren Umzug sollten ältere Regeln direkt auf die neueste gleichwertige Ressource zeigen. Kürzere Ketten verringern Latenz und Fehlermöglichkeiten. Google erklärt, dass dauerhafte Weiterleitungen keinen grundsätzlichen PageRank-Verlust verursachen; ein fester Verlust je Sprung ist keine zutreffende Begründung.

Eigene Apache-Regeln gehören außerhalb des WordPress-generierten Blocks, normalerweise oberhalb von # BEGIN WordPress. WordPress kann den markierten Abschnitt neu erzeugen. Eine Konfiguration auf Serverebene ist ebenfalls möglich. nginx hat eigene Syntax und Auswahlregeln; die Apache-Reihenfolge lässt sich nicht einfach übertragen.

curl --silent --show-error --connect-timeout 10 --max-time 20 \
  --dump-header - --output /dev/null \
  --write-out 'status=%{http_code} next=%{redirect_url}\n' \
  'https://example.com/wordpress-hacks/feed/?source=test'

Dieser GET-Aufruf zeigt erste Antwort und Ziel, ohne Weiterleitungen zu folgen. Die reservierte Beispieldomain benötigt eine Ersetzung durch die vorgesehene Testwebsite. Jede erfasste alte Adresse braucht eine Prüfung bis zum endgültigen Inhalt: genaues Ziel, richtiger Beitrag oder Archiv, Status, Feed-Format und gültige Seitenzahlen. Abfragewerte, kodierte Zeichen und ein nicht vorhandenes Pfadende sind hilfreiche Testfälle. HEAD kann von GET abweichen; Browsercaches können eine korrigierte Serverregel verdecken.

301-Redirect-Regel-Generator bietet einen Ausgangspunkt zur Regelvorbereitung. Erzeugte Ausgaben benötigen weiterhin den Abgleich mit URL-Bestand, Serverkontext und Kodierungstests. Ein Generator kann den richtigen Inhalt jedes Ziels nicht belegen.

Fragen und Antworten

Ändern sich Links in Beiträgen automatisch?

Gespeicherte Links bleiben normalerweise unverändert, unabhängig von absoluter oder relativer Schreibweise. Dynamische Rubrikeinträge im Menü können über dieselbe ID die neue URL erzeugen; individuelle Links brauchen eigene Aufmerksamkeit. Datenbankänderungen benötigen Sicherung, begrenzten Ersetzungsplan und Probelauf. WP-CLI search-replace berücksichtigt serialisierte Werte. Tabellenauswahl, maskierte Darstellungen und Ausnahmen wie GUID-Spalten brauchen trotzdem Planung. Serialisierte Werte speichern strukturierte Daten als Text und können die Byte-Längen einzelner Zeichenketten enthalten. Blindes SQL-Ersetzen kann den Text ändern, ohne diese Längen anzupassen. Dadurch wird der gespeicherte Wert möglicherweise unlesbar.

Warum zunächst mit 302 testen?

Eine temporäre Weiterleitung kann eine vorschnell erklärte dauerhafte Umstellung vermeiden. Weder 302 noch 301 bestimmen allein die Speicherdauer: Ausdrückliche Header und Cacheverhalten spielen eine Rolle. Staging-Tests mit passenden Cachevorgaben und einem frischen Client verringern Verwechslungen. Eine bestätigte dauerhafte Umstellung kann anschließend 301 verwenden.

Wie lange sollten Weiterleitungen bleiben?

Google empfiehlt Umzugsweiterleitungen möglichst lange, normalerweise mindestens ein Jahr. Lesezeichen, Feeds und fremde Links können eine längere Aufbewahrung begründen. Interne Links sollten direkt auf aktuelle Adressen zeigen.

Serverregel oder WordPress-Hook?

Eine frühe Serverweiterleitung kann den Start von PHP und WordPress vermeiden. Ein Hook bleibt sinnvoll ohne Serverzugriff oder bei benötigter Anwendungslogik. Der Aufwand hängt von Caches, Plugins und Infrastruktur ab und entspricht nicht zwangsläufig einem vollständigen Seitenaufruf. Beide Ansätze lassen sich versionieren und benötigen wiederholbare Prüfungen.

Quellen

• WordPress: Rubrikverwaltung
• WordPress: Beitragsadressen erzeugen
• WordPress: Archivlinks für Taxonomiebegriffe
• WordPress: Kanonische Weiterleitungen
• WordPress: Permalink nach einem 404-Fehler ermitteln
• Apache HTTP Server: RewriteRule-Flags
• Apache HTTP Server: Verarbeitung von Weiterleitungsregeln und URL-Kodierung
• Google-Suche: Websiteumzug mit geänderten URLs
• WP-CLI: Suchen und Ersetzen
• RFC 9111: HTTP-Zwischenspeicherung
• curl: Handbuch