ERR_TOO_MANY_REDIRECTS: jak to naprawić (wszystkie przeglądarki)

Czym jest ERR_TOO_MANY_REDIRECTS?

ERR_TOO_MANY_REDIRECTS oznacza, że strona ponad 20 razy odesłała przeglądarkę pod inny adres i nigdy się nie załadowała: to pętla przekierowań. Chrome wyświetla „Ta strona nie działa. Strona example.com spowodowała zbyt wiele przekierowań” (Edge pokazuje podobną stronę z tym samym kodem), Firefox pisze „Pętla przekierowań”, a Safari — „Safari nie może otworzyć strony” z wyjaśnieniem „Wystąpiło zbyt wiele przekierowań podczas próby otworzenia…”.

Jeśli tylko odwiedzasz witrynę, usuń jej pliki cookie i przeładuj stronę: gdy u innych witryna działa, przyczyną jest zwykle nieaktualny plik cookie. Jeśli to Twoja witryna, pętla prawie zawsze wynika z wymuszania HTTPS (lub www) w dwóch miejscach naraz, najczęściej trybu Flexible SSL w Cloudflare razem z przekierowaniem na HTTPS na serwerze.

Limit jest wszędzie taki sam, bo tak określa standard Fetch, który implementują przeglądarki: „If request's redirect count is 20, then return a network error” (jeśli licznik przekierowań żądania wynosi 20, zwróć błąd sieci). Sama pętla to zwykle dwie odpowiedzi 301 lub 302 wskazujące na siebie nawzajem: URL A odsyła Cię do URL B, URL B z powrotem do A, a przeglądarka przestaje liczyć na 20.

Co powoduje pętle przekierowań?

Pętle przekierowań występują, gdy dwie lub więcej reguł przekierowań wchodzi ze sobą w konflikt. Serwer wysyła przeglądarkę na dany URL, a ten URL wysyła przeglądarkę z powrotem. Oto najczęstsze przyczyny:

• Błędna konfiguracja SSL/HTTPS — Najczęstsza przyczyna. Twój serwer wymusza HTTP na HTTPS, ale CDN lub load balancer łączy się z serwerem po HTTP, tworząc pętlę: CDN → HTTP → serwer przekierowuje na HTTPS → CDN usuwa HTTPS → HTTP → pętla
• Cloudflare Flexible SSL — Tryb Flexible SSL w Cloudflare wysyła żądania do serwera po HTTP. Jeśli serwer również wymusza przekierowanie HTTP na HTTPS, powstaje nieskończona pętla między Cloudflare a serwerem
• Kolidujące reguły w .htaccess — Wiele reguł przekierowań w .htaccess, które sobie przeczą, np. jedna reguła wymuszająca www, a druga wymuszająca bez www jednocześnie
• Niezgodność URL w WordPress — Adres WordPress (URL) i Adres witryny (URL) w Ustawienia > Ogólne nie są zgodne, lub jeden używa HTTP, a drugi HTTPS
• Przestarzałe pliki cookie przeglądarki — Stare pliki cookie zawierające nieaktualne instrukcje przekierowań lub dane sesji, które kierują przeglądarkę na URL, który już nie istnieje lub został przeniesiony
• Przekierowania w cache CDN lub proxy — CDN zapamiętał stare przekierowanie 301, które teraz koliduje z aktualną konfiguracją serwera
• Konflikty konfiguracji serwera — Pliki konfiguracyjne Nginx lub Apache z konkurującymi blokami przekierowań, np. przekierowanie zarówno w bloku serwera, jak i w .htaccess jednocześnie
• Pętle logowania w aplikacjach — Strona logowania przekierowuje niezalogowanych odwiedzających do samej siebie albo przeglądarka odmawia zapisania pliku cookie sesji (OAuth, Supabase Auth, NextAuth). Zobacz Poprawkę 8

Jak zdiagnozować pętlę przekierowań

