Stronę na nowym hostingu możesz otworzyć pod jej dotychczasową domeną, zanim zmienisz publiczne wskazania WWW w DNS. W pliku hosts na swoim komputerze przypisujesz domenie adres IP nowego serwera. Ty oglądasz przygotowaną kopię, a pozostali odwiedzający nadal korzystają ze starej strony. Po teście usuwasz lokalny wpis.
Poniższa instrukcja zakłada, że pliki i baza są już skopiowane, a domena została dodana do nowego konta. Pokazuje podgląd w Windows i kontrolę w Chrome, z dodatkowymi wskazówkami dla WordPressa. Nie wymaga przełączenia ruchu ani wyłączenia obecnej witryny. Gdy dopiero przygotowujesz kopię, zacznij od pełnej instrukcji przeniesienia WordPressa.
Dlaczego samo wejście na adres IP nie wystarcza?
Na jednym adresie IP może działać wiele witryn. Serwer rozpoznaje właściwą stronę po nazwie domeny, a przy HTTPS nazwa uczestniczy także w wyborze i weryfikacji certyfikatu. Po wejściu na https://203.0.113.10 możesz więc zobaczyć stronę domyślną albo ostrzeżenie certyfikatu zamiast swojej instalacji.
Podgląd przez hosts zachowuje nazwę w pasku przeglądarki: na przykład https://example.com/oferta/. Dzięki temu sprawdzasz również linki, przekierowania i zachowanie aplikacji pod adresem, którego będzie używać po migracji. Przy zachowaniu domeny, protokołu i ścieżek WordPress nie wymaga zamiany adresów w bazie. Nie wpisuj do jego ustawień IP ani tymczasowej domeny tylko po to, żeby obejrzeć kopię.
1. Przygotuj nową kopię przed pierwszym otwarciem
Potrzebujesz adresu IP przeznaczonego do obsługi WWW, nie adresu panelu czy serwera bazy. Odczytaj go przy domenie w nowym panelu albo poproś operatora o IP do bezpośredniego podglądu. Spisz wszystkie nazwy objęte sprawdzeniem: domenę główną, wariant www i używane subdomeny. Samo wpisanie domeny do hosts nie dodaje jej do konfiguracji hostingu.
Oddziel dane i zadania nowej kopii od działającej strony
Nowa aplikacja ma korzystać z własnej kopii bazy i plików. W WordPressie porównaj DB_HOST, DB_NAME i konto użytkownika bazy z danymi nowego hostingu. Te ustawienia w wp-config.php decydują o połączeniu. Gdy wskazują produkcyjną bazę, nawet zapis szkicu w podglądzie może zmienić prawdziwą stronę. Przy zewnętrznym magazynie plików lub współdzielonym cache również potrzebna jest odrębna konfiguracja kopii.
Jeszcze przed otwarciem nowego WordPressa wstrzymaj jego zadania w tle. Po zachowaniu kopii nowego wp-config.php ustaw w nim poniższą definicję przed wczytaniem wp-settings.php. Jeśli już występuje, popraw jej wartość zamiast dodawać drugą:
define( 'DISABLE_WP_CRON', true );Definicja zatrzymuje uruchamianie WP-Cron przy wejściach na stronę. Osobno wstrzymaj zadania tej kopii w harmonogramie nowego hostingu oraz automatyczne synchronizacje wtyczek. Nie wyłączaj zadań starej witryny, która nadal obsługuje użytkowników. Jeśli kopię przygotował wykonawca, poproś go o potwierdzenie odrębnej bazy, zatrzymanych zadań i odłączenia produkcyjnych integracji.
Zabezpiecz dostęp i przygotuj HTTPS
Nowa kopia powinna być dostępna tylko osobom wykonującym test. W cPanel możesz użyć Directory Privacy: wybrać katalog domeny, włączyć ochronę hasłem i utworzyć konto dostępu. Zachowaj jej reguły podczas późniejszego kopiowania plików. W innych środowiskach operator może ograniczyć dostęp do wskazanych adresów IP. Reguła noindex dotyczy indeksowania, nie zabezpiecza danych przed osobą znającą adres.
Na nowym serwerze przygotuj certyfikat zaufany przez przeglądarkę, obejmujący testowane nazwy. Można go uzyskać przed przełączeniem rekordów WWW, na przykład przez weryfikację DNS-01. Operator potwierdza wtedy kontrolę domeny rekordem TXT. To osobna czynność od zmiany adresu strony; wpis w Twoim pliku hosts nie zmieni tego, co widzi wystawca certyfikatu.
Do nowego operatora możesz wysłać:
Chcę sprawdzić skopiowaną stronę przez plik hosts przed przełączeniem ruchu. Proszę podać IP do podglądu oraz sposób uruchomienia na nowym serwerze certyfikatu zaufanego przez przeglądarkę dla mojej domeny z www i bez www, bez zmiany produkcyjnych rekordów WWW. Proszę wskazać, jakie dane lub działanie z mojej strony będą potrzebne.
Dopiero po odseparowaniu kopii i przygotowaniu HTTPS przejdź do podglądu. Ochrona hasłem ogranicza dostęp z zewnątrz, ale nie blokuje połączeń, które sama aplikacja wysyła do poczty, płatności czy innych usług.
2. Ustaw domenę w pliku hosts w Windows
Plik hosts w Windows znajdziesz pod adresem C:\Windows\System32\drivers\etc\hosts. Zrób jego kopię, a następnie uruchom Notatnik jako administrator. Wybierz otwarcie pliku i przejdź do tego katalogu; w razie potrzeby zmień filtr na wszystkie pliki.
Dopisz IP nowego hostingu i domenę. Poniższe nazwy oraz adres 203.0.113.10 są przykładami — zastąp je swoimi danymi:
203.0.113.10 example.com
203.0.113.10 www.example.comWpisujesz samą nazwę, bez https://, portu i ścieżki podstrony. Wariant www wymaga osobnego uwzględnienia, tak samo jak potrzebna subdomena. Jeśli plik ma już wpisy dla tych nazw, zachowaj ich treść i usuń konflikt przed dodaniem nowych. Sprawdź także stare wpisy IPv6. Nie zmieniaj innych domen ani pozostałych nazw zapisanych w tej samej linii.
Zapisz plik pod dotychczasową nazwą, bez rozszerzenia .txt. W terminalu Windows uruchomionym jako administrator wyczyść lokalną pamięć odpowiedzi DNS:
ipconfig /flushdnsTa opcja czyści pamięć klienta DNS w Windows; nie zmienia publicznych rekordów domeny. Zamknij przeglądarkę i uruchom ją ponownie, aby nie korzystała z wcześniejszego połączenia.
Alternatywą dla ręcznej edycji jest Hosts File Editor w Microsoft PowerToys. Dodajesz IP i nazwę hosta, włączasz wpis i zapisujesz zmianę z uprawnieniami administratora. Wybierz jedną metodę edycji. To ustawienie komputera, nie tylko jednej karty przeglądarki. Okno incognito nie przywróci starego wskazania domeny.
Do testów możesz przygotować osobny lokalny profil Chrome, bez logowania do konta Google. Ułatwi to oddzielenie sesji i danych przeglądarki od codziennej pracy. Profil nadal korzysta jednak z tego samego lokalnego wskazania domeny.
3. Potwierdź, że oglądasz właściwy serwer
Przed logowaniem do aplikacji umieść tylko na nowym hostingu plik tekstowy o unikalnej nazwie, np. podglad-8c42f1.txt. Wgraj go do katalogu WWW tej domeny i zapisz w nim krótki tekst nowy-hosting-8c42f1, bez konfiguracji i danych dostępowych. Własna nazwa powinna różnić się od plików istniejących na obu kontach.
Otwórz w przeglądarce https://example.com/podglad-8c42f1.txt, podstawiając swoją domenę i nazwę pliku. Przy poprawnym HTTPS podaj dane ochrony katalogu, jeśli zostaniesz o nie poproszony — to konto przygotowane dla podglądu, nie login WordPressa. Ostrzeżenie certyfikatu wymaga poprawienia konfiguracji, a nie dodania wyjątku bezpieczeństwa.
W Chrome naciśnij F12 i wybierz Network / Sieć. Włącz Disable cache oraz Preserve log, a prawym przyciskiem na nagłówkach tabeli dodaj kolumnę Remote address. Odśwież plik. Panel sieciowy pokaże adres połączenia oraz status żądania. Wyłączenie cache działa tu, gdy narzędzia pozostają otwarte.
Poprawny wynik tego sprawdzenia to jednocześnie: kod 200, dokładnie Twój tekst kontrolny i adres połączenia zgodny z nowym IP podanym do podglądu. Jeśli domena przekierowała na www, sprawdź również końcowe żądanie. Potwierdzenie pliku sprawdza kierowanie do właściwego katalogu; działanie PHP i bazy ocenisz przy otwarciu aplikacji.
Polecenie nslookup może nadal pokazywać stare IP i jest to oczekiwane: pyta o odpowiedź serwera DNS. Do potwierdzenia tego podglądu używaj rzeczywistego żądania HTTP i pliku kontrolnego, nie wyniku publicznego DNS.
4. Sprawdź podstrony, zasoby i działanie aplikacji
Zostaw otwarty panel Network i przejdź od pliku kontrolnego do witryny. Przy żądaniach dokumentów nadal kontroluj docelowy serwer. Kliknięcie linku do nazwy nieujętej w hosts może otworzyć starą stronę. Jeśli w Twojej konfiguracji istnieje kilka domen lub subdomen, każda powinna prowadzić do właściwego przygotowanego miejsca.
| Co sprawdzić | Jak rozpoznać poprawny wynik |
|---|---|
| Strona główna, oferta i kilka starszych wpisów | Otwierają właściwą treść, mają spodziewane adresy i odpowiedź 200 |
| Menu, wyszukiwanie i wariant www | Prowadzą do właściwych podstron; przekierowanie nie przenosi na tymczasową domenę ani nie zapętla się |
| Zdjęcia, style, skrypty i pliki do pobrania | Wczytują się bez błędów; adresy odpowiadają zasobom, które mają działać po migracji |
| Nieistniejący adres, np. własna losowa nazwa podstrony | Pokazuje stronę błędu z rzeczywistym statusem 404, nie zwykłą stronę z kodem 200 |
| Logowanie i odczyt panelu | Sesja działa, a dane odpowiadają stanowi kopii; nie pojawia się instalator nowej witryny |
| Zapis szkicu — dopiero po potwierdzeniu odrębnej bazy i integracji | Szkic daje się zapisać oraz ponownie otworzyć w nowej kopii; testowy wpis nie jest publikowany |
Po kliknięciu żądania w Network otwórz Headers, aby sprawdzić status, oraz Response, aby zobaczyć odpowiedź. Widok żądań i odpowiedzi pomaga odróżnić błąd brakującego pliku od sytuacji, w której zamiast skryptu serwer zwraca stronę logowania. Przy HTTPS certyfikat sprawdzisz w narzędziach Privacy and security → Security → Overview → View certificate.
Zwróć uwagę na zdjęcia lub skrypty pobierane z oddzielnej domeny CDN. Ich poprawne wyświetlenie nie dowodzi, że znajdują się na nowym hostingu. Jeśli CDN zostaje, taki adres może być prawidłowy. Gdy zasób ma zostać przeniesiony, trzeba sprawdzić jego nową lokalizację. Podobnie oceniaj datę treści: porównujesz stan z chwili wykonania kopii, nie wpisy dodane na starej stronie później.
Układ mobilny obejrzysz przez ikonę telefonu i tabletu w DevTools, czyli Device Mode. Zwęź widok i sprawdź menu, tabele oraz formularze. To symulacja w przeglądarce komputerowej. Telefon bez własnego sposobu podglądu nadal otworzy stronę wskazaną przez publiczny DNS, nawet jeśli jest połączony z tym samym Wi-Fi.
Formularze i sklep: kiedy można wykonać pełny test?
Najpierw sprawdź wyświetlanie pól i przycisków, bez wysyłania formularza. Przed próbą zapisu lub wysyłki w nowej kopii ustaw kontrolowanych odbiorców oraz przechwytywanie wiadomości. Uwzględnij autoresponder, zewnętrzny serwer SMTP i integracje przekazujące dane dalej. Jeśli nie masz przygotowanej izolacji, pozostaw wysyłanie jako niezweryfikowane zamiast kierować próbę do rzeczywistego klienta.
Przy sklepie pełna próba wymaga środowiska testowego płatności i odłączenia produkcyjnego fakturowania, magazynu oraz wysyłki. Testowe zamówienia WooCommerce mogą uruchamiać e-maile i inne integracje. Mechanizm blokowania wiadomości musi obejmować także faktycznie używany sposób wysyłki — nie każda blokada poczty w WordPressie obejmie zewnętrzne SMTP.
Plik hosts zmienia trasę na Twoim komputerze, nie na serwerze operatora płatności. Powiadomienie wysłane przez zewnętrzną usługę na publiczny adres domeny nadal może dotrzeć do starej witryny. Tak samo żądanie nowego serwera do własnej domeny może korzystać z publicznego DNS. Pełny test takich połączeń wymaga przygotowanego adresu testowego i ustawień właściwej integracji. Sam poprawny powrót przeglądarki do sklepu nie potwierdza odebrania powiadomienia serwerowego.
Co zmienia Cloudflare lub inny pośrednik?
Skierowanie domeny lokalnie prosto na nowy serwer może ominąć Cloudflare. Wtedy sprawdzasz aplikację na serwerze źródłowym, ale nie jej działanie przez reguły pośrednika, jego pamięć podręczną i ochronę ruchu. Cloudflare w trybie Full (strict) dodatkowo weryfikuje połączenie z serwerem źródłowym; ten odcinek również trzeba będzie sprawdzić przy przygotowaniu publicznej trasy.
Certyfikat Cloudflare Origin CA nie jest przeznaczony do bezpośredniego zaufania przez zwykłą przeglądarkę. Jeśli tylko taki certyfikat działa na nowym serwerze, poproś operatora o podgląd z certyfikatem publicznie zaufanym albo o przygotowanie kontrolowanego podglądu przez pośrednika. Nie obchodź ostrzeżenia i nie wyłączaj ochrony działającej witryny. Przy serwerze dopuszczającym wyłącznie połączenia z Cloudflare sposób bezpośredniego dostępu również trzeba wcześniej uzgodnić.
Dlaczego nadal widać starą stronę lub pojawia się błąd?
Sprawdzaj najpierw połączenie, potem konfigurację aplikacji. Zapisz końcowy URL, status, godzinę próby i wynik pliku kontrolnego. Jeśli plik dociera z właściwego miejsca, a WordPress pokazuje błąd, ponowne poprawianie DNS nie usunie usterki jego bazy czy PHP.
| Objaw | Pierwsze sprawdzenie |
|---|---|
| Plik kontrolny nie pojawia się | Nazwa zapisanego pliku hosts, właściwe IP, konflikty wpisów oraz katalog, do którego wgrano plik |
| Nowa strona otwiera się tylko bez www | Wpis dla www, dodanie tej nazwy na nowym hostingu, certyfikat oraz docelowy adres przekierowania |
| Widoczna strona domyślna operatora | Przypisanie domeny do nowego konta i właściwego katalogu WWW |
| Żądanie zwraca 401 | Czy oczekiwana ochrona katalogu wymaga zalogowania; użyj konta podglądu przez poprawne HTTPS |
| Ostrzeżenie certyfikatu | Nazwa i ważność certyfikatu podawanego przez nowy serwer, zaufanie wystawcy oraz ewentualny Origin CA |
| Plik działa, a aplikacja zwraca błąd bazy lub 500 | Połączenie nowej bazy i log błędów PHP; przy ekranie instalacji nie uruchamiaj instalatora |
Gdy odpowiedź wygląda na starą mimo poprawnego adresu połączenia, oddziel pamięć przeglądarki od cache nowej aplikacji. Opcja Disable cache nie czyści cache na serwerze. Jeśli witryna używa service workera, w Application → Service Workers zaznacz na czas kontroli Bypass for network. Pozwala to pobrać odpowiedź z sieci zamiast przez service workera. Przy firmowym proxy lub narzuconych ustawieniach sieci poproś o dozwolony sposób podglądu, nie wyłączaj zabezpieczeń na próbę.
Opcjonalnie: sprawdź jedno żądanie przez curl bez edycji hosts
Do sprawdzenia samego pliku lub odpowiedzi serwera możesz użyć curl.exe w PowerShellu. Najpierw sprawdź dostępność przez curl.exe --version. Parametr --resolve przypisuje IP konkretnej nazwie i portowi na czas tego polecenia, z zachowaniem domeny w HTTPS. Nie ustawia podglądu w przeglądarce. To alternatywa do wąskiej kontroli, nie kolejny obowiązkowy etap.
Przykład zakłada dozwolone bezpośrednie połączenie z nowym serwerem. Podstaw własną domenę, IP i utworzony plik kontrolny. Polecenie wklej jako jedną linię:
curl.exe --disable --noproxy 'example.com' --resolve 'example.com:443:203.0.113.10' --connect-timeout 10 --max-time 20 --include --write-out '\nIP=%{remote_ip} HTTP=%{http_code}\n' 'https://example.com/podglad-8c42f1.txt'Opcja --disable na początku pomija domyślny plik ustawień curl, a --noproxy wyłącza użycie proxy dla wskazanej nazwy w tym wywołaniu. Polecenie pobiera nagłówki i treść; bez --location nie podąża za przekierowaniem. Jeśli otrzymasz 301 lub 302, odczytaj nagłówek Location i osobno sprawdź docelową nazwę z właściwym mapowaniem.
Poprawny wynik potwierdzają łącznie: brak błędu połączenia, dokładnie Twój tekst kontrolny, właściwy adres IP i status HTTP 200. W tym przykładzie końcowy wiersz powinien mieć postać IP=203.0.113.10 HTTP=200. Wartości remote_ip i http_code opisują połączenie i odpowiedź tego żądania. Sam brak komunikatu błędu nie wystarcza: bez opcji --fail lub --fail-with-body curl może poprawnie zakończyć pobieranie odpowiedzi 404 lub 500.
Przy ochronie hasłem dodaj przed URL opcję --user 'LOGIN_PODGLADU', zastępując login własnym; hasło wpisz dopiero po pytaniu programu. Nie umieszczaj go w poleceniu. Curl domyślnie weryfikuje certyfikat i nazwę serwera — nie dodawaj -k ani --insecure, aby ukryć błąd.
5. Zakończ podgląd i zapisz wynik testów
Jeszcze przy aktywnym lokalnym wskazaniu wyloguj się z nowej aplikacji. Usuń z pliku hosts wyłącznie dodane wpisy tej próby, a wcześniej zmienione wpisy przywróć do ich zapisanej postaci. W PowerToys wyłącz lub usuń własne wpisy podglądu. Ponownie wykonaj ipconfig /flushdns i zamknij przeglądarkę.
Po jej uruchomieniu domena znów korzysta ze zwykłego rozwiązywania nazw. Jeśli publicznego DNS jeszcze nie zmieniono, powrót do starej strony jest prawidłowym wynikiem. Usuń plik kontrolny z nowego konta przez panel lub narzędzie do transferu. Nowa kopia pozostaje zabezpieczona, a jej zadania zatrzymane do właściwej migracji.
Zapisz, co działa, co wymaga poprawy i co pozostaje niezweryfikowane — na przykład powiadomienia płatnicze albo publiczna trasa przez Cloudflare. Jeśli stara strona w tym czasie przyjmowała nowe dane, przed przełączeniem potrzebna będzie końcowa synchronizacja. Po niej trzeba ponowić istotne sprawdzenia i zachować potrzebne ustawienia nowego środowiska.
Zdjęcie ochrony podglądu, ewentualnego testowego noindex oraz wznowienie zadań należą do zaplanowanego przełączenia, nie do samego końca tej próby. Google rozdziela test nowej infrastruktury od zmiany DNS i kontroli publicznego ruchu. Zewnętrzny skaner strony i narzędzie inspekcji Google nie korzystają z pliku hosts Twojego komputera, więc przed przełączeniem domeny nie potwierdzą w ten sposób działania nowej kopii.
Podgląd jest zakończony, gdy potwierdzisz właściwy serwer, poprawne HTTPS i potrzebne funkcje kopii oraz usuniesz lokalne wskazania. Wynik daje podstawę do przełączenia przygotowanej strony; kontrola publicznego DNS, pośredników i zewnętrznych integracji pozostaje osobnym etapem po zmianie ruchu. Ten następny etap porządkuje procedura zmiany DNS i TTL bez niepotrzebnego przestoju.
Po zakończeniu lokalnego podglądu sprawdź jeszcze publiczną stronę i sygnały techniczne po przełączeniu. Lista kontroli adresów, canonicali i indeksowania znajduje się w poradniku zmiana hostingu a SEO.
Całą kolejność przygotowań, testów i przełączenia możesz zaznaczyć w planerze migracji. Jeśli potrzebujesz takiego środowiska także do późniejszych aktualizacji, jego wymagania opisuje poradniku o stagingu WordPressa.