Migracja i multisite: Zaawansowane zarządzanie WordPressem

Dwa zagadnienia w ekosystemie WordPressa budzą szczególny respekt wśród administratorów i deweloperów: bezbłędna migracja rozbudowanego serwisu produkcyjnego na nową infrastrukturę oraz uruchomienie i utrzymanie sieci witryn (WordPress Multisite).

Oba procesy, wykonane po amatorsku, potrafią sparaliżować działanie firmy: zepsute zserializowane tablice w bazie danych prowadzą do utraty konfiguracji wtyczek, a błędnie zaplanowana sieć Multisite staje się architektoniczną pułapką, w której błąd w jednym module kładzie setki stron naraz.

W tym technicznym przewodniku omawiamy inżynieryjne podejście do migracji bez przestojów oraz zasady projektowania skalowalnych sieci WordPress Multisite. Migracja i Multisite to dwie osobne decyzje, które często się myli: migracja przenosi pliki, bazę i DNS, a Multisite zmienia sposób, w jaki kilka witryn dzieli jedną instalację WordPressa. Oficjalnym źródłem dla części sieciowej jest podręcznik WordPress Multisite.

Więcej o tym, jak dbamy o infrastrukturę i stabilność serwisów, przeczytasz w naszej ofercie na utrzymanie i rozwój WordPressa.

#Jak wygląda profesjonalna migracja WordPressa

Typowy błąd początkujących to próba pobierania setek tysięcy plików przez klasyczny protokół FTP i edycja 2-gigabajtowego pliku .sql w edytorze tekstu. W profesjonalnym środowisku operujemy wyłącznie na protokole SSH oraz dedykowanych narzędziach wiersza poleceń.

#Krok 1: Bezpieczna synchronizacja plików przez rsync

Zamiast pobierać archiwum zip przez panel hostingowy, synchronizujemy drzewo katalogów bezpośrednio między serwerami za pomocą narzędzia rsync. Pozwala to na wznawianie transferu i wykluczenie zbędnych plików tymczasowych:

# Uruchomienie synchronizacji z wykluczeniem cache i zbędnych logów
rsync -avzP --delete \
  --exclude 'wp-content/cache/*' \
  --exclude 'wp-content/uploads/cache/*' \
  --exclude '*.log' \
  [email protected]:/var/www/html/ /var/www/html/

Flaga -a zachowuje uprawnienia i czasy modyfikacji plików, a -z kompresuje dane w locie, drastycznie skracając czas transferu przez łącze sieciowe.

#Krok 2: Eksport bazy danych i problem danych serializowanych

WordPress przechowuje wiele złożonych konfiguracji (np. ustawienia ACF, opcje motywów potomnych, struktury menu) w postaci tablic zserializowanych przez funkcję serialize() w PHP. Przykład zapisu w tabeli wp_options:

a:2:{s:4:"host";s:15:"stary-serwer.pl";s:4:"port";i:3306;}

Zwróć uwagę na ciąg s:15:"stary-serwer.pl". Liczba 15 oznacza dokładną długość ciągu znaków. Jeżeli zmienisz domenę ręcznie za pomocą funkcji Znajdź i zamień w edytorze tekstu na nowy-host.pl (długość: 12), parser PHP podczas odczytu natrafi na niezgodność długości i odrzuci całą tablicę. Efekt: zresetowane opcje wtyczek, znikające widżety i błędy typu Notice: unserialize(): Error at offset.

#Krok 3: Poprawna zamiana URL-i za pomocą WP-CLI

Najpewniejszą metodą zmiany adresów URL w bazie danych z poziomu konsoli serwera jest polecenie wp search-replace (podręcznik WordPressa wymienia też wtyczkę Better Search Replace i skrypt Search and Replace for WordPress Databases). WP-CLI deserializuje każdy obiekt w pamięci, dokonuje zamiany ciągu tekstowego, przelicza na nowo wskaźniki długości i ponownie serializuje dane przed zapisem do bazy. Według dokumentacji search-replace polecenie nie zmienia wartości kluczy głównych. Test na sucho powinien mieć dokładnie te same tabele i flagi co właściwe uruchomienie, inaczej podgląd pokazuje coś innego niż to, co się wykona:

# 1. Test na sucho: te same tabele i flagi co właściwe uruchomienie, nic nie jest zapisywane
wp search-replace 'https://stary-serwer.pl' 'https://nowy-serwer.pl' \
  --all-tables --skip-columns=guid --dry-run

# 2. Wykonanie zamiany
wp search-replace 'https://stary-serwer.pl' 'https://nowy-serwer.pl' \
  --all-tables --skip-columns=guid

# 3. Wyczyszczenie pamięci podręcznej i odświeżenie reguł w .htaccess
wp cache flush
wp rewrite flush --hard

Dwie flagi kopiowane ze starszych poradników wymagają korekty. --recurse-objects jest domyślnie włączone, więc dopisanie go niczego nie zmienia. --precise nie jest tym, co chroni dane serializowane: domyślnie polecenie używa szybkich zapytań SQL i samo przełącza się na PHP w kolumnach zawierających dane serializowane, a --precise wymusza PHP we wszystkich kolumnach. To wolniejsze i ma sens tylko przy nietypowo złożonych strukturach. Ważniejsze jest --skip-columns=guid, z powodu opisanego niżej w części o zmianie adresu witryny.

#Jak przeprowadzić migrację WordPress bez przestoju

Aby klienci i roboty wyszukiwarek nie napotkali błędów podczas przenosin, stosuje się czterofazowy protokół migracyjny:

1. Obniżenie parametru TTL (Time to Live) w DNS: Na 48 godzin przed planowanym oknem serwisowym zmniejsz wartość TTL dla rekordu A domeny do 300 sekund (5 minut). Dzięki temu po zmianie adresu IP cały świat dowie się o nowym serwerze niemal natychmiast.
2. Synchronizacja wstępna: Prześlij 99% plików multimedialnych (wp-content/uploads/) z wyprzedzeniem.
3. Okno serwisowe:
   • Włącz tryb konserwacji na starym serwerze (wp maintenance-mode activate).
   • Wykonaj końcowy zrzut bazy danych (wp db export dump-final.sql).
   • Prześlij zrzut na nowy serwer i zaimportuj go (wp db import dump-final.sql).
   • Uruchom wp search-replace na nowej maszynie.
4. Przepięcie rekordu DNS: Zmień adres IP rekordu A na nowy serwer. Od tego momentu ruch zacznie płynnie spływać na nową instancję.

#Kiedy warto używać WordPress Multisite, a kiedy nie

WordPress Multisite (dawniej WPMU) umożliwia uruchomienie setek lub tysięcy wirtualnych serwisów w oparciu o jedną instancję kodu i wspólną bazę danych.

#Jak Multisite organizuje bazę danych

W instalacji pojedynczej WordPress tworzy standardowe 12 tabel (np. wp_posts, wp_options, wp_users). W trybie Multisite zachodzi kluczowa zmiana architektoniczna:

• Współdzielone tabele globalne: Tabela użytkowników (wp_users) oraz ich metadanych (wp_usermeta) pozostaje jedna dla całej sieci. Konto użytkownika istnieje raz, ale może mieć różne role w różnych witrynach sieci. Dochodzą też tabele zarządzania siecią (wp_blogs, wp_site, wp_sitemeta).
• Izolowane tabele per witryna: Każda kolejna strona w sieci otrzymuje własny prefiks numeryczny: witryna nr 2 otrzymuje tabele wp_2_posts, wp_2_options, wp_2_comments itd.

+--------------------------------------------------+
|          WordPress Multisite - Baza Danych       |
+--------------------------------------------------+
| Tabele globalne:                                 |
| - wp_users                                       |
| - wp_usermeta                                    |
| - wp_blogs                                       |
| - wp_site / wp_sitemeta                          |
+--------------------------------------------------+
| Witryna Główna (ID: 1):                          |
| - wp_posts, wp_options, wp_terms...              |
+--------------------------------------------------+
| Subwitryna (ID: 2):                              |
| - wp_2_posts, wp_2_options, wp_2_terms...        |
+--------------------------------------------------+
| Subwitryna (ID: 3):                              |
| - wp_3_posts, wp_3_options, wp_3_terms...        |
+--------------------------------------------------+

#Kiedy Multisite to dobry wybór