Zanim zaczniesz próbować poprawek, zidentyfikuj dokładny łańcuch przekierowań. To pokaże Ci, które adresy URL są zaangażowane i które reguły przekierowań powodują pętlę.

Metoda 1: użyj curl do śledzenia przekierowań

Najszybszym sposobem na zobaczenie łańcucha przekierowań jest użycie curl w terminalu. Flaga -I pobiera tylko nagłówki, -L podąża za przekierowaniami, a --max-redirs ogranicza ich liczbę:

# Trace redirect chain (limit to 10 hops)
curl -ILs --max-redirs 10 https://example.com 2>&1 | grep -i 'HTTP/\|location:'

# Example output showing a redirect loop:
# HTTP/2 301
# location: http://example.com/
# HTTP/1.1 301 Moved Permanently
# Location: https://example.com/
# HTTP/2 301
# location: http://example.com/
# (repeats...)

Jeśli widzisz te same dwa adresy URL naprzemiennie w nagłówkach Location, potwierdziłeś pętlę przekierowań. Zwróć uwagę na kody statusu: 301 to przekierowanie stałe, które przeglądarki zapisują w pamięci podręcznej, a 302 to przekierowanie tymczasowe, którego się nie buforuje, chyba że odpowiedź stanowi inaczej.

Obserwuj schemat w każdym nagłówku Location: pętla między wersją http:// i https:// tego samego adresu URL to najczęstszy wzorzec i wskazuje prosto na ustawienie SSL.

Metoda 2: karta Network w DevTools przeglądarki

Możesz również śledzić przekierowania wizualnie w Chrome DevTools:

• Krok 1 — Otwórz Chrome DevTools za pomocą F12 lub Ctrl+Shift+I (Mac: Cmd+Option+I)
• Krok 2 — Przejdź do karty Network i zaznacz Preserve log (zachowuje wpisy między przekierowaniami)
• Krok 3 — Załaduj stronę, która wywołuje błąd
• Krok 4 — Sprawdź sekwencję żądań. Każde przekierowanie pojawia się jako osobny wpis ze statusem 301 lub 302. Kolumna Location pokazuje, dokąd wskazuje każde przekierowanie

Karta Network pokazuje pełny łańcuch przekierowań w kolejności chronologicznej. Zobaczysz wzorzec — zazwyczaj dwa lub trzy adresy URL powtarzające się cyklicznie. Użyj narzędzia Checker nagłówków HTTP od DNS Robot, aby sprawdzić nagłówki odpowiedzi poza pamięcią podręczną przeglądarki.

Metoda 3: sprawdzanie przekierowań online

Jeśli nie masz terminala, wklej URL do Checker przekierowań od DNS Robot. Narzędzie przechodzi każdy skok z naszego serwera, pokazuje każdy kod statusu i nagłówek Location oraz informuje, gdy łańcuch zapętla się sam na siebie. Działa bez plików cookie Twojej przeglądarki, więc od razu wiesz, czy pętla jest po stronie witryny, czy Twojej przeglądarki.

Poprawka 1: wyczyść pliki cookie i pamięć podręczną przeglądarki

Zacznij od najprostszej poprawki. Przestarzałe pliki cookie lub buforowane przekierowania w przeglądarce mogą powodować pętle nawet przy prawidłowej konfiguracji serwera. Jest to szczególnie częste po migracji witryny z HTTP na HTTPS — stare pliki cookie mogą nadal odwoływać się do adresów HTTP.

Czyszczenie plików cookie w Chrome

Wyczyść pliki cookie dla konkretnej witryny, a nie wszystkie — to zachowa Twoje logowania na innych stronach:

• Krok 1 — Kliknij ikonę kłódki (lub ikonę ustawień) na pasku adresu obok URL
• Krok 2 — Kliknij Ustawienia witryn
• Krok 3 — Kliknij Usuń dane, aby usunąć pliki cookie i dane w cache tylko dla tej witryny
• Krok 4 — Przeładuj stronę

