Przekierowanie 301 (301 Moved Permanently) to kod odpowiedzi HTTP, który informuje przeglądarki i wyszukiwarki, że strona została przeniesiona na stałe pod nowy adres URL. To najsilniejszy sygnał konsolidacji w SEO – silniejszy niż canonical, silniejszy niż sitemap – i jednocześnie jedyny mechanizm, który fizycznie przenosi użytkownika na nową stronę. Według danych Ahrefs Keywords Explorer, fraza „przekierowanie 301” generuje w Polsce 250 wyszukiwań miesięcznie przy zerowym Keyword Difficulty, a jej Traffic Potential sięga 350 – co oznacza, że strona rankująca na pierwszym miejscu zbiera ruch z kilkunastu powiązanych fraz. Google wyświetla AI Overview i Question features w SERP, co potwierdza, że temat jest traktowany jako answerable query.
Co ważne – i to obalenie jednego z najtrwalszych mitów w SEO – Google oficjalnie potwierdza, że przekierowania 301, 302 i inne redirecty server-side nie powodują utraty PageRank. Gary Illyes z Google ogłosił to w 2016 roku, a dokumentacja Google Search Central dotycząca migracji stron potwierdza to wprost: przekierowania 30x nie tracą PageRank. Mit o „15% utracie” pochodzący z wypowiedzi Matta Cuttsa z 2013 roku jest od lat nieaktualny.
Semgence – agencja SEO z Warszawy – naprawia problemy z przekierowaniami w niemal każdym audycie technicznym. Łańcuchy redirectów, pętle, blanket redirecty na stronę główną – to błędy, które diagnozujemy regularnie i które potrafią kosztować serwis dziesiątki pozycji w Google.
Co to jest przekierowanie 301?
Przekierowanie 301 (301 Moved Permanently) to kod odpowiedzi HTTP, który serwer wysyła przeglądarce lub robotowi wyszukiwarki, gdy odwiedzona strona została trwale przeniesiona pod nowy adres. W momencie, gdy użytkownik klika link prowadzący do starego URL-a, serwer zamiast wyświetlić stronę odpowiada kodem 301 i nagłówkiem Location wskazującym nowy adres. Przeglądarka automatycznie przechodzi na ten nowy adres – cały proces jest niewidoczny dla użytkownika, który widzi po prostu docelową stronę pod nowym URL-em.
Z perspektywy technicznej, komunikacja wygląda tak: przeglądarka wysyła żądanie GET na stary URL, serwer zwraca odpowiedź HTTP/1.1 301 Moved Permanently z nagłówkiem Location: https://twojadomena.pl/nowy-url/, a przeglądarka automatycznie wysyła nowe żądanie GET pod wskazany adres. Całość trwa zazwyczaj 50-150 milisekund – na tyle szybko, że użytkownik tego nie zauważa.
Z punktu widzenia SEO, przekierowanie 301 robi trzy rzeczy jednocześnie. Po pierwsze, przenosi użytkownika na nowy URL, eliminując ryzyko, że trafi na stronę 404. Po drugie, przekazuje sygnały rankingowe – linki, autorytet, historię indeksowania – ze starego URL na nowy. Google potwierdza, że ten transfer odbywa się w 100%, bez utraty wartości. Po trzecie, informuje Google, żeby zaktualizował swój indeks: usunął stary URL i zastąpił go nowym. To właśnie odróżnia 301 od canonical – przekierowanie to dyrektywa (Google MUSI ją wykonać), podczas gdy canonical to wskazówka (Google MOŻE ją zignorować).
Warto rozumieć kontekst historyczny. Protokół HTTP 1.0 zdefiniował kod 301 już w 1996 roku (RFC 1945), ale w SEO stał się on kluczowy dopiero z rozwojem Google w latach 2000., gdy webmasterzy potrzebowali sposobu na przenoszenie stron bez utraty pozycji w wyszukiwarce. Przez lata panowało przekonanie, że 301 „traci” część PageRank – mit, który Google oficjalnie obalił dopiero w 2016 roku.

