Audyt techniczny strony WordPress to przegląd wersji oprogramowania, wtyczek, kodu motywu, bezpieczeństwa, wydajności, kopii zapasowych i SEO technicznego. Wynikiem jest lista problemów z priorytetami: co naprawić w ciągu dni, co w ciągu tygodni, a co może poczekać. Ma sens przed przejęciem opieki, bo bez niego pierwsza aktualizacja to loteria.

Po co audyt przed przejęciem opieki

Strona po innym wykonawcy ma historię, której nie widać w panelu. Ktoś zmienił plik wtyczki, żeby naprawić błąd. Ktoś wyłączył aktualizacje, bo coś się zepsuło. Ktoś zostawił konto administratora dla freelancera sprzed trzech lat.

Audyt odpowiada na trzy pytania:

  • Czy stronę można bezpiecznie aktualizować i co się przy tym zepsuje.
  • Czy strona jest teraz zainfekowana albo narażona na znane podatności.
  • Ile pracy wymaga doprowadzenie jej do stanu, w którym stała opieka ma sens.

Dla właściciela to też podstawa do rozmowy o cenie. Oferta opieki bez audytu jest zgadywaniem, zwykle na czyjąś niekorzyść.

Wersje WordPress, PHP i serwera

Pierwsza tabela w raporcie to wersje. Są łatwe do sprawdzenia i dużo mówią o tym, jak strona była prowadzona.

  • WordPress. Poprawki bezpieczeństwa trafiają do najnowszej gałęzi. Strona kilka wersji głównych w tyle zwykle ma też zaległe wtyczki i motyw.
  • PHP. Według harmonogramu wsparcia PHP wersje 8.1 i starsze nie dostają już poprawek bezpieczeństwa. PHP 8.2 przestaje je dostawać 31 grudnia 2026 r.
  • Baza danych. Wymagania WordPress zalecają PHP 8.3 lub nowsze oraz MySQL 8.0 lub MariaDB 10.11 lub nowsze.
  • WooCommerce. W sklepie audyt obejmuje wersję wtyczki i raport stanu systemu. Pokazuje on między innymi szablony WooCommerce nadpisane w motywie, które są nieaktualne.

Stare PHP to najczęstszy powód, dla którego strona „nie daje się zaktualizować”. Nowe wersje wtyczek wymagają nowszego PHP, a stary kod motywu nie działa na nowym. Trzeba to rozplątać w dobrej kolejności, na kopii strony.

Wtyczki: ile, jakie i skąd

Sama liczba wtyczek niewiele mówi. Strona z 40 dobrze utrzymanymi wtyczkami może być zdrowsza niż strona z 12 porzuconymi. Liczy się stan każdej z nich.

Audyt sprawdza:

  • Porzucone wtyczki. Katalog WordPress.org ostrzega przy wtyczkach, których autor nie testował z trzema ostatnimi wersjami głównymi WordPress.
  • Wtyczki zamknięte. Zniknęły z katalogu, czasem z powodu niezałatanej podatności. Nie dostaną już aktualizacji.
  • Wtyczki z nieoficjalnych źródeł. Płatne wtyczki pobrane za darmo z przypadkowych stron to częsta droga malware na serwer.
  • Zmodyfikowane pliki. Polecenie wp plugin verify-checksums --all porównuje pliki wtyczek z katalogu WordPress.org z oryginałem. Każda różnica oznacza ręczną zmianę albo infekcję.
  • Licencje premium. Czy są aktywne i na czyje konto.
  • Dublujące się funkcje. Dwie wtyczki SEO, trzy do cache, dwa formularze. Każda para to ryzyko konfliktu.
  • Wtyczki nieaktywne. Nie działają, ale ich pliki wciąż są na serwerze i mogą mieć podatności.

Motyw i własny kod

Tu audyt zajmuje najwięcej czasu, bo narzędzia automatyczne niewiele pomagają. Ktoś musi przeczytać kod.

