Wybór CMS-a to jedna z niewielu decyzji w projekcie, której nie da się tanio odwrócić. Zmiana systemu po dwóch latach oznacza migrację treści, przekierowania, nowy szablon i często utratę części ruchu z Google. Dlatego zanim polecę klientowi konkretny system, przechodzę z nim przez kilka pytań o to, kto będzie z niego korzystał, jak projekt ma się rozwijać i ile naprawdę będzie kosztował. Poniżej pokazuję te kryteria, typowe pułapki i to, co wybieram w najczęstszych scenariuszach.
Pytania, od których zaczynam
- Kto będzie edytował treści i jak często? Inny system sprawdzi się, gdy jedna osoba raz w miesiącu dodaje wpis, a inny, gdy kilkuosobowa redakcja publikuje codziennie i potrzebuje ról, akceptacji i harmonogramu.
- Jakie treści będą na stronie? Wpisy i podstrony to standard. Katalog produktów z wariantami, baza realizacji z filtrami czy oferty pracy z formularzem zgłoszeń wymagają systemu, który dobrze obsługuje własne typy treści.
- Ile wersji językowych i domen? Wielojęzyczność dodana do systemu, który jej nie wspiera, to później jedno z najtrudniejszych miejsc w utrzymaniu.
- Z czym strona ma się łączyć? ERP, CRM, system magazynowy, marketplace, narzędzia marketingowe. Brak gotowej integracji oznacza pisanie jej od zera i utrzymywanie przy każdej aktualizacji.
- Kto będzie dbał o aktualizacje i bezpieczeństwo? System open source na własnym serwerze daje pełną kontrolę, ale ktoś musi regularnie aktualizować rdzeń, wtyczki i serwer.
Kryteria, według których porównuję systemy
Kontrola nad SEO. Sprawdzam, czy mogę samodzielnie ustawić adresy URL, tytuły, opisy, canonicale, przekierowania, mapę strony i dane strukturalne. W części platform abonamentowych struktura adresów jest narzucona, np. produkty i kategorie zawsze mają w adresie stały przedrostek, którego nie da się zmienić.
Wydajność. Patrzę nie na demo z pustą bazą, ale na to, jak system zachowuje się przy tysiącach wpisów lub produktów. Wiele problemów z szybkością wynika nie z samego CMS-a, tylko z tego, jak wtyczki i motywy odpytują bazę, dlatego wydajna komunikacja z bazą danych jest dla mnie jednym z głównych kryteriów.
Całkowity koszt. Licencja lub abonament to tylko część. Doliczam płatne wtyczki i motywy z rocznym odnowieniem, prowizje od sprzedaży w platformach SaaS, koszt hostingu, aktualizacji i wsparcia programisty. Dopiero suma za trzy lata pokazuje realną różnicę.
Dostępność specjalistów. Na popularny system łatwiej znaleźć wykonawcę i taniej go utrzymać. Niszowy CMS może być technicznie świetny, ale przy zmianie firmy wdrożeniowej okazuje się, że nikt nie chce go przejąć.
Możliwość wyjścia. Zawsze sprawdzam, czy da się wyeksportować treści, produkty, klientów i zamówienia w otwartym formacie. To, jak łatwo opuścić system, jest równie ważne jak to, jak łatwo go wdrożyć.
Strony firmowe, blogi i portale
WordPress wybieram w większości stron firmowych i blogów. Daje ogromny wybór rozwiązań, łatwą edycję i pełną kontrolę nad SEO. Jego największą wadą nie jest sam system, tylko skłonność do instalowania kolejnych dodatków. Przy każdym projekcie ograniczam liczbę rozszerzeń do tych, które naprawdę są potrzebne, i sprawdzam, które wtyczki do WordPressa rzeczywiście są niezbędne.
Drupal i TYPO3 to dobry wybór dla dużych serwisów: wielu redaktorów, rozbudowane uprawnienia, wiele wersji językowych i domen w jednym panelu. W małych projektach ich możliwości rzadko się zwracają.
Webflow sprawdza się przy stronach marketingowych, w których zespół chce samodzielnie zmieniać wygląd. Trzeba jednak liczyć się z abonamentem i ograniczeniami przy bardziej złożonej logice.
Kreatory typu Wix pozwalają szybko wystartować, ale przy rozwoju projektu ograniczają kontrolę nad kodem i wydajnością. Traktuję je jako rozwiązanie na start, a nie na lata.
Sklepy internetowe: open source czy abonament
W e-commerce wybór sprowadza się do pytania, czy wolisz pełną własność i elastyczność, czy spokój w sprawach technicznych.
Platformy abonamentowe, takie jak Shoper, Sky-Shop, IdoSell czy Shopify, dają gotową infrastrukturę: hosting, płatności, integracje z kurierami i marketplace'ami, aktualizacje bezpieczeństwa. To dobry wybór na start i dla firm bez własnego działu IT. Ceną są ograniczenia w niestandardowych funkcjach, abonament rosnący wraz ze skalą i trudniejsza migracja.
Systemy open source, takie jak WooCommerce, PrestaShop czy Magento, pozwalają zbudować dowolną logikę sprzedaży, np. złożone cenniki B2B czy nietypowe konfiguratory. WooCommerce najlepiej łączy sprzedaż z rozbudowanym blogiem i content marketingiem, PrestaShop ma dużą bazę modułów i społeczność w Polsce, a Magento sprawdza się w największych sklepach z zespołem programistów. Wymagają jednak dobrego hostingu dobranego do projektu i stałej opieki technicznej.
Headless, czyli WordPress z Astro
Coraz częściej proponuję klientom architekturę headless, a konkretnie połączenie WordPressa jako panelu do zarządzania treścią z front-endem zbudowanym w Astro. Uważam ją dziś za jedno z najlepszych rozwiązań dla stron firmowych, blogów i serwisów contentowych. Redaktorzy pracują w panelu, który znają, a odwiedzający dostają szybkie strony generowane jako statyczny HTML, bez ładowania całego zaplecza WordPressa przy każdym wejściu.
Najważniejszym argumentem jest dla mnie bezpieczeństwo. W ostatnim czasie wyraźnie widzę, że ataki na strony są coraz bardziej zautomatyzowane, a narzędzia AI pozwalają atakującym szybciej wyszukiwać podatne wtyczki, generować warianty exploitów i skanować tysiące stron jednocześnie. W klasycznym WordPressie każda podatność we wtyczce jest dostępna dla każdego, kto odwiedzi stronę. W układzie headless publiczna strona to statyczne pliki, najczęściej serwowane z CDN, bez PHP i bazy danych po drodze. Panel WordPressa może działać na osobnej subdomenie, za listą dozwolonych adresów IP albo VPN, więc atakujący po prostu go nie widzi. Nawet jeśli w jednej z wtyczek pojawi się luka, nie ma jak jej wykorzystać z poziomu publicznej strony.
Taka architektura wymaga więcej pracy przy wdrożeniu: trzeba zbudować front-end, zaplanować przebudowę stron po publikacji treści i zadbać o podgląd dla redaktorów. W zamian projekt dostaje wydajność, której klasyczny motyw z kilkunastoma wtyczkami nie osiągnie, i dużo mniejszą powierzchnię ataku. Dla wielu firm to dziś najmocniejszy argument, żeby porzucić monolityczny CMS na rzecz headless.
Pułapki, które widzę najczęściej
- Wybór pod demo, a nie pod treści. Szablon wygląda świetnie na prezentacji, a po wprowadzeniu prawdziwych treści okazuje się, że system nie obsługuje potrzebnej struktury.
- Zmiany w rdzeniu systemu. Modyfikacje plików CMS-a zamiast pisania rozszerzeń blokują aktualizacje i są klasycznym źródłem długu technologicznego.
- Page buildery do wszystkiego. Wizualne kreatory przyspieszają start, ale generują ciężki kod i uzależniają treści od jednej wtyczki, której usunięcie oznacza przebudowę wszystkich podstron.
- Brak planu na migrację. Przy zmianie systemu zmieniają się adresy podstron. Bez mapy przekierowań i testów cała historia strony w Google zaczyna się od nowa, dlatego każdą zmianę CMS-a prowadzę jak pełną migrację strony.
Dobry CMS to nie ten, który ma najwięcej funkcji, tylko ten, który pasuje do zespołu, treści i planów firmy na kilka najbliższych lat. Warto przeanalizować to z deweloperem, zanim zostanie napisana pierwsza linijka kodu albo opłacona pierwsza rata abonamentu.