Dziesięć miesięcy migracji z WordPressa do Astro na Cloudflare Pages

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ęły się właściwe miesiące: 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.

[!NOTE] Projekt w skrócie

• Projekt: wppoland.com przeniesiony z WordPressa na Astro na Cloudflare Pages, przebudowa mojej własnej strony
• Zakres: sześć języków, 15 718 prerenderowanych stron i 8180 adresów w mapie witryny (build z 20.10.2026)
• Czas: start w grudniu 2025 (2 grudnia strona działała jeszcze na WordPressie z WPML i WP Rocket, według archiwum Wayback; repozytorium Astro powstało 21 grudnia), tygodnie do działającego buildu, pierwsza wersja tego raportu po pięciu miesiącach, aktualizacja po dziesięciu
• Build: przekroczył sufit 8 GB runnera Cloudflare Pages, rozwiązane budowaniem lokalnie ze stertą 16 GB i wdrażaniem artefaktu przez Wrangler
• Przekierowania: reguły 301, które trafiły na limit 100 KB pliku _redirects; dziś 3619 z nich żyje w mapie w Cloudflare Functions, a 249 w _redirects
• Stack: Astro z Tailwind CSS, potok obrazów AVIF, statyczny HTML serwowany z brzegu sieci
• Efekt: PageSpeed (laboratorium, mobile, 20.10.2026) 94 dla strony głównej PL i 98 dla strony usługi Astro, brak PHP i bazy danych na produkcji, utrzymany parytet sześciu języków

#Ile naprawdę kosztuje migracja WordPressa do Astro

1. Przeniesienie to tania część. Szablony i eksport treści zajęły tygodnie; po dziesięciu miesiącach długi ogon migracji nadal wymaga poprawek.
2. Warstwa przekierowań to pierwsza niespodzianka. Tysiące wcześniej zaindeksowanych adresów potrzebują własnego kodu 301, a sama ich liczba zderzyła się z limitem rozmiaru pliku na Cloudflare Pages, który po cichu odrzucał reguły.
3. 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 bez wyjątku.
4. Build przerósł własny runner platformy. Sufit 8 GB pamięci nie wystarcza na ponad 15 000 prerenderowanych stron; odpowiedzią było budowanie lokalnie ze stertą 16 GB i wdrażanie gotowego artefaktu przez CLI.

#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 użytkownika.
• Prerender - generowanie pełnego drzewa DOM każdej podstrony do fizycznego pliku HTML. Witryna z sześcioma językami mnoży liczbę stron przez liczbę języków, więc build skaluje się proporcjonalnie do siatki treści.
• Cloudflare Pages - platforma hostingowa serwująca pliki z globalnego brzegu sieci CDN, obsługująca mechanizmy brzegowe przez Pages Functions.
• Wrangler - narzędzie wiersza poleceń Cloudflare, używane tutaj do bezpośredniego wdrażania lokalnie skompilowanego katalogu dist/ z pominięciem ograniczeń runnera zdalnego.
• Hreflang - atrybuty w nagłówkach HTML informujące roboty indeksujące o lokalnych odpowiednikach danej strony w innych językach.
• Przekierowanie 301 - stałe przekierowanie HTTP przenoszące autorytet i historię zaindeksowanego adresu na nowy adres URL.

#Ile trwa przeniesienie WordPressa do Astro

Widoczna migracja to ta część, którą się szacuje, i szacunek bywa początkowo trafny. Treść wychodzi z bazy MySQL WordPressa w formie plików Markdown z nagłówkiem YAML frontmatter. Szablony PHP i motywy potomne są przepisywane na komponenty Astro z wykorzystaniem Tailwind CSS. Całość kompiluje się do katalogu wyjściowego i ląduje na serwerze brzegowym. Witryna treściowa średniej wielkości osiąga działający build statyczny w kilka tygodni. To faza, która doskonale prezentuje się na wewnętrznych prezentacjach i przekonuje zarząd, że projekt jest praktycznie ukończony.

W rzeczywistości projekt znajduje się dopiero na progu najtrudniejszego etapu. Działający build dowodzi wyłącznie tego, że komponenty Astro potrafią złożyć HTML bez błędów składniowych. Nie mówi nic o tym, czy tysiące historycznych adresów URL nadal poprawnie przekazują ruch, czy relacje hreflang nie uległy zerwaniu w wyszukiwarce Google oraz czy pamięć procesu Node.js udźwignie dalszy rozrost bazy artykułów.

