Geändert: ein 301-Redirect, aber der Browser schickt Besucher hartnäckig weiter auf die alte URL? Ein vertrautes Ärgernis für jeden, der schon einmal Site-Migrationen konfiguriert oder Linkstrukturen umgebaut hat.

Das Problem liegt weder am Server noch an WordPress. Der Browser merkt sich einen permanenten Redirect dauerhaft und fragt den Server nicht erneut an; so funktioniert die HTTP-Spezifikation. Bis der Cache abläuft oder der Nutzer ihn manuell löscht, bleibt die alte Regel wirksam.

Nachfolgend eine klare Strategie: wie Sie Redirects folgenlos testen, warum 302 beim Debugging die Nerven schont und was zu tun ist, wenn der Cache bei echten Besuchern bereits festsitzt.

💡 Kurzüberblick:

• Beginnen Sie immer mit 302 (temporär), testen Sie, und schalten Sie erst danach auf 301 (permanent) um
• Leeren Sie Ihren Browser-Cache nach jeder Änderung an Redirect-Regeln
• Für Chrome: DevTools → Network → Disable cache, oder Application-Tab → Clear site data
• Ist ein 301 bereits bei Nutzern gecached, hilft nur Abwarten oder Ändern der Ziel-URL

Wie der Browser einen 301-Redirect cached

Antwortet der Server mit dem Status 301 Moved Permanently, interpretiert der Browser das wörtlich: „Diese URL ist für immer umgezogen." Er legt das Paar „alte URL → neue URL" in seinem eigenen Redirect-Cache ab, getrennt vom Seiten- und Bild-Cache.

Öffnet der Nutzer (oder Sie als Entwickler) dieselbe Adresse erneut, sendet der Browser überhaupt keine Anfrage an den Server. Er setzt sofort die gespeicherte Ziel-URL aus dem Cache ein. Der Server sieht keine Anfrage, und Sie sehen nicht das aktuelle Verhalten.

Die HTTP-Spezifikation definiert keine feste Vorhaltezeit für einen solchen Cache. In der Praxis behalten Chrome, Firefox und Safari den 301 so lange im Cache, bis er explizit gelöscht wird. Der Cache-Control-Header des Servers kann vom Browser speziell bei 301 ignoriert werden, denn „permanent" heißt permanent.

Dieses Verhalten ist ein Feature, kein Bug. Es spart einen Round-Trip bei legitimen permanenten Umzügen (etwa einem Domain-Wechsel). In der Entwicklung wird es jedoch zur Falle.

Warum das bei der Konfiguration Probleme bereitet

Stellen Sie sich folgendes Szenario vor. Sie richten einen Redirect von der alten URL /old-page auf /new-page ein. Sie konfigurieren einen 301, testen ihn im Browser, und er funktioniert. Eine Stunde später stellen Sie fest, dass Sie einen Fehler gemacht haben: Die korrekte URL lautet /new-page/v2.

Sie ändern die Regel auf dem Server und klicken im Browser auf „Aktualisieren". Sie landen auf /new-page. Wieder. Denn der Browser hat sich bereits das erste Paar gemerkt und gibt dem Server keine Chance, die neue Regel zu zeigen.

Sie denken, der Redirect funktioniert nicht. In Wirklichkeit funktioniert er, nur nicht der, den Sie gerade konfiguriert haben.

Auf einer Testseite haben wir einmal eine halbe Stunde lang .htaccess-Regeln durchprobiert, bevor uns klar wurde, dass der Browser den Cache anzeigte. Cache geleert, und alles funktionierte sofort wie vorgesehen.

Schlimmer ist die Situation bei Besuchern. Haben Sie auf einer Produktivseite einen fehlerhaften 301 aktiviert, bekam jeder, der in diesen Minuten die Seite besuchte, die falsche Regel in seinen Browser-Cache. Sie haben den Fehler auf dem Server in 10 Minuten behoben, aber deren Browser werden sie noch Tage oder Wochen lang auf die alte URL schicken, bis der Cache gelöscht wird.

