Przekierowanie 301

TL;DR — Przekierowanie 301 na stałe wysyła każdą osobę (lub bota), który odwiedza stary adres URL, do nowego. To właściwe narzędzie, gdy strona przenosi się na dobre — do nowej domeny, pod nowy adres URL, z HTTP na HTTPS albo gdy łączysz dwie strony w jedną. Skonfiguruj je na serwerze, skieruj każdy stary adres URL do jego rzeczywistego zamiennika (nie tylko do strony głównej) i pozostaw regułę aktywną. Google twierdzi, że 301 nie powoduje utraty wartości rankingowej, więc nie ma się czego obawiać.

Czym jest przekierowanie 301

Gdy przeglądarka lub wyszukiwarka prosi o stronę, serwer odpowiada trzycyfrowym kodem stanu HTTP. 200 oznacza „oto strona”. 404 oznacza „nie znaleziono”. 301 oznacza „Moved Permanently” — ten adres URL ma nowy dom, więc przejdź tam zamiast niego.

Przekierowanie 301 to zatem komunikat serwera dla wszystkich: rzecz, o którą prosisz, znajduje się teraz pod innym adresem i jest to zmiana stała. Odwiedzający są automatycznie wysyłani na nową stronę, a wyszukiwarki aktualizują swoje rekordy, aby wskazywać nowy adres URL.

Kiedy go użyć

Sięgnij po 301, gdy adres strony zmienia się na dobre:

• Zmieniasz adres URL — zmieniasz nazwę strony, przebudowujesz witrynę albo porządkujesz nieczytelny adres URL.
• Przenosisz się do nowej domeny — w ramach rebrandingu lub migracji witryny.
• Przechodzisz na HTTPS — każdy adres http:// powinien przekierowywać przez 301 na odpowiadający mu adres https://.
• Łączysz strony — dwa podobne artykuły stają się jednym; przekieruj stare adresy do strony, która pozostaje.
• Wycofujesz stronę z wyraźnym zamiennikiem — wyślij odwiedzających do najbliższego odpowiednika, a nie w ślepą uliczkę.

Własna rada Google brzmi: “If you need to change the URL of a page as it is shown in search engine results, we recommend that you use a permanent server-side redirect whenever possible.” (tłumaczenie) „Jeśli musisz zmienić adres URL strony wyświetlany w wynikach wyszukiwania, Google zaleca, aby w miarę możliwości użyć stałego przekierowania po stronie serwera.”

Jedna liczba, którą należy zignorować

Usłyszysz, że 301 „traci 10–15% mocy linków”. To stary mit. Google mówi wprost: “301 and other permanent redirects don’t cause a loss in PageRank.” (tłumaczenie) „301 i inne stałe przekierowania nie powodują utraty PageRank.” Nie unikaj więc przekierowania strony z obawy przed „wyciekiem” wartości — prawidłowy 301 przekazuje stronie docelowej sygnały, które zdobył stary adres URL.

(Zobaczysz też pewnie brzmiące twierdzenia, że 301 „przekazuje 90–99% wartości linków”. Je również zignoruj — Google nie publikuje takiego odsetka, a liczba jest zmyślona.)

Trzy rzeczy, które trzeba zrobić poprawnie

1. Skieruj każdy stary adres URL do jego rzeczywistego zamiennika — nie do strony głównej. Jeśli zrzucisz każdą wycofaną stronę na stronę główną, Google może potraktować takie adresy jako błędy („soft 404”) i nie przekazać wartości. Dopasuj stare i nowe adresy jeden do jednego.
2. Użyj prawdziwego 301, nie jego imitacji. Przekierowanie wykonane wyłącznie w JavaScript albo link „kliknij tutaj, jeśli nie nastąpiło przekierowanie” nie jest tym samym — Google może go nawet nie zobaczyć. Zrób to na serwerze.
3. Pozostaw je aktywne. Google zaleca pozostawienie przekierowań zwykle co najmniej przez rok, aby wszystko miało czas się przenieść. Szczerze mówiąc, jeśli możesz, zachowaj je na zawsze.

A co z 302?

302 to wersja tymczasowa — „ta strona została przeniesiona na razie, ale oryginalna nadal jest właściwa”. Jeśli użyjesz 302, gdy chodziło o 301, Google może pozostawić stary adres URL w wynikach zamiast nowego. Gdy przeniesienie jest stałe, użyj 301. (Osobne porównanie 301 i 302 omawia ten temat dokładniej.)

Chcesz poznać konfiguracje serwera, szczegóły dotyczące czasu, zasady łańcuchów przekierowań i sposób wykrywania „fałszywego” 301, który po cichu nie działa? Przejdź do karty Advanced.

TL;DR — 301 (HTTP „301 Moved Permanently”) to odpowiedź po stronie serwera, która trwale przenosi adres URL i jest najsilniejszym sygnałem konsolidowania rankingu na stronie docelowej. Google wyraźnie mówi, że stałe przekierowania nie powodują utraty PageRank — zasada „utraty około 15% na każdym przeskoku” jest nieaktualna i nie istnieje żadna opublikowana wartość procentowa przekazywanej wartości, więc nie należy jej wymyślać. Wdrażaj je na serwerze (Apache, nginx, kod aplikacji) albo na brzegu sieci (Cloudflare), a nie przez JavaScript lub opóźnione odświeżenie meta. Przekierowuj stare adresy URL do odpowiednich zamienników 1:1 — nie wszystko na stronę główną, bo Google może przeklasyfikować takie adresy jako soft 404. Utrzymuj krótkie łańcuchy (Google śledzi do 10 przeskoków, ale zaleca mniej niż około 5; Mueller mówił o około 5 przy jednym crawlu). Na serwerze działa natychmiast; pełna konsolidacja indeksu i sygnałów zajmuje tygodnie do zwykle co najmniej roku.

Czym właściwie jest 301

301 to kod stanu HTTP — „301 Moved Permanently” — zwracany przez serwer (lub brzeg CDN) w nagłówkach odpowiedzi, przed jakimkolwiek ciałem strony. To najważniejsza część: prawdziwy 301 działa na poziomie protokołu, w odpowiedzi na żądanie. Nie jest funkcją wtyczki, tagiem <meta> ani fragmentem JavaScript — to obejścia na sytuacje, w których nie możesz wykonać przekierowania na serwerze, i zachowują się inaczej (o czym niżej).

