Headless WordPress w 2026 to ustalony wybór inżynierski z nieustalonym biznesowym. Pytanie nie brzmi, czy Next.js albo Astro dobrze wyrenderują treść z WordPressa, bo oba to potrafią. Pytanie brzmi, co kupujesz drugim codebase'em, a uczciwa odpowiedź jest w WordPress core: odseparowany front płaci gotówką za każdą wygodę, którą monolit dostaje za darmo.
Większość porównań wycenia to mnożnikiem. Headless kosztuje dwa albo trzy razy budowę motywu, liczbę, której nikt nie sprawdzi i którą wszyscy cytują. Użyteczna wersja to lista konkretnych rzeczy, które core przestaje robić za ciebie, gdy front nie jest już motywem PHP, bo to pozycje, które agencja naprawdę wystawi na fakturze. Lista jest krótka, da się ją poznać z góry i to jest cały rok zero.
Ten artykuł to sama decyzja. Długi model z czteroletnim cashflow: przewodnik TCO headless vs monolit WordPress 2026.
1. Koszty budowy na start (rok 0)
Zacznij od tego, co API naprawdę oddaje, bo różnica między tym a działającą stroną to właśnie budowa.
Core dostarcza REST, nie GraphQL. REST_API_VERSION to 2.0 w wp-includes/rest-api.php, trasy da się rejestrować od 4.4, a przestrzeń wp/v2 to to, na co odpowiada stockowa instalacja WordPress 7.1.1. GraphQL to WPGraphQL, które stało się wtyczką kanoniczną w październiku 2024 z backingiem Automattic po przejściu Jasona Bahla. Canonical to mocny sygnał o utrzymaniu. To nie jest core. Instalujesz, wersjonujesz, patchujesz, a wycena agencji mówiąca „WordPress mówi GraphQL” pominęła zależność.
Potem konkretne rzeczy, za które zapłacisz programiście JavaScript:
Nawigacja. wp/v2/menus istnieje, WP_REST_Menus_Controller jest w core od 5.9 i nie odpowie na anonimowe żądanie. check_has_read_only_access() zwraca true tylko dla edit_theme_options, edit_posts albo uprawnienia edycji na publicznym typie posta, chyba że ktoś odwróci filtr rest_menu_read_access. Front albo uwierzytelnia się przy każdym buildzie, albo piszesz własny publiczny endpoint i bierzesz na siebie jego cache. To jest to, co każdy post o headlessie oznacza przez „trzeba zbudować menu”, bez mówienia dlaczego.
Podgląd. Szkice nie są danymi publicznymi i core ma rację. Odczyt nieopublikowanej treści to żądanie uwierzytelnione: application passwords (core od 5.6) albo wtyczka JWT, plus trasa podglądu na froncie, plus sposób, by redaktor kliknął Podgląd w wp-admin i tam wylądował. Trzy ruchome części, żadna opcjonalna, żadna w starterze frameworka.
CSS bloków. Filtr should_load_separate_core_block_assets nadal domyślnie ma false, ale core już go nie zostawia: _add_default_theme_supports() ustawia true dla motywów blokowych, a wp_load_classic_theme_block_styles_on_demand() (od 6.9) robi to samo dla klasycznych przez buffer szablonu. Stockowa strona 7.x drukuje style użytych bloków z wp_head() i wp_footer(). Twój front nie wywołuje żadnego. Albo importujesz ten stylesheet, albo restylujesz każdy blok core, który redaktorzy mogą wstawić: columns, gallery, quote, table, buttons, separator, cover. To nie jest trudna robota. To jest robota do wyceny, i zwykle nie pojawia się w estimate.
Formularze i wszystko z zachowaniem. Sekcja czwarta, bo to koszt po starcie, nie przed nim.
Nic z tego nie czyni headlessa złym wyborem. Czyni rok zero łatwym: jeśli nie finansujesz już zespołu frontendowego, monolit wygrywa na koszcie budowy za każdym razem, bo WordPress core robi za ciebie nieopłaconą pracę, którą inaczej zlecasz.
2. Utrzymanie i operacje (rok 1-3)
Bezpieczeństwo
Popularna wersja mówi, że odseparowana architektura rozdziela powierzchnię ataku, więc podatna wtyczka formularza nie dosięgnie bazy. To nieprawda w tej formie. Wtyczka nadal działa w tej samej instalacji WordPressa, na tej samej bazie, z tymi samymi capabilities. Decoupling przeniósł rendering. Nie przeniósł podatności.
Co decoupling naprawdę kupuje, to opcję, której monolit nie ma: skoro publiczna strona nie jest już WordPressem, możesz schować origin za allowlistą IP, VPN albo prywatną siecią i wystawić tylko front oraz potrzebne endpointy. Monolit tego nie zrobi, bo to, co chciałbyś ukryć, jest tym, na co patrzą odwiedzający. To realne zmniejszenie ekspozycji i kosztuje inżynierię sieciową, nie architekturę. Jeśli headless WordPress siedzi na publicznym hoście z wp-admin dostępnym z dowolnego miejsca, a większość tak ma, zapłaciłeś za architekturę i pominąłeś korzyść.
Druga połowa jest mniej pochlebna. Patchujesz dwa runtime’y w dwóch rytmach. WordPress wysyła minor releases z automatycznymi aktualizacjami w tle, a 7.1.1 weszło 17 września 2026 bez niczyjej pracy w zespole. Nic w drzewie zależności JavaScript nie zachowuje się tak. Next.js 16.3.5 wyszedł 11 września 2026, Astro 7.3.3 16 września 2026, a linie LTS Node wygasają według własnego kalendarza (Node 18 Hydrogen dostał ostatnie wydanie 27 marca 2025). Monolit ma jedną bieżnię upgrade’ów. Headless ma dwie, a szybsza to ta, której nikt nie budżetował.
Redesigny
Argument o zwinności to najmocniejszy realny punkt za headlessem i zwykle jest przeceniony o jedno słowo. „Front to czysty React albo Vue” nie jest dokładne dla Astro, które domyślnie nie wysyła JavaScriptu klienta. Dokładniejsze twierdzenie: gdy model treści stoi w miejscu, odseparowany front da się przebudować bez ruszania WordPressa, i to naprawdę tańsze niż walka z markupiem page buildera albo motywem z dziesięcioletnimi warunkowymi szablonami.
Zastrzeżenie to to samo zdanie odwrócone. Gdy redesign zmienia to, jaka treść istnieje, nie tylko jak wygląda, edytujesz dwa repozytoria, synchronizujesz dwa deploye i piszesz migrację, która musi wylądować w obu. Połowa redesignów sprzedawanych jako „tylko front” kończy się jednym nowym polem, i to jest dzień, w którym drugie repo przestaje być darmowe.
Dla sektora publicznego w USA jest data: finalna reguła DOJ pod ADA Title II (Federal Register, 24 kwietnia 2024) ustawia WCAG 2.1 Level AA dla treści webowych stanowych i lokalnych rządów, z deadlinami 2027 i 2028 zależnie od populacji. Jeśli przebudowa i tak się dzieje, to najtańszy moment wchłonąć dostępność, w dowolnej architekturze. W Polsce analogiczne ciśnienie w zamówieniach publicznych działa podobnie: WCAG wchodzi do scope przy przebudowie, nie jako osobna „późniejsza” warstwa.
3. Wydajność i współczynnik konwersji
Case wydajnościowy za headlessem był mocny w 2020. Od tamtej pory zawężył się z obu stron, i obie zmiany da się datować.
Najpierw zmieniła się metryka. INP zastąpiło FID jako Core Web Vital 12 marca 2024. FID mierzyło, jak długo przeglądarka potrzebowała, by zaakceptować pierwszą interakcję, co było prawie darmowe dla strony renderowanej po stronie serwera. INP mierzy opóźnienie interakcji przez całą wizytę, czyli bezpośrednio pracę głównego wątku. Front React ciężki od hydration jest z konstrukcji architekturą, która wysyła najwięcej pracy na main thread. SSR wyrównuje headless z motywem PHP na metrykach paint. Nie daje przewagi, a na INP może dać przegraną. Build, który traktuje JavaScript jako opt-in (Astro islands albo React Server Components), to wersja headlessa, która ten argument naprawdę wygrywa.
Core ruszył z drugiej strony. Speculative loading weszło w WordPress 6.8, opisane w dev note z 6 marca 2025 i żyjące w wp-includes/speculative-loading.php. Na stronie z pretty permalinkami, dla wylogowanych, core emituje Speculation Rules domyślnie, a 7.1 dodało WP_SPECULATIVE_LOADING_DEFAULT_MODE i WP_SPECULATIVE_LOADING_DEFAULT_EAGERNESS. Domyślnie tryb prefetch z conservative eagerness: core pobiera następny dokument, gdy wskaźnik idzie w dół na link. To prefetch, nie prerender. I tak zabiera część tego, co kiedyś było widocznym powodem routera JavaScript, na stockowym motywie bez żadnego routera.
Zostaje case biznesowy na własnych liczbach. Weź obecny współczynnik konwersji, dodaj jeden punkt procentowy, pomnóż przez rok zamówień i średnią wartość zamówienia, i porównaj z budową headless plus stałym inżynierem frontendowym. Na sklepie o dużym wolumenie lift spłaca koszt w pierwszym roku. Na katalogu o skromnym wolumenie nigdy nie spłaci, a uczciwa rekomendacja to ta, którą większość agencji pomija: wydaj te same pieniądze na cache, obrazy i checkout, i zostań przy motywie.
4. „Podatek od wtyczek”
To koszt po starcie, kończy życzliwość marketingu i ma precyzyjny mechanizm wart poznania przed podpisaniem czegokolwiek.
W WP_REST_Posts_Controller::prepare_item_for_response() pole content buduje się tak:
$data['content']['rendered'] = post_password_required( $post )
? ''
: apply_filters( 'the_content', $post->post_content );the_content działa. Shortcode’y się rozwijają, callbacki bloków się wykonują, markup wraca przez API. Nie wraca to, co wtyczka zarejestrowała na wp_enqueue_scripts, wydrukowała w wp_head() albo podpięła pod wp_footer(), bo twój front nigdy tego nie wywołuje.
Efekt wygląda jak bug. Shortcode slidera zwraca div z właściwymi klasami, bez stylesheetu i bez initializera. Tabela cen bez CSS. Formularz bez handlera submit. Redaktor widzi to działające w wp-admin (nadal monolit), widzi to zepsute na produkcji i otwiera ticket przeciw zespołowi frontendowemu.
Podatek nie brzmi „znajdź bibliotekę React pod koło fortuny”. Brzmi: każda wtyczka, którą marketing zainstaluje, przychodzi w połowie, ta połowa wygląda dobrze w CMS, a brakująca połowa to ticket do developera za każdym razem. Dwie wtyczki rocznie to szum. Dwie miesięcznie to retainer.
Są wyjątki. WooCommerce utrzymuje Store API pod wc/store, więc koszyk i checkout da się budować na udokumentowanym kontrakcie. To istnieje, bo WooCommerce to zbudowało i utrzymuje. Przytłaczająca większość katalogu wtyczek nie ma odpowiednika i nigdy nie będzie miała.
Druga strona: przycisk Install to też największa odpowiedzialność monolitu. Tak strona zbiera jedenaście wtyczek rejestrujących ten sam skrypt, i tak nowy marketingowiec wypuszcza tag trackingowy bez review. Headless czyni każdą instalację rozmową z inżynierem. Jeśli problemem governance jest to, że każdy może zainstalować wszystko, to tarcie jest feature’em, za który płacisz świadomie.
5. Koszty hostingu
Dwa runtime’y to dwa rachunki, i to najmniej interesująca część liczby.
Kształt to origin PHP dla WordPressa plus osobny host dla frontu, Node albo build statyczny, typowo na Vercel, Netlify albo Cloudflare. Opcja zunifikowana: platforma headless WP Engine łączy środowisko Node z hostingiem WordPressa u jednego vendora. Tak czy inaczej uruchamiasz dwie rzeczy tam, gdzie wcześniej jedną.
Pozycja, którą się pomija, to nie drugi rachunek. To publikacja docierająca do frontu. Na monolice publikacja unieważnia object cache i page cache. Na froncie generowanym statycznie publikacja musi coś wywołać: webhook on-demand revalidation, targeted purge albo scheduled rebuild. Ta ścieżka to kod, jest krucha jak webhooki bywają kruche, a gdy pada, redaktor twierdzi, że post jest live, podczas gdy strona się nie zgadza. Ktoś musi to mieć na własność, monitorować i być osiągalny w piątek o siedemnastej.
Druga pomijana pozycja to observability. Monolit ma jeden log. Odseparowany stack ma błędy PHP w jednym miejscu, failujące buildy frontu w drugim, requesty między nimi w trzecim, a pierwszy poważny incydent produkcyjny to moment, w którym okazuje się, że nikt ich nie korelował.
6. Werdykt: kiedy iść w headless?
Użyj tradycyjnego WordPressa, jeśli
- Budżet pokrywa jedną budowę, nie stałego inżyniera frontu potem.
- Marketing instaluje wtyczki wizualne bez developera w pętli.
- Strona informacyjna: speculative loading i cache już dają większość zysku prędkości.
- Brak JS in-house i braku planu zatrudnienia. Agencja zbuduje; ktoś musi utrzymać.
Użyj headless WordPressa, jeśli
- Publikujesz do więcej niż jednego destination z jednego workflow (strona + app / powierzchnia w produkcie).
- Naprawdę chowasz origin WordPressa; compliance albo threat model to uzasadnia.
- Wydajność = przychód, wolumen pokrywa stały zespół, JS jest opt-in.
- WordPress jest jednym systemem wśród ERP/CRM, model treści stabilny.
Headless to decyzja o staffing z architekturą dołączoną. Kto pisze front w miesiącu osiemnastym i czy jest na payrollu? Niepewna odpowiedź oznacza monolit.
Budujemy obie architektury; headless tylko gdy liczby wychodzą na jego korzyść. Astro na shortliście: programista Astro. Scope: kontakt.