Najważniejsze pytanie brzmi: czy motyw da się zaktualizować. Jeśli poprzedni wykonawca zmieniał pliki motywu nadrzędnego zamiast motywu potomnego, aktualizacja wymaże te zmiany. Wtedy trzeba je najpierw wyodrębnić i przenieść.

Poza tym audyt obejmuje:

  • kod w functions.php i w katalogu mu-plugins, bo tam lądują szybkie poprawki bez dokumentacji,
  • zapytania do bazy bez zabezpieczenia danych wejściowych,
  • wpisane na sztywno adresy, hasła i klucze API,
  • zależność od page buildera, która decyduje o kosztach każdej przyszłej zmiany.

O tym ostatnim piszemy więcej w tekście o tym, jak page buildery wpływają na wydajność i utrzymanie.

Bezpieczeństwo

Część bezpieczeństwa sprawdza się poleceniami, część trzeba obejrzeć ręcznie. Minimalny zakres wygląda tak:

  1. Integralność rdzenia: wp core verify-checksums porównuje pliki WordPress z sumami kontrolnymi z WordPress.org.
  2. Skan plików na obecność malware, szczególnie plików PHP w katalogu uploads, gdzie nie powinno ich być.
  3. Lista kont administratorów. Każde nieznane konto to sygnał alarmowy.
  4. Wersje wtyczek i motywu porównane z publicznymi bazami podatności.
  5. Ustawienia w wp-config.php: wyłączona edycja plików z panelu, wyłączony tryb debugowania na produkcji.
  6. Dostępność xmlrpc.php, listowanie katalogów, uprawnienia plików.
  7. Logowanie: dwuskładnikowe uwierzytelnianie dla administratorów, limit prób.

Gdy audyt wykryje infekcję, plan się zmienia: najpierw sprzątanie, potem reszta. Procedurę opisujemy w poradniku co zrobić po włamaniu na stronę WordPress.

Wydajność i SEO techniczne

Audyt mierzy wydajność na danych, nie na odczuciach. Punktem odniesienia są progi Core Web Vitals z dokumentacji Google:

  • LCP, czyli wczytanie głównej treści: do 2,5 s,
  • INP, czyli reakcja na kliknięcie: do 200 ms,
  • CLS, czyli przesunięcia układu: do 0,1.

Progi dotyczą 75 procent odsłon, osobno na telefonach i komputerach. Do tego dochodzi czas odpowiedzi serwera, rozmiar opcji ładowanych automatycznie z bazy i liczba zapytań na stronę.

Audyt wskazuje przyczyny spowolnienia. Samą optymalizację opisujemy krok po kroku w osobnym poradniku optymalizacji WordPress.

W SEO technicznym audyt szuka błędów, które potrafią wyzerować ruch z Google:

  • zaznaczona opcja „Proś wyszukiwarki o nieindeksowanie witryny” w ustawieniach czytania,
  • blokady w robots.txt i znaczniki noindex na ważnych podstronach,
  • brakująca lub błędna mapa witryny,
  • błędne adresy kanoniczne i łańcuchy przekierowań,
  • zdublowane dane strukturalne z dwóch wtyczek SEO naraz.

Kopie zapasowe i środowisko

Pytanie „czy są kopie?” to za mało. Audyt sprawdza, czy kopię da się przywrócić.

  • Jak często powstaje kopia i ile wersji wstecz jest przechowywanych.
  • Gdzie jest przechowywana. Kopia na tym samym serwerze nie przetrwa awarii serwera ani włamania.
  • Czy obejmuje pliki i bazę, czy tylko jedno z nich.
  • Kiedy ostatnio ktoś ją przywrócił na próbę.

Brak działającej kopii to zawsze punkt pilny. Pierwsza pełna kopia powinna powstać jeszcze przed audytem, żeby żadna czynność diagnostyczna nie odbywała się bez zabezpieczenia.

