Jak przeprowadzić kontrolę stanu WordPress w celu rozwiązywania problemów (Przewodnik 2025)

Kontrola stanu WordPress to systematyczny proces diagnostyczny, który ocenia wersję PHP Twojej witryny, integralność bazy danych, aktywne wtyczki, zgodność motywów, środowisko serwera i poziom bezpieczeństwa — wszystko z poziomu panelu administracyjnego WordPress lub za pomocą dedykowanych narzędzi. Regularne przeprowadzanie tej kontroli zapobiega kaskadowym awariom, identyfikuje wąskie gardła wydajności zanim wpłyną na pozycje w rankingach oraz wykrywa luki bezpieczeństwa zanim staną się naruszeniami.

Wbudowane narzędzie Site Health (wprowadzone w WordPress 5.2) dostarcza automatyczny raport stanu oraz panel surowych informacji debugowania, który doświadczeni programiści wykorzystują jako pierwszy krok w każdym procesie rozwiązywania problemów. W połączeniu z wtyczką Health Check & Troubleshooting możesz odtwarzać problemy produkcyjne w izolowanej sesji bez ingerowania w działającą witrynę — funkcja ta eliminuje największe ryzyko w debugowaniu WordPress: psucie rzeczy dla prawdziwych odwiedzających podczas dochodzenia.

Dlaczego kontrole stanu WordPress mają większe znaczenie, niż przyznaje większość poradników

Większość poradników traktuje Site Health jako listę kontrolną do jednorazowego odhaczenia. W praktyce jest to ciągły sygnał operacyjny. Core Web Vitals Google bezpośrednio penalizuje wolne lub niestabilne witryny. Jedna przestarzała wtyczka ze znanym CVE może skutkować pełnym przejęciem witryny w ciągu kilku godzin od publicznego ujawnienia. Niezgodności wersji PHP między serwerem a minimalnym wymaganiem wtyczki po cichu degradują wydajność na długo przed wyrzuceniem błędu krytycznego.

Działanie w dobrze skonfigurowanym środowisku VPS Hosting daje Ci bezpośrednią kontrolę nad wersjami PHP, buforowaniem na poziomie serwera i wzmocnieniem bezpieczeństwa — kontrolę, której środowiska współdzielone po prostu nie mogą zapewnić. Opisany poniżej proces kontroli stanu zakłada, że masz dostęp SSH lub panel sterowania zdolny do modyfikowania ustawień na poziomie serwera, co jest właściwym punktem wyjścia dla każdego produkcyjnego wdrożenia WordPress.

Krok 1: Dostęp do wbudowanego narzędzia Site Health WordPress

Przejdź do Narzędzia > Site Health w panelu administracyjnym WordPress. WordPress natychmiast rozpocznie wykonywanie automatycznych kontroli i wypełni zakładkę Status wynikami skategoryzowanymi według ważności.

Ten krok nie wymaga żadnej wtyczki. Site Health to podstawowa funkcjonalność, a jej wyniki są generowane po stronie serwera, co oznacza, że odzwierciedlają rzeczywiste środowisko uruchomieniowe — nie symulowane.

Co Site Health faktycznie sprawdza pod maską:

• Wersja PHP, limit pamięci i maksymalny czas wykonania
• Aktywna wersja WordPress w porównaniu z najnowszą stabilną wersją
• Czy REST API jest dostępne i zwraca prawidłowe odpowiedzi
• Status wykonania zaplanowanych zadań cron (wp-cron)
• Wymuszanie HTTPS i ważność certyfikatu SSL
• Obecność pliku debug.log w publicznie dostępnej lokalizacji
• Możliwość wykonywania żądań zwrotnych (wymagana do aktualizacji w tle i instalacji wtyczek)
• Wersja serwera bazy danych i czy spełnia minimalne wymagania WordPress
• Uprawnienia plików i katalogów dla wrażliwych ścieżek

Krok 2: Prawidłowa interpretacja raportu stanu Site Health

