Headless commerce — kiedy sklep headless ma sens, a kiedy wystarczy klasyczny

Headless commerce to sposób budowy sklepu internetowego, w którym warstwa widoczna dla klienta — strony produktów, koszyk, treści — działa osobno od silnika, który przechowuje katalog, ceny i zamówienia. Oba elementy komunikują się przez API. Taki podział daje swobodę w wyglądzie i działaniu sklepu, ale dokłada drugą warstwę, którą ktoś musi zbudować i utrzymywać.

Sami budujemy sklepy w tej architekturze, więc piszemy też o tym, kiedy ją klientom odradzamy. Zamiast historii klientów z procentowymi wzrostami dostajesz kryteria, które sprawdzisz na własnym sklepie. Ceny i dokumentację dostawców odczytaliśmy 30.09.2026.

Headless commerce — co to jest

Headless commerce oddziela front sklepu od silnika i łączy je przez API. Najkrótszą definicję podaje commercetools, jeden z dostawców platform tego typu: „Headless commerce is an architecture that separates the frontend experience layer from backend commerce functionality, exposing capabilities through APIs”. W tłumaczeniu: headless commerce to architektura, która oddziela warstwę doświadczenia klienta (front) od funkcji handlowych po stronie serwera (backend) i udostępnia te funkcje przez API.

„Head”, czyli „głowa”, to w tym obrazie front sklepu. Sklep headless nie ma jednej, wbudowanej głowy w postaci motywu — silnik udostępnia dane i operacje (pokaż produkt, dodaj do koszyka, złóż zamówienie), a front budujesz osobno. Tych frontów może być kilka: strona, aplikacja mobilna, kiosk w sklepie stacjonarnym.

Obok headless pada często skrót MACH. Manifest MACH Alliance rozwija go jako „microservices-based, API-first, cloud-native SaaS, and headless”, czyli architekturę opartą na mikroserwisach, projektowaną od API, działającą w chmurze w modelu SaaS i bezgłową. Headless to jedna z czterech liter, nie synonim całego MACH. Na nowszej stronie MACH explained organizacja opisuje swoje podejście trzema zasadami: Open, Composable i Connected, a o ostatniej pisze: „Connected architecture is API-first, real-time, and interoperable by design” — architektura połączona jest z założenia oparta na API, działa w czasie rzeczywistym i współpracuje z innymi systemami.

Drugie pojęcie to composable commerce: sklep składany z osobnych usług — na przykład katalog od jednego dostawcy, wyszukiwarka od drugiego, treści z trzeciego — połączonych przez API. Każdy sklep composable jest headless, ale nie każdy sklep headless jest composable: możesz mieć jeden silnik (np. Shopify) i tylko własny front.

Headless commerce to nie to samo co headless CMS. Headless CMS zarządza treściami strony (artykuły, podstrony) bez wbudowanego frontu — dotyczy treści, a nie koszyka i zamówień. W sklepie headless często pracują oba: silnik handlowy i osobny CMS dla treści marketingowych.

Klasyczny sklep a headless — co się zmienia

W klasycznym sklepie front i silnik to jeden system — w headless dzielisz go na dwa. Tak działają zarówno platformy SaaS (Shoper, Shopify, IdoSell), jak i open source z motywem (WooCommerce, PrestaShop). Wygląd zmieniasz motywem i jego ustawieniami, funkcje dodajesz aplikacjami lub wtyczkami, a wszystko działa na jednym serwerze lub u jednego dostawcy.

W sklepie headless są to dwie osobne części:

• Silnik (backend) — produkty, ceny, stany, koszyk, zamówienia, klienci, płatności. Może nim być platforma SaaS (np. Shopify), open source (np. Medusa, Shopware) albo system budowany na zamówienie.
• Front — osobna aplikacja, która pobiera dane z silnika przez API i wyświetla je klientowi. Budujesz ją od zera lub na frameworku (np. Hydrogen, Next.js).

API to w tym układzie umowa między częściami: silnik publikuje listę operacji i formatów danych, a front z nich korzysta. Jak to działa od środka — czym jest REST, webhook i dokumentacja OpenAPI — wyjaśniamy w tekście API — co to jest.

Kto utrzymuje co