Beachten Sie: Sie können den Redirect-Cache auf Nutzerseite nicht löschen. Kein Server-Trick erreicht den Browser eines anderen.

Die 302 → 301-Strategie: folgenlos testen

Eine Regel, die Stunden Debugging spart und vor Fehlern auf der Live-Site schützt:

Beginnen Sie immer mit einem 302-Redirect (temporär). Wechseln Sie erst zu 301, wenn Sie sicher sind, dass die Regel korrekt ist.

Der Browser cached 302 nicht aggressiv; er fragt den Server bei jeder Anfrage neu an. Ändern Sie die Regel auf dem Server, übernimmt der Browser sofort das neue Verhalten. Kein Cache-Leeren nötig.

Schrittweises Vorgehen für jede URL-Änderung:

• Richten Sie einen 302-Redirect in .htaccess, der Nginx-Konfiguration oder über ein WordPress-Plugin (z. B. Redirection) ein.
• Öffnen Sie die alte URL im Inkognito-Modus oder mit aktivierter Option „Disable cache" in den DevTools.
• Prüfen Sie, ob Sie auf der korrekten Zielseite landen.
• Prüfen Sie 2-3 weitere URLs aus derselben Gruppe.
• Erst wenn alles getestet ist, ersetzen Sie 302 in den Regeln durch 301.
• Führen Sie einen abschließenden Check im normalen Browser-Modus durch.

In der Praxis kostet dieser Ansatz exakt zwei zusätzliche Minuten pro Redirect-Gruppe und eliminiert das Risiko eines „gecachten Fehlers" für Besucher vollständig.

Nutzen Sie das Redirection-Plugin für WordPress, legt es standardmäßig 301 an. Schalten Sie beim Anlegen einer Regel im Dropdown manuell auf 302 um und vergessen Sie nicht, nach dem Test auf 301 zurückzuschalten.

So leeren Sie den Redirect-Cache lokal

Wenn der Browser sich bereits einen fehlerhaften 301 gemerkt hat und Sie das aktuelle Verhalten nicht sehen können, hilft Folgendes:

Chrome. Öffnen Sie die DevTools (F12), gehen Sie zum Network-Tab und aktivieren Sie Disable cache. Oder setzen Sie einen vollständigen Reset: Application → Clear storage → Clear site data. Die zuverlässigste Methode für eine bestimmte Site ist chrome://settings/clearBrowserData → Cached images and files.

Firefox. Web Developer Tools → Network → Disable Cache. Für eine vollständige Leerung: History → Clear Recent History → Cache.

Safari. Develop → Disable Caches (das Develop-Menü aktivieren Sie unter Settings → Advanced).

Inkognito-Modus ist der schnelle Weg, um frisches Verhalten zu prüfen, ohne den Haupt-Cache zu leeren. Der Browser nutzt eine saubere Sitzung ohne gespeicherte Redirects.

Wichtige Nuance: Das Schließen des Browsers leert den 301-Redirect-Cache NICHT. Anders als der Session Storage überlebt der Redirect-Cache Browser-Neustarts. Nur explizites Leeren oder der Inkognito-Modus wirken.

Was tun, wenn der Cache bei Nutzern festsitzt

Das ist das unangenehmste Szenario: Ein fehlerhafter 301 war auf der Produktivseite einige Zeit aktiv, und ein Teil Ihrer Zielgruppe trägt ihn nun im Browser-Cache. Sie haben die Server-Regel korrigiert, aber diese Nutzer landen weiterhin an der falschen Stelle.

Folgendes können Sie tun:

• Ändern Sie die Ziel-URL auf eine neue. Zeigte der alte location-Header auf /page-v1 und Sie benötigen /page-v2, ersetzen Sie einfach die Adresse in derselben Regel. Browser mit gecachter alter Ziel-URL werden weiterhin dorthin gehen (das Problem). Neue Besucher hingegen gelangen an die richtige Stelle. Das löst das Problem für die bereits „Infizierten" nicht, stoppt aber die Ausbreitung.