Strona stanu kategoryzuje wyniki w trzech poziomach. Zrozumienie, co każdy poziom faktycznie oznacza — i czego nie oznacza — zapobiega zarówno samozadowoleniu, jak i niepotrzebnej panice.

Krytyczne problemy wymagające natychmiastowej uwagi:

• Przestarzała wersja PHP — PHP 7.4 osiągnął koniec wsparcia w listopadzie 2022 roku. Jego używanie oznacza brak poprawek bezpieczeństwa. WordPress 6.x oficjalnie zaleca PHP 8.1 lub 8.2.
• Nieaktywne wtyczki nadal zainstalowane — Nieaktywne wtyczki są nadal odczytywalne przez system plików i mogą zawierać podatny na exploity kod. Usuń je, nie tylko dezaktywuj.
• Zablokowane REST API — Wiele nowoczesnych wtyczek, edytor blokowy (Gutenberg) i WooCommerce zależą od dostępności REST API. Zablokowane REST API powoduje ciche awarie, które są notorycznie trudne do wyśledzenia.
• Błąd żądania zwrotnego — Jeśli WordPress nie może wykonać zwrotnego żądania HTTP do siebie, automatyczne aktualizacje w tle i zaplanowane zadania będą kończyć się cichą awarią.
• WP_DEBUG włączony na działającej witrynie — Tryb debugowania zapisuje wrażliwe dane konfiguracyjne i ślady stosu do debug.log. Jeśli ten plik znajduje się w wp-content/ bez ograniczeń dostępu na poziomie serwera, jest publicznie odczytywalny.

Często pomijany przypadek brzegowy: Site Health raportuje status „Dobry” dla buforowania obiektów, jeśli wykryto *jakiekolwiek* buforowanie obiektów — w tym oparte na plikach. Buforowanie obiektów oparte na plikach na witrynach o dużym ruchu może faktycznie zwiększyć obciążenie I/O zamiast je zmniejszyć. Właściwym rozwiązaniem jest backend Redis lub Memcached, który wymaga konfiguracji na poziomie serwera wykraczającej poza możliwości Site Health.

Krok 3: Wyodrębnienie i wykorzystanie panelu informacji debugowania

Kliknij zakładkę Informacje na stronie Site Health. Ten panel jest prawdopodobnie bardziej wartościowy do rozwiązywania problemów niż zakładka Status, ponieważ ujawnia surowe dane środowiskowe.

Kluczowe sekcje i na co zwrócić uwagę:

• WordPress — Potwierdza aktywny motyw, czy multisite jest włączony i czy WP_DEBUG jest aktywny.
• Katalogi i rozmiary — Ujawnia, czy wp-content/uploads/ urósł do rozmiarów obciążających I/O dysku lub procesy tworzenia kopii zapasowych.
• Aktywne wtyczki — Wyświetla każdą aktywną wtyczkę z jej wersją. Skonfrontuj z WordPress Vulnerability Database (wpscan.com) w poszukiwaniu znanych CVE.
• Serwer — Pokazuje wersję PHP, limit pamięci PHP, maksymalny rozmiar przesyłania, maksymalny czas wykonania i czy mod_rewrite lub równoważne przepisywanie URL jest aktywne.
• Baza danych — Potwierdza wersję MySQL lub MariaDB oraz zestaw znaków bazy danych. utf8mb4 jest wymagany dla pełnej obsługi emoji i wielojęzyczności; utf8 (3-bajtowy) po cichu obetnie niektóre znaki.
• Wtyczki Must Use — Często pomijane. Wtyczki MU ładują się przed wszystkimi innymi wtyczkami i nie można ich dezaktywować z poziomu interfejsu administracyjnego. Jeśli dostawca hostingu wstrzyknął wtyczkę MU (powszechne w przypadku hostingu zarządzanego), pojawia się tutaj.

Praktyczne zastosowanie przycisku „Skopiuj informacje o witrynie do schowka”:

Otwierając zgłoszenie do pomocy technicznej lub publikując na forum programistycznym, wklej te dane bezpośrednio. Eliminuje to wymianę pytań o podstawowe informacje o środowisku i pozwala doświadczonym inżynierom natychmiast wykryć anomalie konfiguracyjne — na przykład memory_limit wynoszący 40M gdy WooCommerce wymaga minimum 128M, lub max_execution_time wynoszący 30 sekund gdy duży proces importu wymaga 300.

Krok 4: Użycie wtyczki Health Check & Troubleshooting do debugowania w trybie bezpiecznym

Wtyczka Health Check & Troubleshooting (dostępna bezpłatnie w repozytorium wtyczek WordPress) umożliwia tryb bezpieczny z izolacją sesji. Jest to właściwa metoda diagnozowania konfliktów wtyczek i motywów na działającej witrynie produkcyjnej.

Jak technicznie działa izolacja sesji:

Wtyczka ustawia plik cookie przeglądarki, który WordPress odczytuje przy każdym żądaniu. Gdy plik cookie jest obecny, WordPress ładuje tylko domyślny motyw i dezaktywuje wszystkie nieistotne wtyczki — ale *tylko dla sesji przeglądarki posiadającej ten plik cookie*. Wszyscy pozostali odwiedzający doświadczają witryny dokładnie tak, jak było przed. Nie jest to środowisko stagingowe; jest to filtr uruchomieniowy stosowany na poziomie bootstrapu WordPress.

Instalacja i aktywacja:

# If you have WP-CLI available on your server (recommended)
wp plugin install health-check --activate

Lub przejdź do Wtyczki > Dodaj nową, wyszukaj „Health Check & Troubleshooting” i kliknij Zainstaluj teraz, a następnie Aktywuj.

Uruchamianie sesji rozwiązywania problemów:

1. Przejdź do Narzędzia > Site Health i kliknij zakładkę Rozwiązywanie problemów.
2. Kliknij Włącz tryb rozwiązywania problemów. Twoja sesja działa teraz ze wszystkimi dezaktywowanymi wtyczkami i aktywnym domyślnym motywem (Twenty Twenty-Four od WordPress 6.5+).
3. Odtwórz problem. Jeśli zniknął, odpowiada za niego wtyczka lub motyw.
4. Ponownie włączaj wtyczki jedna po drugiej, korzystając z listy wtyczek w zakładce Rozwiązywanie problemów. Po włączeniu każdej z nich przeładuj stronę, której dotyczy problem, i przetestuj.
5. Gdy problem pojawi się ponownie, ostatnio włączona wtyczka jest źródłem konfliktu.
6. Kliknij Wyłącz tryb rozwiązywania problemów, aby przywrócić pełne środowisko produkcyjne.

Przypadki brzegowe i pułapki:

• Jeśli problem utrzymuje się nawet w trybie bezpiecznym (brak wtyczek, domyślny motyw), problem leży na poziomie serwera lub rdzenia WordPress — nie jest to konflikt wtyczek. Sprawdź następnie php_error.log i dziennik debugowania WordPress.
• Wtyczki MU nie są dezaktywowane przez tryb bezpieczny. Jeśli podejrzewasz wtyczkę MU, musisz ręcznie zmienić jej nazwę w wp-content/mu-plugins/ przez SFTP lub SSH.
• Plik cookie rozwiązywania problemów jest specyficzny dla przeglądarki. Jeśli testujesz na urządzeniu mobilnym, musisz osobno włączyć tryb rozwiązywania problemów w tej sesji przeglądarki.

Krok 5: Diagnozowanie i rozwiązywanie konfliktów wtyczek i motywów

Konflikty wtyczek dzielą się na dwie kategorie wymagające różnych strategii rozwiązania:

Typ 1: Bezpośrednie konflikty PHP — Dwie wtyczki próbują zdefiniować tę samą funkcję lub klasę. Powoduje to natychmiastowy błąd krytyczny. Dziennik błędów będzie zawierał Cannot redeclare function lub Cannot redeclare class.

