Krótka odpowiedź: sklep ma cenę uruchomienia i koszt posiadania — i o tym drugim prawie nikt nie uprzedza. Składają się na niego wtyczki, licencje, aktualizacje, konflikty i godziny potrzebne, żeby to wszystko dalej działało. Z czasem ten koszt rośnie, a zdolność do wprowadzania zmian maleje.
Jak to się kumuluje
Mechanika jest niemal wszędzie taka sama i każdy krok z osobna jest rozsądny. Potrzebny kalkulator dostawy — instalujemy wtyczkę. Potrzebne opinie — kolejną. Filtry, plakietki „bestseller”, eksport do marketplace, popup z newsletterem, czat, kreator landingów — wtyczki, wtyczki, wtyczki. Każda pojedyncza decyzja zajmuje godzinę i kosztuje grosze.
Dwa lata później sklep ma 40 wtyczek, z czego jedna trzecia jest nieużywana, połowa reszty dubluje swoje funkcje, a dwie zostały porzucone przez autorów. Nikt nigdy nie zdecydował „skomplikujmy to”; złożoność narosła sama, po jednym rozsądnym kroku naraz.
Czym za to płacisz
Szybkością. Każda wtyczka dokłada zapytania do bazy oraz własny CSS i JS na każdą stronę. To bezpośrednia strata konwersji.
Bezpieczeństwem. Wtyczki są głównym wektorem ataków na strony WordPress. Podatność w jednym popularnym rozszerzeniu dotyka setek tysięcy witryn naraz, a atakujący skanują je masowo. Dla sklepu ceną włamania jest nie tylko przestój, ale i dane klientów wraz ze wszystkimi konsekwencjami prawnymi.
Możliwością aktualizacji. Znajoma sytuacja: aktualizacja WooCommerce psuje zgodność z wtyczką, autor milczy, a sklep zostaje na starej wersji. Potem nie da się zaktualizować PHP, potem WordPressa, a rok później masz stos, którego nikt nie chce dotknąć.
Tempem zmian. Proste zadanie w rodzaju „dodać pole w checkoucie” zamienia się w śledztwo: która z czterech wtyczek checkoutu za to odpowiada i co się zepsuje. To dokładnie to uczucie „dlaczego taki drobiazg zajmuje dwa dni”.
Pieniędzmi wprost. Piętnaście wtyczek premium po 60–100 € rocznie to 1000–1500 € rocznie wyłącznie za prawo do dalszego korzystania z tego, co już masz.
Sześć zasad higieny
1. Audyt wtyczek dwa razy w roku. Dla każdej: czy jest używana? czy da się ją zastąpić jedną funkcją w motywie? czy autor wydał aktualizację w ostatnim roku? Wszystko, co nie przechodzi, zostaje usunięte. Nie zdezaktywowane — usunięte, razem z tabelami.
2. Nic nie zmienia się bezpośrednio na produkcji. Kopia staging to nie luksus, tylko warunek. Aktualizacja wtyczki koszyka w piątek wieczorem na żywym sklepie to obstawianie własnym przychodem.
3. Kopie zapasowe sprawdzone odtworzeniem. Backup, którego nigdy nie przywracano, nie jest backupem, tylko nadzieją. Raz na kwartał warto go odtworzyć na stagingu i upewnić się, że sklep wstaje.
4. Aktualizacje według harmonogramu, nie w panice. Raz w miesiącu: staging → aktualizacja → sprawdzenie kluczowych ścieżek (zamówienie, płatność, maile) → produkcja. Nudno i przewidywalnie, czyli dokładnie tak, jak trzeba.
5. Minimalizm domyślnie. Przed instalacją wtyczki pytanie: czy da się to zrobić dwudziestoma liniami w motywie? Często się da, a wtedy jest to tańsze w utrzymaniu na lata.
6. Dokumentuj rzeczy niestandardowe. Jeden plik opisujący, które wtyczki są krytyczne, co ustawiono ręcznie i gdzie jest własny kod. To właśnie odróżnia sklep, który można przekazać innemu wykonawcy, od sklepu trzymającego Cię jako zakładnika.
Trzy scenariusze wyjścia, gdy dług jest już duży
Scenariusz 1: sprzątanie. Usunąć nieużywane, zastąpić jednorazowe wtyczki kodem, przywrócić porządek w aktualizacjach. Jeden–dwa tygodnie, usuwa większość bólu i prawie zawsze się zwraca. Od tego się zaczyna — pozostałe warianty bez tego kroku po prostu przenoszą chaos w nowe miejsce.
Scenariusz 2: przepisanie szablonów. Zrezygnować z motywu-kreatora i zbudować potrzebne szablony wprost. Trudniejsze, ale usuwa główne źródło wagi i czyni sklep przewidywalnym. Uzasadnione, gdy design jest w porządku, a szybkość nie.
Scenariusz 3: rozdzielenie witryny i backendu. WooCommerce zostaje systemem ewidencji — produkty, zamówienia, płatności, panel, który zespół już zna — a witryna powstaje osobno. Szybkość przestaje zależeć od wtyczek, a zmiany we frontendzie przestają zagrażać zamówieniom. Kiedy to się opłaca, a kiedy nie, opisuje strona WooCommerce i headless; gotową wersją takiego przejścia jest NextWoo.
Jeśli sklep stoi na platformie, która naprawdę się wyczerpała, to osobna rozmowa: migracja strony lub CMS.
Wstawka dla programisty
- Inwentaryzacja z faktów, nie z pamięci. Lista wtyczek plus data ostatniej aktualizacji autora plus miejsce faktycznego użycia. Wtyczka bez wywołań w szablonach to kandydat do usunięcia.
- Poszukaj pozostałości po usuniętych wtyczkach. Wiersze w
wp_optionszautoload='yes', osierocone pola meta, zadania cron wskazujące na nieistniejący kod. - Oddziel własny kod od motywu. Funkcjonalność do osobnej wtyczki, prezentacja do motywu. Inaczej aktualizacja albo zmiana motywu zabierze ze sobą logikę biznesową.
- Przypnij wersje i trzymaj środowiska identyczne. Różnica wersji PHP między stagingiem a produkcją unieważnia całe testowanie.
- Śledź podatności automatycznie. Subskrypcja bazy podatności wtyczek jest tańsza niż dowiadywanie się o problemie od klientów. Praktyki bezpieczeństwa opisuje usługa bezpieczeństwo aplikacji webowych, a podstawowe wskazówki wydajnościowe — dokumentacja WordPressa i WooCommerce Developer Docs.
- Loguj błędy na produkcji. Sklep, w którym nikt nie zagląda do logów, dowiaduje się o zepsutej płatności od klienta — dzień później i w opinii.
Praktyczny test
- Spisałem wszystkie wtyczki z datą ostatniej aktualizacji autora
- Usunąłem nieużywane razem z ich danymi
- Istnieje kopia staging i zmiany idą przez nią
- Backup był odtwarzany i sprawdzony w ostatnich 3 miesiącach
- Aktualizacje idą według harmonogramu, a nie „gdy coś się zepsuje”
- Znam roczną sumę licencji
- Istnieje dokument opisujący modyfikacje
- PHP i WordPress są na wspieranych wersjach
Zbiorczy plan na 90 dni
Na zamknięcie całego przewodnika — kolejność prac, którą zaproponowałbym niemal każdemu sklepowi:
Tygodnie 1–2. Zmierzyć. Zebrać pięć liczb lejka, uzgodnić analitykę z panelem, zdjąć Core Web Vitals, przeczytać raport pustych zapytań. Jeszcze niczego nie naprawiać — tylko ustalić, gdzie się rwie. Zobacz diagnostykę lejka i analitykę.
Tygodnie 3–5. Checkout. Zakup bez konta, uczciwy koszt dostawy z góry, mniej pól, porządny formularz mobilny, metody płatności. Najszybszy zwrot z listy — koszyk i checkout.
Tygodnie 6–8. Szybkość i karta produktu. Zdjęcia, cache, fragmenty koszyka; na karcie termin dostawy, dostępność, tabela rozmiarów, opinie. Zobacz szybkość i kartę produktu.
Tygodnie 9–10. Widoczność i zaufanie. Filtry poza indeksem, obsługa produktów niedostępnych, znaczniki, kontakty i warunki zwrotu: błędy SEO i zaufanie.
Tygodnie 11–12. Drugi zakup. Sekwencja posprzedażowa, segmenty, reaktywacja — retencja i LTV.
Równolegle, w tle. Sprzątanie wtyczek, staging, backupy, aktualizacje.
Po 90 dniach nie będziesz mieć „nowej strony”. Będziesz mieć sklep, o którym wiesz dokładnie, gdzie tracisz pieniądze — i w którym traci się ich zauważalnie mniej.
Jeśli potrzebujesz kogoś, kto poprowadzi ten plan za Ciebie: optymalizacja konwersji, przyspieszenie strony albo wsparcie i rozwój produktu — w zależności od tego, co pokazał pierwszy tydzień.