Audyt sklepu WooCommerce wyposazenie24.pl

Sklep

wyposazenie24.pl, sprzedaż w Polsce

Asortyment

wyposażenie gastronomii (4 574 z 7 330 produktów), warsztat i garaż, dom i ogród, elektronarzędzia, wagi, chemia przemysłowa i inne

Model sprzedaży

dropshipping: produkty, ceny i stany importowane z pliku hurtowni

Platforma

WordPress 6.8.1, WooCommerce 9.9.3, PHP 8.3

Motyw

Porto 7.5.3 z motywem potomnym Porto Child 1.1

Wtyczki

35, w tym 32 aktywne

Serwer

hosting współdzielony, serwer LiteSpeed

Okres działania

09.2024-29.07.2026; domena wygasła 06.09.2026

Audyt

23.09.2026, wariant podstawowy

Raport przykładowy wariantu podstawowego. Sklep należał do wykonawcy audytu. Do audytu przywrócono go 23.09.2026 z kopii plików i bazy na tym samym serwerze, na osobnym adresie za hasłem, z zanonimizowanymi danymi klientów (dalej: kopia audytowa). Raport opisuje stan sklepu w chwili wyłączenia; pomiary wydajności pochodzą z kopii audytowej.

Wszystkie odstępstwa od zwykłego audytu są opisane w ostatniej części raportu. Przy każdym problemie stoi rekomendacja naprawy: wskazówka, co zmienić, bez instrukcji krok po kroku.

Priorytety w całym raporcie: krytyczny kosztuje zamówienia teraz albo otwiera sklep na atak; wysoki hamuje sprzedaż albo podnosi koszt utrzymania; średni to porządek i higiena; niski nie wpływa na zamówienia. Priorytety podano tak, jakby sklep działał. Sklep jest wyłączony, więc dziś realne ryzyko mogą stwarzać tylko klucze usług zapisane w jego plikach i bazie (punkt 3.4); pozostała kolejność dotyczy sklepu, który miałby wrócić do sprzedaży.

1. Skrót

Kasa działała bez typowych przeszkód, ale od czerwca 2025 r. sklep sprzedawał ofertę, której nie znał: import stanów z hurtowni zatrzymał się 15.06.2025 i nie został wznowiony do końca działania sklepu. Telefony dostawały wolniejszy sklep niż komputery, aktualizacje nie miały jak przyjść, a ostrzeżenia zapory nie trafiały do nikogo.

Dlaczego sprzedaż nie działała tak, jak mogła. Sama kasa nie odstraszała; sprzedaż hamowały rzeczy przed nią. Klient mógł zamówić jeden z 1 095 produktów, których hurtownia nie miała, i dostać anulowanie zamiast paczki; nie widział 580 produktów, które mógł kupić; na telefonie każda strona kategorii i produktu czekała na serwer. Porzuconych koszyków w wariancie podstawowym nie da się policzyć.

Co zrobić najpierw. Pełna lista z priorytetami i tym, kto wykonuje: rozdział 7, Co poprawić, w jakiej kolejności.

1. 01Zaktualizować WordPress do 6.8.10 i usunąć z katalogu strony repozytorium kodu oraz spisy plików po kopiowaniu przez FTP.
2. 02Wznowić import stanów z hurtowni, z powiadomieniem o każdym nieudanym przebiegu.
3. 03Przywrócić pamięć podręczną dla telefonów i wyłączyć tryb gościa we wtyczce LiteSpeed Cache.
4. 04Usunąć klucz OpenAI z kodu wtyczki i odwołać pozostałe klucze usług zapisane w sklepie.
5. 05Zaplanować aktualizację wtyczek i WooCommerce jako osobny projekt z testem na kopii sklepu.

Czego audyt nie objął: zachowań klientów (wariant rozszerzony; sklep bez ruchu), treści i pozycjonowania, zgodności prawnej, dostarczalności poczty, kopii zapasowych po stronie hostingu oraz pięciu wtyczek, których nie ma w publicznych bazach luk.

2. Wydajność

2.1 Pomiar

Lighthouse 12.8.2 w przeglądarce Chromium na komputerze audytora, profil telefonu i komputera, ograniczenie łącza i procesora symulowane (ustawienia domyślne), trzy przebiegi na stronę, mediana; 23.09.2026 13:30-13:54 UTC+2. PageSpeed Insights nie był możliwy, bo kopia audytowa jest za hasłem; porównanie tego zestawu z PageSpeed Insights na stronie publicznej (telefon: różnica kilku punktów w granicach rozrzutu, komputer: ten sam wynik) jest w „Warunkach audytu i odstępstwach".

Pamięć podręczna stron jest na kopii wyłączona (odpowiadała przed sprawdzeniem hasła), więc każdy pomiar pokazuje stronę wygenerowaną przez PHP. Dla telefonów to jest zwykły stan sklepu (punkt 2.2), dla komputera stan przy pierwszym wejściu po wyczyszczeniu pamięci podręcznej. Koszyk mierzono pusty.

