WordPress czy strona dedykowana: osiem pytań przed decyzją

WordPress czy strona dedykowana — pytanie brzmi tak, jakby rozstrzygała je wielkość firmy albo budżet, a rozstrzygają dwie zupełnie inne rzeczy: kto realnie utrzymuje stronę i jak często zmienia się jej treść. Każdy wykonawca odpowie na to pytanie po swojemu, bo poleca to, co sam robi najczęściej. Poniżej znajdziesz osiem pytań rozstrzygających, na które odpowiadasz sam, zanim wejdziesz do rozmowy — przy każdym napisane jest wprost, co dana odpowiedź oznacza dla wyboru platformy.

Co naprawdę rozstrzyga wybór platformy

O platformie decyduje model utrzymania, a nie skala biznesu. Trzy warianty, które porównujemy w tym tekście, to: gotowy CMS instalowany na własnym hostingu (WordPress i podobne), strona kodowana pod konkretny projekt oraz platforma abonamentowa, w której oprogramowanie i serwer należą do dostawcy.

Różnią się nie „jakością”, tylko tym, gdzie leży odpowiedzialność. W gotowym CMS-ie masz pełną kontrolę nad kodem i pełną odpowiedzialność za aktualizacje. W stronie kodowanej masz kontrolę nad tym, co trafia do przeglądarki, ale każda zmiana funkcji przechodzi przez wykonawcę. W platformie abonamentowej dostawca zdejmuje z Ciebie utrzymanie i w zamian ogranicza to, co możesz zmienić.

Jeśli budżet jest dziś najostrzejszym ograniczeniem — firma dopiero rusza, a strona ma być czytelną wizytówką z formularzem kontaktowym — rozsądniej zacząć od gotowej strony dla nowej firmy i wrócić do tego wyboru wtedy, gdy pojawią się realne wymagania, a nie wyobrażone.

Pytania 1-4: kto codziennie pracuje na tej stronie

1. Kto będzie edytował treść i jak często

Jeśli odpowiedź brzmi „osoba nietechniczna, kilka razy w miesiącu”, panel redakcyjny jest wartością, a nie ozdobą — idziesz w stronę gotowego CMS-a albo strony kodowanej z podpiętym CMS-em headless. Jeśli brzmi „raz na kwartał, i tak przez wykonawcę”, panel jest kosztem utrzymania, aktualizacji i kolejnym wektorem ataku, za który płacisz bez zwrotu.

2. Ile integracji z systemami zewnętrznymi jest w grze

Zero albo jedna typowa integracja (formularz do skrzynki, newsletter, płatności) mieści się we wtyczkach gotowego CMS-a i nie jest argumentem za niczym. Trzy i więcej — a zwłaszcza integracja z własnym ERP, magazynem, systemem rezerwacji albo CRM-em — oznacza, że sercem projektu jest wymiana danych, nie warstwa graficzna. Wtedy o platformie decyduje to, jak wygodnie da się w niej pisać własny kod integracyjny i utrzymywać go przy aktualizacjach.

3. Kto odpowiada za aktualizacje bezpieczeństwa i w jakim trybie

Jeśli nie umiesz wskazać imienia i okna czasowego („w ciągu 48 godzin od wydania poprawki”), wybierasz rozwiązanie, w którym aktualizacje robi ktoś inny: platformę abonamentową albo umowę utrzymaniową z wykonawcą. Odpowiedź „zainstalujemy i jakoś będzie” to w praktyce decyzja o tym, że po roku strona będzie działać na nieaktualnych komponentach — niezależnie od platformy.

4. Ile podstron realnie powstanie i czy będą rosły

Kilkanaście stałych podstron o ustalonej treści to sytuacja, w której baza danych i panel redakcyjny nie zarabiają na siebie. Setki wpisów, kategorie, filtrowanie, wielu autorów i treść dopisywana co tydzień to sytuacja odwrotna — potrzebujesz modelu treści i panelu, a pytanie zawęża się do tego, czy panel ma być zintegrowany z warstwą wyświetlaną, czy oddzielony.

Pytania 5-8: co się stanie z tą stroną za dwa lata

5. Czy platforma domyślnie generuje dostępny kod

Odpowiedź brzmi zawsze „częściowo” — żadna platforma sama z siebie nie jest zgodna z WCAG, bo zgodność zależy od implementacji i od treści, którą wpisujesz. Pytanie praktyczne dotyczy więc kontroli: czy możesz zmienić strukturę nagłówków, etykiety pól i kolejność fokusa bez walki z motywem. Wymagania i poziom odniesienia opisuje osobno tekst o dostępności strony w kontekście European Accessibility Act, a standardem technicznym przywoływanym przy zgodności unijnej jest EN 301 549, który w warstwie webowej odsyła do WCAG na poziomie AA.

6. Jak wygląda kontrola nad strukturą adresów i danymi strukturalnymi

Jeśli nie możesz zmienić wzorca adresów bez wtyczki albo bez zgłoszenia do dostawcy, każda przyszła zmiana architektury informacji staje się projektem migracyjnym z przekierowaniami — a to osobna operacja, którą opisuje poradnik o migracji strony bez utraty pozycji. Sprawdź też, czy dane strukturalne (produkt, artykuł, firma lokalna) da się edytować na poziomie szablonu, czy tylko przez pola dodane przez wtyczkę.

