Przeniesienie platformy z WordPressa do Astro miało być całym projektem. Okazało się prologiem. Eksport treści, odbudowa szablonów, doprowadzenie statycznej witryny do kompilacji i wdrożenia na Cloudflare Pages zajęło tygodnie. Potem zaczął się właściwy rok: przekierowania, hreflang, parytet sześciu wersji językowych i build, który przerósł platformę, na której był wdrażany. To jest raport o tym, gdzie poszedł czas, bo czas nie poszedł tam, gdzie zakładał plan.
Polemika, jeśli już jakaś jest, dotyczy ujmowania przeniesienia platformy jako jednorazowego portu. “Zejdź z WordPressa na witrynę statyczną” brzmi jak jednorazowa migracja. Dla wielojęzycznej witryny treściowej jest to bliżej przejęcia odpowiedzialności za trzy systemy, które WordPress dotąd ukrywał: warstwę routingu, build i strukturę między wersjami językowymi. Żaden z nich nie jest trudny. Wszystkie są ciągłe.
Migracja WordPress do Astro, prawdziwy koszt: TL;DR w 4 punktach
- Przeniesienie to tania część. Szablony i eksport treści zajęły tygodnie; migracja potrzebowała około dwunastu miesięcy, by osiągnąć stabilne wyniki wyszukiwania bez regresji.
- Warstwa przekierowań to pierwsza niespodzianka. Tysiące wcześniej zaindeksowanych adresów potrzebują każde własnego 301, a sama ich liczba zderzyła się z limitem rozmiaru pliku na Cloudflare Pages, który po cichu odrzucał reguły.
- Parytet sześciu wersji językowych to praca ciągła, nie zadanie. Hreflang, adresy kanoniczne i struktura sekcji muszą pozostać zgodne we wszystkich wersjach językowych, na zawsze.
- Build przerósł własny runner Cloudflare. Sufit 8 GB nie wystarcza na tysiące prerenderowanych stron; odpowiedzią było budowanie lokalnie ze stertą 16 GB i wdrażanie gotowego artefaktu.
Słownik: build statyczny, prerender, hreflang, brzeg sieci
Raport opiera się na kilku pojęciach platformowych.
- Build statyczny - cała witryna jest renderowana do zwykłych plików HTML z wyprzedzeniem, podczas kroku buildu, zamiast na każde żądanie.
- Prerender - generowanie HTML każdej strony podczas buildu. Witryna z sześcioma językami mnoży liczbę stron przez liczbę języków, więc build skaluje się jak treść razy języki.
- Cloudflare Pages - host. Serwuje wcześniej zbudowane pliki z brzegu sieci i może też uruchamiać build, w granicach limitów pamięci.
- Wrangler - narzędzie wiersza poleceń Cloudflare, użyte tutaj do wdrożenia lokalnie zbudowanego artefaktu bezpośrednio, z pominięciem kroku buildu platformy.
- Hreflang - odnośniki, które mówią wyszukiwarkom, która strona jest niemiecką, polską czy hiszpańską wersją tego samego artykułu.
- Przekierowanie 301 - trwałe przekierowanie, które przenosi sygnał rankingowy przeniesionego adresu na jego nowe miejsce.
Tygodnie: przeniesienie, które wszyscy budżetują
Widoczna migracja to ta część, którą się szacuje, i szacunek jest mniej więcej trafny. Treść wychodzi z WordPressa, szablony są odbudowywane w Astro z Tailwindem, build kompiluje się, wdrożenie ląduje na Cloudflare Pages. Witryna treściowa średniej wielkości osiąga działający build statyczny w tygodnie. To faza, która dobrze prezentuje się na demo i przekonuje wszystkich, że projekt jest prawie gotowy.
Nie jest prawie gotowy. Jest za częścią, którą łatwo było przewidzieć, i dociera do części, której nikt nie zaplanował. Działający build dowodzi, że szablony się renderują; nie dowodzi niczego co do tego, czy stare adresy się rozwiązują, czy wersje językowe są ze sobą zgodne i czy build wciąż się skończy, gdy treść potroi się.
Miesiące: warstwa przekierowań, której nikt nie zaplanował
Pierwszy miesiąc długiego ogona poszedł na przekierowania. Każdy adres, jaki WordPress kiedykolwiek wystawił i jaki Google kiedykolwiek zaindeksował, potrzebował 301 do nowego adresu Astro, inaczej stawał się 404, a sygnał rankingowy parował. Na jednojęzycznym blogu to długa lista. Na witrynie z sześcioma językami i opisowymi slugami idzie w tysiące.
Ta liczba uderzyła w ścianę, która ma swój własny raport z pola: Cloudflare Pages po cichu odrzuca reguły _redirects powyżej limitu rozmiaru pliku 100 KB, bez żadnego ostrzeżenia, więc część mapy przekierowań wdrożyła się na zielono i nigdy nie zadziałała. Objaw pojawił się miesiące później jako błędy 404 w Search Console i niedostępne strony produktów w Merchant Center, długo po tym, jak migracja wyglądała na skończoną. Wniosek wykracza poza Cloudflare: w przeniesieniu platformy mapa przekierowań to nie punkt na liście kontrolnej, który się odhacza; to system, który się eksploatuje, z własnymi trybami awarii i własnym monitoringiem.
Miesiące: sześć języków, które muszą się zgadzać na zawsze
WordPress, z odpowiednimi wtyczkami, ukrywa strukturę wielojęzyczną za panelem. Build statyczny ją obnaża. Sześć wersji językowych każdego artykułu musi pozostać strukturalnie równoległe: te same nagłówki sekcji w tej samej kolejności, odnośniki hreflang, które faktycznie prowadzą do każdej wersji siostrzanej, adresy kanoniczne wskazujące tam, gdzie powinny, i adresy taksonomii pasujące między językami. Gdy jedna wersja językowa odpływa, graf odnośników międzyjęzykowych pęka na warstwie indeksowania, podczas gdy każda strona wciąż renderuje się bez zarzutu.
Łączy się to bezpośrednio z osobnym trybem awarii w tym, jak tłumaczenie AI psuje wielojęzyczne SEO: narzędzia tłumaczeniowe, które dotykają pól strukturalnych, produkują dryf wersji językowych niewidoczny na stronie, a kosztowny w indeksie. Po migracji parytet przestał być kamieniem milowym, a stał się stałą kontrolą, uruchamianą przy każdej zmianie treści, bo sześć wersji językowych nie utrzymuje zgodności samo z siebie.
Narzędzia, które odbudowujesz, a które WordPress dawał za darmo
Cichszym kosztem odejścia od WordPressa jest to, że przejmujesz odpowiedzialność za kontrole, które platforma i jej wtyczki wykonywały dotąd niewidocznie. WordPress walidował odnośniki wewnętrzne w edytorze, utrzymywał aktualną mapę witryny przez wtyczkę i ostrzegał o zepsutych odwołaniach w panelu. Build statyczny nie robi nic z tego sam z siebie; odbudowujesz to albo wypuszczasz regresje.
Przez ten rok oznaczało to małą bibliotekę walidatorów wpiętą we wdrożenie: walidację odnośników wewnętrznych względem rzeczywistej powierzchni tras, by zmieniony slug nie zostawiał wiszących odnośników, kontrole danych strukturalnych, by schema we frontmatterze pozostawała poprawnie zbudowana między językami, kontrole parytetu porównujące wersje siostrzane pod kątem brakujących sekcji oraz generator mapy witryny i hreflang podczas buildu. Każda z nich zastępuje coś, co WordPress robił po cichu. Bilans to więcej kontroli i więcej pewności (kontrole są jawne, wersjonowane i uruchamiane w CI), ale to realna inżynieria, o której słowo “migracja” nie wspomina. Każdy, kto wycenia przeniesienie platformy, powinien dopisać tę pozycję: nie tylko przenosisz treść, ale na nowo wdrażasz zabezpieczenia, które stara platforma stosowała za darmo.
Miesiące: build, który przerósł swój host
Ostatnia niespodzianka była mechaniczna. Cloudflare Pages serwuje dużą witrynę statyczną bez wysiłku, ale budowanie jej jest ograniczone pamięcią, a własny runner buildu platformy zatrzymuje się na 8 GB. Wielojęzyczna witryna Astro z tysiącami prerenderowanych stron, gdzie każdy język mnoży tę liczbę, potrzebuje więcej sterty niż to, a build platformy zaczął kończyć się błędami braku pamięci, których rozpoznanie zajęło trochę czasu.
Rozwiązaniem było zaprzestanie budowania na platformie. Witryna buduje się teraz lokalnie ze stertą 16 GB, a gotowe wyjście jest wypychane na Cloudflare Pages przez Wrangler, który wdraża artefakt bez ponownego budowania go. Lokalna maszyna z procesorem z serii M kończy build niezawodnie w minuty tam, gdzie ograniczony runner nie kończył go wcale. Obrazy wymusiły powiązaną dyscyplinę: wszystko, co przechodzi przez potok zasobów Astro, jest optymalizowane podczas buildu, co jest świetne, ale głodne pamięci, więc wstępnie zoptymalizowane tła są serwowane bez zmian z katalogu public, a w potoku zostają tylko obrazy, które zyskują na przetwarzaniu, utrzymywane w rozsądnym rozmiarze, by build trzymał się poniżej swojego sufitu.
Co migracja faktycznie kupiła
Powiedziane wprost, by rok nie czytał się jak żal: ruch był tego wart. Strony renderują się z brzegu sieci jako pliki statyczne, co jest szybsze i stabilniejsze niż renderowanie na żądanie, powierzchnia ataku skurczyła się do mniej więcej niczego dynamicznego, a dostęp dla crawlerów stał się przewidywalny zamiast zależeć od zachowania wtyczek. Dla witryny treściowej, gdzie szybkość, stabilność i niezawodna czytelność dla crawlerów wyszukiwarek i AI są sednem, to właściwa wymiana.
Uczciwe zastrzeżenie jest takie samo, jakie powinno poprzedzać każde przeniesienie platformy: to właściwa wymiana dla witryny treściowej, a niewłaściwa dla witryny żyjącej z dynamicznych funkcji po zalogowaniu, gdzie renderowanie WordPressa na żądanie i jego ekosystem są zaletą, nie obciążeniem. Decyzja nie brzmi “statyczne jest lepsze”. Brzmi “statyczne jest lepsze dla tego kształtu witryny, a oto rok pracy z ogona, który słowo migracja ukrywa”. Więcej zapisków inżynierskich z tej przebudowy znajdziesz na blogu wppoland.
