Komunikat „Zbyt wiele przekierowań” w przeglądarce. Skąd się bierze pętla?

Strona firmy jeszcze wczoraj działała, a dziś zamiast niej przeglądarka pokazuje szary ekran z informacją o zbyt wielu przekierowaniach. Nie widać oferty, nie działa formularz, a klient, który trafił na taki ekran, po prostu zamyka kartę. Najczęściej dzieje się to zaraz po jakiejś zmianie: włączeniu certyfikatu, przeniesieniu strony, instalacji wtyczki albo podłączeniu usługi przyspieszającej serwis.

Ta instrukcja jest przeznaczona dla właścicieli firm i osób, które samodzielnie opiekują się stroną, zwłaszcza zbudowaną na WordPressie. Nie wymaga wiedzy programistycznej, wymaga natomiast dostępu do panelu strony, do plików na serwerze i odrobiny cierpliwości.

Po lekturze czytelnik będzie umiał rozpoznać pętlę przekierowań, ustalić, czy winna jest przeglądarka, czy sama strona, prześledzić, które adresy odsyłają do siebie nawzajem, usunąć każdą z typowych przyczyn i upewnić się, że naprawa jest trwała, także w oczach Google.

Po czym rozpoznać, że strona wpadła w pętlę przekierowań?

Objaw jest zawsze ten sam: strona się nie otwiera, a przeglądarka po krótkiej chwili wyświetla komunikat o błędzie. W Chrome towarzyszy mu kod ERR_TOO_MANY_REDIRECTS. Pomoc Google opisuje go słowami „Ta strona internetowa zawiera pętlę przekierowań” i wyjaśnia, że błąd występuje wtedy, gdy strona zbyt wiele razy próbuje przekierować odwiedzającego.

Inne przeglądarki formułują to własnymi słowami, na przykład że strona nie jest poprawnie przekierowywana albo że wystąpiło zbyt wiele przekierowań. Dokładne brzmienie zależy od programu i jego wersji, ale sens pozostaje ten sam. Dla diagnozy ważniejszy od słów jest kod błędu i moment, w którym problem się pojawił.

Pętla nie zawsze obejmuje cały serwis. Zdarza się, że nie działa wyłącznie panel administracyjny, wyłącznie strona logowania, tylko wersja z przedrostkiem www albo jedna podstrona. Ten zasięg jest pierwszą wskazówką, gdzie szukać przyczyny, dlatego radzę zanotować go na samym początku.

Trzeba też odróżnić pętlę od innych awarii. Biały ekran bez żadnego komunikatu, błąd serwera z numerem 500 albo ostrzeżenie o niezabezpieczonym połączeniu to zupełnie inne problemy i wymagają innych działań. Tutaj mowa wyłącznie o sytuacji, w której przeglądarka sama przerywa wczytywanie, bo adresy odsyłają ją w kółko.

Jak działa przekierowanie i skąd bierze się pętla?

Przekierowanie to odpowiedź serwera, która zamiast treści strony podaje przeglądarce inny adres: „tej strony należy szukać tam”. Przeglądarka posłusznie otwiera wskazany adres. Tak działa na przykład przeniesienie z wersji http na https albo z adresu bez www na adres z www.

Pętla powstaje wtedy, gdy dwa polecenia sobie przeczą. Pierwsza reguła odsyła z adresu A pod adres B, a druga z adresu B z powrotem pod adres A. Przeglądarka wykonuje kilkanaście takich skoków, po czym uznaje, że do celu nie dotrze, i wyświetla błąd. Nie jest to więc usterka przeglądarki, tylko jej zabezpieczenie przed krążeniem bez końca.

Najważniejsze w całej sprawie jest to, że przekierowania na jednej stronie mogą być ustawione w kilku miejscach jednocześnie: w ustawieniach WordPressa, we wtyczce, w pliku .htaccess, w panelu hostingu oraz w usłudze pośredniczącej, takiej jak Cloudflare. Każde z tych miejsc z osobna może być ustawione rozsądnie. Pętla pojawia się, gdy dwa z nich ciągną w przeciwne strony.

