Migracja WordPress Multisite: kompletny poradnik na 2026 rok

Prawdopodobnie jesteś teraz w jednej z dwóch sytuacji. Albo sieć multisite przerosła serwer, model zarządzania lub strukturę adresów URL, od których zaczynała, albo ktoś po stronie biznesu zdecydował, że jedna z podwitryn ma stać się osobną platformą, i to bez utraty widoczności w wyszukiwarce, bez rozbijania procesów redakcyjnych i bez wpływu na przychody.

W tym momencie migracja WordPress Multisite przestaje być rutynowym zadaniem hostingowym i staje się projektem inżynieryjnym. Samo techniczne przeniesienie ma znaczenie, ale większe ryzyko zwykle kryje się gdzie indziej: licencja wtyczki, która po wydzieleniu przestaje się weryfikować, konfiguracja wielojęzyczna, która gubi tagi canonical, biblioteka mediów, która wygląda dobrze, dopóki redaktorzy trzy dni później nie odkryją uszkodzonych plików, albo plan wycofania, który istnieje tylko jako mglista obietnica.

Najczystsze migracje, jakie widziałem, przebiegają według tego samego schematu. Traktują przeniesienie bazy danych jako jeden z elementów większej, kontrolowanej zmiany. Wcześnie zamykają zakres, testują jak śledczy i zakładają, że coś zawiedzie, dopóki nie zostanie zweryfikowane. To podejście sprawia, że migracja multisite nie zamienia się w nocny incydent.

Strategia przed migracją i ocena ryzyka

Piątek, 20:40. Za chwilę przełączenie DNS, import bazy danych się zakończył, a ktoś pyta, czy zachowano tagi hreflang francuskiej podwitryny i które licencje płatnych wtyczek przetrwają przeniesienie. Jeśli to pytanie pada w noc migracji, planowanie zawiodło.

Migracja WordPress Multisite zaczyna się od kontroli zakresu i planowania na wypadek awarii. Baza danych i pliki są ważne, ale projekty wysokiego ryzyka zwykle sypią się na kwestiach ciągłości działania: licencjach wtyczek powiązanych ze starą domeną lub typem instalacji, regułach wielojęzycznego SEO, które znikają po wydzieleniu, i planach wycofania, które brzmią dobrze, dopóki ktoś pod presją nie musi zdecydować, czy cofnąć DNS.

Traktuj plan jak runbook na wypadek incydentu. Zanim ktokolwiek dotknie produkcji, plan powinien odpowiadać na cztery pytania:

1. Co dokładnie jest przenoszone
2. Co musi pozostać dostępne
3. Co uruchamia wycofanie
4. Kto ma uprawnienia, aby zatwierdzić uruchomienie lub je cofnąć

Określ zakres migracji, zanim wybierzesz narzędzia

„Przenieść multisite” to nie jest użyteczny zakres. W praktyce zlecenie jest często bardziej zagmatwane: wydzielić jedną generującą przychód podwitrynę do osobnej instalacji WordPress, zostawić dwie starsze podwitryny, zachować zmapowane domeny, zapewnić redaktorom możliwość pracy w poniedziałek rano i nie stracić pozycji w trzech językach.

Najpierw spisz inwentarz.

• Każda podwitryna: obecny adres URL, zmapowana domena, właściciel biznesowy i tolerancja na przestój
• Model aktywacji: wtyczki aktywowane sieciowo kontra wtyczki na poziomie witryny
• Własny kod: mu-plugins, drop-iny, własne tabele, zadania cron, webhooki i nadpisania motywu
• Wspólne zależności: odwołania do mediów, integracje API, SSO, formularze, wyszukiwarka i skrypty analityczne

Jeśli nikt nie potrafi powiedzieć, które podwitryny mogą być niedostępne i jak długo, migracja nie jest gotowa.

To także moment, w którym zespoły decydują, czy zrealizować pracę we własnym zakresie, czy zaangażować specjalistę od usług migracji WordPress. Kompromis jest prosty. Zespoły wewnętrzne znają stos technologiczny. Zewnętrzni wykonawcy często wnoszą bardziej uporządkowany runbook, lepszą dyscyplinę wycofywania i mniej założeń.

Przeanalizuj punkty awarii, które bolą po uruchomieniu

Eksport i import bazy danych to łatwa część. Kosztowne awarie pojawiają się później, gdy witryna wygląda na „w zasadzie w porządku”.

Licencjonowanie wtyczek to częsty przypadek. Płatne wtyczki mogą weryfikować licencję po domenie głównej, kontekście sieci, liczbie witryn lub środowisku. Podwitryna wydzielona z multisite może poprawnie się uruchomić, a mimo to stracić dostęp do aktualizacji, renderowania pól, funkcji tłumaczeń lub integracji z kasą, bo licencja nie pasuje już do nowej instalacji. Sprawdź warunki dostawcy przed przeniesieniem, a nie po nim.

Wielojęzyczne SEO wymaga takiej samej uwagi. Jeśli sieć używa WPML, Polylang, własnego generowania hreflang, adresów canonical dla poszczególnych rynków lub przetłumaczonych slugów, udokumentuj obecne zachowanie. Chodzi o tagi title, adresy canonical, tagi hreflang, mapy witryny XML, reguły przekierowań i szablony zależne od lokalizacji. Witryna może przejść wizualną kontrolę jakości, a mimo to stracić wartość w wyszukiwarce, bo warstwa metadanych niepostrzeżenie się zmieniła.

Media to kolejna pułapka. W multisite redaktorzy często wklejają adresy plików między podwitrynami, używają własnych pól odwołujących się do starych ścieżek uploadu albo polegają na wtyczkach, które zmieniają obsługę mediów. Uszkodzone miniatury są irytujące. Uszkodzone dokumenty, materiały kampanii i zlokalizowane pliki PDF szybko generują zgłoszenia do supportu.

