{"id":13580,"date":"2026-10-17T12:45:00","date_gmt":"2026-10-17T10:45:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=13580"},"modified":"2026-10-09T23:24:04","modified_gmt":"2026-10-09T21:24:04","slug":"eine-wordpress-rubrik-umbenennen-welche-adressen-brechen-und-welche","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/wordpress-plugins-tricks-de\/tutorials-de-wordpress-plugins-tricks-de\/eine-wordpress-rubrik-umbenennen-welche-adressen-brechen-und-welche\/","title":{"rendered":"Eine WordPress-Rubrik umbenennen: Welche Adressen brechen und welche Weiterleitungsregeln die L\u00fccke schlie\u00dfen"},"content":{"rendered":"

Eine Rubrik umzubenennen ist ein Feld in der WordPress-Verwaltung. Bei einer Permalinkstruktur, die die Rubrik enth\u00e4lt, ist es zugleich eine \u00c4nderung an der Adresse jedes Beitrags darin und an der Adresse jedes zugeh\u00f6rigen Archivs und Feeds.<\/p>\n

Ein Teil dieser Adress\u00e4nderungen wird automatisch aufgefangen. F\u00fcr den \u00fcbrigen Teil sind weniger Weiterleitungsregeln n\u00f6tig, als die Zahl der betroffenen Beitr\u00e4ge vermuten l\u00e4sst.<\/p>\n

\n\"Drei
Drei Adressebenen, drei verschiedene Antworten – und nur zwei davon brauchen eine Regel.<\/figcaption><\/figure>\n

Was eine Umbenennung \u00e4ndert<\/h2>\n

Bei der Permalinkstruktur \/%category%\/%postname%\/<\/code> steckt der Rubrik-Slug in der Adresse jedes Beitrags. Ein Beitrag, der unter \/wordpress-hacks\/speed-up\/<\/code> lag, liegt in dem Moment unter \/wordpress-plugins-tricks\/speed-up\/<\/code>, in dem sich der Slug \u00e4ndert.<\/p>\n

Betroffen sind drei Adressebenen, und sie verhalten sich verschieden. Die Beitr\u00e4ge selbst. Das Archiv der Rubrik und ihr Feed. Und, sofern die Rubrik Unterrubriken hat, deren Archive ebenfalls – denn ihre Slugs enthalten \u00fcblicherweise den Elternslug und \u00e4ndern sich damit mit.<\/p>\n

Wer nur Beitr\u00e4ge z\u00e4hlt, untersch\u00e4tzt die Arbeit. Wer jede Ebene z\u00e4hlt, sieht, dass der gr\u00f6\u00dfte Teil aus Archiven besteht, und genau dort h\u00f6rt der Kern auf zu helfen.<\/p>\n

Was der Kern von selbst umleitet<\/h2>\n

Ein Beitrag wird \u00fcber 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\u00e4ndig ist redirect_canonical<\/code>, und es braucht keine Einstellung.<\/p>\n

Damit sind die Beitr\u00e4ge vollst\u00e4ndig abgedeckt, in jeder Sprache einer mehrsprachigen Seite, ohne eine einzige Regel. Das lohnt sich nachzupr\u00fcfen statt anzunehmen, denn ein Plugin, das kanonische Weiterleitungen aus eigenen Gr\u00fcnden abschaltet, nimmt es stillschweigend wieder weg.<\/p>\n

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\u00fcr den Feed unter diesem Archiv, und genau diese Adresse merken sich Feedleser und Sammeldienste.<\/p>\n

Eine Pr\u00e4fixregel statt einer Zeile je Beitrag<\/h2>\n

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\u00e4chst ohne Grenze.<\/p>\n

Eine Pr\u00e4fixregel ersetzt die Liste. Getroffen wird der alte Rubrikpfad und alles darunter, und der Rest des Pfades wandert unver\u00e4ndert hin\u00fcber.<\/p>\n

RewriteEngine On\nRewriteRule ^wordpress-hacks\/(.*)$ \/wordpress-plugins-tricks\/$1 [L,R=301,NE,QSA]<\/code><\/pre>\n
Die Klammergruppe h\u00e4lt, was auf die Rubrik folgte: einen Beitragsnamen, eine Unterrubrik, einen Feed, einen Abschnitt f\u00fcr die Seitenz\u00e4hlung. Das Kennzeichen QSA<\/code> reicht den Abfrageteil durch, was f\u00fcr Kampagnenparameter z\u00e4hlt. NE<\/code> h\u00e4lt kodierte Zeichen kodiert, was f\u00fcr jeden Beitragsnamen mit einem diakritischen Zeichen z\u00e4hlt.<\/p>\n
Als auf dieser Seite am 2. September 2026 eine Rubrik umbenannt wurde, waren 27 Beitr\u00e4ge in drei Sprachen betroffen. In die Konfiguration gingen zw\u00f6lf Regeln: vier je Sprache, f\u00fcr den Rubrikpfad und den Unterrubrikpfad, jeweils in den zwei Formen, die die Permalinkstruktur erzeugt. Keine einzige davon nennt einen Beitrag.<\/p>\n
\n\"Zwei
\n<\/figure>\n
Die Reihenfolge entscheidet<\/h2>\n
Zwei dieser Regeln je Sprache \u00fcberschneiden sich, denn der Unterrubrikpfad beginnt mit dem Rubrikpfad. Eine Regel, die auf ^wordpress-hacks\/<\/code> passt, passt auch auf wordpress-hacks\/tutorials-wordpress-hacks\/<\/code>.<\/p>\n
Apache liest die Regeln der Reihe nach und h\u00f6rt beim ersten Treffer mit dem Kennzeichen L<\/code> 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.<\/p>\n
Die Regel dazu ist einfach: l\u00e4ngere Pfade zuerst, k\u00fcrzere danach. F\u00fcr nginx gilt das nur teilweise, denn exakte location =<\/code>-Bl\u00f6cke werden vor Pr\u00e4fixbl\u00f6cken gepr\u00fcft, unabh\u00e4ngig von ihrer Reihenfolge in der Datei – ein Unterschied, der sich zu kennen lohnt, bevor Regeln zwischen beiden wandern.<\/p>\n
Ketten aus zwei Umz\u00fcgen<\/h2>\n
Eine zweite Umbenennung ein Jahr sp\u00e4ter erzeugt das Muster, das am leisesten am meisten kostet: Die alte Adresse leitet auf die Zwischenadresse, diese auf die aktuelle. Zwei Spr\u00fcnge, und Suchmaschinen geben \u00fcber jeden davon ein wenig weniger weiter.<\/p>\n
Das zu verhindern ist eher Gewohnheit als Technik. Vor dem Hinzuf\u00fcgen 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. \u00dcbrig bleibt ein Satz, in dem jede alte Adresse direkt auf die Adresse zeigt, die es jetzt gibt, gleich wie viele Umz\u00fcge zur\u00fcckliegen.<\/p>\n
Wohin die Regeln geh\u00f6ren<\/h2>\n
In einer WordPress-Installation geh\u00f6ren die Regeln \u00fcber<\/em> den Block mit der Markierung # BEGIN WordPress<\/code>. Alles zwischen dieser Markierung und # END WordPress<\/code> wird beim Speichern der Permalinks neu geschrieben, und dort abgelegte Regeln verschwinden ohne Hinweis.<\/p>\n
Nach der \u00c4nderung lohnt es sich, die alten Adressen je einmal aufzurufen, ohne der Weiterleitung zu folgen, um Code und Ziel zu sehen statt der Endseite.<\/p>\n
curl -sI -o \/dev\/null -w \"%{http_code} %{redirect_url}\\n\" https:\/\/example.com\/wordpress-hacks\/feed\/<\/code><\/pre>\n
Die Regeln zu einer Liste von Adresspaaren zu schreiben, ist die Aufgabe des 301-Redirect-Regel-Generators<\/a> in der Toolbox: Er fasst Paare mit demselben Ordnerwechsel zu einer Pr\u00e4fixregel zusammen, gl\u00e4ttet Ketten, sodass jede alte Adresse auf das Endziel zeigt, weist Schleifen und widerspr\u00fcchliche Ziele ab und schreibt das Ergebnis f\u00fcr Apache, nginx oder einen WordPress-Hook.<\/p>\n
\n
Fragen und Antworten<\/h2>\n
Was geschieht mit den Verweisen innerhalb der eigenen Beitr\u00e4ge?<\/h3>\n
Sie bleiben, wie sie sind. WordPress speichert Verweise im Beitragstext als vollst\u00e4ndige Adressen, und eine Umbenennung schreibt keinen davon um. Solange die Weiterleitungen greifen, funktionieren sie weiter: Verweise auf Beitr\u00e4ge laufen \u00fcber redirect_canonical, Verweise auf Archive \u00fcber die Pr\u00e4fixregel. Jeder Klick kostet aber einen Sprung, und jeder Crawler findet die alten Adressen im eigenen Inhalt der Seite immer wieder neu.<\/p>\n
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\u00e4ngenangaben ein einfaches Ersetzen per SQL zerst\u00f6rt. Werkzeuge wie wp search-replace aus WP-CLI ber\u00fccksichtigen das. Men\u00fceintr\u00e4ge, 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.<\/p>\n
Warum ist eine neue Pr\u00e4fixregel zuerst mit 302 zu testen?<\/h3>\n
Weil Browser eine 301 dauerhaft zwischenspeichern d\u00fcrfen und es h\u00e4ufig tun. Steht eine Regel in der falschen Reihenfolge und schickt die Unterrubrik in eine 404, h\u00e4lt jeder Browser, der diese Weiterleitung einmal gesehen hat, an ihr fest, auch wenn die Regel l\u00e4ngst korrigiert ist. Erst wenn alle alten Adressen am richtigen Ziel ankommen, wird aus der 302 eine 301.<\/p>\n
Wie lange m\u00fcssen die Weiterleitungsregeln bestehen bleiben?<\/h3>\n
So lange wie m\u00f6glich, im Zweifel dauerhaft. Google empfiehlt bei Adress\u00e4nderungen, 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\u00e4fixregeln kosten dabei fast nichts: Es bleiben zw\u00f6lf Regeln, die nicht mit der Zahl der Beitr\u00e4ge wachsen.<\/p>\n
Ist ein WordPress-Hook als Ort f\u00fcr die Weiterleitungen gleichwertig mit der .htaccess?<\/h3>\n
Im Ergebnis ja, im Aufwand nicht. Eine Regel in der .htaccess beantwortet die alte Adresse, bevor PHP \u00fcberhaupt startet. Ein Hook in WordPress l\u00e4uft 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.<\/p>\n
Der Hook hat trotzdem seinen Platz: auf Hosts, bei denen die Serverkonfiguration nicht zug\u00e4nglich ist, und dort, wo die Regeln zusammen mit dem \u00fcbrigen Code versioniert werden sollen. Ein Seitencache vor WordPress verringert den Unterschied nur, wenn er auch Weiterleitungen zwischenspeichert.<\/p>\n<\/div>\n
\n
Quellen<\/h2>\n