Google ujmuje definicję prosto: “The 301 and 308 status codes mean that a page has permanently moved to a new location.” (tłumaczenie) „Kody stanu 301 i 308 oznaczają, że strona została trwale przeniesiona do nowej lokalizacji.” (308 to nowszy kod stałego przekierowania, który zachowuje także metodę żądania; z punktu widzenia SEO Google traktuje 301 i 308 tak samo — “use HTTP permanent redirects if possible, such as 301 and 308.” (tłumaczenie) „jeśli to możliwe, używaj stałych przekierowań HTTP, takich jak 301 i 308.”)

Przed wdrożeniem warto znać kilka szczegółów protokołu: odpowiedź 301 jest domyślnie heurystycznie zapisywana w pamięci podręcznej, więc przeglądarka lub pośredni cache może ją przechować — właśnie dlatego „naprawione” przekierowanie może nadal wysyłać testerów do starego celu, dopóki pamięć podręczna się nie wyczyści. Ponieważ 301 istnieje od czasów HTTP/1.0, klient użytkownika może zmienić żądanie POST na GET, gdy za nim podąża — nie zakładaj więc, że 301 zachowuje pierwotną metodę formularza; jeśli ma to znaczenie, użyj 308. Sam nagłówek Location musi zawierać jedynie odwołanie URI (technicznie może być względne), choć w praktyce absolutny adres URL usuwa niejednoznaczność.

Jak Google przetwarza 301 (kanonizacja i indeksowanie)

Stałe przekierowanie jest jednym z najsilniejszych sygnałów kanonizacji, jakie ma Google. Gdy Googlebot podąża za 301, potok indeksowania używa przekierowania jako sygnału, że cel przekierowania powinien być kanonicznym adresem URL. Google zachowuje zapis obu końców: “When you redirect a URL, Google keeps track of both the redirect source (the old URL) and the redirect target (the new URL). One of the URLs will be the canonical… The other URL becomes an alternate name of the canonical URL.” (tłumaczenie) „Po przekierowaniu adresu URL Google śledzi zarówno źródło przekierowania (stary adres URL), jak i jego cel (nowy adres URL). Jeden z adresów URL będzie kanoniczny, a drugi stanie się alternatywną nazwą kanonicznego adresu URL.”

Dlatego po przeniesieniu przez pewien czas możesz nadal widzieć w wynikach stary adres URL — Google przechowuje go jako „alternatywną nazwę”. Google uspokaja: “it’s very likely that Google will continue to occasionally show the old URLs in the results, even though the new URLs are already indexed. This is normal… the alternate names will fade away without you doing anything.” (tłumaczenie) „jest bardzo prawdopodobne, że Google nadal będzie od czasu do czasu wyświetlać stare adresy URL w wynikach, mimo że nowe są już zindeksowane. To normalne — alternatywne nazwy z czasem znikną bez żadnego działania z Twojej strony.”

Przekierowanie ma większą wagę niż słabsze sygnały kanonizacji. Gary Illyes ujął tę hierarchię dosadnie — przekierowanie “should be much higher weight… than whether the page is on an http URL or https.” (tłumaczenie) „powinno mieć znacznie większą wagę niż to, czy strona znajduje się pod adresem http czy https.” Dlatego pojedynczy 301 może po cichu nadpisać tag kanoniczny lub preferencję HTTPS wskazującą w inną stronę. (Pełne omówienie znajduje się w artykule o kanonizacji.)

Warto precyzyjnie rozumieć, czego ten sygnał nie obiecuje: 301 to silny sygnał celu kanonicznego, a nie gwarancja. Wskazuje Google, który adres URL powinien być kanoniczny — nie gwarantuje, że ten adres zostanie zindeksowany, będzie się pozycjonował, przyniesie ruch ani że każdy inny sygnał (linki, jakość treści, autorytet witryny) przeniesie się automatycznie. Traktuj „wybór kanonicznego adresu” oraz „wyniki indeksowania, rankingu i ruchu” jako osobne pytania; 301 odpowiada bezpośrednio tylko na pierwsze.

Mit PageRank — trzeba to ująć dokładnie

To najbardziej zniekształcany fakt dotyczący 301, więc przedstawmy go precyzyjnie.

Dokładne stwierdzenie Google: “301 and other permanent redirects don’t cause a loss in PageRank.” (tłumaczenie) „301 i inne stałe przekierowania nie powodują utraty PageRank.” To wszystko. Nie „zachowujesz 85%”, nie „tracisz 10–15% na każdym przeskoku”. Żadnej straty.

Zasada „utraty około 15% na każdym przeskoku” wywodzi się ze starych, sprzed 2016 roku wypowiedzi o tłumieniu PageRank przy przekierowaniach (powszechnie przypisywanych Mattowi Cuttsowi). Google publicznie odwróciło to stanowisko około 2016 roku — jak wówczas informowano, Google przestało stosować rozcieńczanie PageRank przy przekierowaniach 30x, a strona docelowa otrzymuje autorytet.

Wniosek, który prowadzi ludzi do błędów w przeciwnym kierunku: nie twierdź, że 301 „przekazuje 90–99% wartości linków”. Google nie publikuje takiej liczby. „Nie powoduje utraty PageRank” to stwierdzenie kierunkowe, a nie procent — każdy konkretny odsetek, który zobaczysz, jest folklorem, a nie czymś potwierdzonym przez Google. Cytuj sformułowanie o „braku utraty”; nigdy nie wymyślaj wartości procentowej.

Dodam własną uwagę ostrzegawczą. Sam sprawdziłem twierdzenie, że „sygnały utrzymują się po roku”, usuwając przekierowania 301 z czterech dobrze podlinkowanych artykułów Ahrefs i obserwując wynik (Czy można usunąć przekierowania 301 po roku? Sprawdziliśmy to). Liczba domen odsyłających wyraźnie spadła po usunięciu przekierowań, a ruch organiczny był mieszany — jeden artykuł zyskał, jeden stracił, a dwa pozostały mniej więcej bez zmian; przy jednym pozornym „spadku” okazało się, że zaczął się jeszcze przed usunięciem. Mój uczciwy wniosek brzmi: “I’m not willing to conclusively say that permanent redirects pass value even after one year, but what Gary said seems to mostly hold true.” (tłumaczenie) „Nie jestem gotów kategorycznie stwierdzić, że stałe przekierowania przekazują wartość nawet po roku, ale to, co powiedział Gary, wydaje się w większości prawdziwe.” Mała próba, więc zachowuję ostrożność — praktyczny wniosek jest jednak banalny: nie usuwaj przekierowań.