¹ Zdjęcia na kopii audytowej pochodzą z plików na serwerze i z pliku hurtowni, część odpowiada błędem 404, bo zasobnik ze zdjęciami sklepu przestał działać razem z domeną. Waga i LCP stron ze zdjęciami nie opisują sklepu. Przesunięcie układu (CLS) na wszystkich stronach 0-0,043, czyli w normie.

Czas odpowiedzi serwera, seria curl z komputera audytora (strona główna i produkt, profil telefonu i komputera, 10 próbek, UTC+2: dziewięć 23.09.2026 w godz. 14:12-22:32 co 53-68 minut, dziesiąta 24.09.2026 w godz. 08:39-08:43):

Mediana, najkrótszy i najdłuższy czas liczone z żądań wysłanych 1-2 minuty po poprzednim, 7-8 na wiersz. Ostatnia kolumna to pierwsze żądanie próbki, po 38-64 minutach bez ruchu na kopii (w dziesiątej próbce po 10 godzinach, pierwsze żądanie tego dnia).

Dla porównania strona podana z pamięci podręcznej: 0,061 s (główna) i 0,062 s (produkt), pomiary pojedyncze 23.09.2026 13:17-13:19 UTC+2, zanim pamięć podręczną na kopii wyłączono. Pierwsze wejście po kilkunastu minutach bez ruchu trwało 3,28 s (14:05 UTC+2) i 3,64 s (13:17 UTC+2, pierwsze żądanie po uruchomieniu kopii).

2.2 Telefony nie dostają stron z pamięci podręcznej ani kodu po optymalizacji priorytet: wysoki

Wtyczka LiteSpeed Cache 7.1 ma włączoną osobną pamięć dla telefonów. Działa to tylko wtedy, gdy w pliku .htaccess stoi jej reguła oznaczająca żądania z telefonów. Bez tej reguły wtyczka oznacza każde żądanie z telefonu jako niepodlegające pamięci podręcznej (kod wtyczki: src/control.cls.php, linie 738-758), a strona niepodlegająca pamięci podręcznej nie przechodzi też optymalizacji plików CSS i JS.

Kopia pliku .htaccess z 22.06.2025 ma tę regułę; plik działający do wyłączenia sklepu (ostatnia zmiana 04.09.2025, przy konfiguracji zapory Wordfence) już jej nie ma. Na tym samym serwerze i z tymi samymi regułami kopia audytowa odpowiada tak (23.09.2026 14:09-14:10 UTC+2):

• profil komputera: nagłówek x-litespeed-cache-control: public,max-age=604800, 57 plików CSS z katalogu optymalizacji wtyczki, w kodzie strony adnotacja wtyczki o optymalizacji i zapisie do pamięci;
• profil telefonu: x-litespeed-cache-control: no-cache i cache-control: no-cache, no-store, 57 oryginalnych plików CSS, adnotacja „Page uncached".

Skutki na telefonie: każda strona kategorii i produktu jest generowana od nowa (czasy w punkcie 2.1); Lighthouse widzi 9-12 plików blokujących pierwsze wyświetlenie wobec 2-8 na komputerze i szacuje, że usunięcie ich z tej drogi skróci pierwsze wyświetlenie treści o 1,7-2,15 s; nagłówek no-store wyłącza przeglądarce pamięć stron, więc powrót przyciskiem „wstecz" z produktu do kategorii pobiera i generuje kategorię od nowa.

2.3 Każdy nowy odwiedzający wczytuje pierwszą stronę dwa razy priorytet: wysoki

W LiteSpeed Cache włączony jest tryb gościa. Przeglądarka bez ciasteczka wtyczki dostaje stronę, po czym skrypt wtyczki pyta serwer o ciasteczko i przeładowuje stronę (kod: lib/guest.cls.php, linie 49-81, i assets/js/guest.min.js). Przeglądarki przedstawiające się jako narzędzia pomiarowe (Lighthouse, GTmetrix, Google, Pingdom, roboty) są z tego wyłączone, więc testy tego nie pokazują.

Potwierdzenie w pomiarze: dwa pierwsze przebiegi Lighthouse, jeszcze bez ciasteczka wtyczki, wczytały dokument strony dwa razy, razem z zapytaniem o ciasteczko; po jego ustawieniu kolejne przebiegi wczytywały stronę raz. Pierwsze wejście z reklamy albo z wyszukiwarki to więc dwa pełne wczytania, na telefonie oba generowane przez serwer.

2.4 Cache obiektowy ustawiony, ale nie działa priorytet: wysoki

W LiteSpeed Cache wybrany jest cache obiektowy Redis, ale w katalogu wp-content nie ma pliku object-cache.php, bez którego WordPress go nie używa. Na koncie hostingu rozszerzenie PHP redis jest załadowane i jest katalog usługi Redis (odczyt z serwera 23.09.2026). Bez cache obiektowego strony poza pamięcią podręczną (telefony, koszyk, kasa, konto) za każdym razem wykonują pełen zestaw zapytań do bazy. Czy usługa Redis działa i jaki ma limit pamięci, rozstrzygnie test połączenia w ustawieniach wtyczki.

