Jak zabezpieczyć WordPress? Checklista dla strony firmowej i kiedy prościej zmienić technologię

Jeśli masz stronę na WordPressie, prędzej czy później ktoś spróbuje się na nią dostać. Nie dlatego, że Twoja firma jest wyjątkowo ciekawa, tylko dlatego, że boty skanują cały internet w poszukiwaniu nieaktualnych wtyczek. Dlaczego tak się dzieje, rozpisałem w tekście czy WordPress jest jeszcze bezpieczny. Tutaj skupiam się na tym, co z tym zrobić.

Poniżej jest lista, którą przechodzę na stronach firmowych. Kolejność ma znaczenie: pierwsze punkty dają najwięcej, a ostatnie to dopracowanie. Jeśli masz czas tylko na część, zacznij od góry.

Dlaczego tempo jest ważniejsze niż kolejne wtyczki

Zanim przejdę do listy, jedna liczba, która ustawia priorytety:

Wyścig z czasem

ważona mediana czasu do pierwszego ataku przy najczęściej wykorzystywanych lukach

5 h

luk o dużym znaczeniu wykorzystano w ciągu 24 godzin

~50%

podatności nie miało poprawki od autora w chwili ujawnienia

46%

ataków zatrzymały typowe zabezpieczenia hostingu w testach Patchstacka

12-26%

Źródło: Patchstack, State of WordPress Security in 2026.

Wniosek jest prosty. Zabezpieczenia na serwerze pomagają, ale zatrzymują tylko część ataków. Jedyną pewną ochroną przed znaną luką jest jej usunięcie, czyli aktualizacja. A kiedy poprawki jeszcze nie ma, liczy się to, ile kodu w ogóle masz na serwerze.

1. Aktualizacje: szybko i automatycznie

Rdzeń WordPressa od lat sam instaluje poprawki bezpieczeństwa. Wtyczki i motywy nie, chyba że to włączysz. Od wersji 5.5 możesz w panelu włączyć automatyczne aktualizacje dla każdej wtyczki i motywu osobno.

Na stronach firmowych włączam je prawie zawsze. Obawa, że aktualizacja coś zepsuje, jest uzasadniona, ale rachunek wychodzi na korzyść aktualizacji: zepsuty układ strony naprawia się w godzinę z kopii zapasowej, a sprzątanie po włamaniu i spamie w Google trwa tygodniami.

Wyjątki, które aktualizuję ręcznie, po sprawdzeniu na kopii strony: duże page buildery, wtyczki sklepowe i wszystko, od czego zależy płatność albo rezerwacja.

Sprawdź też wersję PHP na serwerze. Jeśli hosting pozwala wybrać wersję, wybierz taką, która nadal ma wsparcie bezpieczeństwa. Aktualną listę wspieranych wersji publikuje projekt PHP na php.net.

2. Wtyczki i motywy: mniej znaczy bezpieczniej

Każda wtyczka to kod innej osoby uruchamiany na Twoim serwerze. Patchstack policzył, że w 2025 roku 91% nowych podatności w ekosystemie WordPressa dotyczyło właśnie wtyczek.

• Usuń wszystko, czego nie używasz. Wyłączona wtyczka nadal leży na serwerze, a w wielu przypadkach da się wywołać jej pliki bezpośrednio. To samo dotyczy domyślnych motywów, których nie używasz: zostaw jeden zapasowy.
• Sprawdzaj, kiedy wtyczka była ostatnio aktualizowana. Dodatek bez aktualizacji od ponad roku to sygnał ostrzegawczy. Jeśli wtyczka zniknęła z katalogu WordPress.org, poszukaj zamiennika.
• Uważaj na płatne dodatki z wygasłą licencją. Według Patchstacka komponenty premium miały trzy razy więcej podatności znanych z realnych ataków niż darmowe. Bez aktywnej licencji często nie dostają aktualizacji.
• Nigdy nie instaluj „darmowych” wersji płatnych wtyczek z nieoficjalnych stron. To jedna z najprostszych dróg do zainfekowania strony.