# Chrome keyboard shortcut to open Delete browsing data:
# Windows/Linux: Ctrl + Shift + Delete
# macOS: Cmd + Shift + Delete

Albo usuń wszystko dla wszystkich witryn: naciśnij Ctrl+Shift+Delete (Mac: Cmd+Shift+Delete), aby otworzyć okno Usuń dane przeglądania, zaznacz Pliki cookie i inne dane witryn oraz Obrazy i pliki zapisane w pamięci podręcznej, wybierz Od początku i kliknij Usuń dane.

Czyszczenie plików cookie w Firefox i Safari

Firefox: Naciśnij Ctrl+Shift+Delete (Mac: Cmd+Shift+Delete), zaznacz Ciasteczka i dane witryn oraz Pliki i strony w tymczasowej pamięci podręcznej, ustaw zakres czasowy na wszystko i kliknij Wyczyść.

Safari: Przejdź do Safari > Ustawienia > Prywatność > Zarządzaj danymi witryn, wyszukaj daną domenę, zaznacz ją i kliknij Usuń. Następnie wyczyść pamięć podręczną skrótem Cmd+Option+E.

Jeśli usunięcie plików cookie pomogło, reguła przekierowania na serwerze niedawno się zmieniła, a Twoja przeglądarka wciąż pamiętała stary stan. Odwiedzający z nowymi sesjami mogą nigdy nie zobaczyć tego błędu.

Strona mail.google.com lub accounts.google.com spowodowała zbyt wiele przekierowań (Gmail, Dysk Google)

Gdy komunikat wymienia accounts.google.com, mail.google.com lub drive.google.com (na przykład „Ta strona nie działa. Strona mail.google.com spowodowała zbyt wiele przekierowań. Usuń pliki cookie.”), pętla powstaje między stronami logowania Google a plikami cookie Twojej przeglądarki, a nie przez zepsutą witrynę. Logowanie do Google działa tylko wtedy, gdy przeglądarka zachowuje pliki cookie Google, więc wszystko, co je blokuje lub nadpisuje, każe Ci krążyć w kółko:

• Usuń tylko pliki cookie Google — otwórz chrome://settings/content/all, wyszukaj google.com, usuń jego dane i zaloguj się ponownie. Jak podaje pomoc Google, potem trzeba będzie ponownie zalogować się na konto Google w tej przeglądarce
• Zezwól Google na pliki cookie — usuń google.com z list witryn, którym nie wolno używać plików cookie (w Chrome: „Nie zezwolono na zapisywanie danych na urządzeniu”), a jeśli blokujesz pliki cookie innych firm, dodaj [*.]google.com w sekcji „Zezwolono na używanie plików cookie innych firm” (Chrome: Ustawienia → Prywatność i bezpieczeństwo → Pliki cookie innych firm)
• Wyloguj się ze wszystkich kont i zaloguj na jedno — kilka zalogowanych kont albo konto służbowe, które przekazuje logowanie na firmową stronę logowania, mogą odbijać Cię między sobą
• Wyłącz rozszerzenia do plików cookie i prywatności — rozszerzenia, które usuwają lub nadpisują pliki cookie podczas logowania, to częsta przyczyna. Chrome nie uruchamia rozszerzeń w trybie incognito, dopóki na to nie zezwolisz, więc najpierw spróbuj w oknie incognito

Poprawka 2: sprawdź konfigurację SSL/HTTPS

Błędna konfiguracja SSL to przyczyna nr 1 pętli przekierowań. Najczęstszy scenariusz to konflikt między CDN/proxy a serwerem źródłowym co do użycia HTTP lub HTTPS.

Oto co zazwyczaj idzie nie tak: CDN łączy się z serwerem po HTTP (ponieważ obsługuje terminację SSL), ale serwer wymusza przekierowanie HTTP na HTTPS. Serwer odsyła CDN na HTTPS, CDN usuwa HTTPS i ponownie wysyła HTTP — nieskończona pętla.