Zbuduj rejestr ryzyk, z którego naprawdę da się korzystać

Niech będzie na tyle krótki, żeby osoba prowadząca migrację przeczytała go w trakcie przełączenia.

Ustal obiektywne warunki wycofania

Wycofanie nie powinno zależeć od pewności siebie, nastroju ani od tego, kto najgłośniej mówi na callu. Ustal mierzalne warunki przed uruchomieniem.

Przykłady:

• Nie działa dostęp administracyjny dla głównych właścicieli witryn
• Nie działają kasa, formularze kontaktowe lub logowanie
• Mapowanie domen kieruje ruch do niewłaściwej podwitryny
• Na stronach produkcyjnych brakuje kluczowych metadanych wielojęzycznych
• Licencjonowanie wtyczek wyłącza wymagane funkcje
• Liczba błędów gwałtownie rośnie i nie da się jej skorygować w oknie serwisowym

Zapisz próg i uzyskaj akceptację osoby prowadzącej migrację, właściciela produktu i osoby kontrolującej DNS. Zalecam też spisanie dokładnych poleceń i działań na potrzeby wycofania, a nie tylko reguły decyzyjnej. W prawdziwych incydentach jasność wygrywa z optymizmem.

Jeśli na przykład wycofanie obejmuje przywrócenie starej bazy danych i wymuszenie powrotu DNS, zapisz kolejność:

# Example rollback checks
wp site list
wp plugin list --network
wp search-replace 'https://new.example.com' 'https://old.example.com' --network --dry-run

Używaj przebiegów próbnych (dry run) na etapie planowania, aby potwierdzić, że zespół ma dostęp, który wydaje mu się, że ma. W noc migracji brak uprawnień do WP-CLI lub zły klucz SSH zjada czas potrzebny na odzyskanie sprawności.

Dobre migracje multisite to kontrolowane zmiany. Zespoły, które przechodzą przez nie bez problemów, wcześnie ustalają zakres, dokumentują ukryte zależności, testują zachowanie licencji i SEO przed przełączeniem i definiują wycofanie tak, jakby spodziewały się go użyć.

Przygotowanie środowisk i DNS

Większość nieudanych migracji zaczyna się od niezgodności między starym a nowym środowiskiem. Nie dramatycznej niezgodności. Cichej. Brakującego rozszerzenia PHP na serwerze docelowym, problemu z uprawnieniami w uploads, luki w regułach przepisywania albo zmian DNS zostawionych na ostatnią godzinę.

Nowe środowisko powinno być nudne. O to właśnie chodzi. Jeśli środowisko docelowe zachowuje się inaczej niż źródłowe w sposób, którego nie uwzględniłeś, migracja ujawni te różnice jako zerwane sesje, problemy z mediami lub awarie wtyczek.

Zbuduj środowisko docelowe zgodne ze źródłowym

Zacznij od czystej instalacji WordPress na serwerze docelowym i przygotuj ją pod multisite, zanim cokolwiek zaimportujesz. Jeśli przenosisz się do nowej sieci, odtwórz ten sam układ strukturalny, którego już używasz. Nie zmieniaj podkatalogów na subdomeny w ramach tej samej migracji, chyba że masz ku temu ważny powód i osobną ścieżkę testów.

Na tym etapie potwierdź:

• Zgodność PHP: Dopasuj obsługiwane wersje wymagane przez obecny motyw i zestaw wtyczek.
• Dostęp do bazy danych: Przetestuj dostęp z CLI, uprawnienia do importu i zachowanie przy tworzeniu tabel.
• Własność systemu plików: Upewnij się, że WordPress może zapisywać w odpowiednich katalogach bez obchodzenia uprawnień.
• Dostęp do powłoki: Potwierdź dostęp przez SSH i WP-CLI przed dniem migracji.
• Poczta i usługi zewnętrzne: Przygotuj wszystko, czego sieć potrzebuje do formularzy, procesów transakcyjnych lub webhooków.

Dla zespołów, które przenoszą infrastrukturę w ramach zmiany hostingu, to moment, w którym przydaje się praktyczny przewodnik po przenoszeniu witryny WordPress do nowego hostingu, bo zmiana hostingu i migracja multisite często nakładają się operacyjnie, nawet jeśli ścieżka danych jest inna.

Przygotuj DNS zarówno na uruchomienie, jak i na odwrót

Planowanie DNS dostaje za mało uwagi w większości poradników o migracji. A powinno dostawać więcej. Chcesz, żeby ostateczne przełączenie było szybkie, ale chcesz też, żeby odwrót był szybki, jeśli walidacja na produkcji zawiedzie.

Kluczowy nawyk to obniżenie TTL z dużym wyprzedzeniem przed oknem migracji. Daje to czystsze przełączenie i realną możliwość wycofania. Jeśli przygotujesz DNS zbyt późno, nadal możesz przeprowadzić migrację, ale okno odzyskiwania staje się trudniejsze do kontrolowania.

Skorzystaj z tej listy kontrolnej przed przełączeniem:

• Obniż TTL wcześnie: Zrób to na długo przed uruchomieniem, a nie w jego trakcie.
• Udokumentuj zmapowane domeny: Szczególnie w sieciach multisite z domenami dla marek, wersji językowych lub klientów.
• Potwierdź pokrycie SSL: Subdomeny i zmapowane domeny muszą poprawnie się rozwiązywać po przełączeniu.
• Przygotuj hosty weryfikacyjne: Używaj niepublicznych metod walidacji, aby przetestować routing przed zmianą ruchu produkcyjnego.

Nie pomijaj czystej instalacji

