Przeniesienie strony z nazwa.pl: 7 etapów migracji

Przeniesienie strony z nazwa.pl zacznij od ustalenia, która usługa obsługuje stronę, a która pocztę. Panel Klienta, CloudHosting Panel i Cloud Mail mają różne zadania. Dopiero po skopiowaniu plików, bazy oraz potrzebnych danych pocztowych przygotuj przełączenie. Wyłączenie odnowienia hostingu przed odbiorem nowego środowiska nie jest skrótem migracji.

Poniższa ścieżka obejmuje WordPressa na zwykłym CloudHosting i konto docelowe z DirectAdmin, przy zachowaniu dotychczasowej domeny. CloudHosting WordPress ma własną strukturę instalacji, której nie wolno utożsamiać ze zwykłym katalogiem jednej strony. Dokumentację paneli i eksportów sprawdzono 30.10.2026.

W tym poradniku

1. 1. Przeniesienie strony z nazwa.pl: właściwe panele
2. 2. Pobierz pliki z właściwego CloudHosting
3. 3. Wyeksportuj bazę, nie tylko treść z panelu WordPressa
4. 4. Odizoluj cel i dopiero potem odtwórz instalację
5. 5. Sprawdź stronę bez polegania na starej warstwie CDN
6. 6. Przenieś pocztę oraz osobno kontakty Cloud Mail
7. 7. Przeniesienie strony z nazwa.pl: przełączenie i odbiór
8. Dlaczego jedni widzą nową stronę, a inni poprzednią?

1. Przeniesienie strony z nazwa.pl: właściwe panele

W Panelu Klienta przejdź do Usługi → Domeny → konfiguruj i odczytaj bieżące skierowanie domeny. Właściwy hosting i serwer poczty mogą się różnić. Przy ręcznym DNS sprawdź rekordy u aktywnego dostawcy strefy; sam adres IP nie pozwala początkującemu niezawodnie odgadnąć identyfikatora serwera. Wątpliwości wyjaśnij z obsługą przed pobraniem danych.

Przykład: strona zajmuje 7 GB, baza 1 GB, a cztery skrzynki po 3 GB. Razem to 20 GB; własna rezerwa 25% oznacza wymaganie 25 GB, bez archiwów tworzonych na tym samym koncie. Jeśli pozostawiasz pocztę osobno, do nowego WWW nie przenoś mechanicznie całych 12 GB skrzynek. Zapisz wybraną granicę migracji i sprawdź hosting docelowy według miejsca, kopii i pomocy migracyjnej.

2. Pobierz pliki z właściwego CloudHosting

W CloudHosting Panel otwórz WWW I FTP → Wykaz kont FTP. Ustal, czy konto ma dostęp do katalogu właściwej witryny. Nie zmieniaj ograniczeń IP na całkowicie otwarty dostęp tylko dlatego, że wykonawca nie może się połączyć; uzgodnij wąski dostęp na czas prac.

1. W WinSCP wybierz protokół SFTP, host odczytany z własnej usługi, port 22 i właściwego użytkownika. Nazwa server12345.nazwa.pl z dokumentacji jest wzorem, nie adresem Twojego konta.
2. Zweryfikuj klucz serwera z zaufanymi danymi operatora. Pobierz rozpoznany katalog aplikacji do bezpiecznego miejsca na komputerze, uwzględniając pliki ukryte.
3. Zachowaj oryginalny wp-config.php i odczytaj z niego nazwę bazy oraz prefiks tabel. Nie wysyłaj tego pliku w publicznym zgłoszeniu.
4. Sprawdź raport transferu, ostatnio dodane media i pliki spoza standardowych katalogów WordPressa, jeżeli aplikacja z nich korzysta.

Jeśli używasz CloudHosting WordPress, zatrzymaj ręczne kopiowanie całej struktury serwera i ustal eksport konkretnej instalacji. Oficjalna dokumentacja ostrzega, że wspólne katalogi tej usługi wpływają na pozostałe strony i przyszłe instalacje. Wykonawca powinien potwierdzić zakres, zamiast usuwać pliki, których roli nie rozpoznaje.

3. Wyeksportuj bazę, nie tylko treść z panelu WordPressa

Eksport wpisów z WordPressa nie jest kopią całej bazy i konfiguracji dodatków. Otwórz opisane przez nazwa.pl narzędzie phpMyAdmin dla MariaDB pod adresem https://mariadb.nazwa.pl/, zaloguj się użytkownikiem przypisanym do właściwej bazy i wybierz ją w drzewie po lewej. W zakładce Eksport przygotuj SQL obejmujący wszystkie tabele tej instalacji i zapisz wynik lokalnie.

Przed wykorzystaniem zrzutu potwierdź jego kompletność oraz to, że polecenia USE, CREATE DATABASE lub DROP DATABASE nie przełączają operacji na inną bazę. Przy współdzielonej bazie lub dużym pliku poproś o przygotowanie właściwego zakresu. Nie rozpakowuj eksportu SQL w katalogu dostępnym z internetu. Pliki i bazę pobierz z uzgodnionego momentu; sklep po pierwszej kopii może przyjąć kolejne zamówienia.

