Headless WordPress — kiedy faktycznie ma sens, a kiedy to przerost formy

„Zrobimy Ci WordPressa w architekturze headless” — jedno z modniejszych haseł w prezentacjach ofertowych agencji digitalowychowych. Next.js po stronie użytkownika, WordPress jako zaplecze (wyłącznie baza i panel administracyjny), komunikacja przez REST API, wdrożenie na Vercelu. Brzmi nowocześnie i szybko. W praktyce — dla 80% klientów to niepotrzebna komplikacja, która wychodzi drożej, wolniej się rozwija i wymaga dwóch programistów tam, gdzie wystarczał jeden.

Kiedy ma sens, a kiedy nie — z perspektywy agencji, która zbudowała kilka takich wdrożeń i kilku klientów odradziła architekturę headless na rzecz klasycznej.

Co to jest headless WordPress

Najpierw metapytanie: czy WordPress w ogóle ma jeszcze sens w 2026 jako backend? Tak, ale z zastrzeżeniami — jeśli rozważasz headless, warto najpierw przemyśleć czy fundament (WP) jest właściwy dla Twojego projektu.

Standardowy WordPress: PHP renderuje HTML po stronie serwera, motyw buduje interfejs, użytkownik otrzymuje gotowy dokument.

Architektura headless: WordPress pełni funkcję wyłącznie zaplecza (baza danych plus panel administracyjny), nie renderuje strony. Dane udostępnia przez REST API albo GraphQL (za pośrednictwem wtyczki WPGraphQL). Warstwa widoczna dla użytkownika to osobna aplikacja (Next.js, Astro, Nuxt, Gatsby), która pobiera dane z WordPressa i renderuje je po swojemu.

Architektura: [użytkownik] → [Next.js na Vercelu] → [REST API WordPressa] → [MySQL].

Zamiast jednej aplikacji masz dwie, które trzeba utrzymywać.

Kiedy ma sens — cztery konkretne sytuacje

1. Ogromna skala treści z nietypowym interfejsem

Przykład: serwis redakcyjny z 50 000 artykułów, 500 redaktorów, własnym procesem publikacji. WordPress jako system zarządzania treścią — świetny. Ale warstwa widoczna dla użytkownika zbudowana w React z generacją statyczną lub ISR pozwala na:

• statyczne generowanie artykułów (Vercel, Netlify),
• Incremental Static Regeneration — przebudowa tylko zmienionych artykułów,
• optymalizację obrazów przez next/image,
• rozproszenie treści na brzegowe serwery CDN na całym świecie.

Dla klienta o takiej skali różnica w LCP i koszcie serwera jest wymierna (redukcja 50–70%).

2. Treść dla wielu kanałów

WordPress jako źródło treści dla:

• strony głównej (Next.js),
• aplikacji mobilnej (React Native, Flutter),
• aplikacji na Smart TV,
• systemu mailingowego (pobiera treść przez REST),
• asystenta głosowego.

Wszystkie kanały odpytują ten sam serwis API. Architektura headless rozwiązuje tu realny problem: jedno źródło prawdy.

3. Integracje z zewnętrznymi usługami po stronie przeglądarki

Wyszukiwarka Algolia, system płatności Shopify osadzony jako element strony, strona rozliczeń w Stripe, Contentstack dla części treści. Tyle ruchomych części i własnej logiki w przeglądarce, że PHP z motywem staje się problemem. Oddzielna aplikacja w React wprowadza czytelne granice między komponentami.

4. Wymagania RODO lub inne wymagania zgodności z separacją warstw

Gdy dział prawny wymaga, żeby baza danych użytkowników była oddzielona od warstwy publicznej. Architektura headless na to pozwala — zaplecze za firmowym VPN-em, warstwa publiczna w internecie, komunikacja przez bramę API z ograniczaniem ruchu i pełnym logowaniem.

Kiedy NIE ma sensu — najczęstsze błędy

1. „Bo jest szybciej” — to mit

Tradycyjny WordPress z dobrą warstwą pamięci podręcznej (Redis, WP Rocket, Cloudflare) daje TTFB na poziomie 100–200 ms i LCP 1,5–2,5 s.

Architektura headless z Next.js i WordPressem jako zapleczem też daje podobne TTFB przy renderowaniu po stronie serwera, ale ma dodatkową warstwę odpytania WordPressowego REST API przy każdej regeneracji strony. Jeśli API WordPressa działa wolno (napuchnięty autoload, duża baza, brak pamięci podręcznej w PHP), architektura headless okazuje się wolniejsza niż tradycyjny WordPress z dobrze skonfigurowanym cache’em.

U jednego klienta po przejściu na headless LCP wzrosło z 1,8 s do 2,4 s — bo zapytanie WPGraphQL trwało 400 ms, a Next.js musiał je wywoływać przy każdej regeneracji strony.

2. „Bo bezpieczniej” — też mit

Tradycyjny WordPress z firewallem aplikacyjnym (Wordfence, Cloudflare) i regularnymi aktualizacjami jest bezpieczny. W architekturze headless REST API jest wystawione na świat — to nowa powierzchnia ataku (złamane autoryzacje, wstrzyknięcia w parametrach zapytań, błędy autoryzacji dostępu do zasobów typu IDOR).

W 2023 roku CVE-2023-5561 — podatność REST API WordPressa ujawniająca adresy e-mail użytkowników. Dotknęła wszystkich instalacji, ale wdrożenia headless z publicznym API były mocniej eksponowane, bo to API było aktywnie wykorzystywane.