Uszkodzony certyfikat w tej samej konfiguracji daje inny błąd; zobacz ERR_SSL_PROTOCOL_ERROR i „Połączenie nie jest prywatne”.

• Sprawdź certyfikat SSL — Użyj „Sprawdź certyfikat SSL” od DNS Robot, aby zweryfikować, że certyfikat jest ważny, nie wygasł i obejmuje poprawną domenę
• Dopasuj protokoły — Jeśli CDN obsługuje terminację SSL, usuń przekierowanie HTTP na HTTPS na serwerze lub skonfiguruj CDN, aby łączył się z serwerem po HTTPS
• Sprawdź ustawienia wymuszania HTTPS — Jeśli masz zarówno przekierowanie na poziomie serwera (Nginx/Apache), JAK I na poziomie CDN wymuszające HTTPS, usuń jedno z nich
• Zweryfikuj nagłówek X-Forwarded-Proto — Za proxy Twój serwer powinien sprawdzać ten nagłówek zamiast surowego protokołu połączenia, aby określić, czy oryginalne żądanie było HTTPS

Poprawka 3: napraw pętlę przekierowań Cloudflare

Cloudflare jest najczęstszym źródłem błędu, bo od jego trybu szyfrowania zależy, czy łączy się z Twoim serwerem po HTTP, czy po HTTPS. Strona rozwiązywania problemów Cloudflare (zaktualizowana we wrześniu 2026 r.) wymienia pięć ustawień, które tworzą pętlę, każde w zestawieniu z tym, co robi Twój serwer źródłowy:

Typowe rozwiązanie pętli przekierowań Cloudflare: zmień tryb szyfrowania SSL/TLS z Flexible na Full lub Full (Strict). To informuje Cloudflare, aby łączył się z serwerem po HTTPS, eliminując pętlę HTTP-HTTPS.

Poprawka Cloudflare krok po kroku

• Krok 1 — Zaloguj się do panelu Cloudflare
• Krok 2 — Wybierz swoją domenę
• Krok 3 — Przejdź do SSL/TLS > Overview
• Krok 4 — Zmień tryb szyfrowania na Full (strict), jeśli serwer ma ważny certyfikat (darmowy certyfikat Cloudflare Origin CA też się liczy), lub na Full tylko wtedy, gdy certyfikat jest samopodpisany
• Krok 5 — Przejdź do SSL/TLS > Edge Certificates i sprawdź, czy Always Use HTTPS jest włączone. Jeśli serwer już przekierowuje na HTTPS, wyłącz to, aby uniknąć podwójnego przekierowania
• Krok 6 — Sprawdź Page Rules i Redirect Rules pod kątem kolidujących przekierowań URL
• Krok 7 — Wyczyść cache Cloudflare: przejdź do Caching > Configuration > Purge Everything

Poprawka 4: napraw reguły przekierowań w .htaccess (Apache)

Na serwerach Apache .htaccess to najczęstsze miejsce reguł przekierowań i najczęstsze źródło pętli przekierowań. Kolidujące reguły, zduplikowane przekierowania lub brakujące warunki mogą tworzyć pętle.

• Szukaj zduplikowanych przekierowań HTTPS — Jeśli panel hostingu (cPanel, Plesk) wymusza HTTPS, usuń ręczne przekierowanie z .htaccess
• Sprawdź warunki RewriteCond — Każda reguła RewriteRule przekierowująca powinna mieć RewriteCond zapobiegający jej uruchomieniu na URL-ach, które już spełniają warunek. Bez tego reguła uruchamia się przy każdym żądaniu, włącznie z już przekierowanym
• Uważaj na flagę [L] — Flaga [L] oznacza 'ostatnia reguła', ale tylko dla bieżącego przejścia. Jeśli w podkatalogu istnieje inny .htaccess, uruchamia się ponownie. Użyj [END] na Apache 2.4+
• Sprawdź nagłówki proxy — Za CDN użyj %{HTTP:X-Forwarded-Proto} zamiast %{HTTPS}, aby wykryć oryginalny protokół

