ERR_TOO_MANY_REDIRECTS w WordPressie. Jak sprawdzić adresy witryny w ustawieniach?

Strona na WordPressie przestaje się otwierać, a przeglądarka zamiast treści pokazuje komunikat o zbyt wielu przekierowaniach z kodem ERR_TOO_MANY_REDIRECTS. Najczęściej dzieje się to tuż po zmianie adresu witryny, po włączeniu certyfikatu SSL, po przeniesieniu strony na inny serwer albo po podłączeniu usługi pośredniczącej, takiej jak Cloudflare. Witryna nie zniknęła i nie została uszkodzona. Serwer i WordPress odsyłają przeglądarkę między dwoma adresami tak długo, aż ta przerywa połączenie.

W bardzo wielu przypadkach źródłem kłopotu są dwa pola w ustawieniach WordPressa: „Adres WordPressa (URL)” oraz „Adres witryny (URL)”. Wystarczy, że jedno z nich zaczyna się od http, a drugie od https, albo że jedno zawiera przedrostek www, a serwer wymusza wersję bez niego, i pętla gotowa.

Ten wpis jest instrukcją dla właścicieli firm, którzy sami opiekują się swoją stroną. Po lekturze będzie wiadomo, jak sprawdzić oba adresy na cztery sposoby (także wtedy, gdy kokpit jest niedostępny), jak je poprawić, jak rozpoznać pozostałe przyczyny pętli i po czym poznać, że naprawa się udała.

Co oznacza komunikat ERR_TOO_MANY_REDIRECTS i po czym rozpoznać pętlę?

Przekierowanie to polecenie, które serwer wysyła przeglądarce: „tej strony należy szukać pod innym adresem”. Pojedyncze przekierowanie jest czymś zwyczajnym, na przykład z wersji http na https. Kłopot zaczyna się wtedy, gdy adres docelowy odsyła z powrotem do adresu wyjściowego. Przeglądarka wykonuje kilkanaście takich skoków, po czym uznaje, że dalsze próby nie mają sensu, i pokazuje błąd.

Chrome i przeglądarki zbudowane na tym samym silniku wyświetlają kod ERR_TOO_MANY_REDIRECTS razem z informacją, że witryna przekierowała zbyt wiele razy, oraz podpowiedzią dotyczącą usunięcia plików cookie. Inne przeglądarki opisują to samo zjawisko własnymi słowami, zwykle jako nieprawidłowe przekierowanie albo zbyt wiele przekierowań. Znaczenie jest zawsze takie samo.

Pętlę odróżnia od innych awarii kilka cech. Błąd pojawia się natychmiast, bez długiego oczekiwania. Często dotyczy całej witryny albo całego kokpitu, a nie pojedynczego wpisu. Adres w pasku przeglądarki potrafi się zmienić w trakcie ładowania, na przykład z wersji z www na wersję bez www. Wreszcie błąd zwykle pojawia się zaraz po jakiejś zmianie w konfiguracji, co jest najlepszą wskazówką, gdzie szukać.

Przed rozpoczęciem pracy radzę zapisać na kartce trzy rzeczy: pod jakim dokładnie adresem strona ma działać (z https czy bez, z www czy bez), co zmieniano w ostatnich dniach oraz czy błąd widać na stronie głównej, w kokpicie, czy w obu miejscach. Te trzy odpowiedzi skracają diagnozę o połowę.

Jak wykluczyć przeglądarkę, zanim zacznie się zmieniać ustawienia?

Przeglądarka zapamiętuje pliki cookie i część przekierowań. Zdarza się więc, że konfiguracja została już poprawiona, a błąd nadal się wyświetla, bo przeglądarka korzysta ze starych danych. Bywa też odwrotnie: strona działa u wszystkich poza jedną osobą. Dlatego pierwszy test zawsze dotyczy przeglądarki, a nie serwera.

Najszybciej jest otworzyć stronę w oknie incognito albo w zupełnie innej przeglądarce, najlepiej także na telefonie korzystającym z sieci komórkowej. Jeśli w oknie incognito witryna otwiera się poprawnie, problem leży w zapisanych plikach cookie i wystarczy je usunąć dla tej jednej domeny. Nie trzeba usuwać danych wszystkich stron, co skończyłoby się wylogowaniem z poczty, banku i pozostałych serwisów.

W Chrome na komputerze usunięcie plików cookie jednej witryny przebiega według oficjalnej pomocy Google w następujący sposób:

1. W prawym górnym rogu okna Chrome należy kliknąć ikonę „Więcej”, a następnie pozycję „Ustawienia”.
2. W menu po lewej stronie trzeba wybrać „Prywatność i bezpieczeństwo”, a potem „Pliki cookie innych firm”.
3. Następnie należy kliknąć „Zobacz wszystkie dane witryn i ich uprawnienia”.
4. W polu wyszukiwania w prawym górnym rogu wpisuje się nazwę domeny, której dotyczy błąd.
5. Po prawej stronie znalezionej pozycji należy kliknąć „Usuń” i potwierdzić ponownym kliknięciem „Usuń”.
6. Na koniec trzeba zamknąć kartę z błędem i otworzyć stronę w nowej karcie.

Jeżeli błąd widać także w oknie incognito, w innej przeglądarce i na innym urządzeniu, przyczyna leży po stronie witryny lub serwera. Wtedy dalsze czyszczenie przeglądarki nic nie zmieni i należy przejść do sprawdzenia adresów w WordPressie.

Czym różnią się „Adres WordPressa (URL)” i „Adres witryny (URL)”?

W kokpicie, na ekranie „Ustawienia” i dalej „Ogólne”, znajdują się dwa pola, które decydują o tym, pod jakim adresem WordPress uważa się za zainstalowany. Dokumentacja WordPressa opisuje je jednoznacznie. „Adres witryny (URL)” to adres, który odwiedzający wpisują w przeglądarce, żeby zobaczyć stronę. „Adres WordPressa (URL)” to adres, pod którym znajdują się pliki samego WordPressa.

W typowej instalacji oba pola mają identyczną wartość. Różnią się wyłącznie wtedy, gdy pliki WordPressa celowo umieszczono w osobnym podkatalogu, a strona ma się otwierać pod adresem głównym domeny. Jeśli nikt świadomie nie przygotowywał takiej konfiguracji, różnica między polami jest błędem.

W bazie danych te same ustawienia noszą nazwy home (adres witryny) oraz siteurl (adres WordPressa), a w pliku konfiguracyjnym odpowiadają im stałe WP_HOME i WP_SITEURL. Dobrze znać wszystkie trzy zestawy nazw, bo w zależności od sposobu naprawy spotyka się każdy z nich.

Dokumentacja podaje dwie zasady zapisu, których naruszenie najczęściej kończy się pętlą. Adres ma zaczynać się od protokołu, czyli od https://, oraz nie może kończyć się ukośnikiem. Poprawny zapis to na przykład https://example.com, a błędny to https://example.com/ albo samo example.com.

Jakie rozbieżności powodują pętlę?

Pierwsza to niezgodność protokołu. Serwer albo usługa pośrednicząca wymusza https, a w WordPressie zapisano adres z http. WordPress odsyła przeglądarkę na http, serwer z powrotem na https i tak bez końca.

Druga to niezgodność przedrostka www. W panelu hostingu albo w pliku .htaccess ustawiono przekierowanie na wersję z www, a w WordPressie widnieje adres bez www, lub odwrotnie. Trzecia to zwykła literówka, zbędna spacja, ukośnik na końcu albo adres starej domeny pozostawiony po przenosinach. Czwarta to dwa pola o różnych wartościach w instalacji, która nie korzysta z osobnego podkatalogu.

Jak sprawdzić adresy witryny, gdy kokpit jeszcze działa?

Zdarza się, że pętla dotyczy tylko części publicznej, a do kokpitu nadal można się zalogować. To najwygodniejsza sytuacja, bo poprawkę wykonuje się w zwykłym formularzu. Zanim cokolwiek zostanie zmienione, radzę przygotować aktualną kopię bazy danych. Sposób jej wykonania i sprawdzenia opisałem we wpisie o tym, jak powinna wyglądać kopia zapasowa WordPressa, która naprawdę działa.

