Payload CMS: dlaczego przenoszę na niego firmy z WordPressa

PageSpeed mobile na poziomie 56, LCP 8,2 sekundy, 640 podstron do przeniesienia i trzy miesiące pracy. Tak wyglądał punkt startowy jednego z moich ostatnich projektów, w którym klient przyszedł z pytaniem o “coś szybszego niż WordPress”. Payload CMS wybraliśmy wspólnie, po przejściu przez alternatywy, i to nie był przypadek jednorazowy. Od dwóch lat regularnie przenoszę firmy z WordPressa na ten system i widzę powtarzający się wzorzec. Właściciele stron przestają wierzyć w obietnice kolejnej wtyczki do cache’owania, kiedy strona i tak ładuje się jak w 2015 roku.

Ten artykuł nie jest kolejnym wpisem sprzedażowym o cudownym headless CMS, który rozwiąże wszystkie problemy. Pokażę konkretne różnice między Payload a WordPressem, rozłożę koszty wdrożenia na czynniki pierwsze (łącznie z tym, kiedy WordPress wciąż wygrywa cenowo) i przejdę krok po kroku przez migrację 421 postów, 188 stron i 793 przekierowań 301 z realnego projektu. Nie obejdzie się bez niewygodnej prawdy. Dla dużej części małych firm Payload to strzelanie z armaty w komara, a agencje rzadko mówią to głośno, bo mniej marżowy WordPress nie sprzedaje się tak dobrze w ofercie.

Piszę to z perspektywy praktyka, który wdraża, a nie tylko czyta dokumentację. Dlatego zamiast ogólników znajdziesz tu tabele porównawcze, realne liczby z case study i szczerą odpowiedź na pytanie, kiedy sam odradzałem klientowi przejście na Payload, mimo że to właśnie ten system polecam najczęściej.

Czym jest Payload dla właściciela firmy: proste wyjaśnienie bez żargonu

WordPress znasz: instalujesz, wybierasz motyw, klikasz i masz stronę. Payload działa inaczej. To nie gotowa aplikacja, a silnik do zarządzania treścią, który programista wkleja w kod strony budowanej od zera.

Formalnie Payload CMS to headless CMS, czyli system zarządzania treścią bez wbudowanego wyglądu. “Headless” (bez głowy) znaczy dosłownie tyle, że jest panel do wpisywania treści, ale nie ma szablonu, który tę treść wyświetla. Front-end (to, co widzi klient w przeglądarce) buduje się osobno, najczęściej w Next.js.

W praktyce nie klikniesz “zainstaluj motyw” i nie zobaczysz strony w pięć minut. Ale zyskujesz coś ważniejszego, pełną kontrolę nad tym, jak treść jest wykorzystywana, bez ograniczeń szablonu.

Payload CMS kontra WordPress: różnice, które mają znaczenie

Różnica między “wtyczką” a “funkcją jako kodem” jest fundamentalna. W WordPressie instalujesz czarną skrzynkę napisaną przez kogoś, kogo nie znasz. W Payload developer pisze konkretną funkcję w TypeScript, widzi cały kod, testuje go i wersjonuje.

Rozdzielenie treści od wyglądu w praktyce

Ten sam artykuł czy produkt w Payload trafia do bazy raz, a potem zasila stronę WWW, aplikację mobilną i ekran w salonie, bo dane są dostępne przez API. WordPress miesza treść z szablonem PHP, więc wykorzystanie jej gdzie indziej wymaga dodatkowej pracy albo obejść.

Funkcje jako kod: inny domyślny model pracy

WordPress też pozwala pisać własny kod, w PHP, w motywie albo w osobnej wtyczce podpiętej pod hooki systemu. Problem jest w praktyce rynkowej. Typowa strona składa się z kilkudziesięciu gotowych wtyczek od różnych autorów, stąd konflikty między nimi i podatności bezpieczeństwa jako codzienność. W Payload własny kod nie jest opcją dla zaawansowanych, jest jedyną domyślną ścieżką. Formularz czy kalkulator piszesz w TypeScript, w tym samym repozytorium co cały front-end, z typami i code review, a nie jako oddzielony dodatek od nieznanego dostawcy.