3. Logowanie i konta

Panel WordPressa pod adresem /wp-admin/ jest wystawiony w internecie i boty codziennie próbują zgadywać do niego hasła.

• Włącz logowanie dwuskładnikowe (2FA) dla wszystkich kont z uprawnieniami do edycji. Robi to kilka sprawdzonych wtyczek, w tym rozwijana przez społeczność WordPressa wtyczka Two Factor.
• Ogranicz liczbę prób logowania. Wiele hostingów robi to na poziomie serwera, a jeśli nie, pomoże wtyczka.
• Nie używaj loginu „admin” i nie pokazuj prawdziwych loginów jako autorów wpisów.
• Daj każdemu najniższą rolę, jaka wystarcza. Osoba, która dodaje wpisy na blog, nie potrzebuje roli administratora. Konta byłych pracowników i wykonawców usuń.
• Wyłącz XML-RPC, jeśli z niego nie korzystasz. To stary interfejs, który bywa używany do masowego zgadywania haseł. Nowoczesne integracje korzystają z REST API i haseł aplikacji.

Sucuri w raporcie za 2023 rok podało, że w 55,2% zainfekowanych baz danych znalazło fałszywe konta administratorów. Raz w miesiącu przejrzyj listę użytkowników z rolą administratora. Każde konto, którego nie rozpoznajesz, to alarm.

4. Ustawienia w wp-config.php i na serwerze

Kilka zmian w plikach, które robi się raz i które utrudniają życie atakującym:

• Wyłącz edytor plików w panelu, dodając do wp-config.php linię define( 'DISALLOW_FILE_EDIT', true );. Jeśli ktoś przejmie konto administratora, nie wklei złośliwego kodu prosto przez panel.
• Wymuś HTTPS w panelu przez define( 'FORCE_SSL_ADMIN', true );, jeśli strona nie działa jeszcze w całości przez HTTPS.
• Ustaw własne klucze i sole. Wygenerujesz je oficjalnym generatorem WordPressa. Po włamaniu zmiana kluczy wylogowuje wszystkich, także atakującego.
• Ogranicz uprawnienia plików. Katalogi zwykle 755, pliki 644, a wp-config.php jeszcze ciaśniej, jeśli hosting na to pozwala.
• Zablokuj wykonywanie PHP w katalogu z przesłanymi plikami (wp-content/uploads). Tam powinny być obrazy, a nie skrypty.
• Wyłącz listowanie katalogów na serwerze, żeby nikt nie przeglądał zawartości folderów.

Zmiana prefiksu tabel w bazie danych z wp_ na inny często pojawia się w poradnikach. Daje niewiele, bo nowoczesne ataki nie zgadują nazw tabel, więc nie traktowałbym jej jako priorytetu.

5. Kopie zapasowe, które da się odtworzyć

Kopia zapasowa to Twoje ubezpieczenie od wszystkiego: włamania, nieudanej aktualizacji, pomyłki przy edycji.

• Kopia obejmuje pliki i bazę danych. Sama baza albo same pliki nie wystarczą.
• Kopia leży poza serwerem strony. Jeśli atakujący dostanie się na serwer, kopie na tym samym serwerze mogą zostać zainfekowane albo usunięte.
• Trzymasz kilka wersji wstecz. Infekcja bywa wykryta po tygodniach, więc kopia sprzed jednego dnia może już zawierać złośliwy kod.
• Raz sprawdziłeś odtwarzanie. Kopia, z której nikt nigdy nie odtworzył strony, to tylko nadzieja.

6. Zapora i monitoring