301 vs 302 vs 308 – jaka jest różnica?
Nie każde przekierowanie jest takie samo, a wybór kodu HTTP ma realne konsekwencje dla indeksowania w Google. Kluczowe rozróżnienie dotyczy trwałości: kody 301 i 308 oznaczają przeniesienie trwałe, a 302 i 307 – tymczasowe.
301 Moved Permanently to najczęściej używany kod w SEO. Mówi Google: „ta strona przeniosła się na stałe, zaktualizuj indeks.” Google usuwa stary URL z indeksu i zastępuje go nowym. Wszystkie sygnały rankingowe (linki, autorytet) są przenoszone na nowy URL. To domyślny wybór przy zmianach struktury URL, migracjach domen i scalaniu stron.
308 Permanent Redirect to nowszy odpowiednik 301 z protokołu HTTP/1.1 (RFC 7538). Funkcjonalnie identyczny z 301 z jedną różnicą: 308 gwarantuje, że metoda HTTP jest zachowana (jeśli użytkownik wysłał POST, przeglądarka wyśle POST na nowy URL). W praktyce SEO różnica nie ma znaczenia – Google traktuje 301 i 308 identycznie. 308 jest przydatny w aplikacjach webowych i API, gdzie zachowanie metody HTTP jest krytyczne.
302 Found to przekierowanie tymczasowe. Mówi Google: „ta strona jest tymczasowo przeniesiona, ale wróci.” Google zachowuje stary URL w indeksie, bo spodziewa się, że strona wróci pod oryginalny adres. To właściwy wybór przy pracach serwisowych, tymczasowym maintenance, A/B testach i sezonowych kampaniach.
Kluczowa pułapka, którą widzimy w audytach: wielu CMS-ów (w tym WordPress z niektórymi wtyczkami) domyślnie ustawia 302 zamiast 301. Efekt: Google przez tygodnie lub miesiące trzyma stary URL w indeksie, bo myśli, że strona jest tymczasowo przeniesiona. John Mueller z Google wyjaśniał na sesjach Office Hours, że gdy 302 utrzymuje się przez dłuższy czas, Google z czasem zaczyna traktować go jak 301 – ale ten proces jest nieprzewidywalny i niekontrolowany. Lepiej od razu użyć właściwego kodu.
Pod kątem PageRank, Google potwierdza, że zarówno 301, jak i 302 przekazują pełną wartość linków. Jak ujął to Gary Illyes z Google w 2016 roku: „30x redirects don’t lose PageRank anymore.” To obalenie jednego z najdłużej żyjących mitów w SEO – przez lata panowało przekonanie, że 301 „traci 15% PageRank.” Ta informacja pochodziła z wypowiedzi Matta Cuttsa z 2013 roku, ale została oficjalnie zdezaktualizowana.

