Як виконати перевірку стану WordPress для усунення несправностей (Посібник 2025)

Перевірка стану WordPress — це систематичний діагностичний процес, який оцінює версію PHP вашого сайту, цілісність бази даних, активні плагіни, сумісність теми, серверне середовище та стан безпеки — усе це з панелі адміністратора WordPress або за допомогою спеціальних інструментів. Регулярне виконання цієї перевірки запобігає каскадним збоям, виявляє вузькі місця продуктивності до того, як вони вплинуть на рейтинги, та виявляє вразливості безпеки до того, як вони стануть порушеннями.

Вбудований інструмент Site Health (представлений у WordPress 5.2) надає автоматизований звіт про стан та панель необробленої налагоджувальної інформації, яку досвідчені розробники використовують як першу зупинку в будь-якому процесі усунення несправностей. У поєднанні з плагіном Health Check & Troubleshooting ви можете відтворювати проблеми виробничого середовища в ізольованому сеансі, не торкаючись живого сайту — можливість, яка усуває найбільший ризик у налагодженні WordPress: зламати речі для реальних відвідувачів під час розслідування.

Чому перевірки стану WordPress мають більше значення, ніж визнає більшість посібників

Більшість посібників розглядають Site Health як контрольний список, який потрібно відмітити один раз. На практиці це безперервний операційний сигнал. Core Web Vitals від Google безпосередньо штрафують повільні або нестабільні сайти. Один застарілий плагін з відомим CVE може призвести до повного компрометування сайту протягом кількох годин після публічного розкриття. Невідповідності версій PHP між вашим сервером і мінімальними вимогами плагіна непомітно знижують продуктивність задовго до того, як вони спричинять фатальну помилку.

Робота у добре налаштованому середовищі VPS Хостингу дає вам прямий контроль над версіями PHP, кешуванням на рівні сервера та посиленням безпеки — контроль, який спільні середовища просто не можуть забезпечити. Описаний нижче процес перевірки стану передбачає, що у вас є SSH-доступ або панель керування, здатна змінювати налаштування на рівні сервера, що є правильною базовою лінією для будь-якого виробничого розгортання WordPress.

Крок 1: Доступ до вбудованого інструменту Site Health WordPress

Перейдіть до Інструменти > Site Health у панелі адміністратора WordPress. WordPress негайно почне виконувати автоматизовані перевірки та заповнить вкладку Стан результатами, категоризованими за серйозністю.

Для цього кроку не потрібен жоден плагін. Site Health є основною функціональністю, і його результати генеруються на стороні сервера, тобто вони відображають фактичне середовище виконання, а не симульоване.

Що насправді перевіряє Site Health під капотом:

• Версія PHP, ліміт пам’яті та максимальний час виконання
• Активна версія WordPress порівняно з останнім стабільним випуском
• Чи доступний REST API та чи повертає він дійсні відповіді
• Статус виконання запланованих завдань cron (wp-cron)
• Примусове використання HTTPS та дійсність SSL-сертифіката
• Наявність файлу debug.log у загальнодоступному місці
• Можливість зворотного запиту (необхідна для фонових оновлень та встановлення плагінів)
• Версія сервера бази даних та відповідність мінімальним вимогам WordPress
• Дозволи на файли та каталоги для чутливих шляхів

Крок 2: Правильна інтерпретація звіту про стан Site Health

Сторінка стану категоризує результати на три рівні. Розуміння того, що насправді означає кожен рівень — і що він не означає — запобігає як самозаспокоєнню, так і непотрібній паніці.

Критичні проблеми, що вимагають негайної уваги:

• Застаріла версія PHP — PHP 7.4 досяг кінця терміну служби у листопаді 2022 року. Його використання означає відсутність патчів безпеки. WordPress 6.x офіційно рекомендує PHP 8.1 або 8.2.
• Встановлені неактивні плагіни — Неактивні плагіни все ще доступні для читання файловою системою та можуть містити код, що піддається експлуатації. Видаліть їх, а не просто деактивуйте.
• REST API заблоковано — Багато сучасних плагінів, блоковий редактор (Gutenberg) та WooCommerce залежать від доступності REST API. Заблокований REST API призводить до прихованих збоїв, які надзвичайно важко відстежити.
• Збій зворотного запиту — Якщо WordPress не може зробити зворотний HTTP-запит до себе, автоматичні фонові оновлення та заплановані завдання будуть мовчки завершуватися невдачею.
• WP_DEBUG увімкнено на живому сайті — Режим налагодження записує чутливі дані конфігурації та трасування стека до debug.log. Якщо цей файл знаходиться в wp-content/ без обмежень доступу на рівні сервера, він загальнодоступний для читання.