Wiele zespołów chce najpierw skopiować całą starą instalację i „posprzątać później”. Zwykle przenosi to stare założenia do nowego środowiska. Świeża instalacja docelowa daje znany punkt odniesienia i ułatwia izolowanie awarii.

Jeśli przeniesienie obejmuje zamianę samodzielnej witryny w podwitrynę albo najpierw utworzenie sieci na serwerze docelowym, przygotowanie środowiska musi też uwzględniać stałe multisite i strukturę witryn, których będą oczekiwać importowane dane. To w tym miejscu projekty migracyjne albo pozostają pod kontrolą, albo zaczynają obrastać jednorazowymi poprawkami.

Pełna kopia zapasowa i migracja bazy danych

Na tym etapie jedno złe polecenie może położyć każdą witrynę w sieci. W multisite użytkownicy, role, tabele witryn, ustawienia sieci i wiele danych wtyczek są ze sobą powiązane. Niedbały import nie kończy się czystą porażką. Tworzy częściowe uszkodzenia, które redaktorzy znajdują kilka dni później.

Są dwie sensowne ścieżki. Użyj wtyczki migracyjnej przystosowanej do multisite albo przeprowadź przeniesienie przez WP-CLI i samodzielnie kontroluj każdy krok. Korzystam z obu. Właściwy wybór zależy od wielkości sieci, okna zmian i tego, ile dyscypliny operacyjnej zespół jest w stanie utrzymać o 2:00 w nocy.

Wybierz metodę migracji na podstawie ryzyka, a nie preferencji

Wtyczka jest często bezpieczniejsza, gdy projekt ma krótkie okno serwisowe, mniej doświadczony zespół przejmujący prace albo sieć z wieloma podwitrynami i zmapowanymi domenami. All-in-One WP Migration pozostaje częstym wyborem, bo pakuje sieć w sposób ograniczający błędy na poziomie tabel i podczas importu wykonuje wyszukiwanie i zamianę świadome specyfiki WordPressa. Ta ochrona ma znaczenie w multisite, bo zserializowane wartości znajdują się w opcjach, widżetach, danych page builderów i ustawieniach wtyczek w całej sieci.

WP-CLI sprawdza się lepiej, gdy potrzebujesz powtarzalności opartej na skryptach, selektywnych zamian, kontroli specyficznej dla środowiska lub dziennika migracji, który można przekazać innemu inżynierowi podczas wycofania. To także lepsza opcja, gdy wymagania korporacyjne wykraczają poza samo przeniesienie danych. Licencjonowanie wtyczek może się zepsuć po zmianie domeny lub serwera. Wtyczki wielojęzyczne często przechowują metadane SEO we własnych tabelach lub zserializowanych zestawach opcji. Jeśli te wartości nie zostaną czysto przeniesione, pozycje w wyszukiwarce i aktywacje licencji mogą spaść jednocześnie.

Jeśli środowisko docelowe budujesz od zera, zacznij od czystej sieci zgodnej ze strukturą, której oczekują importowane dane. Ma to jeszcze większe znaczenie, gdy zamieniasz samodzielną instalację w sieć lub zmieniasz tryb subdomen na podkatalogi albo odwrotnie. Przed importem skorzystaj z udokumentowanego procesu instalacji i konfiguracji WordPress Multisite, aby baza danych trafiła do sieci z właściwymi stałymi i założeniami dotyczącymi tabel.

Proces WP-CLI dla zespołów, które potrzebują kontroli

Zacznij od pełnego eksportu. Nie częściowego zrzutu. Nie „tylko tabel aktywnej witryny”. Całej sieci.

wp db export network-backup.sql --all-tables

Przed zmianą adresów URL wykonaj przebieg próbny i przejrzyj wynik:

wp search-replace 'old-domain.com' 'new-domain.com' --network --precise --recurse-objects --all-tables --dry-run

Jeśli zakres wygląda poprawnie, wykonaj właściwą zamianę:

wp search-replace 'old-domain.com' 'new-domain.com' --network --precise --recurse-objects --all-tables

Te flagi wykonują realną pracę. --network zapobiega rozjazdom między poszczególnymi witrynami. --precise poświęca szybkość na rzecz dokładności, co podczas migracji jest zwykle właściwym wyborem. --recurse-objects chroni zserializowane struktury. --all-tables obejmuje tabele wtyczek i własne tabele, o których zespoły zapominają, dopóki nie zawiedzie coś krytycznego dla biznesu.

Zserializowane dane to mina. Jeśli narzędzie nie rozumie serializacji WordPressa, trzymaj je z dala od bazy danych.

Najważniejsze polecenia WP-CLI search-replace dla multisite

Twórz kopię zapasową sieci tak, jakbyś spodziewał się wycofania

Użyteczny zestaw kopii zapasowych to coś więcej niż eksport SQL leżący we wspólnym folderze. W przypadku sieci o wysokiej stawce chcę mieć cztery rzeczy, zanim ktokolwiek dotknie produkcji:

• Pełny zrzut bazy danych: Uwzględnij tabele sieci, tabele użytkowników, tabele wtyczek i wszystko, co niestandardowe.
• Migawka wp-content: Motywy, wtyczki, mu-plugins, uploady, pliki językowe i kod własnych integracji.
• Kopie konfiguracji: wp-config.php, ustawienia object cache, reguły vhostów serwera oraz wszelka konfiguracja cron lub workerów powiązana z siecią.
• Notatki dotyczące odtwarzania: Dokładna lokalizacja kopii, kto ją zweryfikował, która wersja została zapisana i ile ma potrwać odtworzenie.