Najważniejsza zmiana dotyczy odpowiedzialności. W klasycznym SaaS dużą część pracy wykonuje dostawca w ramach abonamentu. Polski cennik Shopify wymienia w planach „Nielimitowany hosting www” i „Darmowy certyfikat SSL”, Sky-Shop — „Ciągły rozwój i aktualizacje platformy”, a strona AtomStore deklaruje „Aktualizacje i hosting w cenie”. W open source z motywem ten zakres przechodzi na Ciebie lub wykonawcę: hosting, aktualizacje silnika i wtyczek, kopie zapasowe.

W headless dochodzi trzecia kolumna — front. Silnik utrzymujesz według jego modelu (dostawca SaaS albo Ty przy open source), a front — z jego kodem, hostingiem, aktualizacjami zależności i monitoringiem — jest zawsze po Twojej stronie albo po stronie wykonawcy. Do tego integracja: każda zmiana API silnika może wymagać zmiany we froncie.

Kod jest Twój, dane zostają w silniku

Kod frontu może należeć do Ciebie, ale produkty, klienci i zamówienia nadal są w silniku. Kod jest Twój, jeśli przewiduje to umowa z wykonawcą, a repozytorium leży na Twoim koncie. Warunki wyjścia z silnika są więc tak samo ważne jak przy klasycznym sklepie. Shopify w pomocy opisuje eksport klientów, zamówień i produktów do plików CSV (klienci, zamówienia, produkty). Przy silniku open source na własnym serwerze baza danych jest po prostu Twoja. Zanim wybierzesz silnik, sprawdź, co z niego wyeksportujesz — to ten sam test, który opisujemy w porównaniu platform e-commerce. Ogólne zasady oceny dostawcy chmurowego zebraliśmy w przewodniku po SaaS.

Kiedy headless commerce ma sens

Headless opłaca się wtedy, gdy ograniczenia jednego systemu kosztują Cię więcej niż utrzymanie dwóch. Nie jest „lepszą wersją” sklepu, tylko innym podziałem pracy. Najczęściej uzasadniają go cztery sytuacje.

Potrzebujesz frontu, którego motyw nie da. Nietypowy konfigurator produktu, własny proces zamówienia, strony produktowe mocno połączone z treściami poradnikowymi. W klasycznym sklepie każde takie wymaganie to obejście w motywie albo kolejna wtyczka. W headless front piszesz pod proces, a nie proces pod motyw.

Sprzedajesz w kilku kanałach. Jeden katalog ma zasilać stronę, aplikację mobilną i ekran w salonie albo kilka stron dla różnych rynków. W headless wszystkie fronty korzystają z tego samego API i tych samych danych.

Masz wymagania co do wydajności i kontroli. Chcesz decydować, co i jak się ładuje, gdzie działa front i jak cache'owane są strony, zamiast polegać na ustawieniach motywu i hostingu platformy. Headless daje tę kontrolę, ale szybkości nie gwarantuje — ta zależy od tego, jak zbudujesz front (więcej w sekcji o SEO).

Integracje są rdzeniem sprzedaży. Cenniki per kontrahent, stany z ERP, reguły z systemu magazynowego. Tu headless często idzie w parze z B2B — opisujemy to w tekście o platformach B2B.

Kiedy headless się nie opłaca

Masz mały katalog i standardowy proces zakupu. Jeśli motyw i aplikacje platformy pokrywają to, czego potrzebujesz, headless dokłada koszt bez nowej wartości. Piszemy to także na naszej stronie oferty: dla pierwszego sklepu z 50 produktami headless bywa przesadą i wtedy polecamy klasyczne rozwiązanie.

Nie masz zespołu ani budżetu na utrzymanie frontu. Front to aplikacja: aktualizacje bibliotek, poprawki bezpieczeństwa, monitoring, zmiany po aktualizacjach API silnika. Jeśli nikt nie będzie za to odpowiadał po starcie, każda zmiana w sklepie zamieni się w zlecenie dla developera.

Popyt nie jest jeszcze sprawdzony. Na etapie testowania oferty liczy się czas do pierwszego zamówienia. Jak wystartować szybko i tanio, opisujemy w poradniku jak założyć sklep internetowy.