Czas — trzy różne zegary

„Jak długo trzeba czekać, aż 301 zacznie działać?” zależy od tego, o którym zegarze mówisz:

• Serwer: natychmiast. W chwili, gdy reguła działa, każde żądanie otrzymuje 301, a użytkownik trafia pod nowy adres URL. Nie trzeba czekać.
• Indeks: dni lub tygodnie. Google musi ponownie pobrać stary adres URL, zobaczyć przekierowanie i przetworzyć cel. Własne ujęcie Google brzmi: “a small to medium-sized website can take a few weeks for most pages to move, and larger sites take longer,” (tłumaczenie) „mała lub średnia witryna może potrzebować kilku tygodni, aby większość stron się przeniosła, a większe witryny potrzebują więcej czasu” oraz “visibility of your content in Search may fluctuate temporarily during the move. This is normal.” (tłumaczenie) „widoczność treści w wyszukiwarce może tymczasowo zmieniać się podczas przenosin. To normalne.”
• Pełna konsolidacja sygnałów: zwykle co najmniej rok. Google: “Keep the redirects for as long as possible, generally at least 1 year. This timeframe allows Google to transfer all signals to the new URLs… From users’ perspective, consider keeping redirects indefinitely.” (tłumaczenie) „Utrzymuj przekierowania tak długo, jak to możliwe, zwykle co najmniej rok. Ten czas pozwala Google przenieść wszystkie sygnały na nowe adresy URL; z perspektywy użytkowników rozważ utrzymywanie przekierowań bezterminowo.” To ta sama roczna wartość, którą podał Illyes, mówiąc, że pełne przejście sygnałów ze źródła do celu zajmuje około roku.

Praktyczna zasada: utrzymuj przekierowania 301 co najmniej przez rok, a najlepiej po prostu na zawsze, jeśli adresy URL nic Cię nie kosztują.

Wdrażanie 301

Zrób to możliwie blisko serwera. Poniższe cztery ścieżki obejmują prawie wszystkich. (To przykłady; dostosuj ścieżki i nazwy hostów, a karta Scripts zawiera wersje do skopiowania oraz instrukcje testowania.)

Przed edycją wykonaj kopię istniejącej konfiguracji .htaccess lub nginx — błędna reguła może wyłączyć całą witrynę, a nie tylko jeden przekierowywany adres URL.

Apache (.htaccess)

Dla pojedynczego adresu URL z użyciem mod_alias:

Redirect permanent "/old-page" "https://example.com/new-page"

Dla reguł opartych na wzorcach z użyciem mod_rewrite:

RewriteEngine on
RewriteRule "^/service$" "/about/service" [R=301,L]

nginx

location = /service {
  return 301 https://example.com/about/service;
}

WordPress

WordPress nie ma wbudowanego menedżera przekierowań, więc trzeba dodać jeden z poniższych wariantów:

• Wtyczka Redirection (bezpłatna) — najczęstszy wybór; dodajesz źródło → cel w interfejsie.
• Yoast SEO Premium — jego Redirect Manager może automatycznie utworzyć przekierowanie, gdy usuwasz slug adresu URL lub go zmieniasz. Pamiętaj, że bezpłatna wersja Yoast nie ma menedżera przekierowań (wiele poradników to pomija).
• Poziom serwera — jeśli możesz edytować .htaccess/nginx bezpośrednio, reguła serwerowa jest szybsza niż wtyczka oparta na PHP, która uruchamia się przy każdym żądaniu.

Cloudflare

Jeśli korzystasz z Cloudflare, możesz przekierować na brzegu sieci, zanim żądanie dotrze do serwera źródłowego:

• Single Redirects — pojedyncze reguły w panelu.
• Bulk Redirects — lista przekierowań (tysiące par źródło → cel) stosowana na poziomie całego konta. To naprawdę przydatne przy pełnej migracji, bo nie trzeba w ogóle dotykać konfiguracji serwera źródłowego — wygodne, gdy stary serwer jest wycofywany.

Kod aplikacji (przykład w PHP)

header('HTTP/1.1 301 Moved Permanently');
header('Location: https://www.example.com/new-url');
exit();

„Fałszywe” 301 — tryb awarii, którego nikt nie sprawdza

To zaskakujący przypadek, który warto zapamiętać: adres URL może zwracać 200 OK i nadal przekierowywać. Jak napisałem w artykule 11 typów przekierowań i ich wpływ na SEO, “A redirect can still be happening with any status code. You may have a page that shows as a 200 OK status code, but still actually be redirecting” (tłumaczenie) „Przekierowanie może nadal zachodzić przy dowolnym kodzie stanu. Strona może wyświetlać kod stanu 200 OK, a mimo to faktycznie przekierowywać” — przez JavaScript, po załadowaniu strony. Takie „przekierowanie” jest niewidoczne przy szybkim sprawdzeniu kodu stanu i nie ma żadnej z gwarancji 301.

Wytyczne Google porządkują te metody następująco:

• Po stronie serwera (301/308): najlepiej. Używaj zawsze, gdy jest to technicznie możliwe.
• Odświeżenie meta: zależy od czasu. Google: natychmiastowe odświeżenie meta jest interpretowane jako stałe przekierowanie, a opóźnione odświeżenie meta (uruchamiane po N sekundach) jako tymczasowe. Dlatego odświeżenie content="5;url=…" nie zastępuje 301.
• JavaScript: ostateczność. Google: “Only use JavaScript redirects if you can’t do server-side or meta refresh redirects… if you set a JavaScript redirect, Google might never see it if rendering of the content failed.” (tłumaczenie) „Używaj przekierowań JavaScript tylko wtedy, gdy nie możesz zastosować przekierowania serwerowego ani odświeżenia meta; jeśli ustawisz przekierowanie JavaScript, Google może go nigdy nie zobaczyć, gdy renderowanie treści się nie powiedzie.” Jeśli renderowanie się nie zakończy, przekierowanie praktycznie nie istnieje dla Google.
• „Crypto” / pseudo-przekierowania oparte wyłącznie na linku: nie. Strona, która tylko prowadzi do nowego adresu URL bez kodu stanu i bez odświeżenia, jest — słowami Google — czymś, “not all search engines may recognize… as an official redirect.” (tłumaczenie) „czego nie wszystkie wyszukiwarki mogą rozpoznać jako oficjalne przekierowanie.” Nie polegaj na tym.