Ta część obejmuje też trzy sprawy, o które rzadko ktoś pyta:

  • Serwer testowy. Czy istnieje kopia strony do testowania aktualizacji i zmian. Bez niej każda poprawka trafia od razu do klientów.
  • Wysyłka poczty. Czy formularze i zamówienia wysyłają maile przez uwierzytelniony serwer SMTP. Czy domena ma rekordy SPF, DKIM i DMARC. Bez nich wiadomości z formularza częściej trafiają do spamu.
  • Zadania cron. Czy zaplanowane zadania WordPress uruchamia serwer, czy tylko wizyty użytkowników. Przy małym ruchu publikacje i wysyłki potrafią się wtedy opóźniać.

Jak czytać wynik audytu

Dobry raport nie jest wydrukiem ze skanera. Każde znalezisko ma opis, dowód, skutek dla firmy i rekomendację. Znaleziska są pogrupowane według pilności.

Pilne, do naprawy w ciągu kilku dni:

  • aktywna infekcja lub nieznane konta administratorów,
  • wtyczki ze znanymi, wykorzystywanymi podatnościami,
  • brak kopii, której przywrócenie zostało sprawdzone,
  • PHP bez poprawek bezpieczeństwa,
  • blokada indeksowania na produkcji.

Ważne, do zaplanowania w ciągu tygodni:

  • porzucone wtyczki do wymiany,
  • zmiany w motywie nadrzędnym do przeniesienia do motywu potomnego,
  • wyniki Core Web Vitals w kategorii „słabe”,
  • brak serwera testowego.

Do planu rozwoju: przebudowa motywu, zmiana page buildera, porządki w bazie. Te sprawy nie grożą awarią, ale podnoszą koszt każdej zmiany.

Sygnałem ostrzegawczym jest raport bez priorytetów, w którym wszystko jest „krytyczne”. Podobnie raport, który kończy się tylko propozycją budowy nowej strony. Czasem to słuszna rekomendacja. Powinna jednak wynikać z listy znalezisk i z porównania kosztu napraw z kosztem przebudowy.

Po naprawie punktów pilnych strona przechodzi w tryb regularnych aktualizacji. Jak robić je bez przestojów, opisujemy w tekście o aktualizacjach WordPress bez awarii.

Najczęstsze pytania

Czy audyt techniczny można zrobić bez dostępu do serwera?

Tylko częściowo. Z zewnątrz da się zmierzyć wydajność, sprawdzić SEO techniczne i wersje widoczne w kodzie strony. Kod motywu, integralność plików, konta administratorów i kopie zapasowe wymagają dostępu do panelu WordPress, plików i bazy danych.

Czy audyt może zepsuć stronę?

Nie powinien. Audyt polega na odczycie, a testy aktualizacji i obciążające skany wykonuje się na kopii strony na osobnym serwerze. Przed rozpoczęciem powstaje pełna kopia zapasowa, więc nawet niespodziewany problem da się cofnąć.

Czy wystarczy darmowy skaner bezpieczeństwa albo PageSpeed Insights?

Narzędzia automatyczne pokazują objawy: znaną podatność, wolne ładowanie, brak nagłówka. Nie pokażą zmodyfikowanego motywu nadrzędnego, kodu bez zabezpieczeń ani kopii, której nie da się przywrócić. Są dobrym początkiem, ale decyzję o aktualizacji podejmuje się po przeczytaniu kodu.

Co powinienem dostać po audycie?

Raport z listą znalezisk pogrupowanych według pilności, z opisem skutku i rekomendacją dla każdego z nich. Do tego plan napraw z kolejnością prac i szacunkiem nakładu. Raport powinien być zrozumiały dla osoby, która nie jest programistą.

Audyt techniczny to pierwszy krok, od którego zaczynamy każde przejęcie strony po innym wykonawcy. Jeśli dopiero zbierasz dostępy od poprzedniej agencji, zacznij od listy w tekście o tym, jak przejąć stronę WordPress od agencji. Stałą opiekę po audycie opisujemy na stronie opieka nad stroną WordPress.