Krótka odpowiedź: sklep ma cenę uruchomienia i koszt posiadania — a ten drugi łatwo przeoczyć. 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
Częsty schemat składa się z kroków, które z osobna wyglądają rozsądnie. 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 900–1500 € rocznie wyłącznie za prawo do dalszego korzystania z tego, co już masz.
Sześć zasad higieny
-
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.
-
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.
-
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.
-
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.
-
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.
-
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, może usunąć dużą część problemów i się zwrócić. 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ń.