Zmienili Państwo przekierowanie 301, a przeglądarka uparcie wysyła odwiedzających na stary URL? Znajomy ból każdego, kto konfigurował migrację witryny lub zmieniał strukturę linków.

Problem nie leży w serwerze ani w WordPressie. Przeglądarka na stałe zapamiętuje trwałe przekierowanie i nie pyta serwera ponownie, tak działa specyfikacja HTTP. Dopóki pamięć podręczna nie wygaśnie lub użytkownik nie wyczyści jej ręcznie, stara reguła nadal obowiązuje.

Poniżej jasna strategia: jak testować przekierowania bez konsekwencji, dlaczego 302 ratuje nerwy podczas debugowania i co zrobić, jeśli pamięć podręczna utknęła już u żywych odwiedzających.

💡 Szybki przegląd:

• Najpierw zawsze ustawiaj 302 (tymczasowe), testuj i dopiero potem zmieniaj na 301 (trwałe)
• Czyść pamięć podręczną przeglądarki przy każdej zmianie reguł przekierowania
• Dla Chrome: DevTools → Network → Disable cache lub zakładka Application → Clear site data
• Jeśli 301 jest już zapisane w pamięci podręcznej użytkowników, pozostaje tylko czekać lub zmienić docelowy URL

Jak przeglądarka buforuje przekierowanie 301

Gdy serwer odpowiada statusem 301 Moved Permanently, przeglądarka rozumie to dosłownie: „ten URL przeniósł się na zawsze". Zapisuje parę „stary URL → nowy URL" we własnej pamięci podręcznej przekierowań, oddzielnie od pamięci podręcznej stron i obrazów.

Następnym razem, gdy użytkownik (lub Pan/Pani, deweloper) otwiera ten sam adres, przeglądarka w ogóle nie wysyła zapytania do serwera. Od razu podstawia zapisany docelowy URL z pamięci podręcznej. Serwer nie widzi żądania, a Państwo nie widzą aktualnego zachowania.

Specyfikacja HTTP nie określa sztywnego czasu przechowywania takiej pamięci podręcznej. W praktyce Chrome, Firefox i Safari trzymają 301 w pamięci podręcznej aż do jawnego wyczyszczenia. Nagłówek serwera Cache-Control przeglądarka może zignorować właśnie dla 301, ponieważ „na zawsze" oznacza na zawsze.

To zachowanie, nie błąd, a funkcja. Oszczędza round-trip dla uczciwych trwałych migracji (na przykład zmiana domeny). Ale podczas prac deweloperskich zamienia się w pułapkę.

Dlaczego stwarza to problemy podczas konfiguracji

Proszę wyobrazić sobie scenariusz. Konfigurują Państwo migrację starego URL /old-page na /new-page. Wpisują Państwo 301, sprawdzają w przeglądarce, działa. Za godzinę orientują się Państwo, że popełnili błąd: prawidłowy URL to /new-page/v2.

Zmieniają Państwo regułę na serwerze, klikają „odśwież" w przeglądarce. I trafiają na /new-page. Znowu. Ponieważ przeglądarka już zapamiętała pierwszą parę i nie daje serwerowi szansy pokazać nowej reguły.

Myślą Państwo, że przekierowanie nie działa. W rzeczywistości działa, tylko nie to, które właśnie Państwo skonfigurowali.

Na testowej witrynie straciliśmy kiedyś pół godziny na przeglądanie reguł .htaccess, zanim zrozumieliśmy: przeglądarka pokazuje pamięć podręczną. Wyczyszczenie pamięci podręcznej i wszystko od razu zadziałało zgodnie z zamierzeniem.

Gorsza sytuacja jest z odwiedzającymi. Jeśli aktywowali Państwo błędne 301 na produkcyjnej witrynie, każdy, kto wszedł w tych minutach, otrzymał nieprawidłową regułę w pamięci podręcznej swojej przeglądarki. Naprawili Państwo błąd na serwerze po 10 minutach, ale ich przeglądarki będą nadal wysyłać na stary URL przez dni, tygodnie, dopóki pamięć podręczna nie zostanie wyczyszczona.

