Nieaktualny WordPress — czym grozi i jak bezpiecznie go zaktualizować

Aktualizacja: 18.10.2026

Wersja WordPressa sama w sobie nie wpływa na pozycje w Google. Problemem jest bezpieczeństwo: luki w starych wersjach są publicznie opisane i automaty masowo szukają stron, które ich nie załatały. Zhakowana strona dostaje ukryte podstrony ze spamem, wstrzyknięte linki albo przekierowania, a włamywacz potrafi nawet dodać się jako właściciel w Google Search Console — i to już potrafi wyrzucić stronę z wyników.

Co dokładnie wykrył audyt

Audyt sprawdza wersję tylko na stronach zbudowanych na WordPressie (także z WooCommerce). Odczytuje ją z kodu strony — z metatagu generator albo z dopisku ?ver= przy plikach rdzenia WordPressa — i porównuje z najnowszym wydaniem podawanym przez oficjalne API wordpress.org.

Nieaktualny WordPress — poważne. Wykryta wersja jest starsza niż najnowsza i nie da się jej uznać za załataną. Jeśli audyt dopisuje, że brakuje poprawek bezpieczeństwa wydanych już dla Twojej gałęzi (np. masz 6.8.2, a dla serii 6.8 wyszła już 6.8.11), to znaczy, że nie działają nawet automatyczne aktualizacje bezpieczeństwa — to sytuacja najpilniejsza.
Starsza seria, ale załatana — do poprawy. Masz starszą serię (np. 6.8), ale z ostatnią wydaną dla niej poprawką bezpieczeństwa. Ryzyko jest mniejsze niż przy braku łatek, ale WordPress oficjalnie wspiera tylko najnowszą wersję, więc zaplanuj aktualizację (najpierw kopia zapasowa).
Aktualny WordPress — w porządku. Wersja jest równa najnowszej.
Strona ukrywa wersję — informacja. Audyt nie znalazł numeru wersji, więc nie może ocenić, czy jest aktualna. To nie znaczy, że jest dobrze — sprawdź to sam w panelu (niżej).
Nie udało się sprawdzić — informacja. Audyt odczytał wersję, ale nie zdołał pobrać listy wydań z wordpress.org, więc nie porównał jej z najnowszą. Sprawdź wersję w panelu albo uruchom audyt ponownie.

Warto wiedzieć: WordPress oficjalnie wspiera tylko najnowszą wersję. Zespół bezpieczeństwa zwykle przenosi poprawki także do starszych serii, ale dokumentacja WordPressa wprost mówi, że starsze wersje nie są utrzymywane. Dlatego audyt traktuje jako aktualną tylko najnowszą wersję, a starszą serię — nawet w pełni załataną — oznacza jako do poprawy.

Dlaczego to problem dla widoczności w Google

Google opisuje zhakowane treści w swoich zasadach dotyczących spamu: to treści dodane bez zgody właściciela przez lukę w zabezpieczeniach — wstrzyknięty kod, podstrony ze spamem, ukryte linki, przekierowania. Skutki dla strony bywają poważne:

w wynikach wyszukiwania pojawiają się tysiące obcych podstron (apteka, kasyno, podróbki), a Twoje strony tracą widoczność;
przeglądarki i Google pokazują ostrzeżenie o niebezpiecznej witrynie;
w Google Search Console pojawia się zgłoszenie w raporcie Problemy dotyczące bezpieczeństwa;
włamywacz weryfikuje się jako właściciel w Search Console i np. zgłasza własną mapę witryny albo usuwa Twoje adresy z wyników.

Nieaktualne są przy tym nie tylko rdzeń, ale też wtyczki i motywy — to one są najczęstszą drogą włamania. Aktualizacja samego WordPressa przy zostawionych starych wtyczkach rozwiązuje połowę problemu.

Jak sprawdzić wersję samemu

W panelu: Kokpit → Aktualizacje. Na górze zobaczysz, którą wersję masz i czy jest dostępna nowsza (przycisk „Zaktualizuj do wersji…”). Na tym samym ekranie są oczekujące aktualizacje wtyczek, motywów i tłumaczeń.
Szczegóły: Narzędzia → Stan witryny → zakładka Informacja. W sekcji WordPress znajdziesz wersję i ustawienia automatycznych aktualizacji, a w sekcji Serwer — wersję PHP, która przyda się za chwilę.
Bez logowania: otwórz stronę, naciśnij Ctrl+U (podgląd źródła) i wyszukaj generator albo wp-includes — przy plikach rdzenia zwykle stoi ?ver= z numerem wersji.
Z konsoli serwera (jeśli masz dostęp SSH i WP-CLI): wp core version.

Najnowszą wersję sprawdzisz na stronie wordpress.org/download/releases.

Jak bezpiecznie zaktualizować

1. Kopia zapasowa — zawsze najpierw

