Zwróć uwagę, jak zwykle ustawiana jest prowadzona rozmowa. To prawie nigdy nie jest „WordPress kontra Craft”, „WordPress kontra Statamic” albo „WordPress kontra Payload”. To WordPress kontra wszystko inne naraz. WordPress i reszta świata. Po jednej stronie zasiedziały standard, po drugiej cały nowoczesny stack.
Żaden inny CMS nie jest tak traktowany. Nikt nie pisze „Sanity kontra świat”. To ujęcie jest zarezerwowane dla WordPressa i warto zapytać, dlaczego przetrwało do 2026 roku, skoro powód, który kiedyś je uzasadniał, w dużej mierze zniknął.
Klasycznym powodem, dla którego rysowało się grubą linię wokół CMS-a, był koszt wyjścia. Migracja z platformy oznaczała wielomiesięczny projekt: odtworzenie szablonów, przebudowę modelu treści, przeniesienie pluginów, szkolenie redaktorów, przepisanie zapytań. Zmiana stacku była na tyle droga, że początkowy wybór wydawał się prawie trwały. Nie wybierałeś CMS-a. Dołączałeś do obozu. Nie dotyczyło to tylko WordPressa ale każdego innego CMS’a.
AI po cichu skompresowało dużą część tego kosztu, zwłaszcza w małych, dobrze zdefiniowanych serwisach treściowych. Ten podział powinien więc słabnąć. Nie słabnie. I właśnie ten fakt jest najciekawszy.
Co naprawdę staniało
Żmudna praca związana z przechodzeniem między stackami gwałtownie potaniała. To nie jest marketingowe hasło, tylko opis tego, co praktycy już robią.
Przeniesienie szablonu Liquid do komponentów Astro, zamiana pętli PHP z motywu WordPressa na warstwę renderowania we frameworku, przełożenie struktury pól ACF na typowany frontmatter, napisanie skryptu export-transform-import dla dziesięciu tysięcy wpisów z zachowaniem custom meta - to były zadania, które robiły z migracji osobną dużą pozycję w budżecie. Dziś coraz częściej sprowadza się to do rozmowy z modelem i popołudnia przeglądu.
To zmienia ekonomię decyzji o CMS-ie u samego źródła. Gdy zmiana jest droga, racjonalnie jest przesadnie dużo zainwestować w początkowy wybór, a potem go bronić. Gdy zmiana jest tania, początkowy wybór liczy się mniej niż zdolność do zmiany stacku później. Stack przestaje być kupnem mieszkania, a zaczyna być najmem.
Trzeba jednak uczciwie mówić o kierunku tej krzywej kosztu, bo „tanie” nie znaczy „darmowe”, a cena nie jest stała - rośnie. Im większą i bardziej splątaną rzecz oddajesz modelowi - pełny motyw, nieudokumentowany plugin, dekadę custom meta - tym więcej kosztuje uzyskanie wyniku, któremu można zaufać: więcej tokenów, więcej rund przeglądu, więcej iteracji.
AI obniżyło koszt migracji o rząd wielkości względem ręcznej pracy, ale koszt dobrego prowadzenia takiego procesu jest realny i rośnie, nie zmierza do zera. Jak ten koszt ograniczać - ekonomia promptu i projektowania kontekstu - to temat na osobny tekst. Tutaj ważniejszy jest węższy punkt widzenia: nawet rosnący koszt migracji wspieranej przez AI pozostaje dużo tańszy niż dawny ręczny proces, przez który wybór CMS-a stawał się decyzją na lata.
Jeśli mały serwis treści mogę przenieść z WordPressa na dowolny inny CMS w dni, a nie miesiące, to w takim świecie slogan: „WordPress kontra reszta świata” brzmi coraz dziwniej. Dlaczego więc nadal działa?
Ten spór nigdy nie był o kod
Główna teza tego tekstu jest taka: ustawienie WordPressa przeciwko wszystkiemu innemu nigdy tak naprawdę nie dotyczyło technologii. Dotyczyło powierzchni operacyjnej, którą WordPress kontroluje. AI obniżyło koszt kodu, ale tej powierzchni praktycznie do tej pory nie ruszyło.
WordPress nie jest broniony dlatego, że jego PHP jest nie do zastąpienia. Jest broniony przez wszystko, co otacza kod. Redaktora, który od ośmiu lat publikuje z tego panelu. Abonament agencyjny zbudowany wokół konkretnego zestawu pluginów. Klienta, który chce się zalogować, zobaczyć znajomy kokpit i zmienić tekst w hero bez udziału programisty. Czterdzieści pluginów rozwiązujących nudne, prawdziwe problemy - formularze, przekierowania, pola SEO, backupy, bramkę członkowską - których nikt nie chce odtwarzać od zera. To ten sam punkt, który opisywałem w tekście Astro + AI kontra WordPress dla prostych stron treściowych: realnym konkurentem WordPressa nigdy nie był inny framework. Był nim gotowy proces pracy jaki zapewnia WordPress.
AI skompresowało tę część migracji, która dotyczyła kodu. Prawie nic nie zrobiło z częścią, która żyje w ludziach, nawykach, umowach i pamięci organizacji. A to właśnie ta druga część zawsze jest ważniejsza. Podział przetrwał, bo rzecz, którą naprawdę koduje - ciążenie redakcyjne, własność powierzchni publikacji, koszt ponownego przeszkolenia ludzi - nie stała się tańsza.
Dlaczego to „kontra” nadal coś mówi - i gdzie kłamie
Jest powód, dla którego WordPress ląduje po jednej stronie, a „wszystko inne” po drugiej. To nie jest wyłącznie przynależność do obozu. WordPress naprawdę zajmuje osobne miejsce: jest dominującą mainstreamową aplikacją, która dostarcza kompletny produkt redakcyjny bez składania go z części - role, rewizje, bibliotekę mediów, harmonogram publikacji, podglądy, interfejs znany nietechnicznym zespołom. Duża część „reszty świata” dostarcza warstwę techniczną treści i każe ją samodzielnie złożyć w workflow.
Slogan: “WordPress kontra reszta świata” częściowo łapie coś prawdziwego. Tylko celuje w złą oś. Uczciwy podział w 2026 roku nie brzmi: WordPress kontra nowoczesne stacki. Brzmi: gotowa powierzchnia redakcyjna kontra składana powierzchnia redakcyjna - i ta linia przechodzi także przez nowoczesny ekosystem. Headless Sanity z porządnie zbudowanym Studio jest bliżej pierwszej strony tej linii. Surowe repo Astro z plikami Markdown jest bliżej drugiej. WordPress jest ważnym przykładem modelu gotowego, nie kategorią samą w sobie.
Ta sama korekta pojawia się na zupełnie innej osi, gdy problemem nie jest treść. W tekście Laravel kontra WordPress dla aplikacji księgi transakcyjnej linia zostaje narysowana jako problem treści kontra problem transakcji, a wniosek jest ten sam od drugiej strony: obozy zawsze były skrótem dla dopasowania, nie realną opozycją. Dwie różne osie, jeden wniosek - “obóz” nigdy nie było użyteczną jednostką analizy.
Nie wybierasz obozu. Wybierasz, ile infrastruktury redakcyjnej chcesz kupić, a ile zbudować. I ponieważ AI sprawiło, że budowanie jest tańsze, ten stosunek możesz dziś regulować per projekt, zamiast zamykać się w decyzji na dekadę. Zmęczenie kompozycyjnością na rynku CMS-ów opowiada tę samą historię od drugiej strony: zespoły, które kupiły wizję „złóż wszystko sam”, odkrywają, że koszt składania był niedoszacowany, tak samo jak kiedyś koszt migracji.
Czym zastąpić ten podział
Jeśli zmiana stacku jest tania, a prawdziwą zmienną jest własność workflow, użyteczne pytanie nie brzmi już „WordPress czy nie”. Lepiej rozbić je na sekwencję konkretnych pytań.
Kto jest właścicielem powierzchni redakcyjnej i czy musi mieć nad nią kontrolę niezależnie od programistów? Jeśli nietechniczny zespół musi publikować i przebudowywać treść bez wsparcia developmentu, kupujesz gotowy workflow, a WordPress jest mocną i uczciwą odpowiedzią na ten wymóg. Nie kompromisem z przeszłości. Trafnym dopasowaniem.
Jaka część problemu „czterdziestu pluginów” naprawdę dźwiga wartość serwisu? Duża część ciężaru WordPressa rozwiązuje problemy, których skupiony serwis treściowy po prostu nie ma. Jeśli nie prowadzisz członkostw, komentarzy, kampanii i lejka commerce, większość tej gotowej powierzchni jest kosztem bez korzyści, a lżejszy stack wygrywa.
I najważniejsze: jak odwracalna jest ta decyzja teraz? To właśnie to AI faktycznie zmieniło. Skoro możesz migrować później za ułamek dawnego kosztu - tam, gdzie powierzchnia redakcyjna jest na tyle lekka, by to było prawdą - wolno Ci podjąć mniejszą, bardziej warunkową decyzję. Zacznij od monolitu i wyciągnij frontend dopiero wtedy, gdy problem stanie się konkretny. Zacznij od płaskich plików i dodaj CMS oparty na git, gdy pojawi się drugi redaktor. Stack staje się pozycją, którą zajmujesz, a nie murem, który budujesz.
Co to oznacza w praktyce
Trwałość hasła „WordPress kontra reszta świata” jest sygnałem, że branża wciąż wycenia decyzje CMS-owe tak, jakby były nieodwracalne, w roku, w którym w większości przypadków już takie nie są. Ta błędna wycena produkuje dwa symetryczne błędy.
Jeden obóz broni WordPressa długo po tym, jak przestał pasować, bo rama rozmowy podpowiada, że odejście oznacza przejście do wroga - podczas gdy dla małej, dobrze ograniczonej strony może dziś oznaczać skrypt migracyjny, przegląd i preview deploy. Drugi obóz porzuca WordPressa z zasady, traktuje gotową powierzchnię redakcyjną jak wstydliwy ciężar legacy, a potem ręcznie odbudowuje jej gorszą wersję, bo nie docenił, gdzie naprawdę była wartość.
Oba błędy wynikają z wiary, że ten podział dotyczy technologii. Nie dotyczy. Dotyczy tego, kto wykonuje pracę redakcyjną, jak niezależny musi być od developerów i - po raz pierwszy - jak łatwo można później zmienić zdanie.
Podsumowanie
WordPress wciąż jest ustawiany przeciwko całej reszcie świata, bo ta opozycja nigdy nie była twierdzeniem technicznym. Była skrótem dla realnego kompromisu: kup kompletny workflow redakcyjny albo złóż własny. Ten kompromis nadal istnieje, nadal warto o nim dyskutować i nadal często słusznie kończy się wyborem WordPressa.
AI zmieniło koszt pomyłki. Migracja potaniała, wybór stał się bardziej odwracalny, więc teza straciła ekonomiczny fundament, choć zachowała rozpęd. Obozy przeżyły własne uzasadnienie.
Ważne pytanie nie brzmi, po której jesteś stronie. Brzmi: ile powierzchni redakcyjnej ten konkretny projekt powinien kupić, a ile zbudować - i jak tanio możesz wrócić do tej odpowiedzi, gdy projekt się zmieni. Odpowiedz Sobie na te dwa pytania. „WordPress kontra reszta świata” przestaje być linią frontu i wraca do tego, czym zawsze powinno być: zwykłą, możliwą do rewizji decyzją inżynierską.