Headless WordPress: co to jest, jak działa i kiedy się opłaca

Headless WordPress to sposób budowy strony, w którym WordPress zostaje wyłącznie panelem do zarządzania treścią, a to, co widzi odwiedzający, generuje osobna aplikacja frontendowa, najczęściej w Next.js. Oba elementy rozmawiają ze sobą przez API. Redaktor odczuje niewiele. Dla odwiedzających i dla wyników w Google zmienia się sporo. Ta architektura ma też swoją cenę, a w części firm klasyczny WordPress zostaje lepszym wyborem.

Czym headless różni się od klasycznego WordPressa?

Tym, kto składa stronę. W klasycznym WordPressie jeden system robi wszystko: przechowuje treść, udostępnia panel redaktorom i renderuje stronę za pomocą motywu. Każde wejście użytkownika uruchamia PHP, zapytania do bazy i kod wszystkich aktywnych wtyczek. Przy kilku wtyczkach to nie problem. Przy czterdziestu strona zaczyna się dławić.

W podejściu headless („bezgłowym”) odcinamy warstwę prezentacji, a WordPress zostaje tym, w czym jest dobry, czyli panelem do pisania, edycji i organizowania treści. Strony już nie wyświetla. Dane wystawia przez REST API, wbudowane w każdy WordPress, albo przez WPGraphQL. To wtyczka, dzięki której dana podstrona pobiera dokładnie te pola, których potrzebuje.

Po drugiej stronie stoi frontend: osobna aplikacja, która pobiera treść z API i składa z niej gotowe strony HTML. Najczęściej jest to Next.js, framework oparty na React, który generuje podstrony z wyprzedzeniem (statycznie) albo na żądanie i serwuje je z sieci CDN, czyli z serwerów rozmieszczonych blisko użytkownika. Stąd określenie „WordPress Next.js”.

Headless WordPress to jeden z wariantów headless CMS. Redaktorzy dostają w nim znany panel, a firma nie musi przenosić treści do nowego systemu.

Co się zmienia dla redaktora?

Zaskakująco mało. Osoba, która dodaje wpisy i poprawia podstrony, loguje się do tego samego wp-admin, pisze w Gutenbergu, wrzuca zdjęcia do biblioteki mediów, ustawia kategorie i tagi. Jeśli strona używała ACF (Advanced Custom Fields) do pól typu „cena od” czy „sekcja z opiniami”, te pola zostają na swoim miejscu.

Różnica wychodzi przy publikacji. Klasyczny WordPress pokazuje zmianę od razu, bo renderuje stronę przy każdym wejściu. W headless frontend musi się o zmianie dowiedzieć. Może przebudować konkretną podstronę, gdy dostanie sygnał z WordPressa (to tak zwana rewalidacja, w Next.js część mechanizmu ISR, czyli Incremental Static Regeneration), albo pobierać świeże dane co ustalony czas. Dobrze skonfigurowany projekt publikuje zmianę w ciągu kilku sekund. Źle skonfigurowany każe czekać na pełną przebudowę, a redaktorzy odbierają to jako awarię.

Drugą rzeczą do zaprojektowania jest podgląd. Przycisk „Podejrzyj” w WordPressie domyślnie pokazuje stronę wyrenderowaną przez motyw, którego w headless już nie ma. Frontend potrzebuje więc trybu podglądu wersji roboczych dla zalogowanego redaktora. To standardowy element wdrożenia. Jeśli wykonawca o nim zapomni, marketing będzie publikował „w ciemno”.

Co zyskujesz na headless WordPress?

Szybkość i Core Web Vitals

To główny powód, dla którego firmy w ogóle rozważają ten model. Strona z Next.js serwowana jako gotowy HTML z CDN nie czeka na PHP, bazę danych ani wtyczki. Google bierze pod uwagę przy ocenie strony wskaźniki Core Web Vitals: LCP (jak szybko pojawia się główna treść), INP (jak szybko strona reaguje na kliknięcie) i CLS (czy układ przeskakuje podczas ładowania). W takiej architekturze znacznie łatwiej utrzymać je w zielonym zakresie. Jeśli obecna strona ma z nimi problem, zacznij od audytu wydajności. Często okazuje się, że część kłopotów da się rozwiązać bez zmiany architektury, a część tylko przez nią. Co da się poprawić w zwykłym WordPressie, pokazujemy na przykładzie przyspieszania sklepu WooCommerce.

Bezpieczeństwo

Większość włamań na WordPressa idzie przez publicznie dostępny panel logowania i dziurawe wtyczki. W headless wp-admin można schować za VPN-em, ograniczyć do konkretnych adresów IP albo wystawić pod osobną domeną, o której nikt poza zespołem nie wie. Odwiedzający widzą tylko statyczny frontend. Nie ma w nim formularza logowania ani PHP, więc nie ma czego atakować.

Mniejsza zależność od wtyczek

