Jak zabezpieczyć stronę WordPress? 12 praktycznych kroków

Jeden z częstszych sposobów, w jaki właściciel firmowej strony dowiaduje się o problemie, wygląda tak: przychodzi wiadomość z hostingu, że na koncie wykryto podejrzane pliki. Albo Google zaczyna pokazywać ostrzeżenie przy adresie w wynikach. Albo klient dzwoni, że po kliknięciu w link z wizytówki przerzuciło go na obcą stronę.

W żadnym z tych scenariuszy nie było wcześniej sygnału ostrzegawczego. Strona działała, formularz wysyłał wiadomości, panel się otwierał. Poniżej rozkładam to na dwanaście kroków w kolejności, w jakiej mają sens — plus to, czego lepiej nie robić, bo część popularnych porad kosztuje więcej, niż daje.

Krótka odpowiedź: jak zabezpieczyć stronę WordPress?

Najkrótsza odpowiedź: największy efekt daje kilka podstawowych rzeczy robionych regularnie, a nie jedna zaawansowana konfiguracja zrobiona raz. Aktualny WordPress, unikalne hasła, drugi składnik logowania, uporządkowane konta i backup, który da się przywrócić — to pokrywa większość realnych scenariuszy. Reszta jest wartościowa, ale dopiero po tym.

Nie podam Ci, ile to zajmie w minutach, bo uczciwa odpowiedź brzmi: to zależy. Na stronie wizytówce podstawa to jedno spokojne popołudnie. Na serwisie z kilkunastoma wtyczkami i integracjami sam przegląd uprawnień potrafi zająć tyle, co reszta razem.

Jedno jest za to pewne: żaden z tych kroków, ani wszystkie naraz, nie dają gwarancji, że nikt się nie włamie. Oficjalna dokumentacja WordPressa mówi to wprost — bezpieczeństwo nie polega na systemach idealnie bezpiecznych, tylko na ograniczaniu ryzyka, a nie jego eliminowaniu. Różnica jest praktyczna: dobrze zabezpieczona strona jest trudniejszym celem i wraca do działania w godziny, a nie w dni.

Od czego naprawdę zaczynają się włamania na WordPressie

Najsłabszym punktem rzadko jest sam WordPress

Rdzeń WordPressa jest rozwijany przez duży zespół, a wykryte w nim podatności są łatane szybko. Problem leży zwykle w warstwie, którą dokłada właściciel strony. Najczęstsze punkty wejścia wyglądają nudno i właśnie dlatego są skuteczne:

• Przestarzała wtyczka — autor wydaje poprawkę, opis podatności staje się publiczny, a strony bez aktualizacji są od tego momentu łatwiejszym celem niż wcześniej.
• Motyw, którego nikt nie aktualizuje — szczególnie kupiony kiedyś na giełdzie szablonów i od lat nietknięty.
• Słabe albo powtórzone hasło — to samo hasło, które wyciekło z zupełnie innego serwisu.
• Przejęte konto — nie trzeba łamać strony, jeśli można się po prostu zalogować.
• Zbyt szerokie uprawnienia — pięć kont administratora, z czego trzy należą do osób, które nie pracują już przy tej stronie.
• Zaniedbany hosting — stara wersja PHP, brak izolacji między kontami, backup, o którym nikt nie wie, czy działa.

Wspólny mianownik: to wszystko są rzeczy zależne od decyzji, nie od szczęścia.

Atak jest zwykle zautomatyzowany, nie osobisty

W ogromnej większości przypadków nikt nie wybrał akurat Twojej firmy. Działają boty, które przeczesują sieć i sprawdzają kolejne adresy pod kątem znanych słabości. Sprowadza się to do dwóch mechanizmów: brute force, czyli automatu podstawiającego kolejne kombinacje loginu i hasła, oraz skanowania podatności — bot sprawdza, jakie wtyczki i w jakich wersjach masz zainstalowane, i porównuje to z publicznymi listami luk.

To dobra wiadomość. Skoro atak jest masowy i schematyczny, obrona też może być schematyczna. Nie potrzebujesz strategii szytej na miarę, tylko zamkniętych drzwi, przez które automat przechodzi najczęściej.

Co firma realnie może stracić po infekcji

Skutki rzadko ograniczają się do „strona nie działa”:

• Dostępność — strona przestaje się otwierać albo przekierowuje odwiedzających w obce miejsce.
• Widoczność w Google — wyszukiwarka może oznaczyć witrynę jako niebezpieczną, a przeglądarka wyświetlić ostrzeżenie zamiast treści.
• Formularze — zapytania od klientów przestają dochodzić i nikt tego nie zauważa od razu.
• Dane — treści, zamówienia albo dane kontaktowe mogą zostać zmienione lub usunięte.
• Zaufanie — klient, którego przeglądarka ostrzegła przed Twoją stroną, niekoniecznie wróci sprawdzić, czy już naprawione.

12 kroków, które warto wdrożyć po kolei

1. Aktualizuj rdzeń, wtyczki i motyw w stałym rytmie

To pojedynczo najważniejsze zabezpieczenie i jednocześnie najczęściej zaniedbywane. Poprawka bezpieczeństwa działa dopiero po zainstalowaniu — dopóki tego nie zrobisz, opublikowany opis luki pracuje na Twoją niekorzyść.

Nie rozwijam tu tematu, bo ma osobny wpis: opisałem w nim, jak często aktualizować WordPress, wtyczki i motyw, w jakiej kolejności to robić i co zrobić, gdy aktualizacja zepsuje stronę.

2. Ustaw silne, unikalne hasło do każdego konta

Kluczowe jest słowo unikalne. Najczęstszy problem to nie hasło zbyt krótkie, tylko hasło używane równocześnie w skrzynce pocztowej, panelu hostingu i WordPressie. Wyciek z jednego serwisu otwiera wtedy wszystkie trzy.

Menedżer haseł nie jest gadżetem dla informatyków, tylko jedynym sposobem, żeby to było wykonalne: generuje hasła losowo, przechowuje je i podstawia, a Ty pamiętasz jedno hasło główne. Uwaga na jedno — hasła do hostingu i FTP/SFTP są równie ważne jak to do WordPressa, bo dostęp do plików na serwerze omija panel całkowicie.

3. Włącz uwierzytelnianie dwuskładnikowe (2FA)

Drugi składnik logowania to najskuteczniejsza pojedyncza rzecz, jaką możesz zrobić z panelem administratora: nawet wykradzione hasło samo nie wystarczy, bo potrzebny jest jednorazowy kod z telefonu.

Jedno zastrzeżenie: WordPress nie ma 2FA w rdzeniu i zawsze wymaga to dodatkowej wtyczki — co zderza się z radą, żeby wtyczek mieć jak najmniej. To jeden z niewielu przypadków, w których kompromis jest oczywisty: jedna wtyczka do 2FA daje więcej niż większość innych zabezpieczeń razem. Rozwiązań jest kilka, w tym oficjalna wtyczka Two Factor z repozytorium WordPress.org — to przykład, nie rekomendacja rankingowa.

Włącz drugi składnik przede wszystkim dla kont administratora i redaktora.

4. Ogranicz ryzyko ataków na logowanie

WordPress domyślnie nie ogranicza liczby prób logowania — automat może próbować bez końca. Limit nieudanych prób i czasowa blokada adresu ucinają większość ruchu brute force, zanim stanie się problemem. Do tego dochodzi informacja o próbach: powiadomienie o serii nieudanych logowań albo o logowaniu z nowego urządzenia bywa pierwszym sygnałem, że ktoś się Twoją stroną interesuje.

Czego to nie załatwia: samo zmienienie adresu panelu nie jest zabezpieczeniem. Zmniejsza hałas w logach, ale nie chroni przed nikim, kto ten adres znajdzie — a znajdują go stosunkowo łatwo. Rób to jako dodatek do limitu prób i 2FA, nigdy zamiast nich.

5. Uporządkuj konta i uprawnienia

WordPress ma pięć podstawowych ról: administrator, redaktor, autor, współpracownik i subskrybent. Różnią się realnie — administrator może instalować wtyczki, zmieniać motyw i edytować pliki, redaktor zarządza treścią, a autor tylko własnymi wpisami.

Zasada najmniejszych uprawnień mówi, żeby każde konto miało dokładnie tyle możliwości, ile potrzebuje do pracy. Powód jest praktyczny: przejęte konto redaktora to problem z treścią, przejęte konto administratora to problem z całą stroną.

Przegląd sprowadza się do trzech pytań: kto ma dziś uprawnienia administratora i czy naprawdę musi, czy zostały konta osób już niepracujących przy stronie, czy nie działa otwarta rejestracja użytkowników, choć strona jej nie potrzebuje. Konta nieużywane usuwaj albo obniżaj im rolę — nie zostawiaj „na wszelki wypadek”.