Часто пропущений граничний випадок: Site Health повідомляє статус «Добре» для кешування об’єктів, якщо виявлено *будь-який* кеш об’єктів — включаючи файловий. Файлове кешування об’єктів на сайтах з великим трафіком насправді може збільшити навантаження на I/O, а не зменшити його. Правильним рішенням є бекенд Redis або Memcached, що вимагає конфігурації на рівні сервера, яку Site Health не може забезпечити.

Крок 3: Отримання та використання панелі налагоджувальної інформації

Натисніть вкладку Інформація на сторінці Site Health. Ця панель, мабуть, більш цінна для усунення несправностей, ніж вкладка Стан, оскільки вона розкриває необроблені дані середовища.

Ключові розділи та на що звертати увагу:

• WordPress — Підтверджує активну тему, чи увімкнено мультисайт та чи активний WP_DEBUG.
• Каталоги та розміри — Показує, чи виріс wp-content/uploads/ до розміру, що навантажує дисковий I/O або процеси резервного копіювання.
• Активні плагіни — Перелічує кожен активний плагін з його версією. Перехресно перевіряйте з базою даних вразливостей WordPress (wpscan.com) на наявність відомих CVE.
• Сервер — Показує версію PHP, ліміт пам’яті PHP, максимальний розмір завантаження, максимальний час виконання та чи активний mod_rewrite або еквівалентне перезаписування URL.
• База даних — Підтверджує версію MySQL або MariaDB та набір символів бази даних. utf8mb4 необхідний для повної підтримки емодзі та багатомовності; utf8 (3-байтовий) мовчки обрізатиме певні символи.
• Must Use Plugins — Часто ігнорується. MU-плагіни завантажуються перед усіма іншими плагінами та не можуть бути деактивовані з інтерфейсу адміністратора. Якщо хостинг-провайдер впровадив MU-плагін (поширено при керованому хостингу), він з’являється тут.

Практичне використання кнопки «Копіювати інформацію про сайт у буфер обміну»:

При відкритті заявки в службу підтримки або публікації на форумі розробників вставте цей вивід безпосередньо. Це усуває зайві питання про базове середовище та дозволяє досвідченим інженерам негайно помітити аномалії конфігурації — наприклад, memory_limit рівний 40M, тоді як WooCommerce вимагає мінімум 128M, або max_execution_time рівний 30 секунд, тоді як великий процес імпорту вимагає 300.

Крок 4: Використання плагіна Health Check & Troubleshooting для налагодження в безпечному режимі

Плагін Health Check & Troubleshooting (доступний безкоштовно з репозиторію плагінів WordPress) вмикає безпечний режим з ізоляцією сеансу. Це правильний метод діагностики конфліктів плагінів та тем на живому виробничому сайті.

Як технічно працює ізоляція сеансу:

Плагін встановлює файл cookie браузера, який WordPress зчитує при кожному запиті. Коли файл cookie присутній, WordPress завантажує лише тему за замовчуванням та деактивує всі несуттєві плагіни — але *лише для сеансу браузера, що несе цей файл cookie*. Всі інші відвідувачі бачать сайт точно таким, яким він був раніше. Це не середовище для тестування; це фільтр виконання, застосований на рівні завантаження WordPress.

Встановлення та активація:

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

Або перейдіть до Плагіни > Додати новий, знайдіть «Health Check & Troubleshooting» та натисніть Встановити зараз, потім Активувати.

Запуск сеансу усунення несправностей:

1. Перейдіть до Інструменти > Site Health та натисніть вкладку Усунення несправностей.
2. Натисніть Увімкнути режим усунення несправностей. Ваш сеанс тепер працює з усіма деактивованими плагінами та активною темою за замовчуванням (Twenty Twenty-Four для WordPress 6.5+).
3. Відтворіть проблему. Якщо вона зникла, відповідальний плагін або тема.
4. Повторно вмикайте плагіни по одному, використовуючи список плагінів на вкладці Усунення несправностей. Після увімкнення кожного перезавантажте відповідну сторінку та протестуйте.
5. Як тільки проблема з’явиться знову, останній увімкнений вами плагін є джерелом конфлікту.
6. Натисніть Вимкнути режим усунення несправностей, щоб відновити повне виробниче середовище.

