Normalerweise tauchen 404-Fehler im Web auf, wenn eine URL falsch eingegeben oder ein veralteter Link aufgerufen wurde. Änderungen an URLs können schnell passieren, mir zum Beispiel geht es manchmal so, dass mir erst nach der Veröffentlichung eines Beitrags einfällt, dass der Slug für einen Artikel nicht optimal ist.
Nur möchte natürlich niemand, dass Besucherinnen und Besucher auf 404-Seiten landen, daher gibt es verschiedene Plugins, um Redirects einzurichten, sodass auch veraltete Links zum richtigen Ziel führen.
Manchmal ist das Erstellen von manuellen Redirects aber gar nicht notwendig, weil WordPress verschiedene Handgriffe tut, um 404-Fehler zu vermeiden und solche Anfragen nach Möglichkeit auf Inhalte weiterzuleiten.
WordPress und die Suche nach alten URL-Versionen
Wenn der Slug eines Beitrags geändert wird, speichert WordPress den alten Slug in der Post-Meta-Tabelle mit dem Schlüssel _wp_old_slug ab. Ähnliches geschieht, wenn das Datum eines veröffentlichten Beitrags nachträglich geändert wird: WordPress speichert das alte Datum in der Meta-Tabelle als _wp_old_date.
Damit liegt in der Datenbank alles bereit, um beim Aufruf einer ungültigen URL zu schauen, ob das vielleicht mal ein gültiger Slug war, und in dem Fall auf den Inhalt mit der neuen URL weiterzuleiten. Und genau das macht die Funktion wp_old_slug_redirect(), die an den template_redirect-Hook gehängt ist – allerdings nur für nicht-hierarchische Inhaltstypen, das heißt, dass beispielsweise Seiten nicht in den Genuss dieser Routine kommen.
Wenn ein 404 ausgegeben werden soll, wird in der Funktion geprüft, ob ein alter Slug für den ermittelten Inhaltstyp in der Datenbank vorkommt. Ist das nicht der Fall, wird nach Änderungen des Veröffentlichungsdatums gesucht.
Falls eine ID ermittelt werden konnte, wird ein 301-Redirect an die neue URL durchgeführt. Wenn ihr also den Slug oder das Veröffentlichungsdatum eines Beitrags oder eines anderen nicht-hierarchischen Inhalts über das normale Interface verändert, solltet ihr kein Redirect-Plugin brauchen, damit die alte URL korrekt weitergeleitet wird.
Grenzen der Methode mit alten Slugs und Daten
Änderung der Permalink-Struktur
Wenn ihr die Permalink-Struktur umstellt, müsst ihr euch eventuell um manuelle Redirects kümmen, wobei es auch hier Fälle gibt, in denen die automatischen Weiterleitung funktionieren.
Wenn ihr bisher zum Beispiel die Struktur /%year%/%monthnum%/%day%/%postname%/ hattet und nun auf die Struktur /%year%/%postname%/ umstellt, wird der Redirect des aktuellen Slugs von /%year%/%monthnum%/%day%/%postname%/ auf /%year%/%postname%/ funktionieren. Allerdings nicht wegen wp_old_slug_redirect() (die Funktion ermittelt in dem Fall den Inhaltstyp page, weshalb dort nicht nach alten Slugs gesucht wird), sondern redirect_guess_404_permalink(), die in der redirect_canonical()-Funktion aufgerufen wird. Darin wird unter anderem geschaut, ob in der Posts-Tabelle ein Inhalt mit dem übergebenen Slug existiert, und falls ja, wird auf den weitergeleitet.
Wenn ihr aber von der Datum-Struktur zum Beispiel auf /%postname%/ umstellt, funktioniert auch das nicht mehr, da im Rewrite-Objekt aus der alten URL-Struktur kein name ermittelt werden kann.
Republish von Beiträgen
Wenn ihr Beiträge neu veröffentlichen wollt, weil ihr den Inhalt komplett überarbeitet habt, könnt ihr sie dafür ein paar Minunten in die Zukunft planen.
Dabei wird kein Eintrag in der Datenbank für Änderung von Datum und/oder Slug eingefügt. Das heißt, wenn ihr das Datum in der Permalinkstruktur berücksichtigt und es sich durch den Republish ändert, wird eine automatische Weiterleitung nicht funktionieren. Gleiches gilt, wenn der Slug geändert wird (wobei es weiter funktionieren sollte, wenn nur etwas an den Slug angehängt wird, da in redirect_guess_404_permalink() standardmäßig nicht nur exakte Treffer des post_name gesucht werden).
Sonderfall mit ID im Slug
Ich habe bei meiner eigenen Site das Permalinkformat /%postname%-%post_id%/. Dadurch leitet WordPress alles auf den Beitrag mit der entsprechenden ID weiter, solange in der URL hinten die ID stimmt und davor ein Bindestrich und mindestens ein weiteres Zeichen kommt. So kann der Beitrag mit der URL https://florianbrinkmann.com/statische-gutenberg-bloecke-11415/ beispielsweise auch über https://florianbrinkmann.com/bloecke-11415/ oder https://florianbrinkmann.com/🎉-11415/ aufgerufen werden.
Der Grund dafür ist, dass in der redirect_canonical()-Funktion geprüft wird, ob die ID in der URL übergeben wird, und falls das der Fall ist, wird entsprechend die Redirect-URL ermittelt. Diese Lösung behebt das Problem beim Republish, allerdings nicht das bei größeren Änderungen der Permalinkstruktur.
Fazit
Bei normalen Anpassungen von Beitrag-Slugs oder Slugs anderer nicht-hierarchischer Inhalte kümmert sich WordPress darum, dass alte URLs weitergeleitet werden.
Bei der Anpassung von Seiten-Slugs oder bei größeren/spezielleren Änderungen wie Permalinkstruktur-Anpassungen oder Republishes muss man allerdings gegebenenfalls selbst tätig werden.
Mentions