Problemy z domeną w WordPress: DNS, SSL i adres strony

Zacznij od pełnego adresu wraz z protokołem i wariantem hosta. Zanotuj komunikat przeglądarki, godzinę, sieć i urządzenie. Brak rozwiązania nazwy, ostrzeżenie certyfikatu, błąd serwera i pętla przekierowań to różne objawy. Zrzut ekranu ułatwia rozmowę, lecz do diagnozy potrzebna jest także informacja, jaki adres został wpisany i gdzie ostatecznie trafiła przeglądarka.

Porównaj domenę główną i www oraz HTTP i HTTPS. Jeżeli tylko część kombinacji nie działa, nie zmieniaj od razu całej konfiguracji. Różnica może wskazywać brak rekordu, brak obsługi hosta na serwerze albo certyfikat nieobejmujący tej nazwy. Wykonuj odczyty i zachowuj wyniki bez przesyłania haseł.

Ustal, czy poprzedzała to migracja, zmiana operatora DNS lub odnowienie certyfikatu. Przy obsłudze WordPressa taki rejestr zmian pomaga skrócić poszukiwania. Historia wdrożenia jest wskazówką, ale przyczynę trzeba potwierdzić aktualnym stanem, nie samą zbieżnością dat.

Domena i hosting są oddzielnymi usługami. Aktywne pliki oraz baza danych nie wystarczą, jeśli nazwa przestała prowadzić do serwera. Zaloguj się do znanego panelu rejestratora, sprawdź status domeny, termin odnowienia i dane kontaktowe abonenta. Nie rozpoczynaj płatności z przypadkowego linku w wiadomości informującej o rzekomym wygaśnięciu.

Dla domeny .pl punktem odniesienia jest cykl życia domeny opisany przez NASK oraz aktualny status u rejestratora. Nie przenoś okresów i zasad z innych rozszerzeń. Możliwość odnowienia, przywrócenia lub ponownej rejestracji zależy od etapu, dlatego najpierw ustal stan konkretnej domeny, a dopiero później dostępne działania.

Jeżeli nie masz dostępu do panelu, wyjaśnij uprawnienia i właściciela konta z operatorem. Nie zakładaj, że hosting automatycznie zarządza rejestracją. W planie obsługi strony internetowej warto wskazać osobę odpowiedzialną za odnowienia i kanał alertów, aby pojedyncza nieodczytana wiadomość nie zatrzymała całego procesu.

Sprawdź, które serwery nazw są delegowane dla domeny, a następnie odczytaj rekordy u faktycznie obsługującego ją operatora DNS. Edycja strefy w innym panelu nie zmieni odpowiedzi publicznych. Porównaj rekord A dla IPv4, AAAA dla IPv6 oraz sposób obsługi www. Pozostawiony rekord AAAA może kierować część użytkowników do innego serwera niż poprawiony rekord A.

Dokumentacja typów rekordów Cloudflare rozróżnia między innymi adresy hosta, rekordy pocztowe i aliasy. Przy porządkowaniu strefy zachowaj potrzebne MX i TXT. Naprawa witryny nie powinna przypadkowo przerwać poczty ani usunąć wpisów weryfikacyjnych usług. CAA również sprawdza się w DNS, nie jako pole danych abonenta.

TTL określa czas przechowywania odpowiedzi w pamięci podręcznej, ale nie gwarantuje jednego terminu zakończenia całej zmiany. Delegacja, wcześniejsze odpowiedzi i błędy DNSSEC wymagają osobnego sprawdzenia. Jeżeli odpowiedzi są niespójne, zapisz resolver oraz czas pomiaru, zamiast ponawiać edycję rekordów co kilka minut.

Jeżeli nazwa prowadzi do właściwego serwera, a przeglądarka ostrzega o połączeniu, sprawdź certyfikat przedstawiany dla konkretnego hosta. Zweryfikuj objęte nim nazwy, okres ważności i poprawność łańcucha. Certyfikat dla jednego wariantu adresu nie musi obejmować drugiego. Z kolei jeden prawidłowo skonfigurowany certyfikat może obejmować wiele nazw; nie należy z góry zakładać konieczności osobnych zakupów.

Przy pośredniku CDN istnieją połączenia użytkownika z usługą pośrednią oraz usługi z serwerem źródłowym. Dokumentacja trybów szyfrowania Cloudflare rozdziela oba odcinki. Ustal, w którym miejscu występuje problem i jaka konfiguracja szyfrowania jest oczekiwana. Nie wyłączaj weryfikacji certyfikatu jako trwałej naprawy. To może ukryć błąd, pozostawiając niewłaściwie zabezpieczony odcinek połączenia.

Przy konfiguracji Cloudflare dla WordPressa sprawdź również zachowanie serwera źródłowego i wymuszanie HTTPS. Problem certyfikatu nie jest tym samym co mieszana zawartość, kiedy poprawnie otwarta strona odwołuje się do zasobów przez HTTP. Te objawy wymagają oddzielnych poprawek.

