Czy małej firmie potrzebny jest WordPress? Koszty, bezpieczeństwo i alternatywa bez CMS

Strona niewielkiej firmy może przez wiele miesięcy prezentować tę samą ofertę, kilka realizacji i numer telefonu. Mimo to w jej zapleczu pojawiają się aktualizacje, odnowienia licencji i komunikaty wymagające uwagi. Właściciel firmy zaczyna się zastanawiać, czy rozbudowany system jest mu rzeczywiście potrzebny.

WordPress może być dobrym narzędziem do samodzielnego publikowania. Może też obsługiwać stronę, na której z tych możliwości prawie nikt nie korzysta. Ocena zależy od potrzeb firmy, jakości wykonania i sposobu utrzymania witryny.

Wybór warto oprzeć na trzech pytaniach: co strona ma robić, kto będzie ją zmieniał i kto odpowie za jej działanie oraz bezpieczeństwo. Dopiero potem można porównać technologie i koszty. Ten poradnik pomaga podjąć taką decyzję, również wtedy, gdy strona na WordPressie już istnieje.

1. Co właściwie daje WordPress?

WordPress jest systemem zarządzania treścią, czyli CMS. Udostępnia panel, w którym można dodawać podstrony, publikować wpisy, wstawiać zdjęcia i zarządzać dostępem innych osób. Motyw odpowiada za sposób prezentacji strony, a wtyczki rozszerzają jej możliwości.

To rozróżnienie ma znaczenie: WordPress, motyw i poszczególne wtyczki są odrębnymi składnikami. Mogą pochodzić od różnych autorów, mieć różne zasady wsparcia i wymagać osobnych aktualizacji.

Sam WordPress jest dostępny bez opłaty licencyjnej. Nie oznacza to, że bezpłatne są wykonanie witryny, hosting, płatne dodatki lub praca osoby odpowiedzialnej za utrzymanie. Funkcje publikowania, uprawnienia użytkowników i możliwość rozbudowy opisuje oficjalny polski serwis WordPressa.

Co oznacza strona bez CMS?

W prostej stronie bez CMS treść można zmieniać bezpośrednio w plikach lub w narzędziach używanych przez wykonawcę. Firma nie musi mieć panelu redakcyjnego dostępnego w internecie. Aktualizacja numeru telefonu czy opisu usługi może wtedy wymagać zlecenia zmiany.

Określenie „bez CMS” nie opisuje jednak całej konstrukcji witryny. Strona może zawierać skrypt formularza, korzystać z PHP, biblioteki JavaScript albo zewnętrznego systemu rezerwacji. Brak WordPressa nie oznacza automatycznie braku oprogramowania wymagającego utrzymania.

Istnieją także rozwiązania pośrednie, np. panel służący do przygotowywania statycznej wersji strony. W takim modelu publiczna witryna i zaplecze redakcyjne mogą być rozdzielone. To dodatkowa możliwość, ale również proces publikacji i kolejne elementy do obsługi. Nie każda mała firma ich potrzebuje.

2. Najpierw potrzeby firmy, potem technologia

Liczba podstron nie rozstrzyga, czy potrzebny jest CMS. Witryna z pięcioma podstronami może wymagać codziennej edycji cennika. Strona z kilkudziesięcioma opisami usług może przez długi czas pozostawać bez zmian.

Przed decyzją warto spisać:

• jakie informacje zmieniano w ostatnim roku i jak często;
• kto faktycznie wprowadzał te zmiany;
• które aktualizacje muszą pojawić się od razu, a które mogą poczekać;
• czy firma będzie regularnie publikować realizacje, artykuły lub ogłoszenia;
• czy potrzebne są konta klientów, płatności, rezerwacje lub integracje z innymi systemami;
• jakie nowe funkcje są rzeczywiście zaplanowane na najbliższy rok.

Panel ma wartość wtedy, gdy ktoś z niego korzysta lub potrzebuje gotowości do szybkiej edycji. Sama możliwość samodzielnego publikowania niewiele daje, jeżeli każda zmiana i tak trafia do wykonawcy.

Przykład ilustracyjny: firma instalacyjna aktualizująca ofertę dwa razy w roku może dobrze funkcjonować bez CMS. Organizator szkoleń, który co tydzień zmienia terminy i przyjmuje zapisy, ma inne potrzeby. W obu przypadkach należy ocenić cały proces, także to, czy rezerwacje obsługuje sama witryna, czy osobna usługa.