#Przekierowania 301 po migracji z WordPressa do Astro

Po uruchomieniu buildu przyszła kolej na infrastrukturę przekierowań. Każdy adres URL, jaki WordPress wygenerował od 2006 roku (w tym archiwa dat, kategorie, tagi, taksonomie wtyczek i wersje językowe), musiał otrzymać precyzyjną regułę 301 prowadzącą do nowego odpowiednika w Astro. Brak takiej mapy skutkował natychmiastowym wzrostem błędów 404 w Google Search Console i utratą wypracowanych pozycji w rankingu.

Na jednojęzycznym serwisie przygotowanie takiej listy jest zadaniem liniowym. Przy serwisie obsługującym sześć języków z lokalizowanymi slugami (np. polskie, niemieckie, norweskie czy hiszpańskie nazwy usług) lista szybko poszła w tysiące wpisów. W październiku 2026 mapa w Cloudflare Functions ma 3619 reguł, a plik _redirects 249.

W tym momencie ujawniło się twarde ograniczenie platformy: plik _redirects w Cloudflare Pages posiada nieudokumentowany limit 100 KB. Powyżej tej wielkości parser platformy po cichu ignoruje nadmiarowe wiersze bez zgłaszania jakichkolwiek błędów podczas deployu. W rezultacie część reguł działała, a część zwracała błąd 404. Rozwiązaniem było przeniesienie logiki przekierowań do brzegowego handlera middleware napisanego w TypeScript (functions/redirect-map.ts), który dokonuje wyszukiwania w pamięci o złożoności O(1) na poziomie żądania brzegowego.

#Jak utrzymać spójny hreflang w sześciu wersjach językowych

W tradycyjnym WordPressie wtyczki wielojęzyczne (takie jak WPML czy Polylang) maskują złożoność relacji między wersjami językowymi za bazą danych. W architekturze statycznej cała struktura staje się bezpośrednio widoczna w plikach i nagłówkach.

Sześć wersji językowych każdego artykułu musi pozostawać strukturalnie i semantycznie równoległych:

• Identyczny zestaw nagłówków merytorycznych H2 i H3 we właściwym porządku logicznym.
• Pełna siatka odnośników hreflang w sekcji head, wskazująca bezbłędnie na wszystkie 5 rodzeństw językowych.
• Kanoniczne adresy URL odzwierciedlające właściwą domenę i ścieżkę językową.
• Spójność taksonomii i powiązań między kategoriami w każdym języku.

Gdy jedna wersja językowa ulega zmianie (np. dodanie nowej sekcji lub zmiana sluga), brak automatyzacji prowadzi do natychmiastowego dryfu wersji. Wyszukiwarki napotykające asymetryczne tagi hreflang zaczynają ignorować sygnały regionalne, co prowadzi do kanibalizacji treści między rynkami. Z tego powodu wprowadziłem automatyczny skrypt walidacji relacji wielojęzycznych uruchamiany przed każdym commitem.

#Błąd JavaScript heap out of memory w buildzie Astro

Astro kompiluje strony statyczne w jednym procesie roboczym. Gdy serwis rozrósł się do ponad 14 000 podstron (w październiku 2026 jest ich 15 718) (łącząc bazę wiedzy, przewodniki techniczne, strony ofertowe i lokalne profile miast w 6 językach), silnik V8 w domyślnej konfiguracji wyczerpał limit 4 GB pamięci podręcznej.

Standardowy runner Cloudflare Pages dysponuje 8 GB pamięci RAM, co przy intensywnej kompilacji TypeScriptu, przetwarzaniu bloków MDX, parsowaniu drzew AST i optymalizacji stylów Tailwind CSS okazało się niewystarczające. Proces kompilacji kończył się błędem JavaScript heap out of memory.

Problem rozwiązano poprzez przebudowę całego przepływu wdrożeniowego:

1. Lokalny profil budowania na procesorach Apple Silicon: Build wykonuje się lokalnie z jawnie przydzieloną stertą (--max-old-space-size, w produkcyjnym profilu 16 GB). 20 października 2026 krok astro build złożył 15 718 stron w 5 minut 30 sekund, a wysyłka plików przez Wrangler trwała kolejne 338 sekund.
2. Czyszczenie rusztowania prerenderu: Astro podczas kompilacji tworzy katalog dist/.prerender z modułami serwerowymi. Pojedynczy plik potrafił osiągnąć 43.9 MiB, co blokowało deploy (Cloudflare Pages odrzuca pojedyncze pliki powyżej 25 MiB). Skrypt wdrożeniowy automatycznie usuwa zbędne artefakty przed wysyłką.
3. Bezpośredni upload przez Wrangler: Gotowy, zwalidowany katalog dist/ jest wgrywany bezpośrednio do sieci brzegowej, eliminując zawodny krok budowania w chmurze.