Dla kogo Payload CMS ma sens, a dla kogo lepiej zostać przy WordPressie

Po kilkunastu wdrożeniach mam już wzorzec, kto skorzysta na migracji, a kto po prostu wyda pieniądze bez efektu.

Payload ma sens, gdy:

• firma ma rozbudowany produkt cyfrowy: stronę, aplikację mobilną, panel klienta zasilane tą samą treścią,
• treść trafia do wielu kanałów (web, app, ekrany w salonie, newsletter) i duplikowanie jej ręcznie boli,
• w zespole jest dostęp do developera na stałe, nie tylko na etapie wdrożenia,
• strona rośnie: setki podstron, częste zmiany struktury, potrzeba porządku w danych.

Zostań przy WordPressie, gdy:

• to wizytówka jednostronicowa albo blog firmowy bez ambicji skalowania,
• budżetu nie ma na developera do utrzymania, tylko na jednorazowe postawienie strony,
• wystarczy gotowy motyw i wtyczka do formularza kontaktowego.

Mówię to szczerze, mimo że poleceniem Payloada zarabiam. Nie każdy klient potrzebuje headless CMS. Czasem najlepsza rekomendacja to “zostań, jak jest”.

Next.js i Payload CMS: jak wygląda integracja front-endu

Payload od wersji 3 jest budowany natywnie wokół Next.js. To nie jest CMS, który dokleja się przez API do osobnej aplikacji, panel admina i front-end żyją w jednym repozytorium i jednym procesie.

W praktyce oznacza to korzystanie z Server Components, renderowania SSR i ISR bez dodatkowej konfiguracji. Dane z Payload trafiają do stron praktycznie bezpośrednio, bez zbędnych warstw pośrednich.

Dla SEO przekłada się to na szybszy czas do pierwszego renderu, lepsze wyniki Core Web Vitals, mniej JavaScriptu ładowanego po stronie klienta. Google to widzi i to punktuje.

Przejęcie Payload przez Figmę w 2025 roku: co to znaczy dla stabilności projektu

W czerwcu 2025 roku Figma ogłosiła na swoim blogu przejęcie Payload. Dla klientów, którzy pytają mnie “a co jeśli ten startup się zamknie”, to dobra wiadomość.

Przejęcie przez firmę wielkości Figmy oznacza realne finansowanie i dłuższy horyzont rozwoju niż niezależny startup żyjącego z rundy do rundy. Licencja MIT, na której działa Payload, zostaje bez zmian, więc nawet w czarnym scenariuszu kod nie zniknie z dnia na dzień. To argument, który realnie przemawia do działów IT: oparcie się o technologię dużego, rozpoznawalnego gracza zwiększa wiarygodność projektu bardziej niż jakiekolwiek zapewnienia w dokumentacji.

Jest też druga strona. Nowy właściciel może zmienić priorytety produktowe, przesunąć zespół na integracje z Figmą, wolniej reagować na zgłoszenia z innych nisz. To realne ryzyko, ale mniejsze niż to, że małemu startupowi po prostu zabraknie pieniędzy na kolejny rok działania.

Ile kosztuje wdrożenie Payload CMS w firmie

Payload CMS jest open source i darmowy. Płacisz za hosting (Vercel, Railway, VPS: przy małym projekcie zwykle 100-200 zł miesięcznie, przy dużym serwisie odpowiednio więcej) i za pracę developera, który wdroży i utrzyma system.

WordPress ma odwrotny profil kosztów: niski próg wejścia, tani hosting, gotowy motyw, strona w tydzień. Problem zaczyna się, gdy rośnie ruch i liczba podstron.

WordPress z czasem:

• płatne wtyczki za każdą funkcję
• narzędzia do przyspieszania (bo domyślnie jest wolny)
• mocniejszy hosting pod obciążenie
• developer do gaszenia pożarów po aktualizacjach

Payload z czasem:

• brak licencji wtyczek
• wydajność domyślna, nie dokupowana
• mniejsza powierzchnia awarii