3. Jak porównać pełne koszty w ciągu trzech lat?

Porównanie ceny wykonania strony z miesięczną opłatą za opiekę prowadzi do niepełnego rachunku. Trzeba zestawić ten sam zakres funkcji i ten sam okres użytkowania.

Przy istniejącym WordPressie punktem odniesienia jest koszt dalszego korzystania z niego. Kwota zapłacona kilka lat wcześniej nie wraca po zmianie technologii. Do porównania należy natomiast włączyć potrzebne naprawy i przyszłe wydatki.

Pomocny jest prosty model:

Koszt 36 miesięcy = prace początkowe + domena i hosting + licencje + obsługa techniczna + zmiany treści + inne przewidywane prace.

Osobno warto oszacować czas własny oraz możliwe koszty przestoju. Nie należy wpisywać przewidywanej „straty po włamaniu” jako pewnej kwoty bez danych pozwalających ocenić takie ryzyko.

Przykład: przeniesienie nie zawsze zwraca się dzięki niższym opłatom

Poniższe liczby są fikcyjnym przykładem rachunku, nie cennikiem KrokDo ani badaniem stawek rynkowych. Wszystkie kwoty są brutto. Założono istniejącą stronę firmową, trzy lata użytkowania i zachowanie podobnych funkcji.

W tych założeniach przeniesienie kosztuje o 1100 zł więcej, mimo niższej opłaty za obsługę techniczną. Nie doliczono płatnych licencji ani awarii, ponieważ przykład zakłada brak takich wydatków. Obsługa techniczna nie zawiera zmian treści, dlatego pokazano je osobno.

W konkretnej firmie wynik może być odwrotny. Wystarczy inny koszt potrzebnych napraw, dodatków lub aktualizacji treści. Przy częstej edycji należy też uwzględnić czas pracownika korzystającego z panelu. Samodzielna zmiana nie zawsze wiąże się z fakturą, ale nadal zajmuje czas.

Szerszy kontekst wydatków przedstawia poradnik o kosztach strony internetowej, a kwestie infrastruktury omawia przewodnik po wyborze hostingu.

4. Bezpieczeństwo: co dokładnie może zawierać błąd?

Podatność to słabość oprogramowania lub konfiguracji, którą można wykorzystać do nieuprawnionego działania. Jej istnienie nie jest równoznaczne z udanym włamaniem. Liczą się m.in. wersja programu, dostępność danej funkcji i warunki wymagane do przeprowadzenia ataku.

W przypadku strony na WordPressie warto rozdzielić kilka obszarów:

Nie każda luka opisana jako „błąd WordPressa” znajduje się w samym WordPressie. Jednocześnie rdzeń systemu również może mieć poważne podatności. Rzetelna ocena powinna wskazywać konkretny składnik.

Liczba wtyczek jest wskazówką organizacyjną, a nie samodzielnym miernikiem bezpieczeństwa. Jeden nieutrzymywany dodatek może stanowić większy problem niż kilka potrzebnych i aktualizowanych. Ocenie podlegają również pochodzenie kodu i uprawnienia, jakie otrzymuje.

5. Co pokazują polskie komunikaty o zagrożeniach?

Podatności samego WordPressa: komunikat z sierpnia 2026

5 sierpnia 2026 r. w serwisie Gov.pl opublikowano rekomendację dotyczącą podatności WordPressa. Wskazano w niej CVE-2026-63030 oraz CVE-2026-60137. Opisane połączenie błędów mogło prowadzić do ingerencji w zapytania do bazy danych, a w konsekwencji do wykonania kodu na podatnym systemie.

Rekomendacja obejmowała aktualizację oraz sprawdzenie logów, czyli zapisów zdarzeń, pod kątem podejrzanej aktywności. To ważne rozróżnienie: udostępnienie poprawki nie potwierdza, że każda działająca witryna została już zaktualizowana. Komunikat Pełnomocnika Rządu ds. Cyberbezpieczeństwa.

Dla właściciela firmy praktyczny wniosek jest prosty: ktoś powinien śledzić komunikaty i sprawdzać, czy dotyczą używanej instalacji. Sam fakt poprawnego wyświetlania strony nie daje odpowiedzi na to pytanie.

