ADDwNET.pl

Przekierowania 301 i 302: jak nie stracić ruchu przy zmianach na stronie

zarządzanie stroną

przekierowania 301

Zaczyna się niewinnie. Zmieniasz nazwę kategorii, poprawiasz slug artykułu, przenosisz sklep na nową domenę. Kilka kliknięć. A tydzień później przekierowania 301 albo ich brak odbija się w Google Search Console jako lawina błędów 404 i powolny odpływ organicznego ruchu, który budowałeś miesiącami.

Mechanizm jest prosty, a skutki – dalekosiężne. Kod HTTP 301 Moved Permanently to sygnał dla wyszukiwarki: „ten adres nie wróci, przenieś na nowy cały autorytet, wszystkie linki zwrotne, całą historię indeksowania". Kod 302 Found mówi coś zupełnie innego: „zmiana tymczasowa, stary URL zostaje w indeksie, nie ruszaj wartości SEO". Mylenie tych dwóch kodów to jeden z najczęstszych błędów wdrożeniowych – i jeden z najkosztowniejszych.

Ten artykuł przeprowadzi cię przez całą logikę: kiedy stosować 301, kiedy 302, jak skonfigurować przekierowania w .htaccess i w WordPressie, dlaczego łańcuchy przekierowań zabijają crawl budget i jak sprawdzić, czy twoje obecne przekierowania w ogóle działają poprawnie.

Przekierowanie 301 trwale przenosi adres URL i przekazuje praktycznie całą wartość SEO na nowy adres – Google usuwa stary URL z indeksu. Przekierowanie 302 to zmiana tymczasowa – stary adres pozostaje w indeksie, a wartość SEO przy nim. Błędne użycie 302 zamiast 301 może trwale zablokować przeniesienie autorytetu strony.

Kod 301 kontra 302: co naprawdę mówisz Google

Wyobraź sobie dwa scenariusze. W pierwszym przenosisz sklep z domeny stary-sklep.pl na nowy-sklep.pl i ustawiasz 302. Pół roku później Google nadal indeksuje stary adres, nowy nie przejmuje backlinków, a ty tracisz pozycje na frazy, które budowałeś przez dwa lata. W drugim scenariuszu zmieniasz slug produktu na sezon letni – z /buty-letnie-2024 na /buty-letnie-2025 – i ustawiasz 301 na stałe. Tyle że po sezonie wracasz do starego sluga. Google zdążył już zaktualizować indeks i nie wróci do poprzedniej wersji bez nowego przekierowania. Oba błędy wynikają z tego samego: niezrozumienia, do czego każdy z kodów służy.

Różnica nie jest tylko semantyczna. To kwestia tego, co zostaje w cache przeglądarki. Przekierowanie 301 jest cachowane – przeglądarka zapamięta je i przy kolejnych wizytach nie odpyta serwera. Przekierowanie 302 odpytuje serwer przy każdym żądaniu, co przy dużym ruchu generuje dodatkowe obciążenie. Zresztą, z punktu widzenia crawlera Google'a, 302 to zaproszenie do trzymania dwóch wersji adresu w indeksie jednocześnie – co prowadzi do duplikacji treści, czyli jednego z klasycznych problemów technicznych SEO.

Kiedy 301, kiedy 302 – i kiedy inne kody