Wniosek: jeśli zależy Ci na SEO, potwierdź, że przekierowanie jest prawdziwym serwerowym 301, a nie kodem 200 przekierowującym w przeglądarce. Karta Scripts pokazuje, jak sprawdzić to za pomocą curl.

Typowe błędy przy 301

• Przekierowanie wszystkiego na stronę główną. Klasyczny błąd. Google: “Don’t redirect many old URLs to one irrelevant single URL destination, such as the home page… This can confuse users and might be treated as a soft 404 error.” (tłumaczenie) „Nie przekierowuj wielu starych adresów URL do jednego niepowiązanego celu, takiego jak strona główna — może to zdezorientować użytkowników i zostać potraktowane jako błąd soft 404.” Przekieruj do odpowiedniego zamiennika — a jeśli naprawdę połączyłeś kilka stron w jedną, przekierowanie wszystkich do nowej połączonej strony jest w porządku.
• Długie łańcuchy przekierowań. Google podąży za “up to 10 hops,” (tłumaczenie) „nawet za 10 przeskokami”, ale zaleca przejście prosto do końcowego celu, “ideally no more than 3 and fewer than 5.” (tłumaczenie) „najlepiej nie więcej niż 3 i mniej niż 5.” Mueller powiedział, że przy jednej próbie crawlowania Google śledzi około 5 przeskoków dla często crawlowanych adresów URL. Mój praktyczny próg jest podobny: nie martwię się łańcuchami krótszymi niż około 5 przeskoków, ale po przekroczeniu 5 widziałem problemy. Łańcuchy zwiększają też opóźnienie dla prawdziwych użytkowników. Po dodaniu nowego przekierowania zaktualizuj stare reguły tak, aby wskazywały końcowy adres URL, a nie poprzedni przeskok.
• Użycie 302, gdy chodzi o 301. 302 mówi Google, że oryginalny adres URL powinien pozostać kanoniczny, więc stała zmiana wykonana przez 302 może pozostawić w indeksie niewłaściwy adres URL. Google może z czasem zinterpretować długo utrzymywany 302 jako stały, ale czas tego procesu jest nieznany — jak ująłem to wcześniej, nikt dokładnie nie wie, ile to potrwa, „zwykle od kilku tygodni do kilku miesięcy”. Użyj kodu stanu zgodnego z intencją.
• Zbyt wczesne usuwanie przekierowań. Okres krótszy niż rok grozi pozostawieniem wartości na martwym adresie URL. Utrzymuj je co najmniej rok, najlepiej bezterminowo.
• Zbyt szerokie reguły wieloznaczne. Reguła obejmująca cały folder może wysyłać adresy URL do niewłaściwego miejsca. Mapuj stare adresy na nowe 1:1, na ile to możliwe.
• Zapominanie o zasobach innych niż HTML. Podczas migracji przekieruj także obrazy i PDF-y; plików JS/CSS/fontów nie musisz przekierowywać.
• Zbyt wczesne wyłączenie starego hosta. Reguła przekierowania nie uratuje żądania, które nigdy do niego nie dotrze — jeśli wycofasz DNS starej domeny, pozwolisz wygasnąć certyfikatowi TLS albo wyłączysz stary serwer przed zakończeniem pracy przekierowań, odwiedzający i boty zobaczą błąd połączenia zamiast 301. Utrzymuj DNS starego hosta, certyfikat i reguły przekierowań tak długo, jak długo zachowujesz przekierowania.

Bing

Bing traktuje 301 jako silny sygnał konsolidowania rankingu na stronie docelowej i wycofywania starego adresu URL z indeksu — zasadniczy model jest taki sam jak w Google. Wieloletnie wytyczne Binga zalecają utrzymywanie stałego przekierowania przez krótsze minimum (rzędu kilku miesięcy) niż około rok zalecany przez Google, a wytyczne migracji mówią, że 301 zwykle wystarczają — narzędzie Site Move ich nie zastępuje. Jeśli obsługujesz obie wyszukiwarki (a tak jest), bezpieczny wybór to kierować się surowszą wskazówką: prawdziwe serwerowe 301 utrzymywane co najmniej przez rok.

Gdzie to się mieści

301 to jeden z kodów stanu należących do całej rodziny. Najbardziej bezpośrednio łączy się z przekierowaniem 302 (swoim tymczasowym odpowiednikiem) — wybór 301 czy 302 sprowadza się do pytania: „czy przeniesienie jest stałe?”. Jest blisko spokrewniony z kanonizacją (301 to silny sygnał kanoniczny, ale przy przenoszeniu strony, a nie przy konsolidowaniu duplikatów, które nadal pozostają aktywne — w tym drugim przypadku służy rel="canonical"). To podstawa każdej migracji witryny. Szerszy zestaw kodów — tymczasowe 302/307, stały 308, usunięte 404/410 i błędy 5xx — znajdziesz w klastrze kodów stanu HTTP, do którego należy ta strona.

Podsumowanie AI

Skrócona wersja wariantu Advanced:

• 301 = HTTP „301 Moved Permanently” — odpowiedź po stronie serwera, która trwale przenosi adres URL i jest jednym z najsilniejszych sygnałów celu kanonicznego w Google. To sygnał, nie gwarancja — sam w sobie nie obiecuje indeksowania, rankingu ani ruchu. Google traktuje 301 i 308 tak samo z punktu widzenia SEO, ale 301 może zmienić POST na GET i jest domyślnie heurystycznie zapisywany w cache; użyj 308, jeśli musisz zachować metodę.
• Brak utraty PageRank. Dokładne słowa Google: “301 and other permanent redirects don’t cause a loss in PageRank.” (tłumaczenie) „301 i inne stałe przekierowania nie powodują utraty PageRank.” Stara zasada „utraty około 15% na przeskok” jest nieaktualna — Google nie publikuje też żadnego odsetka przekazywanej wartości, więc nigdy nie podawaj „90–99%”.
• Trzy zegary czasu: serwer = natychmiast; migracja indeksu = dni lub tygodnie (dłużej w przypadku dużych witryn); pełna konsolidacja sygnałów = zwykle co najmniej rok. Utrzymuj przekierowania co najmniej rok, najlepiej na zawsze.
• Wdrażaj na serwerze lub brzegu sieci: Apache .htaccess (Redirect permanent / mod_rewrite [R=301]), nginx (return 301), WordPress (wtyczka Redirection lub Yoast Premium — bezpłatny Yoast nie ma menedżera przekierowań), Cloudflare — przekierowania Single/Bulk na brzegu, bez konfiguracji serwera źródłowego — albo kod aplikacji.
• „Fałszywe” 301: strona może zwrócić 200 i nadal przekierowywać przez JavaScript (niewidoczne przy sprawdzaniu kodu stanu). Natychmiastowe odświeżenie meta ≈ stałe; opóźnione odświeżenie meta ≈ tymczasowe; JS jest ostatecznością (Google może go nie zobaczyć, jeśli renderowanie się nie powiedzie); pseudo-przekierowania oparte tylko na linku są zawodne.
• Najczęstsze błędy: przekierowanie wszystkiego na stronę główną (ryzyko soft 404); długie łańcuchy (utrzymuj mniej więcej poniżej 5 przeskoków); użycie 302 przy stałej zmianie; zbyt wczesne usunięcie przekierowań; szerokie wieloznaczniki zamiast mapowania 1:1.
• Zastrzeżenie Patricka: własny test usunięcia 301 po roku pokazał bardziej nieuporządkowane i mieszane wyniki w rzeczywistym świecie niż prosta opowieść „po roku wszystko jest bezpieczne” — więc zachowaj przekierowania.

Oficjalna dokumentacja

Dokumentacja źródłowa wyszukiwarek.

Google

• Przekierowania i wyszukiwarka Google — czym jest 301, przekierowania po stronie serwera a odświeżenie meta i JavaScript, zasady czasu odświeżenia meta oraz przykładowy kod implementacji (PHP, Apache, nginx).
• Przenosiny witryny ze zmianą adresów URL — stwierdzenie o „braku utraty PageRank”, wskazówka, by utrzymywać przekierowania zwykle co najmniej rok, limity łańcuchów przekierowań, ostrzeżenie o soft 404 oraz tempo przenoszenia małych i dużych witryn.
• How to specify a canonical URL — miejsce przekierowań w hierarchii sygnałów kanonizacji.
• Crawling and Indexing — strona nadrzędna dla przekierowań, kanonizacji i kontroli crawlowania.

Bing / Microsoft

• Bing Webmaster Guidelines — stanowisko Binga wobec przekierowań i stałych przenosin.
• Website Migration with Bing (grudzień 2020) — narzędzie Site Move Binga i informacja, że 301 zwykle wystarcza, a narzędzie go nie zastępuje.

Wdrożenia platformowe

• Cloudflare — Bulk Redirects — listy przekierowań stosowane na poziomie całego konta, na brzegu sieci.
• Cloudflare — URL forwarding (Redirects) overview — przegląd przekierowań Single i Bulk.
• Yoast — How to create a 301 redirect in WordPress — warianty właściwe dla WordPressa (w tym informacja, że zarządzanie przekierowaniami jest funkcją Premium).

Cytaty ze źródła

Udokumentowane wypowiedzi Google. Każdy odnośnik prowadzi bezpośrednio do cytowanego fragmentu na stronie źródłowej.

Google — czym jest 301 i kiedy go używać

• “The 301 and 308 status codes mean that a page has permanently moved to a new location.” (tłumaczenie) „Kody stanu 301 i 308 oznaczają, że strona została trwale przeniesiona do nowej lokalizacji.” — Google Search Central, Przekierowania i wyszukiwarka Google. Przejdź do cytatu
• “If you need to change the URL of a page as it is shown in search engine results, we recommend that you use a permanent server-side redirect whenever possible.” (tłumaczenie) „Jeśli musisz zmienić adres URL strony wyświetlany w wynikach wyszukiwania, Google zaleca, aby w miarę możliwości użyć stałego przekierowania po stronie serwera.” Przejdź do cytatu
• “Use server side permanent redirects if technically possible… we recommend that you use HTTP permanent redirects if possible, such as 301 and 308.” (tłumaczenie) „Jeśli to technicznie możliwe, używaj stałych przekierowań po stronie serwera; zalecamy, aby w miarę możliwości używać stałych przekierowań HTTP, takich jak 301 i 308.” — Google Search Central, Przenosiny witryny ze zmianą adresów URL. Przejdź do cytatu

Google — PageRank / konsolidacja (oś dokładności)

• “301 and other permanent redirects don’t cause a loss in PageRank.” (tłumaczenie) „301 i inne stałe przekierowania nie powodują utraty PageRank.” — Google Search Central, Przenosiny witryny ze zmianą adresów URL. Przejdź do cytatu
• “When you redirect a URL, Google keeps track of both the redirect source (the old URL) and the redirect target (the new URL). One of the URLs will be the canonical… The other URL becomes an alternate name of the canonical URL.” (tłumaczenie) „Gdy przekierujesz adres URL, Google zapisuje zarówno jego stare źródło, jak i nowy cel. Jeden z tych adresów zostaje kanoniczny; drugi staje się jego alternatywną nazwą.” Przejdź do cytatu

Google — czas

• “Keep the redirects for as long as possible, generally at least 1 year. This timeframe allows Google to transfer all signals to the new URLs… From users’ perspective, consider keeping redirects indefinitely.” (tłumaczenie) „Przekierowania należy zachować jak najdłużej, zazwyczaj przez co najmniej rok. Pozwala to Google przenieść wszystkie sygnały na nowe adresy URL; z punktu widzenia użytkowników warto utrzymywać je bezterminowo.” Przejdź do cytatu
• “A small to medium-sized website can take a few weeks for most pages to move, and larger sites take longer… the visibility of your content in Search may fluctuate temporarily during the move. This is normal.” (tłumaczenie) „Mała lub średnia witryna może potrzebować kilku tygodni, aby większość stron się przeniosła, a większe witryny potrzebują więcej czasu; widoczność treści w wyszukiwarce może tymczasowo zmieniać się podczas przenosin. To normalne.” Przejdź do cytatu

Google — łańcuchy przekierowań, soft 404 i fałszywe przekierowania