Podatność wtyczki: W3 Total Cache

W podsumowaniu listopada 2025 r. CERT Polska opisał aktywnie wykorzystywaną podatność CVE-2025-9501 we wtyczce W3 Total Cache. Dotyczyła możliwości wykonania poleceń PHP przez osobę bez uprawnionego dostępu, po przesłaniu odpowiednio przygotowanego komentarza. Według raportu poprawkę wprowadzono w wersji 2.8.13. CERT Polska/CSIRT NASK, podsumowanie nr 3/2025, s. 10.

To przykład historyczny dotyczący konkretnego dodatku i podatnych wersji. Nie oznacza, że każda strona z WordPressem była na niego podatna. Numer wersji z raportu wskazuje ówczesną poprawkę, a nie wersję zalecaną do instalacji dzisiaj.

Wniosek: opieka nad witryną powinna obejmować również dodatki. Sama aktualizacja rdzenia nie zastępuje sprawdzenia całej instalacji.

Skutki przejęcia strony dotyczą także odwiedzających

W materiale opublikowanym 25 sierpnia 2026 r. CERT Orange Polska opisał wykorzystanie przejętych stron do dalszych cyberataków. Zespół wskazał, że w zebranych danych zaobserwował w poprzednim tygodniu kilkadziesiąt zmodyfikowanych stron w domenie .pl. Prezentowały one fałszywe testy „nie jestem robotem” (CAPTCHA), związane z atakami ClickFix.

W takim scenariuszu odwiedzający może zobaczyć pozorną weryfikację bezpieczeństwa, która nakłania do wykonania niebezpiecznej czynności na jego komputerze. CERT Orange: „Krajobraz Zagrożeń – 24.08.2026”.

Znaczenie biznesowe wykracza poza niedostępną stronę. Przejęta witryna może narażać klientów i podważać wiarygodność firmy. Z tych obserwacji nie można jednak obliczyć prawdopodobieństwa włamania do dowolnej strony na WordPressie.

Jak czytać doniesienia o kolejnej luce?

Pomocne są cztery pytania: jakiego składnika dotyczy błąd, które wersje obejmuje, jakie warunki umożliwiają atak i czy istnieje poprawka. Nagłówek wiadomości zwykle nie zawiera wszystkich tych informacji.

Niebezpiecznik publikuje również omówienia zagrożeń związanych z WordPressem, np. materiał z 10 sierpnia 2026 r. o ataku XSS. Takie publikacje pomagają zrozumieć problem. Przy ustalaniu wersji wymagających aktualizacji podstawą powinien być aktualny komunikat producenta lub właściwego zespołu reagowania.

6. Co zmienia rezygnacja z CMS, a jakie ryzyka pozostają?

Usunięcie publicznego panelu WordPressa, jego wtyczek i mechanizmów, których firma nie potrzebuje, ogranicza liczbę elementów wymagających ochrony. Znikają również podatności wynikające z obecności tych konkretnych składników, jeżeli rzeczywiście usunięto je z działającego środowiska.

Jest to zmniejszenie zakresu utrzymania, a nie gwarancja bezpieczeństwa. Ostateczny efekt zależy od konstrukcji nowej strony i zabezpieczeń infrastruktury.

Formularz nadal jest oprogramowaniem

Witryna bez CMS może przyjmować dane przez formularz i wysyłać wiadomości przy użyciu skryptu na serwerze. Taki mechanizm wymaga poprawnej obsługi danych, ochrony przed nadużyciami i testowania. Nie wystarcza to, że wygląda poprawnie w przeglądarce.

Jeżeli formularz obsługuje zewnętrzna usługa, część obowiązków przechodzi na dostawcę. Pozostają jednak konfiguracja, dostęp do konta, zależność od tej usługi i sprawdzenie, gdzie trafiają wiadomości.

Domena, hosting i poczta pozostają ważne

Przejęcie konta u dostawcy domeny lub hostingu może zagrozić także stronie złożonej z prostych plików. Poczta bywa używana do odzyskiwania dostępów, dlatego jej zabezpieczenie ma znaczenie dla całej firmy.