Twój zespół chce samodzielnie zmieniać wygląd stron. W klasycznym sklepie marketing przestawia bloki w edytorze motywu. W headless to możliwe, ale trzeba to zaprojektować (np. przez CMS z blokami) — inaczej każda zmiana wymaga developera.

Jeśli nie wiesz, od którego modelu zacząć, porównanie platform e-commerce pokazuje różnice między SaaS, open source i headless na faktach z cenników, a quiz „Jaka platforma e-commerce?” zawęzi wybór w siedmiu pytaniach. Koszty klasycznych wariantów liczymy w tekście ile kosztuje sklep internetowy.

Narzędzia: Shopify Hydrogen, Medusa JS, Shopware, commercetools i Next.js

Podajemy stan z dokumentacji i cenników producentów z 30.09.2026. Ceny się zmieniają, więc przed decyzją sprawdź aktualny cennik.

Shopify headless: Hydrogen i Oxygen

Shopify pozwala zostawić swój silnik i zbudować własny front. Dokumentacja Hydrogen fundamentals opisuje dwa elementy:

• Hydrogen — „A set of components, utilities, and design patterns that make it easier to work with Shopify APIs”, czyli zestaw komponentów, narzędzi i wzorców, które ułatwiają pracę z API Shopify.
• Oxygen — „Shopify's global serverless hosting platform, built for deploying Hydrogen storefronts at the edge”, czyli globalny hosting bezserwerowy Shopify do uruchamiania frontów Hydrogen blisko użytkownika.

Dla budżetu najważniejsze jest zdanie z dokumentacji: „Oxygen is available at no extra charge on paid Shopify plans: Starter, Basic, Grow, Advanced, Plus, and Pause and build”. Hosting frontu masz więc w abonamencie Shopify. Planu Starter nie ma w polskim cenniku, więc dla sklepu w Polsce punktem wyjścia jest Basic — według cennika Shopify PL 79 zł miesięcznie przy płatności rocznej lub 109 zł przy miesięcznej (cennik nie podaje, czy kwoty zawierają VAT). Plus zaczyna się od 2 100 EUR miesięcznie przy rozliczeniu rocznym.

Shopify headless niesie mniejsze ryzyko niż budowa całości od zera: katalog, checkout, płatności i panel zostają u dostawcy, a Ty odpowiadasz za front. Ceną jest zależność od Shopify w warstwie silnika i jego opłat (o nich w sekcji o kosztach).

Medusa JS — silnik open source

Medusa to silnik sklepu, na którym budujesz własny backend. Dokumentacja opisuje go tak: „Medusa is an AI-native commerce platform with a Framework to build custom commerce features” — platforma handlowa z frameworkiem do budowy własnych funkcji sklepu. Front budujesz osobno, więc Medusa z natury pracuje w układzie headless.

Licencja: plik LICENSE w repozytorium mówi, że poza materiałami Enterprise Edition („Except for the Enterprise Edition materials identified in ENTERPRISE-LICENSE.md”) repozytorium jest na licencji MIT. Rdzeń możesz więc uruchomić na własnym serwerze bez opłat licencyjnych.

Jeśli nie chcesz utrzymywać serwera, jest Medusa Cloud: plan Develop od 29 USD miesięcznie, Launch od 99 USD, Scale od 299 USD i Enterprise z wyceną indywidualną. Cennik podaje „0.0%” opłaty od obrotu, ale nalicza dopłaty za przekroczenie limitów użycia. Starsze nazwy planów (Hobby, Pro), które krążą w artykułach, są nieaktualne.

Medusa daje najwięcej swobody w logice sklepu, ale wymaga zespołu, który zna ten framework. To sklep budowany przez programistów, a nie konfigurowany w panelu.

Shopware

Shopware to silnik open source z płatnymi planami zależnymi od obrotu. Cennik podaje: Community Edition „Free” na licencji MIT, plan Rise od 600 EUR miesięcznie, Evolve od 2 400 EUR miesięcznie (bez VAT) i Beyond z wyceną indywidualną. Ceny płatnych planów zależą według producenta od obrotu (GMV) i „further individual factors”. Jeśli rozważasz Shopware jako silnik dla osobnego frontu, sprawdź w dokumentacji producenta zakres API dla sklepu — w tym tekście nie opisujemy go szczegółowo.

commercetools