W typowym WordPressie wtyczki odpowiadają za suwaki, formularze, cache, optymalizację obrazów, SEO i galerie, a każda z nich dokłada własny kod do każdej strony i każda może przestać działać po aktualizacji. W headless większość tych funkcji przechodzi do frontendu. Tam są napisane raz, pod konkretną stronę. WordPressowi zostaje kilka wtyczek (ACF, WPGraphQL, ewentualnie SEO), które rzadko ze sobą kolidują.

Jeden backend dla strony i aplikacji mobilnej

Skoro treść jest dostępna przez API, może z niej korzystać nie tylko strona. Aplikacja mobilna, kiosk w salonie, wersja językowa na innej domenie: wszystko czyta z tego samego źródła. Redaktor publikuje raz, a zmiana pojawia się wszędzie. Dla firm, które obok strony planują aplikację mobilną, to argument często ważniejszy niż szybkość. Backend to 30–50% budżetu aplikacji, więc gotowe API wyraźnie obniża jej koszt. Więcej liczb w tekście o tym, ile kosztuje aplikacja mobilna.

Skalowanie

Statyczne strony z CDN wytrzymują nagłe skoki ruchu (kampania, wzmianka w mediach, Black Friday) bez dokładania serwerów. WordPress obsługuje w tym czasie tylko redaktorów i API, więc wystarczy mu skromny hosting. W sklepie na WooCommerce z frontendem w Next.js ten podział działa tak: katalog produktów i strony kategorii ładują się błyskawicznie, a serwer liczy tylko koszyki i zamówienia.

Wady i koszty headless WordPress

Headless ma realne koszty i kilka pułapek, o których sprzedawcy tej architektury mówią niechętnie.

• Droższy start. Zamiast kupić motyw i skonfigurować wtyczki, trzeba zaprojektować i zaprogramować frontend od zera. Każdy typ podstrony, każda sekcja i każdy komponent to praca programisty. Kreatora nie ma.
• Dwa systemy do utrzymania. WordPress wymaga aktualizacji jak dotąd. Do tego dochodzi aplikacja w Next.js z własnymi zależnościami, własnym hostingiem i własnym cyklem wydań. Potrzebujesz zespołu albo firmy, która umie utrzymywać oba systemy.
• Część wtyczek nie działa po stronie frontu. Wtyczka, która „dodaje coś do strony” (popup, chat, suwak, formularz), działa w motywie WordPressa. W headless motywu nie ma, więc taką funkcję trzeba odtworzyć w Next.js. Marketing nie zainstaluje nowej wtyczki w piątek po południu. Zgłosi zadanie programiście.
• Formularze, SEO i podgląd trzeba zaprojektować. Wysyłka formularza kontaktowego, meta tagi, dane strukturalne, mapa strony, przekierowania, strony 404, podgląd wersji roboczych: w klasycznym WordPressie dostajesz to z wtyczkami. W headless każda z tych rzeczy jest decyzją projektową i punktem w wycenie. Nawet przy prostym formularzu trzeba ustalić, dokąd frontend wysyła dane.
• Nie każda firma tego potrzebuje. Strona wizytówka z dziesięcioma podstronami i blogiem aktualizowanym raz w miesiącu będzie szybka także na dobrze zrobionym klasycznym WordPressie. Headless rozwiązuje problemy, które dopiero trzeba mieć.

Kiedy headless, a kiedy klasyczny WordPress?

Headless broni się przy dużym ruchu, uporczywych problemach z Core Web Vitals, planowanej aplikacji mobilnej i wysokich wymaganiach bezpieczeństwa. Przy małej stronie i małym budżecie wygrywa klasyczny WordPress.

Jeśli w tabeli widzisz się w kolumnie „klasyczny”, nie szukaj headless na siłę. WordPress z lekkim motywem i dziesięcioma wtyczkami zamiast czterdziestu bywa równie skuteczny. I dużo tańszy.

Jak przenieść istniejącą stronę na headless?

Treści nie budujesz od nowa. Wpisy, strony, media i pola ACF zostają w tej samej bazie, a zmienia się wszystko, co leży między bazą a przeglądarką. Takie projekty prowadzimy w Mobitry w sześciu etapach.

1. Audyt i inwentaryzacja. Spisujemy wszystkie typy treści, pola niestandardowe, wtyczki i funkcje, które strona realizuje. Przy każdej wtyczce odpowiadamy na pytanie: zostaje w WordPressie, przenosimy ją do frontendu czy rezygnujemy. Na tym etapie wychodzą zapomniane formularze i strony z kampanii sprzed trzech lat.
2. Przygotowanie API. Instalujemy WPGraphQL lub konfigurujemy REST API, wystawiamy pola ACF, ustawiamy uwierzytelnianie dla podglądu i sygnały rewalidacji. WordPress nadal działa po staremu. Nic się nie wyłącza.
3. Budowa frontendu. Projektujemy i programujemy komponenty w Next.js na podstawie nowego lub odświeżonego projektu graficznego. Równolegle odtwarzamy formularze, wyszukiwarkę, mapę strony, dane strukturalne i meta tagi.
4. Adresy URL i przekierowania. Od tego punktu zależy, czy migracja zaszkodzi pozycjom w Google. Najbezpieczniej zachować dotychczasową strukturę adresów jeden do jednego, a tam, gdzie adres się zmienia, przygotowujemy mapę przekierowań 301 ze starego na nowy, łącznie z adresami obrazów i plików PDF, o których łatwo zapomnieć.
5. Testy i przełączenie. Frontend działa na domenie testowej. Porównujemy go z obecną stroną podstrona po podstronie, sprawdzamy wydajność, formularze i podgląd. Samo przełączenie to zmiana DNS. Stary WordPress zostaje dostępny jeszcze przez pewien czas, na wypadek gdyby trzeba było wrócić.
6. Obserwacja po starcie. Przez kilka tygodni pilnujemy Google Search Console pod kątem błędów 404 i spadków pozycji.