Warto stosować unikalne hasła i dodatkowe uwierzytelnianie tam, gdzie jest dostępne. Konta powinny umożliwiać odebranie dostępu konkretnej osobie bez wymiany wspólnego hasła całego zespołu. Podstawy ochrony kont opisuje poradnik CERT Polska.

Zewnętrzny skrypt może zmienić działanie strony

6 kwietnia 2013 r. Niebezpiecznik opisał incydent dotyczący własnego serwisu. Zmodyfikowany skrypt reklamowy, pobierany z serwera zewnętrznej firmy, przekierowywał część odwiedzających. Redakcja wyjaśniła, że nie wynikało to z podatności WordPressa ani włamania na jej serwer. Piotr Konieczny: „Zastanów się do których skryptów się odwołujesz”.

To historyczny przykład konkretnego mechanizmu, nie opis obecnego stanu tego serwisu. Pokazuje, dlaczego w przeglądzie bezpieczeństwa trzeba uwzględniać również zewnętrzne elementy ładowane przez stronę.

Nieznany publicznie, własny kod również może zawierać błędy. Jego autorstwo ani wykorzystanie AI do napisania witryny nie zastępują kontroli jakości. Wycena strony bez CMS powinna określać, kto będzie poprawiał wykryte problemy.

7. Jak powinna wyglądać rozsądna opieka nad stroną?

Właściciel firmy nie musi samodzielnie wykonywać prac administracyjnych. Powinien jednak wiedzieć, kto odpowiada za każdą z nich i jaki wynik potwierdza wykonanie zadania.

Aktualizacje wraz ze sprawdzeniem działania

Potrzebna jest lista używanego oprogramowania oraz ustalony sposób reagowania na komunikaty bezpieczeństwa. Pilnej poprawki nie powinno się automatycznie odkładać do odległego, comiesięcznego przeglądu.

Aktualizacja wymaga przygotowania i kontroli. Warto sprawdzić formularz, istotne podstrony i integracje oraz mieć możliwość przywrócenia działania po nieudanej zmianie. Automatyczne aktualizacje mogą pomóc, ale nie potwierdzają samodzielnie, że cały serwis nadal działa. Zasady organizacji tego procesu przedstawia CERT Polska w poradniku o aktualizacjach.

W stronie bez CMS lista może być krótsza. Nadal może obejmować kod formularza, biblioteki i środowisko serwera. Zakres prac dostawcy hostingu trzeba ustalić w warunkach usługi; nie należy zakładać, że obejmuje wszystkie elementy witryny.

Kopie, z których da się odtworzyć stronę

Kopia zapasowa powinna obejmować dane potrzebne do odtworzenia serwisu. Dla WordPressa znaczenie mają zarówno pliki, jak i baza danych. Dla strony bez CMS trzeba ustalić komplet plików, ustawień i ewentualnych danych usług dodatkowych.

Ważne są okres przechowywania, odrębne zabezpieczenie kopii oraz test odtworzenia. Informacja „hosting robi backup” nie odpowiada jeszcze na pytanie, czy po awarii można odzyskać właściwą wersję. Zalecenia CERT Polska dotyczące kopii zapasowych.

Dostępy i kontrola kontaktu

W umowie lub instrukcji obsługi warto zapisać:

• kto zarządza domeną, hostingiem i kontami usług zewnętrznych;
• jak odbierane są dostępy po zakończeniu współpracy;
• kto zauważy niedostępność strony lub niedziałający formularz;
• w jakim czasie rozpocznie się reakcja na zgłoszenie;
• które naprawy są objęte opieką, a które wymagają dodatkowej wyceny.

Najprostszy test formularza powinien kończyć się sprawdzeniem wiadomości w docelowej skrzynce. Komunikat „wysłano” na stronie nie potwierdza doręczenia.

8. Pozostawić, uporządkować czy przenieść?

Decyzja nie musi sprowadzać się do zachowania wszystkiego albo zbudowania całej strony od początku.

Uporządkowanie istniejącego WordPressa może obejmować ograniczenie zbędnych funkcji, wymianę nieutrzymywanych dodatków i lepszą organizację aktualizacji. Zakres powinien wynikać z przeglądu. Nie każdą wadę da się usunąć niewielkim nakładem.

W przypadku przeniesienia wykonawca powinien wskazać, które funkcje zostaną zachowane, które zastąpione i z których firma rezygnuje. Oszczędność wynikająca z utraty potrzebnej funkcji nie jest równoważna wykonaniu tej samej pracy taniej.