1. Sieci franczyzowe i oddziałowe: Gdy 50 lokalnych oddziałów firmy korzysta z tego samego szablonu graficznego, tego samego zestawu wtyczek i centralnego brandingu, a różni się jedynie danymi teleadresowymi i lokalnym cennikiem.
2. Szkolnictwo i portale uczelniane: Gdzie każdy wydział lub koło naukowe potrzebuje własnej podstrony w ujednoliconej domenie uczelni.
3. Wewnętrzny staging i dema produktów: Gdy skrypty mają szybko zakładać odizolowane witryny z gotową konfiguracją.

Sama wielojęzyczność rzadko uzasadnia Multisite. WPML, Polylang albo warianty językowe w jednej instalacji są zwykle prostsze w utrzymaniu niż sieć z osobną witryną na każdy język. Podręcznik mówi podobnie: jeśli witryny muszą intensywnie dzielić dane lub użytkowników albo potrzebują jedynie różnych motywów dla sekcji, jedna instalacja z wtyczką bywa lepsza od sieci.

#Kiedy Multisite jest błędem projektowym

• Różni, niepowiązani klienci agencyjni: Jeden fatalny błąd PHP w motywie klienta A wyłącza serwisy klientów B, C i D. Ponadto wyodrębnienie jednej witryny z sieci Multisite do osobnej bazy danych jest czasochłonnym procesem.
• Różne wymagania hostingowe: Jeśli witryny potrzebują różnych wersji PHP, planów hostingowych albo stref bezpieczeństwa, jedna sieć tego nie zapewni.
• Skrajnie różne zestawy wtyczek: Jeśli strona A potrzebuje WooCommerce, strona B zaawansowanego LMS, a strona C forum dyskusyjnego bbPress, wspólna baza wtyczek staje się ociężałym monolitem trudnym do aktualizacji.

#Wymagania przed utworzeniem sieci WordPress Multisite

Rozdział Before you create a network wymienia ograniczenia, które egzekwuje ekran Uruchamianie sieci. Większość nieudanych konwersji rozbija się o jedno z nich.

Sieci nie da się utworzyć, gdy adres WordPressa używa innego portu niż 80 lub 443. Instalacja na subdomenach jest zablokowana, gdy adres WordPressa zawiera ścieżkę (WordPress nie leży w katalogu głównym serwera), gdy adresem jest localhost albo gdy jest nim adres IP, np. 127.0.0.1. Do testów lokalnych podręcznik zaleca przypisanie własnej nazwy hosta do 127.0.0.1 w pliku hosts. Instalacja na podkatalogach jest zablokowana, gdy istniejąca instalacja ma więcej niż miesiąc, bo wpisy witryny głównej kolidowałyby ze ścieżkami podwitryn. W sieci opartej na ścieżkach adresy wpisów witryny głównej dostają dodatkowo prefiks /blog/.

Po stronie serwera Apache potrzebuje mod_rewrite z obsługą .htaccess, niewyłączonego FollowSymLinks oraz AllowOverride ustawionego na All lub Options All dla danego vhosta. Przyjazne bezpośrednie odnośniki muszą już działać na pojedynczej instalacji. Ustal domenę, także kwestię www, przed aktywacją. Jeśli WordPress ma działać z osobnego katalogu, tę zmianę też trzeba zrobić wcześniej. Wildcard DNS jest potrzebny tylko wtedy, gdy użytkownicy sami zakładają witryny na subdomenach; witryny dodawane ręcznie mogą korzystać z osobnych rekordów DNS lub wirtualnych hostów.

#Jak skonfigurować sieć WordPress Multisite krok po kroku

Procedura Create a Network ma kolejność, która ma znaczenie. Zrób kopię bazy i plików. Wyłącz wszystkie wtyczki; po utworzeniu sieci można je włączyć ponownie. Następnie dopisz przełącznik do pliku wp-config.php nad linią /* That's all, stop editing! Happy publishing. */:

// 1. Odblokowanie kreatora sieci w kokpicie
define('WP_ALLOW_MULTISITE', true);

Po przejściu do Narzędzia > Uruchamianie sieci i wybraniu modelu (subdomeny czy podkatalogi), instalator generuje ostateczny zestaw stałych, które wklejasz bezpośrednio pod linią z WP_ALLOW_MULTISITE:

// 2. Aktywacja właściwej sieci (wariant subdomenowy)
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', true);
define('DOMAIN_CURRENT_SITE', 'twojadomena.pl');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);

Ten sam ekran wyświetla reguły przepisywania. Zastępują one dotychczasowy blok WordPressa w .htaccess (na Nginx stają się regułami w bloku server). Przed edycją zrób kopię obu plików. Po zapisaniu zaloguj się ponownie przez link podany przez WordPressa; czasem trzeba wyczyścić ciasteczka przeglądarki. W menu “Moje witryny” pojawia się wtedy Administracja siecią. Późniejsza zmiana między subdomenami a podkatalogami jest możliwa, ale podręcznik ostrzega, że może nie być łatwa, więc zdecyduj przed utworzeniem pierwszej podwitryny.

#Mapowanie domen w Multisite bez wtyczki

Od wersji WordPress 4.5 natywne mapowanie domen (Domain Mapping) jest wbudowane bezpośrednio w silnik. Wystarczy w edycji konkretnej witryny w panelu Super-Administratora wpisać docelową domenę (np. zewnetrzna-marka.pl), a serwer WWW (Nginx/Apache) skierować za pomocą certyfikatu SSL na ten sam katalog główny.

Rozdział o mapowaniu domen podaje kolejność. Najpierw każda domena musi wskazywać w DNS na serwer. Potem certyfikat TLS dla domeny głównej i certyfikaty SNI dla pozostałych, żeby każde logowanie do panelu było szyfrowane. Dopiero wtedy wpisujesz pełny adres, np. https://zewnetrzna-marka.pl, w polu Adres witryny (URL) danej podwitryny. Obniż TTL dzień wcześniej i zmieniaj adres dopiero wtedy, gdy serwer odpowiada pod nową nazwą hosta. Jeśli logowanie na zmapowanej witrynie kończy się komunikatem o zablokowanych ciasteczkach albo nie działa bez żadnego komunikatu, dopisz pod stałymi sieci:

define( 'COOKIE_DOMAIN', $_SERVER['HTTP_HOST'] );

#Role użytkowników w wielu witrynach WordPress Multisite

W Multisite wszyscy użytkownicy są w jednej wspólnej tabeli. Członkostwo i role przydziela się osobno dla każdej witryny.

Co to oznacza w praktyce:

• Administrator witryny krakow.marka.pl nie zainstaluje wtyczki. To zadanie superadministratora.
• Usunięcie użytkownika w Administracji siecią kasuje konto wszędzie, nie tylko w jednym oddziale.
• Wspólne logowanie do kilku marek przychodzi w Multisite naturalnie; izolacja między klientami nie.

Spisz, kto ma uprawnienia superadministratora, i trzymaj tę liczbę nisko. Zbyt wielu superadministratorów to typowa przyczyna sytuacji “ktoś włączył wtyczkę w Administracji siecią i padły trzy witryny”.

#Jak połączyć kilka stron WordPress w jedną sieć Multisite

Włączenie sieci na istniejącej instalacji, opisane wyżej, to nie to samo co połączenie pięciu osobnych instalacji. Każda kolejna witryna musi trafić do sieci przez eksport i import (WXR), WP-CLI albo narzędzie, które rozumie prefiksy tabel Multisite.

Zalecana kolejność:

1. Pełna kopia plików i bazy wszystkich źródeł (3-2-1: trzy kopie, dwa nośniki, jedna poza siedzibą).
2. Budowa sieci na stagingu z tą samą wersją PHP co na produkcji.
3. Utworzenie pustych witryn w Administracji siecią z docelowymi domenami lub subdomenami.
4. Import treści witryna po witrynie. Potem search-replace starych adresów tylko wewnątrz tabel tej witryny, z --url=<witryna> i bez --network.
5. Mapowanie użytkowników: te same adresy e-mail stają się jednym kontem, role przydziela się per witryna.
6. Sprawdzenie mediów. Pliki podwitryny leżą w wp-content/uploads/sites/{id}/.
7. Obniżenie TTL w DNS, przełączenie i gotowy SQL do wycofania zmian.

#Jak wydzielić jedną witrynę z WordPress Multisite

Czasem sieć okazuje się złym modelem. Wtedy eksportujesz jedną witrynę:

1. Ustal blog_id i prefiks tabel (wp_5_ itd.), np. poleceniem wp site list --fields=blog_id,url.
2. Wyeksportuj treści (WXR) albo sklonuj tabele do nowej bazy ze standardowym prefiksem wp_.
3. Skopiuj media z uploads/sites/{id}/ do zwykłego katalogu uploads/.
4. Zaktualizuj siteurl i home, potem uruchom search-replace.
5. Zainstaluj tylko te wtyczki i motywy, których witryna faktycznie używała, a nie cały katalog sieci w ciemno.

Zaplanuj przekierowania ze starych adresów na subdomenie na nową domenę. Inaczej tracisz siłę linków, a Search Console zapełnia się błędami 404.

#Jak zmienić adres witryny WordPress po przeprowadzce

W Ustawieniach > Ogólne są dwa pola: Adres WordPressa (URL), czyli miejsce plików rdzenia, i Adres witryny (URL), czyli adres wpisywany przez odwiedzających. Gdy po przenosinach panel jest nieosiągalny, rozdział o migracji opisuje cztery sposoby poprawienia tych wartości. Dotyczą pojedynczych instalacji; dla Multisite podręcznik odsyła do bazy danych, o czym w następnej części.

1. wp-config.php: define( 'WP_HOME', 'https://example.pl' ); i define( 'WP_SITEURL', 'https://example.pl' );. Wartości są wtedy zapisane na sztywno, a pól w Ustawieniach ogólnych nie da się już edytować.
2. functions.php: dwa wywołania update_option() dla siteurl i home w aktywnym motywie, załadowane raz i usunięte. Podręcznik wprost zaznacza, że kod nie może zostać w pliku.
3. RELOCATE: define('RELOCATE', true); w wp-config.php, a następnie otwarcie wp-login.php pod nowym adresem. To poprawia wyłącznie adres witryny i nic poza nim. Pozostawienie stałej jest niebezpieczne, bo w niektórych konfiguracjach pozwala atakującemu zmienić adres witryny. Usuń ją od razu.
4. Baza danych lub WP-CLI: edycja siteurl i home w wp_options albo wp option update home 'https://example.pl' i wp option update siteurl 'https://example.pl'.

Ten sam rozdział zawiera zasadę, którą warto powtarzać: kolumny guid w wp_posts nie zmienia się nigdy. Czytniki kanałów RSS rozpoznają po GUID wpisy, które już pokazały, więc jego zmiana sprawia, że stare wpisy wracają jako nowe. Dlatego przykład WP-CLI w dokumentacji używa --skip-columns=guid. Stare adresy mogą też siedzieć w transientach. W przeniesionej kopii można je bezpiecznie usunąć (wp transient delete --all), bo WordPress odtworzy je w razie potrzeby.

Przeniesienie WordPressa do innego katalogu na tym samym serwerze ma własną kolejność: najpierw zmiana obu adresów w Ustawieniach, potem przeniesienie plików. Jeśli pliki przeniesiono wcześniej, podręcznik proponuje tymczasowe dowiązanie symboliczne ze starej ścieżki do nowej (ln -s /path/to/new /path/to/old), po którym zwykłe kroki działają.

#Jak uruchomić wp search-replace w sieci Multisite

W Multisite wp search-replace zmienia domyślnie tylko tabele bieżącej witryny. Dokumentacja polecenia definiuje zakresy:

• bez flagi: tabele zarejestrowane w $wpdb dla witryny wskazanej przez --url (domyślnie witryny głównej),
• --network: wszystkie tabele zarejestrowane w $wpdb w całej sieci,
• --all-tables-with-prefix: każda tabela z prefiksem WordPressa, zarejestrowana lub nie,
• --all-tables: każda tabela w bazie, niezależnie od prefiksu. Ta flaga nadpisuje --network, więc w bazie współdzielonej z innymi aplikacjami sięga także ich tabel.

Tabele bez klucza głównego są pomijane bez ostrzeżenia; wp db query 'DESCRIBE <tabela>' pokaże, czy jest PRI. Udokumentowany sposób zamiany produkcyjnej sieci w kopię lokalną jawnie obejmuje też tabele sieci:

wp search-replace --url=example.pl example.pl example.test \
  'wp_*options' wp_blogs wp_site --network --skip-columns=guid

