Migracja WordPress potrafi wyglądać na zakończoną sukcesem… dopóki nie otworzysz strony z innej sieci, nie wejdziesz w panel albo nie sprawdzisz kilku podstron. Nagle pojawia się „Zbyt wiele przekierowań”, kłódka w przeglądarce znika, a w konsoli lecą ostrzeżenia o niebezpiecznych zasobach.
To normalne: po migracji zmienia się otoczenie serwera, sposób wydawania certyfikatu, cache, a czasem nawet drobiazgi typu końcowy slash w adresie czy nagłówki z proxy. WordPress, wtyczki i przeglądarka potrafią wtedy „przeciągać linę” o to, czy strona ma być http czy https, z www czy bez, i którędy ma prowadzić 301.
W tym poradniku znajdziesz najczęstsze problemy po migracji WordPress i dowiesz się, jak je diagnozować metodą „krok po kroku”. Skupimy się na trzech klasykach: pętle przekierowań, mixed content oraz błędy SSL, ale nie zabraknie też rzeczy, które wychodzą „przy okazji”: 404 po zmianie permalinków, problemy z logowaniem, 500 po zmianie PHP, a nawet spadek wydajności po przeprowadzce.
Migracja WordPress: po czym poznasz, że coś jest nie tak
Najbardziej mylące po migracji jest to, że strona „działa” u Ciebie, ale nie działa u klientów, w Google albo na telefonie. Pierwszy sygnał ostrzegawczy to rozjazd zależny od środowiska: w jednej przeglądarce logowanie działa, w innej wraca do formularza; przez Wi-Fi jest ok, na LTE kręci się w nieskończoność.
Drugi typ objawów jest czytelny od razu: komunikat o zbyt wielu przekierowaniach, brak kłódki przy adresie, ostrzeżenie o „niezabezpieczonej stronie” lub czerwone błędy zasobów w konsoli. To często nie jest jeden błąd, tylko cały łańcuch: najpierw 301, potem wtyczka wymusza https, potem proxy zmienia schemat, a na końcu WordPress dorzuca kolejne przekierowanie, bo „adres witryny” mu się nie zgadza.
Trzeci typ to objawy „miękkie”: strona ładuje się wolniej niż przed przeprowadzką, panel reaguje ospale, czasem wyskakuje 503 w godzinach ruchu. Migracja to moment, w którym wychodzą ograniczenia zasobów i różnice w konfiguracji. Warto mieć z tyłu głowy, że w praktyce dwa hostingi o podobnej cenie potrafią zachowywać się inaczej – dlatego ranking hostingów WordPress może być przydatny, kiedy próbujesz zrozumieć, czy problem wynika z ustawień, czy z realnych limitów po stronie serwera.
Jeśli migracja była „między hostingami”, dobrze jest pamiętać o dwóch rzeczach: DNS potrafi trzymać stare IP dłużej, niż się wydaje, a cache po drodze może pokazywać starą wersję strony. Zanim zaczniesz cokolwiek zmieniać, dopnij sobie jedno: upewnij się, że testujesz nowy serwer (o tym w kolejnej sekcji).
Zanim zaczniesz naprawiać: szybka diagnostyka
Najkrótsza droga do sensownej naprawy to odtworzenie problemu i zebranie faktów: kto przekierowuje, na jaki adres i dlaczego. Zacznij od prostego testu: otwórz stronę w trybie incognito i na telefonie w sieci komórkowej. Jeśli błąd pojawia się tylko czasem, to często nie WordPress, tylko cache, DNS albo węzeł pośredni.
Potem sprawdź łańcuch przekierowań. Najwygodniej w przeglądarce: DevTools → Network → zaznacz „Preserve log” i odśwież stronę. Zobaczysz po kolei odpowiedzi 301/302 i adresy docelowe. Jeżeli w kółko przeskakujesz między http i https albo między wersją z www i bez www, masz klasyczną pętlę.
Równolegle sprawdź ustawienia WordPress: w panelu (Ustawienia → Ogólne) porównaj „Adres WordPress (URL)” i „Adres witryny (URL)”. Jeżeli po migracji zmieniała się domena albo przechodziłeś na HTTPS, te pola są pierwszym miejscem, gdzie robi się bałagan. Gdy nie masz dostępu do panelu, sprawdź wartości w bazie danych w tabeli wp_options: klucze siteurl i home.
Trzecia rzecz to warstwa serwera i pośredników. Jeśli korzystasz z proxy, CDN albo ochrony typu WAF, pamiętaj, że to one czasem „wymyślają” przekierowania albo zmieniają schemat żądania. W praktyce warto na czas diagnozy wyłączyć wszelkie wtyczki od SSL/redirectów, a cache po stronie wtyczki i serwera wyczyścić. Jeśli nie masz pewności, jak migracja powinna wyglądać od A do Z, zerknij do wpisu Migracja strony między hostingami krok po kroku – to dobry punkt odniesienia, czy któryś etap nie został pominięty.
Pętle przekierowań: jak znaleźć źródło i przerwać zapętlenie
Pętla przekierowań najczęściej bierze się z konfliktu „kto ma prawo ustalać poprawny adres”. Jedna warstwa robi 301 na https, druga robi 301 na http, trzecia dorzuca www, a WordPress na koniec próbuje „kanonizować” URL na podstawie swoich ustawień. Efekt: przeglądarka kręci się, aż zgłosi błąd.
Najpierw ustal, czy przekierowanie robi WordPress, serwer czy pośrednik. W DevTools zobacz nagłówki odpowiedzi: jeśli Location: wygląda jak typowy URL z Twojej domeny, sprawdź też, czy w odpowiedzi jest charakterystyczny nagłówek serwera/proxy. Dodatkowo możesz podejrzeć plik .htaccess (Apache/LiteSpeed) albo konfigurację vhost (Nginx) – często po migracji zostaje stara reguła z poprzedniego środowiska.
Najpopularniejszy scenariusz: WordPress ma w bazie http://, a serwer wymusza https://. Wtedy WordPress generuje linki i ciasteczka w http, serwer robi 301 na https, a w pewnym momencie znów wracasz do http, bo aplikacja „myśli”, że pracuje po http. Jeśli używasz proxy/CDN, dochodzi kolejny problem: WordPress może nie widzieć, że użytkownik jest na https, bo połączenie do serwera origin idzie po http. W takich przypadkach kluczowe jest poprawne rozpoznanie schematu po stronie WordPress (nagłówki typu X-Forwarded-Proto) albo ustawienie stałych WP_HOME i WP_SITEURL w wp-config.php.
Drugi scenariusz to konflikt reguł www/non-www. Jeśli w DNS i certyfikacie masz tylko jedną wersję, a .htaccess próbuje robić „porządki” w drugą stronę, pętla gotowa. Zasada jest prosta: wybierz jedną wersję kanoniczną (z www albo bez) i wymuszaj ją w jednym miejscu, nie w trzech. Najbezpieczniej: jedno źródło prawdy w konfiguracji serwera + spójne URL-e w WordPress.
Na koniec pamiętaj o cache. Po zmianie reguł przekierowań wyczyść cache wtyczki, cache serwera oraz cache pośredników. W przeciwnym razie testujesz „stare 301”, które potrafią siedzieć w przeglądarce bardzo długo i udawać, że nic nie naprawiłeś.
Mixed content: jak wykryć zasoby po HTTP i wymienić je bez psucia strony
Mixed content to sytuacja, w której strona otwiera się po HTTPS, ale część zasobów (obrazki, CSS, JS, fonty) ładuje się po HTTP. Przeglądarki blokują wtedy część elementów albo przynajmniej straszą użytkownika brakiem pełnego bezpieczeństwa. Po migracji zdarza się to szczególnie często, gdy zmieniasz domenę albo przechodzisz z http na https.
Diagnoza jest prosta: otwórz DevTools → Console i zobacz, które zasoby są blokowane. W Network możesz też filtrować po „blocked” lub po schemacie http://. Dodatkowo sprawdź źródło strony (View source) i wyszukaj http://twojadomena – czasem problem siedzi w treści wpisów, a czasem w ustawieniach motywu.
Naprawa bywa dwuetapowa. Najpierw uporządkuj bazę danych: w treściach WordPress potrafi trzymać absolutne adresy do obrazków i linków. Jeśli po migracji zmienił się schemat albo domena, trzeba wykonać bezpieczne „zamień wystąpienia” (search/replace) z uwzględnieniem serializowanych danych (ustawienia wtyczek). W praktyce najwygodniej robi się to narzędziem, które rozumie strukturę WordPress (np. WP-CLI). Ważne: nie ruszaj pola guid w tabeli wpisów, bo to identyfikator techniczny, a nie adres do klikania.
Drugi etap to miejsca „poza treścią”: ustawienia motywu, kreatory stron, wtyczki od sliderów, formularzy i cache potrafią trzymać stare URL-e w swoich własnych tabelach. Jeśli po search/replace nadal widzisz pojedyncze zasoby po HTTP, idź po nitce: znajdź w konsoli konkretny URL i sprawdź, w jakim miejscu strony się pojawia (czasem to widget, czasem header, czasem wstrzyknięty skrypt).
Na koniec dopnij też warstwę zewnętrzną: jeśli używasz CDN w hostingu, upewnij się, że CDN nie serwuje Ci starych, zcache’owanych wersji plików z HTTP w linkach. Mixed content potrafi „zniknąć” po czyszczeniu cache na CDN i wrócić po godzinie, jeśli gdzieś w źródle nadal jest twardy http://.
Problemy z SSL: certyfikat, łańcuch, HSTS i proxy po drodze
Błędy SSL po migracji zwykle nie wynikają z „braku certyfikatu”, tylko z detali: certyfikat jest na inną nazwę, brakuje łańcucha pośredniego, serwer podaje zły certyfikat dla danego hosta (SNI), albo po drodze jest proxy, które terminuję TLS inaczej, niż zakładasz. Objawy są charakterystyczne: NET::ERR_CERT_COMMON_NAME_INVALID, komunikaty o niepełnym łańcuchu zaufania albo ostrzeżenia tylko na niektórych urządzeniach.
Zacznij od podstaw: czy certyfikat obejmuje dokładnie tę nazwę, pod którą wchodzisz (www i bez www to dwa różne hosty). Potem sprawdź, czy serwer podaje pełny łańcuch (często problem pojawia się na starszych urządzeniach, bo one są bardziej czułe na braki w chainie). Jeśli masz możliwość, przetestuj stronę z kilku miejsc: desktop, telefon, różne przeglądarki. Różnice w zachowaniu to często sygnał, że łańcuch albo konfiguracja TLS nie jest w pełni poprawna.
Osobny rozdział to HSTS. Jeśli kiedyś włączyłeś HSTS i przeglądarka pamięta, że domena ma zawsze działać po HTTPS, to wszelkie zabawy z przejściowym HTTP potrafią skończyć się wrażeniem, że strona „nie działa”. HSTS jest świetny, ale po migracji wymaga pewności: HTTPS musi działać stabilnie na każdym wariancie domeny, zanim go ponownie ustawisz.
Trzeci typ problemu to proxy/CDN i tryb połączenia do serwera origin. Klasyczna pułapka: pośrednik robi HTTPS do użytkownika, ale do serwera łączy się po HTTP, a WordPress nie rozpoznaje, że użytkownik jest na HTTPS. Wtedy wracają pętle przekierowań, ciasteczka sesyjne nie pasują, a SSL „wydaje się popsute”. W takich wdrożeniach naprawa polega na spójnej konfiguracji po obu stronach: poprawny tryb SSL w proxy oraz poprawne rozpoznawanie protokołu w WordPress.
404/403/500 po migracji: permalinki, .htaccess, uprawnienia i wersja PHP
Błąd 404 po migracji, mimo że strona główna działa, to w 80% przypadków kwestia permalinków albo reguł routingu na serwerze. Najprościej: wejdź w panel WordPress → Ustawienia → Bezpośrednie odnośniki i kliknij „Zapisz zmiany” bez modyfikacji. To wymusza regenerację reguł. Jeśli po tym dalej jest 404, sprawdź, czy .htaccess jest obecny i czy serwer w ogóle czyta reguły (na części konfiguracji Nginx .htaccess nie działa, bo to mechanizm Apache).
Błędy 403 (Forbidden) często wynikają z uprawnień plików po migracji albo z filtrów bezpieczeństwa. Po przeprowadzce z jednego środowiska na drugie potrafią zmienić się właściciele plików, a wtedy WordPress nie może pisać do katalogów z cache, uploadami albo aktualizacjami. Czasem 403 pojawia się tylko na wp-admin lub wp-login.php, bo nowy hosting ma dodatkowe reguły ochrony, które blokują nietypowe żądania.
Błąd 500 (Internal Server Error) bywa „workiem” na wszystko, ale po migracji najczęściej chodzi o niezgodność wersji PHP albo brak rozszerzeń wymaganych przez wtyczki. Jeżeli na starym hostingu działałeś na PHP 7.x, a nowy ma PHP 8.x, część starych wtyczek potrafi się wyłożyć bez eleganckiego komunikatu. Szybka metoda izolacji: wyłącz wszystkie wtyczki (np. przez zmianę nazwy katalogu plugins w FTP) i sprawdź, czy błąd znika. Potem włączaj po jednej.
Warto też pamiętać o ograniczeniach panelu i środowiska. Jeśli po migracji brakuje Ci wygodnych narzędzi, stagingu czy łatwego przełączania PHP, to takie „drobiazgi” realnie wpływają na czas naprawy.
Spadek wydajności po migracji: cache, baza danych i zasoby hostingu
Spadek wydajności po migracji bywa frustrujący, bo intuicja podpowiada, że „na nowym powinno być szybciej”. Tymczasem nowy hosting może mieć inne ustawienia PHP (limity pamięci, OPcache), inny serwer WWW, inne domyślne kompresje i cache, a także inne zasady współdzielenia zasobów. Jeśli po przeprowadzce panel działa wolniej, a przy większym ruchu pojawiają się 503, to zwykle nie jest „WordPress się zepsuł”, tylko środowisko ma węższe gardła.
Pierwszy krok to sprawdzenie cache. Jeżeli przenosiłeś stronę „z zamrożonym cache” (wtyczka generowała statyczne pliki), to po migracji cache może się nie odświeżać, bo brakuje uprawnień do katalogu albo cron nie działa. Z drugiej strony bywa odwrotnie: na starym hostingu miałeś dobrze ustawione cache serwera i wtyczki, a na nowym startujesz bez konfiguracji i wszystko leci dynamicznie.
Drugi krok to baza danych. Po migracji zdarza się, że w bazie zostają śmieci, transienty albo duplikaty wpisów w tabelach wtyczek, co potrafi ciągnąć czas odpowiedzi. Nie zawsze trzeba robić „wielką optymalizację”, ale warto przynajmniej sprawdzić, czy panel i strona nie wykonują nagle dużo cięższych zapytań niż wcześniej.
Trzeci krok to zasoby hostingu. Jeśli po migracji wchodzisz na limity CPU/RAM albo I/O, to objawy są typowe: strona działa, ale „przytyka” pod obciążeniem, a cache nie nadąża się budować. W tym miejscu przydaje się zrozumienie, jak czytać limity hostingu i które z nich faktycznie wpływają na TTFB, a które są tylko marketingowym parametrem.
Najczęstsze błędy i jak je naprawić
Poniżej masz zestaw problemów, które wracają po migracji najczęściej.
1) Pętla przekierowań (zbyt wiele przekierowań, ERR_TOO_MANY_REDIRECTS)
Najczęściej widzisz skakanie między http i https albo między www i bez www. Sprawdź łańcuch w DevTools (Network) i porównaj ustawienia home/siteurl z docelowym adresem. Naprawa polega na zostawieniu jednego miejsca, które wymusza docelowy URL: albo serwer, albo WordPress. Usuń duplikaty reguł w .htaccess i wyłącz wtyczki, które „wymuszają SSL”, jeśli równolegle robi to serwer/proxy. Na końcu wyczyść cache przeglądarki i cache pośredników.
2) Mixed content po przejściu na HTTPS (kłódka znika, zasoby blokowane)
W konsoli zobaczysz konkretne URL-e po http://. Jeśli to Twoja domena, zwykle problem siedzi w bazie danych. Zrób bezpieczny search/replace dla http://twojadomena → https://twojadomena narzędziem świadomym serializacji, a potem dobij ustawienia motywu i wtyczek, które przechowują własne linki. Jeśli pojedyncze zasoby nadal są po HTTP, namierz je w miejscu generowania (widget, header, wstrzyknięty skrypt) i popraw ręcznie.
3) Błędy SSL (nieprawidłowa nazwa domeny, brak zaufania, problemy tylko na części urządzeń)
Sprawdź, czy certyfikat obejmuje dokładny host (www i bez www), oraz czy serwer podaje pełny łańcuch certyfikatów. Jeśli korzystasz z proxy/CDN, upewnij się, że tryb SSL do serwera origin jest spójny z tym, co robi WordPress (najlepiej tak, żeby WordPress „wiedział”, że użytkownik jest na HTTPS). Po naprawie unikaj włączania HSTS „na próbę” – HSTS potrafi utrwalić problem w przeglądarce i utrudnić testy.
4) 404 na podstronach po migracji (strona główna działa, wpisy nie)
W panelu WordPress zapisz ustawienia bezpośrednich odnośników, żeby odświeżyć reguły. Jeśli to nie pomoże, problem jest po stronie serwera: .htaccess nie jest czytany albo konfiguracja Nginx nie przekazuje poprawnie żądań do WordPress. W praktyce najczęściej chodzi o brak reguły „fallback do index.php” albo błędny root katalogu po migracji.
5) Panel nie loguje, wyrzuca na stronę główną, sesja „znika”
To częsty efekt niespójnego schematu (http/https) i ciasteczek, zwłaszcza przy proxy. Sprawdź, czy home i siteurl są takie same i czy WordPress poprawnie rozpoznaje HTTPS. Wyczyść cookies dla domeny i sprawdź, czy nie masz dwóch równoległych wersji witryny (np. domena.pl i www.domena.pl) działających „na zmianę” w zależności od trasy DNS.
6) 500 po migracji, białe strony, błędy po wejściu do wp-admin
Najpierw podejrzewaj wersję PHP i wtyczki. Tymczasowo wyłącz wtyczki (zmiana nazwy katalogu plugins) i sprawdź, czy strona wraca. Potem włączaj po jednej, żeby znaleźć winowajcę. Jeśli migracja była robiona „na szybko”, upewnij się też, że pliki mają poprawne uprawnienia i właściciela, bo część błędów 500 wynika z tego, że WordPress nie może zapisać cache lub aktualizacji.
7) Strona działa, ale jest wolna / pojawiają się 503 przy ruchu
W pierwszej kolejności sprawdź cache (czy się buduje i czy jest serwowany), a potem obciążenie i limity zasobów. Jeśli po migracji masz częstsze problemy, możliwe, że wszedłeś na węższe limity hostingu albo straciłeś elementy przyspieszające (OPcache, HTTP/3, sensowny cache serwera). W przypadku dużego ruchu dorzuć też warstwę dystrybucji statyków, np. przez CDN w hostingu.
Checklista po migracji: 60 minut, 24 godziny, 7 dni
Dobra checklista robi dwie rzeczy: wyłapuje błędy, zanim zobaczy je użytkownik, i daje Ci pewność, że naprawa nie była tylko chwilowym efektem czyszczenia cache. Poniżej masz zestaw działań w trzech oknach czasowych.
W pierwsze 60 minut po przełączeniu DNS:
- Sprawdź stronę w incognito i na LTE: strona główna, jedna podstrona, jeden wpis, koszyk (jeśli jest), logowanie do panelu.
- Zweryfikuj łańcuch przekierowań (Network): czy masz jeden docelowy adres i brak skakania http/https oraz www/non-www.
- Otwórz konsolę i sprawdź, czy nie ma mixed content oraz blokowanych zasobów.
- Przejrzyj Ustawienia → Ogólne: spójność adresów URL (WordPress i witryna).
- Wyczyść cache: wtyczka cache, cache serwera, cache CDN/proxy (jeśli używasz).
W ciągu 24 godzin:
- Przeklikaj formularze kontaktowe, rejestrację, reset hasła i kluczowe funkcje sklepu (jeśli dotyczy).
- Sprawdź, czy backup działa i czy umiesz go odtworzyć.
- Zajrzyj do logów błędów (serwer, PHP) i zobacz, czy nie pojawiają się powtarzalne ostrzeżenia.
Po 7 dniach:
- Oceń wydajność: TTFB, stabilność pod obciążeniem, sporadyczne 5xx. Jeśli widzisz regres, wróć do konfiguracji cache i zasobów.
- Sprawdź indeksację i przekierowania w narzędziach webmastera: czy nie rośnie liczba błędów 404, czy kanoniczny adres jest spójny.
- Zrób porządek w procesie wdrożeń, żeby kolejna zmiana nie była „operacją na żywym organizmie” – tutaj pomaga testowanie zmian na kopii, czyli staging.
Jak przygotować migrację, żeby tych problemów nie było
Największa różnica między migracją „bez dramatu” a migracją z serią awarii to przygotowanie warunków testu. Jeśli masz możliwość, rób migrację na kopii i testuj na docelowym serwerze, zanim ruszysz DNS. Brzmi banalnie, ale w praktyce to jedyny sposób, żeby wykryć pętle przekierowań i błędy SSL bez presji, że już „wszyscy patrzą”.
Drugi filar to spójna polityka adresów. Zanim migrujesz, zdecyduj: docelowy adres to www czy bez www, i czy wymuszasz HTTPS na serwerze, czy w WordPress. Po migracji nie mieszaj tych odpowiedzialności. Jedna warstwa ma wymuszać docelowy URL, reszta ma się do niego dostosować.
Trzecia rzecz to bezpieczeństwo i higiena: ogranicz liczbę ruchomych elementów w dniu migracji. Aktualizacje motywu i wtyczek rób wcześniej albo później, a nie „przy okazji”. Jeśli w nowym środowisku wchodzą dodatkowe filtry bezpieczeństwa, sprawdź wcześniej, czy nie blokują logowania, wp-cron i kluczowych endpointów. W tym kontekście przydaje się szerszy przegląd praktyk z tekstu WordPress – bezpieczeństwo na hostingu.
Na koniec: backup i plan odwrotu. Migracja bez możliwości szybkiego powrotu to proszenie się o nerwy. Jeżeli masz pewny backup i wiesz, jak go odtworzyć, możesz podejmować decyzje spokojniej, bo każda zmiana jest odwracalna. To często ważniejsze niż „idealny scenariusz”, bo w realnym świecie problemy wychodzą dopiero po stronie użytkowników.
FAQ – Najczęściej zadawane pytania
Nie zawsze. .htaccess to częsty winowajca, ale równie często pętlę tworzy konflikt między WordPress (adresy home/siteurl), wtyczką wymuszającą HTTPS i pośrednikiem (proxy/CDN), który inaczej widzi protokół niż przeglądarka. Dlatego najpierw sprawdź łańcuch przekierowań w DevTools i ustal, która warstwa robi które przekierowanie. Dopiero potem upraszczaj konfigurację do „jednego źródła prawdy”.
Jeśli błąd występuje u jednych, a u innych nie i zależy od sieci (Wi-Fi vs LTE), to bardzo często w grę wchodzi propagacja DNS albo cache po drodze. Sprawdź, czy Twoje urządzenie trafia na nowe IP (np. porównując wyniki w różnych sieciach) i czy przypadkiem nie testujesz starego serwera. Problemy aplikacyjne zwykle są powtarzalne niezależnie od sieci i dają się odtworzyć w incognito.
Bo WordPress może mieć HTTPS w ustawieniach, a w bazie danych nadal siedzą stare, absolutne linki do obrazków i zasobów po HTTP. Do tego część motywów i wtyczek trzyma własne URL-e w osobnych tabelach. Ustawienie HTTPS to dopiero początek: potem trzeba wyczyścić stare adresy w treści i ustawieniach oraz zadbać, żeby cache i CDN nie serwowały starych wersji zasobów.
To często sygnał problemu z łańcuchem certyfikatu (brakujące certyfikaty pośrednie) albo konfiguracją TLS, która jest bardziej restrykcyjna na niektórych urządzeniach. Bywa też, że telefon trafia na inny wariant domeny (np. z www), a certyfikat obejmuje tylko wersję bez www. Warto testować oba warianty i upewnić się, że certyfikat jest wydany dla wszystkich używanych nazw.
HSTS nie psuje strony sam w sobie, ale potrafi utrwalić problem w przeglądarce. Jeśli kiedyś ustawiłeś HSTS, przeglądarka może na sztywno wymuszać HTTPS, nawet jeśli chwilowo testujesz po HTTP. Po migracji, kiedy konfiguracja SSL nie jest jeszcze idealna, HSTS utrudnia diagnozę, bo część ruchu jest automatycznie przepisana. Dlatego HSTS ustawiaj dopiero, gdy masz pewność, że HTTPS działa stabilnie dla wszystkich wariantów domeny.
Często to problem ciasteczek i domeny/protokołu. Jeśli raz wchodzisz na wersję z www, a raz bez www, WordPress może ustawiać cookies dla innego hosta, niż ten, na którym jesteś. Podobnie bywa, gdy WordPress nie rozpoznaje HTTPS i generuje część odpowiedzi „jakby była po HTTP”. Zacznij od ujednolicenia adresów i wyczyszczenia cookies dla domeny, a potem sprawdź, czy nie ma pętli przekierowań w tle.
Najpierw odśwież permalinki w panelu (zapisz ustawienia bezpośrednich odnośników). Jeśli to nie pomoże, problem leży w routingu serwera: reguły przekazywania żądań do index.php nie działają albo .htaccess jest ignorowany. Wtedy potrzebujesz korekty konfiguracji serwera (szczególnie przy Nginx), a nie kolejnych zmian w WordPress.
30-letnia pasjonatka informatyki, która świat serwerów i hostingów zna od podszewki. Wierzy, że technologia powinna ułatwiać życie, a nie je komplikować. Żyje w ciągłym ruchu – jeśli akurat nie konfiguruje nowej usługi, prawdopodobnie pakuje plecak na kolejną wyprawę w nieznane.
Dodaj komentarz