Wbrew pozorom, decyzja nie zawsze jest oczywista. Poniżej sytuacje, które naprawdę się zdarzają, a nie podręcznikowe przykłady:

  • Trwała zmiana URL artykułu lub kategorii – zawsze 301. Nie ma tu wyjątków. Każdy stary slug powinien mieć bezpośrednie przekierowanie na nowy.
  • Migracja domeny – 301 z mapowaniem 1:1 (stara strona → nowa strona), nie globalne przekierowanie całej domeny na stronę główną (zaskakująco częsty błąd!).
  • Testowanie A/B lub kampania sezonowa – 302, bo wracasz do pierwotnego adresu. Google nie przeniesie wtedy wartości i zachowa stary URL w indeksie.
  • Strona w konserwacji – żaden z nich. Poprawny kod to 503 Service Unavailable z nagłówkiem Retry-After. Użycie 302 w tym miejscu to pułapka.
  • Zmiana protokołu z HTTP na HTTPS – 301 globalny, ale skonfigurowany na poziomie serwera, nie przez plugin WordPress.
  • Usunięcie produktu ze sklepu – 301 na najbliższą kategorię lub podobny produkt, nie na stronę główną. Przekierowanie „do niczego" niszczy wartość backlinków.

Konfiguracja w praktyce: .htaccess, Nginx i WordPress

Trzy środowiska, trzy różne podejścia. Każde ma swoje pułapki.

Na serwerach Apache podstawą jest plik .htaccess. Najprostsze przekierowanie jednej strony wygląda tak: Redirect 301 /stara-strona https://twojadomena.pl/nowa-strona. Dyrektywa Redirect jest wystarczająca dla pojedynczych adresów. Dla masowych przekierowań opartych na wzorcach wchodzi moduł mod_rewrite:

RewriteEngine On oraz RewriteRule ^stary-katalog/(.*)$ /nowy-katalog/$1 [R=301,L] – ta konstrukcja przenosi całą zawartość jednego katalogu do drugiego, zachowując ścieżkę. Flaga [L] zatrzymuje dalsze przetwarzanie reguł. Bez niej Apache przetworzy każdą kolejną regułę, nawet jeśli ta pierwsza już zadziałała.

Na Nginx nie ma pliku .htaccess – konfiguracja trafia bezpośrednio do bloku serwera. Przekierowanie z www na bez-www wygląda następująco: return 301 https://twojadomena.pl$request_uri; w bloku server nasłuchującym na www. Nginx jest szybszy w obsłudze przekierowań niż Apache z mod_rewrite – przetwarzanie odbywa się na etapie parsowania konfiguracji, nie przy każdym żądaniu.

W WordPressie masz trzy ścieżki. Pierwsza to wtyczka Redirection – wystarczy podać stary i nowy URL w panelu administracyjnym, bez dotykania serwera. Druga to plugin Yoast Premium lub RankMath, który obsługuje przekierowania wbudowane w zakładkę SEO. Trzecia, i najszybsza dla serwera, to bezpośredni wpis do .htaccess lub konfiguracji Nginx – bo przekierowanie wtyczkowe musi załadować WordPress, zanim odpowie, co dodaje opóźnienie. Na dużych serwisach z tysiącami przekierowań ta różnica jest mierzalna.

Łańcuchy przekierowań: cichy pożeracz crawl budgetu

Wyobraź sobie adres, który był przekierowywany trzykrotnie: /artykul-stary → /artykul-2022 → /artykul-2023 → /artykul-aktualny. Każde przekierowanie w takim łańcuchu dokłada do czasu ładowania strony około 70 ms. Przy trzech przeskokach to ponad 200 ms opóźnienia, zanim użytkownik zobaczy cokolwiek. A robot Google'a rekomenduje maksymalnie pięć przekierowań w sekwencji, zanim porzuci śledzenie łańcucha.

Ale to nie wszystko. Łańcuch przekierowań osłabia przenoszony autorytet. Każde ogniwo to punkt, w którym część link equity może ulec rozproszeniu. Efekt kumuluje się przy serwisach migrowanych kilka razy – np. zmiana domeny, potem zmiana struktury URL, potem przejście na HTTPS. Trzy operacje, trzy warstwy przekierowań, a finalnie Googlebot dociera do strony z ułamkiem wartości, którą miała mieć.