#Jak podzielić sitemapę Astro na wiele plików

Jednym z najtrudniejszych wyzwań okazało się generowanie map witryn (sitemap). Domyślna integracja @astrojs/sitemap nie zna reguł indeksowalności, które mam w poszczególnych kolekcjach (noindex, progi długości, strony miast).

Zbudowałem własny generator. W październiku 2026 daje on taki układ:

• Główny plik sitemap-index.xml wskazuje 24 mapy, po cztery na każdy z sześciu języków.
• Każdy język ma osobne pliki dla stron usług (sitemap-pages.xml), bloga, portfolio i stron miast (sitemap-locations.xml), razem 8180 adresów.
• Rygorystyczny filtr wykluczający adresy z metatagiem noindex (skrypt check:noindex-sitemaps gwarantuje, że do sitemapy nie trafia ani jeden adres nieindeksowalny).

Dzięki takiemu podziałowi roboty Google, Bing i crawlerów AI pobierają mapy partiami, bez przekraczania limitów czasowych i bez przeciążania bufora pamięci.

#Automatyczne testy przed wdrożeniem strony w Astro

Najmniej docenianym kosztem odejścia od CMS-a jest konieczność napisania własnych narzędzi kontroli jakości, które WordPress i jego wtyczki realizowały niewidocznie w tle. WordPress automatycznie blokował tworzenie zduplikowanych slugów, dbał o spójność relacji w bazie MySQL i weryfikował linki podczas zapisu. W świecie statycznym każda pomyłka w pliku Markdown natychmiast trafia na produkcję, jeśli nie zostanie wykryta przez zautomatyzowane testy.

Do maja 2026 powstały 34 bramki kontrolne (skrypt run-gates.mjs); w październiku 2026 npm run gates wymienia ich ponad 120. Przykłady:

• Weryfikacja linków wewnętrznych (check:incoming-internal-links i check:service-navigation-parity): Sprawdzenie, że każda usługa ma odnośniki przychodzące i że nawigacja jest zgodna we wszystkich językach.
• Kontrola spójności językowej i diakrytyków (check:diacritic-wordlist): Wykrywanie błędów kodowania znaków narodowych w każdym z sześciu języków.
• Strażnik wycieku cen (check:no-own-prices): Automatyczny audyt sprawdzający, czy twarde kwoty nie pojawiają się w treściach poradnikowych poza zatwierdzonymi stronami cennika.
• Walidacja bezpieczeństwa CSP (check:csp-inline): Skanowanie wygenerowanych plików HTML pod kątem skrótów SHA-256 dla skryptów liniowych w celu utrzymania restrykcyjnej polityki Content Security Policy.
• Audyt retoryki AI (check:slop-rhetoric): Sprawdzanie tekstów pod kątem pustych zwrotów marketingowych i sztucznych konstrukcji językowych.

Każda z tych bramek powstała po konkretnym błędzie, który wcześniej trafił na produkcję.

#Optymalizacja obrazów i lokalne fonty w Astro

W dynamicznym WordPressie przetwarzanie mediów opiera się na bibliotece GD lub ImageMagick wywoływanej w momencie wysyłania pliku przez formularz mediów. W statycznym ekosystemie Astro optymalizacja obrazów staje się częścią potoku kompilacji.

W początkowej fazie projektu skierowanie setek wielomegabajtowych grafik rastrowych przez wbudowany komponent obrazów Astro doprowadziło do gwałtownego wydłużenia czasu buildu i wyczerpania pamięci przez silnik Sharp. Wdrożyłem rygorystyczny podział zasobów:

1. Wstępna kompresja tła i elementów stałych: Grafiki dekoracyjne oraz statyczne tła są konwertowane do formatu AVIF i WebP przed umieszczeniem w katalogu public/, co pozwala serwować je bezpośrednio z CDN bez obciążania pamięci kompilatora.
2. Dynamiczne warianty dla grafik artykułów: Obrazy w treści są procesowane z jawnym określeniem wymiarów width i height, co zapobiega przesunięciom układu (Cumulative Layout Shift).
3. Prywatność i lokalne fonty: Całkowicie wyeliminowałem zewnętrzne zapytania do Google Fonts. Krój Geist jest serwowany z mojej domeny jako pliki WOFF2 z podzbiorem łacińskim (paczka @fontsource/geist), co zapobiega blokowaniu renderowania tekstu i spełnia wymogi europejskiego RODO.