Typ 2: Ciche konflikty behawioralne — Dwie wtyczki podpinają się pod tę samą akcję lub filtr WordPress i generują nieoczekiwane dane wyjściowe lub uszkodzenie danych bez wyrzucania błędu. Są one znacznie trudniejsze do zdiagnozowania i wymagają metodycznej izolacji jedna po drugiej.

Proces rozwiązywania:

# Check the WordPress debug log for fatal errors
tail -n 100 /path/to/wp-content/debug.log

# Enable WP_DEBUG temporarily via wp-config.php if debug.log is empty
# Add these lines to wp-config.php before the "stop editing" comment:
# define('WP_DEBUG', true);
# define('WP_DEBUG_LOG', true);
# define('WP_DEBUG_DISPLAY', false);

Gdy wtyczka jest potwierdzonym źródłem konfliktu:

1. Sprawdź dziennik zmian wtyczki pod kątem niedawnej aktualizacji rozwiązującej konflikt.
2. Przeszukaj forum wsparcia wtyczki na wordpress.org w poszukiwaniu zgłoszeń tego samego konfliktu.
3. Jeśli nie ma dostępnej poprawki, znajdź alternatywną wtyczkę o równoważnej funkcjonalności.
4. Jeśli wtyczka jest krytyczna dla działalności, skontaktuj się z autorem wtyczki, podając konkretny błąd z dziennika debugowania — dołącz wersję PHP, wersję WordPress oraz nazwę i wersję konfliktującej wtyczki.

Krok 6: Aktualizacja wersji PHP i serwera bazy danych

Jest to pojedyncze działanie konserwacyjne o największym wpływie zarówno na wydajność, jak i bezpieczeństwo. PHP 8.1 i 8.2 zapewniają mierzalne ulepszenia przepustowości w porównaniu z PHP 7.4 — testy porównawcze konsekwentnie wykazują 20–30% szybsze wykonanie dla typowych obciążeń WordPress dzięki kompilacji JIT i ulepszonemu zachowaniu OPcache.

Macierz zgodności wersji PHP dla WordPress:

Aktualizacja PHP przez cPanel (dla środowisk VPS z cPanel):

1. Zaloguj się do WHM (dostęp root) lub cPanel (poziom użytkownika, jeśli MultiPHP Manager jest włączony).
2. Przejdź do MultiPHP Manager w sekcji Oprogramowanie.
3. Wybierz swoją domenę i wybierz docelową wersję PHP z listy rozwijanej.
4. Kliknij Zastosuj.

Aktualizacja PHP przez wiersz poleceń (Ubuntu/Debian):

# Add the Ondrej PHP PPA (Ubuntu)
sudo add-apt-repository ppa:ondrej/php
sudo apt update

# Install PHP 8.2 with common WordPress extensions
sudo apt install php8.2 php8.2-mysql php8.2-curl php8.2-gd php8.2-mbstring 
  php8.2-xml php8.2-zip php8.2-intl php8.2-bcmath php8.2-imagick

# Switch the CLI default (if using WP-CLI)
sudo update-alternatives --set php /usr/bin/php8.2

Krytyczny krok przed aktualizacją: Przed zmianą wersji PHP w środowisku produkcyjnym przetestuj swój motyw i każdą aktywną wtyczkę pod kątem nowej wersji. Użyj WP-CLI w środowisku stagingowym:

wp core check-update
wp plugin list --update=available --format=table
wp theme list --update=available --format=table

Kwestie dotyczące wersji bazy danych:

WordPress wymaga MySQL 5.7+ lub MariaDB 10.3+. MariaDB 10.6 i 10.11 (LTS) to aktualnie zalecane wersje. Używanie starszej wersji serwera bazy danych wprowadza zarówno zagrożenia bezpieczeństwa, jak i brak ulepszeń optymalizatora zapytań wpływających na witryny z dużymi tabelami wpisów lub wolumenami zamówień WooCommerce.

-- Check current database version from within WordPress or phpMyAdmin
SELECT VERSION();

