Kiedy strona albo sklep potrzebuje stałej opieki?
Aktualizacji nikt nie robi, bo ostatnia wyłożyła sklep, a od tamtej pory wtyczki czekają na „lepszy moment”.
Monitoring mówi „działa”, a zamówienia stoją.
W panelu jest konto z uprawnieniami, którego nikt nie pamięta, i nie wiadomo, od kiedy.
Kopia zapasowa robi się na tym samym dysku co sklep i pewnej nocy zajmuje całe wolne miejsce.
Alerty niby są skonfigurowane, ale nikt nie pamięta, kiedy ostatnio jakiś przyszedł.
Co obejmuje opieka nad WordPress i PrestaShop?
Aktualizacje z testem na kopii
WordPress, WooCommerce, PrestaShop, wtyczki, moduły i PHP najpierw na kopii sklepu. Na produkcję trafia wersja, która przeszła koszyk i zamówienie.
Kontrola kasy jak klient
Skrypt dodaje produkt do koszyka, otwiera kasę i sprawdza, jakie skrypty się na niej ładują. Pusta kasa przekierowuje do koszyka, więc bez produktu niczego by nie zobaczył.
Monitoring integralności plików
Sumy kontrolne treści plików, nie daty modyfikacji, bo te atakujący potrafi podrobić. Każdy nowy, zmieniony albo usunięty plik trafia do raportu.
Administratorzy i wtyczki
Konta liczymy po uprawnieniach, a nie po nazwie roli. Do tego nowe katalogi wtyczek, pliki PHP poza wtyczkami i motywem oraz kod JavaScript wstrzyknięty w bazę.
Alerty z testem dostarczenia
Alert idzie przez zewnętrzny serwer pocztowy, a jego wysyłkę testujemy przy uruchomieniu. Nierozwiązany problem przypomina o sobie co 6 godzin.
Kopie i miejsce na dysku
Kopie zapasowe strony i bazy, a obok kontrola wolnego miejsca. Logi i pliki tymczasowe kopii mają limity, zanim zapchają serwer.
Raport z prac
Co zaktualizowaliśmy, co wykrył monitoring i co z tym zrobiliśmy. Raport miesięczny jest w pakietach Premium i Business Pogotowia IT.
Jak aktualizujemy WordPress i PrestaShop?
W WordPressie zamykamy instalowanie i edycję plików z panelu (stałe DISALLOW_FILE_MODS i DISALLOW_FILE_EDIT), a aktualizujemy przez WP-CLI. Ktoś, kto przejmie konto administratora, nie wgra wtedy wtyczki przez przeglądarkę. Po aktualizacji porównujemy rdzeń i wtyczki z sumami kontrolnymi z wordpress.org, więc od razu widać, czy zmiana w plikach to nowa wersja, czy coś obcego.
Przed pierwszą aktualizacją sprawdzamy też samo narzędzie. W jednym sklepie zastaliśmy konfigurację WP-CLI wskazującą na inną kopię WordPressa niż ta, na której działał sklep. Każda aktualizacja i każde sprawdzenie sum trafiały w nie ten katalog. Sklep wyglądał na aktualny. Wyszło to dopiero w monitoringu, który pokazał 1232 nieaktualne pliki rdzenia.
W PrestaShop pliki rdzenia i modułów porównujemy z oficjalnym wydaniem tej samej wersji. Aktualizację sklepu, modułów i PHP robimy najpierw na kopii. Przy przejściu z 1.7 na 8 zaczynamy od motywu i modułów, bo to one decydują, czy sklep przeżyje nową wersję. Szybkością zajmujemy się osobno: optymalizacja WooCommerce i optymalizacja PrestaShop.
Dokumentacja: wp core verify-checksums i wp plugin verify-checksums (developer.wordpress.org).
Jak wygląda monitoring strony WWW i sklepu poza dostępnością?
Gdy na serwerze zabrakło miejsca, wszystkie strony zwracały błąd 521, a strona główna sklepu wciąż odpowiadała z cache Cloudflare. Sprawdzanie samej strony głównej by tego nie wykryło.
Dlatego kontrola sklepu działa jak klient: dodaje produkt do koszyka, otwiera kasę i sprawdza znaczniki skimmerów, nagłówek CSP i domeny zewnętrznych skryptów. Skrypty na kasie porównujemy z listą tych, które sklep ma prawo ładować, czyli bramki płatności, dostawy i analityki.
Monitoring tylko wykrywa i alarmuje. Niczego sam nie kasuje. Automatyczne usuwanie zatarłoby ślady, po których ustalamy, jak ktoś wszedł. Bazę sprawdzamy bezpośrednim zapytaniem SQL, a nie przez WordPressa, bo zainfekowana wtyczka mogłaby podmienić wynik. Więcej przykładów w artykule co monitorować w sklepie poza uptime.
Kontrole i ich częstotliwość w naszych wdrożeniach
| Co sprawdzamy | Jak często |
|---|---|
| Sygnatury złośliwego kodu, rdzeń WordPressa vs sumy z wordpress.org, nowe wtyczki, PHP poza wtyczkami i motywem, administratorzy, JS w bazie | co 10 minut (sklep WooCommerce w Dockerze) |
| Sumy MD5 treści plików: ok. 127 tys. plików w 4 katalogach (sklep PrestaShop i 3 strony na jednym serwerze) | co godzinę |
| Pliki WordPressa i WooCommerce po włamaniu, monitor w PHP z crona hostingu, baseline 42 814 plików | co 30 minut |
| Administratorzy, PHP w uploads, wtyczki i drop-iny, crontab | co godzinę |
| Sumy rdzenia, sygnatury w plikach zmienionych w ciągu doby, JS w bazie | raz dziennie |
| Wolne miejsce na dysku z progiem 20 GB | co 15 minut |
Częstotliwość dobieramy do sklepu i serwera. Na hostingu współdzielonym monitor działa z crona hostingu.
Scrapery cen i podejrzany ruch
W branżach, w których konkuruje się ceną, ktoś regularnie pobiera ceny ze sklepu. Wyłapujemy takie boty, blokujemy je i sprawdzamy, czy wyszukiwarki dalej widzą sklep.
W jednym sklepie klient podejrzewał, że konkurencja pobiera jego ceny. Logi to potwierdziły: serwer w centrum danych bez odwrotnego DNS, trzy własne nazwy User-Agent udające narzędzia do badań katalogu, ok. 1300 żądań. Bot pobierał tylko HTML, bez CSS i obrazków, ok. 20 razy na dobę każdą z 41 kart produktów, także między 2 a 5 w nocy. Żadnej z tych nazw nie było w publicznych bazach botów.
Blokujemy po User-Agencie regułą WAF w Cloudflare, z odpowiedzią 403 i opisem, jak ją zdjąć. Czwarty profil z tego samego adresu udawał pełną przeglądarkę. Jego nie zablokowaliśmy, bo wymagałoby to blokady IP, która mogłaby odciąć prawdziwych klientów. Jest pod obserwacją.
Po każdej regule sprawdzamy, kto nadal ma dostęp. Googlebota i bingbota rozpoznajemy po odwrotnym i prostym DNS, a nie po nazwie, bo nazwę może wpisać każdy. Do tego test na żywo w Google Search Console i kontrola Merchant Center. Fałszowania cen dla scrapera nie wdrażamy. Cena siedzi w kilku miejscach strony, w tym w danych dla Google, a podmiana grozi problemami z Merchant Center i z przepisami o cenach. Więcej w artykule jak zablokować scraper cen bez utraty Google.
Test po wdrożeniu blokady
| Kto pyta o stronę | Odpowiedź |
|---|---|
| User-Agenty scrapera | 403 |
| Chrome na komputerze i iPhone | 200 |
| Googlebot i bingbot | 200 |
Te same zapytania powtarzamy po każdej zmianie reguł WAF.
Jak wygląda pierwszy miesiąc opieki?
Przegląd na start
Wersje, wtyczki, moduły, kopie zapasowe, wolne miejsce, konta administratorów i skrypty na stronie kasy. Pliki porównujemy z oficjalnymi wydaniami.
Stan odniesienia
Zapisujemy stan plików i kont, gdy sklep jest czysty. Od tej chwili alert przychodzi tylko na nowe pozycje, a nie na wszystko, co było wcześniej.
Alerty i test wysyłki
Uruchamiamy kontrole i wysyłamy próbny alert. Dopóki nie dojdzie, monitoringu nie uznajemy za działający.
Stała praca
Testowane aktualizacje, reakcja na alerty, porządek na dysku i raport z prac.
Co wyłapał monitoring?
Bez nazw klientów, bo to ich dane.
Sytuacje z ostatnich miesięcy
| Sytuacja | Co się okazało |
|---|---|
| Serwer ze sklepem i kilkoma stronami, kontrola sum co godzinę | monitoring wykrył dropper na sąsiedniej stronie z tego samego serwera, nie w samym sklepie |
| Alert wysyłany przez lokalną pocztę serwera | lokalna poczta nie dostarczała wiadomości na zewnątrz; alerty wysyłamy przez zewnętrzny serwer pocztowy i testujemy ich dostarczenie |
| Sklep WooCommerce, cztery awarie przez pełny dysk | log integratora ERP urósł do 5,5 GB, kopia zapasowa pocięła uploads na 129 plików po 400 MB, innym razem 49,5 GB plików tymczasowych kopii |
| Pełny dysk na serwerze z kilkoma stronami | błąd 521 dla wszystkich stron na serwerze, a strona główna sklepu wciąż odpowiadała z cache Cloudflare |
| Sklep WooCommerce, audyt 1.10.2026 | czysto: 42 wtyczki z wordpress.org zgodne z sumami kontrolnymi |
Opieka w abonamencie Pogotowia IT
Opiekę nad WordPressem, WooCommerce i PrestaShop prowadzimy w abonamencie Pogotowia IT. Pakiet Standard kosztuje 1 100 zł miesięcznie, ma 5 godzin pracy i reakcję do 24 h. Premium i Business mają krótszy czas reakcji, proaktywny monitoring strony i raport miesięczny. W każdym pakiecie są monitoring dostępności, powiadomienia o awariach i kopie zapasowe strony. Umowa jest na czas nieokreślony z miesięcznym wypowiedzeniem.
Jeśli strona jest już zainfekowana, zaczynamy od usuwania malware, a opieka przejmuje sklep po czyszczeniu, z zapisanym czystym stanem plików.
Najczęstsze pytania o opiekę nad WordPress i PrestaShop
Opisz stronę albo sklep, którym mamy się zająć
Współpracowałam z Kamilem przy kodowaniu Landing Pages. Mogę polecić go z uwagi na jego otwartość, chęć rozwoju współpracy i wytrzymałość na moją perfekcję pikselową
Współpraca z ASAPDevs przebiega bardzo profesjonalnie. Zleciliśmy przeniesienie naszego sklepu internetowego na nową platformę i cały proces przebiegł bardzo sprawnie. Specjaliści bez problemu wdrażają wszystkie modyfikacje.