Przekierowanie 301 w pliku .htaccess potrafi być jedną z tych małych zmian, które robi się „na szybko”, a potem przez kilka godzin gasi pożar: strona nie działa, pojawia się pętla przekierowań, a Google widzi dwa adresy tej samej treści. Jeśli masz to już za sobą, to wiesz, jakie to frustrujące.
W tym poradniku przeprowadzę Cię przez ustawienie 301 w .htaccess tak, żeby było stabilnie, czytelnie i bez typowych wpadek. Zobacz, jak to działa: najpierw uporządkujemy podstawy, potem pokażę sprawdzone reguły dla najczęstszych scenariuszy, a na końcu sposób testowania, który pozwala wychwycić błędy zanim zrobią szkody w SEO.
Dlaczego przekierowanie 301 w .htaccess jest tak ważne dla SEO i użytkownika?
Przekierowanie 301 mówi przeglądarce i robotom wyszukiwarek, że dany adres został trwale przeniesiony pod inny URL. W praktyce pomaga utrzymać porządek w indeksie, przenieść sygnały SEO na nowy adres i nie gubić użytkowników, którzy wchodzą z zakładek, starych linków czy publikacji (w tym artykułów sponsorowanych).
W realnych projektach 301 pojawia się przy wdrożeniu HTTPS, zmianie domeny, porządkowaniu adresów (np. z końcowym ukośnikiem lub bez), migracji bloga na nową strukturę, a nawet przy prostym „przeniosłem ofertę na inny URL, bo lepiej konwertuje”. Jeśli robisz PR i SEO, to wiesz też, że przekierowania są kluczowe przy kontrolowaniu tego, gdzie finalnie prowadzi link z publikacji.
Zanim zaczniesz: 3 rzeczy, które oszczędzają najwięcej nerwów
Najwięcej błędów w .htaccess bierze się nie z samej reguły, tylko z pośpiechu. Dlatego warto zatrzymać się na minutę przy trzech nawykach.
1) Zrób kopię .htaccess
Najbezpieczniej jest skopiować plik .htaccess na dysk i trzymać wersję „ostatnio działającą”. Wtedy, jeśli serwer zwróci błąd 500 albo strona nagle przestanie się ładować, możesz szybko wrócić do poprzedniej konfiguracji.
2) Ustal, czy serwer to Apache i czy działa mod_rewrite
.htaccess dotyczy środowiska Apache (albo kompatybilnych konfiguracji). Jeśli projekt stoi na Nginx, przekierowania robi się inaczej. W Apache kluczowe jest też to, czy działa moduł mod_rewrite, bo większość sensownych 301 opiera się o RewriteEngine i RewriteRule.
3) Wiedz, gdzie „kończy się” .htaccess
Reguły w .htaccess działają kontekstowo. Plik w katalogu głównym wpływa na całą stronę, ale plik w podkatalogu nie ma mocy „nad” katalogiem nadrzędnym. To niby detal, a w praktyce potrafi wytłumaczyć, dlaczego przekierowanie nie łapie lub działa tylko na części adresów.
Gdzie jest plik .htaccess i jak go czytać, żeby nie strzelać na oślep?
Najczęściej .htaccess leży w katalogu głównym strony (tam, gdzie startuje WordPress, panel CMS albo plik index). Bywa ukryty, więc w FTP/menedżerze plików trzeba włączyć widoczność plików ukrytych.
W przekierowaniach 301 w .htaccess liczą się dwie rzeczy: kolejność reguł i warunki. Apache czyta plik od góry do dołu. Jeśli na początku ustawisz szeroką regułę (np. „wszystko przekieruj na X”), to dalsze, bardziej szczegółowe przekierowania mogą już nigdy nie zadziałać.
W praktyce pomaga prosta zasada: najpierw reguły „kanonizujące” (HTTPS, www/non-www, ukośnik), potem reguły dla całych katalogów, a na końcu pojedyncze URL-e.
Najczęstsze przekierowania 301 w .htaccess (sprawdzone przykłady)
Poniższe przykłady są celowo „czytelne” i oparte o typowe scenariusze. Wklejając je, dopasuj domenę i ścieżki. I ważne: jeśli masz już w .htaccess reguły CMS-a, dodawaj przekierowania w miejscu, które nie popsuje ich logiki (często nad sekcją generowaną przez system).
Przekierowanie HTTP → HTTPS (jedna z najczęstszych przyczyn bałaganu w indeksie)
To przekierowanie wymusza HTTPS i domyka sytuację, w której strona działa na dwóch protokołach.
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]Dlaczego to zwykle działa bezpiecznie? Bo nie zakłada konkretnej domeny, tylko bierze bieżący host. Jeśli jednak równolegle robisz też www/non-www, warto połączyć reguły tak, by uniknąć „dwóch skoków” (o tym za chwilę).
Wariant z www → bez www (albo odwrotnie)
To przekierowanie wybiera jeden, spójny wariant domeny. Przykład poniżej przenosi z www na wersję bez www.
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [R=301,L]Jeżeli chcesz iść w drugą stronę (bez www → www), logika jest podobna, tylko docelowy host to „www + domena”. Najważniejsze: trzymaj się jednej konwencji w całym serwisie, bo inaczej łatwo o duplikację adresów.
Połączenie: HTTPS + bez www w jednym przekierowaniu (mniej ryzyka, mniej „skoków”)
To przekierowanie w jednym kroku wymusza HTTPS i usuwa www, co zwykle jest bardziej eleganckie dla użytkownika i robotów.
RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [R=301,L]Tu ważny jest szczegół: użycie [OR] sprawia, że reguła wykona się, gdy którykolwiek warunek jest spełniony. Dzięki temu nie robisz najpierw HTTPS, a potem dopiero www (albo odwrotnie).
Przekierowanie jednej podstrony na inną (np. zmiana URL oferty lub artykułu)
To przekierowanie przenosi konkretny URL bez ruszania reszty serwisu.
Redirect 301 /stara-oferta/ /nowa-oferta/Ten zapis jest prosty, ale ma znaczenie: ścieżki są względem domeny. To dobry wybór, kiedy nie potrzebujesz warunków, wyrażeń regularnych ani skomplikowanej logiki. W praktyce mniej „magii” oznacza mniej błędów.
Przekierowanie całego katalogu (np. /blog/ → /poradniki/)
To przekierowanie przenosi cały dział wraz z podstronami.
RedirectMatch 301 ^/blog/(.*)$ /poradniki/$1Jeśli Twoja nowa struktura ma inną logikę niż stara, czasem lepsze będzie mapowanie URL-i 1:1 (zwłaszcza dla treści o ruchu i linkach). Ale gdy zmiana jest czysto „katalogowa”, taka reguła bywa wystarczająca.
Zmiana domeny (migracja) z zachowaniem ścieżek
To przekierowanie przenosi cały serwis na nową domenę, zachowując ścieżkę i parametry.
RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?stara-domena\.pl$ [NC]
RewriteRule ^(.*)$ https://nowa-domena.pl/$1 [R=301,L]W migracjach domeny szczególnie ważna jest dyscyplina: jedna domena docelowa, jeden wariant protokołu, jedna wersja www/non-www. Mieszanie tego na etapie przekierowań to prosta droga do łańcuchów i pętli.
Jak uniknąć błędów: pętle, łańcuchy i „zjadanie” adresów
Najczęstszy błąd to pętla przekierowań, czyli sytuacja, w której URL A przekierowuje na B, ale B (bezpośrednio lub przez inną regułę) wraca do A albo znowu przekierowuje do B w nieskończoność. Przeglądarka zwykle pokaże komunikat o zbyt wielu przekierowaniach, a roboty wyszukiwarek zaczną to omijać.
Żeby tego uniknąć, pilnuj trzech rzeczy. Po pierwsze, nie dubluj logiki: jeśli masz regułę „wymuś HTTPS” i osobną „usuń www”, to łatwo zrobić dwuskok, a przy gorszym układzie nawet pętlę. Po drugie, zwracaj uwagę na to, czy reguły są zbyt szerokie. Zapis typu „przekieruj wszystko na stronę główną” potrafi wyłączyć cały serwis, jeśli zabraknie warunku wyłączającego stronę docelową. Po trzecie, pilnuj kolejności: reguły szczegółowe zwykle powinny stać wyżej niż reguły globalne.
Warto też znać cichy problem numer dwa: łańcuch przekierowań. To sytuacja, gdy URL A przekierowuje na B, B na C, a dopiero C jest docelowe. Z perspektywy użytkownika to tylko wolniejsze ładowanie, ale z perspektywy SEO to sygnał, że struktura jest „niedomknięta”. Dlatego, jeśli możesz, kieruj od razu na URL finalny.
Jak przetestować przekierowanie 301, zanim wpłynie na SEO?
Najprościej jest testować w dwóch warstwach: w przeglądarce i narzędziem technicznym. W przeglądarce zobaczysz efekt końcowy, ale pamiętaj o cache. Czasem warto użyć okna prywatnego, żeby nie wprowadzać się w błąd.
Technicznie interesują Cię trzy rzeczy: kod odpowiedzi (czy jest 301), adres docelowy (czy jest poprawny) i liczba skoków (czy nie ma łańcucha). Jeśli po wdrożeniu czujesz niepewność, zacznij od kilku kluczowych URL-i: strona główna, przykładowy artykuł, przykładowa kategoria, jeden URL ze „starej” struktury, jeden z parametrem (jeśli występuje). To zwykle wystarcza, żeby wyłapać pętle i zbyt szerokie reguły.
Dobra praktyka na koniec: zapisuj sobie „mapę przekierowań” przy większych zmianach. Nie musi to być dokument na kilkadziesiąt stron. Czasem wystarczy prosta lista stary URL → nowy URL, bo przy kolejnych publikacjach sponsorowanych czy aktualizacjach treści będziesz wiedzieć, co i dlaczego zostało przeniesione.
FAQ: przekierowanie 301 w .htaccess bez wpadek
Czy mogę zrobić przekierowanie 301 w .htaccess na pojedynczą podstronę bez mod_rewrite?
Tak, często wystarczy proste Redirect 301, które nie wymaga budowania reguł w mod_rewrite, o ile przekierowanie dotyczy konkretnej ścieżki.
Co najczęściej powoduje błąd 500 po edycji .htaccess?
Najczęściej jest to literówka, brakujący znak, źle zapisane wyrażenie regularne albo wklejenie reguł w nieodpowiednim miejscu względem konfiguracji CMS-a.
Dlaczego mam pętlę przekierowań po ustawieniu HTTPS i www?
Najczęściej dlatego, że działają dwie reguły, które „odbijają” ruch między wariantami, albo bo SSL jest wymuszany jednocześnie w kilku miejscach (np. .htaccess i panel hostingu).
Czy 301 zawsze jest najlepszym wyborem?
301 jest właściwe, gdy zmiana jest trwała i chcesz, żeby nowy adres był docelowy na stałe, ale w krótkich, tymczasowych sytuacjach stosuje się inne kody.
Podsumowanie: prościej znaczy bezpieczniej
Jeśli chcesz robić przekierowania 301 w .htaccess bez błędów, trzymaj się prostoty, porządku i testowania. Najpierw wybierz docelowy wariant adresu (HTTPS, www/non-www), potem dopiero dopinaj przekierowania treści. A gdy tylko da się to zrobić jednym skokiem, zrobisz przysługę zarówno użytkownikowi, jak i SEO.
Jeśli planujesz większą migrację, porządkowanie struktury URL albo chcesz mieć pewność, że przekierowania nie „rozjadą” efektów publikacji sponsorowanych, skontaktuj się z nami.