-- Check table storage engines (InnoDB is required for full-text search and transactions)
SELECT TABLE_NAME, ENGINE FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'your_wordpress_database';

Jeśli jakiekolwiek tabele pokazują MyISAM jako silnik, przekonwertuj je na InnoDB dla lepszego odzyskiwania po awarii i wydajności równoczesnych zapisów:

ALTER TABLE wp_options ENGINE=InnoDB;

Krok 7: Pomiar i optymalizacja wydajności witryny

Site Health nie mierzy wydajności front-endu — wymaga to zewnętrznych narzędzi. Użyj Google PageSpeed Insights (mierzy Core Web Vitals w rzeczywistych warunkach), GTmetrix (analiza kaskadowa) i WebPageTest (wiele lokalizacji, zaawansowana konfiguracja) jako uzupełniających narzędzi.

Optymalizacja wydajności według warstwy:

Warstwa serwera:

• Włącz OPcache dla buforowania kodu bajtowego PHP. Na prawidłowo skonfigurowanym VPS samo to zmniejsza czas wykonania PHP o 40–60%.

; Add to php.ini or a custom .ini file
opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.revalidate_freq=60
opcache.jit_buffer_size=100M
opcache.jit=1255

• Użyj Redis do trwałego buforowania obiektów. Zainstaluj pakiet redis-server i wtyczkę WordPress Redis Object Cache, a następnie dodaj do wp-config.php:

define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_CACHE', true);

Warstwa aplikacji:

• Optymalizacja obrazów — Używaj formatu WebP z alternatywami JPEG/PNG. Wtyczki Imagify lub ShortPixel obsługują masową konwersję i automatyczne dostarczanie WebP przez reguły przepisywania .htaccess.
• Leniwe ładowanie — WordPress 5.5+ automatycznie dodaje loading="lazy" do obrazów, ale sprawdź, czy nie jest to nadpisywane przez Twój motyw.
• Optymalizacja bazy danych — Uruchamiaj OPTIMIZE TABLE na tabelach o dużej rotacji (wp_options, wp_postmeta) co miesiąc. Wtyczka WP-Optimize automatyzuje to zadanie.

# Optimize all WordPress tables via WP-CLI
wp db optimize

• Wtyczki buforowania — W3 Total Cache z backendem Redis lub WP Rocket (premium) to dwie najbardziej zaawansowane opcje. Unikaj jednoczesnego uruchamiania dwóch wtyczek buforowania — będą ze sobą konfliktować.

Integracja CDN:

CDN odciąża dostarczanie statycznych zasobów i zmniejsza TTFB dla geograficznie rozproszonych odwiedzających. Bezpłatny poziom Cloudflare zapewnia odpowiednią funkcjonalność CDN dla większości witryn. W przypadku witryn bogatych w multimedia BunnyCDN oferuje lepszą wydajność w stosunku do ceny. Skonfiguruj swój CDN tak, aby agresywnie buforował statyczne zasoby, ale wykluczał panel administracyjny WordPress (/wp-admin/) i wszelkie dynamiczne punkty końcowe.

Krok 8: Wzmocnienie bezpieczeństwa i ustanowienie rutyny monitorowania podatności

Bezpieczeństwo nie jest jednorazową konfiguracją — jest to ciągła praktyka operacyjna. Narzędzie Site Health wykrywa niektóre problemy bezpieczeństwa, ale nie wykonuje skanowania podatności.

Warstwowe podejście do bezpieczeństwa:

Na poziomie serwera (wymaga dostępu do VPS lub serwera dedykowanego):

# Disable XML-RPC if not required (common attack vector for brute force amplification)
# Add to .htaccess
# <Files xmlrpc.php>
#   Order Deny,Allow
#   Deny from all
# </Files>

# Restrict wp-config.php access
chmod 600 /path/to/wp-config.php

# Verify file permissions across the WordPress installation
find /path/to/wordpress/ -type f -name "*.php" -perm /022
# Any PHP file writable by group or world is a security risk