2.5 Waga kodu strony priorytet: wysoki, projekt

Strona produktu na telefonie bez zdjęć to 148 plików i ok. 1,26 MB: skrypty 575 KB (59 plików), fonty 393 KB (24), style 246 KB (61), HTML 47 KB. Na każdej stronie ładuje się 56-61 plików CSS i 50-60 plików JS; Lighthouse wskazuje 134-158 KB nieużywanego CSS i 74-168 KB nieużywanego JS na stronę. Dwa pliki ikon Font Awesome ważą razem 254 KB i ładują się wszędzie.

Fonty przychodzą z serwerów Google (8-9 plików) i dodatkowo z lokalnych kopii Elementora (Roboto, Poppins, Roboto Slab); na kopii audytowej kolejne 9-11 plików fontów wskazuje starą domenę i się nie wczytuje, więc w sklepie fontów było więcej. Największy pojedynczy skrypt to Google Tag Manager (172 KB).

Skrypt banera zgody (CookieYes, 34 KB) blokuje wyświetlenie każdej strony: ok. 1,07 s w symulacji telefonu i ok. 0,26 s na komputerze. Wtyczka wstawia go jako pierwszy skrypt celowo, żeby mogła zatrzymać inne skrypty przed zgodą, więc nie należy go odraczać; zysk da dopiero przegląd narzędzia zgody. Strony mają 1 266-2 927 elementów, a przetwarzanie na telefonie zajmuje procesorowi 1,7-3,1 s.

2.6 Pozostałe

• Brak reguł pamięci przeglądarki dla plików statycznych priorytet: średni: Lighthouse znajduje 106-121 plików na stronę bez długiego czasu przechowywania. Blok tych reguł zniknął z .htaccess razem z blokiem z punktu 2.2.
• Zdjęcie największego elementu strony głównej na telefonie ma atrybut loading="lazy" priorytet: średni, więc przeglądarka pobiera je później, niż mogłaby.
• Zapytania o koszyk przy każdej stronie priorytet: średni: wtyczka koszyka bocznego (Side Cart WooCommerce 2.6.6) po wczytaniu każdej strony pyta serwer o zawartość koszyka, także gdy koszyk jest pusty; na stronie głównej, w koszyku i na stronie potwierdzenia drugie takie zapytanie wysyła WooCommerce. To zapytania POST, których pamięć podręczna stron nie obsługuje, więc nawet strona podana z pamięci kosztuje serwer jedno albo dwa wywołania PHP. Na kopii audytowej trwały 0,18-1,0 s (mediana 0,26 s, 30 zapytań w czterech przejściach ścieżki zakupu), najdłużej przy pierwszym wejściu na komputerze.

Czego nie sprawdzono: wyników PageSpeed Insights z serwerów Google (kopia za hasłem); danych z prawdziwych urządzeń (Chrome UX Report, Search Console; domena wygasła); wagi i formatu zdjęć sklepu (zasobnik niedostępny); trafień w pamięć podręczną przy ruchu (jedna para pomiarów); zachowania pod obciążeniem; zapytań do bazy na poszczególnych stronach.

3. Bezpieczeństwo

3.1 Wersje i opublikowane luki priorytet: krytyczny dla rdzenia, wysoki dla wtyczek

WordPress 6.8.1 (aktualna poprawka tej linii: 6.8.10, najnowsza wersja: 7.1.2), WooCommerce 9.9.3 (najnowsza 11.1.2), PHP 8.3 (tylko poprawki bezpieczeństwa, do 31.12.2027). Przegląd publicznych baz luk (Wordfence, Patchstack, WPScan, NVD, GitHub Security Advisories) wobec zainstalowanych wersji 38 składników (35 wtyczek, rdzeń, motyw Porto, PHP), stan 23.09.2026, bez żadnych żądań do sklepu: 92 luki w 19 składnikach, 14 składników bez znanych luk dla tej wersji, 5 nie do sprawdzenia (brak w publicznych bazach: wtyczki płatne, pisane na zamówienie albo mało znane). Pasma CVSS: krytyczne 2, wysokie 27, średnie 55, niskie 8. Bez logowania do wykorzystania 45, z czego 10 wymaga działania ofiary (kliknięcia w przygotowany link).

Dwie luki krytyczne:

• Rdzeń WordPressa, CVE-2026-87902 (CVSS 4.0: 9.2, bez logowania): obejście ścieżki przy wyborze szablonu strony. Poprawka w 6.8.10 z 22.09.2026; według Patchstack pierwsza próba wykorzystania pojawiła się tego samego dnia o 19:44 UTC+2, kilka godzin po publikacji poprawki. Według opublikowanego opisu wykonanie kodu wymaga motywu z katalogiem page-* i dostępnego na serwerze pliku pearcmd.php. Żaden z zainstalowanych motywów (Porto, motyw potomny, cztery motywy domyślne) nie ma takiego katalogu (sprawdzone w plikach), więc ta droga jest tu zamknięta. Aktualizacja i tak jest pierwsza, bo to poprawka w tej samej linii wersji, a atakujący już próbują tę lukę wykorzystać.
• CTX Feed, CVE-2026-66709 (CVSS 9.1): wykonanie kodu z konta z rolą kierownika sklepu. W sklepie jest jedno takie konto, bez weryfikacji dwuetapowej.