# Correct HTTPS redirect behind Cloudflare/CDN:
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

Jeśli nie jesteś pewien, która reguła powoduje pętlę, tymczasowo zmień nazwę .htaccess na .htaccess.bak i sprawdź, czy witryna się ładuje. Jeśli tak, problem tkwi w pliku .htaccess. Włączaj reguły pojedynczo, aż znajdziesz tę problematyczną.

Poprawka 5: napraw pętlę przekierowań WordPress

Pętle przekierowań w WordPress zazwyczaj pochodzą z trzech źródeł: niezgodne URL w ustawieniach, konflikty wtyczek lub nieprawidłowe wartości w wp-config.php. Jeśli nie możesz dostać się do panelu WordPress z powodu pętli przekierowań, musisz naprawić to bezpośrednio przez bazę danych lub pliki konfiguracyjne.

Sprawdź ustawienia URL WordPress

WordPress ma dwa ustawienia URL, które muszą być zgodne: Adres WordPressa (URL) i Adres witryny (URL) w Ustawienia > Ogólne. Jeśli jedno używa http://, a drugie https://, lub jedno zawiera www., a drugie nie, otrzymasz pętlę przekierowań.

Jeśli nie możesz dostać się do panelu administracyjnego, ustaw adresy URL bezpośrednio w wp-config.php:

// Add these lines to wp-config.php (above "That's all, stop editing!"):
define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');

// If behind a reverse proxy (Cloudflare, Nginx proxy):
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

Wyłącz wtyczki, aby znaleźć konflikty

Wtyczki przekierowań i buforowania są częstymi winowajcami. Wtyczki takie jak Redirection, Yoast SEO, Really Simple SSL, WP Super Cache i W3 Total Cache mogą dodawać reguły przekierowań kolidujące z konfiguracją serwera lub CDN.

Jeśli nie możesz dostać się do panelu, wyłącz wszystkie wtyczki przez FTP lub SSH:

# Rename the plugins folder to disable all plugins at once:
cd /var/www/html/wp-content/
mv plugins plugins.bak

# If the site loads, rename it back and disable plugins one by one:
mv plugins.bak plugins
# Then rename individual plugin folders to find the culprit:
mv plugins/really-simple-ssl plugins/really-simple-ssl.bak

Jeśli wyłączenie wtyczek naprawi błąd, włączaj je pojedynczo, aby zidentyfikować kolidującą wtyczkę. Najczęściej winnymi są wtyczki SSL dodające przekierowania HTTP na HTTPS, gdy serwer lub CDN już to obsługuje.

Poprawka 6: napraw przekierowania na poziomie serwera (Nginx i Apache)

Pliki konfiguracyjne serwera mogą zawierać reguły przekierowań kolidujące z przekierowaniami na poziomie aplikacji (WordPress, .htaccess) lub ustawieniami CDN.

Nginx: szukanie konfliktów przekierowań

Pętle przekierowań w Nginx zazwyczaj występują, gdy blok serwera HTTP przekierowuje na HTTPS, ale coś w bloku HTTPS przekierowuje z powrotem na HTTP. Sprawdź konfigurację witryny:

# Correct Nginx HTTPS redirect (separate server blocks):
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    # SSL certificate configuration here
    # DO NOT add another redirect to HTTPS here
}

# If behind Cloudflare/proxy, check real protocol:
server {
    listen 80;
    server_name example.com;
    if ($http_x_forwarded_proto != 'https') {
        return 301 https://example.com$request_uri;
    }
}

Po edycji uruchom nginx -t, aby wychwycić błędy składni, a potem systemctl reload nginx, aby zastosować zmiany bez przestoju.

Apache: sprawdzanie przekierowań VirtualHost

W Apache sprawdź zarówno konfigurację VirtualHost, jak i .htaccess. Przekierowanie w konfiguracji VirtualHost plus przekierowanie w .htaccess tworzy podwójne przekierowanie, które może się zapętlić:

# Check Apache config for redirect rules:
grep -r 'Redirect\|RewriteRule' /etc/apache2/sites-enabled/
grep -r 'Redirect\|RewriteRule' /etc/httpd/conf.d/

# Check .htaccess:
cat /var/www/html/.htaccess | grep -i 'rewrite\|redirect'

Usuń zduplikowane przekierowania — zachowaj przekierowanie tylko w jednym miejscu. Najlepsza praktyka to obsługa przekierowań HTTPS w konfiguracji VirtualHost (nie w .htaccess), ponieważ reguły VirtualHost są przetwarzane raz na żądanie, podczas gdy .htaccess jest przetwarzany przy każdym żądaniu.

Poprawka 7: rozwiązywanie problemów specyficznych dla przeglądarki

Jeśli błąd pojawia się tylko w jednej przeglądarce, problem prawdopodobnie dotyczy buforowanego przekierowania lub konfliktu rozszerzenia, a nie serwera.

Chrome: czyszczenie HSTS i puli gniazd

Chrome buforuje polityki HSTS (HTTP Strict Transport Security) wymuszające HTTPS. Jeśli witryna wcześniej wysłała nagłówek HSTS, ale już nie używa poprawnie HTTPS, Chrome będzie nadal przekierowywał na HTTPS nawet po wyczyszczeniu plików cookie.

• Wyczyść cache HSTS — Przejdź do chrome://net-internals/#hsts, wpisz domenę w polu Delete domain security policies i kliknij Delete
• Opróżnij pulę gniazd — Przejdź do chrome://net-internals/#sockets i kliknij Flush socket pools, aby wyczyścić buforowane połączenia
• Wyczyść cache DNS — Przejdź do chrome://net-internals/#dns i kliknij Clear host cache (więcej sposobów w artykule jak wyczyścić pamięć DNS)
• Przetestuj w trybie incognito — Otwórz okno incognito (Ctrl+Shift+N) i spróbuj otworzyć URL. Jeśli w trybie incognito działa, a w normalnym oknie nie, przyczyną jest buforowane przekierowanie lub rozszerzenie

Poprawki dla Firefox i Safari

Firefox: Wpisz about:config w pasku adresu, wyszukaj network.http.redirection-limit i sprawdź, czy ma wartość 20 (domyślną). Niższa wartość, ustawiona ręcznie lub przez zasady firmowe, sprawia, że przekierowania kończą się błędem wcześniej. Spróbuj też usunąć dane witryny: Ustawienia > Prywatność i bezpieczeństwo > Zarządzaj danymi > wyszukaj domenę > Usuń zaznaczone.

Safari: Safari wyświetla „Safari nie może otworzyć strony” z komunikatem „Wystąpiło zbyt wiele przekierowań podczas próby otworzenia…”; konsola Web Inspector pisze „Load cannot follow more than 20 redirections”. Przejdź do Safari > Ustawienia > Prywatność > Zarządzaj danymi witryn, znajdź domenę i usuń jej dane. Jeśli pętla nadal występuje, sprawdź w oknie prywatnym: jeśli i tam się zapętla, witryna jest źle skonfigurowana.

Poprawka 8: pętle przekierowań przy logowaniu w aplikacjach webowych

W aplikacji webowej pętlę często tworzy Twój własny kod: strona wymagająca zalogowanego użytkownika przekierowuje na /login, a coś odsyła /login (lub callback logowania) prosto z powrotem. Konsola przeglądarki pokazuje to jako net::ERR_TOO_MANY_REDIRECTS przy nieudanym żądaniu.