Na poziomie aplikacji:

• Wordfence Security — Zapewnia zaporę aplikacji webowych (WAF), skaner złośliwego oprogramowania i kanał informacji o zagrożeniach w czasie rzeczywistym. Bezpłatny poziom jest wystarczający dla większości witryn; poziom premium dodaje aktualizacje reguł zapory w czasie rzeczywistym.
• Ograniczanie prób logowania — Wtyczka Limit Login Attempts Reloaded lub wbudowana ochrona przed atakami brute force Wordfence. Ustaw blokadę po 3–5 nieudanych próbach.
• Uwierzytelnianie dwuskładnikowe — Wymuś 2FA dla wszystkich kont administratora za pomocą wtyczek WP 2FA lub Google Authenticator.
• Wymuszanie SSL/HTTPS — Każda witryna WordPress musi działać przez HTTPS. Uzyskaj i zainstaluj certyfikat SSL; jeśli go potrzebujesz, Certyfikaty SSL od Twojego dostawcy hostingu są najprostszą ścieżką. Dodaj następujące elementy do wp-config.php, aby wymusić HTTPS na poziomie aplikacji:

define('FORCE_SSL_ADMIN', true);

I w .htaccess:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Automatyczne monitorowanie podatności:

Subskrybuj alerty e-mail WPScan Vulnerability Database dla używanych przez Ciebie wtyczek. Narzędzie WPScan CLI można zintegrować z zadaniem cron, aby powiadamiać Cię o opublikowaniu nowego CVE dla dowolnej zainstalowanej wtyczki:

# Install WPScan (requires Ruby)
gem install wpscan

# Run a vulnerability scan against your site
wpscan --url https://yourdomain.com --api-token YOUR_API_TOKEN 
  --enumerate vp,vt,u --plugins-detection aggressive

Kopie zapasowe bazy danych jako mechanizm kontroli bezpieczeństwa:

Czysta, aktualna kopia zapasowa jest Twoim najbardziej niezawodnym mechanizmem odzyskiwania po kompromitacji. Automatyzuj codzienne kopie zapasowe do lokalizacji poza serwerem (magazyn obiektów kompatybilny z S3, zdalny SFTP). Wtyczka UpdraftPlus niezawodnie to obsługuje. Weryfikuj procedury przywracania kwartalnie — kopia zapasowa, której nigdy nie testowałeś, nie jest kopią zapasową.

Kontrola stanu WordPress: macierz decyzyjna i kluczowe wnioski

Użyj tej macierzy, aby określić właściwe działanie na podstawie tego, co raportuje Site Health:

Lista kontrolna operacyjna dla bieżącego stanu WordPress:

• Przeprowadzaj miesięczny przegląd stanu Site Health; traktuj wyniki Krytyczne jako incydenty.
• Utrzymuj PHP na obsługiwanej wersji (minimum 8.1; preferowane 8.2 lub 8.3).
• Usuwaj nieaktywne wtyczki i motywy — nie tylko je dezaktywuj.
• Włącz buforowanie obiektów Redis na każdej witrynie z ponad 500 codziennymi odwiedzającymi.
• Automatyzuj codzienne kopie zapasowe bazy danych poza serwerem z weryfikowanym testowaniem przywracania.
• Subskrybuj alerty o podatnościach dla każdej wtyczki i motywu w swoim stosie.
• Wymuszaj HTTPS w całej witrynie i ustaw FORCE_SSL_ADMIN w wp-config.php.
• Używaj WP-CLI do zbiorczych aktualizacji i operacji na bazie danych — jest szybszy i skryptowalny.
• Na Serwerze Dedykowanym lub VPS skonfiguruj zadanie cron po stronie serwera zamiast polegać na wp-cron — wp-cron uruchamia się tylko gdy odwiedzający trafi na witrynę, co czyni go zawodnym na witrynach o małym ruchu.