To także moment, aby wyeksportować wszystko, co może nie przetrwać zwykłego przeniesienia plików i bazy danych. Klucze licencyjne płatnych wtyczek to częsty przykład. Niektórzy dostawcy wiążą aktywacje z domenami, adresami IP lub odciskami maszyn. Tam, gdzie to zasadne, dezaktywuj licencje, udokumentuj obecne aktywacje i potwierdź warunki ponownego wydania przed przełączeniem. Jeśli w sieci działają wielojęzyczne wtyczki SEO, sprawdź, gdzie przechowywane są dane hreflang, przetłumaczone slugi, reguły przekierowań i metadane SEO. Utrata tych danych nie zawsze objawia się błędem PHP. Objawia się spadkiem ruchu tydzień później.

Powtarzające się błędy bazodanowe w projektach multisite

Te same awarie pojawiają się raz po raz:

• Uruchamianie surowego SQL replace na zserializowanej treści
• Eksportowanie tylko widocznych tabel witryn i pomijanie tabel sieci lub wtyczek
• Import do środowiska z niewłaściwym trybem multisite lub błędnymi założeniami co do prefiksu tabel
• Zapominanie o ponownej aktywacji licencji wtyczek, dopóki kluczowe funkcje nie przestaną działać
• Zmiana domen głównych bez sprawdzenia wielojęzycznych pól SEO, tagów canonical lub odwołań hreflang

Rozwiązanie nie jest skomplikowane, ale wymaga dyscypliny. Eksportuj całą sieć. Zapisuj każde polecenie. Testuj zamiany z --dry-run. Zachowaj nienaruszoną kopię bazy danych sprzed migracji. W migracjach korporacyjnych historia poleceń, artefakty SQL i inwentarze licencji są częścią ciągłości działania, a nie dodatkową papierologią.

Migracja plików i konfiguracja sieci

Piątkowe nocne przełączenia zawodzą tutaj częściej niż gdziekolwiek indziej. Baza danych importuje się czysto, strona główna się wyświetla, wszyscy się odprężają, a potem redaktorzy odkrywają brakujące media, licencjonowane wtyczki przechodzą w tryb ograniczony albo zmapowana witryna regionalna zaczyna serwować niewłaściwe zasoby. W migracji multisite system plików i konfiguracja sieci decydują o tym, czy uruchomienie jest stabilne, czy tylko wygląda na stabilne przez pierwsze dziesięć minut.

Katalogiem najwyższego ryzyka jest zwykle wp-content/uploads. Jest duży, nieuporządkowany i pełen plików krytycznych dla biznesu, których nikt nie zauważa, dopóki nie zniknie landing page kampanii, przetłumaczony PDF lub zdjęcie produktu.

Przenoś pliki: najpierw integralność, potem szybkość

W dużych sieciach rsync jest domyślnym wyborem, bo zachowuje strukturę, potrafi czysto wznowić transfer i daje metodę, którą można uruchomić więcej niż raz przed przełączeniem. To ma znaczenie. Jednorazowe kopiowanie wszystkiego naraz trudniej zweryfikować i trudniej mu zaufać.

Standardowy wzorzec wygląda tak:

rsync -avz --progress /path/to/source/wp-content/ /path/to/destination/wp-content/

W sieciach korporacyjnych dzielę transfer na etapy. Najpierw kopiuję motywy, wtyczki i mu-plugins. Uploady kopiuję osobno. Potem tuż przed przełączeniem wykonuję końcową synchronizację, aby przenieść tylko zmienione pliki:

rsync -avz --delete /path/to/source/wp-content/uploads/ /path/to/destination/wp-content/uploads/

Flaga --delete jest przydatna, ale tylko wtedy, gdy masz pewność, że środowisko docelowe jest jednorazowe lub już zweryfikowane. Użyta nieostrożnie może usunąć zasoby, które zostały ręcznie przygotowane na serwerze docelowym.

Unikaj do tej pracy długich sesji FTP. Są wolne, ukrywają częściowe niepowodzenia i zostawiają nieczytelny ślad, gdy ktoś pyta, które pliki zostały przeniesione. W przypadku dużych katalogów uploadów stopniowe kopiowanie przez rsync to praktyczny sposób na zachowanie integralności plików przy zachowaniu powtarzalności transferu.

Uprawnienia wymagają osobnego sprawdzenia. Jeśli właściciel lub tryby plików zmienią się podczas przenoszenia, generowanie obrazów, zapisy cache i aktualizacje wtyczek mogą zawodzić po uruchomieniu. Zweryfikuj je jawnie:

find /path/to/destination/wp-content -type d -exec chmod 755 {} ;
find /path/to/destination/wp-content -type f -exec chmod 644 {} ;
chown -R www-data:www-data /path/to/destination/wp-content

Poprawnie skonfiguruj multisite w wp-config.php

Środowisko docelowe musi odpowiadać modelowi sieci, którą migrujesz. Drobna literówka w wp-config.php może objawiać się pętlami logowania, uszkodzonymi ciasteczkami albo podwitrynami kierującymi do witryny głównej.

Jeśli włączasz multisite na serwerze docelowym, dodaj:

define('WP_ALLOW_MULTISITE', true);

Ta stała powinna znaleźć się bezpośrednio przed linią /* That's all, stop editing! Happy publishing. */. Po zakończeniu konfiguracji sieci WordPress generuje pozostałe stałe multisite i reguły przepisywania na podstawie trybu subdomen lub podkatalogów. Zachowaj te wygenerowane wartości dokładnie w takiej postaci. Ręczne edytowanie ich bez powodu to sposób, w jaki działające sieci stają się niespójne.

Jeśli podczas weryfikacji decyzji architektonicznych potrzebujesz materiału o samej instalacji, ten przewodnik po instalacji WordPress Multisite przyda się, zanim zatwierdzisz konfigurację docelową.