Pętlę warto odróżnić od łańcucha przekierowań, czyli kilku skoków, które jednak kończą się na działającej stronie. Łańcuch spowalnia serwis, ale go nie wyłącza. Osobno opisałem, jak wykryć łańcuch przekierowań i skrócić go do jednego kroku.

Jak sprawdzić, czy winna jest przeglądarka, czy strona?

Zanim ktokolwiek zacznie zmieniać ustawienia serwera, należy wykluczyć najprostszą przyczynę. Pomoc Chrome podaje wprost, że strony czasami nie otwierają się, ponieważ pliki cookie nie działają prawidłowo, i jako pierwszy środek zaleca ich usunięcie. Dotyczy to zwłaszcza sytuacji, gdy pętla występuje tylko przy logowaniu.

Szybki test zajmuje minutę. Wystarczy otworzyć stronę w oknie incognito, w innej przeglądarce oraz w telefonie korzystającym z sieci komórkowej zamiast firmowego wifi. Jeżeli strona wszędzie tam działa, problem leży w danych zapisanych w jednej przeglądarce. Jeżeli nigdzie nie działa, przyczyna jest po stronie serwisu i czyszczenie przeglądarki niczego nie zmieni.

Usunięcie plików cookie jednej witryny w Chrome

Nie ma potrzeby kasowania wszystkich danych przeglądarki, bo oznaczałoby to wylogowanie ze wszystkich serwisów. Chrome pozwala usunąć pliki cookie tylko jednej witryny. Na komputerze wygląda to tak:

1. Po otwarciu Chrome należy kliknąć ikonę z trzema kropkami w prawym górnym rogu okna i wybrać „Ustawienia”.
2. W menu bocznym wybiera się „Prywatność i bezpieczeństwo”, a następnie „Pliki cookie innych firm”.
3. Należy kliknąć „Zobacz wszystkie dane witryn i ich uprawnienia”.
4. W polu wyszukiwania w prawym górnym rogu wpisuje się nazwę witryny, czyli adres własnej strony.
5. Obok nazwy witryny trzeba kliknąć ikonę „Usuń” i potwierdzić przyciskiem „Usuń”.
6. Na koniec należy zamknąć kartę ze stroną i otworzyć ją ponownie.

Po tej czynności przeglądarka wyloguje użytkownika z danej witryny, co jest zjawiskiem normalnym. Jeżeli strona zaczęła się otwierać, sprawa jest zamknięta. Jeżeli błąd wraca albo widzą go również inne osoby, trzeba przejść do badania samej strony.

Jak prześledzić, które adresy odsyłają do siebie nawzajem?

Naprawianie pętli na ślepo kończy się zwykle dodaniem kolejnej reguły, która tylko pogarsza sytuację. Najpierw należy zobaczyć, jakie dokładnie adresy pojawiają się w pętli. Różnica między nimi zdradza przyczynę: raz zmienia się http na https, innym razem znika i wraca www, a jeszcze innym pojawia się i znika ukośnik na końcu.

Podgląd przekierowań w przeglądarce

Chrome ma wbudowane narzędzia dla programistów, które pokazują każde żądanie wysłane do serwera. Ich interfejs bywa wyświetlany po angielsku, dlatego podaję nazwy w tej wersji.

1. W nowej karcie należy nacisnąć klawisz F12, co otwiera narzędzia dla programistów.
2. Trzeba przejść do karty „Network” i zaznaczyć opcję „Preserve log”, dzięki której lista nie czyści się przy każdym skoku.
3. W pasku adresu wpisuje się adres strony i zatwierdza klawiszem Enter.
4. Na liście pojawi się seria wierszy z kodem 301 lub 302 w kolumnie „Status”. Po kliknięciu wiersza w części „Headers” widać nagłówek Location, czyli adres, pod który serwer odsyła.
5. Należy zapisać trzy lub cztery kolejne adresy z nagłówka Location i porównać je znak po znaku.

Podgląd przekierowań z wiersza poleceń

Kto ma dostęp do terminala, uzyska ten sam obraz jednym poleceniem. Narzędzie curl, dostępne w systemach Windows, macOS i Linux, wypisuje nagłówki każdej kolejnej odpowiedzi:

curl -sIL https://example.com/