# Replace wp-cron with a real cron job (add to crontab)
# First, disable wp-cron in wp-config.php:
# define('DISABLE_WP_CRON', true);

# Then add to crontab (crontab -e):
*/15 * * * * php /path/to/wordpress/wp-cron.php > /dev/null 2>&1
# Or with WP-CLI (preferred):
*/15 * * * * wp --path=/path/to/wordpress cron event run --due-now > /dev/null 2>&1

Jeśli oceniasz środowiska hostingowe dla wdrożenia WordPress, Panele sterowania VPS zapewniają dostęp na poziomie serwera niezbędny do wdrożenia każdej optymalizacji i środka wzmocnienia bezpieczeństwa opisanego w tym przewodniku — zarządzanie wersjami PHP, konfiguracja Redis, cron po stronie serwera i reguły zapory wymagają dostępu root lub sudo, którego środowiska współdzielone nie zapewniają.

FAQ

Jaka jest różnica między zakładką Status a zakładką Informacje w Site Health?

Zakładka Status wykonuje automatyczne kontrole i kategoryzuje wyniki według ważności (Dobry, Zalecany, Krytyczny). Zakładka Informacje wyświetla surowe dane środowiskowe — konfigurację PHP, aktywne wtyczki z wersjami, szczegóły bazy danych i rozmiary katalogów — bez żadnej oceny zaliczenia/niezaliczenia. Zakładka Informacje jest używana głównie do ręcznej diagnozy i udostępniania inżynierom wsparcia.

Czy włączenie trybu rozwiązywania problemów wpływa na żywych odwiedzających?

Nie. Tryb rozwiązywania problemów używa pliku cookie przeglądarki, aby zastosować środowisko trybu bezpiecznego wyłącznie do Twojej sesji. Odwiedzający bez pliku cookie doświadczają witryny normalnie. Jedynym wyjątkiem jest sytuacja, gdy błąd krytyczny w wtyczce sam w sobie powoduje awarię procesu serwera — w takim przypadku wszyscy odwiedzający są dotknięci niezależnie od stanu aktywacji wtyczki w Twojej sesji.

Której wersji PHP powinienem używać dla WordPress w 2025 roku?

PHP 8.2 to zalecana wersja dla produkcyjnych witryn WordPress w 2025 roku. Jest aktywnie utrzymywana z poprawkami bezpieczeństwa, oferuje mierzalne ulepszenia wydajności w porównaniu z 8.0 i 8.1 oraz jest obsługiwana przez wszystkie główne wtyczki WordPress. PHP 8.3 jest stabilny i odpowiedni dla nowych wdrożeń, ale przed aktualizacją istniejącej witryny sprawdź zgodność wtyczek.

Dlaczego Site Health raportuje „Dobry” gdy moja witryna jest wyraźnie wolna?

Site Health sprawdza konfigurację i poziom bezpieczeństwa — nie mierzy wskaźników wydajności front-endu, takich jak Largest Contentful Paint (LCP) czy Time to First Byte (TTFB). Witryna może przejść wszystkie kontrole Site Health i nadal słabo wypadać w Core Web Vitals z powodu niezoptymalizowanych obrazów, braku warstwy buforowania, wolnej bazy danych lub geograficznie odległego serwera. Użyj Google PageSpeed Insights lub WebPageTest do pomiaru wydajności.

Jak naprawić błąd żądania zwrotnego w WordPress Site Health?

Błąd zwrotny oznacza, że WordPress nie może wykonać żądania HTTP do własnego URL z serwera. Typowe przyczyny to: zapora blokująca połączenia wychodzące z procesu serwera WWW, wpis w pliku hosts błędnie kierujący domenę, błąd certyfikatu SSL w żądaniu zwrotnym lub wtyczka bezpieczeństwa blokująca żądanie. Zacznij od tymczasowego wyłączenia wtyczki bezpieczeństwa i ponownego uruchomienia Site Health. Jeśli to rozwiąże problem, dodaj własny IP serwera do białej listy w ustawieniach zapory wtyczki bezpieczeństwa.