1. Po zalogowaniu do kokpitu należy przejść do menu „Ustawienia” i wybrać pozycję „Ogólne”.
2. Trzeba odczytać i przepisać do notatnika obie wartości: „Adres WordPressa (URL)” oraz „Adres witryny (URL)”. Notatka przyda się, gdyby zmiana wymagała cofnięcia.
3. Oba adresy porównuje się znak po znaku z adresem, pod którym strona ma działać. Sprawdzenia wymagają: protokół, przedrostek www, pisownia domeny i brak ukośnika na końcu.
4. Jeśli któryś adres jest błędny, należy go poprawić w polu. W zwykłej instalacji oba pola otrzymują tę samą wartość.
5. Na dole ekranu trzeba kliknąć „Zapisz zmiany”.
6. WordPress po zmianie adresu zwykle wylogowuje użytkownika. Należy zalogować się ponownie pod nowym adresem i otworzyć stronę główną w oknie incognito.

Uwaga na jedną pułapkę. Błędna wartość zapisana w tych polach odcina dostęp do kokpitu w tej samej sekundzie, w której zostanie zapisana. Dlatego adres przed kliknięciem „Zapisz zmiany” należy przeczytać dwa razy. Gdyby mimo to doszło do pomyłki, dostęp przywracają metody opisane w następnej części.

Kto woli nie zajmować się tym samodzielnie, może zadzwonić pod numer 533 525 168 albo napisać na info@lukaszwudyka.pl. Przejmę sprawę: sprawdzę oba adresy w ustawieniach, bazie i pliku konfiguracyjnym, znajdę miejsce, w którym przekierowania się zapętlają, i przywrócę działanie strony.

Jak sprawdzić i poprawić adresy, gdy kokpit jest niedostępny?

Gdy pętla obejmuje także stronę logowania, formularz w kokpicie jest poza zasięgiem. Dokumentacja WordPressa opisuje kilka dróg naprawy bez kokpitu. Poniżej omawiam trzy, które uważam za najbezpieczniejsze dla osoby bez doświadczenia programistycznego, w kolejności od najprostszej.

Wpisanie adresów w pliku wp-config.php

Plik wp-config.php leży w głównym katalogu WordPressa na serwerze. Dostęp do niego daje menedżer plików w panelu hostingu albo program FTP. Przed edycją należy pobrać kopię pliku na komputer, żeby w razie pomyłki wgrać ją z powrotem.

Do pliku dopisuje się dwa wiersze, powyżej komentarza informującego o końcu części przeznaczonej do edycji:

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

W miejsce example.com wstawia się własną domenę, dokładnie w tej postaci, w jakiej strona ma być dostępna. Po zapisaniu pliku WordPress zaczyna korzystać z tych wartości i pomija to, co zapisano w bazie danych. To rozwiązanie działa od razu i można je cofnąć przez usunięcie obu wierszy.

Ma ono jeden skutek uboczny, o którym trzeba wiedzieć: pola adresów na ekranie „Ogólne” stają się wyszarzone i nie da się ich zmienić w kokpicie, dopóki wiersze pozostają w pliku. Dla wielu firm jest to zaleta, bo nikt przypadkiem nie zmieni adresu.

Poprawienie adresów w bazie danych przez phpMyAdmin

Drugi sposób polega na zmianie wartości bezpośrednio w bazie. Jest równie skuteczny, lecz wymaga większej ostrożności, ponieważ pomyłka w innym wierszu tabeli potrafi wywołać nowe kłopoty. Dokumentacja WordPressa zaczyna opis tej metody od wykonania kopii bazy i przechowania jej poza serwerem. Popieram to w pełni.

1. W panelu hostingu należy otworzyć narzędzie phpMyAdmin i z listy po lewej stronie wybrać bazę danych używaną przez WordPressa. Jej nazwę zawiera wiersz DB_NAME w pliku wp-config.php.
2. Na liście tabel trzeba odszukać tabelę opcji. Domyślnie nazywa się wp_options, ale przedrostek bywa inny, na przykład abc_options.
3. Po otwarciu tabeli w widoku „Przeglądaj” należy znaleźć wiersz, w którym kolumna option_name ma wartość siteurl. Zwykle jest to jeden z pierwszych wierszy.
4. Przy tym wierszu trzeba kliknąć „Edytuj”, w polu option_value wpisać poprawny adres i zatwierdzić przyciskiem „Wykonaj”.
5. Te same czynności powtarza się dla wiersza home. Jeśli nie widać go na pierwszej stronie wyników, należy przejść na kolejną stronę albo skorzystać z wyszukiwania w tabeli.
6. Po zapisaniu obu wierszy trzeba otworzyć witrynę w oknie incognito.