Proszę zwrócić uwagę: nie mogą Państwo wyczyścić pamięci podręcznej przekierowań po stronie użytkownika. Żadna sztuczka serwerowa nie sięgnie do cudzej przeglądarki.

Strategia 302 → 301: testujemy bez konsekwencji

Reguła, która oszczędza godziny debugowania i zabezpiecza przed błędami na produkcyjnej witrynie:

Zawsze zaczynaj od 302 (tymczasowego) przekierowania. Zmieniaj na 301 dopiero po upewnieniu się, że reguła jest prawidłowa.

Przeglądarka nie buforuje 302 agresywnie, przy każdym żądaniu ponownie pyta serwer. Zmienili Państwo regułę na serwerze, przeglądarka natychmiast podchwyci nowe zachowanie. Żadnego czyszczenia pamięci podręcznej.

Algorytm działań przy każdej zmianie URL:

• Proszę wpisać przekierowanie 302 w .htaccess, konfiguracji Nginx lub poprzez wtyczkę WordPress (na przykład Redirection).
• Proszę otworzyć stary URL w trybie incognito lub z włączoną opcją „Disable cache" w DevTools.
• Proszę upewnić się, że trafili Państwo na właściwą stronę docelową.
• Proszę sprawdzić 2-3 dodatkowe URL-e z tej samej grupy.
• Dopiero gdy wszystko jest przetestowane, proszę zamienić 302 na 301 w regułach.
• Proszę finalnie sprawdzić w zwykłym trybie przeglądarki.

W praktyce to podejście zajmuje dokładnie dwie dodatkowe minuty na każdą grupę przekierowań i całkowicie eliminuje ryzyko „zabuforowanego błędu" dla odwiedzających.

Jeśli pracują Państwo przez wtyczkę Redirection dla WordPressa, domyślnie tworzy ona 301. Proszę przełączyć ręcznie na 302 na liście rozwijanej podczas tworzenia reguły i nie zapomnieć wrócić na 301 po testowaniu.

Jak wyczyścić pamięć podręczną przekierowań lokalnie

Gdy przeglądarka już zapamiętała nieprawidłowe 301 i nie widzą Państwo aktualnego zachowania, oto co pomaga:

Chrome. Proszę otworzyć DevTools (F12), przejść na zakładkę Network i zaznaczyć Disable cache. Lub pełny reset: Application → Clear storage → Clear site data. Najpewniejszy sposób dla konkretnej witryny, chrome://settings/clearBrowserData → Cached images and files.

Firefox. Web Developer Tools → Network → Disable Cache. Dla pełnego wyczyszczenia: History → Clear Recent History → Cache.

Safari. Develop → Disable Caches (menu Develop włącza się w Settings → Advanced).

Tryb incognito, szybki sposób na sprawdzenie świeżego zachowania bez czyszczenia głównej pamięci podręcznej. Przeglądarka używa czystej sesji, gdzie nie ma zapisanych przekierowań.

Ważny niuans: zamknięcie przeglądarki NIE czyści pamięci podręcznej przekierowań 301. W przeciwieństwie do pamięci sesyjnej, pamięć podręczna przekierowań przetrwa restart przeglądarki. Tylko jawne wyczyszczenie lub incognito.

Co robić, jeśli pamięć podręczna utknęła u użytkowników

To najbardziej nieprzyjemny scenariusz: błędne 301 działało na produkcyjnej witrynie przez jakiś czas i część publiczności już nosi je w pamięci podręcznej swoich przeglądarek. Poprawili Państwo regułę serwerową, ale ci użytkownicy nadal trafiają nie tam.

Proszę sprawdzić, co można zrobić:

• Zmienić docelowy URL na nowy. Jeśli stary location prowadził na /page-v1, a trzeba na /page-v2, proszę po prostu zamienić adres w tej samej regule. Przeglądarki, w których zabuforowany jest stary docelowy URL, będą nadal na niego wchodzić (problem). Ale nowi odwiedzający pójdą prawidłowo. To nie rozwiązuje problemu dla tych, którzy już są „zarażeni", ale zatrzymuje rozprzestrzenianie się.