W miejsce przykładowej domeny wstawia się własny adres. W wyniku interesują dwa rodzaje wierszy: pierwszy wiersz każdej odpowiedzi z kodem 301 lub 302 oraz wiersz zaczynający się od słowa location. Jeśli te same dwa adresy powtarzają się na przemian, pętla jest potwierdzona, a jej przebieg znany. Ta metoda ma dodatkową zaletę: pomija pliki cookie i pamięć przeglądarki, więc pokazuje to, co naprawdę odpowiada serwer.

Warto wykonać ten test dla czterech wariantów adresu: z http i z https, z www i bez www. Poprawnie ustawiona strona z trzech wariantów odsyła do czwartego, wybranego jako główny, i tam odpowiada kodem 200.

Kto woli nie zajmować się tym samodzielnie, może zadzwonić pod numer 533 525 168 albo napisać na info@lukaszwudyka.pl, a ja przejmę sprawę: prześledzę całą ścieżkę przekierowań, wskażę dwie sprzeczne reguły i usunę tę, która powoduje pętlę.

Jakie są najczęstsze przyczyny pętli przekierowań?

Z praktyki wynika, że zdecydowana większość pętli sprowadza się do kilku powtarzalnych sytuacji. Po porównaniu adresów z poprzedniego kroku zwykle od razu widać, która z nich zachodzi.

• Spór o https. Adresy w pętli różnią się wyłącznie początkiem: http i https. Jedno miejsce wymusza połączenie szyfrowane, a inne uznaje, że połączenie szyfrowane nie jest, i odsyła ponownie.
• Spór o www. Adresy różnią się przedrostkiem www. Zwykle plik .htaccess albo panel hostingu kieruje na jedną wersję, a ustawienia WordPressa na drugą.
• Usługa pośrednicząca. Strona korzysta z Cloudflare lub podobnej usługi, a jej tryb szyfrowania nie pasuje do reguł na serwerze.
• Wtyczka. Pętla pojawiła się po instalacji lub aktualizacji wtyczki do przekierowań, bezpieczeństwa, pamięci podręcznej albo wymuszania https.
• Reguła wskazująca samą siebie. Ręcznie dodane przekierowanie obejmuje wzorcem także adres docelowy, na przykład po zmianie adresu podstrony tam i z powrotem.
• Dane w przeglądarce. Błąd widzi jedna osoba na jednym urządzeniu, a wszyscy pozostali otwierają stronę bez trudu.

Kolejność naprawy radzę ustalić według tego, co zmieniło się jako ostatnie. Jeżeli dzień wcześniej włączono certyfikat, należy zacząć od sporu o https. Jeżeli zainstalowano wtyczkę, od wtyczki. Cofnięcie ostatniej zmiany bywa najszybszą drogą do przywrócenia strony, a spokojne szukanie właściwego ustawienia można wtedy odłożyć na później.

Jak naprawić pętlę w ustawieniach WordPressa?

Przed jakąkolwiek zmianą w plikach lub bazie danych należy wykonać kopię: pobrać na dysk pliki wp-config.php i .htaccess oraz zrobić kopię bazy. Błąd w jednym znaku potrafi wyłączyć stronę całkowicie, a kopia pozwala wrócić do punktu wyjścia w minutę. Sposób wykonania opisałem we wpisie o tym, jak zrobić i sprawdzić kopię zapasową WordPressa.

Dwa pola z adresem strony

WordPress przechowuje adres serwisu w dwóch polach: „Adres WordPressa (URL)” oraz „Adres witryny (URL)”. Znajdują się one w panelu, w menu „Ustawienia”, w pozycji „Ogólne”. Dokumentacja WordPressa wskazuje, że oba adresy powinny zawierać początek https:// i nie powinny kończyć się ukośnikiem.

Jeżeli w tych polach wpisany jest adres bez www, a serwer odsyła na adres z www, WordPress odeśle odwiedzającego z powrotem i pętla gotowa. To samo dotyczy różnicy między http a https. Oba pola muszą więc wskazywać dokładnie ten wariant adresu, na który kieruje serwer. Po poprawieniu wartości należy kliknąć „Zapisz zmiany”.

Gdy panel jest niedostępny