Krzywe kosztów się przecinają. Przy małej wizytówce wygrywa WordPress. Przy serwisie z ruchem i setkami podstron Payload wychodzi taniej w perspektywie roku, mimo wyższego kosztu startowego. Orientacyjnie implementacja projektu średniej wielkości to 30-60 tys. zł, zależnie od liczby typów treści i integracji.

Case study: migracja 640 podstron z WordPressa na Payload CMS

Przeczytaj więcej: pełne case study migracji 640 stron

Klient miał serwis firmowy na WordPressie: 421 postów, 188 stron statycznych, 22 case studies. Łącznie 640 adresów URL z wieloletnią historią w Google. Cel ustaliliśmy wspólnie: przenieść to na Payload CMS bez utraty pozycji w wyszukiwarce. Wybór technologii też był wspólną decyzją, a nie moją rekomendacją przyjętą w ciemno.

Proces rozłożyłem na etapy. Najpierw eksport treści z WordPressa przez REST API, bo eksport XML gubił część metadanych w niestandardowych polach. Potem mapowanie. Każdy typ treści z WP dostał odpowiednik w postaci kolekcji w Payload, z polami dopasowanymi 1:1. Import zrobił skrypt, który przechodził przez wyeksportowane dane i zapisywał je do bazy Payload przez lokalne API, bez ręcznego klikania.

Najwięcej czasu zajęła nie migracja treści, a zachowanie struktury URL. Powstało 793 przekierowania 301, żeby stare adresy trafiały na nowe bez utraty linków przychodzących i pozycji SEO. Zespół klienta wskazał przy tym parametry, które z ich perspektywy były dla SEO najistotniejsze, i te wymagania stały się twardym kryterium odbioru, nie listą życzeń.

Ta migracja nie była pracą w pojedynkę. Klient dostarczał komplet danych o serwisie, brał aktywny udział w QA i precyzyjnie określił, jak ma wyglądać codzienna obsługa strony po stronie marketingu. To ostatnie ważyło najwięcej. Model edycji treści zaprojektowaliśmy pod ich realny sposób pracy, a nie pod domyślne założenia CMS-a.

Efekt: PageSpeed mobile poszedł z 56 do ponad 90, LCP spadł z 8,2 sekundy do wartości uznawanej za dobrą. Marketing dostał panel, w którym edycja treści jest prostsza niż w starym WordPressie, bez ryzyka rozjechania wyglądu.

Pełny opis kroków, narzędzi i kontroli kompletności jest w case study migracji 640 stron.

Headless CMS a klasyczny CMS: prawda, o której nie mówią agencje

Agencje kochają headless CMS, bo to droższy projekt, z dłuższym wdrożeniem, większą liczbą godzin developera i wyższą marżą. Problem w tym, że dla większości małych firm to strzelanie z armaty do muchy.

Miałem klienta, który po rozmowach z inną agencją przyszedł do mnie z gotowym planem migracji na Payload. Odradziłem. Miał wizytówkę z pięcioma podstronami, zero planów na aplikację mobilną, jeden człowiek edytujący treść raz na miesiąc. Klient został przy WordPressie, bo takim serwisem i tak zwykle zarządza ktoś w jego zespole, a migracja przy tej skali by się nie zwróciła.

Polecam Payload w innych projektach każdego tygodnia. Ale szczerość wobec klienta jest ważniejsza niż faktura za kolejne wdrożenie.

FAQ: najczęstsze pytania o Payload CMS

Podsumowanie

Payload CMS to nie uniwersalny następca WordPressa, a narzędzie dla konkretnego typu firmy: takiej z rozbudowanym produktem cyfrowym, wieloma kanałami dystrybucji treści i dostępem do developera na stałe. Migracja realnego serwisu z 640 podstronami pokazała, że przy odpowiedniej skali różnica w wydajności i porządku w danych jest ogromna, ale ta sama logika działa w drugą stronę. Mała wizytówka bez planów rozwoju nie potrzebuje headless CMS i tylko wyda pieniądze bez efektu. Przejęcie przez Figmę w 2025 roku dodatkowo zdejmuje z projektu ryzyko związane ze stabilnością dostawcy.