#Jak dodać JavaScript do formularzy na statycznej stronie w Astro

Największą zaletą Astro jest domyślna wysyłka zerowej ilości JavaScriptu do przeglądarki użytkownika (Zero-JS by default). Dla serwisu treściowego oznacza to, że czytelnik przeglądający artykuły techniczne nie pobiera żadnych frameworków frontendowych.

W miejscach, gdzie interaktywność jest niezbędna (formularz kontaktowy, wyszukiwarka, kalkulatory), dokładam mały skrypt tylko na tej stronie:

• Formularz kontaktowy to zwykły HTML z krótkim skryptem w komponencie, bez frameworka po stronie przeglądarki.
• Zabezpieczenie antyspamowe realizowane jest przez Cloudflare Turnstile bez łamigłówek graficznych CAPTCHA.
• Dane trafiają do endpointu w Cloudflare Pages Functions (functions/api/enquiry.ts), który wysyła wiadomość przez Resend, a gdy Resend zawiedzie, przez Web3Forms. Nie ma serwera aplikacji do utrzymania.

#Checklista migracji z WordPressa do Astro

Na podstawie tej migracji zebrałem checklistę inżynieryjną, którą należy zrealizować przed ostateczną zmianą rekordów DNS:

1. Inwentaryzacja wszystkich tras: Wygenerowanie pełnego zrzutu adresów URL z bazy WordPressa (w tym stron, wpisów, archiwów, autorów, załączników i kanałów RSS).
2. Projekt mapy przekierowań 301: Przygotowanie tabeli mapowania starych adresów na nowe slugi z uwzględnieniem struktury wielojęzycznej.
3. Wdrożenie przekierowań brzegowych: Umieszczenie mapy przekierowań w kodzie funkcji brzegowej (Cloudflare Functions / Worker), omijając limity wielkości plików statycznych.
4. Walidacja siatki hreflang: Sprawdzenie, czy każdy artykuł we wszystkich wersjach językowych posiada kompletne i wzajemne odnośniki alternatywne.
5. Audyt danych strukturalnych JSON-LD: Zweryfikowanie schematów Article, FAQPage, HowTo i Organization pod kątem zgodności ze standardem schema.org.
6. Podział map witryn na moduły: Utworzenie indeksu sitemap oraz dedykowanych podplików dla poszczególnych typów treści.
7. Test wydajnościowy kompilacji: Przetestowanie buildu w środowisku z ograniczoną pamięcią i zoptymalizowanie alokacji sterty V8.
8. Wdrożenie nagłówków bezpieczeństwa: Skonfigurowanie Content Security Policy (CSP), HSTS, X-Frame-Options i Permissions-Policy na poziomie brzegu sieci.
9. Sprawdzenie spójności metatagów noindex: Upewnienie się, że strony techniczne, szablony i duplikaty są poprawnie wykluczone z indeksowania.
10. Plan monitoringu post-migracyjnego: Skonfigurowanie automatycznych testów dymnych (Smoke Tests) weryfikujących kody odpowiedzi HTTP oraz stan indeksu w Search Console po przełączeniu DNS.

#Wyszukiwarka na statycznej stronie w Astro

Jednym z kluczowych argumentów przemawiających dawniej za WordPressem była wbudowana funkcja wyszukiwania oparta na zapytaniach SQL do bazy wp_posts. W architekturze statycznej brak serwera bazodanowego wymusił zmianę podejścia do przeszukiwania zasobów.

Zamiast zapytań do bazy wyszukiwarka korzysta z indeksu generowanego przy buildzie:

• Dla każdego języka powstaje osobny plik JSON (/api/search/<język>.json). Podział na języki był konieczny, bo jeden wspólny plik przekraczał limit 25 MiB na plik w Cloudflare Pages.
• Strona wyszukiwarki pobiera indeks swojego języka i przeszukuje go w przeglądarce biblioteką Fuse.js. Plik ma dziś 7,7 do 9,4 MB, więc pobiera go tylko ten, kto otworzy wyszukiwarkę, a nie każdy czytelnik.
• Serwer nie wykonuje żadnej pracy przy wyszukiwaniu, niezależnie od liczby użytkowników. Kosztem jest rozmiar indeksu, który rośnie razem z blogiem.