• “While Googlebot can follow up to 10 hops in a ‘chain’ of multiple redirects… we advise redirecting to the final destination directly. If this is not possible, keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5.” (tłumaczenie) „Googlebot może podążać za maksymalnie 10 przeskokami w „łańcuchu” wielu przekierowań; zalecamy jednak przekierowanie bezpośrednio do celu końcowego. Jeśli nie jest to możliwe, utrzymuj małą liczbę przekierowań w łańcuchu, najlepiej nie większą niż 3 i mniejszą niż 5.” Przejdź do cytatu
• “Don’t redirect many old URLs to one irrelevant single URL destination, such as the home page of the new site. This can confuse users and might be treated as a soft 404 error.” (tłumaczenie) „Nie przekierowuj wielu starych adresów URL do jednego niepowiązanego celu, takiego jak strona główna nowej witryny. Może to zdezorientować użytkowników i zostać potraktowane jako błąd soft 404.” Przejdź do cytatu
• “Only use JavaScript redirects if you can’t do server-side or meta refresh redirects… if you set a JavaScript redirect, Google might never see it if rendering of the content failed.” (tłumaczenie) „Używaj przekierowań JavaScript tylko wtedy, gdy nie możesz zastosować przekierowania serwerowego ani odświeżenia meta; jeśli ustawisz przekierowanie JavaScript, Google może go nigdy nie zobaczyć, gdy renderowanie treści się nie powiedzie.” — Google Search Central, Przekierowania i wyszukiwarka Google. Przejdź do cytatu
• “Google Search interprets instant meta refresh redirects as permanent redirects… Google Search interprets delayed meta refresh redirects as temporary redirects.” (tłumaczenie) „Google Search interpretuje natychmiastowe przekierowania przez odświeżenie meta jako stałe, a opóźnione przekierowania przez odświeżenie meta jako tymczasowe.” “Google differentiates between two kinds of meta refresh redirects” (tłumaczenie) „Google rozróżnia dwa rodzaje przekierowań przez odświeżenie meta.” Przejdź do cytatu

Lista kontrolna wdrożenia przekierowania 301

Kontrola do wykonania przed, w trakcie i po uruchomieniu stałego przekierowania (lub ich zestawu):

Przed

• Potwierdź, że przeniesienie jest rzeczywiście stałe — jeśli jest tymczasowe, potrzebujesz 302, a nie 301.
• Zbuduj mapę 1:1 starego adresu URL → najbardziej odpowiedniego nowego adresu URL (nie starego adresu URL → strony głównej).
• Przy konsolidacji określ pojedynczy adres URL pozostający dla każdej grupy przekierowań.
• Zaplanuj także przekierowanie obrazów i PDF-ów (pomiń pliki JS/CSS/fontów).

Wdrażanie

• Zrób to po stronie serwera (Apache/nginx/aplikacja) albo na brzegu sieci (Cloudflare) — nie przez JavaScript ani opóźnione odświeżenie meta.
• Preferuj reguły 1:1 zamiast szerokich wieloznaczników folderów, które mogą kierować adresy URL w złe miejsce.
• Kieruj każdą regułę do końcowego celu, aby nie tworzyć łańcuchów.
• W WordPressie użyj wtyczki Redirection lub Yoast Premium (bezpłatny Yoast nie ma menedżera przekierowań), ewentualnie reguły serwerowej.

Weryfikacja

• Sprawdź, czy każdy stary adres URL zwraca prawdziwy 301 (nie 200, nie 302 i nie przekierowanie JS) — zobacz kartę Scripts, aby poznać kontrole curl.
• Potwierdź, że nie ma łańcuchów dłuższych niż około 5 przeskoków; skróć każdy znaleziony łańcuch do jednego przeskoku.
• Sprawdź, czy cel zwraca 200, a nie kolejne przekierowanie lub 404.
• Przetestuj adres URL z parametrem zapytania, fragmentem, końcowym ukośnikiem lub wielkością liter — reguły mogą po cichu zgubić te elementy albo zmienić ich znaczenie podczas przenoszenia.
• Wybiórczo sprawdź przekierowane adresy URL w GSC URL Inspection, aby zobaczyć, jak Google rozwiązuje je w indeksie.
• Przy migracji uruchom crawl całej witryny (Ahrefs Site Audit / Screaming Frog), aby znaleźć pominięte linki wewnętrzne, stare wpisy w sitemapach, pętle, łańcuchy i przekierowane zasoby.

Po wdrożeniu

• Pozostaw przekierowania aktywne zwykle co najmniej przez rok — najlepiej bezterminowo.
• Przygotuj się na to, że stary adres URL będzie przez pewien czas obecny w wynikach („alternatywna nazwa”) — to normalne; nie usuwaj przekierowania, aby wymusić jego zniknięcie.

Wykrywanie i testowanie 301

Sprawdź za pomocą narzędzia Redirect Checker:

1. Wklej testowany adres URL do pola pojedynczego adresu URL (albo przełącz się na tryb zbiorczy dla maksymalnie 20 adresów).
2. Kliknij Check redirects, aby prześledzić cały łańcuch.
3. Odczytaj kod stanu pierwszego przeskoku i kropkę werdyktu — prawdziwe stałe przekierowanie pokazuje 301 (lub 308) przez cały przebieg; wtrącony 302/307 albo poziom ważności „łańcuch” wyższy niż zielony oznacza, że nie jest to czysty jednoprzeskokowy 301.

Te kontrole mają odpowiedzieć na jedno pytanie: czy ten adres URL naprawdę zwraca serwerowy 301, czy coś mnie oszukuje? (Pamiętaj: strona może zwracać 200 OK i nadal przekierowywać w przeglądarce przez JavaScript.)

Nie testuj wyłącznie podstawowego adresu URL — powtórz kontrolę dla wersji z parametrem zapytania, #fragment, końcowym ukośnikiem lub inną wielkością liter. Specyfikacja HTTP nie gwarantuje, że reguła przepisywania przeniesie te elementy; to szczegół implementacji konkretnej reguły, a RewriteRule lub dopasowanie wzorca często po cichu gubi parametr zapytania albo fragment oryginalnego adresu URL.

Zobacz surowy kod stanu i łańcuch przekierowania (curl)

macOS / Linux / WSL