3.2 Aktualizacje nie miały jak przyjść priorytet: wysoki

25 z 27 wtyczek z wordpress.org jest w tyle, m.in. Elementor 3.29.2 (120 nowszych wydań), WooCommerce 9.9.3 (98), CTX Feed 6.5.66 (93), Customer Reviews (60), Rank Math (42), Fluent Forms (37), wtyczka płatności Stripe (36). Daty katalogów w kopii plików pokazują, że od przeprowadzki 17.06.2025 zmieniły się tylko dwie wtyczki (FluentSMTP 03.09.2025, faktury 04.09.2025). Automatyczne aktualizacje są wyłączone dla wszystkich 35 wtyczek.

Rdzeń WordPressa domyślnie instaluje poprawki bezpieczeństwa sam, ale tu nie mógł: w katalogu strony leży repozytorium kodu .git, a WordPress uznaje wtedy stronę za prowadzoną przez programistę i pomija wszystkie aktualizacje w tle (wp-admin/includes/class-wp-automatic-updater.php, funkcja is_vcs_checkout). Informuje o tym tylko ekran „Zdrowie witryny". W bazie nie ma śladu, żeby automat kiedykolwiek zakończył aktualizację.

3.3 Zapora bez powiadomień, logowanie bez drugiego składnika priorytet: wysoki

Wordfence 8.0.5 (wersja darmowa) nie ma wpisanego adresu do powiadomień. Licznik ostrzeżeń wtyczki pokazuje 42; wtyczka zwiększa go, zanim sprawdzi adres, a przy pustym adresie kończy wysyłkę bez błędu (lib/wordfenceClass.php, linie 7442-7445). W archiwum poczty właściciela nie ma ani jednego ostrzeżenia Wordfence z tego sklepu.

Ostatnie skanowanie (szybkie, 12.06.2026 06:11 UTC+2) zgłosiło 26 nowych problemów; otwartych jest 27 (12 krytycznych aktualizacji wtyczek, 10 średnich, 3 motywu, 1 WordPressa, 1 pominięta ścieżka). Porównywanie plików wtyczek i motywów z oryginałami z wordpress.org jest wyłączone, więc zmiana w ich kodzie nie zostałaby zgłoszona, o ile nie pasuje do znanego wzorca złośliwego kodu.