7. Jaki jest koszt wyjścia i czy da się wyeksportować dane

To pytanie zadaje się najrzadziej, a jego skutki są najdroższe — dlatego ma niżej własną sekcję. Na tym etapie wystarczy jedno rozstrzygnięcie: czy potrafisz dziś wymienić format, w jakim odzyskasz treść, media i dane klientów.

8. Kto będzie utrzymywał tę stronę za dwa lata

Odpowiedź „ta sama agencja, mamy umowę” otwiera drogę do rozwiązań mniej popularnych, bo ryzyko przejęcia kodu przez kogoś innego jest niskie. Odpowiedź „nie wiem” albo „wewnętrzny zespół, którego jeszcze nie ma” zawęża wybór do technologii z dużym rynkiem wykonawców i publiczną dokumentacją. Jeśli chcesz, żeby wykonawcy odpowiadali na te osiem pytań porównywalnie, wpisz je do dokumentu — jak go zbudować, opisuje tekst o briefie dla software house’u.

Trzy warianty w tabeli: co realnie różni platformy

Wolna strona: co jest po stronie serwera, a co po stronie przeglądarki

Rozdzielenie tych dwóch warstw zmienia diagnozę i koszt naprawy, dlatego zrób je przed decyzją o platformie. Po stronie serwera dzieje się czas do pierwszego bajtu, generowanie HTML, zapytania do bazy i cache. Po stronie przeglądarki — pobieranie i wykonywanie JavaScriptu, waga obrazów, fonty, skrypty firm trzecich (czaty, piksele analityczne, banery zgód) i przesuwanie się układu podczas ładowania.

Konsekwencja jest prosta: mocniejszy hosting poprawia wyłącznie pierwszą grupę. Jeśli stronę spowalniają skrypty zewnętrzne i obrazy, migracja na szybszy serwer — albo na inną platformę — nie zmieni wyniku, bo problem przenosi się razem z treścią. Zmierz obie warstwy narzędziami, które i tak masz pod ręką: PageSpeed Insights, Lighthouse, Chrome DevTools, Google Search Console, biblioteka web-vitals i WebPageTest.

Same progi metryk i to, że ocena powstaje z danych polowych CrUX w ruchomym oknie 28 dni, na 75. percentylu i osobno dla urządzeń mobilnych i desktopu, opisuje artykuł o Core Web Vitals.

Koszt wyjścia i eksport danych: pytanie zadawane najrzadziej

Koszt wyjścia to suma pracy potrzebnej, żeby przenieść serwis na inną platformę bez utraty treści, danych klientów i adresów. Liczy się nie „czy jest eksport”, tylko co dokładnie obejmuje. Treść stron, obrazy w oryginalnych rozdzielczościach, produkty z wariantami, zamówienia, konta klientów, opinie, mapowanie starych adresów na nowe — każdy z tych zbiorów bywa osobnym przypadkiem.

W polskim e-commerce różnica jest widoczna gołym okiem. W rozwiązaniach instalowanych u siebie, jak WooCommerce, PrestaShop czy Magento (Adobe Commerce), masz dostęp do bazy i plików. W modelu abonamentowym — Shoper, IdoSell, Shopify, Sky-Shop, Selly, AtomStore — dostajesz to, co dostawca udostępnia w panelu i przez API. Oba modele są używane przez duże sklepy; różnią się tym, ile kosztuje odejście. Cały wybór, sklep na abonament czy dedykowany, rozkłada się na sześć kryteriów, które bolą dopiero w trzecim roku działania.

Odpowiedź „napiszemy skrypt, jak przyjdzie czas” jest odpowiedzią negatywną. Odpowiedź konkretna wymienia formaty i zakres, i da się ją wpisać do umowy.

Kiedy optymalizacja istniejącego WordPressa jeszcze się opłaca

Opłaca się, dopóki poprawki są trwałe — czyli nie cofa ich aktualizacja motywu ani wtyczki. Typowe sytuacje po tej stronie progu: motyw klasyczny lub lekki, wtyczek kilkanaście i każdą umiesz uzasadnić, hosting da się podnieść w ramach tej samej umowy, a lista problemów to nieskompresowane obrazy, brak cache i cztery skrypty marketingowe, z których dwa są martwe.

Problemem jest architektura, gdy: układ powstaje w edytorze typu page-builder generującym zagnieżdżone kontenery, których nie da się uprościć bez przebudowy szablonu; wtyczek jest kilkadziesiąt i ich zakresy się nakładają; część nie ma aktualizacji od dawna; każda poprawka wydajności wymaga obejścia, a wynik znika po najbliższej aktualizacji. W tym układzie koszt utrzymania rośnie w sposób nieprzewidywalny, a przebudowa daje policzalny zakres prac.

Sam WordPress nie jest tu winowajcą — ta sama diagnoza dotyczy strony kodowanej, w której przez trzy lata dokładano skrypty bez rewizji. Próg wyznacza odwracalność zmian, nie nazwa platformy.