Na początku 2025 roku WordPress trzymał 43,6 procent sieci. Dziś jest to 41,5 procent, a spadek przyspiesza. Ciekawe nie jest jednak samo “ile”, tylko dokąd te udziały uciekają. Nie do Wixa ani Shopify, bo te stoją w miejscu. Rosną strony, na których W3Techs nie wykrywa żadnego CMS-a. Josh Koenig, współzałożyciel Pantheona, ujął to jednym słowem: “to vibecoding”.
Zanim odpowiemy, czy to problem dla WordPressa, warto powiedzieć wprost, o czym mowa, bo termin robi zawrotną karierę i rozumiany jest różnie.
Czym jest vibecoding
Vibecoding to budowanie aplikacji przez opisywanie ich modelowi językowemu i akceptowanie tego, co wygeneruje, bez czytania kodu linijka po linijce. Narzędzia to Lovable, Bolt.new, v0 od Vercela, Replit Agent i Base44. Wpisujesz “zrób sklep z logowaniem i płatnościami”, dostajesz działający frontend, bazę (zwykle Supabase) i deploy w kilka minut.
Dla prototypu, wewnętrznego narzędzia albo landingu, który ma żyć tydzień, to naprawdę dobre. Robimy tak własne makiety, żeby pokazać klientowi kierunek, zanim ktokolwiek napisze produkcyjny kod. Problem zaczyna się dopiero wtedy, gdy taki wynik trafia na produkcję jako fundament biznesu.
Gdzie vibecodowane strony się sypią
To nie jest obrona WordPressa z urzędu. To lista tego, co realnie widać, gdy ktoś przychodzi z prośbą “działało, a teraz nie działa”:
- Klucze w bundlu. Model wrzuca klucz
service_roleSupabase do kodu, który ląduje w przeglądarce. Każdy z narzędzi deweloperskich go odczyta. W 2025 roku przez wycieki kluczy z aplikacji budowanych w Lovable i bazy Supabase bez włączonego Row Level Security wyciekały całe tabele użytkowników. - Endpointy bez autoryzacji. Prompt “zrób panel admina” generuje panel, ale trasa
/api/adminnie sprawdza, kto puka. Wygląda, że działa, bo autor testuje ją zalogowany na własne konto. - Brak walidacji i limitów. Formularz kontaktowy bez rate limitingu i sanityzacji staje się otwartą bramą do wysyłki spamu i prób iniekcji.
- Niewidzialność w wyszukiwarce. Treść renderowana dopiero po stronie klienta, bez renderowania po stronie serwera, to dla robota Google pusta strona. Katalog produktów, który nie istnieje w kodzie HTML, nie trafi do indeksu.
- Zero ścieżki utrzymania. Brak migracji bazy, backupów, wersjonowania i pipeline’u. Pierwsza poważniejsza zmiana to przepisywanie od zera, bo nikt, łącznie z autorem promptu, nie wie, dlaczego to zostało zbudowane tak, a nie inaczej.
Dwa konkretne przypadki z ostatnich miesięcy. Startup zbudował panel klienta w Bolt.new i ruszył w tydzień. Po dwóch tygodniach okazało się, że użytkownicy widzą i edytują dane z cudzych kont, bo anon key Supabase leżał w kodzie, a Row Level Security nie było w ogóle. Druga firma postawiła “sklep” w v0. Ładny, szybki, i po trzech miesiącach zerowy ruch z Google, bo cały katalog renderował się dopiero w przeglądarce. Obie strony wyglądały bez zarzutu w dniu premiery. To jest pułapka vibecodingu: demo jest bezbłędne, a rachunek przychodzi później.
Jak rozpoznać vibecodowaną stronę
Nie trzeba do tego dostępu do kodu. Kilka sygnałów wystarczy:
- Podgląd źródła (Ctrl+U) pokazuje niemal pusty
<body>i jeden duży plik JavaScript. Treść pojawia się dopiero po załadowaniu skryptu. - Wyłączenie JavaScriptu zostawia białą stronę zamiast tekstu.
- W wynikach Google strona nie ma podstron poza główną, mimo że w przeglądarce widać ich wiele.
- Brak strony logowania pod własną domeną albo panel oparty wyłącznie o zewnętrzny serwis bez konfiguracji uprawnień.
- Nagłówki odpowiedzi wskazują na hosting typu preview (Vercel, Netlify) bez własnej warstwy aplikacji.
Żaden z tych punktów osobno nie jest wyrokiem. Razem układają się w obraz strony, która powstała z promptu i nigdy nie dostała fundamentu.
Vibecoding a WordPress na produkcji
| Kryterium | Strona vibecodowana | WordPress prowadzony przez seniora |
|---|---|---|
| Czas do pierwszego demo | Minuty | Dni |
| Renderowanie dla SEO | Zwykle po stronie klienta | HTML po stronie serwera |
| Kontrola uprawnień | Domyślnie brak, trzeba dodać | Role i uprawnienia w rdzeniu |
| Ścieżka utrzymania | Brak migracji i backupów | Aktualizacje, kopie, pipeline |
| Rozwój po roku | Często przepisanie od zera | Iteracja na istniejącym kodzie |
| Odpowiedzialność za awarię | Rozproszona | Jeden inżynier, który zna kod |
Tabela nie mówi, że vibecoding jest zły. Mówi, do czego każde z narzędzi pasuje. Do sprawdzenia pomysłu w weekend, vibecoding wygrywa bez dyskusji. Do serwisu, który ma zarabiać za rok, wygrywa fundament.
Dlaczego to nie koniec WordPressa
Udział spada, bo dolna półka rynku, czyli proste strony stawiane kiedyś na WordPressie “bo tak”, faktycznie przenosi się na AI. I dobrze. To była najmniej dochodowa, najbardziej jednorazowa część rynku. WordPress traci to, na czym i tak nikt nie zarabiał.
Zostaje reszta: sklepy WooCommerce z realnym obrotem, serwisy z wielojęzycznością i poprawnym hreflang, strony pod RODO i inne wymogi zgodności, projekty, które mają żyć pięć lat i przetrwać kilkanaście aktualizacji. Tam vibecoding nie sięga, bo tam nie chodzi o wygenerowanie ekranu, tylko o fundament: bezpieczeństwo, wydajność mierzalną w Core Web Vitals, utrzymanie i odpowiedzialność za to, co stanie się o drugiej w nocy w szczycie Black Friday.
WordPress nie wygrywa dlatego, że jest modny. Wygrywa dlatego, że ma dwadzieścia lat ekosystemu, przewidywalną ścieżkę utrzymania i człowieka, który wie, dlaczego coś jest zbudowane tak, a nie inaczej.
Kiedy vibecoding ma sens, a kiedy zadzwonić po seniora
Prosto. Prototyp, MVP, wewnętrzne narzędzie albo landing na kampanię, vibecoduj śmiało. Szybko, tanio, wystarczająco. Sklep, serwis firmowy albo cokolwiek, co ma z czegoś żyć i istnieć za rok, potrzebuje fundamentu, a nie wygenerowanego ekranu.
Jeśli masz już stronę zbudowaną przez AI i coś zaczyna się sypać, od wycieków, przez brak ruchu, po “nie da się tego rozwinąć”, to zwykle naprawialne, ale nie kolejnym promptem. Naprawiamy strony zrobione przez AI: audyt bezpieczeństwa, SEO od zera i decyzja, co przepisać, a co uratować. Robi to programista, który przeczyta kod, którego nikt wcześniej nie czytał.
