„Warum leitet Chrome mich immer noch auf die alte URL weiter?“ Diese Frage stellen uns Entwickler bei Never Code Alone regelmäßig in Consulting-Gesprächen. Ihr habt eine 301-Weiterleitung geändert, der Server liefert längst das richtige Ziel – aber Chrome ignoriert das hartnäckig. Das Problem: Der Browser cached 301-Redirects dauerhaft, und ein normaler Hard Refresh bringt gar nichts.
Wir arbeiten seit über 15 Jahren spezialisiert auf Softwarequalität, Open Source und Remote Consulting. In dieser Zeit haben wir unzählige Teams dabei unterstützt, genau solche vermeintlich kleinen Probleme zu lösen, die im Entwicklungsalltag massiv Zeit kosten. Der Chrome Redirect Cache ist ein Klassiker – und mit dem richtigen Wissen in wenigen Sekunden erledigt.
1. Warum cached Chrome überhaupt 301-Weiterleitungen?
Das Verhalten ist kein Bug, sondern Absicht. Laut RFC 7231 Section-6.4.2 ist eine 301-Antwort standardmäßig cachebar. Der Browser speichert das Redirect-Ziel lokal, um bei zukünftigen Anfragen keine neue Server-Anfrage stellen zu müssen. Das ist performant und sinnvoll – bis ihr die Weiterleitung ändern wollt.
Das Problem zeigt sich typischerweise in diesen Situationen: Ihr testet Weiterleitungen während der Entwicklung, ihr migriert eine Domain und müsst Redirects anpassen, oder ihr habt versehentlich eine falsche Weiterleitung konfiguriert. In all diesen Fällen bekommt Chrome die Änderung nicht mit, weil er gar nicht mehr beim Server nachfragt.
Der normale Cache-Refresh mit Strg+F5 hilft hier nicht, weil der Redirect bereits vor dem eigentlichen Seitenladen greift. Chrome folgt dem gecachten Redirect, bevor er überhaupt prüft, ob die Zielseite gecached ist.
Tipp aus der Praxis: Wenn ihr bei der Entwicklung regelmäßig mit Redirects arbeitet, empfehlen wir, den Cache in den DevTools dauerhaft zu deaktivieren. Das spart euch wiederholte Frustration.
2. Wie lösche ich den Redirect Cache für eine einzelne URL in Chrome?
Die schnellste Methode nutzt die Chrome DevTools und den versteckten Hard Reload. So geht ihr vor: Öffnet die Chrome Developer Tools mit Strg+Shift+I unter Windows oder Cmd+Option+I auf Mac. Wechselt zum Network-Tab und aktiviert die Checkbox „Disable cache“. Gebt die URL, deren Cache ihr löschen wollt, in die Adressleiste ein und drückt Enter. Klickt jetzt auf den Reload-Button und haltet die Maustaste gedrückt – nach ein bis zwei Sekunden erscheint ein Kontextmenü. Wählt „Empty Cache and Hard Reload“ aus diesem Menü.
Wichtig ist dabei: Die DevTools müssen während des gesamten Vorgangs geöffnet bleiben. Sobald ihr sie schließt, ist das „Empty Cache and Hard Reload“-Feature nicht mehr verfügbar. Nach dem Reload könnt ihr die „Disable cache“-Checkbox wieder deaktivieren, falls ihr das möchtet.
Diese Methode ist ideal, weil sie gezielt nur den Cache für die betroffene URL löscht. Euer restlicher Browser-Cache mit Login-Sessions, CSS-Dateien und anderen Assets bleibt erhalten.
3. Funktioniert der Incognito-Modus als Workaround?
Ja, aber mit einer wichtigen Einschränkung. Der Incognito-Modus von Chrome startet mit einem leeren Cache und löscht alle Daten beim Schließen des Fensters. Wenn ihr also im Incognito-Modus eure URL testet, werdet ihr das korrekte Redirect-Verhalten sehen.
Allerdings löst das euer Problem im normalen Browser-Profil nicht. Der gecachte Redirect bleibt dort bestehen. Für schnelle Tests ist Incognito praktisch, aber wenn ihr im normalen Profil weiterarbeiten wollt, müsst ihr den Cache dort explizit löschen.
Wir nutzen bei Never Code Alone den Incognito-Modus häufig für initiale Tests, gerade wenn wir prüfen wollen, ob ein Problem am lokalen Cache liegt oder serverseitig besteht. Wenn es im Incognito funktioniert und im normalen Browser nicht, wisst ihr sofort: Es ist ein Cache-Problem.
4. Kann ich den Redirect Cache auch über die Konsole löschen?
Es gibt einen cleveren Workaround über die Chrome Fetch API, der in bestimmten Situationen funktioniert. Öffnet dazu die Developer Console mit Strg+Shift+J. Navigiert zu einer beliebigen Seite mit lockerer CORS-Policy, beispielsweise google.com. Führt dann folgenden Befehl in der Konsole aus:
fetch('https://eure-domain.de/betroffene-url', {cache: 'reload'})Ersetzt dabei die URL entsprechend. Diese Methode sendet eine Anfrage mit dem Cache-Mode „reload“, was Chrome zwingt, den Cache für diese URL zu ignorieren und eine frische Antwort vom Server zu holen.
Die Methode ist nicht so zuverlässig wie der DevTools-Ansatz, kann aber in Situationen helfen, wo ihr schnell mehrere URLs invalidieren müsst. Wir haben das in Projekten eingesetzt, wo dutzende Redirects gleichzeitig geändert wurden.
5. Was ist der Unterschied zwischen Browser-Cache und Redirect-Cache?
Der Browser-Cache speichert Assets wie Bilder, CSS-Dateien, JavaScript und HTML-Dokumente. Wenn eine Ressource im Cache liegt und noch gültig ist, lädt Chrome sie von der lokalen Festplatte statt vom Server. Strg+F5 umgeht diesen Cache und erzwingt einen frischen Download.
Der Redirect-Cache funktioniert anders. Hier speichert Chrome nicht die Ressource selbst, sondern die Information, dass eine bestimmte URL auf eine andere URL weiterleitet. Diese Information wird vor dem eigentlichen Request ausgewertet. Der Browser fragt gar nicht mehr beim Server nach, sondern geht direkt zur gecachten Ziel-URL.
Deshalb hilft ein normaler Hard Refresh nicht bei Redirect-Problemen: Der Refresh bezieht sich auf die Ziel-URL, nicht auf die Quell-URL. Um den Redirect-Cache zu invalidieren, braucht ihr die DevTools-Methode oder müsst den gesamten Browser-Cache löschen.
6. Wie lange speichert Chrome 301-Redirects im Cache?
Die genaue Cache-Dauer für 301-Redirects ist nicht fix definiert und hängt von mehreren Faktoren ab. Chrome folgt den Cache-Control-Headern des Servers, sofern vorhanden. Ohne explizite Header kann Chrome den Redirect quasi unbegrenzt cachen, weil ein 301 per Definition eine permanente Weiterleitung signalisiert.
In der Praxis haben wir beobachtet, dass Chrome 301-Redirects oft über Tage oder sogar Wochen cached. Das macht Sinn aus Browser-Perspektive: Warum sollte er eine als permanent markierte Weiterleitung jemals wieder überprüfen?
Wenn ihr als Developer Weiterleitungen testet, empfehlen wir stattdessen 302-Redirects oder 307-Redirects während der Entwicklung. Diese signalisieren eine temporäre Weiterleitung und werden von Browsern weniger aggressiv gecached. Erst wenn die finale Weiterleitung steht, wechselt ihr auf 301.
7. Wie lösche ich den Cache für eine einzelne Domain komplett?
Manchmal reicht es nicht, nur den Redirect-Cache einer URL zu löschen. Wenn ihr den kompletten Cache einer Domain invalidieren wollt, nutzt den Application-Tab in den DevTools. Öffnet die DevTools und wechselt zum Application-Tab. Wählt links „Storage“ und dann „Clear site data“. Dort könnt ihr gezielt auswählen, was gelöscht werden soll: Cache, Cookies, Local Storage, Session Storage, IndexedDB und mehr.
Diese Methode ist gründlicher als der „Empty Cache and Hard Reload“, weil sie auch andere gespeicherte Daten erfasst. Nutzt sie, wenn ihr vermutet, dass nicht nur der Redirect-Cache, sondern auch andere gecachte Daten Probleme verursachen.
Eine Alternative ist der Weg über die Chrome-Einstellungen: Einstellungen, Datenschutz und Sicherheit, Website-Einstellungen, dann „Alle Website-Daten und -berechtigungen anzeigen“. Dort könnt ihr nach einer Domain suchen und deren Daten gezielt löschen.
8. Kann ich den Browser-Cache für Entwicklung komplett deaktivieren?
Ja, und für die Entwicklungsarbeit empfehlen wir das sogar. In den DevTools unter dem Network-Tab gibt es die Option „Disable cache“. Diese deaktiviert den Cache für alle Requests, solange die DevTools geöffnet sind.
Der Haken: Die DevTools müssen geöffnet bleiben. Sobald ihr sie schließt, ist der Cache wieder aktiv. Für dauerhaftes Arbeiten könnt ihr das DevTools-Fenster in ein separates Fenster abdocken und minimieren. So stört es nicht, aber der Cache bleibt deaktiviert.
Alternativ gibt es Chrome-Extensions wie den „Classic Cache Killer“, die den Cache automatisch bei jedem Seitenaufruf löschen. Das simuliert einen deaktivierten Cache, ohne dass die DevTools offen sein müssen. Für Produktivumgebungen solltet ihr diese Extensions allerdings deaktivieren, weil sie das Surferlebnis deutlich verlangsamen.
9. Welche Fehler können bei 301-Redirects auftreten und wie debugge ich sie?
Der häufigste Fehler ist eine Redirect-Schleife, bei der URL A auf URL B weiterleitet und URL B wieder auf URL A. Chrome zeigt dann den Fehler „ERR_TOO_MANY_REDIRECTS“. Wenn ihr diesen Fehler seht, prüft zuerst im Incognito-Modus, ob das Problem serverseitig besteht oder nur am lokalen Cache liegt.
Ein weiterer häufiger Fehler ist ein gemischter Content-Redirect: Die HTTPS-Version einer Seite leitet auf HTTP weiter oder umgekehrt, was zu Sicherheitswarnungen führt. Hier hilft die Überprüfung der .htaccess oder der Server-Konfiguration auf konsistente Protokoll-Verwendung.
Zum Debuggen von Redirects nutzen wir bei Never Code Alone den Network-Tab der DevTools mit aktiviertem „Preserve log“. So seht ihr die komplette Redirect-Kette, auch wenn der Browser schnell durchspringt. Achtet auf den Status-Code: 301 ist permanent, 302 und 307 sind temporär, 308 ist permanent mit Methodenbeibehaltung.
10. Was sollte ich bei Redirect-Problemen im Team-Umfeld beachten?
Wenn mehrere Teammitglieder an einer Migration oder Umstrukturierung arbeiten, treten Cache-Probleme gehäuft auf. Jeder hat einen anderen Cache-Zustand, und was bei einem funktioniert, scheitert beim anderen. Etabliert klare Kommunikation darüber, wann Redirects geändert werden und wie das Team darauf reagieren soll.
Wir empfehlen eine Staging-Umgebung mit deaktiviertem Caching oder sehr kurzen Cache-Zeiten für solche Arbeiten. Damit vermeidet ihr, dass Cache-Probleme überhaupt erst produktionsrelevant werden. Testet Redirects außerdem immer mit Tools wie curl oder wget, die keinen Browser-Cache haben.
Dokumentiert eure Redirect-Strategien und die Methoden zum Cache-Clearing im Team-Wiki. Klingt trivial, spart aber wiederholte Erklärungen und Frustration.
Wenn ihr Unterstützung bei der Optimierung eurer Entwicklungsprozesse braucht, ob bei Cache-Strategien, CI/CD-Pipelines oder Testing-Infrastruktur, meldet euch gerne bei uns. Mit über 15 Jahren Erfahrung in Softwarequalität, Open Source und Remote Consulting haben wir schon viele Teams durch solche Herausforderungen begleitet. Schreibt einfach an roland@nevercodealone.de – wir freuen uns auf den Austausch.