Często pętla obejmuje również panel administracyjny, więc pól nie da się zmienić w zwykły sposób. Dokumentacja WordPressa opisuje wtedy wpisanie adresów bezpośrednio do pliku wp-config.php. Wykonuje się to tak:

1. Należy połączyć się z serwerem przez FTP albo otworzyć menedżer plików w panelu hostingu.
2. W głównym katalogu strony trzeba odszukać plik wp-config.php i pobrać jego kopię na dysk.
3. W pliku, powyżej wiersza z komentarzem informującym o końcu edycji, wstawia się dwa wiersze z własną domeną w miejsce przykładowej.
4. Plik zapisuje się na serwerze, po czym stronę otwiera się w oknie incognito.

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

Dokumentacja uczciwie zaznacza, że jest to wpisanie wartości na sztywno i niekoniecznie najlepsze rozwiązanie docelowe. Po dodaniu tych wierszy pól w ustawieniach ogólnych nie da się już edytować w panelu. Uważam jednak, że do przywrócenia strony do życia jest to droga najbezpieczniejsza, ponieważ nie wymaga dotykania bazy danych i daje się cofnąć usunięciem dwóch wierszy.

Opis dotyczy pojedynczej instalacji WordPressa. W sieci witryn, czyli w trybie Multisite, adresy są zapisane w bazie w kilku miejscach i według dokumentacji wymagają ręcznej zmiany w bazie. W takim przypadku odradzam eksperymenty bez świeżej kopii.

WordPress za usługą pośredniczącą

Osobny, bardzo częsty przypadek to strona, przed którą stoi pośrednik obsługujący szyfrowanie: Cloudflare, serwer równoważący ruch albo warstwa przyspieszająca u dostawcy hostingu. Odwiedzający łączy się z pośrednikiem przez https, ale pośrednik łączy się z serwerem przez zwykłe http. WordPress widzi wtedy połączenie nieszyfrowane, odsyła na https i tak bez końca.

Dokumentacja WordPressa podaje na to gotowe rozwiązanie. W pliku wp-config.php, przed wierszem wczytującym plik wp-settings.php, umieszcza się fragment, który każe WordPressowi uznać połączenie za szyfrowane, jeśli pośrednik przekazał taką informację w nagłówku:

define( 'FORCE_SSL_ADMIN', true );
if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https' ) !== false ) {
    $_SERVER['HTTPS'] = 'on';
}

Fragment ma sens wyłącznie wtedy, gdy przed stroną rzeczywiście działa pośrednik. Na zwykłym serwerze bez takiej warstwy nie należy go wstawiać, bo nie rozwiąże problemu, a utrudni późniejszą diagnozę.

Wyłączenie wtyczek bez dostępu do panelu

Gdy pętla pojawiła się po instalacji lub aktualizacji wtyczki, najprościej wyłączyć ją z poziomu plików. W katalogu wp-content/plugins należy zmienić nazwę folderu podejrzanej wtyczki, na przykład dopisując na końcu „-wylaczona”. WordPress nie znajdzie jej plików i uzna wtyczkę za nieaktywną, a jej ustawienia pozostaną w bazie.

Jeżeli nie wiadomo, która wtyczka zawiniła, można w ten sam sposób zmienić nazwę całego folderu plugins, sprawdzić, czy strona wróciła, a potem przywrócić nazwę i włączać wtyczki pojedynczo w panelu. W pierwszej kolejności podejrzane są wtyczki do przekierowań, wymuszania https, bezpieczeństwa i pamięci podręcznej. Po każdej zmianie trzeba też opróżnić pamięć podręczną strony, ponieważ potrafi ona przechowywać stare przekierowanie.

Jak znaleźć sprzeczne reguły w pliku .htaccess?

Na serwerach Apache i LiteSpeed przekierowania zapisuje się najczęściej w pliku .htaccess w głównym katalogu strony. Plik bywa edytowany przez kilka wtyczek i kilka osób, więc z czasem gromadzą się w nim reguły, o których nikt już nie pamięta. Budowę takich reguł omawiam szerzej we wpisie o tym, jak ustawić przekierowanie 301 w pliku .htaccess.

