Next.js i WordPress: Twoja strona w nowym wymiarze

Headless WordPress to architektura, w której WordPress przestaje renderować stronę, a zaczyna pełnić wyłącznie rolę panelu do zarządzania treścią. Frontend (to, co widzi użytkownik) buduje osobna aplikacja Next.js, która pobiera dane z WordPressa przez API i sama generuje HTML. Głowa (frontend) zostaje odłączona od ciała (CMS) i stąd nazwa headless.

W praktyce działa to tak: redaktor loguje się do panelu WordPress i pisze artykuł jak zwykle. Next.js w momencie budowania strony (lub na żądanie) wysyła zapytanie do WordPressa, dostaje tytuł, treść, obrazy i metadane, po czym składa z tego gotową stronę. WordPress zwykle stoi pod osobnym adresem (np. cms.twojadomena.pl), a publiczny frontend pod główną domeną.

Komunikacja idzie jedną z dwóch dróg: wbudowanym REST API WordPressa lub przez WPGraphQL. Różnica jest spora i wracamy do niej niżej, bo to ona w dużej mierze decyduje o wydajności i wygodzie utrzymania. Całość najczęściej hostuje się rozdzielnie: WordPress na klasycznym hostingu PHP, a frontend Next.js na platformie typu Vercel albo własnym serwerze Node.js.

Kluczowa zmiana mentalna jest taka, że motyw WordPress (themes) przestaje cokolwiek znaczyć dla wyglądu strony. Cały wygląd, układ i interakcje przenoszą się do kodu React w projekcie Next.js. WordPress staje się dla frontendu po prostu bazą treści z API, niczym więcej.

Do pobierania danych z headless WordPressa masz dwie opcje, a wybór wpływa na to, ile zapytań poleci i jak dużo danych prześlesz po sieci. REST API działa od ręki, bez instalowania niczego: każdy WordPress wystawia endpointy pod /wp-json/wp/v2/. WPGraphQL to wtyczka, która dodaje jeden endpoint /graphql i pozwala w jednym zapytaniu poprosić dokładnie o te pola, których potrzebujesz.

Największy problem REST API to nadmiarowość i wiele zapytań. Żeby zbudować wpis z autorem, kategoriami i obrazem wyróżniającym, często trzeba odpytać kilka endpointów, a każdy zwraca pełny obiekt z polami, które wyrzucasz. WPGraphQL rozwiązuje to jednym zapytaniem o ściśle wybrane pola, co przy listach wpisów i menu potrafi mocno odciążyć transfer.

Dla pól niestandardowych (ACF) dochodzi wtyczka WPGraphQL for ACF, która wystawia te pola w schemacie GraphQL. Z czystym REST trzeba do tego dołożyć rejestrację pól w REST albo wtyczkę pośredniczącą. Do testowania zapytań GraphQL służy GraphiQL IDE, wbudowane w WPGraphQL narzędzie, w którym sprawdzisz, jakie dane zwróci konkretne zapytanie, zanim wpiszesz je do kodu Next.js.

W samym Next.js dane pobiera się funkcją fetch albo lekkim klientem GraphQL, najczęściej w komponentach serwerowych lub na etapie budowania strony. Adres endpointu trzyma się w zmiennej środowiskowej w pliku .env (np. WP_API_URL), żeby nie zaszywać go na sztywno w kodzie. Poniżej skrócone porównanie obu podejść.

Wniosek z naszej praktyki: dla pojedynczego bloga REST w zupełności wystarcza, ale gdy strona ma złożone typy treści, wiele pól ACF i rozbudowane listingi, WPGraphQL oszczędza realnie godziny pracy i obciążenia. To nie jest wybór ideologiczny, tylko kwestia skali projektu. Jeśli dopiero zaczynasz i masz prostą stronę, zacznij od REST i przejdź na GraphQL dopiero, gdy poczujesz jego brak.

Headless ma sens, gdy frontend musi być szybki, niestandardowy lub wspólny dla kilku kanałów. Klasyczne przykłady to: aplikacja, która czyta treść z WordPressa i jednocześnie z innego systemu, mocno interaktywny interfejs (kalkulatory, konfiguratory), albo zespół frontendowy, który chce pracować w React zamiast w PHP i szablonach motywu.

Dla większości firmowych stron i blogów headless to jednak przerost formy. Tracisz natychmiastowy podgląd zmian, edytor blokowy Gutenberg przestaje odzwierciedlać to, co zobaczy użytkownik, a wtyczki renderujące frontend (formularze, slidery, popupy) po prostu nie działają, bo ich kod nie trafia do Next.js. Każda taka funkcja wymaga zbudowania od nowa po stronie Reacta.

Dochodzi do tego praca redaktora. W klasycznym WordPress osoba pisząca tekst widzi efekt od razu w podglądzie. W headless podgląd trzeba osobno oprogramować, a do czasu wdrożenia tej funkcji redaktor pracuje w ciemno, co przy częstych zmianach treści potrafi być realną uciążliwością.

Najczęstszy błąd, jaki widzimy: ktoś wybiera headless dla samej wydajności, a tradycyjny WordPress z dobrym hostingiem, cache i optymalizacją obrazów osiąga bardzo dobre wyniki przy ułamku kosztu i złożoności. Headless opłaca się wtedy, gdy realnie potrzebujesz tego, co daje React, a nie gdy gonisz za wynikiem w jednym teście szybkości.

