Headless WordPress + Next.js w 2026 jest legalnym stackiem, nie magią. Jest też najdroższym sposobem na stronę-wizytówkę, jaki regularnie widzę w briefach. Poniżej nie ma „headless is the future”. Jest decyzja: klasyczny WP albo WP jako CMS i Next jako front — kiedy to ma sens, ile kosztuje i gdzie się wywraca.

Szerszy kontekst architektury (commerce, inne CMS-y): technologia headless w 2026.

Dwa modele

Klasyczny WordPress — PHP renderuje HTML. Motyw, wtyczki, cache (plugin + CDN), wp-admin i front to jeden system. Preview, formularze, wyszukiwarka, WooCommerce działają, bo siedzą w tym samym requestcie.

Headless — WP zostaje panelem i API (REST albo WPGraphQL). Next.js (App Router) robi HTML: SSG/ISR/SSR, cache tagów, revalidate. Publiczny origin to Node/Vercel, nie Apache z motywem. wp-admin chowasz za VPN — to plus bezpieczeństwa, nie darmowy lunch.

REST vs GraphQL

REST jest w core, zero pluginów, bolesny overfetch, paginacja i ACF jako mega-JSON. WPGraphQL (plugin) daje precyzyjne query, schema, ale to zależność, którą aktualizujesz razem z core — po WordPress 7.1 sprawdzasz kompatybilność GraphQL tak samo jak motywu.

Na małych stronach REST + cienki mapper wystarczy. Na wielu typach treści, relacjach i i18n GraphQL zwykle wygrywa. Nie mieszaj obu „na wszelki wypadek”.

SSR, SSG, ISR, cache

Decyzja o renderze jest decyzją o biznesie:

SSG — cennik, landing, case study. Build przy publish.
ISR / revalidateTag — blog, listing. Webhook z WP po zapisie. W Next 16.3 ISR przy Cache Components umie pokazać shell pierwszemu hitowi — Instant Navigations.
SSR — sesja, geo, preview token. Płacisz TTFB.

Cache bez invalidacji to stary wpis na CDN. Invalidacja bez cache to origin w kolanach. Taguj po slugu i po taksonomii, nie „revalidate wszystko co 60s”.

// app/api/revalidate/route.ts
import { revalidateTag } from "next/cache";
import { NextRequest } from "next/server";

export async function POST(req: NextRequest) {
  const secret = req.headers.get("x-webhook-secret");
  if (secret !== process.env.WP_REVALIDATE_SECRET) {
    return new Response("no", { status: 401 });
  }
  const slug = (await req.json()).slug as string;
  revalidateTag("wp:" + slug);
  return Response.json({ revalidated: true });
}

Secret tylko po stronie serwera. WP woła webhook po save_post. Bez podpisu to publiczny flush cache.

SEO i Core Web Vitals

Headless nie psuje SEO, jeśli HTML wychodzi z serwera. Psuje, gdy treść jest tylko w kliencie. Zysk: kontrola metadata, hreflang, JSON-LD, mniej pluginowego CSS. Koszt: sam implementujesz to, co Yoast robił kliknięciem — canonical, og:image z ACF, sitemap z WP + front.

CWV: Next + CDN zwykle bije motyw z 40 wtyczkami. Nie bije dobrze zrobionego WP z lekkim motywem i hostem z pełnym page cache. Mierz, nie wierz slajdom. O WP i vitals: dlaczego 80% stron WP ma problem z CWV.

Deployment: Vercel vs VPS

Vercel jest naturalnym targetem App Routera (preview per PR, ISR, edge). VPS (Docker + Nginx) gdy masz compliance, stały koszt albo już klastrowany WP. Wtedy dwa originy: API (WP) i front (Next) — patrz wdrożenie Next na VPS.

Preview treści: draft w WP + tokenizowany route w Next. Bez tego redakcja wraca do „opublikuj i się pomódl”.

Formularze, search, WooCommerce

Formularze — Contact Form 7 na headless umiera. Endpoint w Next + walidacja + honeypot/Turnstile, albo WP REST z nonce, którego nie wystawiasz publicznie bez limitu.

Wyszukiwarka — WP search na SQL nie skaluje się ładnie przez API. Algolia / Meilisearch / OpenSearch, indeks z webhooka. To osobny system do utrzymania.

