Era po WordPressie. Dlaczego rezygnuję z CMS-ów?
Tradycyjny system zarządzania treścią (CMS) to podstępny twór. Wszyscy powtarzali nam jako pewnik: „jeśli budujesz stronę firmową, musisz użyć WordPressa. Ewentualnie postaw na rozbudowane Headless CMS typu Strapi czy Contentful". Argumentem najczęstszym na rzecz takiego wyboru była możliwość zarządzania treścią bez dotykania kodu — dla przeciętnego klienta i redaktora. Dziś śmiało mówię: do widzenia. I to nie w teorii, a w bardzo bezwzględnej praktyce. Rezygnuję z CMS-ów.
Jeśli przyjrzysz się dzisiejszemu rynkowi, to coś, co pierwotnie miało być „ułatwieniem w zarządzaniu prostym tekstem", ewoluowało do skomplikowanych potworów z tysiącem nieaktualnych wtyczek, regularnymi włamaniami przez luki bezpieczeństwa PHP rodem z roku 2012 i gigabajtami generowanej na zapas pamięci podręcznej spowalniającej i tak kiepską responsywność u użytkownika końcowego.
W erze przed-autonomicznej alternatyw było niewiele. Pisanie artykułów manualnie w kodzie HTML to udręka deweloperska. Ale pojawienie się AI oraz koncepcji autonomicznych silników renderujących treści to zmiana na poziomie odkrycia druku przez Gutenberga. Czas wyjść z pudełka CMS.
Rachunek sumienia z WordPressem
Zanim przejdziemy dalej, cofnijmy się o krok. WordPress sam w sobie nie jest zły — to narzędzie, które zbudowało niemal 40% wszystkich stron internetowych na świecie. Problem polega na tym, w co się rozrósł i jak wygląda jego codzienne utrzymanie w 2026 roku.
Zacznijmy od bezpieczeństwa. WordPress opiera się na PHP — języku, który przez lata zbierał kolejne łatki jak stary płaszcz zbiera dziury. Każda wtyczka to potencjalne drzwi wejściowe dla atakującego. Wystarczy jeden nieaktualny plugin kontaktowy, formularz komentarzy bez walidacji albo zapomniana kopia zapasowa w publicznym katalogu — i Twoja strona firmowa staje się hostem dla phishingu lub kopalnią kryptowalut. To nie jest teoria. Statystyki mówią same za siebie: w samym 2024 roku ponad 90% zhakowanych stron opartych o CMS to instalacje WordPressa. A do tego dochodzi cała kultura „zainstaluj wtyczkę na wszystko" — od optymalizacji obrazków przez formularz kontaktowy po generowanie sitemap. Każda z tych wtyczek to osobny projekt open-source z własnym cyklem życia, własnymi podatnościami i nierzadko — porzucony przez autora po dwóch latach.
Następnie — wydajność. Świeża instalacja WordPressa z motywem, kilkoma wtyczkami SEO, cache'em i builderem stron potrafi ważyć kilkadziesiąt megabajtów. Każde zapytanie użytkownika to podróż przez serwer PHP, bazę danych MySQL, warstwy cache'owania i dopiero potem — wygenerowany HTML. Porównaj to z serwowaniem statycznego pliku HTML bezpośrednio z CDN: różnica w czasie odpowiedzi to nie procenty, a rzędy wielkości.
I wreszcie — koszty. „Darmowy" WordPress wymaga hostingu z PHP i bazą danych (od kilkudziesięciu do kilkuset złotych miesięcznie), płatnych wtyczek zabezpieczających, regularnych kopii zapasowych i czyjegoś czasu na aktualizacje. Suma tych kosztów rośnie z każdym miesiącem, a w zamian dostajesz system, którego główną zaletą było kiedyś to, że „łatwo dodać nowy wpis przez panel".
Statyczne pliki w natarciu
Jak uciec od ciężkich instalacji WordPressa, za których pozorną darmowość płacimy utrzymaniem gigantycznego długu technicznego w bazie danych pełnej spamerskich komentarzy w cyrylicy?
Kierunek wyznacza file-based routing wymieszany z Markdown (lub MDX). W tej architekturze nie potrzebujesz skomplikowanego panelu do opublikowania wpisu na blogu. Mówiąc krótko — artykuły są po prostu fizycznymi plikami tekstowymi (.md), zamkniętymi w konkretnym podfolderze Twojego repozytorium (np. src/content/dziennik/).
Każdy taki plik ma prostą strukturę: nagłówek z metadanymi (tytuł, data, tagi, opis SEO) zapisany w formacie frontmatter YAML i treść w czystym Markdownie. Zero bazy danych. Zero zapytań SQL. Zero warstw abstrakcji między Twoim tekstem a użytkownikiem. Plik istnieje — strona istnieje. Plik usuniesz — strona znika. Prostota, która jest jednocześnie potężna i niezawodna.
Co więcej, taka architektura naturalnie wspiera wersjonowanie. Każda zmiana w artykule to commit w repozytorium Git — masz pełną historię edycji, możliwość cofnięcia się do dowolnej wersji i przejrzysty diff pokazujący, co dokładnie się zmieniło. WordPress oferuje coś podobnego w postaci rewizji wpisów, ale to kolejne wiersze w bazie danych, których nikt nigdy nie czyści i które z czasem spowalniają całą instalację.
Brzmi jak coś trudnego do edycji w locie? Dochodziło przecież do kuriozalnych sytuacji, gdzie właściciele biznesów musieli pisać e-maile do „Zespołu IT" pod tytułem: „Proszę zaktualizować na stronie nagłówek promocyjny i poprawić literówkę w piątym paragrafie". Zastąpmy zespół IT... sztuczną inteligencją.
Bezobsługowy backend — Git jako źródło prawdy
Wprowadźmy do gry pełną autonomię. W dzisiejszych realiach to, jak zasilany jest Twój system blogowy, może zapierać dech w piersiach.
Wyobraź sobie, że piszesz swój najnowszy tekst w Notatniku Apple (Notes) na iPhonie — na fali inspiracji, np. „Dlaczego nie lubię ryb o poranku". Twoja aplikacja Skróty na iOS formatuje go i wyrzuca przez Webhooka do chmury (Cloudflare Workflows). W chmurze czeka zaprogramowany asystent AI, który odczytuje tekst, analizuje, co z niego ma być tytułem, a co zajawką SEO, automatycznie dokłada formatowanie z poprawnymi tagami Markdown, a na koniec... po prostu wywołuje GitHub Commit i wrzuca plik tekstowy o nazwie 2026-dlaczego-nie-lubie-ryb.md prosto do repozytorium.
Repozytorium GitHub po przyjęciu tego malutkiego, statycznego pliku wysyła cichy sygnał do Vercela czy innej usługi Edge: „Zrób nowy deployment". Twoja strona odświeża się sama. Wszystko zostaje idealnie sformatowane i podpięte pod klasę wizualną Twojej aplikacji dzięki rozwiązaniom typu Tailwind Typography. A to wszystko w czasie trzydziestu sekund.
Gdzie tu jest CMS? Nie ma. Nie ma bazy danych PostgreSQL. Nie ma logowania przez /wp-admin. Nie ma barier wejścia ani hakerów szukających szczelin w firewallu, a już tym bardziej opłat subskrypcyjnych w zamian za „przyjemne bycie w chmurze".
Stworzyłeś nieskończenie skalowalnego bloga, który za cenę darmowego GitHuba przetrwa każdy atak DDoS na poziomie DNS, a jego opłaty eksploatacyjne to zero złotych. Twoim „panelem edycji" jest dowolny komunikator czy notatnik połączony z Cloudflare Workflows, wysyłający Twoje pliki w świat. Twoją zaporą, a zarazem backendem — repozytorium kodu.
Wbudowane mechanizmy Next.js
Ten rewolucyjny brak potrzeby istnienia klasycznego backendu informacyjnego opiera się po stronie Twojej witryny o silne i już dojrzałe filary frameworków webowych pokroju Next.js. Funkcje takie jak generateStaticParams pozwalają po wdrożeniu pliku błyskawicznie wstępnie zbudować czysty, hiper-szybki HTML zoptymalizowany dla każdego bota Google'a — bez żadnych zewnętrznych sitemap, bo te budowane są automatycznie.
Warto podkreślić, co to oznacza w praktyce. Tradycyjny blog na WordPressie generuje stronę dynamicznie przy każdym żądaniu — serwer odpytuje bazę, składa szablon, wstrzykuje treść i dopiero serwuje wynik. W podejściu statycznym HTML jest gotowy jeszcze zanim ktokolwiek go odwiedzi. Strona jest pre-renderowana w momencie deployu i serwowana z edge'a — najbliższego geograficznie węzła sieci CDN. Dla użytkownika oznacza to czas ładowania rzędu milisekund. Dla Google'a — idealnie skrojony dokument pod indeksowanie.
Do tego dochodzą takie mechanizmy jak Incremental Static Regeneration (ISR), pozwalający odświeżać pojedyncze podstrony bez przebudowy całego projektu, oraz dynamiczne importy komponentów MDX — dzięki którym w pliku Markdown możesz osadzać interaktywne elementy React. To nie jest statyczna strona z lat dziewięćdziesiątych. To nowoczesny, reaktywny frontend zasilany najprostszym możliwym źródłem danych: plikami tekstowymi.
Do widzenia, Headless
Należałoby zadać pytanie biznesowe: czy powinieneś w 2026 roku kupować wariant Headless CMS dla „zwiększenia użyteczności zarządzania"? Trzeba uświadomić sobie, że tego typu narzędzia są genialne dla redakcji, w których czterdziestu edytorów musi publikować treść pod ostrzałem edycji innych — z systemem ról, wersjonowania i workflow zatwierdzania.
Ale dla niezależnych twórców, freelancerów, inżynierów i founderów nowoczesnych stron lub SaaS-ów opartych o generację danych? To strzelanie do mrówki z armaty na abonament 99 dolarów miesięcznie. Contentful, Sanity, Prismic — każde z tych narzędzi rozwiązuje problem, którego samodzielny twórca po prostu nie ma.
Odrzuciłem to z wielkim zadowoleniem. Pliki Markdown umiejscowione na równi z interfejsem dają absolutną elastyczność budowy. Skrypty asystentów AI piszą samodzielnie całą witrynę opartą o content bez mojej fizycznej obecności. Mam system, w którym strona po upadku wszystkich platform hostingowych z wirtualnymi serwerami na świecie mogłaby zostać odbudowana lokalnie w minutę — jednym poleceniem odzyskania plików z repozytorium Git.
Co zyskujesz, porzucając CMS?
Podsumujmy to konkretnie. Po przejściu na architekturę opartą o pliki Markdown i automatyzację zyskujesz po pierwsze bezpieczeństwo — brak backendu PHP to brak powierzchni ataku; nie ma bazy danych do wykradzenia, nie ma panelu logowania do złamania brute-forcem. Po drugie wydajność — statyczny HTML serwowany z CDN zamiast dynamicznych zapytań do bazy oznacza czas ładowania, o którym WordPress może tylko pomarzyć. Po trzecie zerowy koszt — GitHub, Vercel i Cloudflare w darmowych planach wystarczają w zupełności nawet dla stron z dziesiątkami tysięcy odsłon miesięcznie. Po czwarte pełną przenośność — Twoje treści to pliki tekstowe, które możesz otworzyć w dowolnym edytorze, na dowolnym systemie operacyjnym, za sto lat. I wreszcie automatyzację — publikacja od pomysłu do produkcji zajmuje sekundy, bez logowania do żadnego panelu, bez czekania na „Zespół IT".
To nie jest rozwiązanie dla każdego. Duże redakcje, portale z tysiącami autorów i złożonymi workflow zatwierdzania nadal potrzebują dedykowanych systemów. Ale jeśli jesteś samodzielnym twórcą, founderem, freelancerem lub małym zespołem — CMS to zbędny balast, za który płacisz czasem, pieniędzmi i bezpieczeństwem. Przez lata branża wmówiła nam, że „postawić stronę" to znaczy zainstalować CMS, wybrać motyw i modlić się, żeby aktualizacja nie położyła produkcji. Tymczasem w 2026 roku „postawić stronę" może oznaczać napisanie tekstu na telefonie i pozwolenie, by reszta wydarzyła się sama.
Kierunek tej koncepcji wytycza jeden z bloków nauczania na naszych szkoleniach dla „samotnych wilków foundingu" — jak przejść z systemu zarządzania opartego na wtyczkach do w pełni automatycznego, lekkiego modułu. Zapoznasz się z tym szczegółowo na naszej stronie Kursy. Era bez-CMS-owa to powrót do natury w kodowaniu internetu, a matka natura połączona z AI oddaje nam ogromną dywidendę.