Weryfikacji dwuetapowej nie ma żadne konto. W dzienniku logowań (09.2024-05.2026) jest 19 udanych logowań i 156 nieudanych, wszystkie na nieistniejące nazwy użytkownika (148 razy „admin"). Na stronie logowania wystąpiły dwa błędy krytyczne PHP (01.05.2026 12:11 i 03.05.2026 18:46 UTC+2): Wordfence nie obsłużył adresu IP zawierającego niedozwolony znak; dotyczyły pojedynczych żądań (źródło: wiadomości trybu odzyskiwania WordPressa).

3.4 Klucze usług w kodzie i w bazie priorytet: wysoki

Klucz API OpenAI jest zapisany jawnie w kodzie wtyczki pisanej na zamówienie („WooCommerce SEO Optimizer", wp-content/plugins/woo-seo-optimizer/index.php, linia 163) i w dwóch ustawieniach w bazie; to ten sam klucz (porównanie skrótów, bez wypisywania wartości). W dniu audytu klucz był aktywny (sprawdzone zapytaniem tylko do odczytu o listę modeli), więc każdy, kto miał kopię plików albo bazy, mógł go używać na koszt właściciela konta; to był jedyny priorytet krytyczny w tym punkcie. Właściciel odwołał klucz 24.09.2026, a to samo zapytanie zwróciło wtedy błąd autoryzacji (09:07 UTC+2).

W bazie leżą też klucze produkcyjne Stripe, token konta CookieYes, tokeny dostępu Rank Math do usług Google i hasło skrzynki SMTP, a w wp-config.php klucze zasobnika Cloudflare R2.

3.5 Pliki w katalogu strony, których tam nie powinno być priorytet: krytyczny

• Repozytorium .git: 64 zapisy z okresu 05.09.2024-13.06.2025, ok. 400 MB. W historii jest m.in. kod wtyczki pisanej na zamówienie (plik zmieniany w 5 zapisach); nie ma w niej wp-config.php ani zrzutów bazy. Plik .htaccess sklepu do dnia wyłączenia nie blokował dostępu do /.git, a serwer wydaje pliki ukryte (następny punkt), więc repozytorium mogło być do pobrania z zewnątrz. Nie da się tego potwierdzić, bo logi dostępu z okresu działania sklepu już nie istnieją.
• 5 998 plików .listing po kopiowaniu przez FTP; każdy zawiera spis plików swojego katalogu z rozmiarami i datami. Serwer wydaje je każdemu: /.listing na kopii audytowej odpowiada kodem 200 (2 313 bajtów, 23.09.2026 14:08 UTC+2). To spis zawartości katalogów mimo wyłączonego listowania.
• wp-content/debug.log (111 KB, z 04.03.2025), cf-images.log w katalogu wgrywanych plików (4,8 MB, 104 629 linii), kopie .htaccess, pliki konfiguracyjne edytora kodu.

3.6 Konfiguracja serwera i WordPressa

• Brak pliku .htaccess w wp-content/uploads blokującego wykonanie PHP priorytet: wysoki: plik PHP wgrany przez lukę w którejś z wtyczek uruchomi się.
• Brak nagłówków bezpieczeństwa (HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy); nagłówek x-powered-by podaje wersję PHP priorytet: średni. Żadna z wersji pliku .htaccess sklepu nie ustawia nagłówków, a odpowiedź kopii audytowej na tym samym serwerze ich nie ma (23.09.2026 14:09 UTC+2).
• Edycja plików PHP z panelu WordPressa włączona (brak DISALLOW_FILE_EDIT) priorytet: średni.
• W porządku: rejestracja kont zamknięta, trzy konta (administrator, kierownik sklepu, klient), brak haseł aplikacji, unikalne klucze i sole w wp-config.php, katalog faktur zamknięty regułą serwera, w katalogu drugiej wtyczki faktur brak plików PDF.

3.7 Kopie zapasowe priorytet: wysoki

W WordPressie jest jeden wpis Duplicatora z 27.09.2024, a plik tej kopii nie istnieje. Innej wtyczki kopii nie ma. Kopii po stronie hostingu nie sprawdzano.

Czego nie sprawdzono: kopii zapasowych i kont w panelu hostingu i FTP; pięciu wtyczek, których nie ma w publicznych bazach luk; czy klucz OpenAI jest w historii repozytorium; dostępności XML-RPC i ujawniania nazw użytkowników; logów dostępu z okresu działania (nie istnieją). Luk nie testowano żądaniami: ustalenia pochodzą z odczytu wersji wobec opublikowanych komunikatów.

4. Konfiguracja sklepu

4.1 Stany magazynowe i import z hurtowni priorytet: krytyczny

Produkty i stany przychodzą z hurtowni przez WP All Import Pro, a import uruchamia zewnętrzny harmonogram (cron-job.org). Ostatni zakończony import ruszył 15.06.2025 o 00:00 UTC+2, a przebieg trwał ok. 1 h 52 min (6 308 produktów zaktualizowanych, 9 157 wierszy pominiętych).

Tego samego dnia o 15:02 UTC+2 harmonogram wyłączył zadanie przetwarzania importu po 26 kolejnych błędach serwera (HTTP 500) i wysłał o tym e-mail. Import uruchomiony o północy 16.06.2025 nie został przetworzony i do końca działania sklepu pozostał w stanie „uruchomiony". Zadanie uruchamiające import harmonogram wyłączył w nocy z 7 na 8.07.2026 (08.07.2026 00:01 UTC+2, błąd 404). W ten sam sposób harmonogram wyłączał zadanie przetwarzania już wcześniej (30.12.2024, 30.03.2025). Przyczyny błędów 500 nie da się dziś ustalić, bo logi serwera z tamtego okresu nie istnieją; zbiega się to z przeprowadzką sklepu na nowy serwer (12-17.06.2025).

Stany sklepu wobec pliku hurtowni pobranego 23.09.2026 ok. 08:45 UTC+2 (dopasowanie po SKU, 7 330 produktów):

1 095 z 4 688 produktów oznaczonych jako dostępne (23%) hurtownia dziś nie ma; 580 produktów, które ma, sklep ukrywa (ustawienie „ukryj produkty niedostępne" włączone). Porównanie mierzy rozjazd po 15 miesiącach bez synchronizacji, nie stan z dnia wyłączenia. Porównanie obejmuje tylko dostępność, bo sklep przelicza ceny przy imporcie (m.in. dolicza koszt wysyłki produktom wysyłanym osobno).

4.2 Stan w dniu wyłączenia

Tryb „wkrótce" (coming soon) włączony, wszystkie metody płatności wyłączone. To zgodne z zamknięciem sklepu, nie usterka. W historii 11 zamówień (08.2024-09.2025) klienci wybierali płatność za pobraniem (7) i Przelewy24 obsługiwane przez wtyczkę Stripe (4). Wtyczka Stripe pozostała w trybie produkcyjnym z kluczami w bazie (punkt 3.4).

W ustawieniach przelewu zostały dane przykładowe z WooCommerce: „Przykładowe konto bankowe", numer 555 555 555, bez numeru IBAN priorytet: krytyczny w chwili włączenia przelewu. Przy wyłączonym przelewie nie ma to skutku, ale po jego włączeniu klient dostaje te dane na stronie potwierdzenia zamówienia i w mailu, więc nie wie, dokąd wpłacić (sprawdzone zamówieniem testowym, punkt 4.3).

4.3 Kasa i ścieżka zakupu

Zakup bez konta włączony, kasa w jednym kroku (klasyczna, na krótkim kodzie WooCommerce), koszt wysyłki widoczny w koszyku (przykład: produkt 290,00 zł, wysyłka 19,00 zł, razem 309,00 zł z 23% VAT).

Ścieżka zakupu (strona główna, sklep, produkt, dodanie do koszyka, koszyk, kasa) sprawdzona na kopii audytowej: dwa przejścia na telefonie (390 px) i dwa na komputerze (1440 px), 23.09.2026 15:12-15:25 UTC+2. Wszystkie strony odpowiadają, serwer oddaje dokument strony w 0,38-0,94 s (bez pamięci podręcznej, która na kopii jest wyłączona; jeden wyjątek: pierwsza strona przejścia z zamówieniem testowym, 3,2 s), dodanie do koszyka działa bez przeładowania strony. W każdym przejściu pierwsza strona wczytała się dwa razy (punkt 2.3). W stanie z dnia wyłączenia kasa pokazuje komunikat „Przykro nam, ale nie jest udostępniona żadna metoda płatności" (punkt 4.2).

Zamówienie testowe (telefon, 15:17-15:20 UTC+2, dane fikcyjne, przelew włączony na czas testu): od kliknięcia przycisku zamówienia do wczytania strony potwierdzenia 1,6 s. Zamówienie dostało status „wstrzymane (oczekujące na płatność)", stan magazynowy produktu zmniejszył się o jedną sztukę, sklep wygenerował mail do klienta i powiadomienie do sklepu. Strona potwierdzenia i mail do klienta podają przykładowe dane konta z punktu 4.2. Po anulowaniu zamówienia stan magazynowy wrócił.

Na obu urządzeniach jedyny błąd JavaScript pochodzi ze skryptu banera zgody (CookieYes), przypisanego do starej domeny; po zablokowaniu tego skryptu strona nie zgłasza błędów JavaScript. To skutek kopii, nie usterka sklepu.

4.4 Wysyłka

W ustawieniach WooCommerce jest jedna strefa (Polska) i „Kurier" za 1,00 zł, ale faktyczny koszt liczy kod motywu potomnego (porto-child/functions.php, filtry woocommerce_package_rates, linie 180 i 808): 19 zł za paczkę (własne pole w ustawieniach), koszt indywidualny z pola produktu, paczki łączone i osobne. Produktom wysyłanym osobno import dolicza koszt wysyłki do ceny (linia 144) i oznacza je jako „darmowa dostawa". Działa, ale ustawienia WooCommerce pokazują coś innego niż płaci klient, a zmiana cennika wysyłki wymaga programisty priorytet: średni, rozdział 5. Etykieta w koszyku „Kurier (1 łączone paczki)" jest niegramatyczna priorytet: niski.

4.5 Podatki, maile, ceny

• Podatki: VAT 23%, ceny z podatkiem, liczony wg adresu wysyłki. Bez uwag.
• Maile transakcyjne: szablony domyślne, wszystkie włączone. Nadawca w ustawieniach WooCommerce to adres w innej domenie niż sklep, a wtyczka FluentSMTP wysyła przez skrzynkę na serwerze hostingu z adresu w domenie sklepu priorytet: niski; ujednolicić. Dziennik FluentSMTP ma jeden wpis (01.06.2026), więc nie mówi, czy maile do klientów dochodziły.
• Najniższa cena z 30 dni (Omnibus): wtyczka Price History, 30 dni, wyświetlanie przy promocji, historia cen dla wszystkich 7 330 produktów. W sklepie nie było produktów w promocji, więc wyświetlenia nie dało się sprawdzić.

4.6 Analityka i zgody

Tagi Google Analytics 4 i Microsoft Advertising (UET) wstawione w kod strony i ładowane przez mechanizm opóźniania skryptów LiteSpeed Cache; motyw potomny dodaje konwersje rozszerzone Bing w nagłówku i zaproszenie do opinii Google w stopce, oba tylko na stronie potwierdzenia zamówienia. Moduł analityki Rank Math nie wstawia drugiego kodu GA (w porządku). Baner zgody: CookieYes.

• Zakup w Google Analytics 4 priorytet: średni: tag GA4 w motywie potomnym ma samą konfigurację, bez zdarzeń sklepu, więc GA4 nie dostaje zakupu ani wartości zamówienia i nie pokaże przychodu ani tego, które źródło ruchu sprzedaje. Wtyczki, które mogłyby te zdarzenia wysyłać, są wyłączone albo bez identyfikatorów (moduł Rank Math bez wstawiania kodu, śledzenie w CTX Feed bez numeru konta). Czy zakup zdefiniowano regułą w panelu GA4 (i tak bez wartości zamówienia), nie sprawdzono.
• Konwersje rozszerzone Bing priorytet: średni: kod przekazuje skrót adresu e-mail i numeru telefonu klienta. Numer miał trafiać w formacie międzynarodowym, ale warunek dopisujący „+" nigdy się nie spełnia, a numeru kierunkowego kraju kod nie dodaje, więc dla numerów wpisanych bez „+48" dopasowanie po telefonie prawdopodobnie nie działa.

Czego nie sprawdzono: czy tagi czekają na zgodę (baner CookieYes jest przypisany do starej domeny i na kopii audytowej nie działa); dostarczania maili do skrzynek (na kopii poczta jest przechwytywana do pliku); płatności online w działaniu (bramki Stripe wyłączone, klucze usunięte z kopii; przelew sprawdzono zamówieniem testowym); aktualności feedów produktowych CTX Feed (Google Shopping i drugi feed).

5. Porządek w instalacji

5.1 Wtyczki i motywy priorytet: średni

35 wtyczek: 32 aktywne, 3 nieaktywne (WP MailHog SMTP, narzędzie programisty do przechwytywania poczty; Better Search Replace; Preserve Page and Taxonomy Hierarchy 0.1 spoza wordpress.org). Filenames to Latin nie ma wydania od 09.08.2020. Dwie wtyczki formularzy (Contact Form 7 i Fluent Forms), obie używane (zgłoszenia zapisane w obu).

Wtyczka pisana na zamówienie „WooCommerce SEO Optimizer" (nagłówek z szablonu „Author: Your Name") wysyła tytuły i opisy produktów do API OpenAI; klucz w kodzie, punkt 3.4. Cztery nieaktywne motywy domyślne (Twenty Twenty-Two do Twenty Twenty-Five).

5.2 Baza danych priorytet: średni

Baza ma 153 tabele i ok. 0,9 GB; ok. dwie trzecie to dane wtyczki Offload Media: tabela wp_acoofm_items (ok. 490 MB) i 71 wygasłych transientów acoofm_cached_data_* w tabeli opcji (razem ok. 163 MB, wygasły 12-13.06.2026). Tabela wp_postmeta ma ok. 194 MB.

Opcje ładowane przy każdym żądaniu (autoload) zajmują ok. 1,4 MB wobec progu 800 KB, od którego WordPress ostrzega w „Zdrowiu witryny" (wp-admin/includes/class-wp-site-health.php, linia 2648). Dwie największe, po ok. 0,5 MB, to transienty bez terminu ważności: _transient_dirsize_cache (pamięć rozmiarów katalogów) i _transient_ptk_patterns (wzorce bloków pobierane przez WooCommerce). WordPress 6.8 zapisze pierwszy ponownie z terminem ważności, już bez ładowania przy każdym żądaniu; drugi WooCommerce 9.9.3 zapisuje bez terminu, więc po usunięciu wróci (do sprawdzenia po aktualizacji WooCommerce). Rewizji 97, osieroconych metadanych 0.

5.3 Zdjęcia produktów priorytet: średni, projekt

Załączników jest 27 542, pliki na serwerze ma ok. 29% z nich. Resztę wtyczka Offload Media przeniosła do zewnętrznego zasobnika (Cloudflare R2) pod adresem w domenie sklepu, który przestał odpowiadać z wygaśnięciem domeny (brak rekordu DNS, 23.09.2026). Zdjęcia zależą więc od domeny, zasobnika i licencji jednej wtyczki. Czy sam zasobnik nadal istnieje, rozstrzygnie konto Cloudflare. Plik hurtowni daje zdjęcia dla 5 217 produktów (71%); dla 2 113 produktów spoza jej oferty zdjęcia są tylko w zasobniku albo w plikach na serwerze.

5.4 Zadania w tle priorytet: średni

Na koncie hostingu nie ma crona systemowego dla sklepu (odczyt 23.09.2026), więc zadania WordPressa uruchamiają się tylko przy wizytach. Action Scheduler: 250 zadań nieudanych z okresu 09.2024-02.2026, z czego 110 w czerwcu 2025, głównie przebudowa tabel wyszukiwania produktów (125) i czyszczenie pamięci powiązanych produktów (84); 5 zadań oczekuje od 12.06.2026; 22 844 wiersze dziennika.

5.5 Logika sklepu w motywie potomnym priorytet: średni, projekt

Plik porto-child/functions.php ma 1 239 linii logiki sklepu: wysyłka (punkt 4.4), doliczanie kosztów przy imporcie, teksty stanów, oznaczenia darmowej wysyłki, konwersje Bing, zaproszenia do opinii Google. Zmiana albo uszkodzenie motywu potomnego zmienia ceny wysyłki.

5.6 Drobne

Ustawienie wtyczki Debug Log Manager wskazuje ścieżkę poprzedniego hostingu (ostrzeżenie w logu PHP); pliki robocze w katalogu strony: punkt 3.5.

Czego nie sprawdzono: które funkcje każdej wtyczki są faktycznie używane; tabel po usuniętych wtyczkach poza tymi z listy największych.

6. Zachowania klientów, w wariancie rozszerzonym

Nie był objęty: raport przykładowy pokrywa wariant podstawowy, a sklep w dniu audytu nie miał ruchu. W wariancie rozszerzonym ten rozdział opisuje miesiąc pomiaru: gdzie klienci klikają, na którym kroku kasy odpadają, z jakich stron trafiają do koszyka i na jakich urządzeniach, każde ustalenie z liczbą sesji.

7. Co poprawić, w jakiej kolejności

Do kliknięcia dziś, bez wykonawcy

• Wordfence: w ustawieniach powiadomień e-mail wpisać adres, który ktoś czyta; w module logowania (Login Security) włączyć weryfikację dwuetapową dla administratora i kierownika sklepu.
• LiteSpeed Cache: na karcie Cache kliknąć „Zapisz zmiany" bez zmieniania ustawień (wtyczka zapisze ponownie swoje reguły serwera, w tym tę dla telefonów); w ustawieniach ogólnych wyłączyć tryb gościa.
• Wtyczki: usunąć trzy nieaktywne (WP MailHog SMTP, Better Search Replace, Preserve Page and Taxonomy Hierarchy).
• Usługa uruchamiająca import (cron-job.org): włączyć ponownie zadania importu i sprawdzić w historii zadania, czy przebieg kończy się bez błędu.

Proste (do zrobienia w tydzień, bez projektu):

Większe (projekt do wyceny):

Warunki audytu i odstępstwa

• Sklep: własność wykonawcy audytu, wyłączony 29.07.2026, domena wygasła 06.09.2026. Od 12-13.06.2026 w bazie nie ma śladów pracy WordPressa (zadania w tle, skanowanie zapory); przyczyny nie ustalano.
• Kopia audytowa: pliki sklepu i zrzut jego bazy z 23.09.2026, przywrócone tego dnia na tym samym serwerze (hosting współdzielony, serwer LiteSpeed, PHP 8.3) na osobnym adresie za hasłem, z nagłówkiem i plikiem robots.txt zakazującymi indeksowania. Kopia zostanie usunięta z serwera po zakończeniu prac nad raportem. Część odczytów kodu i bazy wykonano na drugiej kopii (ten sam kod i ta sama baza) na komputerze audytora; ścieżkę zakupu i zamówienie testowe wykonano na kopii audytowej.
• Dane klientów: zanonimizowane przed wystawieniem na serwer (11 zamówień i 3 zwroty, 8 rekordów klientów, kontakty, zgłoszenia formularzy, notatki zamówień); dzienniki z adresami IP wyczyszczone. Kontrola po anonimizacji: 0 adresów e-mail spoza domen sklepu i jego właściciela w całej bazie (przed: 306 wierszy). Klucze usług usunięte z bazy i kodu kopii. Ustalenia dotyczące danych osobowych klientów przekazano właścicielowi osobno; nie ma ich w tej wersji raportu.
• Zmiany na kopii: wyłączony tryb „wkrótce", żeby sklep dało się mierzyć; poczta przechwytywana do pliku; połączenia z usługami zewnętrznymi zablokowane; zadania zaplanowane WordPressa wyłączone. Na czas zamówienia testowego (23.09.2026 15:17-15:20 UTC+2) włączono przelew; zamówienie anulowano, stan magazynowy wrócił, przelew wyłączono. W przeglądarce, którą przechodzono ścieżkę zakupu, zablokowano wysyłanie danych do Google Analytics i Microsoft Advertising, żeby zamówienie testowe nie trafiło do statystyk sklepu. Rdzenia, wtyczek i motywu nie aktualizowano: zaniedbanie jest materiałem audytu.
• Zdjęcia i fonty: zdjęcia z plików na serwerze (ok. 29% załączników) i z pliku hurtowni; pozostałe odpowiadają błędem 404. Część fontów wskazuje adres starej domeny i się nie wczytuje (punkt 2.5), więc strony kopii są lżejsze niż w sklepie.
• Pomiary: Lighthouse zamiast PageSpeed Insights (kopia za hasłem), z komputera audytora; pamięć podręczna stron wyłączona na kopii, bo odpowiadała przed sprawdzeniem hasła. Zestaw pomiarowy porównano z PageSpeed Insights 23.09.2026 na publicznej stronie wykonawcy audytu, po trzy przebiegi: wynik na telefonie 89 wobec 93 (przebiegi 82-95 wobec 84-98), na komputerze 99 w obu. Różnica median na telefonie mieści się w rozrzucie przebiegów obu narzędzi, więc wyniki z kopii należy czytać z tolerancją kilku punktów. Pojedyncze metryki różnią się w obie strony (telefon: TBT 189 ms wobec 71 ms, LCP 2,86 s wobec 3,08 s), a PageSpeed Insights używa nowszej wersji Lighthouse (13.5 wobec 12.8). Strona porównawcza jest lekka, więc zgodności dla stron z dużą ilością skryptów nie sprawdzono. Ustalenia o kodzie wtyczek pochodzą z odczytu kodu zainstalowanych wersji, o stanie danych z bazy sklepu, o serwerze z dostępu tylko do odczytu na koncie hostingu.
• Rozdział 6: nie istnieje (wariant podstawowy, sklep bez ruchu).