commercetools to dostawca platformy handlowej, od którego pochodzi przytoczona wyżej definicja headless commerce. Cennika commercetools nie weryfikowaliśmy, więc nie podajemy kwot.

Moduły headless w platformach SaaS

Niektóre polskie platformy SaaS oferują front headless jako dodatek. W cenniku AtomStore B2C w PDF, obowiązującym od 1.03.2026, moduł „Headless Front (PWA)” kosztuje 1 199 zł miesięcznie i jest dostępny tylko w planie MAX. Uwaga: strona cennika AtomStore pokazuje inną tabelę abonamentów niż PDF.

Front w Next.js

Front sklepu headless nie musi powstawać na narzędziu dostawcy silnika. My budujemy go w Next.js, a silnikiem może być Shopify, Stripe albo system budowany na zamówienie — tak opisujemy to na stronie oferty sklepu headless. Framework nie przesądza o szybkości ani o SEO; przesądza to, jak zbudujesz strony, cache i ładowanie danych.

Koszt i zespół sklepu headless

Widełek „headless kosztuje od… do…” nie podajemy, bo bez Twojego zakresu nic nie znaczą. Zamiast nich — lista pozycji, za które płacisz i które powinny się znaleźć w każdej wycenie.

Dwa systemy zamiast jednego. Płacisz za silnik (abonament SaaS, plan chmurowy jak Medusa Cloud albo serwer przy open source) i osobno za front: jego zbudowanie, hosting i utrzymanie. Wyjątkiem jest hosting Oxygen dla frontów Hydrogen, wliczony w płatne plany Shopify.

Opłaty silnika od płatności. Jeśli silnikiem jest Shopify, a płatności przyjmujesz przez zewnętrznego operatora zamiast Shopify Payments, Shopify dolicza „Zewnętrzne opłaty transakcyjne”: według cennika PL 2% w Basic, 1% w Grow, 0,6% w Advanced i 0,2% w Plus — ponad prowizję samego operatora. Według pomocy Shopify opłata nie dotyczy metod ręcznych (np. płatność przy odbiorze), a sklepy Plus korzystające wyłącznie z Shopify Payments są z niej zwolnione. To pozycja, która w headless łatwo umyka, bo checkout projektujesz sam.

Integracje. Każde połączenie — ERP, magazyn, kurierzy, operator płatności, CMS — trzeba zbudować przez API, przetestować i utrzymywać, gdy któraś strona zmieni wersję. W klasycznym sklepie część z nich to gotowe aplikacje z panelu.

Ludzie po starcie. Front wymaga kogoś, kto aktualizuje zależności, reaguje na błędy i wdraża zmiany. Przy dwóch dostawcach masz też dwa zestawy warunków dostępności i wsparcia — jak czytać takie zobowiązania, piszemy w tekście o SLA.

Dane rynkowe. Nasz raport „Koszty sklepów internetowych w Polsce — edycja 2026” nie wyodrębnia sklepów headless jako osobnej kategorii. Dla orientacji: mediana wdrożenia w kategorii sklepu średniego wynosi 15 000 zł netto (n=34), a w kategorii enterprise 46 000 zł netto (n=29). To zestawienie 108 publicznie dostępnych obserwacji cenowych od 70 podmiotów, zebranych w marcu–maju 2026, a nie faktury z projektów — traktuj je jako tło, nie jako cenę sklepu headless.

Własny szacunek zrobisz w kalkulatorze kosztu sklepu internetowego, który ma wariant headless z frontem w Next.js. Żeby porównać koszt posiadania sklepu w kilku latach, użyj kalkulatora TCO e-commerce — przy headless dolicz do wyniku osobno front i jego utrzymanie.

Headless a SEO i wydajność

Headless nie jest z definicji szybszy ani lepiej widoczny w Google. Daje kontrolę nad tym, co decyduje o szybkości: ile kodu trafia do przeglądarki, które strony są generowane z wyprzedzeniem, jak działa cache. Źle zbudowany front headless może być wolniejszy niż dobrze skonfigurowany motyw.