6. Ogranicz liczbę wtyczek i usuń nieużywane

Każda wtyczka to kod, który ktoś musi utrzymywać. Im więcej wtyczek, tym większa szansa, że któraś zostanie porzucona przez autora albo dostanie podatność w niewygodnym momencie.

Najważniejszy szczegół: wyłączona wtyczka nadal leży na serwerze wraz z całym swoim kodem. Dezaktywacja to nie usunięcie. Jeśli nie potrafisz wskazać palcem, co dana wtyczka robi na stronie, prawdopodobnie nie jest potrzebna — a wtedy trzeba ją usunąć.

Nie przesadź jednak w drugą stronę: sama liczba niczego nie przesądza. Piętnaście aktualnych wtyczek od aktywnych autorów jest bezpieczniejsze niż cztery porzucone trzy lata temu.

7. Instaluj rozszerzenia tylko z zaufanych źródeł

Dokumentacja WordPressa jest tu wyjątkowo bezpośrednia: nie należy pobierać wtyczek i motywów z niezaufanych źródeł, tylko ograniczyć się do repozytorium WordPress.org lub znanych firm.

Przed instalacją sprawdź cztery rzeczy: kiedy ostatnio było aktualizowane, czy jest zgodne z Twoją wersją WordPressa, ile ma aktywnych instalacji i jak autor odpowiada w wątkach wsparcia. Rozszerzenie bez aktualizacji od dwóch lat nie jest „stabilne” — jest bez opieki.

Osobno i bez owijania: wersje „nulled”, czyli płatne wtyczki i motywy udostępniane za darmo poza oficjalnym kanałem, to jedno z najprostszych wejść na stronę. Ktoś włożył pracę w usunięcie zabezpieczenia licencji i rozdaje efekt za darmo — oszczędność jest pozorna, bo koszt pojawia się później i jest wyższy.

8. Wybierz hosting, który realnie pomaga w bezpieczeństwie

Część ochrony dzieje się poniżej WordPressa i nie da się jej nadrobić wtyczkami: aktualne wersje PHP, izolacja między kontami, własny backup z możliwością przywrócenia, filtrowanie ruchu na poziomie serwera i wsparcie, które faktycznie odpowiada.

Nie polecam konkretnego dostawcy, bo wybór zależy od tego, co strona robi. Polecam za to zadać cztery pytania przed decyzją: jaką wersję PHP mogę włączyć, jak wygląda backup i jego przywracanie, czy konta są od siebie odizolowane i co dokładnie robicie, gdy na koncie pojawi się złośliwy kod.

9. Wymuś HTTPS na całej stronie

Certyfikat SSL szyfruje połączenie między przeglądarką a serwerem, więc hasło z panelu i treść formularza nie lecą przez sieć otwartym tekstem. Dziś to standard, nie opcja.

Ważne, czego HTTPS nie robi: nie chroni przed złośliwym kodem, nie powstrzyma przejęcia panelu i nie zabezpiecza przed podatnością we wtyczce. Zaszyfrowane połączenie z zainfekowaną stroną jest nadal połączeniem z zainfekowaną stroną. Sprawdź przy okazji, czy po HTTPS działa cała strona — zdarza się, że pojedyncze obrazy albo skrypty ładują się przez stare adresy.

10. Zbuduj backup, który da się przywrócić

Backup nie zapobiega włamaniu. Decyduje o tym, czy incydent oznacza kilka godzin pracy, czy odtwarzanie strony od zera.

Dokumentacja WordPressa jest tu konkretna: kopia musi obejmować pliki oraz bazę danych, bo sama baza nie odtworzy działającej strony. Zalecane jest trzymanie kilku ostatnich kopii w różnych lokalizacjach i wykonywanie kopii zawsze przed aktualizacją. Najważniejsze zaś — kopia, której nigdy nie próbowałeś przywrócić, jest założeniem, a nie zabezpieczeniem. Rozwinąłem to razem z tematem kopii wykonywanej przed każdą aktualizacją.

11. Włącz monitoring i skanowanie

To trzy różne rzeczy, które łatwo pomylić:

• Monitoring dostępności — czy strona się otwiera. Odpowiada na pytanie „czy działa”.
• Monitoring zmian — czy ktoś coś zmienił: nowe konto administratora, zmodyfikowany plik, nagła instalacja wtyczki. Odpowiada na pytanie „czy ktoś tu był”.
• Skanowanie bezpieczeństwa — czy jest coś złośliwego albo podatnego. Odpowiada na pytanie „czy coś już się stało”.

Realistyczne oczekiwania: skanowanie nie wykrywa wszystkiego. Działa na wzorcach i bazach znanych zagrożeń, więc dobrze ukryty albo świeży kod może mu umknąć. To narzędzie skracające czas wykrycia, a nie czujnik, który zawsze zadziała.

12. Przygotuj plan na wypadek incydentu

W momencie, gdy strona przekierowuje w obce miejsce, nikt nie planuje na spokojnie. Dlatego kolejność pierwszych ruchów lepiej znać wcześniej:

• Nie działaj pochopnie. Kasowanie plików na wyczucie usuwa dowody, a nie przyczynę.
• Zabezpiecz kopię, którą masz — zanim harmonogram nadpisze ją wersją już zainfekowaną.
• Ogranicz dalsze zmiany. Im mniej się dzieje, tym łatwiej ustalić, co i kiedy się zmieniło.
• Zmień dane dostępowe — WordPress, hosting, FTP/SFTP, baza — i wyloguj wszystkie sesje.
• Zbierz informacje — kiedy pojawił się pierwszy objaw, co się dzieje, co zmieniało się na stronie w ostatnich dniach.
• Skontaktuj się z hostingiem, a przy poważniejszym przypadku ze specjalistą. Hosting widzi logi serwera, do których nie masz dostępu z panelu.

To celowo nie jest pełna procedura reagowania na incydent — od pewnego momentu to praca dla kogoś, kto robi to regularnie. Ale te sześć ruchów w pierwszej godzinie potrafi zdecydować, czy w ogóle jest z czego odtwarzać stronę.

Czy potrzebujesz wtyczki bezpieczeństwa WordPress?

To pytanie, przy którym poradniki najbardziej się rozjeżdżają. Jedne mówią „zainstaluj, to podstawa”, inne „nie instaluj, zrobisz sobie krzywdę”. Oba obozy mają rację — tylko w różnych sytuacjach.

Reguła, którą stosuję, brzmi: najpierw sprawdź, co daje hosting, a dopiero potem decyduj o wtyczce.

Jeśli hosting zapewnia już filtrowanie ruchu, skanowanie plików i porządny backup, kolejna ciężka wtyczka w dużej mierze dubluje te funkcje — dokłada obciążenie i drugi zestaw powiadomień, a dodaje niewiele. Wtedy lepiej wypada wąskie rozwiązanie do jednej rzeczy, na przykład 2FA albo limitu prób logowania. Jeśli hosting nie daje z tego nic, jedna dobrze dobrana wtyczka bezpieczeństwa realnie podnosi poziom ochrony.

Czego nie robić w żadnym z tych wariantów: nie instaluj kilku pełnych pakietów bezpieczeństwa równocześnie. Potrafią blokować sobie nawzajem funkcje, skanowanie uruchamia się kilka razy zamiast raz, powiadomienia przychodzą podwójnie, a przy problemie z logowaniem nie wiadomo, która z nich Cię zablokowała.

Zabezpieczenia nie są też darmowe wydajnościowo — ciężki pakiet skanujący pliki w tle obciąża serwer, a to widać w czasie ładowania. Przed taką zmianą i po niej zmierz szybkość strony, żeby wiedzieć, ile Cię kosztowała.

Od czego zacząć, jeśli masz na to godzinę?

Jeśli masz dziś jedno wolne popołudnie i chcesz, żeby dało najwięcej, zrób te cztery rzeczy w tej kolejności.

• 1. Sprawdź, czy masz działający backup. Najpierw, bo każdy następny krok jest zmianą, a zmiany warto robić z punktem powrotu. Jeśli kopii nie ma albo nikt jej nigdy nie przywracał — to jest zadanie na dziś, a reszta może poczekać.
• 2. Zaktualizuj wszystko, co czeka. Zaraz po backupie, bo to jeden ruch zamykający największą liczbę znanych dziur naraz. Odwrotna kolejność byłaby ryzykiem bez zabezpieczenia.
• 3. Przejrzyj konta i usuń zbędne uprawnienia. Trzecie, bo nie zależy od żadnego narzędzia i zajmuje kilkanaście minut. Jeśli w panelu jest konto po byłym współpracowniku, to w tej chwili Twoja największa dziura — i nikt jej nie załata za Ciebie.
• 4. Włącz 2FA na koncie administratora. Na końcu, bo wymaga wtyczki i telefonu pod ręką, ale jeszcze przed odejściem od komputera — od tego momentu samo wykradzione hasło przestaje wystarczać.