4. Odizoluj cel i dopiero potem odtwórz instalację

Przed importem uzgodnij blokadę wychodzącego SMTP, płatności, API i webhooków kopii oraz wyłączenie zadań serwera. Ogranicz dostęp do witryny próbnej. Noindex nie zabezpiecza danych, a wyłączenie WP-Cron nie blokuje samodzielnych połączeń wtyczek. Jeśli nowy hosting nie umożliwia potrzebnej izolacji, zleć administratorowi przygotowanie bezpiecznej próby zamiast uruchamiać kopię produkcji.

1. W DirectAdmin wybierz Zarządzanie kontami → Zarządzanie domenami → Dodaj nową, wpisz domenę bez https:// i ścieżki, zatwierdź i sprawdź listę. Samo dodanie domeny nie zmienia publicznego DNS.
2. Potwierdź pusty katalog tej domeny i zgodność PHP oraz rozszerzeń. Nie nadpisuj działającego projektu znajdującego się na tym samym koncie.
3. W sekcji Bazy danych → Utwórz bazę danych utwórz pustą bazę i odrębnego użytkownika. Potwierdź jego uprawnienia tylko do niej; odczytaj pełną nazwę, host i dane połączenia z panelu.
4. W lokalnej kopii wp-config.php ustaw nowe DB_NAME, DB_USER, DB_PASSWORD i DB_HOST, zachowaj prefiks tabel oraz ustaw DISABLE_WP_CRON na true. Konfiguracja musi wskazywać cel przed przesłaniem i pierwszym wywołaniem PHP.
5. Prześlij przygotowane pliki szyfrowanym transferem. W docelowym phpMyAdmin zaznacz wyłącznie nową pustą bazę, otwórz Import i załaduj sprawdzony SQL. Oczekuj pełnego zakończenia bez błędów.

Gdy import się przerwie, nie zgaduj, które tabele już działają. Zabezpiecz wynik, wyjaśnij błąd i uzgodnij ponowne odtworzenie wyłącznie tej nowej bazy. Nie przełączaj DNS, dopóki instalacja nie jest spójna. Pełny plan kontroli, lokalny podgląd hosts i uzgodnienie danych po powrocie opisuje instrukcja migracji WordPressa.

5. Sprawdź stronę bez polegania na starej warstwie CDN

CDN nazwa.pl buforuje elementy statyczne, a jego aktywacja przy CloudHosting może być automatyczna. Wczytanie dawnego obrazka z pamięci podręcznej nie dowodzi poprawnego skopiowania plików. W uzgodnionym podglądzie nowego serwera sprawdź kilka konkretnych mediów, najnowszą treść, bezpośrednie podstrony i zapis w panelu.

Przy zachowanej domenie nie wykonuj globalnej zamiany adresów w bazie. Użyj kontrolowanego mapowania hosts z faktycznym nowym IP, prawidłowym certyfikatem i potwierdzeniem serwera w logu. Zachowaj oryginalne reguły cache oraz .htaccess, ale ich zgodność na celu uzgodnij osobno. Funkcje CDN, WAF i konwersji obrazów nie przenoszą się automatycznie razem z motywem WordPressa.

6. Przenieś pocztę oraz osobno kontakty Cloud Mail

Przy zmianie dostawcy poczty utwórz docelowe konta, limity, aliasy i przekierowania przed zmianą MX. Uzgodnij pierwsze kopiowanie IMAP oraz końcowe dosynchronizowanie ze źródła do celu. Sprawdź folder wysłanych, załączniki i próbki starszych wiadomości. Dostęp do starej skrzynki zachowaj do wyjaśnienia różnic.

W Cloud Mail otwórz Książkę adresową, wybierz grupę, na przykład Kontakty osobiste albo Automatycznie zbierane, i użyj Eksportuj. Zapisany vCard (.vcf) przechowuj prywatnie i zaimportuj do właściwego programu po sprawdzeniu próbek. Kalendarze, filtry, podpisy, lokalne archiwa POP i konfigurację urządzeń zinwentaryzuj oddzielnie; samo IMAP ich nie potwierdza.

7. Przeniesienie strony z nazwa.pl: przełączenie i odbiór

Ustal okno ostatnich zapisów, końcowy eksport bazy i mediów oraz synchronizację skrzynek. Przed każdym importem potwierdź nową bazę i zachowanie konfiguracji celu. Następnie zmień tylko uzgodnione A/AAAA/www oraz MX, jeśli przenosisz pocztę. Przy pozostawieniu strefy u dotychczasowego operatora zachowaj potrzebną usługę DNS; przy zmianie NS odtwórz kompletną strefę i uwierzytelnianie wszystkich nadawców.

Usuń lokalne mapowanie hosts, sprawdź normalny dostęp, HTTPS, formularz na kontrolowaną skrzynkę i oba kierunki poczty. Produkcyjne zadania oraz integracje uruchom tylko na jednym serwerze. Przy błędzie zabezpiecz nowe dane przed cofnięciem ruchu — zamówienia nie wracają ze zmianą DNS.