# Show response headers only — look for "HTTP/… 301" and the "location:" target
curl -sI https://example.com/old-page

# Follow the whole chain and print each hop's status + final URL
curl -sIL -o /dev/null -w "%{http_code}  %{url_effective}\n" https://example.com/old-page

# Print every status code in the chain (catches multi-hop chains)
curl -sIL https://example.com/old-page | grep -i "^HTTP\|^location"

Czyste stałe przekierowanie wygląda jak HTTP/1.1 301 Moved Permanently (lub HTTP/2 301) z pojedynczym nagłówkiem location: wskazującym końcowy adres URL. Jeśli widzisz 302, przekierowanie jest tymczasowe. Jeśli widzisz 200, ale przeglądarka trafia gdzie indziej, jest to „fałszywe” przekierowanie JavaScript/meta refresh.

Windows (PowerShell)

# MaximumRedirection 0 stops at the first hop so you can read its status code
$r = Invoke-WebRequest -Uri "https://example.com/old-page" -MaximumRedirection 0 -SkipHttpErrorCheck
$r.StatusCode              # 301 for a permanent redirect
$r.Headers.Location        # the target URL

Wykrywanie „fałszywego” przekierowania JavaScript

curl widzi tylko odpowiedź serwera, a nie JavaScript. Jeśli curl mówi 200, ale strona nadal przenosi Cię w prawdziwej przeglądarce, przekierowanie jest wykonywane po stronie klienta. Potwierdź to w Chrome DevTools:

1. Otwórz DevTools → Network i zaznacz Preserve log.
2. Załaduj stary adres URL.
3. Jeśli pierwsze żądanie pokazuje Status 301 (lub 308), jest to prawdziwe przekierowanie serwerowe. Jeśli pierwsze żądanie ma 200, a później pojawia się wpis nawigacji, jest to przekierowanie JS/meta refresh — nie prawdziwy 301.

Apache .htaccess

# Single URL (mod_alias)
Redirect permanent "/old-page" "https://example.com/new-page"

# Pattern / regex rule (mod_rewrite) — R=301 makes it permanent, L stops processing
RewriteEngine on
RewriteRule "^old-section/(.*)$" "https://example.com/new-section/$1" [R=301,L]

# Force HTTP → HTTPS for the whole site
RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

nginx

# Single URL
location = /old-page {
  return 301 https://example.com/new-page;
}

# Whole-path prefix
location /old-section/ {
  return 301 https://example.com/new-section/;
}

# Force HTTP → HTTPS
server {
  listen 80;
  server_name example.com;
  return 301 https://$host$request_uri;
}

WordPress (bez wtyczki — functions.php, używaj oszczędnie)

// Runs on every request; a server rule or the Redirection plugin scales better.
add_action( 'template_redirect', function () {
    if ( is_page() && get_query_var( 'name' ) === 'old-page' ) {
        wp_redirect( home_url( '/new-page/' ), 301 );
        exit;
    }
} );

W większości witryn WordPress wtyczka Redirection lub Redirect Manager w Yoast Premium to praktyczny wybór — bez kodu, a Yoast Premium może automatycznie utworzyć 301 po zmianie lub usunięciu sluga adresu URL.

Cloudflare (brzeg sieci, bez konfiguracji serwera źródłowego)

Single Redirects Cloudflare są dostępne w panelu (Rules → Redirect Rules). Przy migracji lista Bulk Redirects przyjmuje dwukolumnowy plik CSV źródło → cel i stosuje go na poziomie całego konta, na brzegu sieci — to najszybszy sposób przeniesienia tysięcy adresów URL bez dotykania konfiguracji serwera źródłowego.

Błędy przy 301, które zamieniają czyste przenosiny w bałagan

Przekierowanie każdego starego adresu URL na stronę główną

Nieistotna reguła obejmująca wszystko dezorientuje użytkowników i może zostać potraktowana jako soft 404. Mapuj każdy stary adres URL na jego najbliższy rzeczywisty zamiennik; zwracaj 404 lub 410, gdy nie istnieje żaden zamiennik.

Dodanie nowego celu na końcu starego łańcucha

Łańcuch stary → poprzedni → obecny zwiększa opóźnienie i liczbę punktów awarii. Zaktualizuj najstarszą regułę tak, aby wskazywała bezpośrednio końcowy cel zwracający 200.

Pozostawienie 302 przy stałym przeniesieniu

Tymczasowy kod mówi wyszukiwarkom, aby preferowały źródłowy adres URL. Gdy przeniesienie jest stałe, użyj prawdziwego serwerowego 301 lub 308, a następnie sprawdź status na przewodzie.

Usunięcie przekierowania, gdy tylko pojawi się nowy adres URL

Zmiana w indeksie nie oznacza pełnej konsolidacji sygnałów. Google zaleca utrzymywanie przekierowań tak długo, jak to możliwe, zwykle co najmniej rok; bezterminowe utrzymanie jest lepsze dla użytkowników i starych linków, gdy jego koszt operacyjny jest niski.

Zaufanie szerokiemu wieloznacznikowi bez testowania jego celów

Reguła folderowa może wysłać niepowiązane adresy URL do niewłaściwej strony. Zacznij od mapy 1:1, przetestuj przypadki brzegowe i zostaw wzorce dla struktur adresów URL, których przekształcenie źródło → cel jest rzeczywiście spójne.

Zapominanie o zasobach innych niż HTML

Obrazy i PDF-y również mogą mieć linki i ruch. Uwzględnij przenoszone zasoby w mapie, gdy mają odpowiednie zamienniki; nie przekierowuj bez namysłu każdego żądania JS, CSS ani fontu.

Audyt mapy przekierowań przed wdrożeniem

Wklej plik CSV zawierający co najmniej kolumny source_url i target_url. Dodaj bieżący status źródła i celu, typ treści, tytuł strony oraz kategorię tematyczną, jeśli są dostępne.

Audit this proposed permanent redirect map.

For each row:
1. Flag homepage or other catch-all targets that are not demonstrably relevant.
2. Flag duplicate sources, missing targets, source=target loops, and likely chains where a
   target also appears as a source.
3. Compare source and target titles/categories only from the supplied data and label the
   mapping relevant, questionable, or insufficient evidence.
4. Recommend one action: keep the 1:1 mapping, map to a closer replacement, return 404/410,
   or investigate manually.