Reszta listy może poczekać na kolejny wolny wieczór. Te cztery kroki pokrywają scenariusze, które zdarzają się najczęściej. Jeśli wolisz, żeby ktoś pilnował tego w stałym rytmie, zobacz, jak wygląda stała opieka techniczna nad stroną.

Czego nie robić w imię bezpieczeństwa

Część popularnych porad to środki o niewielkim efekcie, za to z konkretnym ryzykiem. Nie twierdzę, że są bezwartościowe — twierdzę, że nie powinny być pierwsze.

Zmiana prefiksu bazy danych na działającej stronie

Rada wraca w poradnikach regularnie, często jako jeden z pierwszych punktów. Sama dokumentacja WordPressa umieszcza ją jednak w sekcji „security through obscurity” i opisuje takie podejście jako to, które generalnie nie sprawdza się jako główna strategia.

Praktycznie: operacja wymaga jednoczesnych zmian w bazie i w konfiguracji. Wykonana niedokładnie kończy się stroną, która przestaje się otwierać, albo panelem, do którego nie da się zalogować — bo uprawnienia zapisane są w tabelach, których nazwy właśnie się zmieniły. Świadomie nie podaję instrukcji: to nie jest zadanie do zrobienia z poradnika, na produkcyjnej stronie, wieczorem.

Ukrywanie wersji WordPressa jako główne zabezpieczenie

Usunięcie numeru wersji ze źródła strony nie zmienia tego, czy podatność istnieje. Jeśli wtyczka ma lukę, ma ją niezależnie od tego, czego bot dowie się z nagłówka — a i tak może to sprawdzić inaczej.

To znów „security through obscurity”: utrudnienie rozpoznania zamiast usunięcia problemu. Jako drobny dodatek — w porządku. Jako powód, żeby nie zaktualizować wtyczki, bo „przecież wersja jest ukryta” — poważny błąd.

Wklejanie przypadkowych reguł .htaccess z internetu

Reguły serwera potrafią pomóc, ale plik .htaccess ma nieprzyjemną cechę: pojedynczy błąd składni nie daje ostrzeżenia, tylko zwraca błąd serwera na całej stronie. Reguła skopiowana z komentarza pod artykułem może pochodzić z innej konfiguracji, być sprzed lat albo blokować coś, z czego Twoja strona korzysta.

Dlatego nie podaję tu gotowych reguł. Jeśli decydujesz się na takie zmiany, rób je ze świeżą kopią pliku, jedną zmianą naraz i sprawdzeniem strony po każdej — albo zostaw to komuś, kto zna konfigurację danego serwera.

Instalowanie kilku pełnych wtyczek bezpieczeństwa

Najczęstszy odruch po przeczytaniu artykułu o bezpieczeństwie: skoro jedna wtyczka chroni, to dwie ochronią lepiej. Nie ochronią — powody rozpisałem wyżej.

Wyłączanie XML-RPC bez sprawdzenia zależności

XML-RPC to starszy interfejs, przez który zewnętrzne programy komunikują się z WordPressem, i bywa wykorzystywany przy atakach na logowanie. Dlatego „wyłącz XML-RPC” stało się poradą podawaną odruchowo. Problem w tym, że nadal korzystają z niego konkretne rzeczy — część aplikacji mobilnych i niektóre integracje. Wyłączenie na ślepo potrafi po cichu zepsuć coś, co działało, a objaw pojawi się za tydzień i nikt nie połączy go z tą zmianą.

Sytuacja zmieniła się przy tym od WordPressa 5.6, który wprowadził hasła aplikacji jako wbudowany sposób uwierzytelniania dla zewnętrznych narzędzi. Działają wyłącznie dla połączeń nieinteraktywnych, czyli XML-RPC i REST API — nie da się ich użyć do zalogowania przez formularz ani do wejścia do panelu. To daje nowoczesną alternatywę dla integracji. Kolejność jest więc taka: najpierw sprawdź, czy coś z XML-RPC korzysta, potem decyduj.

