Przenoszę publiczną część stron na WordPressie do Astro albo Next.js. WordPress zostaje panelem, w którym redakcja pisze i publikuje, a nowy frontend pobiera z niego treść. Zanim zaproponuję migrację, mierzę, co naprawdę spowalnia stronę. Czasem wystarczy poprawić cache albo obrazy i wtedy to piszę zamiast sprzedawać przebudowę.
Kto realizuje migrację WordPress do Astro i Next.js?
Mariusz Szatkowski, programista WordPress od 2006 roku, z Gdyni. Pracuję sam: audyt, kod, przekierowania i wdrożenie robię osobiście, bez zespołu i podwykonawców. Ta strona, wppoland.com, działa na Astro i Cloudflare Pages.
Co obejmuje migracja WordPress do Astro i Next.js?
Przeniesienie warstwy publicznej na Astro albo Next.js, odtworzenie szablonów i komponentów, pobieranie treści z WordPressa przez REST API albo WPGraphQL, przeniesienie formularzy i integracji oraz mapę przekierowań ze starych adresów. Panel redakcyjny, role i proces publikacji zostają w WordPressie, chyba że ustalę inaczej. Projekt graficzny i układ widoków dostarczasz ty, ja je wdrażam.
Kiedy migracja ma sens, a kiedy nie
Wąskim gardłem rzadko jest sam WordPress. Częściej to konkretna warstwa: zapytania, które wtyczka wykonuje przy każdym żądaniu, cache pomijający zalogowanych, obrazy w oryginalnym rozmiarze albo motyw ładujący kilkanaście plików CSS i JS. Każdą z tych przyczyn da się zmierzyć osobno, a część naprawić bez wymiany frontendu. Dlatego audyt najpierw wskazuje warstwę, a dopiero potem framework.
Migracja frontendu ma sens, gdy problem leży w samym motywie i sposobie renderowania, gdy chcesz trzymać szablony w repozytorium i publikować przez build, albo gdy ta sama treść ma trafiać także do innych kanałów przez API. Nie ma sensu, gdy strona żyje z wtyczek generujących front (kreatory stron, rozbudowane sklepy na WooCommerce z dziesiątkami rozszerzeń), bo każdą z tych funkcji trzeba by napisać od nowa.
Oddzielenie frontendu zmienia też powierzchnię ataku. Publiczny ruch nie trafia już do PHP, ale instalacja WordPressa, wtyczki, konta i API dalej wymagają aktualizacji, kontroli dostępu, kopii zapasowych i monitoringu. Architektura headless nie chroni przed przejęciem zaplecza ani przed podatną integracją.
Astro czy Next.js?
Oba frameworki obsługują generowanie statyczne i renderowanie na serwerze, różnią się punktem wyjścia. Szerzej opisuję to w porównaniu Astro 5 i Next.js 15 na 2026, razem z kosztem utrzymania i dostępnością programistów.
| Astro | Next.js | |
|---|---|---|
| Model | strony wielostronicowe, plik src/pages/index.astro to strona główna | aplikacja Reacta z App Routerem (app/) |
| JavaScript w przeglądarce | domyślnie brak; komponent staje się interaktywną wyspą dopiero z dyrektywą client:load, client:idle lub client:visible | komponenty klienckie oznaczone 'use client' |
| Renderowanie | domyślnie output: 'static'; pojedyncza strona na żądanie przez export const prerender = false i adapter | prerender, renderowanie dynamiczne, ISR przez export const revalidate |
| Odświeżanie treści z CMS | nowy build albo strony renderowane na żądanie | revalidatePath, revalidateTag, podgląd szkiców przez draftMode() |
| Typowy hosting | adaptery @astrojs/cloudflare, @astrojs/netlify, @astrojs/node, @astrojs/vercel; statyczny build na dowolnym serwerze | serwer Node.js, kontener Docker albo eksport statyczny (output: 'export') bez ISR i bez Proxy |
| Pasuje do | stron firmowych, blogów, dokumentacji | aplikacji z logowaniem, panelami klienta, danymi zmieniającymi się przy każdym żądaniu |
Astro nie jest frameworkiem Reacta. Komponenty Reacta można w nim używać przez integrację @astrojs/react, a na stronę trafiają jako HTML albo jako wyspy z dyrektywą client:*. Do tego dochodzą wyspy serwerowe: komponent Astro z dyrektywą server:defer renderuje się osobno, a reszta strony nie czeka na niego.
Co dostajesz po migracji
- Audyt wyjściowy. Lista reprezentatywnych adresów, pomiar LCP, INP, CLS i TTFB przed zmianą oraz wskazanie warstwy, która odpowiada za problem.
- Frontend w repozytorium. Szablony i komponenty w Astro albo Next.js pod kontrolą wersji, publikacja przez build, podgląd przed wypuszczeniem.
- Redakcja zostaje w WordPressie. Te same konta, role i proces publikacji. Treść pobierana z
/wp-json/wp/v2/albo przez WPGraphQL. - Formularze, integracje i przekierowania. Przeniesione i opisane, z listą adresów do sprawdzenia po wdrożeniu.
- Raport przed i po. Te same adresy, te same warunki testu, obie daty pomiaru i dane z ruchu użytkowników, jeśli je masz. Na tej podstawie oceniam, czy cel z oferty został osiągnięty.
Jak wygląda proces migracji?
- Audyt. Mierzę stronę, spisuję treści, typy wpisów, pola ACF, formularze, integracje z CRM i analityką. Sprawdzam, które wtyczki generują coś na froncie.
- Decyzja i oferta. Wybór frameworka z uzasadnieniem, zakres, założenia i termin na piśmie, zanim powstanie kod.
- WordPress jako API. Porządkuję zaplecze, ograniczam dostęp do panelu i sprawdzam, co zwraca REST API. WPGraphQL instaluję tylko wtedy, gdy struktura treści tego wymaga.
- Nowy frontend. Szablony według twojego projektu graficznego, w repozytorium Git, z wersją podglądową, na której akceptujesz zmiany.
- Przełączenie. Stara strona działa do momentu zmiany DNS. Jeśli po przełączeniu coś jest nie tak, powrót oznacza skierowanie domeny z powrotem na starą wersję. WordPress przestaje być widoczny publicznie i służy tylko redakcji.
Polskie znaki w adresach i mapa przekierowań
WordPress tworzy slugi funkcją sanitize_title(), która przez remove_accents() zamienia polskie litery na łacińskie: tytuł “Łódź” daje slug lodz, a “sprzedaż” daje sprzedaz. Nowy frontend musi budować dokładnie te same adresy, inaczej każdy wpis dostanie nowy URL i będzie potrzebował przekierowania. W Astro slug pochodzi z danych WordPressa, a nie z nazwy pliku, więc pobieram pole slug z API zamiast generować go od nowa. Dopiero adresy, które świadomie zmieniamy (archiwa dat, strony załączników, parametry ?p=), trafiają do mapy 301.
Metadane SEO przenoszę razem z treścią: tytuły, opisy, dane strukturalne, adresy kanoniczne i hreflang przy stronach wielojęzycznych. Przed przełączeniem porównuję crawl starej i nowej wersji, a po nim raporty w Google Search Console.
Masz już frontend w Next.js i chcesz przejść na Astro?
Oficjalny przewodnik Astro dla projektów z Next.js opisuje, co się zmienia:
- katalog
pages/przechodzi dosrc/pages/, routing nadal opiera się na plikach; app/layout.jsxihead.jsxłączą się w jedenLayout.astro, a{children}zastępuje<slot />;getStaticProps()znika, dane pobierasz w nagłówku komponentu przezfetch(),import.meta.glob()albogetCollection();<Image />z Next.js zastępuje<Image />zastro:assets, a w plikach.jsxzostaje zwykły<img>bez optymalizacji;<Link>zamienia się w<a href="">, aclassNamewclass.
Komponenty Reacta mogą zostać dzięki @astrojs/react. Przewodnik zaznacza też, że Astro jest nastawione na treść, więc rozbudowane panele aplikacyjne wymagają więcej pracy niż w Next.js.
Typowe scenariusze
Strona treściowa. Blog, strona firmowa, baza wiedzy. Wpisy zmieniają się rzadko, a są czytane często, więc generowanie statyczne w Astro jest tu naturalnym wyborem. Do ustalenia zostaje, co uruchamia nowy build po publikacji.
Sklep na WooCommerce. Katalog, koszyk, płatności i konta klientów to logika, którą w układzie headless trzeba odtworzyć na froncie. Przy sklepie z wieloma rozszerzeniami częściej polecam zostać przy klasycznym motywie i poprawić jego wydajność.
Aplikacja z logowaniem. Panele klienta i dane zależne od użytkownika to obszar Next.js: strony publiczne mogą być prerenderowane, a sekcje po zalogowaniu renderowane na serwerze.
Przykład z mojej pracy to przebudowa WPPoland na statyczny system treści Astro: opis architektury treści, kontroli SEO i obsługi sześciu języków.
Kontakt i powiązane usługi
Wyślij opis projektu: obecny stack, docelowy framework, ograniczenia adresów, integracje i języki. Odpowiadam mailowo z kolejnymi krokami.
Nowe projekty w Next.js, które nie zaczynają się od WordPressa, opisuję na stronie programista Next.js.