Najszybszy test polega na chwilowym wyłączeniu własnych reguł. Po pobraniu kopii pliku należy pozostawić w nim wyłącznie standardowy blok WordPressa, zawarty między wierszami # BEGIN WordPress i # END WordPress, i sprawdzić stronę w oknie incognito. Jeżeli pętla zniknęła, winna jest jedna z usuniętych reguł i trzeba je przywracać po jednej.

Typowy winowajca to reguła wymuszająca https, napisana z myślą o zwykłym serwerze, a działająca za pośrednikiem. Warunek RewriteCond %{HTTPS} off jest wtedy spełniony zawsze, bo do serwera ruch dociera przez http, więc reguła odsyła każdego bez końca. W takim układzie stosuje się wersję, która sprawdza nagłówek przekazany przez pośrednika:

RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Ten zapis zadziała tylko wtedy, gdy pośrednik rzeczywiście wysyła nagłówek X-Forwarded-Proto. Robi tak większość usług tego rodzaju, ale pewność daje wyłącznie dokumentacja dostawcy albo pytanie do pomocy technicznej hostingu.

Drugi typowy błąd to dwa osobne przekierowania o przeciwnych kierunkach: jedno dopisuje www, drugie je usuwa. Należy zostawić tylko jedno i upewnić się, że jego kierunek zgadza się z adresem wpisanym w ustawieniach WordPressa. Trzeba też zajrzeć do panelu hostingu, ponieważ wielu dostawców ma własny przełącznik wymuszania https lub przekierowania domeny, działający niezależnie od pliku.

Jak usunąć pętlę, gdy strona korzysta z Cloudflare?

Dokumentacja Cloudflare poświęca temu błędowi osobną stronę i wymienia trzy grupy przyczyn: tryb szyfrowania, ustawienia certyfikatów brzegowych oraz reguły przekierowań. Panel tej usługi jest w języku angielskim, dlatego nazwy podaję w oryginale.

Tryb szyfrowania ustawia się na stronie „SSL/TLS”, w części „Overview”. W trybie „Flexible” Cloudflare łączy się z serwerem przez http. Jeżeli serwer każde żądanie http odsyła na https, powstaje pętla. Dokumentacja wskazuje dwa wyjścia: usunięcie przekierowania na https z serwera albo zmianę trybu na „Full” lub wyższy, co wymaga certyfikatu zainstalowanego na serwerze.

Zdecydowanie radzę wybrać drugie wyjście. Tryb „Flexible” oznacza, że odcinek między usługą a serwerem pozostaje nieszyfrowany, więc dane z formularzy wędrują nim otwartym tekstem. Skoro większość firm hostingowych pozwala włączyć certyfikat jednym przyciskiem, lepiej to zrobić i przełączyć tryb na „Full (strict)”. Jak przygotować serwer, opisałem we wpisie o tym, jak przejść na https bez strat.

W trybach „Full” i „Full (strict)” pętla powstaje w odwrotnej sytuacji: gdy serwer odsyła żądania https na http. Wtedy z serwera trzeba usunąć przekierowanie na http. Podobnie działa opcja „Always Use HTTPS” na stronie „Edge Certificates”: jeśli serwer zawraca ruch na http, należy poprawić serwer albo tę opcję wyłączyć.

Trzecia grupa to sprzeczne reguły przekierowań ustawione w samej usłudze, na przykład jedna domena kieruje na drugą, a druga z powrotem na pierwszą. Dokumentacja zaleca przejrzenie reguł przekierowań oraz reguł stron pod kątem takich konfliktów. Dla WordPressa Cloudflare poleca ponadto własną wtyczkę z opcją „Automatic HTTPS rewrites”, która ogranicza liczbę takich pętli.

Opisane zasady dotyczą w tym samym stopniu innych usług pośredniczących. Nazwy opcji będą inne, ale pytanie pozostaje jedno: jakim protokołem pośrednik łączy się z serwerem i czy serwer nie próbuje tego połączenia przekierować.

Po czym poznać, że naprawa zadziałała, także w Google?

Sam fakt, że strona otworzyła się na komputerze osoby naprawiającej, niczego jeszcze nie dowodzi. Przeglądarki zapamiętują przekierowania stałe, więc mogą pokazywać stan sprzed zmiany albo odwrotnie: ukrywać błąd, który wciąż widzą inni. Naprawę potwierdza się w czterech krokach:

1. Ponowne wykonanie polecenia curl albo podglądu w karcie „Network” dla czterech wariantów adresu. Każdy powinien dojść do adresu głównego najwyżej jednym skokiem i zakończyć się kodem 200.
2. Otwarcie strony głównej, jednej podstrony, strony logowania i panelu administracyjnego w oknie incognito.
3. Otwarcie strony w telefonie korzystającym z sieci komórkowej.
4. Opróżnienie pamięci podręcznej we wtyczce, w panelu hostingu i w usłudze pośredniczącej, a następnie powtórzenie testu.

Pętla ma również skutki w wyszukiwarce. Robot Google nie może pobrać strony, która odsyła go w kółko, więc taki adres nie zostanie zindeksowany. W Google Search Console, w raporcie „Indeksowanie stron”, adresy tego rodzaju trafiają do grupy niezindeksowanych z powodem „Błąd przekierowania”. Pomoc Google wymienia pod tą nazwą cztery sytuacje, w tym zbyt długi łańcuch przekierowań oraz pętlę przekierowań.

Po usunięciu przyczyny należy otworzyć w raporcie szczegóły tego powodu i kliknąć „Sprawdź poprawkę”. Google zacznie wtedy ponownie odwiedzać wskazane adresy. Według pomocy Search Console weryfikacja zajmuje zazwyczaj do 2 tygodni, ale w niektórych przypadkach może potrwać znacznie dłużej. Postęp widać w wierszu „Weryfikacja” na stronie szczegółów problemu.

Krótka pętla, usunięta w ciągu kilku godzin, zwykle nie zostawia śladu w wynikach wyszukiwania. Im dłużej strona pozostaje niedostępna, tym większe ryzyko, że jej adresy zaczną z wyników wypadać, dlatego nie należy odkładać naprawy na spokojniejszy tydzień.

Co zrobić, gdy pętla nie znika, i jakich błędów unikać?

Jeżeli po przejściu wszystkich opisanych miejsc pętla trwa, przyczyna najpewniej leży w konfiguracji serwera, do której właściciel strony nie ma dostępu. Wtedy należy napisać do pomocy technicznej hostingu. Im dokładniejsze zgłoszenie, tym szybsza odpowiedź. Sprawdza się taka treść:

„Strona example.com wyświetla błąd ERR_TOO_MANY_REDIRECTS. Adres https://example.com/ odsyła kodem 301 na http://example.com/, a ten z powrotem na https. Plik .htaccess zawiera wyłącznie standardowy blok WordPressa, wtyczki są wyłączone. Proszę o sprawdzenie przekierowań ustawionych po stronie serwera i w panelu domeny.”

W zgłoszeniu należy oczywiście wpisać własną domenę i adresy odczytane z nagłówka Location. Dobrze jest dołączyć pełny wynik polecenia curl, bo oszczędza to pracownikowi pomocy powtarzania tych samych testów.

Na koniec lista błędów, które widuję najczęściej i które potrafią zamienić godzinną awarię w kilkudniową:

• Dopisywanie nowej reguły przekierowania zamiast usunięcia jednej z dwóch sprzecznych. Reguł ma ubywać, nie przybywać.
• Edycja plików i bazy bez kopii. Każdą zmianę należy poprzedzić zapisaniem poprzedniej wersji pliku.
• Ustawianie tego samego przekierowania w trzech miejscach „na wszelki wypadek”. Wymuszenie https i wybór wersji z www lub bez www powinny mieć jedno, znane miejsce.
• Ocenianie wyniku w zwykłym oknie przeglądarki, która pamięta stare przekierowania, zamiast w oknie incognito lub poleceniem curl.
• Pozostawianie strony na stałe w trybie „Flexible” tylko dlatego, że w nim pętla znika. To zamiana jednego kłopotu na inny, związany z bezpieczeństwem danych.
• Wprowadzanie kilku zmian naraz. Po każdej pojedynczej zmianie należy wykonać test, inaczej nie wiadomo, która pomogła.

Najczęstsze pytania

Czy pętla przekierowań oznacza, że strona została zhakowana?