Zmieniane są wyłącznie te dwa wiersze. Nie należy przy okazji poprawiać innych wartości ani uruchamiać w phpMyAdmin zapytań zamieniających stary adres na nowy w całej bazie. Część danych jest zapisana w formie, która przechowuje długość tekstu, i ręczna zamiana je uszkadza.

Polecenia WP-CLI dla osób z dostępem do konsoli

Jeżeli hosting udostępnia połączenie SSH oraz narzędzie WP-CLI, obie wartości odczytuje się i zmienia kilkoma poleceniami wydanymi w katalogu WordPressa. Odczyt:

wp option get home
wp option get siteurl

Zmiana, zgodnie z dokumentacją WordPressa:

wp option update home 'https://example.com'
wp option update siteurl 'https://example.com'

Dokumentacja wspomina jeszcze o stałej RELOCATE oraz o tymczasowym kodzie w pliku motywu. Obie metody wymagają usunięcia dopisanych wierszy zaraz po naprawie, a pozostawienie stałej RELOCATE dokumentacja wprost nazywa zagrożeniem dla bezpieczeństwa. Z tego powodu nie polecam ich osobom, które robią to pierwszy raz.

Co zrobić, gdy pola adresów są wyszarzone albo zmiana nie działa?

Wyszarzone pola na ekranie „Ogólne” oznaczają, że adresy zostały narzucone w pliku wp-config.php stałymi WP_HOME i WP_SITEURL. W takiej sytuacji wartość w bazie danych nie ma znaczenia i poprawianie jej przez phpMyAdmin niczego nie zmieni. Należy otworzyć plik konfiguracyjny i poprawić adres właśnie tam.

Zdarza się też sytuacja odwrotna: adres poprawiono w bazie, a strona nadal zachowuje się po staremu. Wtedy trzeba sprawdzić, czy w pliku konfiguracyjnym nie ma starych stałych z poprzednim adresem. To częsta pozostałość po przenosinach strony między serwerami albo po kopiowaniu wersji testowej.

Trzecia możliwość to pamięć podręczna. Wtyczka przyspieszająca stronę, mechanizm po stronie serwera albo usługa pośrednicząca potrafią przez pewien czas podawać zapamiętane przekierowanie. Po każdej zmianie adresów należy opróżnić wszystkie warstwy pamięci podręcznej, do których jest dostęp: we wtyczce, w panelu hostingu i w panelu usługi pośredniczącej.

Osobną sprawą jest sieć witryn, czyli WordPress w trybie multisite. Dokumentacja zastrzega, że opisane wyżej sposoby dotyczą pojedynczej instalacji. W sieci witryn adresy są zapisane w kilku tabelach jednocześnie i zmianę należy powierzyć osobie, która zna tę konfigurację.

Jakie inne przyczyny dają ten sam komunikat, gdy adresy są poprawne?

Jeżeli oba adresy są identyczne, zapisane bez błędów i zgodne z adresem, pod którym strona ma działać, a pętla trwa, przyczyny należy szukać w jednym z czterech miejsc. Każde z nich wysyła własne przekierowania i każde może wejść w konflikt z pozostałymi.

Reguły w pliku .htaccess

Na serwerach Apache i LiteSpeed plik .htaccess w głównym katalogu witryny zawiera reguły przekierowań. Pętla powstaje, gdy dwie reguły sobie przeczą, na przykład jedna wymusza wersję z www, a druga wersję bez www, albo gdy reguła wymuszająca https została wpisana dwukrotnie w różny sposób. Zasady pisania takich reguł omówiłem osobno we wpisie o tym, jak działa przekierowanie 301 w pliku .htaccess.

Bezpieczny test polega na zmianie nazwy pliku na .htaccess-kopia i otwarciu strony głównej w oknie incognito. Jeśli strona główna się otwiera, winne były reguły w pliku. Podstrony mogą w tym czasie zwracać błąd 404, co jest normalne. Wystarczy zalogować się do kokpitu, przejść do „Ustawienia”, potem „Bezpośrednie odnośniki” i kliknąć „Zapisz zmiany”, a WordPress utworzy nowy plik z podstawowymi regułami. Własne przekierowania przenosi się ze starej kopii pojedynczo, sprawdzając stronę po każdym z nich.

Wtyczki wymuszające https albo zarządzające przekierowaniami

Wtyczki do obsługi certyfikatu, wtyczki przekierowań, wtyczki bezpieczeństwa i wtyczki pamięci podręcznej dopisują własne reguły. Dwie takie wtyczki naraz albo wtyczka i reguła serwera wykonujące to samo zadanie to typowe źródło pętli.