#Jak mierzyć Core Web Vitals po migracji z WordPressa do Astro

W tradycyjnym środowisku WordPress wskaźniki Core Web Vitals często ulegały degradacji po instalacji kolejnej wtyczki marketingowej lub zmianie motywu. W Astro pilnuję wydajności tak:

• Lighthouse w GitHub Actions: workflow lighthouse.yml uruchamiam ręcznie albo etykietą na pull requeście, przy zmianach w szablonach i układzie. Nie biegnie przy każdym commicie, bo limit minut Actions jest skończony.

• Pomiar PageSpeed Insights: 20 października 2026 wynik laboratoryjny na mobile to 94 dla /pl/ (LCP 2,7 s) i 98 dla /en/astro-developer/ (LCP 2,3 s). Danych terenowych CrUX Google dla tych adresów jeszcze nie pokazuje, więc to pomiar laboratoryjny, nie ocena Core Web Vitals.

• Natychmiastowe czyszczenie cache brzegowego (Edge Cache Purging): Po wdrożeniu nowego artefaktu skrypt deployu automatycznie wywołuje API strefy Cloudflare (purge_cache: {"purge_everything": true}), co gwarantuje, że użytkownicy na całym świecie natychmiast widzą zaktualizowane treści bez oczekiwania na wygaśnięcie nagłówków s-maxage.

#Czy po PHP2Shell przenieść stronę z WordPressa na stronę statyczną?

21 października 2026 roku projekt PHP wydał poprawki dla PHP2Shell, dwóch krytycznych luk w samym PHP (CVE-2026-109618 i CVE-2026-109619). Według php.net zagrożona jest każda instalacja PHP obsługująca żądania WWW, a dla konfiguracji najwyższego ryzyka istnieje działający exploit uruchamiany, zanim wystartuje jakikolwiek kod aplikacji (php.net). Wiz Research dodaje, że podatna może być nawet prosta aplikacja “Hello World” na dotkniętej wersji PHP (Wiz). Strona generowana do plików HTML i serwowana bez PHP jest poza zakresem tego komunikatu. Ta strona do nich należy: w tamtym tygodniu nie było tu żadnego PHP do aktualizacji. Co zrobić na stronie, która nadal działa na PHP, opisuję w poradniku o PHP2Shell.

W tym samym tygodniu na r/webdev autor serwisu technicznego, który przeniósł się z WordPressa na Hugo i Cloudflare Pages, tak opisał zysk w bezpieczeństwie:

Największą korzyścią jest dla mnie to, że nie mam już wystawionego na świat, znanego wszystkim i ciągle sondowanego panelu /wp-admin/, a potem martwienia się o luki w stosie pod spodem.

(tłumaczenie własne, u/Select_From, r/webdev)

W drugim wątku programista napisał, że po PHP2Shell przeniósł z pomocą agenta AI 45 klienckich stron z WordPressa na Astro w 36 godzin. Jedna z pierwszych odpowiedzi pytała o to, czego statyczny build nie rozwiązuje:

W README na GitHubie ciągle piszesz o plikach statycznych, ale co z nowymi wpisami? Czego używasz, żeby klienci mogli dodawać nowe dane albo edytować istniejące?

(tłumaczenie własne, u/Lower_Rabbit_5412, r/webdev)

Autor odpowiedział, że dla 2 lub 3 klientów, którzy chcieli sami edytować stronę, zbudował CMS oparty na Gicie. Powierzchnia ataku PHP znika, a każde dynamiczne zadanie, które WordPress załatwiał w jednym miejscu, przenosi się gdzie indziej i potrzebuje własnego opiekuna:

Odpowiedź w wątku o Hugo ułożyła kolejność problemów tak, jak sam na nie trafiłem:

Największą przeszkodą są zwykle permalinki, każdy stary URL potrzebuje 301, inaczej tracisz pozycje. Potem elementy dynamiczne: komentarze, wyszukiwarka, formularze.

(tłumaczenie własne, u/ResidentPomegranate6, r/webdev)

Przeniesienie szablonów zajęło mi tygodnie, a kolejne miesiące poszły na przekierowania, hreflang i testy opisane wyżej. Migracja oznacza budowę strony od nowa.

