Wklej stare i nowe adresy URL i otrzymaj reguły 301 dla .htaccess lub Nginx, sprawdzone pod kątem pętli
Działa w przeglądarce. Wpisane dane nie są nigdzie wysyłane. Sprawdzono 16 października 2026.Przekierowanie 301 informuje przeglądarki i wyszukiwarki, że strona została przeniesiona na stałe. W pliku .htaccess Apache reguła RewriteRule ^old-page$ /new-page [L,R=301] kieruje /old-page na /new-page; w Nginx to samo robi location = /old-page { return 301 /new-page; }. Do tymczasowego przeniesienia służy 302 lub 307, a do strony usuniętej celowo 410.
Ta strona została przetłumaczona maszynowo z angielskiego oryginału. Tłumaczenie nie zostało jeszcze sprawdzone przez człowieka, dlatego wiążąca jest wersja angielska. Przeczytaj angielski oryginał
Wklej jedno przekierowanie na wiersz w polu Przekierowania: starą ścieżkę, spację, a potem nową ścieżkę lub URL.
Wybierz Apache lub Nginx i włącz Wymuś HTTPS albo wybierz z www lub bez www, jeśli to również jest potrzebne.
Popraw każdy wiersz oznaczony jako pętla i przyjmij propozycję skrócenia łańcuchów, aby każdy odwiedzający wykonywał jeden skok.
Kliknij Kopiuj lub Pobierz i dodaj reguły na początku pliku .htaccess albo do bloku server.
Wystarczy wkleić jedno przekierowanie na wiersz, najpierw stary adres, potem nowy, a reguły powstają w trakcie pisania. Stare adresy mogą być ścieżkami lub pełnymi adresami URL skopiowanymi z przeglądarki albo z eksportu analityki; tabulatory, przecinki i strzałki również działają, więc parę kolumn z arkusza można wkleić od razu. Kod dodany na końcu wiersza zastępuje domyślny, a 410 zamiast nowego adresu oznacza stronę, która już nie istnieje.
Który kod.
| Kod | Znaczenie | Zastosowanie |
|---|---|---|
| 301 | Przeniesiono na stałe | Strony o zmienionej nazwie, nowa domena, HTTPS |
| 308 | Na stałe, ta sama metoda | API i formularze wysyłające POST |
| 302 / 307 | Tymczasowo | Kampanie, prace serwisowe, testy A/B |
| 410 | Usunięto | Strony usunięte celowo |
Apache. Każda reguła korzysta z mod_rewrite. Prostsza dyrektywa Redirect dopasowuje prefiksy, więc Redirect /shop /store łapie też /shopping, a łączenie obu modułów uruchamia je w kolejności, która wielu zaskakuje. Wzorce są zakotwiczone i zabezpieczone znakami ucieczki, więc kropka w old.html pasuje tylko do kropki. Stary adres z ciągiem zapytania, np. /products?id=42, dostaje własny RewriteCond, a zapytanie jest usuwane z nowego adresu.
Nginx. Każda strona dostaje dokładny blok location = z return. HTTPS i wybór www dostają własne bloki server, które wymagają podania domeny.
Sprawdzanie. Reguła, która kieruje stronę na nią samą, bezpośrednio lub przez inne reguły, jest pętlą i zostaje pominięta. Reguła wskazująca inną przekierowaną stronę jest łańcuchem; jedno kliknięcie kieruje ją wprost na stronę docelową, więc odwiedzający i roboty wykonują jeden skok zamiast kilku. Powtórzony stary adres zostaje oznaczony, ponieważ zadziałałaby tylko pierwsza reguła.
HTTPS i host są obsługiwane w jednym skoku, przed regułami stron. Najpierw warto testować z 302: przeglądarki bardzo długo pamiętają 301.
Wszystko działa w przeglądarce; nic z wklejonej treści nie jest nigdzie wysyłane.
Należy raz dodać RewriteEngine On, a potem po jednym wierszu na stronę: RewriteRule ^old-page$ /new-page [L,R=301]. W .htaccess wzorzec nie ma początkowego ukośnika, daszek i dolar sprawiają, że pasuje tylko do tej konkretnej strony, a R=301 czyni przeniesienie stałym. Reguły warto umieścić blisko początku pliku, przed każdym blokiem WordPressa lub frameworka.
301 i 308 są stałe: wyszukiwarki przenoszą pozycję starej strony na nowy adres. 302 i 307 są tymczasowe, więc stary adres pozostaje w indeksie. 307 i 308 dodatkowo wymagają, by przeglądarki powtórzyły tę samą metodę, np. POST, a 301 i 302 dopuszczają zmianę na GET. Większość przeniesień stron powinna używać 301.
Należy połączyć warunki, aby odwiedzający wykonał jeden skok: przekierować, gdy HTTPS jest wyłączony lub host zaczyna się od www, i kierować na https z hostem bez www. Ten generator zapisuje dokładnie to trzema wierszami RewriteCond i jedną RewriteRule albo parą bloków server dla Nginx, zamiast dwóch osobnych przekierowań po kolei.
Pętla powstaje, gdy reguła kieruje stronę na adres, który ta sama lub inna reguła przekierowuje z powrotem. Częste przyczyny to przekierowanie /page na /page/, podczas gdy inna reguła usuwa ukośnik, albo wymuszanie HTTPS za Cloudflare Flexible SSL, gdzie serwer zawsze widzi HTTP. To narzędzie odrzuca reguły tworzące pętlę i wskazuje wiersz.
RewriteRule nigdy nie widzi ciągu zapytania, więc najpierw należy go dopasować przez RewriteCond: RewriteCond %{QUERY_STRING} ^id=42$, a potem RewriteRule dla ścieżki. Flaga QSD sprawia, że ?id=42 nie jest kopiowane do nowego adresu. Wklejenie tutaj /products?id=42 /products/blue-mug zapisuje oba wiersze dla Apache albo test if ($args) dla Nginx.
Każdy dodatkowy skok kosztuje trochę czasu, a Google wykonuje najwyżej 10 skoków, zanim zrezygnuje, więc łańcuchy marnują budżet indeksowania i spowalniają odwiedzających. Po drugiej migracji witryny stare adresy często wskazują strony, które zostały ponownie przekierowane. Ten generator wykrywa każdy łańcuch i jednym kliknięciem przepisuje regułę tak, by wskazywała wprost stronę docelową.
Stawki i przepisy się zmieniają; przed oparciem się na danej liczbie należy sprawdzić źródło.
Nadal coś nie działa? Zapytaj o narzędzie Generator przekierowań .htaccess a odpowiedzieć może każdy, kto zna odpowiedź. Konto nie jest potrzebne.