Kiedy stosować przekierowanie 301?
Przekierowanie 301 jest właściwym rozwiązaniem wszędzie tam, gdzie stary URL ma zniknąć na stałe, a jego wartość SEO – linki, autorytet, historia – powinna zostać przeniesiona na nowy adres.
Zmiana struktury URL to najbardziej powszechny scenariusz. Przenosisz /stary-slug/ na /nowy-slug/ po optymalizacji architektury serwisu, zmianie nazw kategorii lub uproszczeniu ścieżek URL. Bez 301 stary URL zwraca błąd 404, a użytkownicy i Googlebot trafiają w ślepą uliczkę. Z 301 – stary URL automatycznie przenosi ruch i sygnały na nowy adres.
Scalenie dwóch stron w jedną to rozwiązanie problemu kanibalizacji słów kluczowych. Gdy dwa artykuły na ten sam temat rywalizują ze sobą w Google, zostawiasz lepszy (silniejszy pod kątem linków, pozycji i ruchu) i z gorszego robisz 301 na lepszy. Efekt: jeden silny URL zamiast dwóch słabych.
Migracja domeny to najbardziej złożony scenariusz, w którym 301 jest absolutnie krytyczny. Przenosisz serwis na nową domenę – 301 z każdego URL-a starej domeny na odpowiadający URL nowej. Google opisuje ten proces szczegółowo w poradniku o migracjach stron z domeną i podkreśla, że mapowanie musi być 1:1: każdy stary URL powinien wskazywać na odpowiadający nowy, nie na stronę główną.
Konsolidacja wariantów domeny to często pomijany, ale ważny przypadek. HTTP → HTTPS, www → non-www, trailing slash vs bez trailing slasha – to technicznie różne URL-e, które mogą generować duplikaty. 301 z każdej niepreferowanej wersji na preferowaną eliminuje problem.
Usunięcie produktu ze sprzedaży to scenariusz typowy dla e-commerce. Produkt wycofany ze sklepu – strona produktu zwraca 404. Jeśli ten URL miał linki zewnętrzne (np. z recenzji, blogów), tracisz ich wartość. Rozwiązanie: 301 na najbardziej zbliżony produkt lub na kategorię, do której należał produkt. Kluczowe: nie na stronę główną – Google traktuje takie blanket redirecty jako soft 404.
Naprawa duplikacji treści w sytuacji, gdy duplikat ma zniknąć na stałe. Choć w wielu przypadkach lepszym rozwiązaniem jest canonical (bo zachowuje obie strony), 301 jest odpowiedni, gdy fizycznie chcesz usunąć jedną wersję URL-a i nie planujesz do niej wracać.
Kiedy NIE stosować przekierowania 301?
Przekierowanie 301 nie jest panaceum i są sytuacje, w których jego użycie to aktywny błąd.
Nie stosuj 301, gdy zmiana jest tymczasowa. Prace serwisowe, tymczasowa niedostępność strony, maintenance window – tu właściwym kodem jest 302. Dlaczego? Ponieważ 301 mówi Google: „ta strona przeniosła się na stałe, usuń stary URL z indeksu.” Jeśli po kilku godzinach strona wraca pod oryginalny adres, Google musi ją ponownie zaindeksować – co może zająć dni lub tygodnie.
Nie stosuj 301, gdy obie wersje strony muszą istnieć. Warianty produktów (kolory, rozmiary), filtry fasetowe w e-commerce, parametry UTM – to scenariusze, w których użytkownik potrzebuje dostępu do obu URL-i. Tu właściwym rozwiązaniem jest canonical, który mówi Google: „indeksuj tylko jedną wersję”, ale zostawia obie dostępne dla użytkownika.
Nie stosuj 301 jako blanket redirect na stronę główną. Google Search Central ostrzega przed tym wprost w dokumentacji o migracjach. Przekierowanie wszystkich starych URL-i na / to z perspektywy Google soft 404 – wyszukiwarka rozumie, że strona główna nie jest odpowiednikiem artykułu o przekierowaniach czy strony produktu. Efekt: utrata wartości SEO z przekierowanych stron. Każdy stary URL powinien wskazywać na najbardziej odpowiadający nowy URL (mapowanie 1:1).
Nie stosuj 301, gdy buduje to zbyt długi łańcuch przekierowań. Jeśli A jest już przekierowane na B, a Ty chcesz przenieść B na C – NIE rób B→C (bo powstanie łańcuch A→B→C). Zamiast tego zaktualizuj A, żeby wskazywał bezpośrednio na C, i dodaj B→C. Łańcuchy spowalniają ładowanie, marnują crawl budget i mogą być ignorowane przez Google po zbyt wielu skokach.
Jak wdrożyć przekierowanie 301?
Implementacja przekierowania 301 zależy od platformy CMS i serwera. Oto najczęstsze metody od najprostszej do najbardziej zaawansowanej.
WordPress z Rank Math SEO to najprostsza metoda, niewymagająca edycji plików serwera. W panelu WordPress przechodzisz do Rank Math → Redirections → Add New. W polu Source URL wpisujesz stary slug (np. /stary-slug/), w Destination URL wpisujesz nowy adres, a w Type wybierasz „301 Moved Permanently”. Rank Math obsługuje też automatyczne przekierowania przy zmianie slug posta – jeśli zmienisz permalink istniejącego wpisu, plugin automatycznie tworzy 301 ze starego URL na nowy. Yoast SEO Premium oferuje identyczną funkcjonalność.
Plik .htaccess (Apache) to metoda działająca na poziomie serwera, szybsza niż rozwiązania wtyczkowe, bo redirect odbywa się zanim WordPress w ogóle się załaduje. Pojedyncze przekierowanie: Redirect 301 /stary-slug/ https://www.twojadomena.pl/nowy-slug/. Dla regex (np. cała kategoria): RedirectMatch 301 ^/stara-kategoria/(.*) https://www.twojadomena.pl/nowa-kategoria/$1. Ta metoda wymaga dostępu FTP lub SSH do serwera.
Konfiguracja Nginx wymaga edycji pliku konfiguracyjnego serwera. Pojedyncze przekierowanie: location = /stary-slug/ { return 301 https://www.twojadomena.pl/nowy-slug/; }. Po edycji wymagany jest restart Nginx. Nginx jest szybszy od Apache w obsłudze przekierowań, bo nie przetwarza pliku .htaccess przy każdym żądaniu.
PHP umożliwia programistyczne przekierowanie: header('HTTP/1.1 301 Moved Permanently'); header('Location: https://www.twojadomena.pl/nowy-slug/'); exit();. Kluczowe: exit() musi być wywołane po header(), żeby przerwać wykonanie skryptu.
Jak podkreśla dokumentacja Google Search Central o przekierowaniach: przekierowanie server-side jest najlepszym sposobem, żeby zarówno Google, jak i użytkownicy zostali prawidłowo skierowani na właściwą stronę.
Przekierowanie 301 a SEO – co musisz wiedzieć
Temat przekierowań 301 jest otoczony mitami, które przez lata kształtowały błędne decyzje techniczne. Warto oddzielić fakty potwierdzone przez Google od plotek forumowych.
Przekierowania NIE tracą PageRank. To najważniejszy fakt, który warto powtarzać, bo mit „15% utraty” wciąż żyje na forach i w starszych poradnikach. Google oficjalnie potwierdza w dokumentacji o migracjach stron: „301, 302, and other server side redirects do not cause a loss in PageRank.” Gary Illyes z Google ogłosił to w 2016 roku, a John Mueller wielokrotnie potwierdzał na sesjach Office Hours. Oznacza to, że prawidłowo wdrożone przekierowanie 301 przekazuje 100% wartości linków zewnętrznych ze starego URL na nowy.
Google traktuje 301 i 302 podobnie pod kątem PageRank, ale inaczej pod kątem indeksowania. Oba kody przekazują pełną wartość linków. Różnica dotyczy tego, który URL Google zachowa w indeksie: przy 301 Google indeksuje nowy URL (bo zmiana jest trwała), przy 302 zachowuje stary (bo oczekuje, że strona wróci). W praktyce, jak wyjaśniał John Mueller, gdy 302 utrzymuje się przez wiele miesięcy, Google z czasem zaczyna traktować go jak 301 – ale ten automatyczny proces jest niekontrolowany i może powodować opóźnienia w aktualizacji indeksu.
Łańcuchy przekierowań spowalniają crawlowanie i ładowanie stron. Googlebot podąża za łańcuchami, ale każdy skok to dodatkowe żądanie HTTP, które dodaje 100-300 milisekund latencji. Googlebot podąża za maksymalnie około 10 skokami, ale John Mueller rekomenduje utrzymywanie łańcuchów na 1 skoku (A→B bezpośrednio). Każdy dodatkowy skok to marnowanie crawl budgetu – zasobu, który dla dużych serwisów (powyżej 100 000 stron) jest realnym ograniczeniem.
Nowy wymiar w 2026: AI crawlery mają MNIEJSZY budżet crawl. Analiza Cloudflare z 2025 roku wykazała, że boty AI (GPTBot, ClaudeBot, PerplexityBot) stanowią 4,2% wszystkich żądań HTML, a GPTBot zwiększył swój udział z 5% do 30% wśród crawlerów AI w ciągu jednego roku. Te boty operują pod znacznie ostrzejszymi limitami niż Googlebot: nie renderują JavaScript (więc JS redirect jest dla nich niewidoczny), mają mniejszy budżet crawl i mniejszą tolerancję na łańcuchy. Jak opisuje analiza GetPassionfruit.com o redirect chains i AI crawlerach, każdy dodatkowy skok w łańcuchu zwiększa prawdopodobieństwo, że AI crawler przerwie żądanie zanim dotrze do treści.
Utrzymuj 301 tak długo, jak to możliwe – idealnie permanentnie. Choć Google przetworzy redirect w ciągu kilku tygodni, linki z zewnętrznych stron mogą wskazywać na stary URL latami. Usunięcie 301 za wcześnie oznacza, że te linki trafią na stronę 404, a ich wartość SEO zostanie bezpowrotnie utracona.
Najczęstsze błędy z przekierowaniami 301
Na podstawie audytów technicznych prowadzonych przez Semgence, problemy z przekierowaniami pojawiają się w niemal każdym serwisie powyżej 500 stron. Najczęściej wynikają z braku dokumentacji zmian URL i narastania „długu technicznego” w pliku .htaccess lub wtyczkach SEO.
Łańcuchy przekierowań (redirect chains) to zdecydowanie najczęstszy problem. Powstają, gdy URL A został przekierowany na B, potem B na C, a C na D – i nikt nie zaktualizował oryginalnego przekierowania A. Efekt: użytkownik i Googlebot muszą przejść przez 3 skoki zamiast 1. Każdy skok dodaje latencję (100-300ms) i pogarsza Core Web Vitals, szczególnie Time to First Byte (TTFB) i Largest Contentful Paint (LCP). W Screaming Frog raport „Redirect Chains” identyfikuje te problemy automatycznie – wystarczy wyeksportować listę, skrócić łańcuchy do A→D i zaktualizować reguły.
Pętle przekierowań (redirect loops) to krytyczny błąd, który sprawia, że strona jest całkowicie niedostępna. A→B→A tworzy nieskończoną pętlę – przeglądarka wyświetla komunikat „ERR_TOO_MANY_REDIRECTS” i użytkownik nie widzi żadnej treści. Najczęstsza przyczyna: sprzeczne reguły w .htaccess (np. jedna reguła przekierowuje z non-www na www, a druga z www na non-www) lub konflikty między wtyczką SEO (Rank Math Redirections) a ręcznymi regułami w .htaccess.
Blanket redirect na stronę główną to błąd migracyjny numer jeden. Zamiast mapować każdy stary URL na odpowiedni nowy (1:1), ktoś ustawia jedną regułę: „przekieruj wszystko na /”. Google traktuje to jako soft 404 – rozumie, że strona główna nie jest odpowiednikiem artykułu czy produktu. Efekt: utrata wartości SEO z wszystkich przekierowanych stron.
302 zamiast 301 przy trwałej zmianie to subtelny błąd, który opóźnia indeksowanie. CMS lub wtyczka domyślnie ustawia 302, a nikt nie sprawdza kodu odpowiedzi. Google trzyma stary URL w indeksie miesiącami, bo myśli, że strona wróci pod oryginalny adres. Nowy URL nie pojawia się w SERP.
Redirect na stronę z noindex to sprzeczny sygnał. 301 mówi Google: „tu jest treść, zaindeksuj nowy URL.” Noindex na nowym URL mówi: „nie indeksuj.” Google nie wie, co robić – najczęściej nie indeksuje nowego URL-a, a sygnały ze starego wiszą w próżni. To częsty problem przy migracjach CMS, gdy nowe strony mają domyślnie ustawiony noindex.
Brak 301 po usunięciu produktu to problem specyficzny dla e-commerce. Produkt wycofany ze sprzedaży → strona zwraca 404 → wszystkie linki zewnętrzne prowadzące do tego produktu tracą wartość. Rozwiązanie: 301 na najbardziej zbliżony produkt lub na kategorię. Kluczowe: mapowanie 1:1, nie blanket redirect na stronę główną.

Jak sprawdzić, czy 301 działa poprawnie?
Po wdrożeniu przekierowania weryfikacja jest obowiązkowa – to jeden z elementów, który sprawdzamy w każdym audycie technicznym Semgence.
Przeglądarka to najprostszy test. Wchodzisz na stary URL i sprawdzasz, czy automatycznie trafiasz na nowy. Pasek adresu powinien wyświetlać nowy URL. Jeśli widzisz stary URL lub stronę 404 – redirect nie działa. Uwaga: przeglądarki cachują przekierowania – testuj w trybie incognito lub po wyczyszczeniu cache.
Komenda curl w terminalu to precyzyjne narzędzie. Polecenie curl -I https://twojadomena.pl/stary-slug/ zwraca nagłówki HTTP bez pobierania treści strony. Prawidłowa odpowiedź powinna zawierać HTTP/1.1 301 Moved Permanently i nagłówek Location: https://twojadomena.pl/nowy-slug/. Jeśli widzisz 302 zamiast 301 – masz błędny kod. Jeśli Location wskazuje na inny URL niż oczekujesz – masz błędne mapowanie.
Rozszerzenia Chrome takie jak Redirect Path lub Link Redirect Trace wizualnie pokazują pełny łańcuch przekierowań i kody odpowiedzi na każdym kroku. To najwygodniejsze narzędzie do szybkiego sprawdzenia pojedynczych URL-i bez konieczności otwierania terminala.
Google Search Console daje obraz z perspektywy Google. URL Inspection Tool pozwala wpisać stary URL i zobaczyć, jak Google go przetworzyło. Status „Page is not in Google: Page with redirect” potwierdza, że Google prawidłowo rozpoznaje przekierowanie. Raport „Strony” (Pages → Indexing) wykrywa też łańcuchy i pętle na poziomie całego serwisu.
Screaming Frog SEO Spider to narzędzie do masowej weryfikacji. Crawl domeny → filtr „3xx” pokazuje wszystkie przekierowania na stronie. Raport „Redirect Chains” identyfikuje łańcuchy, a „Redirect Loops” wykrywa pętle. Dla dużych serwisów (10 000+ stron) Screaming Frog jest niezastąpiony – ręczne sprawdzanie każdego URL-a byłoby niepraktyczne.
Więcej o narzędziach i procesie audytu technicznego opisujemy w checkliście technicznego SEO oraz w naszym ebooku „Co powinien zawierać audyt SEO”.
Najczęściej zadawane pytania o przekierowanie 301
Czy przekierowanie 301 powoduje utratę PageRank?
Nie. Google oficjalnie potwierdza, że przekierowania 301, 302 i inne server-side redirects nie powodują utraty PageRank. Gary Illyes z Google ogłosił to w 2016 roku, a dokumentacja Google Search Central dotycząca migracji stron potwierdza to wprost. Mit o „15% utracie” pochodzący z wypowiedzi Matta Cuttsa z 2013 roku jest od lat nieaktualny. Warunek: przekierowanie musi być prawidłowo wdrożone (stary URL → odpowiadający nowy URL, nie blanket redirect na stronę główną).
Jaka jest różnica między 301 a 302?
301 to przekierowanie trwałe – Google usuwa stary URL z indeksu i zastępuje go nowym. 302 to przekierowanie tymczasowe – Google zachowuje stary URL w indeksie, bo spodziewa się, że strona wróci. Oba przekazują PageRank (bez utraty), ale różnią się sygnałem trwałości. Praktyczna zasada: 301 dla zmian permanentnych (migracja, zmiana URL), 302 dla tymczasowych (maintenance, A/B testy).
Jak długo trzeba utrzymywać przekierowanie 301?
Najlepiej permanentnie – bez daty wygaśnięcia. Choć Google przetworzy redirect w ciągu kilku tygodni, linki z zewnętrznych stron mogą wskazywać na stary URL latami. Usunięcie 301 za wcześnie oznacza, że te linki trafią na stronę 404 i ich wartość SEO zostanie bezpowrotnie utracona. W praktyce wielu SEO-wców rekomenduje minimum 1 rok, ale nie ma powodu, by usuwać działające przekierowania.
Czy mogę przekierować wiele stron na jedną?
Tak, ale ostrożnie. Google zaleca mapowanie 1:1 – każdy stary URL powinien wskazywać na najbardziej odpowiadający nowy URL. Przekierowanie wielu niepowiązanych stron na stronę główną (blanket redirect) jest traktowane przez Google jako soft 404 i nie przekazuje wartości SEO. Jeśli scalasz 3 artykuły na ten sam temat w 1 – 301 z dwóch słabszych na najsilniejszy jest prawidłowym podejściem.
Ile skoków w łańcuchu przekierowań toleruje Google?
Googlebot podąża za maksymalnie około 10 skokami. John Mueller rekomendował optymalnie 5 skoków jako maksimum na sesję crawl, ale najlepsza praktyka to 1 skok (A→B bezpośrednio). Dłuższe łańcuchy spowalniają ładowanie (każdy skok = 100-300ms), marnują crawl budget i pogarszają Core Web Vitals. AI crawlery (GPTBot, ClaudeBot) mają jeszcze mniejszą tolerancję na łańcuchy.
Kiedy użyć canonical zamiast 301?
Canonical stosuj, gdy obie wersje strony muszą istnieć i być dostępne dla użytkownika (warianty produktów, filtry, parametry UTM). 301 stosuj, gdy stary URL ma zniknąć na stałe i użytkownik nie powinien mieć do niego dostępu. Canonical to wskazówka dla Google (może ją zignorować), 301 to dyrektywa (Google musi ją wykonać).
Co to jest przekierowanie 301?
Przekierowanie 301 to stałe przekierowanie z jednego URL na inny. Informuje wyszukiwarkę, że strona na stałe przeniosła się pod nowy adres. Google przenosi większość sygnałów rankingowych (linki, autorytet) na nowy URL. Stosuje się je przy zmianie domeny, struktury URL lub usuwaniu stron.
Kiedy stosować 301, a kiedy 302?
301 (permanentne) stosuj gdy strona przeniosła się na stałe – zmiana domeny, nowy slug, usunięcie strony. 302 (tymczasowe) stosuj gdy zmiana jest chwilowa – np. promocja, testy A/B, tymczasowa strona zastępcza. Google traktuje 302 inaczej – nie przenosi pełnego link equity.
Jak wdrożyć przekierowanie 301?
W WordPress: użyj wtyczki Rank Math (Redirections) lub Redirection. Na serwerze: dodaj regułę w pliku .htaccess (Apache) lub nginx.conf (Nginx). W Cloudflare: Page Rules. Zawsze testuj po wdrożeniu – sprawdź czy przekierowanie działa poprawnie i nie tworzy łańcuchów (301→301→301).