Aktualizacje i stałe utrzymanie to często lepsza odpowiedź. PHP2Shell zamknęła aktualizacja PHP, a migracja trwająca tygodnie nic nie daje serwerowi, który jest niezałatany dziś. Zostań przy WordPressie, WooCommerce, Magento albo innym stosie PHP i dbaj o aktualizacje, jeśli redakcja codziennie pracuje w panelu, jeśli firma opiera się na wtyczkach z prawdziwą logiką (sklep, rezerwacje, członkostwa, kursy) albo jeśli nikt w zespole nie przejmie pracy z Gitem. Statyczny build pasuje, gdy treść zmienia się rzadko, edytuje ją niewiele osób, a część dynamiczna sprowadza się do formularza i wyszukiwarki. Strona na PHP potrzebuje regularnego utrzymania WordPressa razem z aktualizacjami PHP; przebudowę na stronę statyczną robi programista Astro.

Aktualizacja 24 października 2026, droga pośrednia: zostanie na WordPressie i przepisanie strony w Astro to nie jedyne dwie opcje. Matt Cromwell opisał 14 października 2026, jak przebudował stronę swojej firmy bez publicznej instalacji WordPressa. WordPress działa tylko na jego komputerze, w WordPress Studio. Kompilator zamienia jego system projektowy w theme.json i wielokrotnego użytku wzorce bloków, wtyczka Simply Static eksportuje stronę do plików statycznych, a serwuje je Cloudflare Pages. Edytor blokowy zostaje, a na publicznej stronie nie ma PHP do łatania. Dodatkowa praca pojawia się przy formularzach: wtyczka formularzy, która wysyła dane przez PHP, nie zadziała na wyeksportowanych stronach, więc zapisy do newslettera trafiają do MailerLite przez osobny adres API, który napisał sam. Cromwell zaznacza też, że statyczna strona ma swoje granice niezależnie od wtyczki. Taki układ pasuje do strony firmowej edytowanej na jednym komputerze. Sklep, strefa dla członków albo zespół, który codziennie publikuje, dalej potrzebują serwera. Jeśli panel edycji musi być dostępny online, a front strony ma działać bez PHP, to już headless CMS.

#Wyniki migracji z WordPressa do Astro po dziesięciu miesiącach

Po dziesięciu miesiącach bilans migracji z WordPressa do Astro jest dodatni, pod warunkiem że serwis ma charakter treściowo-usługowy:

1. Czas odpowiedzi serwera (TTFB): Strona z cache brzegowego Cloudflare odpowiada z Gdyni w około 0,21 do 0,26 s, licząc z połączeniem TLS (curl, 20.10.2026). Porównywalnego pomiaru z czasów WordPressa nie mam, więc nie podaję procentowej poprawy.
2. Redukcja powierzchni ataku: Bez PHP, bazy SQL i wp-admin znikają całe klasy ataków typowe dla WordPressa: SQL injection, wykonanie kodu przez dziurawą wtyczkę, brute force na logowanie. Zostaje mniejsza powierzchnia, którą trzeba pilnować: endpointy w Cloudflare Functions (formularz, API) i nagłówki bezpieczeństwa.
3. Efektywność dla crawlerów wyszukiwarek i AI: Czysty, semantyczny kod HTML bez zbędnego narzutu JavaScriptu pozwala robotom indeksującym (w tym crawlerom OpenAI, Anthropic i Perplexity) na natychmiastowe parsowanie treści, co bezpośrednio wspiera widoczność w wyszukiwarkach generatywnych (GEO/AEO).
4. Przewidywalność kosztów: Serwowanie statycznych plików z brzegu sieci generuje znikome koszty infrastruktury w porównaniu z utrzymaniem dedykowanych klastrów bazodanowych pod dużym ruchem.

Uczciwy wniosek dla zespołów technicznych rozważających podobny krok: migracja do Astro nie jest prostym zabiegiem frontendowym. To kompleksowy projekt inżynieryjny, w którym samo kodowanie szablonów stanowi ułamek pracy, a główny wysiłek koncentruje się na architekturze routingu, automatyzacji testów jakościowych i dyscyplinie wielojęzycznej. Dla serwisów treściowych, którym zależy na szybkości i zasięgu w wielu językach, ta praca się opłaca. Jeśli chcesz wdrożyć taką architekturę w swojej firmie, sprawdź, jak pracuję jako programista Astro, a w przypadku istniejących serwisów zapoznaj się z ofertą migracji z WordPressa do Astro. Dalsze szczegółowe studia przypadków publikuję na blogu technologicznym WPPoland.