Kopia musi obejmować dwie rzeczy: pliki (cały katalog WordPressa, przede wszystkim wp-content i wp-config.php) oraz bazę danych. Możesz ją zrobić w panelu hostingu (większość firm hostingowych ma kopie na żądanie), wtyczką do kopii zapasowych albo ręcznie przez FTP i phpMyAdmin.

Dwie zasady, które oszczędzają nerwów:

Trzymaj kopię poza katalogiem strony (na dysku, w chmurze, w osobnym katalogu na serwerze niedostępnym z przeglądarki). Plik backup.zip albo baza.sql leżący w katalogu publicznym może pobrać każdy — razem z hasłami z wp-config.php.
Sprawdź, że kopia się otwiera (archiwum się rozpakowuje, plik bazy nie jest pusty). Kopia, której nie da się przywrócić, nie jest kopią.

2. Kopia testowa (staging), jeśli jest

Wiele firm hostingowych udostępnia jednym kliknięciem kopię testową strony. Jeśli masz taką możliwość — a zwłaszcza jeśli prowadzisz sklep na WooCommerce albo strona ma mocno przerabiany motyw — zrób całą aktualizację najpierw tam, przeklikaj najważniejsze ścieżki (strona główna, formularz kontaktowy, koszyk i zamówienie), a dopiero potem powtórz na produkcji.

3. Kolejność: wtyczki i motyw, potem rdzeń

Wtyczki — Kokpit → Aktualizacje albo Wtyczki. Przy dużych zaległościach aktualizuj po kilka, a nie wszystkie naraz — łatwiej wtedy znaleźć winowajcę, jeśli coś się zepsuje. Usuń wtyczki nieużywane i takie, których autor od lat nie wydał nowej wersji.
Motyw — Wygląd → Motywy. Jeśli ktoś wprowadzał zmiany bezpośrednio w plikach motywu (a nie w motywie potomnym), aktualizacja je nadpisze — najpierw ustal, co było zmieniane.
Rdzeń WordPressa — Kokpit → Aktualizacje → Zaktualizuj do wersji…. Na czas aktualizacji strona pokazuje komunikat o pracach konserwacyjnych; zwykle trwa to kilkanaście sekund.
Tłumaczenia — na końcu, z tego samego ekranu.

Po aktualizacji WooCommerce panel może poprosić o aktualizację bazy danych sklepu — wykonaj ją, kopia z kroku 1 Cię zabezpiecza.

Jeśli strona jest kilka głównych wersji do tyłu (np. z 5.x na 7.x), dokumentacja WordPressa zaleca aktualizować etapami, zamiast przeskakiwać wszystko naraz. Przy bardzo starych instalacjach (sprzed 4.x) to już zadanie na kilka godzin pracy, a nie jedno kliknięcie.

Z konsoli te same kroki to: wp plugin update --all, wp theme update --all, wp core update, wp core update-db.

4. Zgodność z PHP

Nowy WordPress wymaga odpowiednio nowego PHP. Obecne wydania wymagają co najmniej PHP 7.4, a WordPress zaleca PHP 8.3 lub nowsze. Jeśli PHP na serwerze jest za stare, WordPress pokaże w kokpicie ostrzeżenie, że nie będzie można go zaktualizować.

Wersję PHP zmienisz w panelu hostingu (zwykle sekcja „PHP” lub ustawienia domeny). Kolejność ma znaczenie: najpierw zaktualizuj wtyczki i motyw, bo stare wtyczki często nie działają na nowym PHP, potem podnieś PHP, a na końcu zaktualizuj rdzeń. Po zmianie PHP od razu sprawdź stronę — jeśli coś przestało działać, wróć do poprzedniej wersji PHP w tym samym panelu.

5. Automatyczne aktualizacje

Od wersji 3.7 WordPress sam instaluje wydania konserwacyjne i bezpieczeństwa (np. z 7.1.2 na 7.1.3). Od wersji 5.6 nowe instalacje mają domyślnie włączone także aktualizacje do nowych głównych wersji; starsze instalacje zachowują dawne ustawienie.

Rdzeń: Kokpit → Aktualizacje — jeśli widzisz napis, że witryna jest automatycznie aktualizowana tylko o wydania konserwacyjne i bezpieczeństwa, możesz kliknąć „Włącz automatyczne aktualizacje dla każdej nowej wersji WordPressa”.
Wtyczki: Wtyczki → kolumna „Automatyczne aktualizacje” → „Włącz automatyczne aktualizacje” przy każdej wtyczce.
Motywy: Wygląd → Motywy → kliknij motyw → „Włącz automatyczne aktualizacje”.