Dwa ustawienia wymagają podczas migracji szczególnej uwagi: struktura domen i założenia dotyczące ścieżek. Jeśli sieć źródłowa używała podkatalogów, a docelowa jest odbudowywana na subdomenach, ustawienia wtyczek, logika przekierowań i ścieżki wielojęzycznego SEO mogą przestać pasować do zapisanych oczekiwań. Strona główna nadal może się ładować, podczas gdy odwołania hreflang, adresy canonical i adresy mediów dla poszczególnych wersji językowych przestają działać.

Przewodnik Updraft o konwersji WordPressa do multisite przypomina też, że WP_ALLOW_MULTISITE to tylko punkt wejścia. W projektach zamiany pojedynczej witryny w podwitrynę liczą się stan wtyczek i właściwy cel odtwarzania. Odtworzenie w niewłaściwym kontekście witryny może nadpisać niewłaściwe tabele albo zostawić podwitrynę skonfigurowaną jak samodzielną instalację.

Wybierz strukturę na podstawie działalności, a nie preferencji

Subdomeny i podkatalogi są równie poprawne. Właściwy wybór zależy od tego, jak działa firma.

• Subdomeny sprawdzają się lepiej, gdy każda witryna jest traktowana jako osobna marka, kraj lub podmiot prawny z własnym DNS, SSL i procesami marketingowymi.
• Podkatalogi sprawdzają się lepiej, gdy sieć działa jak jedna platforma publikacyjna ze wspólnym autorytetem i ściśle powiązanymi treściami.
• Zmapowane domeny zwiększają ryzyko operacyjne, bo każda zmapowana witryna dokłada kwestie SSL, DNS, przekierowań, cache i wycofania.

To także miejsce, w którym wychodzą na jaw konflikty licencyjne wtyczek. Niektóre płatne wtyczki są licencjonowane na domenę, środowisko lub aktywną witrynę. Sieć, która działała na serwerze źródłowym, może po migracji nagle pokazywać wyłączone funkcje na zmapowanych domenach. Sprawdź panele licencji przed uruchomieniem, zwłaszcza w przypadku wtyczek SEO, formularzy, tłumaczeń i page builderów. Te awarie nie zawsze powodują widoczny błąd. Objawiają się brakującymi danymi schema, zablokowanymi aktualizacjami lub komunikatami w panelu, które widzą tylko administratorzy sieci.

Oto przydatne omówienie, zanim sfinalizujesz te ustawienia:

Nie przeocz kodu, który znajduje się poza motywem

Awarie multisite często wynikają z kodu, którego od początku nie było w aktywnym motywie.

Sprawdź wszystkie poniższe elementy:

• Wtyczki obowiązkowe (must-use)
• Drop-iny
• Własne skrypty cron
• Pliki dołączane zależne od środowiska
• Zależności od reguł przepisywania na serwerze

Sprawdź też drop-iny object cache, konfigurację sunrise, jeśli zależy od niej mapowanie domen, oraz wszelkie dowiązania symboliczne tworzone przy wdrożeniu. Te elementy często obsługują uwierzytelnianie, przekierowania, cache stron, obsługę obrazów i routing wielojęzyczny. Jeśli któregoś brakuje, sieć może wyglądać na działającą, podczas gdy kluczowe ścieżki biznesowe zawodzą pod obciążeniem lub na domenach pomocniczych.

Traktuj przeniesienie systemu plików jak wdrożenie produkcyjne. Zinwentaryzuj go, synchronizuj etapami i najpierw zweryfikuj elementy wpływające na przychody, SEO i wycofanie.

Testy po migracji i mapowanie domen

Migracja nie jest zakończona, gdy ładuje się strona główna. To pierwszy ruch testów, a nie ich zakończenie. Sieć multisite może na pierwszy rzut oka wyglądać zdrowo, a jednocześnie ukrywać zepsute role użytkowników, nieprawidłowe ścieżki mediów, błędne przekierowania lub jedną zmapowaną domenę, która kieruje do niewłaściwej witryny.

Najszybszy sposób, aby to wychwycić, to traktować walidację po migracji jak pracę śledczą. Nie udowadniasz, że witryna się ładuje. Próbujesz udowodnić, że nie brakuje niczego krytycznego.

Zacznij od systemów najbardziej podatnych na awarie

Delicious Brains podaje, że nieprawidłowa obsługa ścieżek plików multimedialnych to częsta pułapka w migracjach multisite, występująca w około 35% ręcznych prób migracji, podczas gdy migracje automatyczne z kontrolami wstępnymi mogą osiągać 92% skuteczności, a migracje ręczne bez kontroli wstępnych kończą się niepowodzeniem w 28% przypadków, jak wynika z artykułu o wydzielaniu podwitryny z WordPress Multisite.

Te dane pokrywają się z tym, co zespoły widzą na produkcji. Media psują się jako pierwsze, bo zależą jednocześnie od struktury ścieżek, uprawnień i poprawności adresów URL.

Zacznij od:

• Biblioteki mediów: Otwieraj stare wpisy, nie tylko nowe. Sprawdź obrazy wyróżniające, galerie, obrazy w treści i pliki do pobrania.
• Dostępu administracyjnego: Zweryfikuj logowanie do Network Admin, do panelu podwitryn i dla poszczególnych ról.
• Kluczowych formularzy i transakcji: Przetestuj wysyłanie formularzy, wyszukiwanie, koszyki, treści z ograniczonym dostępem i akcje wyzwalane e-mailem.
• Wyników działania wtyczek: Sprawdź wszystko, co zapisuje własne adresy URL, osadza skrypty lub przechowuje dane we własnych tabelach.

Strona główna to najmniej przydatna strona testowa w migracji multisite. Prawdziwe szkody ujawniają się w głęboko osadzonych treściach.

Przeprowadź uporządkowany przegląd weryfikacyjny

Dobry przegląd po migracji przechodzi od kontroli na poziomie sieci do kontroli na poziomie podwitryn. Nie skacz między nimi.