3. Gutenberg traci większość funkcji

Klient lubi Gutenberga. Edytuje bloki, widzi podgląd na żywo. W architekturze headless Gutenberg nie działa tak, jak na klasycznej stronie. Edytor dostaje surowe dane JSON z blokami, które aplikacja po stronie użytkownika musi renderować własnym parserem. Tracisz około 70% funkcjonalności Gutenberga.

Tak samo z Elementorem, Divi i innymi kreatorami — żaden z nich nie działa w architekturze headless. Klient, który przywykł do edycji metodą przeciągnij-i-upuść, musi nauczyć się pracy z treścią w Markdownie lub polami ACF w panelu administracyjnym. Dla wielu biznesów to warunek nie do zaakceptowania.

4. Koszt utrzymania rośnie dwukrotnie

• Dwa wdrożenia (zaplecze WordPressa plus warstwa widoczna w Next.js).
• Dwa monitoringi dostępności.
• Dwa zestawy aktualizacji (wtyczki WordPressa plus paczki npm).
• Dwoje programistów (zaplecze WordPressowe plus front w React) zamiast jednego programisty łączącego obie role.

Dla sklepu z 500 produktami i blogiem na 100 postów architektura headless oznacza dwu- lub trzykrotnie wyższą fakturę miesięczną bez wymiernej korzyści biznesowej.

Co widzieliśmy u klientów (anonimizowane)

Klient A, sklep z 200 produktami i 3000 użytkowników miesięcznie. Zaczęli od architektury headless (Next.js plus zaplecze WordPressa). Po ośmiu miesiącach wrócili do klasycznej instalacji WordPressa z szablonem blokowym i WP Rocketem. Powody:

• Gutenberg przestał działać, marketing się buntował.
• Zautomatyzowane wdrożenia dla dwóch aplikacji zawodziły co drugi raz.
• Koszt hostingu wzrósł z 200 zł/mies. do 780 zł (Vercel plus serwer WordPressa plus CDN).
• Po powrocie do klasycznej architektury LCP się nie pogorszył, a konwersja wzrosła o 8%, bo marketing znów mógł eksperymentować.

Klient B, portal branżowy z 30 000 artykułów i 400 000 użytkowników miesięcznie. Headless (Next.js plus zaplecze WordPressa). Po 18 miesiącach dalej używają. Powody:

• Wydajność w warunkach produkcyjnych: LCP 1,1 s — nieosiągalne na klasycznym WordPressie w tej skali bez ogromnych inwestycji w infrastrukturę.
• Regeneracja statyczna przebudowuje tylko zmienione strony — 30 000 artykułów bez problemu.
• API jest wykorzystywane także przez aplikację mobilną — jedno źródło, dwa kanały.
• Koszt: około 4500 zł/mies. za warstwę widoczną plus zaplecze, ale oszczędność czasu redakcji i wygoda pracy programistów są tego warte.

Architektura pośrednia — dobra dla większości

Jeśli naprawdę chcesz korzyści architektury headless (przebudowa przyrostowa, pamięć podręczna na brzegu, szybki LCP), ale bez wszystkich jej kosztów — rozwiązanie pośrednie: generator stron statycznych plus WordPress jako źródło treści:

• WordPress jako system zarządzania treścią (klasyczny, z Gutenbergiem),
• Astro, Gatsby albo 11ty buduje statyczną stronę, pobierając dane z WordPressa przez REST,
• wdrożenie gotowego HTML-a na CDN,
• zaplecze WordPressa może działać nawet na lokalnym serwerze VPS — warstwa publiczna żyje na brzegowych serwerach.

Stosujemy to u kilku klientów. Efekt: LCP poniżej jednej sekundy, TTFB 50 ms, utrzymanie jest proste (tylko jedna aplikacja w ciągłym wdrożeniu). Strona devance.agency działa właśnie tak — chociaż bez WordPressa, bo treść trzymamy w plikach Markdown.

Decyzja — lista kontrolna

Wybierz architekturę headless, jeśli:

• masz 10 000 artykułów lub produktów i więcej,
• wiele kanałów (strona, aplikacja mobilna, inne) pobiera treść z tego samego źródła,
• masz zespół z programistami Reactowymi, nie tylko specjalistów od WordPressa,
• budżet utrzymania przekracza 3000 zł miesięcznie,
• wydajność realnie przekłada się na przychód.

Zostań przy klasycznym WordPressie (z optymalizacją), jeśli:

• sklep lub strona do 5000 produktów,
• marketing pracuje w Gutenbergu albo Elementorze i jest z tego zadowolony,
• budżet poniżej 2000 zł miesięcznie,
• masz jednego programistę albo jedną agencję.

Jeśli chcesz nowoczesnego efektu bez zbędnej komplikacji, rozważ szablony blokowe z Full Site Editingiem i WP Rocketem. Szczegóły w osobnym artykule o szablonach blokowych.

W Devance odmawiamy prowadzenia projektów w architekturze headless, jeśli nie spełniają powyższej listy kryteriów. To nie duma, tylko realizm — w takich przypadkach klient zostałby z droższym i gorzej działającym systemem niż wcześniej. Jeśli rozważasz headless i chcesz uczciwą opinię (tak lub nie, z uzasadnieniem) — umów konsultację.