Do not invent replacement URLs or assume a target returns 200 unless the data says so.
Return: critical blockers, row-by-row findings, then the exact URLs to test after launch.

PASTE REDIRECT CSV HERE

Model trzech zegarów dla 301

„Jak długo działa 301?” nie ma jednej odpowiedzi, ponieważ trzy systemy poruszają się według różnych zegarów. Zanim zinterpretujesz wynik, nazwij zegar, którego dotyczy.

Model zapobiega dwóm częstym błędom kategorialnym: uznaniu działającej reguły serwerowej za dowód zakończenia indeksowania oraz uznaniu zmiany wyniku wyszukiwania za pozwolenie na usunięcie reguły. Weryfikuj każdy zegar za pomocą właściwych dla niego dowodów.

Narzędzia do wdrażania i sprawdzania 301

Bezpłatne narzędzia Patricka

• Redirect Checker — sprawdź jeden adres URL lub szybką partię i zobacz pierwszy status, każdy przeskok oraz końcowy cel. Użyj go do szybkiej kontroli „czy to prawdziwy jednoprzeskokowy 301?”.
• Redirect Chain Mapper — zdiagnozuj zmiany na każdym przeskoku i wyeksportuj reguły porządkowania dla Cloudflare, Apache lub nginx. Użyj go, gdy sam łańcuch trzeba skrócić.
• Bulk HTTP Status Code Checker — przetestuj do 500 zmapowanych adresów URL, odfiltruj źródła inne niż 301 i cele inne niż 200, a następnie wyeksportuj zestaw kontroli jakości przed uruchomieniem.

Kontrole wyszukiwania i infrastruktury

• Google Search Console URL Inspection — potwierdź, że Google pobrał stary adres URL jako przekierowanie, i sprawdź wybór kanonicznego adresu URL na stronie docelowej.
• Logi serwera/CDN — sprawdź, czy prawdziwe żądania Googlebota otrzymują tę samą regułę co żądania użytkowników.
• Crawler całej witryny — znajdź pominięte linki wewnętrzne, stare wpisy sitemap, pętle, łańcuchy i przekierowane zasoby po migracji.

Sprawdź się: przekierowania 301

Pięć krótkich pytań o stałe przekierowania. Wybierz odpowiedź przy każdym pytaniu, a następnie sprawdź wynik.

Udowodnij, że przekierowanie rzeczywiście zadziałało

Wdrożyłeś 301. Poniższe kontrole odróżniają „reguła jest w pliku konfiguracyjnym” od „Google konsoliduje stary adres URL na nowym”. Wykonuj je po kolei — pierwsza jest natychmiastowa, ostatnia zajmuje tygodnie.

Test 1 — Stary adres URL zwraca prawdziwy serwerowy 301

• Test do wykonania — Wklej stary adres URL do narzędzia Redirect Checker (albo uruchom curl -sIL -o /dev/null -w "%{http_code} %{url_effective}\n" https://example.com/old-url).
• Oczekiwany wynik — Pierwszy przeskok to 301 (lub 308) z nagłówkiem location:, a końcowy adres URL zwraca 200. Jeden przeskok, czysto.
• Interpretacja niepowodzenia — 200 na starym adresie URL oznacza „fałszywe” przekierowanie JavaScript/meta refresh, a nie serwerowy 301; 302/307 oznacza, że przez pomyłkę wdrożono kod tymczasowy.
• Okno monitorowania — Natychmiast — serwer odpowiada w chwili uruchomienia reguły.
• Wyzwalacz wycofania — Checker pokazuje łańcuch dłuższy niż około 5 przeskoków lub pętlę — wycofaj regułę i skieruj stary adres URL bezpośrednio do końcowego celu 1:1 przed ponownym wdrożeniem.

Test 2 — Google zobaczył przekierowanie i wybrał nowy adres URL

• Test do wykonania — Uruchom URL Inspection w Google Search Console dla starego adresu URL.
• Oczekiwany wynik — Status brzmi „strona z przekierowaniem”, a sprawdzenie nowego adresu URL pokazuje go jako zindeksowany z nim samym jako kanonicznym adresem URL wybranym przez Google.
• Interpretacja niepowodzenia — Jeśli po kilku tygodniach stary adres URL nadal ma status „Submitted and indexed” jako własny kanoniczny adres URL, Google nie może pobrać przekierowania albo sprzeczny sygnał (kanoniczny adres URL, sitemap, linki wewnętrzne) wskazuje z powrotem na stary adres.
• Okno monitorowania — Od kilku dni do kilku tygodni w przypadku małej lub średniej witryny; w przypadku dużych witryn dłużej. Google mówi, że widoczność może się zmieniać podczas przenosin — to normalne.
• Wyzwalacz wycofania — Nie usuwaj przekierowania, aby „naprawić” utrzymujący się stary adres URL — Google przechowuje go jako alternatywną nazwę, która z czasem zanika. Zbadaj sprawę ponownie tylko wtedy, gdy nowy adres URL w ogóle nie zostanie zindeksowany.

Test 3 — Migracja nie pozostawiła ruchu bez celu

• Test do wykonania — Przepuść zmapowane stare adresy URL przez Redirect Checker partiami (do 20 naraz) albo wykonaj crawl całej witryny, a następnie obserwuj przeniesione strony w raporcie skuteczności GSC.
• Oczekiwany wynik — Każdy zmapowany adres URL jest jednym przeskokiem do 200, a liczba kliknięć i wyświetleń celu wraca w ciągu kilku tygodni w kierunku wcześniejszych poziomów starego adresu URL.
• Interpretacja niepowodzenia — Trwały spadek zwykle oznacza błędną mapę (stary adres URL → niewłaściwa lub niepowiązana strona, którą Google może potraktować jako soft 404), a nie „wyciek” PageRank przez przekierowanie — prawidłowy 301 nie powoduje utraty PageRank.
• Okno monitorowania — Przed uznaniem trendu za wiarygodny zbierz 2–4 tygodnie danych GSC; porównuj dopasowane okno przed i po wdrożeniu, nie szum dzień po dniu.
• Wyzwalacz wycofania — Wyraźny, utrzymujący się spadek wyświetleń w przeniesionym zbiorze, który zbiega się z datą uruchomienia — ponownie przeprowadź audyt mapy 1:1, zanim uznasz, że problemem jest samo przekierowanie.

Dziennik zmian