Kontrole na poziomie sieci

• Rejestr witryn: Potwierdź, że istnieje każda oczekiwana podwitryna i że routing działa poprawnie.
• Współdzieleni użytkownicy: Przetestuj użytkownika należącego do kilku witryn i sprawdź jego uprawnienia w każdej z nich.
• Wtyczki sieciowe: Potwierdź, że wtyczki aktywowane sieciowo nadal działają zgodnie z przeznaczeniem.
• Dostępność motywów: Upewnij się, że włączone motywy są widoczne tam, gdzie powinny.

Kontrole na poziomie podwitryn

• Renderowanie frontendu: Sprawdź stronę główną, kluczowe landing page, archiwa wpisów i formularze.
• Doświadczenie redaktora: Otwórz edytor blokowy, uploader mediów, wzorce wielokrotnego użytku i własne pola.
• Zachowanie adresów URL: Sprawdź permalinki, paginację i przekierowania.
• Treści zlokalizowane: Przejrzyj treści i nawigację dla poszczególnych języków, jeśli sieć jest wielojęzyczna.

Prosty rejestr testów pomaga zespołom zachować uczciwość:

Mapuj domeny dopiero wtedy, gdy sieć przejdzie walidację

Mapowanie domen powinno być jednym z ostatnich kroków, a nie wczesnym strzałem. Gdy zaimportowana sieć jest stabilna na serwerze docelowym, kieruj każdą zmapowaną domenę świadomie i weryfikuj odpowiedź witryna po witrynie.

W sieciach wrażliwych na SEO mapowanie domen krzyżuje się też ze strukturą wyszukiwania. Jeśli wielojęzyczna podwitryna lub domena regionalna zmienia zachowanie po przeniesieniu, musisz sprawdzić adresy canonical, tagi alternate i ścieżki indeksowania. Jest to szczególnie istotne dla zespołów odpowiedzialnych za SEO w WordPress Multisite, gdzie routing techniczny i sygnały wyszukiwarki są ściśle powiązane.

Zapisz ponownie i sprawdź jeszcze raz, ale nie polegaj tylko na tym

Tak, ponowne zapisanie permalinków często pomaga po imporcie. Nie, to nie jest pełne rozwiązanie. Nie przywróci brakujących uploadów, nie rozwiąże problemów z licencjami wtyczek ani nie naprawi błędnie przypisanych ról.

Dojrzały cykl testów kończy się dopiero wtedy, gdy prawdziwi użytkownicy mogą wykonywać swoją pracę w nowej sieci. Do tego czasu migracja jest nadal tymczasowa.

Plany wycofania i optymalizacja uruchomienia

Godzina 2:07 w nocy, przełączenie DNS już działa, logowanie nadal funkcjonuje, a strona główna wygląda dobrze. Dziesięć minut później płatny ruch zaczyna trafiać na niewłaściwą witrynę regionalną, płatna wtyczka przechodzi w tryb próbny na dwóch podwitrynach, a adresy canonical wskazują z powrotem na starą domenę. To ta część migracji WordPress Multisite, której standardowe listy kontrolne nie doceniają. Transfer może się udać, a uruchomienie i tak może zawieść.

Wycofanie musi być procedurą operacyjną, a nie mglistą obietnicą „przywrócenia kopii zapasowej”. W pracy agencyjnej różnica jest prosta. Prawdziwy plan wycofania wskazuje dokładny punkt przywracania, ścieżkę poleceń, osobę, która może zatwierdzić odwrócenie zmian, osobę, która zmienia DNS, oraz warunki, które uruchamiają tę decyzję. Bez tego zespoły tracą od 30 do 60 minut na dyskusje, podczas gdy użytkownicy i roboty wyszukiwarek nadal trafiają na zepsuty stos.

Napisz plan tak, żeby dyżurny inżynier mógł go wykonać na wpół śpiący. Niech będzie krótki i konkretny:

1. Identyfikator wydania powiązany z ostatecznym zrzutem bazy danych i migawką plików
2. Polecenia przywracania dla bazy danych i uploadów
3. Osoba odpowiedzialna za cofnięcie DNS oraz ścieżka dostępu do rejestratora lub CDN
4. Notatki o odzyskiwaniu licencji wtyczek dla wszystkiego, co jest powiązane z domeną, adresem IP lub środowiskiem
5. Biznesowy warunek wycofania, na przykład awaria kasy, zablokowanie dostępu administratorów lub błędy routingu między domenami
6. Walidacja po wycofaniu dla kilku funkcji, które liczą się najbardziej

Jeśli na przykład docelowa baza danych jest już załadowana i musisz szybko się wycofać, runbook powinien zawierać dokładne polecenia, a nie odwołanie do „kopii zapasowej w S3”:

wp db import /backups/prod-prelaunch.sql
rsync -av /backups/uploads/ wp-content/uploads/
wp cache flush

Jeśli w grę wchodzi object cache lub Redis, dodaj także to polecenie. Jeśli przekierowania obsługuje warstwa brzegowa, zanotuj, czy wycofanie obejmuje wyłączenie reguł stron lub nadpisań originu. Widziałem technicznie poprawne odtworzenia bazy danych, które zawodziły, bo Cloudflare, Route 53 lub load balancer nadal serwowały nowy origin.

DNS jest zwykle najwolniejszą częścią odwracania zmian, dlatego optymalizacja uruchomienia zaczyna się przed nocą startu. Krótkie TTL pomagają, ale nie gwarantują natychmiastowej korekty. Niektóre resolvery je ignorują. Niektórzy klienci stoją za agresywnym cache. Zaplanuj okres ruchu mieszanego, w którym część odbiorców widzi stary stos, a część nowy.