Jeśli audyt wykazał brak poprawek bezpieczeństwa dla Twojej serii, coś te automatyczne aktualizacje blokuje. Najczęściej to wpis w wp-config.php: define( 'AUTOMATIC_UPDATER_DISABLED', true ); albo define( 'WP_AUTO_UPDATE_CORE', false );. Taki wpis zostawia zwykle wykonawca strony „żeby nic się nie zepsuło”. Zmień go na define( 'WP_AUTO_UPDATE_CORE', 'minor' ); (same poprawki bezpieczeństwa) albo usuń. Przyczyną bywa też brak uprawnień do zapisu plików albo wyłączony cron WordPressa — wtedy sprawdź Narzędzia → Stan witryny, który podpowiada takie problemy.

Automatyczne aktualizacje nie zastępują kopii zapasowych. Jeśli je włączasz, ustaw też automatyczną kopię (codzienną lub cotygodniową) w hostingu albo wtyczce.

Co zrobić, gdy po aktualizacji coś się psuje

Komunikat „W witrynie wystąpił krytyczny błąd” — WordPress wysyła wtedy na adres administratora e-mail „Twoja witryna ma problemy techniczne” z linkiem do trybu odzyskiwania. Po zalogowaniu przez ten link zobaczysz, która wtyczka lub motyw spowodował błąd, i możesz go wyłączyć.
Nie dochodzi e-mail, panel nie działa — przez FTP lub menedżer plików hostingu zmień nazwę katalogu podejrzanej wtyczki w wp-content/plugins (np. dopisz -off). WordPress ją wyłączy. Jeśli nie wiesz, która to, zmień tak nazwę całego katalogu plugins, a potem przywracaj wtyczki po jednej.
Strona zawiesiła się na komunikacie o pracach konserwacyjnych — usuń plik .maintenance z głównego katalogu WordPressa.
Szukasz przyczyny — włącz tymczasowo w wp-config.php WP_DEBUG i WP_DEBUG_LOG (błędy trafią do wp-content/debug.log). Po diagnozie wyłącz i usuń log — nie zostawiaj go publicznie dostępnego.
Nic nie pomaga — przywróć kopię zapasową z kroku 1 (pliki i bazę razem) i poszukaj przyczyny na kopii testowej.

Nie cofaj się na stałe do starej wersji WordPressa „bo działała”. To przywraca dokładnie ten problem, który pokazał audyt. Winna jest prawie zawsze konkretna wtyczka albo motyw — tę trzeba zaktualizować, wymienić lub poprawić.

Ukrywanie wersji to nie zabezpieczenie

Popularna rada brzmi: usuń metatag generator, a nikt nie pozna wersji. Nie działa to tak, jak się wydaje:

numer wersji i tak widać w dopiskach ?ver= przy plikach rdzenia, a często też w innych miejscach — tak go znajduje również ten audyt;
automaty atakujące strony zwykle w ogóle nie sprawdzają wersji, tylko od razu próbują znanych luk na każdej napotkanej stronie z WordPressem;
dokumentacja WordPressa nazywa „bezpieczeństwo przez ukrywanie” złą strategią podstawową.

Ukrycie wersji może co najwyżej utrudnić rekonesans. Jedyne realne zabezpieczenie to aktualny rdzeń, aktualne wtyczki i motyw oraz kopie zapasowe.

Jak sprawdzić, że naprawione

Kokpit → Aktualizacje powinien pokazywać, że masz najnowszą wersję WordPressa i brak oczekujących aktualizacji wtyczek i motywów.
Przejrzyj Narzędzia → Stan witryny — krytyczne problemy (np. przestarzałe PHP, wyłączone aktualizacje) są tam wypisane.
Wyczyść cache (wtyczki cache, serwera, Cloudflare) i uruchom audyt ponownie. Najnowszą wersję audyt pobiera z wordpress.org z opóźnieniem do 12 godzin, więc tuż po premierze nowego wydania wynik może się chwilę rozjeżdżać.
W Google Search Console zajrzyj do raportu Problemy dotyczące bezpieczeństwa i do Ustawienia → Użytkownicy i uprawnienia — na liście właścicieli nie powinno być nikogo obcego.

Sama aktualizacja nie zmienia niczego w Google — nie ma na co czekać. Inaczej jest, jeśli strona już była zhakowana: wtedy trzeba usunąć wstrzyknięte treści, zmienić hasła i kliknąć Poproś o sprawdzenie w raporcie bezpieczeństwa, opisując, co zostało naprawione. Według Google rozpatrzenie prośby trwa zwykle od kilku dni do kilku tygodni. Zniknięcie spamerskich adresów z wyników może potrwać dłużej i nie da się go przyspieszyć.

Kiedy warto poprosić o pomoc

Jeśli WordPress jest kilka głównych wersji do tyłu, serwer działa na starym PHP, sklep ma dziesiątki wtyczek albo w wynikach Google widzisz podstrony, których nie tworzyłeś — to już nie jest jedno kliknięcie. W IF.PL zajmujemy się SEO i stronami WWW: możemy przeprowadzić aktualizację na kopii testowej, a przy podejrzeniu włamania oczyścić stronę i sprawdzić Search Console.