Rozwiązanie jest jedno: spłaszczanie łańcuchów. Regularny audyt przekierowań (narzędzia: Screaming Frog, Ahrefs Site Audit, Sitebulb) pozwala wykryć wieloetapowe sekwencje i zastąpić je jednym bezpośrednim przekierowaniem. To operacja jednorazowa, ale przynosi długofalowe korzyści. I tu pojawia się pytanie, które warto zadać sobie przy każdej kolejnej restrukturyzacji: czy nie można od razu zbudować właściwej struktury URL, żeby za rok nie robić tego raz jeszcze?

Jak sprawdzić, czy przekierowania działają poprawnie

Kilka konkretnych metod, bez zbędnych opóźnień:

  • curl w terminalu – komenda curl -I https://twojadomena.pl/stary-url zwraca nagłówki HTTP z kodem odpowiedzi. To najpewniejszy sposób na sprawdzenie, co serwer faktycznie odsyła.
  • Screaming Frog Spider – w trybie darmowym (do 500 adresów) identyfikuje łańcuchy i pętle przekierowań, podając każdy przeskok z kodem HTTP.
  • Google Search Console – raport Pokrycia indeksu (Coverage) pokaże adresy zaindeksowane mimo przekierowania 301 (sygnał, że Google jeszcze nie zaktualizował indeksu) lub błędy 404 przy brakujących przekierowaniach.
  • Wtyczka Redirection w WordPress – wbudowany log przekierowań z liczbą trafień – pozwala zidentyfikować, które przekierowania są aktywnie używane, a które można usunąć.
  • Redirect Checker online (np. redirect-checker.org) – szybka weryfikacja łańcucha bez instalowania narzędzi, wystarczający do jednorazowego sprawdzenia.

Warto ustawić cykliczny monitoring – nawet raz w miesiącu – szczególnie na serwisach, gdzie treść jest regularnie aktualizowana lub usuwana. Błąd 404 po usuniętym artykule to stracona wartość backlinku, który mógłby pracować dla aktualnej treści.

Mapa przekierowań przy migracji: jak to zorganizować, żeby nie zwariować

Każda migracja strony – zmiana domeny, zmiana CMS, restrukturyzacja kategorii – zaczyna się od jednego dokumentu: mapy przekierowań. To arkusz z trzema kolumnami: stary URL, nowy URL, status (gotowe / do weryfikacji). Brzmi banalnie. A jednak większość migracji przeprowadzana jest bez tego dokumentu (choć pewnie wielu z nas woli o tym nie wiedzieć), co skutkuje setkami nieobsłużonych adresów i tygodniami naprawczych audytów po fakcie.

Jak zebrać stare URLe? Google Search Console eksportuje listę zaindeksowanych adresów. Screaming Frog lub wget –spider zwrócą pełną mapę aktualnego serwisu z poziomu crawlu. Ahrefs lub Semrush pokażą adresy z backlinkami – te mają priorytet, bo za każdym stoi link z zewnętrznej domeny.

Następnie: każdy stary URL dopasowujesz do nowego odpowiednika. Mapowanie 1:1 zawsze jest lepsze niż globalne przekierowanie na stronę główną. Google to rozróżnia. Przekierowanie /blog/artykul-o-kotach → / to dla algorytmu „soft 404" – przekierowanie, które technicznie działa, ale prowadzi do nieadekwatnej treści. Nie przenosi wartości.

Przy dużych serwisach (powyżej 1000 podstron) warto podzielić mapę na priorytety: adresy z backlinkami, adresy z ruchem organicznym powyżej X wizyt miesięcznie, pozostałe. Pierwsze dwie grupy wdrażaj przed migracją. Reszta może poczekać tydzień, ale nie dłużej – każdy dzień z błędem 404 na adresie z backlinkami to strata, której nie odrobisz jednym przekierowaniem.

Dobra mapa przekierowań to nie dokumentacja – to polisa ubezpieczeniowa. Wystawiasz ją raz, ale jej wartość poznasz dopiero wtedy, gdy Google nie zgubi połowy twojego serwisu w trakcie reindeksacji.