• Zapora aplikacji (WAF) na poziomie hostingu albo usługi takiej jak Cloudflare odfiltruje część ruchu botów. Pamiętaj o wynikach testów Patchstacka: typowe zabezpieczenia zatrzymały tylko część ataków na luki specyficzne dla WordPressa. WAF to warstwa dodatkowa, nie zamiennik aktualizacji.
• Wirtualne łatki, które oferują wyspecjalizowane usługi, blokują konkretne luki, zanim autor wtyczki wyda poprawkę. To sensowne przy stronach z dużą liczbą dodatków.
• Monitoring dostępności powie Ci, że strona przestała działać, na przykład po automatycznej aktualizacji.
• Google Search Console z dodaną stroną i włączonymi powiadomieniami e-mail. Raport o problemach z bezpieczeństwem często pierwszy pokazuje, że coś jest nie tak.
• Skanowanie plików pod kątem zmian i znanego złośliwego kodu, najlepiej z powiadomieniem na e-mail.

7. Plan na wypadek włamania

Lepiej mieć go spisanego, zanim będzie potrzebny. W skrócie:

Ile to wszystko kosztuje czasu

Pierwsze uporządkowanie strony według tej listy to zwykle kilka godzin pracy. Potem zostają czynności powtarzalne: przegląd aktualizacji, sprawdzenie kopii, przejrzenie użytkowników, reakcja na powiadomienia o lukach. Co tydzień, co miesiąc, przez cały czas życia strony.

Dla sklepu czy dużego serwisu to normalny koszt prowadzenia biznesu w internecie. Dla firmy, której strona to oferta, kilka realizacji i formularz kontaktowy, to płacenie za ochronę funkcji, z których nikt nie korzysta.

Co zostaje do zrobienia

Zabezpieczony WordPress

• Aktualizacje wtyczek i motywów, często kilka razy w tygodniu.
• 2FA, limity logowania, przegląd kont administratorów.
• Kopie plików i bazy poza serwerem, test odtwarzania.
• WAF, monitoring, skanowanie plików, Search Console.
• Plan na wypadek włamania i ktoś, kto go wykona.

Ta sama strona w Astro

• Brak wtyczek na serwerze, więc brak aktualizacji pod presją czasu.
• Brak panelu logowania na stronie i brak bazy danych.
• Kod i treść w repozytorium z pełną historią: każda wersja do przywrócenia.
• Gotowe pliki na sieci CDN, która dobrze znosi nagłe skoki ruchu.
• Do pilnowania zostają konta z 2FA: domena, hosting, repozytorium, CMS.

Kiedy prościej zmienić technologię

Większości tej listy nie trzeba wykonywać, jeśli na serwerze nie ma czego atakować. Strona statyczna zbudowana w Astro to gotowe pliki HTML. Nie ma w niej PHP, bazy danych ani panelu logowania, więc punkty od pierwszego do czwartego w dużej mierze przestają istnieć, a kopie zapasowe robią się same, bo cała strona żyje w repozytorium z historią zmian.

Nie oznacza to rezygnacji z wygody. Formularz kontaktowy działa przez osobną funkcję z ochroną przed spamem. Jeśli chcesz samodzielnie zmieniać teksty, dokładam prosty panel CMS, który działa obok strony. A przy okazji strona zwykle zaczyna ładować się wyraźnie szybciej, bo przeglądarka dostaje gotowy plik zamiast czekać, aż serwer złoży stronę z bazy.

Najważniejsze przy przeprowadzce jest, żeby nie stracić ruchu z Google. Pilnuję tego jako ktoś, kto od lat zajmuje się SEO: te same adresy albo przekierowania 301, przeniesione treści, tytuły i dane strukturalne. Cały proces opisałem w checkliście migracji z WordPressa, a ofertę znajdziesz na stronie o przebudowie strony.

Jeśli nie wiesz, czy lepiej zabezpieczyć obecny WordPress, czy przenieść stronę, napisz do mnie z adresem strony. Przejrzę wtyczki i powiem szczerze, co ma więcej sensu w Twoim przypadku.