Headless WP brzmi sexy, ale nie zawsze się opłaca. Lista pięciu sytuacji, w których to dobry wybór, i trzech, w których lepiej zostać z monolitem.
„Zróbmy headless WordPress" - to zdanie pada w briefach częściej, niż powinno. W większości przypadków klient chce Next.js z fajnym panelem do edycji treści i myśli, że właśnie tego potrzebuje. Czasem ma rację. Często nie.
“Headless WP to nie upgrade WordPressa. To zupełnie inny model utrzymania - i połowa klientów, którzy go chcą, naprawdę potrzebuje czegoś prostszego.
”
WordPress jako CMS dostarcza dwa interfejsy:
W headless setup WP zachowuje:
Traci:
Klient prowadzi sklep B2B z 500+ SKU + bloga z 200 artykułami. Frontendowo chce bardzo szybkiej strony z perfekcyjnym Core Web Vitals. Wynik: Next.js statycznie generuje listing z ISR-em (revalidate co godzinę), panele edytorskie zostają w WP, gdzie redaktorzy znają interfejs. Zysk: 90+ Lighthouse, panel, do którego zespół marketingu nie potrzebuje szkolenia.
Te same treści (opisy produktów, artykuły) muszą trafiać do:
REST API z WP staje się jednym źródłem prawdy. Bez headless trzeba by przepisywać treści w pięciu miejscach.
Klient ma design system w Figmie, mapowany 1:1 do React-owych komponentów. WP-motyw byłby bramą do chaosu - każdy redaktor mógłby wkleić dowolny HTML. W headless setup blok edytorski definiuje strukturę danych, a frontend renderuje to z użyciem znanych komponentów. Design system zostaje nienaruszony.
Jeśli strona ma pokazywać różne treści zalogowanym vs anonimowym, A/B-testować warianty hero, albo robić geolocation routing - robisz to na warstwie edge / middleware, gdzie WP-owy PHP byłby tylko przeszkodą.
Klasyczne WP-hostingi (cPanel, m.in.) są pod PHP i MySQL. Jeśli klient ma VPS i lubi Docker - headless WP siedzi w jednym kontenerze, frontend w drugim, Caddy / Nginx je proxuje. Hosting nie wymusza architektury.
Headless WP dla wizytówki to overengineering. Klasyczny motyw + lekki page builder (Bricks albo własny mini-builder z ACF) dowiezie szybciej, taniej i z lepszym preview.
W headless setup live preview wymaga konfiguracji. Każda zmiana w komponencie React-owym wymaga deployu frontendu. Jeśli klient chce „kliknąć i wystawić"
WooCommerce w headless setupie działa, ale traci się wszystko, co Woo dało za darmo - koszyk, checkout, integracje płatnicze, mailingi transakcyjne, panele reportowe. Trzeba przepisywać po stronie Next.js z użyciem np. WooCommerce REST API. Jeśli sklep ma poniżej 500 produktów i nie potrzebuje custom-checkout-flow, klasyczny Woo motyw wygrywa o lata świetlne.
| Sygnał | Klasyczny WP | Headless WP | Next + Sanity / Payload |
|---|---|---|---|
| Klient zna WP | Tak | Może | Nie |
| Strona ma 10+ powtarzalnych szablonów | Może | Tak | Tak |
| Strona ma 3-5 stron, rzadko aktualizowanych | Tak | Nie | Nie |
| Wymagana wysoka wydajność (CWV) | Może | Tak | Tak |
| E-commerce z WooCommerce | Tak | Nie | Nie |
| Multi-channel publishing | Nie | Tak | Tak |
| Klient ma własny hosting z PHP | Tak | Tak | Nie |
| Klient chce kliknąć i opublikować | Tak | Tak (z preview) | Tak |
Nie ma jednej odpowiedzi. Jest dziewięć pytań, które warto zadać przed podjęciem decyzji.