Mierz to wskaźnikami Core Web Vitals. Od 2024 roku liczy się w nich responsywność na interakcje, czyli INP. Jak ogłosił zespół web.dev, „INP will officially become a Core Web Vital and replace FID on March 12 of this year” — INP zastąpił FID 12 marca 2024 roku. Według web.dev INP do 200 ms oznacza dobrą responsywność, 200–500 ms wymaga poprawy, a powyżej 500 ms jest słaby. W sklepie INP to m.in. czas reakcji filtrów, przycisku „Dodaj do koszyka” i kroków checkoutu — czyli miejsc, które w headless projektujesz sam.

Po stronie SEO headless przenosi na Ciebie rzeczy, które motyw robi automatycznie: tytuły i opisy, dane strukturalne produktów, mapę strony, kanoniczne adresy, przekierowania. Zapisz je w wymaganiach przed startem. Więcej o SEO sklepu znajdziesz w dziale SEO e-commerce, a o projektowaniu koszyka i checkoutu — w dziale UX i UI.

Przejście na headless z działającego sklepu to migracja — ze wszystkimi jej ryzykami. Google w dokumentacji przenosin witryny zaleca stałe przekierowania 301 lub 308 i utrzymanie ich „for as long as possible, generally at least 1 year” (tłumaczenie własne: „jak najdłużej, zasadniczo co najmniej rok”), a także uprzedza: „you may experience ranking fluctuations while Google recrawls and reindexes your site” (tłumaczenie własne: „mogą wystąpić wahania pozycji, gdy Google ponownie indeksuje witrynę”). Plan migracji — mapa adresów, testy, monitoring — ma te wahania ograniczyć i skrócić. Opisujemy go krok po kroku w tekście o migracji sklepu bez utraty SEO, a do odhaczania służy checklista migracji sklepu.

Headless od pierwszego dnia czy później?

Obie drogi są rozsądne, tylko w różnych sytuacjach. Headless od pierwszego dnia ma sens, gdy wymagania, które go uzasadniają, znasz już przed startem: wiesz, że potrzebujesz własnego procesu zakupu, kilku kanałów albo integracji, których platforma nie obsłuży. Wtedy start na klasycznym sklepie i późniejsza migracja oznaczają, że płacisz dwa razy: raz za sklep, który porzucisz, drugi raz za przenosiny z ich ryzykiem dla SEO.

Klasyczny sklep na start, a headless później, ma sens, gdy dopiero sprawdzasz popyt, katalog jest mały, a proces zakupu standardowy. Wtedy wybierz silnik, z którego łatwo wyjść albo który sam obsługuje headless (np. Shopify z Hydrogen), żeby późniejsza zmiana dotyczyła frontu, a nie całego sklepu.

Zanim zdecydujesz, odpowiedz na te pytania:

1. Czy potrafisz wskazać konkretną funkcję lub proces, którego obecna albo planowana platforma nie obsłuży? (Nie „chcemy nowocześnie”, tylko „konfigurator z trzema zależnymi opcjami” albo „ceny z ERP per klient”).
2. Czy sklep ma działać w więcej niż jednym kanale lub na więcej niż jednym rynku z jednego katalogu?
3. Czy masz sprawdzony popyt — regularne zamówienia albo sprzedaż w innym kanale, którą przenosisz do sieci?
4. Kto będzie utrzymywał front po starcie: własny zespół, wykonawca w stałej umowie, nikt?
5. Czy znasz warunki wyjścia z silnika — jakie dane i w jakim formacie wyeksportujesz?
6. Czy budżet obejmuje dwa systemy, integracje i utrzymanie, a nie tylko wdrożenie?
7. Jeśli masz już sklep: czy masz plan migracji z mapą adresów i przekierowań?

Jeśli na pytania 1–3 odpowiadasz „nie”, headless jest prawdopodobnie przedwczesny. Jeśli na 4–6 nie masz odpowiedzi, najpierw je uzupełnij — to od nich zależy, czy headless będzie przewagą, czy kosztem.

Sami budujemy sklepy headless: front w Next.js, silnik dobrany do potrzeb, kod w repozytorium klienta. Przed projektem robimy fazę analizy, w której wybieramy architekturę — headless albo monolit — i jeśli klasyczny sklep wystarczy, mówimy to wprost. Szczegóły, zakres współpracy i poziomy opieki po starcie opisujemy na stronie sklep internetowy headless. Cały dział o wyborze silnika znajdziesz w przeglądzie platform e-commerce, a szerszy kontekst — w przewodniku po e-commerce.