9. Czy strona bez WordPressa będzie szybsza i lepiej widoczna w Google?

Prosta konstrukcja daje możliwość ograniczenia ilości kodu i zasobów pobieranych przez przeglądarkę. O wyniku decyduje jednak wykonanie. Duże zdjęcia, filmy i zewnętrzne skrypty mogą spowolnić również stronę bez CMS.

Przy porównaniu warto sprawdzić działające wersje z podobną treścią, na telefonie i komputerze. Ocena powinna obejmować także czytelność, wygodę kontaktu i dostępność informacji. Szybko otwierająca się strona może nadal źle wyjaśniać ofertę.

Sama zmiana technologii nie jest podstawą do obietnicy wyższej pozycji w Google. Potrzebne są dostępne dla wyszukiwarki treści, poprawne adresy i zachowanie informacji istotnych dla klientów. Wtyczka SEO może ułatwiać zarządzanie ustawieniami, ale jej obecność nie zastępuje dobrej oferty i treści.

Jeżeli głównym problemem jest brak klientów, warto najpierw przejść przez diagnozę strony, która nie przynosi zapytań. Przeniesienie witryny nie naprawi automatycznie niedopasowanej oferty lub braku sposobu docierania do odbiorców.

10. Jak przygotować przeniesienie strony?

Zmiana systemu nie wymaga automatycznie zmiany domeny ani adresów podstron. Warto zachować działające adresy, jeżeli nie ma konkretnej przyczyny ich przebudowy.

Przed rozpoczęciem prac potrzebne są spis podstron, kopia obecnej witryny oraz lista funkcji. Trzeba uwzględnić także rzeczy mniej widoczne: wiadomości z formularza, pliki do pobrania, pomiar zdarzeń i połączenia z usługami zewnętrznymi.

Jeżeli adresy muszą się zmienić, należy przypisać starym podstronom odpowiednie nowe adresy i przygotować trwałe przekierowania. Google odradza przekierowywanie wielu różnych podstron na niepasującą stronę główną. Zaleca też unikanie jednoczesnych, zbędnych zmian i obserwację wyników po migracji. Polska dokumentacja Google dotycząca przenoszenia witryn.

Co powinien obejmować odbiór?

• Porównanie treści i funkcji z uzgodnionym zakresem.
• Sprawdzenie starych adresów oraz przygotowanych przekierowań.
• Test menu, numerów telefonu, formularzy i wiadomości w skrzynce.
• Kontrolę na telefonie i komputerze, również po przeładowaniu strony.
• Sprawdzenie ustawień indeksowania, mapy witryny i narzędzi pomiarowych.
• Przekazanie plików oraz instrukcji aktualizacji i odtworzenia.

Jeżeli zmienia się również hosting, osobnego sprawdzenia wymaga poczta firmowa. Przeniesienie plików WWW nie oznacza przeniesienia skrzynek i wszystkich ustawień domeny.

Warto ustalić moment uruchomienia, sposób cofnięcia nieudanej zmiany i osobę odpowiedzialną za kontrolę po starcie. Po zakończeniu przejścia trzeba także rozliczyć los starej instalacji: pozostawiony publicznie WordPress nadal wymaga opieki. Archiwum powinno być przechowywane w odpowiednio zabezpieczonym miejscu.

Pomocna będzie lista zagadnień do umowy z wykonawcą strony. Celem jest ograniczenie ryzyka migracji; wahań widoczności nie można wykluczyć samą deklaracją wykonawcy.

11. Co zrobić, jeżeli są już oznaki włamania?

Obce przekierowania, nieznane treści, fałszywe CAPTCHA lub ostrzeżenia przy wejściu na stronę wymagają pilnego sprawdzenia. Nie należy zaczynać od zwykłego kopiowania witryny na nowy serwer.

Pierwsze działania trzeba uzgodnić z administratorem lub dostawcą hostingu:

1. Ograniczyć narażenie odwiedzających, np. przez czasowe odłączenie zainfekowanej witryny.
2. Zabezpieczyć logi i materiał potrzebny do ustalenia przebiegu incydentu.
3. Rozpoznać drogę wejścia oraz zakres nieuprawnionych zmian.
4. Odtworzyć zaufaną wersję, usunąć przyczynę i uporządkować dostępy.
5. Sprawdzić działanie oraz obserwować, czy problem nie powraca.