Ile kosztuje headless WordPress w porównaniu z klasycznym?

Na starcie więcej. Konkretnych kwot nie podajemy, bo rozrzut jest zbyt duży, ale relacja jest dość stała: wdrożenie headless kosztuje więcej niż klasyczna strona o tym samym zakresie, bo frontend powstaje od zera, a nie z motywu. Im więcej unikalnych typów podstron i sekcji, tym większa różnica.

Na wycenę najmocniej wpływają liczba typów treści i komponentów do zaprogramowania, liczba integracji (CRM, newsletter, system rezerwacji, ERP), wielojęzyczność, zakres migracji istniejących treści oraz to, czy projekt graficzny powstaje od nowa. Sklep na WooCommerce z frontendem w Next.js jest droższy od zwykłej strony, bo koszyk, konto klienta i płatności wymagają integracji z API sklepu. Sam odczyt treści nie wystarczy.

Utrzymanie też kosztuje więcej: dwa systemy, dwa hostingi i programista tam, gdzie wcześniej wystarczało kliknięcie w „aktualizuj”. Odpada za to część kosztów, które w klasycznym WordPressie są ukryte, czyli drogi hosting z dużym cache, płatne wtyczki do wydajności i bezpieczeństwa oraz godziny spędzone na gaszeniu konfliktów po aktualizacjach.

Headless zwraca się wtedy, gdy strona faktycznie zarabia albo generuje leady, a każda sekunda ładowania i każdy spadek w Google mają mierzalną cenę. Dla wizytówki bez takiego wpływu na biznes różnica w kosztach rzadko się broni. Nie wiesz, po której stronie jesteś? Od tego pytania powinna zacząć się rozmowa o nowej stronie internetowej. Technologię wybiera się później.

Najczęstsze pytania

Czy headless WordPress jest dobry dla SEO?

Tak, pod warunkiem że frontend jest zrobiony poprawnie. Next.js generuje pełny HTML po stronie serwera lub podczas budowania, więc Google widzi treść tak samo jak w klasycznym WordPressie, a do tego dostaje szybszą stronę z lepszymi Core Web Vitals. Ryzyko leży w migracji. Zmiana adresów URL bez przekierowań, brak meta tagów, mapy strony czy danych strukturalnych potrafią zaszkodzić pozycjom, dlatego te elementy muszą być w zakresie projektu od początku.

Czy mogę dalej używać Gutenberga i ACF?

Tak. Panel WordPressa, edytor blokowy i pola ACF działają jak dotąd, bo zmienia się tylko sposób wyświetlania treści. Bloki Gutenberga trafiają do frontendu jako HTML albo jako struktura danych, którą Next.js renderuje własnymi komponentami. Wyjątkiem są bloki z wtyczek, które generują własny kod po stronie motywu. Te trzeba odtworzyć we frontendzie.

Czy WooCommerce działa w modelu headless?

Tak, działa. Katalog produktów, kategorie i strony produktów są pobierane przez API i generowane w Next.js, dzięki czemu ładują się bardzo szybko. Koszyk, konto klienta, płatności i zamówienia obsługuje WooCommerce przez swoje API, a frontend komunikuje się z nim w tle. To więcej pracy niż przy zwykłej stronie, bo trzeba zintegrować cały proces zakupowy. Przy dużym ruchu albo rozbudowanym katalogu różnica w szybkości jest jednak odczuwalna.

Ile trwa migracja istniejącej strony na headless?

Od kilku tygodni do kilku miesięcy. Prosta strona firmowa z blogiem to zwykle kilka tygodni, rozbudowany serwis albo sklep to kilka miesięcy. Decyduje liczba typów treści i integracji oraz to, czy projekt graficzny powstaje od nowa. Treść nie wymaga przenoszenia, bo zostaje w tym samym WordPressie. Najwięcej czasu zajmuje budowa frontendu, odtworzenie funkcji wtyczek i testy przed przełączeniem.

Źródła

• REST API Handbook, WordPress Developer Resources
• WPGraphQL, dokumentacja wtyczki
• Incremental Static Regeneration (ISR), dokumentacja Next.js