WooCommerce — tu headless boli najbardziej: koszyk, podatki, płatności, stany magazynowe, maile. Store API istnieje; pełny custom checkout to projekt, nie „przerobimy motyw”. Często checkout zostaje na WP albo u bramki (jak w headless commerce). Jeśli sklep jest sercem biznesu, klasyczny Woo + mocny hosting bywa tańszy niż dwa lata pisania koszyka.

Bezpieczeństwo

Publiczny Next nie wykonuje PHP pluginów — mniejsza powierzchnia. wp-admin za VPN/SSO to realny zysk (ten sam wzorzec co w VPN dla firm zdalnych). Zostaje: API enumeration, brute na application passwords, wyciek GraphQL introspekcji, webhooks bez podpisu. Hardening WP nadal obowiązuje: checklista.

Koszty developmentu i utrzymania

Klasyczny WP: motyw/child, kilka płatnych wtyczek, hosting, retainer na aktualizacje. Headless: front (Next), mapowanie ACF→typy, preview, cache, CI, monitoring, ktoś kto umie oba stacki. Pierwszy rok często 2–3× droższy. Utrzymanie: dwa changelogi (WP + Next), dwa backupy, dwa on-calle.

Orientacyjnie o utrzymaniu monolitu: ile kosztuje WordPress w 2026. Headless nie kasuje tej linii — dodaje drugą.

Scenariusz | WordPress | Headless WordPress

Scenariusz	Klasyczny WordPress	Headless WP + Next.js
Wizytówka, blog, 1 język, redakcja niemagiczna	Tak — default	Overkill
Wiele kanałów (web + app) z jednym CMSem	Słabo	Tak
Design system + animacje + App Router	Walka z motywem	Naturalne
WooCommerce z checkoutem out of the box	Tak	Ryzykowne / drogie
Core Web Vitals pod ads/SEO	Da się, wymaga dyscypliny	Łatwiej, jeśli SSR/SSG jest zrobione
Preview dla redakcji	Wbudowane	Do zbudowania
Zespół: jeden WP-developer	Pasuje	Nie pasuje
Zespół: frontend + backend, budżet na 12+ miesięcy	Można, ale stack będzie ciasny	Pasuje

Kiedy sam wybrałbym klasycznego WordPressa, a kiedy headless?

Klasyczny WP — strona firmy, blog, landing kampanii, mały katalog, zespół, który żyje w wp-admin, budżet na wdrożenie a nie na platformę. Przykłady z realizacji, gdzie motyw i PHP są racjonalne, widać przy typowych witrynach firmowych w portfolio.

Headless — produkt, który i tak jest aplikacją (dashboard, AI, własne auth), a marketing chce WP; albo front ma być Next z i18n i ISR, a redakcja nie odda Gutenberga. Wtedy WP jest CMS-em, nie „stroną”. Tak podchodzę, gdy stack i tak jest Next — np. kierunek jak przy Księgowy AI (aplikacja), a treści marketingowe mają osobny pipeline.

Nie wybieram headless, bo „tak robi się w 2026”. Wybieram, gdy koszt dwóch systemów jest mniejszy niż koszt walki z motywem albo gdy potrzebuję wielu frontów.

FAQ

Czy headless jest bezpieczniejszy?

Mniejszy publiczny PHP — tak. Zero ryzyka — nie. Źle wystawiony GraphQL i niezałatany core (patrz lato 2026) nadal kładą CMS.

Czy mogę zostać przy motywie i „dorzucić Next”?

To dwa fronty do utrzymania. Albo migrujesz, albo nie. Hybryda na chwilę staje się na lata.

A Payload / Sanity zamiast WP?

Jeśli zespół nie jest przywiązany do wp-admin, często tańsze niż headless WP. Headless WP ma sens, gdy panel WP jest wymaganiem.

Podsumowanie

Headless WordPress + Next.js ma sens przy wielu kanałach, twardym froncie i zespole, który utrzyma dwa changelogi. Klasyczny WP ma sens częściej, niż wynika z Twittera. Architektura nie jest lepsza — jest dopasowana albo nie. Jeśli wahasz się przy wyborze CMS dla firmy, zacznij od WordPress dla firmy w 2026, nie od repo z starterem GraphQL.