Po potwierdzeniu DNS i TLS sprawdź odpowiedzi HTTP dla kolejnych wariantów adresu. Zapisz kody oraz nagłówki Location aż do docelowej strony albo powtarzającego się kroku. Pętla może powstawać między regułą serwera, usługą CDN i ustawieniem aplikacji. Samo usunięcie jednego przekierowania bez poznania pozostałych może przenieść problem na inny wariant hosta.

DNS wiąże nazwy z informacją potrzebną do połączenia; nie wysyła przeglądarce przekierowania 301. Takie przekierowanie wykonuje serwer HTTP lub usługa obsługująca ruch. Dlatego zmiana rekordu nie przenosi automatycznie użytkownika ze starej ścieżki artykułu na jej nowy odpowiednik.

Ustal jedną docelową wersję publicznego adresu i odpowiedzialność za reguły. Przekierowanie trwałe lub tymczasowe dobierz do rzeczywistego zamiaru. Nie oceniaj migracji wyłącznie po otwarciu strony głównej. Sprawdź także podstrony, zasoby i adresy wymagane przez integracje. Czyszczenie całej pamięci CDN nie zastąpi naprawy konfliktujących reguł i nie powinno być pierwszym krokiem.

W WordPressie home określa publiczny adres witryny, natomiast siteurl wskazuje lokalizację plików rdzenia. W poprawnej instalacji rdzenia w podkatalogu wartości mogą się różnić. Nie zrównuj ich automatycznie tylko dlatego, że inne strony używają identycznych adresów. Najpierw ustal strukturę tej konkretnej instalacji i sposób uruchamiania strony.

Stałe WP_HOME i WP_SITEURL w konfiguracji mogą nadpisywać wartości odczytywane z bazy, ale ich dopisanie nie jest uniwersalnym lekarstwem na pętlę. Sprawdź również konfigurację serwera oraz pośrednika. Dokumentacja migracji WordPressa opisuje zależności adresów, plików i danych przy przenoszeniu instalacji.

Przed edycją przygotuj kopię bazy i konfiguracji oraz drogę przywrócenia dostępu. Po zmianie sprawdź stronę publiczną, logowanie, zasoby i panel. Jeżeli błąd dotyczy tylko odnośników w treści, nie zmieniaj ponownie ustawień całej witryny. Rozdzielenie konfiguracji od zapisanych adresów pozwala dobrać mniejszy i bardziej przewidywalny zakres naprawy.

Zmiana domeny może pozostawić stare odnośniki w treści, ustawieniach dodatków i danych integracji. Zanim wykonasz podmianę, określ właściwą bazę, prefiks oraz tabele związane z przenoszoną instalacją. Nie obejmuj automatycznie wszystkich tabel na serwerze. Obok WordPressa mogą znajdować się dane innych witryn lub systemów.

WP-CLI search-replace obsługuje dane serializowane i tryb dry-run. Najpierw wykonaj kopię oraz analizę zakresu, a potem próbę bez zapisu i przegląd wyniku. Uwzględnij kolumnę GUID oraz odrębność Multisite, jeśli występuje. Samo istnienie narzędzia nie uzasadnia globalnej podmiany dowolnego fragmentu tekstu.

Przy zmianie publicznych URL przygotuj mapę starych i nowych podstron. Google opisuje migracje ze zmianą adresów, zalecając spójne przekierowania i kontrolę nowej wersji. Zachowanie ruchu nie jest gwarantowane. Sprawdź też callbacki, webhooki i adresy powrotu, ponieważ ich poprawność nie wynika z działania zwykłego linku w artykule.

Odbiór powinien obejmować status domeny, odpowiedzi DNS, certyfikat, łańcuch przekierowań i działanie właściwych podstron. Porównaj odczyty z więcej niż jednej sieci, jeśli wcześniej użytkownicy widzieli różne wersje. Zapisz wynik i czas. Nie wykonuj przy tym prawdziwych zakupów ani wysyłek formularza; sprawdzenie integracji zaplanuj w odizolowanym środowisku.

Jeżeli przyczyna leży po stronie infrastruktury, dokumentacja wyboru hostingu WordPress pomoże określić wymagania dla obsługi. Gdy potrzebna jest analiza aplikacji, zakres naprawy WordPressa powinien wskazywać konkretny objaw i kryteria zakończenia, bez obietnicy czasu przed poznaniem problemu.

Dalsza opieka może obejmować pilnowanie odnowień, kontrolę certyfikatów i przegląd konfiguracji po migracjach. Pakiet godzinowy, dostępność i ewentualne SLA ustalamy indywidualnie. Przez kontakt KC Mobile przekaż domenę, komunikat błędu oraz informację o ostatniej zmianie. Nie przesyłaj w pierwszej wiadomości haseł ani kodów transferowych.