• Użyć innej metody przekierowania. Jeśli 301 jest zabuforowane, przeglądarka nie pyta serwera, ale logika serwerowa wciąż działa dla nowych odwiedzających. Proszę dodać przekierowanie JavaScript na stronę docelową jako dodatkową warstwę na przekierowaniu HTTP dla tych, którzy mimo wszystko trafiają na starą stronę.

• Szczerze przyznać: nie ma bezpośredniego lekarstwa. Nie mogą Państwo sięgnąć do przeglądarki użytkownika. Jeśli pamięć podręczna jest już załadowana, jedynym sposobem na jej zresetowanie jest samodzielne wyczyszczenie pamięci podręcznej przez użytkownika lub przejście przez link w trybie incognito. Na szczęście pamięć podręczna przekierowań nie żyje wiecznie: przeinstalowanie przeglądarki, zmiana urządzenia, aktualizacja systemu operacyjnego z czasem ją zerują.

Z naszego doświadczenia krytyczne błędne 301 staje się tylko w dwóch przypadkach: masowa migracja (setki URL-i) z błędem w regułach lub przekierowanie strony głównej. W obu przypadkach szkoda z zabuforowanego błędu przeważa nad każdą oszczędnością czasu na testowaniu.

301, 302, 307, 308: Co kiedy stosować

Aby się nie mylić, proszę trzymać krótką tabelę kodów przekierowań:

Dla witryny WordPress w przeważającej większości przypadków wystarczy znać różnicę między 301 a 302. Kody 307 i 308, niszowe narzędzia dla przypadków, gdy krytyczne jest zachowanie metody HTTP (na przykład formularz musi pozostać żądaniem POST, a nie zamienić się na GET podczas przekierowania).

Krótko mówiąc: 302, Państwa narzędzie robocze podczas prac deweloperskich. 301, finalna pieczątka „gotowe".

Jeszcze jedna pułapka: WordPress i wtyczki buforujące

Na WordPressie problem buforowania 301 nakłada się na pamięć podręczną serwera i wtyczek. Typowa sytuacja:

Poprawiają Państwo przekierowanie we wtyczce Redirection, klikają „odśwież", nie działa. Czyszczą Państwo pamięć podręczną przeglądarki, wciąż stara strona. Co się dzieje? Wtyczka buforująca (WP Rocket, LiteSpeed Cache, W3 Total Cache) oddała zabuforowaną wersję strony, serwer nawet nie wykonał reguły przekierowania.

Kolejność działań podczas debugowania przekierowań na WordPressie:

• Proszę zresetować pamięć podręczną wtyczki buforującej (każda wtyczka ma swój przycisk „Purge All Cache").
• Proszę wyłączyć buforowanie na czas testowania (w WP Rocket tryb Development Mode).
• Proszę wyczyścić pamięć podręczną przeglądarki (jak opisano wyżej).
• Dopiero po tym proszę sprawdzać przekierowanie.

Na testowej witrynie trzymamy wtyczkę buforującą wyłączoną do pełnej gotowości wszystkich przekierowań i włączamy dopiero po finalnej zamianie 302 na 301.

Krótkie wideo po angielsku poglądowo pokazuje różnicę między 301 a 302 w praktyce i wyjaśnia, dlaczego wybór kodu przekierowania wpływa na SEO:

⁉️🤔 Częste pytania

Dlaczego przeglądarka buforuje 301, a nie pyta serwera przy każdym żądaniu?

Specyfikacja HTTP definiuje 301 jako „zasób przeniósł się na zawsze". Ponowne zapytanie do serwera przy każdym otwarciu URL przeczyłoby sensowi „na zawsze" i tworzyłoby zbędne obciążenie. Buforowanie przekierowania oszczędza jedno żądanie HTTP dla każdego odwiedzającego. W skali dziesiątek tysięcy wizyt to odczuwalnie przyspiesza nawigację. Przeglądarka buforuje sam fakt przekierowania (parę „skąd → dokąd"), a nie zawartość strony. To osobny typ pamięci podręcznej, redirect cache. Chrome przechowuje go w profilu użytkownika, Firefox w pliku places.sqlite razem z historią nawigacji. Właśnie dlatego czyszczenie pamięci podręcznej obrazów i skryptów nie zawsze resetuje przekierowania, potrzebne jest pełne wyczyszczenie lub wyczyszczenie danych witryny.

Czy można na serwerze zabronić przeglądarce buforowania 301?

Formalnie nie. Nagłówek Cache-Control: no-store przeglądarki mogą zignorować dla trwałych przekierowań. Specyfikacja nie wymaga od przeglądarki przestrzegania Cache-Control dla 301/308, trwałe przekierowanie zakłada, że reguła się nie zmieni. Poszczególne wersje Chrome i Firefox respektują Cache-Control dla 301, ale nie można na tym polegać w produkcji, zachowanie nie jest gwarantowane i zmienia się między wersjami. Jedynym niezawodnym sposobem na „anulowanie" buforowania 301 przez przeglądarkę jest od samego początku stosowanie 302 na czas testowania. Jeśli 301 jest już zabuforowane u użytkownika, serwer jest bezsilny.

Czym 302 różni się od 307 w praktyce?

Oba to tymczasowe przekierowania, oba nie są buforowane przez przeglądarkę. Różnica polega na obsłudze metody HTTP. Przy 302 przeglądarka może zmienić żądanie POST na GET podczas przejścia (historycznie tak się utarło i wiele przeglądarek tak robi). Przy 307 metoda jest gwarantowanie zachowywana: POST pozostaje POST, PUT pozostaje PUT. Dla WordPressa i praktycznie każdej witryny różnica jest nieistotna, przekierowania prawie zawsze dotyczą żądań GET (otwarcie strony). 307 jest potrzebne tylko jeśli mają Państwo formularze, API lub przesyłanie plików idące przez URL, który tymczasowo przekierowują Państwo.

Jak sprawdzić, które przekierowanie jest zabuforowane u mnie w przeglądarce?

Proszę otworzyć DevTools (F12) → zakładka Network, zaznaczyć „Disable cache" KONIECZNIE (w przeciwnym razie przeglądarka nie wyśle żądania do serwera i nie zobaczą Państwo aktualnej odpowiedzi). Następnie proszę otworzyć stary URL. W kolumnie Status zobaczą Państwo aktualny kod odpowiedzi z serwera (301, 302 itd.) i nagłówek Location z docelowym URL-em. Bez „Disable cache" DevTools pokaże status 200 lub (disk cache), to przeglądarka oddała pamięć podręczną, serwer nie był odpytywany.

Czy trzeba trzymać przekierowanie 301 wiecznie?

Google zaleca trzymanie trwałych przekierowań co najmniej rok po migracji. W praktyce, jeśli stary URL nie jest już promowany, nie ma zewnętrznych linków i nie jest indeksowany, przekierowanie można zdjąć po 6-12 miesiącach. Ale jeśli na stary URL prowadziły linki z innych witryn lub jest on obecny w indeksie wyszukiwarek, przekierowanie warto zostawić na zawsze. Usunięcie 301 z zabuforowaną u użytkowników regułą nie rozwiąże problemu, ich przeglądarki będą nadal używać zabuforowanej pary, dopóki nie wyczyszczą pamięci podręcznej.

Czy warto bać się przekierowania 301?

Nie, jeśli przestrzega się zasady „najpierw 302". Trwałe przekierowanie to niezawodne narzędzie do migracji treści, zmiany domeny i czyszczenia duplikatów. Problemy zaczynają się tylko wtedy, gdy 301 jest ustawiane bez testowania.

Proszę zapamiętać najważniejsze: 301 to obietnica dana przeglądarce „nie zmienię zdania". Proszę nie składać tej obietnicy, dopóki nie są Państwo pewni. Dziesięć minut na sprawdzenie przekierowania 302 w trybie incognito zaoszczędzi dni na rozplątywaniu zabuforowanych błędów u żywej publiczności.