Gdy kokpit działa, wtyczki wyłącza się pojedynczo na ekranie „Wtyczki” i po każdej sprawdza stronę. Gdy kokpit jest niedostępny, przez FTP lub menedżer plików zmienia się nazwę katalogu podejrzanej wtyczki w folderze wp-content/plugins, na przykład przez dopisanie na końcu słowa -off. WordPress uznaje wtedy wtyczkę za nieaktywną, a jej ustawienia pozostają w bazie. Po znalezieniu winnej wtyczki katalogowi przywraca się pierwotną nazwę i zmienia jej konfigurację albo rezygnuje z niej.

Cloudflare lub inna usługa pośrednicząca

Jeśli ruch do strony przechodzi przez Cloudflare, najpierw należy sprawdzić tryb szyfrowania w sekcji „SSL/TLS”. Dokumentacja Cloudflare opisuje to wprost. W trybie „Flexible” usługa łączy się z serwerem przez http. Gdy serwer albo WordPress każde połączenie http przekierowuje na https, powstaje pętla. Rozwiązaniem jest zmiana trybu na „Full” lub „Full (strict)”, o ile na serwerze działa certyfikat, albo usunięcie przekierowania po stronie serwera.

W trybach „Full” i „Full (strict)” pętla powstaje w sytuacji odwrotnej, czyli wtedy, gdy serwer przekierowuje połączenia https na http. Według tej samej dokumentacji źródłem bywają także opcja „Always Use HTTPS” oraz HSTS na stronie „Edge Certificates”, a także sprzeczne reguły przekierowań ustawione w panelu usługi.

Osobny przypadek to serwer pośredniczący, który sam obsługuje szyfrowanie, a do WordPressa przekazuje ruch przez http. WordPress nie wie wtedy, że odwiedzający korzysta z https, i próbuje go tam przekierować. Dokumentacja WordPressa podaje na to fragment do pliku wp-config.php, który uczy WordPressa rozpoznawania nagłówka przekazywanego przez serwer pośredniczący:

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

Fragment umieszcza się powyżej komentarza kończącego część do edycji. Przed jego dodaniem radzę zapytać dział pomocy hostingu, czy serwer rzeczywiście działa w takim układzie, ponieważ na zwykłym hostingu ten kod nie jest potrzebny.

Certyfikat SSL i przekierowanie ustawione w panelu hostingu

Wiele paneli hostingowych ma własny przełącznik wymuszający https albo wybraną wersję domeny. Jeśli jest włączony, a w WordPressie pozostał adres z http, efekt jest taki sam jak przy sprzecznych regułach. Należy ustalić jedną wersję adresu i ustawić ją spójnie we wszystkich miejscach. Cały proces zmiany protokołu, razem z kolejnością czynności, opisałem we wpisie o tym, jak przejść na https bez strat.

Jak ustalić, w którym miejscu krąży przekierowanie?

Zamiast zgadywać, można zobaczyć cały łańcuch skoków. W Chrome służą do tego narzędzia dla deweloperów, otwierane klawiszem F12. Na karcie pokazującej ruch sieciowy, po ponownym wczytaniu strony, widać kolejne żądania z kodami 301 lub 302 oraz adres, na który każde z nich odsyła. Wystarczy porównać dwa sąsiednie wiersze, żeby zobaczyć, czym różnią się adresy.

Osoby z dostępem do konsoli mogą użyć polecenia, które wypisuje nagłówki odpowiedzi serwera:

curl -I https://example.com

W odpowiedzi należy odszukać wiersz zaczynający się od słowa location. Wskazuje on adres, na który serwer odsyła. To samo polecenie powtarza się dla tego adresu. Jeśli po dwóch lub trzech krokach wraca adres wyjściowy, pętla jest potwierdzona, a różnica między adresami pokazuje jej rodzaj.

Odczytanie wyniku jest proste. Gdy adresy różnią się tylko protokołem, konflikt dotyczy https i należy sprawdzić adresy w WordPressie, tryb szyfrowania w usłudze pośredniczącej oraz przełącznik w panelu hostingu. Gdy różnią się przedrostkiem www, konflikt leży między adresem w WordPressie a regułą w pliku .htaccess lub w panelu. Gdy w łańcuchu pojawia się adres wp-login.php, pętla dotyczy logowania, a jej przerwanie opisałem we wpisie o tym, dlaczego logowanie do WordPressa wraca do formularza.

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