Przeniesienie strony z nazwa.pl zakończ kontrolą danych i pozostawionych usług. Dopiero po odbiorze w Panelu Klienta otwórz Usługi → Hosting → Szczegóły → Płatności → Rezygnacja z usługi i sprawdź dokładnie identyfikator oraz datę. Dokumentacja wskazuje, że rezygnacja z odnowienia usługi głównej obejmuje jej aktywne dodatki. Nie wyłącz przypadkiem poczty, DNS lub kopii, które nadal są potrzebne. Nie przenoś tych ścieżek do innych paneli: migracja z home.pl wymaga rozpoznania odmiennych miejsc eksportu. Koszt dalszego utrzymania porównaj z wariantami alternatywy dla nazwa.pl, uwzględniając także okres równoległego działania.

Dlaczego jedni widzą nową stronę, a inni poprzednią?

Załóżmy, że w próbie nowy WordPress działa poprawnie, ale po zmianie publicznego skierowania jedna osoba widzi starą stronę, a druga nową. To nie musi oznaczać niekompletnego importu. Sprawdź aktywną strefę DNS, wszystkie używane nazwy i oba rodzaje adresów. Stary rekord AAAA może nadal kierować po IPv6 na wcześniejszy serwer, mimo poprawnej zmiany rekordu A dla IPv4. Osobno odróżnij pozostałość pamięci podręcznej od rzeczywiście innej konfiguracji.

Jeżeli strefa faktycznie jest obsługiwana w nazwa.pl i masz już aktywną ręczną konfigurację, dokumentacja prowadzi przez Panel Klienta → Usługi → Domeny → konfiguruj, a następnie ZMIEŃ do edycji. Zanim cokolwiek zapiszesz, zachowaj pełną obecną strefę. Nie włączaj ręcznej konfiguracji w ciemno: jej aktywacja może zmienić delegację, dotychczasowe przekierowania i domyślne zabezpieczenia poczty. Przy strefie obsługiwanej gdzie indziej właściwym miejscem zmiany jest aktywny dostawca DNS.

1. Odczytaj oddzielnie domenę bez www oraz z www, rekord A i ewentualny AAAA. Uzgodnij z nowym operatorem prawidłowy adres lub sposób obsługi IPv6. Nie kasuj wszystkich rekordów AAAA domeny bez rozpoznania ich usług.
2. Usuń z komputera testowego wcześniejsze mapowanie hosts i sprawdź zwykłe połączenie. Porównaj je z widokiem przez inną własną sieć, np. telefon komórkowy. Odmienny wynik to wskazówka do sprawdzenia DNS i cache, nie automatycznie powód ponownego importu bazy.
3. W logu lub z administratorem potwierdź, który serwer odpowiada. Sprawdź najnowszy wpis i konkretny plik z celu; stary obraz z CDN nie potwierdza poprawnego nowego katalogu.
4. Jeżeli poczta została w nazwa.pl, sprawdź MX oraz właściwe rekordy nadawców i nie rezygnuj z usługi, która ją utrzymuje. Jeżeli ją przenosisz, wykonaj wcześniej opisane osobne kopiowanie i końcową synchronizację.

Nie obiecuj wszystkim jednej godziny zakończenia. Dokumentacja nazwa.pl opisuje wpływ TTL i pamięci pośrednich na czas zauważenia zmiany. Odczekanie nie naprawi jednak stale błędnego AAAA lub www. Jeżeli po weryfikacji rekordy są poprawne, a część użytkowników nadal widzi wcześniejszy stan, zachowaj stare środowisko i obserwuj odpowiedzi zgodnie z uzgodnionym planem. Nie uruchamiaj równolegle prawdziwych zamówień na obu kopiach tylko dlatego, że obie jeszcze się otwierają.

Źródła i data weryfikacji

Materiały odczytano 30.10.2026. Procedura nie zastępuje potwierdzenia zakresu konkretnej usługi i nie jest raportem z wykonanej przeprowadzki.

• nazwa.pl: rozpoznanie serwera WWW i poczty.
• nazwa.pl: Wykaz kont FTP i zakres dostępu.
• nazwa.pl: SFTP w WinSCP, port 22.
• nazwa.pl: odrębna struktura CloudHosting WordPress.
• nazwa.pl: phpMyAdmin i eksport.
• DirectAdmin: dodanie obsługi domeny bez zmiany DNS.
• DirectAdmin: nowa baza i użytkownik.
• phpMyAdmin: import do wskazanej bazy.
• nazwa.pl: automatyczna warstwa CDN i cache.
• Cloud Mail: eksport kontaktów do vCard.
• nazwa.pl: rezygnacja z odnowienia i dodatki.
• nazwa.pl: ręczna strefa DNS i skutki jej aktywacji.
• nazwa.pl: różne odpowiedzi podczas propagacji i wpływ TTL.