Sama aktualizacja może usunąć lukę, ale nie musi usunąć skutków wcześniejszego włamania. Kopia wykonana już po infekcji może zawierać niepożądane zmiany. Szczegółową procedurę przedstawia CERT Polska: „Przejęta strona internetowa”. Incydent można zgłosić przez formularz CERT Polska.

Przeniesienie na stronę bez CMS może później stanowić część odbudowy. Nie zastępuje wyjaśnienia incydentu, zwłaszcza jeśli nieuprawniony dostęp obejmował także hosting lub pocztę.

Jeżeli zdarzenie mogło objąć dane osobowe, potrzebna jest również ocena ich naruszenia i wynikających z niego obowiązków. UODO wskazuje, że zgłoszenie naruszenia zależy od oceny ryzyka dla praw lub wolności osób. Zgłoszenie do CERT Polska nie zastępuje ewentualnego zgłoszenia do organu nadzorczego. Wyjaśnienia UODO dotyczące zgłaszania naruszeń.

12. Lista kontrolna przed decyzją

Poniższa lista pomaga przygotować rozmowę z wykonawcą. Odpowiedź „nie wiadomo” oznacza informację do ustalenia, a nie automatyczne wskazanie technologii.

• Wiadomo, jakie funkcje strony są potrzebne i kto z nich korzysta.
• Ustalono, kto zmienia treści i jak szybko muszą pojawiać się aktualizacje.
• Istnieje lista używanego oprogramowania, dodatków i usług zewnętrznych.
• Wskazano osobę odpowiedzialną za aktualizacje i reakcję na komunikaty bezpieczeństwa.
• Znane są zasady przechowywania kopii i wynik ostatniego testu odtworzenia.
• Firma kontroluje dostępy do domeny, hostingu, poczty i pozostałych usług.
• Porównano koszty na trzy lata, w tym zmiany treści i potrzebne naprawy.
• Wycena przeniesienia określa zachowane funkcje i zasady ochrony istniejących adresów.
• Wiadomo, jak będzie wyglądał odbiór oraz obsługa strony po zakończeniu prac.
• Ustalono sposób przekazania strony innemu wykonawcy.

Brak osoby odpowiedzialnej za utrzymanie jest problemem organizacyjnym. Wybór prostszej strony może zmniejszyć liczbę obowiązków, ale nie sprawi, że wszystkie znikną.

13. Pytania, które warto rozstrzygnąć przed zleceniem

Czy na stronie bez CMS można prowadzić blog?

Tak, można publikować kolejne artykuły bez WordPressa. Trzeba jednak ustalić sposób przygotowania i wdrażania treści. Przy częstym publikowaniu wygodny panel może oszczędzać czas, dlatego potrzebna jest ocena całego procesu redakcyjnego.

Czy brak abonamentu oznacza brak późniejszych kosztów?

Nie. Nadal mogą występować opłaty za domenę, hosting, zmiany treści i prace techniczne. Brak stałej opłaty oznacza określony sposób rozliczania, a nie zapewnienie, że przez kolejne lata nie pojawi się żadna praca.

Czy zmiana wykonawcy wymaga nowej strony?

Nie musi. Zależy to od dostępności plików, dokumentacji, licencji i konstrukcji witryny. Zarówno przy WordPressie, jak i przy stronie bez CMS warto wymagać czytelnego przekazania projektu. Własny kod bez dokumentacji również może utrudniać dalszą współpracę.

Czy hosting zajmuje się bezpieczeństwem całej strony?

Odpowiedź zależy od zakresu usługi. Utrzymanie serwera, aktualizacja aplikacji, kontrola dodatków i usuwanie skutków włamania mogą być osobnymi zadaniami. Rozstrzygają konkretne warunki współpracy, nie nazwa pakietu.

14. Czego nie da się ustalić bez przeglądu konkretnej witryny?

Sam adres strony lub jej wygląd nie pozwalają potwierdzić wszystkich wersji oprogramowania, konfiguracji i jakości kopii zapasowych. Bez tych danych nie można rzetelnie określić kosztu naprawy ani stwierdzić, że zmiana technologii będzie tańsza.