Jedno udane otwarcie strony głównej to za mało. Naprawę uznaję za zakończoną dopiero wtedy, gdy witryna przejdzie krótki test we wszystkich wariantach adresu. Każdy z nich powinien po najwyżej jednym lub dwóch skokach doprowadzić do tej samej, docelowej wersji.

• Adres z http i bez www prowadzi do wersji docelowej.
• Adres z http i z www prowadzi do wersji docelowej.
• Adres z https i bez www otwiera się albo prowadzi do wersji docelowej.
• Adres z https i z www otwiera się albo prowadzi do wersji docelowej.
• Strona logowania i kokpit otwierają się, a po zalogowaniu nie następuje powrót do formularza.
• Dowolny wpis, dowolna podstrona i formularz kontaktowy działają tak jak przed awarią.

Test należy wykonać w oknie incognito oraz na telefonie korzystającym z sieci komórkowej, żeby wykluczyć wpływ zapamiętanych danych. Po zalogowaniu do kokpitu radzę jeszcze raz otworzyć ekran „Ogólne” i upewnić się, że oba pola pokazują ten sam, poprawny adres.

Jeżeli strona jest dodana do Google Search Console, po kilku dniach dobrze jest zajrzeć do raportu dotyczącego indeksowania stron. Adresy, na których robot Google trafił na pętlę, są tam oznaczane jako błąd przekierowania. Po naprawie ich liczba powinna stopniowo spadać.

Co zrobić, gdy pętla nie ustępuje mimo poprawnych adresów?

Wtedy trzeba wrócić do diagnozy i wyłączać kolejne warstwy pojedynczo, za każdym razem sprawdzając łańcuch przekierowań. Kolejność, którą stosuję, jest następująca: najpierw opróżnienie pamięci podręcznej na wszystkich poziomach, potem chwilowe wstrzymanie usługi pośredniczącej, następnie test bez pliku .htaccess, a na końcu wyłączenie wszystkich wtyczek przez zmianę nazwy folderu plugins.

Każdą zmianę wprowadza się osobno i po każdej sprawdza wynik. Zmiana trzech rzeczy naraz może usunąć błąd, ale nie pozwala ustalić przyczyny, więc problem wróci przy najbliższej aktualizacji lub odnowieniu certyfikatu.

Jeśli po wyłączeniu wszystkich tych warstw pętla trwa, przekierowanie ustawiono na poziomie serwera, do którego klient hostingu nie ma dostępu. Wtedy należy napisać do działu pomocy. Zgłoszenie warto sformułować konkretnie, na przykład tak: „Domena example.com zwraca błąd ERR_TOO_MANY_REDIRECTS. Adresy w WordPressie (home i siteurl) są ustawione na https://example.com. Plik .htaccess zawiera wyłącznie domyślne reguły WordPressa, a wtyczki są wyłączone. Proszę o sprawdzenie przekierowań ustawionych w konfiguracji serwera i w panelu dla tej domeny.”

Jakich błędów unikać przy zmianie adresów witryny?

Najpoważniejszy błąd to praca bez kopii. Zmiana dwóch wierszy w bazie trwa minutę, ale pomyłka w innym miejscu tabeli bywa trudna do odnalezienia. Kopia bazy i kopia pliku wp-config.php wykonane tuż przed zmianą pozwalają wrócić do punktu wyjścia w kilka minut.

Drugi błąd to ukośnik na końcu adresu albo brak protokołu na początku. Trzeci to ustawienie jednego adresu z www, a drugiego bez. Czwarty to pozostawienie w pliku konfiguracyjnym stałej RELOCATE albo tymczasowego kodu w pliku motywu po zakończonej naprawie.

Piąty błąd dotyczy przenosin na nową domenę. Poprawienie dwóch pól przywraca działanie strony, lecz w treści wpisów, w ustawieniach motywu i wtyczek nadal pozostają odnośniki do starego adresu. Do ich zamiany służą narzędzia, które poprawnie obsługują dane zapisane w bazie, na przykład polecenie wp search-replace z pominięciem kolumny guid. Dokumentacja WordPressa podkreśla, że wartości w tej kolumnie nie wolno zmieniać, ponieważ czytniki kanałów rozpoznają po niej wpisy już wyświetlone.