Граничні випадки та підводні камені:

• Якщо проблема зберігається навіть у безпечному режимі (без плагінів, тема за замовчуванням), проблема знаходиться на рівні сервера або ядра WordPress — а не конфлікт плагінів. Далі перевірте php_error.log та журнал налагодження WordPress.
• MU-плагіни не деактивуються безпечним режимом. Якщо ви підозрюєте MU-плагін, вам потрібно вручну перейменувати його в wp-content/mu-plugins/ через SFTP або SSH.
• Файл cookie усунення несправностей є специфічним для браузера. Якщо ви тестуєте на мобільному пристрої, вам потрібно окремо увімкнути режим усунення несправностей у цьому сеансі браузера.

Крок 5: Діагностика та вирішення конфліктів плагінів і тем

Конфлікти плагінів поділяються на дві категорії, що вимагають різних стратегій вирішення:

Тип 1: Прямі конфлікти PHP — Два плагіни намагаються визначити однакову функцію або клас. Це негайно призводить до фатальної помилки. Журнал помилок міститиме Cannot redeclare function або Cannot redeclare class.

Тип 2: Приховані поведінкові конфлікти — Два плагіни підключаються до однієї дії або фільтра WordPress та виробляють неочікуваний вивід або пошкодження даних без виникнення помилки. Їх значно важче діагностувати, і вони вимагають методичної ізоляції по одному.

Процес вирішення:

# 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);

Коли плагін є підтвердженим джерелом конфлікту:

1. Перевірте журнал змін плагіна на наявність нещодавнього оновлення, що вирішує конфлікт.
2. Знайдіть на форумі підтримки плагіна на wordpress.org повідомлення про той самий конфлікт.
3. Якщо виправлення недоступне, знайдіть альтернативний плагін з еквівалентною функціональністю.
4. Якщо плагін є критично важливим для бізнесу, зв’яжіться з автором плагіна з конкретною помилкою з вашого журналу налагодження — вкажіть вашу версію PHP, версію WordPress та назву і версію конфліктуючого плагіна.

Крок 6: Оновлення версій PHP та сервера бази даних

Це єдина дія з обслуговування з найбільшим впливом як на продуктивність, так і на безпеку. PHP 8.1 та 8.2 забезпечують вимірювані покращення пропускної здатності порівняно з PHP 7.4 — бенчмарки стабільно показують на 20–30% швидше виконання для типових навантажень WordPress завдяки JIT-компіляції та покращеній поведінці OPcache.

Матриця сумісності версій PHP для WordPress:

Оновлення PHP через cPanel (для середовищ VPS з cPanel):

1. Увійдіть до WHM (root-доступ) або cPanel (рівень користувача, якщо увімкнено MultiPHP Manager).
2. Перейдіть до MultiPHP Manager у розділі Програмне забезпечення.
3. Виберіть свій домен та оберіть цільову версію PHP зі спадного меню.
4. Натисніть Застосувати.