W zdecydowanej większości przypadków nie. Pętla jest zazwyczaj skutkiem sprzecznych ustawień po zmianie certyfikatu, domeny, wtyczki lub usługi pośredniczącej. Niepokój powinna wzbudzić dopiero sytuacja, w której w pętli pojawiają się obce domeny albo w pliku .htaccess znajdują się reguły, których nikt z opiekunów strony nie dodawał.

Dlaczego strona działa u mnie, a klient widzi błąd?

Najczęściej decydują o tym dane zapisane w przeglądarce: pliki cookie albo zapamiętane przekierowanie stałe. Możliwe jest też, że klient wpisuje inny wariant adresu, na przykład z przedrostkiem www, i tylko ten wariant wpada w pętlę. Dlatego test należy zawsze wykonywać dla wszystkich czterech wariantów adresu.

Czy usunięcie plików cookie zawsze pomaga?

Pomaga tylko wtedy, gdy przyczyna leży w przeglądarce. Jeżeli pętla wynika z ustawień serwera, błąd wróci natychmiast i zobaczą go wszyscy odwiedzający. Proszenie klientów o czyszczenie przeglądarki nie jest więc rozwiązaniem, a jedynie testem, który pozwala ustalić, po czyjej stronie leży problem.

Nie działa tylko panel logowania WordPressa. Od czego zacząć?

Należy zacząć od usunięcia plików cookie własnej witryny, a potem porównać adresy w polach „Adres WordPressa (URL)” i „Adres witryny (URL)” z adresem, pod którym strona faktycznie się otwiera. Jeśli strona stoi za pośrednikiem, przyczyną bywa wymuszanie szyfrowanego logowania bez fragmentu rozpoznającego nagłówek od pośrednika, opisanego wyżej.

Ile przekierowań to już za dużo?

Dla odwiedzającego i dla wyszukiwarki najlepszy jest jeden skok: ze starego adresu prosto na docelowy. Dokumentacja Google podaje, że robot śledzi do 10 przeskoków, po czym rezygnuje. Przeglądarki mają własne, nieco wyższe ograniczenia, ale pętla z natury przekroczy każde z nich.

Czy pętla może dotyczyć tylko jednej podstrony?

Tak. Dzieje się tak, gdy ręcznie dodane przekierowanie kieruje ze starego adresu na nowy, a inne, wcześniejsze, z nowego na stary. Zdarza się to po kilkukrotnej zmianie adresu tej samej podstrony. Wystarczy wtedy przejrzeć listę przekierowań we wtyczce lub w pliku i usunąć regułę skierowaną w złą stronę.

Jak szybko Google zauważy, że strona znów działa?

Tego nie da się określić co do dnia, bo zależy to od tego, jak często robot odwiedza dany serwis. Przyspiesza to użycie przycisku „Sprawdź poprawkę” w raporcie „Indeksowanie stron”. Sama weryfikacja według pomocy Google trwa zazwyczaj do 2 tygodni, choć bywa dłuższa.

Czy do naprawy potrzebny jest programista?

Nie zawsze. Poprawienie dwóch pól z adresem, wyłączenie wtyczki czy zmiana trybu szyfrowania w usłudze pośredniczącej to czynności w zasięgu osoby, która na co dzień obsługuje panel strony. Pomoc specjalisty przydaje się przy rozbudowanych plikach reguł, w sieci witryn oraz wtedy, gdy przyczyna leży w konfiguracji serwera.

Brak czasu albo ochoty, żeby zająć się tym samodzielnie?

Niedziałająca strona to stres, zwłaszcza gdy czekają na nią klienci, a każda kolejna próba naprawy kończy się tym samym szarym ekranem. Mogę zająć się tym od początku do końca: sprawdzę, które adresy odsyłają do siebie nawzajem, znajdę miejsce, w którym ustawienia sobie przeczą, uporządkuję przekierowania tak, żeby każdy wariant adresu prowadził jednym skokiem na właściwą stronę, a na koniec dopilnuję, żeby Google ponownie odwiedził naprawione adresy.

Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i podać adres strony oraz krótki opis tego, co zmieniło się przed awarią. Odpowiem, co jest przyczyną i co należy zrobić, żeby strona wróciła do pracy.