--export=siec.sql zapisuje przekształcone dane do pliku zamiast do działającej bazy, co pasuje do przeprowadzki z importem na nowym serwerze. Przed zmianą i po niej wp site list wypisze wszystkie witryny, więc łatwo porównać zapisane adresy:

for url in $(wp site list --field=url); do
  echo "$url $(wp option get siteurl --url="$url")"
done

Uwagi podręcznika o przenoszeniu Multisite wyznaczają zakres prac. Ta sama domena na nowym serwerze: kopiujesz pliki i bazę jak przy pojedynczej instalacji. Nowa domena: przenosisz pliki, zmieniasz DOMAIN_CURRENT_SITE w wp-config.php i .htaccess, jeśli zmienił się katalog, a potem przeglądasz wp_site i wp_blogs (domena i ścieżka) oraz w każdej tabeli wp_N_options wartości home, siteurl i fileupload_url. Zmiana między subdomenami a podkatalogami wymaga dodatkowo zmiany SUBDOMAIN_INSTALL i nowych reguł przepisywania.

#Najczęstsze błędy stagingu w WordPress Multisite

Multisite najczęściej psuje się na stagingu, nie na produkcji.

Adresy zaszyte w sieci. Narzędzie do klonowania, które podmienia tylko domenę główną, a zostawia wp_blogs i wp_site wskazujące na produkcję, loguje redaktorów do złego środowiska albo miesza ciasteczka.

Search-replace bez wykluczenia GUID albo bez testu na sucho. Test na sucho zawsze. Zawęź tabele, gdy przenosisz tylko jedną witrynę.

Cron i poczta. Cron sieci (wp-cron.php) i poczta wychodząca ze stagingu nie mogą trafiać do prawdziwych klientów. Zablokuj wychodzący SMTP na stagingu albo kieruj go do skrzynki testowej.

Subdomeny stagingowe. staging.marka.pl potrzebuje własnego DNS i zwykle własnego certyfikatu TLS. Certyfikat wildcard dla *.marka.pl nie obejmuje staging.innamarka.pl. Sprawdź HTTPS, zanim zaprosisz redaktorów.

Aktywacja wtyczek na poziomie sieci. Testowa wtyczka na stagingu jest w porządku. To samo na produkcji bez witryny kanarkowej już nie. Utrzymuj co najmniej jedną witrynę kanarkową, na której nowe wtyczki włącza się najpierw.

WooCommerce w sieci. Jeśli sieć to sieć sklepów, przetestuj callbacki bramek płatności dla każdego adresu witryny. Webhooki, które po starcie wciąż wskazują staging, kosztują. Bez e-commerce migracja ogranicza się do treści, mediów i ról.

#Multisite, zwykła migracja czy osobna instalacja

#Co powinno być na liście kontrolnej przed migracją WordPressa

1. Kopia zapasowa sprawdzona testem przywracania, nie samym rozmiarem pliku.
2. Ta sama wersja PHP i rozszerzenia na stagingu i produkcji.
3. wp search-replace --dry-run bez niespodzianek, z tymi samymi flagami co właściwe uruchomienie.
4. Logowanie przetestowane jako superadministrator i jako administrator witryny.
5. Adresy mediów ładują się przez HTTPS na każdej zmapowanej domenie.
6. wp site list --field=url zgadza się z oczekiwaną listą adresów.
7. Obniżony TTL w DNS i spisany plan wycofania (kto przestawia rekord A, gdzie leży poprzedni zrzut SQL).

Migracja to mechanika. Multisite to model utrzymania. Pomieszanie jednego z drugim kończy się poprawianiem DNS tam, gdzie należało rozdzielić klientów, albo odwrotnie.

#Najczęstsze pytania o migrację i Multisite

Migracja bez przestojów oraz stabilna sieć Multisite to domena inżynierii, a nie improwizacji. Precyzyjne operowanie na bazach danych, automatyzacja zadań przez WP-CLI oraz właściwe planowanie architektury pozwalają skalować projekty cyfrowe bez obawy o utratę danych czy awarie produkcyjne. Jeżeli planujesz migrację złożonego serwisu lub potrzebujesz audytu swojej infrastruktury, skonsultuj się z naszym programistą WordPress.

Po stronie wdrożenia ten temat trzymamy pod migrację na Next.js lub Astro.