Оновлення PHP через командний рядок (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

Критичний крок перед оновленням: Перед зміною версії PHP у виробничому середовищі протестуйте вашу тему та кожен активний плагін на нову версію. Використовуйте WP-CLI у тестовому середовищі:

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

Міркування щодо версії бази даних:

WordPress вимагає MySQL 5.7+ або MariaDB 10.3+. MariaDB 10.6 та 10.11 (LTS) є поточними рекомендованими версіями. Використання старішої версії сервера бази даних вводить як ризики безпеки, так і відсутні покращення оптимізатора запитів, що впливають на сайти з великими таблицями публікацій або обсягами замовлень 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';

Якщо будь-які таблиці показують MyISAM як рушій, конвертуйте їх до InnoDB для кращого відновлення після збоїв та продуктивності паралельного запису:

ALTER TABLE wp_options ENGINE=InnoDB;

Крок 7: Вимірювання та оптимізація продуктивності сайту

Site Health не вимірює продуктивність фронтенду — для цього потрібні зовнішні інструменти. Використовуйте Google PageSpeed Insights (вимірює Core Web Vitals у реальних умовах), GTmetrix (аналіз водоспаду) та WebPageTest (багатолокаційний, розширена конфігурація) як додаткові інструменти.

Оптимізація продуктивності за рівнями:

Рівень сервера:

• Увімкніть OPcache для кешування байткоду PHP. На правильно налаштованому VPS це одне лише зменшує час виконання PHP на 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

• Використовуйте Redis для постійного кешування об’єктів. Встановіть пакет redis-server та плагін WordPress Redis Object Cache, потім додайте до wp-config.php:

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

Рівень застосунку:

• Оптимізація зображень — Використовуйте формат WebP із запасними варіантами JPEG/PNG. Плагіни Imagify або ShortPixel обробляють масове перетворення та автоматичну доставку WebP через правила перезапису .htaccess.
• Відкладене завантаження — WordPress 5.5+ автоматично додає loading="lazy" до зображень, але перевірте, що ваша тема не перевизначає це.
• Оптимізація бази даних — Запускайте OPTIMIZE TABLE на таблицях з великою кількістю змін (wp_options, wp_postmeta) щомісяця. Плагін WP-Optimize автоматизує це.

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

• Плагіни кешування — W3 Total Cache з бекендом Redis або WP Rocket (преміум) є двома найбільш функціональними варіантами. Уникайте одночасного запуску двох плагінів кешування — вони конфліктуватимуть.

Інтеграція CDN:

CDN розвантажує доставку статичних ресурсів та зменшує TTFB для географічно розподілених відвідувачів. Безкоштовний рівень Cloudflare забезпечує достатню функціональність CDN для більшості сайтів. Для сайтів з великою кількістю медіа BunnyCDN пропонує кращу продуктивність за ціною. Налаштуйте ваш CDN для агресивного кешування статичних ресурсів, але виключіть адміністративну панель WordPress (/wp-admin/) та будь-які динамічні кінцеві точки.

Крок 8: Посилення безпеки та встановлення рутини моніторингу вразливостей

Безпека — це не одноразова конфігурація, а постійна операційна практика. Інструмент Site Health виявляє деякі проблеми безпеки, але не виконує сканування вразливостей.

Багаторівневий підхід до безпеки:

На рівні сервера (вимагає доступу до VPS або виділеного сервера):

# 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

На рівні застосунку:

• Wordfence Security — Надає Web Application Firewall (WAF), сканер шкідливого програмного забезпечення та канал розвідки загроз у реальному часі. Безкоштовний рівень достатній для більшості сайтів; преміум-рівень додає оновлення правил брандмауера в реальному часі.
• Обмеження спроб входу — Плагін Limit Login Attempts Reloaded або вбудований захист від брутфорсу Wordfence. Встановіть блокування після 3–5 невдалих спроб.
• Двофакторна автентифікація — Застосовуйте 2FA для всіх облікових записів адміністраторів за допомогою плагінів WP 2FA або Google Authenticator.
• Примусове використання SSL/HTTPS — Кожен сайт WordPress повинен працювати через HTTPS. Отримайте та встановіть SSL-сертифікат; якщо він вам потрібен, SSL-сертифікати від вашого хостинг-провайдера є найпростішим шляхом. Додайте наступне до wp-config.php для примусового використання HTTPS на рівні застосунку:

define('FORCE_SSL_ADMIN', true);

І в .htaccess:

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

Автоматизований моніторинг вразливостей:

Підпишіться на сповіщення електронною поштою WPScan Vulnerability Database для плагінів, які ви використовуєте. Інструмент WPScan CLI можна інтегрувати в завдання cron для сповіщення вас, коли новий CVE публікується для будь-якого встановленого плагіна:

# 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

Резервні копії бази даних як засіб контролю безпеки:

Чиста, нещодавня резервна копія є вашим найнадійнішим механізмом відновлення після компрометації. Автоматизуйте щоденне резервне копіювання у позасерверне місце (S3-сумісне об’єктне сховище, віддалений SFTP). Плагін UpdraftPlus надійно справляється з цим. Перевіряйте процедури відновлення щоквартально — резервна копія, яку ви ніколи не тестували, не є резервною копією.

Перевірка стану WordPress: матриця рішень та ключові висновки

Використовуйте цю матрицю для визначення правильної дії на основі того, що повідомляє Site Health:

Операційний контрольний список для постійного стану WordPress:

• Щомісяця виконуйте перегляд стану Site Health; ставтеся до критичних знахідок як до інцидентів.
• Підтримуйте PHP на підтримуваній версії (мінімум 8.1; бажано 8.2 або 8.3).
• Видаляйте неактивні плагіни та теми — не просто деактивуйте їх.
• Увімкніть кешування об’єктів Redis на будь-якому сайті з більш ніж 500 щоденними відвідувачами.
• Автоматизуйте щоденне позасерверне резервне копіювання бази даних з перевіреним тестуванням відновлення.
• Підпишіться на сповіщення про вразливості для кожного плагіна та теми у вашому стеку.
• Застосовуйте HTTPS на всьому сайті та встановіть FORCE_SSL_ADMIN у wp-config.php.
• Використовуйте WP-CLI для пакетних оновлень та операцій з базою даних — він швидший та підтримує скриптування.
• На Виділеному сервері або VPS налаштуйте серверне завдання cron замість того, щоб покладатися на wp-cron — wp-cron спрацьовує лише коли відвідувач заходить на сайт, що робить його ненадійним на сайтах з низьким трафіком.

# 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

Якщо ви оцінюєте хостингові середовища для розгортання WordPress, Панелі керування VPS надають доступ на рівні сервера, необхідний для реалізації кожного заходу оптимізації та посилення безпеки, описаного в цьому посібнику — управління версіями PHP, конфігурація Redis, серверний cron та правила брандмауера — все це вимагає root або sudo доступу, який спільні середовища не надають.

FAQ

У чому різниця між вкладкою Стан та вкладкою Інформація в Site Health?

Вкладка Стан виконує автоматизовані перевірки та категоризує знахідки за серйозністю (Добре, Рекомендовано, Критично). Вкладка Інформація відображає необроблені дані середовища — конфігурацію PHP, активні плагіни з версіями, деталі бази даних та розміри каталогів — без будь-якої оцінки «пройдено/не пройдено». Вкладка Інформація використовується переважно для ручної діагностики та обміну з інженерами підтримки.

Чи впливає увімкнення режиму усунення несправностей на живих відвідувачів?

Ні. Режим усунення несправностей використовує файл cookie браузера для застосування середовища безпечного режиму виключно до вашого сеансу. Відвідувачі без файлу cookie бачать сайт у звичайному режимі. Єдиним винятком є ситуація, коли фатальна помилка в плагіні призводить до збою самого серверного процесу — у цьому випадку всі відвідувачі зазнають впливу незалежно від стану активації плагіна у вашому сеансі.

Яку версію PHP слід використовувати для WordPress у 2025 році?

PHP 8.2 є рекомендованою версією для виробничих сайтів WordPress у 2025 році. Вона активно підтримується з патчами безпеки, пропонує вимірювані покращення продуктивності порівняно з 8.0 та 8.1, та підтримується всіма основними плагінами WordPress. PHP 8.3 є стабільним та підходить для нових розгортань, але перевірте сумісність плагінів перед оновленням існуючого сайту.

Чому Site Health повідомляє «Добре», коли мій сайт явно повільний?

Site Health перевіряє конфігурацію та стан безпеки — він не вимірює метрики продуктивності фронтенду, такі як Largest Contentful Paint (LCP) або Time to First Byte (TTFB). Сайт може пройти всі перевірки Site Health та все одно отримати низький бал за Core Web Vitals через неоптимізовані зображення, відсутність рівня кешування, повільну базу даних або географічно віддалений сервер. Використовуйте Google PageSpeed Insights або WebPageTest для вимірювання продуктивності.

Як виправити збій зворотного запиту в WordPress Site Health?

Збій зворотного запиту означає, що WordPress не може зробити HTTP-запит до власної URL-адреси з сервера. Поширені причини включають: брандмауер, що блокує вихідні з’єднання від процесу веб-сервера, запис у файлі hosts, що неправильно маршрутизує домен, помилку SSL-сертифіката при зворотному запиті або плагін безпеки, що блокує запит. Почніть з тимчасового вимкнення вашого плагіна безпеки та повторного запуску Site Health. Якщо це вирішить проблему, додайте власну IP-адресу сервера до білого списку в налаштуваннях брандмауера плагіна безпеки.