Checklista bezpieczeństwa WordPress

Do przejścia raz na kwartał. Jeśli przy którymś punkcie odpowiedź brzmi „chyba tak” — potraktuj to jak „nie” i sprawdź.

Kiedy potrzebna jest pomoc specjalisty?

Cztery rzeczy, które w rozmowach zlewają się w jedno, a różnią się i zakresem, i kosztem.

Rutynowa administracja to praca powtarzalna: aktualizacje w stałym rytmie, kopie zapasowe, monitoring, sprawdzenie strony po zmianach. Da się to robić samodzielnie, jeśli masz jedną prostą stronę i pół godziny w miesiącu.

Zabezpieczenie strony to jednorazowe uporządkowanie: przegląd kont i uprawnień, konfiguracja 2FA i ochrony logowania, ustawienie sensownego backupu, usunięcie tego, co zbędne. Zwykle zadanie na kilka godzin i też wykonalne samodzielnie, jeśli podchodzisz do tego spokojnie i z kopią zapasową.

Diagnostyka infekcji to już inna praca. Ustalenie, czy strona jest zainfekowana, którędy weszło i co zostało zmodyfikowane, wymaga dostępu do logów serwera i doświadczenia w ich czytaniu. Tu kończy się to, co da się zrobić z panelu WordPressa.

Pełne czyszczenie malware i odzyskiwanie po włamaniu to najcięższa kategoria: usunięcie złośliwego kodu z plików i bazy, zamknięcie drogi wejścia, sprawdzenie, czy nie zostawiono ukrytego dostępu, i zdjęcie ostrzeżeń w wyszukiwarce. To praca projektowa i wyceniana osobno — również u mnie. Nie jest częścią standardowego abonamentu opieki i uczciwie jest to powiedzieć wprost.

Granica jest prosta: zapobieganie zwykle da się zrobić samodzielnie, sprzątanie po infekcji zwykle nie. I dlatego pierwsze jest tańsze.

Najczęstsze pytania

Czy WordPress jest bezpieczny?

Sam rdzeń jest rozwijany i łatany przez duży zespół, więc jako oprogramowanie wypada dobrze. Ryzyko wnosi zwykle to, co dokładamy: wtyczki, motywy, konta i konfiguracja hostingu. Popularność systemu oznacza tylko tyle, że jest częściej sprawdzany przez automaty.

Czy wtyczka bezpieczeństwa wystarczy?

Nie, choć bywa pożyteczna. Wtyczka nie zaktualizuje za Ciebie porzuconego rozszerzenia, nie usunie konta byłego współpracownika i nie zrobi kopii, którą ktoś kiedyś przywrócił. Najpierw sprawdź, co daje hosting, potem dobierz jedną wtyczkę do tego, czego brakuje.

Czy zabezpieczenia mogą spowolnić stronę?

Niektóre tak — ciężkie pakiety skanujące pliki w tle potrafią zauważalnie obciążyć serwer. Ale sporo najskuteczniejszych działań nie kosztuje nic wydajnościowo: aktualizacje, unikalne hasła, 2FA i usunięcie zbędnych wtyczek raczej stronę przyspieszą.

Skąd wiadomo, że strona została zainfekowana?

Typowe sygnały to przekierowania w obce miejsca, treści, których nikt nie dodawał, nowe konta administratora, ostrzeżenie przeglądarki lub wyszukiwarki i wiadomość od hostingu o podejrzanych plikach. Część infekcji nie daje żadnych widocznych objawów — i dlatego monitoring zmian ma sens.

Czy darmowy motyw WordPress może być bezpieczny?

Tak, jeśli pochodzi z oficjalnego repozytorium i jest aktywnie rozwijany. Znaczenie ma nie cena, tylko utrzymanie: aktualny darmowy motyw jest bezpieczniejszy od płatnego, którego nikt nie tknął od trzech lat. Unikaj natomiast płatnych motywów rozdawanych poza oficjalnym kanałem.

Nie chcesz pilnować tego samodzielnie?

Zobacz, jak wygląda stała opieka techniczna nad WordPressem: aktualizacje w stałym rytmie, kopie zapasowe, podstawowy monitoring i konkretny czas pierwszej reakcji, kiedy coś przestanie działać. Opisałem tam też, co jest poza standardowym zakresem i wymaga osobnej wyceny.

Sprawdź zakres opieki technicznej