English
DeutschEine WordPress-Rubrik umbenennen: Welche Adressen brechen und welche Weiterleitungsregeln die Lücke schließen
Inhalt
Eine Rubrik umzubenennen ist ein Feld in der WordPress-Verwaltung. Bei einer Permalinkstruktur, die die Rubrik enthält, ist es zugleich eine Änderung an der Adresse jedes Beitrags darin und an der Adresse jedes zugehörigen Archivs und Feeds.
Ein Teil dieser Adressänderungen wird automatisch aufgefangen. Für den übrigen Teil sind weniger Weiterleitungsregeln nötig, als die Zahl der betroffenen Beiträge vermuten lässt.
Was eine Umbenennung ändert
Bei der Permalinkstruktur /%category%/%postname%/ steckt der Rubrik-Slug in der Adresse jedes Beitrags. Ein Beitrag, der unter /wordpress-hacks/speed-up/ lag, liegt in dem Moment unter /wordpress-plugins-tricks/speed-up/, in dem sich der Slug ändert.
Betroffen sind drei Adressebenen, und sie verhalten sich verschieden. Die Beiträge selbst. Das Archiv der Rubrik und ihr Feed. Und, sofern die Rubrik Unterrubriken hat, deren Archive ebenfalls – denn ihre Slugs enthalten üblicherweise den Elternslug und ändern sich damit mit.
Wer nur Beiträge zählt, unterschätzt die Arbeit. Wer jede Ebene zählt, sieht, dass der größte Teil aus Archiven besteht, und genau dort hört der Kern auf zu helfen.
Was der Kern von selbst umleitet
Ein Beitrag wird über seinen eigenen Slug gefunden. Trifft eine Anfrage auf eine Adresse, deren Rubrikteil nicht mehr passt, erkennt WordPress den Beitragsnamen trotzdem, bemerkt die abweichende kanonische Adresse und antwortet mit einer 301 auf die richtige. Zuständig ist redirect_canonical, und es braucht keine Einstellung.
Damit sind die Beiträge vollständig abgedeckt, in jeder Sprache einer mehrsprachigen Seite, ohne eine einzige Regel. Das lohnt sich nachzuprüfen statt anzunehmen, denn ein Plugin, das kanonische Weiterleitungen aus eigenen Gründen abschaltet, nimmt es stillschweigend wieder weg.
Archive haben keine Entsprechung. Eine Anfrage nach einem Archiv unter dem alten Slug ist eine Abfrage nach einem Term, den es nicht mehr gibt, und die Antwort ist eine 404. Dasselbe gilt für den Feed unter diesem Archiv, und genau diese Adresse merken sich Feedleser und Sammeldienste.
Eine Präfixregel statt einer Zeile je Beitrag
Die naheliegende Reparatur ist eine Liste: eine Weiterleitung je Beitrag, erzeugt aus einer Tabelle alter und neuer Adressen. Das funktioniert und altert schlecht. Jeder Beitrag, der danach in der Rubrik erscheint, braucht eine Zeile, an die niemand denkt, und die Datei wächst ohne Grenze.
Eine Präfixregel ersetzt die Liste. Getroffen wird der alte Rubrikpfad und alles darunter, und der Rest des Pfades wandert unverändert hinüber.
RewriteEngine On
RewriteRule ^wordpress-hacks/(.*)$ /wordpress-plugins-tricks/$1 [L,R=301,NE,QSA]Die Klammergruppe hält, was auf die Rubrik folgte: einen Beitragsnamen, eine Unterrubrik, einen Feed, einen Abschnitt für die Seitenzählung. Das Kennzeichen QSA reicht den Abfrageteil durch, was für Kampagnenparameter zählt. NE hält kodierte Zeichen kodiert, was für jeden Beitragsnamen mit einem diakritischen Zeichen zählt.
Als auf dieser Seite am 2. September 2026 eine Rubrik umbenannt wurde, waren 27 Beiträge in drei Sprachen betroffen. In die Konfiguration gingen zwölf Regeln: vier je Sprache, für den Rubrikpfad und den Unterrubrikpfad, jeweils in den zwei Formen, die die Permalinkstruktur erzeugt. Keine einzige davon nennt einen Beitrag.
Die Reihenfolge entscheidet
Zwei dieser Regeln je Sprache überschneiden sich, denn der Unterrubrikpfad beginnt mit dem Rubrikpfad. Eine Regel, die auf ^wordpress-hacks/ passt, passt auch auf wordpress-hacks/tutorials-wordpress-hacks/.
Apache liest die Regeln der Reihe nach und hört beim ersten Treffer mit dem Kennzeichen L auf. Steht die allgemeine Regel vorn, wird die spezifische nie erreicht, und die Unterrubrik landet auf einem Pfad, den es nicht gibt – eine 301 in eine 404, also schlechter als die schlichte 404, die sie ersetzen sollte.
Die Regel dazu ist einfach: längere Pfade zuerst, kürzere danach. Für nginx gilt das nur teilweise, denn exakte location =-Blöcke werden vor Präfixblöcken geprüft, unabhängig von ihrer Reihenfolge in der Datei – ein Unterschied, der sich zu kennen lohnt, bevor Regeln zwischen beiden wandern.
Ketten aus zwei Umzügen
Eine zweite Umbenennung ein Jahr später erzeugt das Muster, das am leisesten am meisten kostet: Die alte Adresse leitet auf die Zwischenadresse, diese auf die aktuelle. Zwei Sprünge, und Suchmaschinen geben über jeden davon ein wenig weniger weiter.
Das zu verhindern ist eher Gewohnheit als Technik. Vor dem Hinzufügen einer Regel werden die bestehenden Regeln nach einem Ziel durchgesehen, das gerade zur alten Adresse wird, und dieses Ziel wird im selben Arbeitsgang auf die neue umgeschrieben. Übrig bleibt ein Satz, in dem jede alte Adresse direkt auf die Adresse zeigt, die es jetzt gibt, gleich wie viele Umzüge zurückliegen.
Wohin die Regeln gehören
In einer WordPress-Installation gehören die Regeln über den Block mit der Markierung # BEGIN WordPress. Alles zwischen dieser Markierung und # END WordPress wird beim Speichern der Permalinks neu geschrieben, und dort abgelegte Regeln verschwinden ohne Hinweis.
Nach der Änderung lohnt es sich, die alten Adressen je einmal aufzurufen, ohne der Weiterleitung zu folgen, um Code und Ziel zu sehen statt der Endseite.
curl -sI -o /dev/null -w "%{http_code} %{redirect_url}\n" https://example.com/wordpress-hacks/feed/Die Regeln zu einer Liste von Adresspaaren zu schreiben, ist die Aufgabe des 301-Redirect-Regel-Generators in der Toolbox: Er fasst Paare mit demselben Ordnerwechsel zu einer Präfixregel zusammen, glättet Ketten, sodass jede alte Adresse auf das Endziel zeigt, weist Schleifen und widersprüchliche Ziele ab und schreibt das Ergebnis für Apache, nginx oder einen WordPress-Hook.
Fragen und Antworten
Was geschieht mit den Verweisen innerhalb der eigenen Beiträge?
Sie bleiben, wie sie sind. WordPress speichert Verweise im Beitragstext als vollständige Adressen, und eine Umbenennung schreibt keinen davon um. Solange die Weiterleitungen greifen, funktionieren sie weiter: Verweise auf Beiträge laufen über redirect_canonical, Verweise auf Archive über die Präfixregel. Jeder Klick kostet aber einen Sprung, und jeder Crawler findet die alten Adressen im eigenen Inhalt der Seite immer wieder neu.
Sauberer ist es, die alten Pfade in der Datenbank durch die neuen zu ersetzen. Dabei ist Vorsicht geboten: Manche Plugins speichern Adressen in serialisierten Werten, deren Längenangaben ein einfaches Ersetzen per SQL zerstört. Werkzeuge wie wp search-replace aus WP-CLI berücksichtigen das. Menüeinträge, die auf Rubriken zeigen, verweisen dagegen auf den Term selbst und ziehen den neuen Slug von allein nach, sofern sie als Rubrik und nicht als eigener Link angelegt wurden.
Warum ist eine neue Präfixregel zuerst mit 302 zu testen?
Weil Browser eine 301 dauerhaft zwischenspeichern dürfen und es häufig tun. Steht eine Regel in der falschen Reihenfolge und schickt die Unterrubrik in eine 404, hält jeder Browser, der diese Weiterleitung einmal gesehen hat, an ihr fest, auch wenn die Regel längst korrigiert ist. Erst wenn alle alten Adressen am richtigen Ziel ankommen, wird aus der 302 eine 301.
Wie lange müssen die Weiterleitungsregeln bestehen bleiben?
So lange wie möglich, im Zweifel dauerhaft. Google empfiehlt bei Adressänderungen, Weiterleitungen mindestens ein Jahr bestehen zu lassen, doch Feedleser, Lesezeichen und Verweise auf fremden Seiten fragen die alten Adressen oft noch nach Jahren an. Präfixregeln kosten dabei fast nichts: Es bleiben zwölf Regeln, die nicht mit der Zahl der Beiträge wachsen.
Ist ein WordPress-Hook als Ort für die Weiterleitungen gleichwertig mit der .htaccess?
Im Ergebnis ja, im Aufwand nicht. Eine Regel in der .htaccess beantwortet die alte Adresse, bevor PHP überhaupt startet. Ein Hook in WordPress läuft erst, nachdem WordPress geladen ist, samt aller Plugins und der Optionen, die vor jeder Seite gelesen werden. Jede Anfrage an eine alte Adresse kostet dann fast so viel wie ein Seitenaufruf, auch die eines Feedlesers, der einen alten Feed alle paar Minuten abfragt.
Der Hook hat trotzdem seinen Platz: auf Hosts, bei denen die Serverkonfiguration nicht zugänglich ist, und dort, wo die Regeln zusammen mit dem übrigen Code versioniert werden sollen. Ein Seitencache vor WordPress verringert den Unterschied nur, wenn er auch Weiterleitungen zwischenspeichert.
Passend dazu