• Strona logowania też jest chroniona — middleware uwierzytelniania działające na każdej trasie przekierowuje na /login także samą stronę /login i trasę callback. Wyłącz je ze sprawdzania
• Plik cookie sesji się nie zapisuje — plik cookie z SameSite=None musi mieć też atrybut Secure, inaczej przeglądarka go odrzuci; plik cookie ustawiony dla złej domeny nigdy nie wraca na serwer. W obu przypadkach każde żądanie nadal wygląda na niezalogowane
• Adres callback się nie zgadza — dostawca (Google, GitHub, Supabase Auth) odsyła użytkowników na callback, którego aplikacja nie obsługuje, a ta trasa znowu przekierowuje na logowanie
• HTTP kontra HTTPS za proxy — aplikacja buduje adresy przekierowań z http://, bo ignoruje X-Forwarded-Proto: pętla z Poprawki 2, tylko warstwę wyżej

// Next.js: proxy.ts (middleware.ts before Next.js 16).
// Never run the sign-in check on the sign-in pages themselves.
export const config = {
  matcher: ["/((?!login|auth/callback|_next/static|_next/image|favicon.ico).*)"],
};

Sprawdź poprawkę w Checkerze przekierowań lub poleceniem curl -IL bez logowania: zdrowy łańcuch kończy się na stronie logowania kodem 200, a nie kolejnym przekierowaniem.

Jak zapobiegać pętlom przekierowań

Po naprawieniu błędu stosuj te praktyki, aby pętle przekierowań nie powtórzyły się:

• Przekierowuj tylko w jednym miejscu — Wybierz jedną warstwę dla przekierowania HTTPS: CDN, serwer web lub aplikacja. Nigdy nie przekierowuj na kilku warstwach jednocześnie
• Używaj 302 podczas testów — Podczas debugowania używaj przekierowań 302 (tymczasowych) zamiast 301 (stałych). Przeglądarki agresywnie buforują 301, co utrudnia testowanie zmian. Przejdź na 301, gdy potwierdzisz poprawne działanie
• Zawsze testuj z curl — Po dodaniu reguły przekierowania uruchom curl -ILs https://twojastrona.com | grep -i 'HTTP/\|location:', aby zweryfikować, że łańcuch przekierowań kończy się odpowiedzią 200
• Monitoruj narzędziami — Regularnie używaj narzędzia Checker nagłówków HTTP od DNS Robot, aby sprawdzać, czy witryna zwraca czystą odpowiedź 200 bez nieoczekiwanych przekierowań
• Dokumentuj przekierowania — Prowadź rejestr wszystkich reguł przekierowań w konfiguracji serwera, .htaccess, regułach CDN i ustawieniach aplikacji. Gdy kilku członków zespołu zarządza witryną, nieudokumentowane przekierowania są przyczyną nr 1 pętli
• Czyść cache CDN po zmianach — Po modyfikacji dowolnej reguły przekierowania natychmiast wyczyść cache CDN. Stare buforowane 301 mogą utrzymywać się przez dni

Zdrowy łańcuch ma najwyżej jeden lub dwa skoki (np. HTTP → HTTPS → 200 OK). Trzy lub więcej zwykle oznacza przekierowanie, którego już nie potrzebujesz.

Wpływ pętli przekierowań na SEO

Pętle przekierowań usuwają strony z wyników wyszukiwania. Dokumentacja Google o crawlowaniu podaje, że roboty Google wykonują maksymalnie 10 przekierowań; pętla nigdy nie dociera do treści, więc Search Console zgłasza błąd przekierowania, a URL wypada z indeksu, dopóki pętla nie zostanie naprawiona.

Długie łańcuchy kosztują, nawet gdy się kończą: każdy skok to kolejne żądanie, które przeglądarka i Googlebot muszą wykonać przed załadowaniem strony, więc kieruj linki i przekierowania prosto na docelowy URL.

• Utrata indeksowania — Strony uwięzione w pętlach przekierowań nie są indeksowane i całkowicie znikają z wyników wyszukiwania
• Zmarnowany budżet crawlowania — Googlebot zużywa swój ograniczony budżet crawlowania na podążanie za przekierowaniami zamiast skanowania rzeczywistej treści
• Wolniejsze strony — Każdy skok to kolejne żądanie i kolejna podróż w obie strony, zanim załaduje się jakakolwiek treść, a skok na inny host wymaga też nowego połączenia