Ta rzeczywistość zmienia sposób uruchamiania. Zamroź treści przed przełączeniem. Kolejkuj zamówienia lub zmiany redakcyjne, jeśli firma może to zaakceptować. Jeśli nie może, potrzebujesz planu uzgodnienia komentarzy, formularzy, danych sprzedażowych i rejestracji użytkowników utworzonych w okresie nakładania się środowisk.

Wielojęzyczne SEO potrzebuje własnego progu wycofania. W praktyce to jedno z miejsc, w których najłatwiej przeoczyć ryzyko biznesowe, bo strona renderuje się normalnie. Ukryte awarie dotyczą adresów canonical, par hreflang, przekierowań regionalnych, przetłumaczonych slugów, map witryny XML i przełączników rynków. Z naszego doświadczenia wynika, że migrowane witryny multisite często tracą część tych sygnałów podczas wydzielania lub ponownego mapowania domen, zwłaszcza gdy wtyczki SEO przechowują ustawienia na innym poziomie, niż zespół się spodziewał.

Sprawdź te elementy natychmiast po przełączeniu:

• Tagi canonical w głównych szablonach i kluczowych landing page
• Pary hreflang dla każdego wariantu językowego lub rynkowego
• Zlokalizowane struktury URL, takie jak /de/ lub subdomeny krajowe
• Mapy witryny generowane przez aktywną wtyczkę SEO na serwerze docelowym
• Działanie przekierowań ze starszych regionalnych adresów URL
• Ustawienia indeksowania, aby reguły noindex ze stagingu nie trafiły na produkcję

Licencjonowanie wtyczek wymaga takiej samej uwagi. Zespoły korporacyjne wpadają tutaj, bo wtyczka działała w starej sieci, a potem zawodzi na wydzielonej witrynie lub nowej domenie. Awaria rzadko jest spektakularna. Często to brakująca grupa pól, wyłączone wysyłanie formularzy, zablokowany kanał aktualizacji albo baner, który po wygaśnięciu cache zamienia się w uszkodzony kod wyjściowy. Jeśli dostawca wtyczki wiąże licencję z pierwotną siecią, uwzględnij kroki ręcznej aktywacji w runbooku uruchomienia i zdecyduj, czy ten stan jest warunkiem wycofania, czy znanym zadaniem po uruchomieniu.

Optymalizacja uruchomienia następuje po kontrolach stabilności, a nie przed nimi. Wyczyść warstwy cache. Rozgrzej najważniejsze strony. Przejrzyj logi PHP, logi serwera WWW, łańcuchy przekierowań, zdarzenia cron i e-maile transakcyjne. Następnie przetestuj ścieżki sprzedażowe w rzeczywistych warunkach: sesje zalogowanych użytkowników, przełączanie języków, wysyłanie formularzy, wyszukiwanie, kasę i wszelkie wywołania zwrotne usług zewnętrznych.

Do porządków, które powinny być powtarzalne, użyj WP-CLI:

wp cache flush
wp rewrite flush --hard
wp cron event run --due-now
wp search-replace 'https://staging.example.com' 'https://example.com' --network --skip-columns=guid

To ostatnie polecenie jest potężne i niebezpieczne. W multisite uruchamiaj je dopiero po potwierdzeniu domen docelowych, zmapowanych hostów i zakresu zserializowanych danych. Błędna zamiana w całej sieci to sposób na wywołanie drugiej awarii podczas naprawiania pierwszej.

Dobre uruchomienie jest nudne w najlepszym znaczeniu. Użytkownicy dalej pracują. Sygnały dla wyszukiwarek pozostają nienaruszone. Licencjonowane wtyczki nadal przechodzą weryfikację. A jeśli któryś z tych elementów zepsuje się na tyle poważnie, że zagraża przychodom lub działalności, wycofanie następuje szybko, bo zespół wcześniej wybrał warunek, osobę odpowiedzialną i dokładne polecenia.

Zaawansowane scenariusze i najważniejsze pytania

Piątek, 17:30. Import bazy danych zakończony, uploady na miejscu, podwitryna się ładuje. Potem z tagów hreflang znikają tłumaczenia, wtyczka formularzy przechodzi w tryb próbny, a zespół SEO zauważa, że adresy canonical wskazują teraz na starą domenę sieci. To ta część, którą standardowe poradniki o migracji multisite zwykle pomijają.

Kosztowne awarie w migracji WordPress Multisite zdarzają się po przeniesieniu plików i tabel. Licencjonowanie wtyczek może się zepsuć, gdy podwitryna opuszcza sieć. Wtyczki wielojęzyczne mogą nadal renderować strony, tracąc przy tym powiązania między językami lub metadane. Plan wycofania, który dobrze wyglądał na papierze, może się rozsypać, jeśli ponowna aktywacja licencji, czas propagacji DNS lub wywołania zwrotne usług zewnętrznych nigdy nie zostały przetestowane.

Licencjonowanie wtyczek to ryzyko operacyjne, a nie zadanie porządkowe

Dyskusje na forum wsparcia WordPress.org na temat migracji multisite wielokrotnie wskazują na awarie wtyczek jako częsty problem po migracji, często związany z licencjonowaniem, brakującymi dodatkami do multisite lub ustawieniami specyficznymi dla sieci. Traktuj to jako osobny strumień prac przed uruchomieniem, a nie niespodziankę po nim.

Płatna wtyczka może działać poprawnie w sieci i przestać działać w chwili, gdy witryna staje się samodzielna. Najczęściej widzę to przy licencjach powiązanych z domeną, wtyczkach przechowujących stan w wp_sitemeta zamiast w opcjach poszczególnych witryn oraz u dostawców, którzy sprzedają obsługę multisite jako osobne uprawnienie.

Sprawdź te punkty, zanim zatwierdzisz przełączenie:

• Czy wtyczka obsługuje zarówno instalacje multisite, jak i samodzielne?
• Czy obecna licencja jest ważna dla domeny docelowej?
• Czy dane aktywacji znajdują się w opcjach sieci, opcjach witryny, własnych tabelach czy w zewnętrznym API?
• Czy wtyczkę można ponownie aktywować przez CLI, czy tylko przez wp-admin?
• Jeśli licencja zawiedzie, czy witryna traci funkcje, traci aktualizacje, czy przestaje renderować kluczowe treści?

Jeśli dostawca nie potrafi jasno odpowiedzieć na te pytania, zaplanuj ręczne działania naprawcze i zdecyduj, czy awaria wtyczki blokuje uruchomienie.

Zakres opcji możesz szybko sprawdzić za pomocą WP-CLI:

wp option get active_plugins
wp site option get active_sitewide_plugins
wp db query "SELECT meta_key FROM wp_sitemeta ORDER BY meta_key;"

Na wydzielonych podwitrynach porównaj także tabele poszczególnych wtyczek. Niektóre wtyczki przechowują licencje, mapowania językowe lub stan kolejek poza zwykłymi opcjami.

Wielojęzyczne SEO psuje się po cichu

Wielojęzyczna podwitryna może wyglądać dobrze dla redaktorów, a mimo to po migracji tracić wartość w wyszukiwarce. Typowe awarie to błędne adresy canonical, brakujące tagi hreflang, uszkodzone przetłumaczone slugi URL i przełączniki języków wskazujące na stare hosty. Dlatego walidacja wielojęzyczna należy do listy kontrolnej uruchomienia, a nie tylko do ogólnej kontroli jakości.

W przypadku WPML, Polylang lub własnych rozwiązań wielojęzycznych sprawdź na zmigrowanej witrynie wszystkie poniższe elementy:

• Tagi canonical wskazują na właściwą domenę produkcyjną
• Tagi hreflang odwołują się do właściwych wariantów językowych
• Przetłumaczone strony nadal są ze sobą powiązane
• Mapy witryny XML obejmują każdy język i właściwe nazwy hostów
• Reguły przekierowań zachowują stare ścieżki językowe i parametry zapytań tam, gdzie to potrzebne

Nie polegaj na sprawdzeniu strony głównej. Testuj głęboko osadzone adresy URL, stronicowane archiwa i strony, które generują przychód.

Trzy najważniejsze pytania

Czy można przenieść pojedynczą witrynę do istniejącej sieci multisite?
Tak, ale najpierw utwórz docelową podwitrynę i odtwórz dane we właściwym kontekście blog ID. Jeśli zaimportujesz dane do niewłaściwego ID witryny, ścieżki uploadów, role użytkowników i ustawienia wtyczek mogą zostać przypisane do niewłaściwych tabel. Przed importem sprawdź cel za pomocą:

wp site list
wp db tables | grep _2_

Zastąp _2_ faktycznym blog ID, którego zamierzasz użyć.

Czy można wydzielić podwitrynę do osobnej, samodzielnej instalacji WordPress?
Tak. Sam transfer jest zwykle prosty. Ryzyko tkwi we wszystkim wokół niego: przepisywaniu ścieżek mediów, zaplanowanych zadaniach, licencjonowanych wtyczkach i sygnałach SEO, którymi wcześniej zarządzano na poziomie sieci. W prawdziwych projektach to właśnie wydzielenie sprawdza ciągłość działania firmy.

A co z użytkownikami i uprawnieniami?
Użytkownicy w multisite są globalni. Role nie są. Po migracji potwierdź uprawnienia na witrynie docelowej, zwłaszcza dla redaktorów, menedżerów sklepu i wszelkich kont zintegrowanych z SSO. Jeśli pierwotna sieć współdzieliła użytkowników między witrynami, sprawdź, czy ci użytkownicy w ogóle powinni istnieć na wydzielonej witrynie.

Pytanie, którego nikt nie zadaje wystarczająco wcześnie

Jakie jest najszybsze bezpieczne wycofanie, jeśli zmigrowana witryna działa już na produkcji, a ścieżki przychodowe zaczynają zawodzić?
Zastosuj wycofanie, które przywraca ostatnią sprawną bazę danych, kieruje ruch z powrotem do starego środowiska i obejmuje wszelkie kroki po stronie dostawców potrzebne do ponownej weryfikacji licencji lub ponownego włączenia usług wielojęzycznych. Jeśli twoje wycofanie zależy od tego, że ludzie coś wymyślą w trakcie awarii, to nie jest plan wycofania.

Miej spisaną sekwencję z imiennie wskazanymi osobami odpowiedzialnymi, założeniami dotyczącymi TTL w DNS i dokładnymi poleceniami przywracania. Na przykład:

wp db import prelaunch-backup.sql
wp search-replace 'https://new.example.com' 'https://old.example.com' --skip-columns=guid
wp cache flush

Uruchamiaj to wyłącznie w środowisku, które zamierzasz przywrócić. W multisite nieostrożne search-replace może poszerzyć awarię.

Najtrudniejszą częścią migracji multisite jest zachowanie działania firmy pod presją. Przeniesienie danych to tylko jedna warstwa. To licencjonowanie, wielojęzyczne SEO i dyscyplina wycofywania sprawiają, że przenosiny nie zamieniają się w incydent zagrażający przychodom.

Jeśli twój zespół potrzebuje doświadczonych specjalistów do migracji multisite wysokiego ryzyka, IMADO to partner inżynieryjny, którego warto zaangażować wcześnie. Zajmuje się elementami, które zwykle są niedoszacowane, w tym architekturą wielojęzyczną, złożonością multisite, wydajnością i dyscypliną uruchomienia, bez sprowadzania projektu do zwykłego „przeniesienia witryny”.