Headless CMS to system zarządzania treścią, który nie ma własnej warstwy prezentacji. Przechowuje treść i udostępnia ją przez API (REST albo GraphQL), a o tym, jak ta treść wygląda na stronie czy w aplikacji, decyduje osobny frontend, np. w Next.js, Astro albo Nuxt.
Headless CMS w skrócie
- „Headless” (bezgłowy) – CMS bez „głowy”, czyli bez szablonów i motywów. Zostaje panel do edycji treści i API.
- Przykłady: Strapi i Payload (open source, do własnego hostingu), Sanity, Contentful i Storyblok (usługi w chmurze), a także WordPress używany przez REST API lub WPGraphQL.
- Zalety: dowolny frontend, jedna treść dla strony, aplikacji i innych kanałów, mniejsza powierzchnia ataku.
- Wady: wyższy koszt wdrożenia i utrzymania, potrzeba programistów, SEO trzeba zaprojektować (SSR/SSG).
- Dla kogo: większe serwisy, wiele kanałów, zespół frontendowy. Do prostej wizytówki zwykle się nie opłaca.
Na początku dodam, że headless CMS dla wielu może być kolejnym buzzwordem – czymś, czego się używa, bo inni używają. W tym tekście chcę odpowiedzieć na pytania, które pojawiają się przy wyborze tej czy innej technologii.
Headless CMS – co to jest?
Od strony redaktora różnica jest niewielka. Po zalogowaniu do panelu są pola do edycji treści, media, role użytkowników. Odwiedzający stronę też nie zobaczy nic szczególnego – strona wygląda i działa tak, jak w „tradycyjnym” rozwiązaniu. Różnica jest w tym, co dzieje się pod spodem.
Tradycyjny CMS
W tradycyjnym CMS-ie zarządzanie treścią i jej wyświetlanie to jedna aplikacja. Gdy użytkownik wchodzi na stronę, serwer uruchamia skrypt (np. PHP), łączy się z bazą danych, pobiera treść, wkłada ją do szablonu i zwraca gotowy HTML. Tak działa WordPress z motywem – w tym ten blog. Na zdjęciu tytułowym widać zresztą kawałek WordPressa, w którym kod HTML jest wymieszany z PHP.
Szablony, wtyczki i treść są tu mocno ze sobą powiązane. Zmiana technologii po stronie serwera albo przebudowa wyglądu oznacza zwykle pracę po obu stronach naraz.
Headless CMS
W headless CMS-ie ten podział jest sztywny: CMS przechowuje treść i wystawia API, a frontend to osobna aplikacja, która z tego API korzysta. Nazwa wzięła się właśnie stąd – „głową” jest warstwa prezentacji, a tej CMS nie ma.
Frontend może pobierać dane w różnych momentach:
- przy budowaniu strony (SSG) – generator pobiera treść po API i tworzy gotowe pliki HTML, które leżą na serwerze lub CDN,
- na serwerze przy każdym żądaniu (SSR) – serwer frontendu pobiera dane i zwraca gotowy HTML,
- w przeglądarce (CSR) – przeglądarka dostaje „pusty” szkielet, a JavaScript dociąga treść po API.
To ostatnie rozwiązanie jest najprostsze, ale – jak za chwilę zobaczysz – najgorsze dla SEO.
Przykłady headless CMS
Rynek jest duży, ale kilka nazw przewija się najczęściej. Warto zwrócić uwagę przede wszystkim na model: czy to oprogramowanie open source, które hostujesz sam, czy usługa w chmurze (SaaS).
| CMS | Model | Co warto wiedzieć |
|---|---|---|
| Strapi | open source (MIT, edycja Community) + Strapi Cloud | Node.js, API REST i GraphQL, własny panel admina. Funkcje Enterprise na osobnej licencji. |
| Payload | open source (MIT) | TypeScript, instaluje się bezpośrednio w katalogu /app projektu Next.js. |
| Sanity | Studio open source (MIT), treść w chmurze | Treść leży w hostowanym Content Lake, zapytania w języku GROQ albo GraphQL. |
| Contentful | SaaS (zamknięty) | Jedna z pierwszych platform tego typu (Berlin, 2013), popularna w dużych firmach. |
| Storyblok | SaaS | Edytor wizualny z podglądem strony na żywo – ukłon w stronę redaktorów. |
| WordPress | open source (GPL) | Od wersji 4.7 (2016) ma w rdzeniu REST API, a wtyczka WPGraphQL dodaje GraphQL. |
WordPress jako headless CMS
WordPress nie musi być „głową”. Od wersji 4.7 wyposażone jest w REST API z endpointami dla wpisów, komentarzy, kategorii, użytkowników i ustawień, więc panel może służyć wyłącznie do redagowania treści, a stronę renderuje np. Next.js. Kto woli GraphQL, ma darmową wtyczkę WPGraphQL.
W praktyce oznacza to, że te dwa serwery (usługi) mogą istnieć w różnych miejscach. W zależności od infrastrukry projektu może to być bardziej lub mniej złożone. Panel CMS-a może być schowany w wewnętrznej sieci a tylko fronaend wystawiony na świat.
To dobra droga, gdy redakcja zna już WordPressa, a zespół chce nowoczesnego frontendu. Trzeba jednak pamiętać, że część wtyczek (np. tych, które dokładają coś do motywu albo generują meta tagi SEO w <head>) w takim układzie nie zadziała sama – frontend musi te dane pobrać i wyrenderować.
Architektura: API + frontend
W typowym wdrożeniu headless CMS są trzy elementy:
- CMS – panel dla redaktorów i API (REST lub GraphQL),
- frontend – aplikacja w Next.js (React), Nuxt (Vue), Astro albo innym frameworku, która pobiera treść i składa z niej strony,
- hosting/CDN – osobno dla CMS-a i osobno dla frontendu.
Do tego dochodzi mechanizm odświeżania. Gdy redaktor opublikuje zmianę, CMS wysyła webhook, a frontend przebudowuje stronę albo unieważnia jej cache. Next.js robi to np. przez ISR (Incremental Static Regeneration): strona jest statyczna, ale może zostać wygenerowana ponownie po określonym czasie albo na żądanie (revalidatePath, revalidateTag). Astro w dokumentacji ma gotowe poradniki integracji ze Strapi, Contentful, Sanity, Storyblok, WordPressem czy Payloadem.
Jeśli frontend ma działać na serwerze (SSR), potrzebujesz hostingu dla Node.js – o tym, na co zwrócić uwagę, pisałem w tekście jaki hosting dla Node.js.
Zalety headless CMS
- Swoboda we frontendzie. Część wizualna może powstać w czystym JavaScripcie, Reakcie, Vue, Svelte czy Astro – CMS niczego nie narzuca.
- Swoboda na backendzie. Frontend rozmawia z API, więc CMS można wymienić (np. z PHP na Node.js) bez przepisywania wyglądu, o ile kontrakt API zostanie ten sam.
- Niezależne zespoły. Frontend i backend mogą być rozwijane i wdrażane osobno.
- Jedna treść, wiele kanałów. To samo API zasili stronę, aplikację mobilną, ekran w sklepie czy newsletter.
- Wydajność. Strony wygenerowane statycznie i serwowane z CDN ładują się bardzo szybko. Sam headless tego nie gwarantuje – to zasługa SSG/SSR i cache, a o resztę (obrazy, loading=”lazy”, JavaScript) trzeba zadbać jak wszędzie.
- Bezpieczeństwo. Panel admina i baza mogą być na innym serwerze niż publiczna strona, a strona statyczna nie wykonuje kodu po stronie serwera. Mniejsza powierzchnia ataku nie zwalnia jednak z zabezpieczenia API.
Wady headless CMS
Nie ma idealnych rozwiązań. Tak i tutaj znajdą się wady.
- Koszty. Zamiast jednej aplikacji masz dwie (albo więcej): CMS i frontend, każde z własnym hostingiem, aktualizacjami i monitoringiem. To nie jest postawienie strony na WordPressie kilkoma kliknięciami.
- Potrzebni są programiści. Podgląd przed publikacją, formularze, wyszukiwarka, mapa witryny, przekierowania – w tradycyjnym CMS-ie załatwia je wtyczka, tu często trzeba je napisać. Co więcej – często tworzony jest cały proces, od pomysłu, implementacji, testów i wdrożenia. Czasami może to znacząco wydłużać zmiany.
- Redaktor traci część wygody. Bez dobrze skonfigurowanego podglądu edytuje „pola”, a nie stronę. Częściowo rozwiązują to edytory wizualne WYSIWYG (np. w Storyblok).
- Widoczność w wyszukiwarkach (SEO). Wiele firm o tym zapomina. A wiem, co piszę, bo robię audyty SEO i pomagam takim serwisom być bardziej widocznymi w Google. Jeżeli headless zostanie źle zaprojektowany pod wyszukiwarki, naprawa będzie kosztowna i długotrwała.
SEO w headless CMS: SSR i SSG
Google przetwarza strony z JavaScriptem w trzech etapach: pobranie, renderowanie (w kolejce, w przeglądarce Chromium) i indeksowanie. Potrafi więc wykonać JavaScript, ale sam zaznacza, że renderowanie po stronie serwera albo wstępne renderowanie to wciąż dobry pomysł – strona jest szybsza dla ludzi i robotów, a nie wszystkie roboty uruchamiają JavaScript.
W praktyce przy headless CMS:
- wybierz SSG lub SSR (np. Next.js, Nuxt, Astro), a nie czysty CSR – treść, tytuł, meta description i dane strukturalne mają być w HTML-u od razu,
- nie licz na dynamic rendering (osobna wersja dla robotów) – Google opisuje go jako obejście, a nie rozwiązanie długoterminowe, i zaleca SSR, renderowanie statyczne lub hydrację,
- przenieś to, co dawała wtyczka SEO – mapę witryny, canonicale, przekierowania 301,
noindex, linki wewnętrzne.
Więcej o tym, jak wyszukiwarki radzą sobie z aplikacjami w JS, piszę w tekście o JavaScript SEO.
Wdrożenie headless CMS – rola programistów
Wdrożenie headless CMS to w praktyce projekt programistyczny, nie instalacja gotowca. Zwykle wygląda tak:
- Model treści – jakie typy treści (wpis, produkt, autor) i pola są potrzebne. To robi się razem z redakcją. Powstaje wtedy tzw. kontrakt pomiędzy backendem a frontendem.
- Wybór CMS-a – open source na własnym serwerze (Strapi, Payload, WordPress), SaaS (Sanity, Contentful, Storyblok), z uwzględnieniem kosztów i limitów planów a może coś własnego pisane pod siebie.
- Frontend – framework, strategia renderowania (SSG/SSR/ISR), podgląd dla redaktorów.
- Integracje – webhooki do przebudowy, wyszukiwarka, formularze, analityka.
- SEO i migracja – mapa witryny, przekierowania ze starych adresów, dane strukturalne.
Programiści są tu potrzebni nie tylko na start, ale też do utrzymania: aktualizacji dwóch aplikacji, zmian w modelu treści i nowych funkcji, które w klasycznym CMS-ie dałaby wtyczka.
Headless czy tradycyjny CMS – kiedy co wybrać?
Jeżeli chcesz mieć prostą stronę, np. wizytówkę firmy, bloga czy niewielki sklep, headless CMS raczej nie jest dla ciebie. To będzie przerost formy nad treścią i dodatkowe koszty. Tradycyjny CMS z dobrym motywem zrobi to taniej.
Headless warto rozważyć, gdy:
- ta sama treść ma trafiać do strony i aplikacji mobilnej (lub innych kanałów),
- masz zespół frontendowy, który chce pracować w nowoczesnym frameworku,
- tworzysz zaawansowaną aplikację webową i chcesz mieć pełną kontrolę nad wydajnością,
- masz kilka serwisów zasilanych z jednego źródła treści.