Prosta heurystyka, której używamy: jeśli potrafisz wymienić konkretną funkcję, której klasyczny WordPress nie udźwignie, headless ma sens. Jeśli jedynym argumentem jest abstrakcyjna nowoczesność albo szybkość bez liczb, to znak, że lepiej zostać przy sprawdzonym, tańszym rozwiązaniu i zainwestować różnicę w treść oraz hosting.

Pod kątem wydajności Next.js daje dwa mocne tryby, których standardowy WordPress nie ma natywnie: statyczną generację stron (SSG) i renderowanie po stronie serwera (SSR). SSG buduje gotowy HTML raz, podczas deploymentu, dzięki czemu strony ładują się błyskawicznie i nie obciążają WordPressa przy każdym wejściu. SSR generuje HTML na żądanie, gdy treść musi być świeża.

Dla SEO kluczowe jest, że Google dostaje gotowy HTML, a nie pusty szkielet doładowywany skryptem. Next.js to zapewnia, więc roboty indeksują treść bez problemu. Sam framework nie zastąpi jednak warstwy SEO WordPressa: meta tytuły, opisy i mapę witryny trzeba przenieść. Z reguły robi się to przez wtyczkę (np. Yoast SEO lub Rank Math z mostkiem do GraphQL), z której Next.js pobiera dane SEO razem z treścią.

Uwaga praktyczna: w headless łatwo zgubić rzeczy, które w klasycznym WordPress działają same. Przekierowania 301, kanoniczne adresy, dane strukturalne schema.org czy mapa witryny muszą zostać świadomie odtworzone w Next.js. Pominięcie ich to najczęstsza przyczyna spadków widoczności po migracji na headless.

Drugi cichy zabójca SEO to obrazy. WordPress sam generuje miniatury i podaje obrazy responsywnie, w headless ten mechanizm trzeba odtworzyć, najlepiej komponentem next/image. Jeśli tego zaniedbasz, Core Web Vitals (szczególnie LCP) potrafią być gorsze niż w dobrze skonfigurowanym klasycznym WordPress, mimo całej teoretycznej przewagi frameworka.

Headless jest droższy w utrzymaniu niż klasyczny WordPress i to trzeba założyć na starcie. Dopłacasz nie tyle za sam hosting, co za złożoność: dwie aplikacje do aktualizacji, dwa środowiska do monitorowania i konieczność utrzymania programisty znającego React. Poniżej orientacyjne widełki rynkowe (są to przybliżenia, nie oferta), żebyś miał punkt odniesienia.

Dochodzi mniej oczywisty koszt: każda zmiana wyglądu, która w klasycznym WordPress jest kliknięciem w panelu lub zmianą w motywie, w headless wymaga programisty i nowego deploymentu. Wdrożenie nowej sekcji na stronie głównej to zadanie deweloperskie, a nie edycja w Gutenbergu, co przekłada się na wyższe koszty bieżącej obsługi.

Wniosek: jeśli budżet jest ograniczony, a strona to wizytówka lub blog, klasyczny WordPress wygra na koszcie i czasie wdrożenia. Headless zwraca się wtedy, gdy szybkość i niestandardowy interfejs realnie przekładają się na konwersje albo gdy i tak utrzymujesz zespół frontendowy.

W naszych wdrożeniach najczęściej widzimy, że klienci pytają o headless WordPress po przeczytaniu, że jest szybszy, a nie dlatego, że potrzebują czegokolwiek, czego nie da klasyczny WordPress. Po rozmowie o kosztach utrzymania (dwa środowiska, developer React na stały etat lub kontrakt, brak gotowych wtyczek frontendowych) większość wybiera dobrze zoptymalizowany klasyczny WordPress i jest zadowolona z efektu.

Headless polecamy tam, gdzie ma realne uzasadnienie: frontend współdzielony przez kilka kanałów albo mocno interaktywny interfejs, którego nie złożysz sensownie z wtyczek. W pozostałych przypadkach traktujemy go uczciwie jako rozwiązanie, które częściej dodaje problemów niż ich ubywa, i mówimy o tym klientowi wprost, zanim zapłaci za złożoność, której nie wykorzysta.

Headless trafia najlepiej do firm, które traktują stronę jak produkt, a nie wizytówkę. To zespoły z własnym programistą lub agencją techniczną, marki potrzebujące bardzo szybkiego i unikalnego frontendu oraz projekty, gdzie ta sama treść zasila kilka miejsc (strona, aplikacja mobilna, ekrany w salonie). W takich warunkach kontrola nad kodem, którą daje Next.js, przekłada się na realną wartość.

Dla małych firm, gabinetów, lokalnych usługodawców i typowych blogów rekomendacja jest odwrotna: zostań przy klasycznym WordPress. Dostaniesz natychmiastowy podgląd, działające wtyczki, niższy koszt i prostsze utrzymanie, a różnice w szybkości nadrobi dobry hosting i cache. Profesjonalnie zaprojektowane i zoptymalizowane strony internetowe na klasycznym WordPress spokojnie konkurują w Google bez całej tej złożoności.

Decyzja sprowadza się do jednego pytania: czy potrzebujesz mocy Reacta i jesteś gotów płacić za jej utrzymanie. Jeśli tak, headless jest świetny. Jeśli nie, to droga, która doda kosztów i punktów awarii, nie dając w zamian tego, co dla Twojego biznesu naprawdę się liczy. Zanim zdecydujesz, policz całkowity koszt utrzymania w skali roku, a nie samą cenę wdrożenia, bo to właśnie obsługa, a nie start, decyduje o opłacalności.