Szósty błąd to włączanie kilku mechanizmów wymuszających https jednocześnie: we wtyczce, w pliku .htaccess, w panelu hostingu i w usłudze pośredniczącej. Wystarczy jeden, dobrze ustawiony. Im mniej miejsc, w których zapisano przekierowanie, tym mniejsze ryzyko, że kiedyś zaczną sobie przeczyć.

Najczęstsze pytania

Czy pętla przekierowań szkodzi widoczności strony w Google?

Krótka awaria zwykle nie zostawia trwałych śladów. Jeśli jednak pętla trwa wiele dni, robot Google nie może pobrać stron, oznacza je jako błąd przekierowania i z czasem może przestać je pokazywać w wynikach. Dlatego naprawy nie należy odkładać, a po jej wykonaniu dobrze jest sprawdzić raporty w Google Search Console.

Czy „Adres WordPressa (URL)” i „Adres witryny (URL)” zawsze muszą być takie same?

W typowej instalacji tak. Różne wartości są poprawne tylko wtedy, gdy pliki WordPressa celowo umieszczono w osobnym podkatalogu, a strona ma być dostępna pod adresem głównym domeny. Taka konfiguracja wymaga dodatkowych zmian w plikach na serwerze, więc sama różnica w polach, bez tych zmian, prowadzi do błędów.

Dlaczego strona działa na telefonie, a na komputerze nadal widać błąd?

Najczęściej przeglądarka na komputerze przechowuje stare pliki cookie albo zapamiętane przekierowanie. Należy usunąć dane tej jednej witryny w ustawieniach przeglądarki i otworzyć stronę w nowej karcie. Jeśli to nie pomaga, warto sprawdzić, czy oba urządzenia otwierają dokładnie ten sam wariant adresu.

Czy wpisanie adresów w pliku wp-config.php można zostawić na stałe?

Tak, stałe WP_HOME i WP_SITEURL mogą pozostać w pliku bez ograniczeń czasowych. Trzeba tylko pamiętać, że od tej chwili adresu nie da się zmienić w kokpicie, a przy przenosinach strony na inną domenę należy poprawić go właśnie w tym pliku. Na stałe nie wolno natomiast zostawiać stałej RELOCATE.

Błąd dotyczy tylko kokpitu, a strona publiczna działa. Co to oznacza?

Taki obraz wskazuje na konflikt związany z szyfrowaniem strony logowania. Zwykle chodzi o wymuszanie https dla kokpitu przy serwerze pośredniczącym, który przekazuje ruch przez http, albo o wtyczkę zmieniającą adres logowania. W pierwszej kolejności należy sprawdzić tryb szyfrowania w usłudze pośredniczącej oraz zawartość pliku konfiguracyjnego.

Czy usunięcie pliku .htaccess jest bezpieczne?

Bezpieczniejsza od usunięcia jest zmiana nazwy pliku, bo pozwala wrócić do poprzedniego stanu jednym ruchem. WordPress odtwarza podstawowe reguły po kliknięciu „Zapisz zmiany” na ekranie „Bezpośrednie odnośniki”. Własne przekierowania i reguły dopisane przez wtyczki trzeba jednak przenieść ze starej kopii ręcznie.

Ile czasu po zmianie trybu szyfrowania w Cloudflare trzeba czekać na efekt?

Zmiana ustawień zwykle zaczyna działać po krótkiej chwili, lecz przeglądarka może jeszcze przez pewien czas pokazywać zapamiętany błąd. Dlatego wynik należy sprawdzać w oknie incognito, a w panelu usługi dodatkowo opróżnić pamięć podręczną. Jeśli po kilkunastu minutach nic się nie zmienia, przyczyna leży w innym miejscu.

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

Pętla przekierowań potrafi zatrzymać stronę w najmniej odpowiednim momencie, a szukanie przyczyny w kilku panelach naraz nie każdemu odpowiada. Chętnie wezmę to na siebie. Sprawdzę adresy witryny w ustawieniach, w bazie danych i w pliku konfiguracyjnym, prześledzę cały łańcuch przekierowań, uporządkuję reguły na serwerze, we wtyczkach i w usłudze pośredniczącej, a na koniec przetestuję wszystkie warianty adresu i opiszę prostymi słowami, co było przyczyną.

Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i podać adres strony oraz krótki opis tego, co zmieniano przed awarią. Resztą zajmę się od początku do końca.