Przywołane komunikaty potwierdzają występowanie konkretnych podatności i incydentów. Nie są badaniem porównującym prawdopodobieństwo włamania do prawidłowo utrzymywanego WordPressa i dowolnej strony bez CMS. Nie uzasadniają procentowej obietnicy zmniejszenia ryzyka.

Dobry przegląd powinien oddzielać potwierdzone problemy, kwestie wymagające sprawdzenia i rekomendowane działania. Powinien też wyjaśnić, kiedy wystarczy lepsza opieka, a jakie argumenty rzeczywiście przemawiają za przeniesieniem strony.

Rozmowa o uproszczeniu strony

Do wstępnej rozmowy wystarczą adres witryny, krótki opis problemów, lista potrzebnych funkcji oraz informacja o częstotliwości zmian treści. Pomocne będą również koszty obecnej obsługi, jeśli są znane.

Na początek nie są potrzebne hasła ani dane klientów. Celem jest ustalenie, czy warto pozostawić obecne rozwiązanie, zlecić jego uporządkowanie czy przygotować wycenę przeniesienia.

Źródła i charakter poradnika

Źródła sprawdzono 6 września 2026 r. Materiały dotyczące cyberbezpieczeństwa pochodzą z polskich instytucji, zespołów reagowania i Niebezpiecznika. Niebezpiecznik jest serwisem branżowym; jego publikacji nie należy utożsamiać z komunikatami urzędowymi.

Przykłady podatności opisują stan i zdarzenia wskazane w konkretnych publikacjach. Historyczny numer poprawki nie jest zaleceniem pozostania przy tej wersji. Bieżące decyzje o aktualizacji wymagają sprawdzenia aktualnych komunikatów dla używanego oprogramowania.

Porównanie rozwiązań, lista kontrolna i kolejność decyzji są autorską syntezą praktyczną. Przykład kosztów jest fikcyjny, a opisane firmy są ilustracyjne. Poradnik nie jest audytem bezpieczeństwa konkretnej instalacji ani gwarancją kosztu, bezawaryjności lub wyniku w Google.

1. WordPress.org Polska, „Funkcje”: możliwości publikowania, użytkownicy i rozbudowa systemu.
2. Gov.pl, Pełnomocnik Rządu ds. Cyberbezpieczeństwa, rekomendacja dotycząca podatności w WordPressie, 5.08.2026: przykład podatności rdzenia i zalecanej reakcji.
3. CERT Polska/CSIRT NASK, „Podsumowanie miesiąca”, nr 3/2025, listopad 2025, s. 10: podatność CVE-2025-9501 we wtyczce W3 Total Cache.
4. CERT Orange Polska, „Krajobraz Zagrożeń – 24.08.2026”, publikacja 25.08.2026: wykorzystanie przejętych witryn i własne obserwacje zespołu dotyczące domen .pl.
5. Niebezpiecznik, redakcja, „Nowy atak na WordPressa znaleziony przez AI: od XSS do admina i wykonania dowolnego kodu PHP”, 10.08.2026: materiał branżowy uzupełniający komunikaty techniczne.
6. Niebezpiecznik, Piotr Konieczny, „Zastanów się do których skryptów się odwołujesz”, 6.04.2013: relacja o incydencie we własnym serwisie, związanym z zewnętrznym skryptem.
7. CERT Polska, „Jak tworzyć bezpieczne hasła i chronić swoje konta”: zasady ochrony dostępów.
8. CERT Polska, „Aktualizacje”: przygotowanie, wdrażanie i sprawdzanie aktualizacji.
9. CERT Polska, „Kopie zapasowe”: ochrona kopii oraz testy odtworzenia.
10. CERT Polska, „Przejęta strona internetowa”: rozpoznanie i obsługa incydentu oraz odbudowa witryny.
11. CERT Polska, formularz zgłoszenia incydentu.
12. Google Search Central, „Przenoszenie witryny i migracja”, polska wersja dokumentacji: mapowanie adresów, przekierowania i kontrola po migracji.
13. Urząd Ochrony Danych Osobowych, „Zgłaszanie naruszeń”: znaczenie oceny ryzyka przy rozstrzyganiu obowiązku zgłoszenia.

Przy wyborze warto połączyć porównanie ofert, dobór technologii i plan struktury strony.