• Nutzen Sie eine andere Redirect-Methode. Ist der 301 gecached, fragt der Browser den Server nicht an, aber die Server-Logik funktioniert für neue Besucher weiterhin. Fügen Sie auf der Zielseite einen JavaScript-Redirect als zusätzliche Ebene über dem HTTP-Redirect ein, für diejenigen, die noch auf der alten Seite landen.

• Ehrlich eingestehen: Es gibt keine direkte Heilung. Ihr Server erreicht den Browser des Nutzers nicht. Ist der Cache erst einmal geladen, wird er nur zurückgesetzt, wenn der Nutzer den Cache löscht oder über einen Inkognito-Link besucht. Glücklicherweise lebt der Redirect-Cache nicht ewig: Browser-Neuinstallation, Gerätewechsel und OS-Updates setzen ihn irgendwann zurück.

Unserer Erfahrung nach wird ein fehlerhafter 301 nur in zwei Fällen kritisch: bei einer Massenmigration (hunderte URLs) mit einem Fehler in den Regeln oder bei einem Redirect der Startseite. In beiden Fällen überwiegt der Schaden durch einen gecachten Fehler jede Zeitersparnis, die ein Überspringen des Tests brächte.

301, 302, 307, 308: Wann was verwenden

Damit keine Verwirrung aufkommt, halten Sie diese kurze Tabelle der Redirect-Codes griffbereit:

Für eine WordPress-Site genügt es in den allermeisten Fällen, den Unterschied zwischen 301 und 302 zu kennen. Die Codes 307 und 308 sind Nischenwerkzeuge für Situationen, in denen die Beibehaltung der HTTP-Methode kritisch ist (etwa wenn ein Formular ein POST-Request bleiben muss und beim Redirect nicht zu GET werden darf).

Kurz gesagt: 302 ist Ihr Arbeitswerkzeug während der Entwicklung. 301 ist der finale „Erledigt"-Stempel.

Eine weitere Falle: WordPress und Caching-Plugins

Bei WordPress stapelt sich das 301-Caching-Problem auf Server- und Plugin-Caching. Eine typische Situation:

Sie bearbeiten einen Redirect im Redirection-Plugin, klicken auf „Speichern", und er funktioniert nicht. Sie leeren den Browser-Cache, und noch immer erscheint die alte Seite. Was passiert hier? Ein Caching-Plugin (WP Rocket, LiteSpeed Cache, W3 Total Cache) hat eine gecachte Version der Seite ausgeliefert; der Server hat die Redirect-Regel nie ausgeführt.

Schritte zum Debugging von Redirects bei WordPress:

• Leeren Sie den Cache des Caching-Plugins (jedes Plugin hat seinen eigenen „Purge All Cache"-Button).
• Deaktivieren Sie das Caching während des Tests (bei WP Rocket ist das der Development Mode).
• Leeren Sie den Browser-Cache (wie oben beschrieben).
• Testen Sie den Redirect erst danach.

Auf einer Testseite lassen wir das Caching-Plugin deaktiviert, bis alle Redirects vollständig fertig sind, und aktivieren es erst nach dem finalen Umschalten von 302 auf 301.

Dieses kurze englischsprachige Video demonstriert den Unterschied zwischen 301 und 302 in der Praxis und erklärt, warum die Wahl des Redirect-Codes Auswirkungen auf SEO hat:

⁉️🤔 Häufig gestellte Fragen

Warum cached der Browser 301, anstatt den Server jedes Mal anzufragen?

Die HTTP-Spezifikation definiert 301 als „die Ressource ist dauerhaft umgezogen". Den Server bei jedem Öffnen der URL anzufragen, widerspräche der Bedeutung von „dauerhaft" und erzeugte unnötige Last. Das Cachen des Redirects spart einen HTTP-Request pro Besucher. Bei Zehntausenden von Zugriffen beschleunigt das die Navigation spürbar. Der Browser cached den Redirect-Sachverhalt selbst (das „von → nach"-Paar), nicht den Seiteninhalt. Das ist ein eigener Cache-Typ namens Redirect-Cache. Chrome speichert ihn im Nutzerprofil, Firefox in der Datei places.sqlite zusammen mit dem Navigationsverlauf. Deshalb setzt das Leeren des Bild- und Skript-Caches Redirects nicht immer zurück; Sie benötigen eine vollständige Leerung oder das Löschen der Site-Daten.

Kann man serverseitig verhindern, dass der Browser 301 cached?

Formal nein. Browser dürfen den Cache-Control: no-store-Header bei permanenten Redirects ignorieren. Die Spezifikation verlangt von Browsern nicht, Cache-Control bei 301/308 zu beachten, da ein permanenter Redirect impliziert, dass sich die Regel nicht ändern wird. Einige Versionen von Chrome und Firefox respektieren Cache-Control bei 301, aber darauf können Sie sich in der Produktion nicht verlassen; das Verhalten ist nicht garantiert und variiert zwischen Versionen. Der einzig zuverlässige Weg, das Browser-Caching eines 301 „rückgängig zu machen", ist, während des Tests von vornherein 302 zu verwenden. Ist ein 301 bereits beim Nutzer gecached, ist der Server machtlos.

Wie unterscheidet sich 302 in der Praxis von 307?

Beides sind temporäre Redirects, und keiner wird vom Browser gecached. Der Unterschied liegt im Umgang mit der HTTP-Methode. Bei 302 darf der Browser einen POST-Request während des Redirects in GET ändern (das geschah historisch so, und viele Browser tun es noch immer). Bei 307 ist die Beibehaltung der Methode garantiert: POST bleibt POST, PUT bleibt PUT. Für WordPress und praktisch jede Website ist der Unterschied vernachlässigbar, da Redirects fast immer GET-Requests betreffen (Seitenaufruf). 307 wird nur benötigt, wenn Formulare, APIs oder Datei-Uploads über eine URL laufen, die Sie temporär umleiten.

Wie kann ich prüfen, welcher Redirect in meinem Browser gecached ist?

Öffnen Sie die DevTools (F12) → Network-Tab und aktivieren Sie „Disable cache" (das ist ZWINGEND, sonst stellt der Browser keine Anfrage an den Server und Sie sehen nicht die aktuelle Antwort). Öffnen Sie dann die alte URL. In der Spalte Status sehen Sie den tatsächlichen Antwortcode des Servers (301, 302 usw.) und den Location-Header mit der Ziel-URL. Ohne „Disable cache" zeigen die DevTools einen 200-Status oder (disk cache), was bedeutet, dass der Browser aus dem Cache bedient hat und der Server nicht angefragt wurde.

Muss man einen 301-Redirect dauerhaft vorhalten?

Google empfiehlt, permanente Redirects nach einem Umzug mindestens ein Jahr lang beizubehalten. In der Praxis kann der Redirect nach 6-12 Monaten entfernt werden, wenn die alte URL nicht mehr beworben wird, keine externen Links darauf verweisen und sie nicht indexiert ist. Verweisen jedoch andere Seiten auf die alte URL oder ist sie in Suchmaschinen-Indizes vorhanden, sollten Sie den Redirect dauerhaft beibehalten. Das Entfernen eines 301 mit einer bei Nutzern gecachten Regel löst das Problem nicht; deren Browser verwenden das gecachte Paar weiter, bis sie den Cache leeren.

Sollte man Angst vor 301-Redirects haben?

Nein, wenn Sie die „302-zuerst"-Regel befolgen. Ein permanenter Redirect ist ein zuverlässiges Werkzeug, um Inhalte umzuziehen, Domains zu wechseln und Duplikate zu bereinigen. Probleme entstehen nur, wenn 301 ohne Test eingerichtet wird.

Merken Sie sich den Kernpunkt: 301 ist ein Versprechen an den Browser, dass Sie „Ihre Meinung nicht ändern werden". Geben Sie dieses Versprechen nicht, bevor Sie sich sicher sind. Zehn Minuten Testen eines 302-Redirects im Inkognito-Modus ersparen Ihnen tagelanges Bereinigen gecachter Fehler bei Ihrer Live-Zielgruppe.