Моніторинг WordPress: 7 речей, що ламаються

Сайт WordPress рідко ламається так, щоб це зрозуміла проста перевірка «чи відповідає сервер?». Сервер відповідає. Він відповідає ввічливою сторінкою помилки, наполовину відображеною темою або формою входу, до якої ніхто не може дістатися, і часто робить це з кодом HTTP 200.

Ось сім збоїв, які ми бачимо на сайтах клієнтів найчастіше, з перевіркою, що ловить кожен, і першим кроком до виправлення. Готовий набір із п’яти перевірок є в супутньому дописі; цей допис побудований за тим, що ламається.

1. База даних зникла, а WordPress ввічливо про це повідомляє

Що відбувається: MySQL перезапускається, вичерпує з’єднання або втрачає диск. WordPress показує «Error establishing a database connection» і повертає це зі звичайним кодом відповіді.

Як виявити: перевірка ключового слова на головній сторінці, яка вимагає фразу зі справної сторінки й забороняє Error establishing a database connection. Монітор ключових слів читає сире тіло відповіді, тому обидва правила працюють без браузера. Дивіться моніторинг ключових слів.

Перший крок на сервері:

systemctl status mysql          # or mariadb
wp db check                     # WP-CLI, run from the site's directory
df -h /var/lib/mysql            # a full disk stops MySQL

2. Оновлення плагіна закінчується фатальною помилкою або білим екраном

Що відбувається: оновлення плагіна чи теми несумісне з версією PHP або іншим плагіном. Сторінка або порожня з кодом 200, або видає 500. На спільному хостингу сплеск трафіку також може дати сторінки 503 чи 508 «ліміт ресурсів вичерпано».

Як виявити: код відповіді плюс ключове слово, яке має бути на справній сторінці, наприклад wp-content, що трапляється в адресах ресурсів кожної правильно відображеної сторінки WordPress. Порожня сторінка такого рядка не містить.

Перший крок: вимкніть плагіни без панелі керування.

wp plugin deactivate --all
wp plugin activate woocommerce        # re-enable one by one, starting with the essentials

Без WP-CLI перейменуйте wp-content/plugins на plugins-off через SFTP. Якщо сайт ожив, поверніть назву й перейменовуйте папки окремих плагінів, доки не знайдете винуватця.

3. wp-cron зупиняється, і заплановані завдання мовчки вмирають

Що відбувається: WordPress виконує заплановані завдання, коли хтось відвідує сайт. На малолюдному сайті або там, де DISABLE_WP_CRON увімкнули без заміни, заплановані публікації, резервні копії, листи про замовлення й синхронізація залишків просто припиняються.

Як виявити: монітор heartbeat. Заплановане завдання кожні кілька хвилин запитує адресу, а ви отримуєте сповіщення, коли запити припиняються. Монітори heartbeat доступні від тарифу Starter; посібник із моніторингу cron містить повний прийом.

Перший крок:

wp cron event list              # what is scheduled, and what is overdue
wp cron event run --due-now     # run overdue events once

Якщо ви вимкнули wp-cron навмисно, подбайте, щоб справжній запис cron запускав wp cron event run --due-now кожні кілька хвилин.

4. Кеш віддає всім не ту сторінку

Що відбувається: кеш сторінок або CDN зберігає те, чого не повинен: панель адміністратора із сеансу авторизованого користувача, порожній кошик, сторінку обслуговування «ми скоро повернемося» чи цикл перенаправлень. Відвідувачі бачать це, доки кеш не очистять.

Як виявити: перевірки ключових слів на важливих сторінках (головна, магазин, оформлення замовлення) і перегляд заголовків відповіді. Інструмент HTTP-заголовків показує cache-control, age і типові заголовки CDN, як-от cf-cache-status. Підказка — age у кілька годин на сторінці, яка має бути динамічною.

Перший крок: очистіть кеш сторінок і CDN, потім з’ясуйте, що зробило сторінку кешованою. Кошик, оформлення замовлення й сторінки облікового запису треба виключити з кешування.

5. Ніхто не може увійти, зокрема й ви

Що відбувається: плагін безпеки обмежує частоту входів, правило брандмауера ставить перевірку кожному запиту, або оновлення змінює адресу входу. Публічний сайт у порядку, а клієнт не може публікувати.

Як виявити: стежте за /wp-login.php (або вашою власною адресою входу) за допомогою ключового слова, такого як user_login. Якщо WAF блокує монітор, спершу додайте його до білого списку (allow-list); посібник про allow-list у Cloudflare показує як, а список IP-адрес перевірок містить адреси.

6. Спливає термін дії сертифіката або домену

Що відбувається: автоматичне продовження тихо ламається, і браузери показують повноекранне попередження, або домен спливає й сайт перетворюється на сторінку-паркувальник реєстратора.

Як виявити: монітори терміну дії SSL і домену зі сповіщеннями за 30, 14 і 3 дні. Обидва доступні від тарифу Starter. Підхід із переліком хостів і однорядкову перевірку openssl дивіться в посібнику про термін дії SSL.

7. Сайт зламано, а він і далі повертає 200

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

Як виявити: дві речі разом. Правило ключового слова, що забороняє слова, яким нема чого робити на сторінці (аптечні товари, казино чи назва відомої спам-мережі, яку ви бачили в журналах), і монітор змін на головній сторінці, який сповіщає, коли її вміст несподівано змінюється. Виявлення змін доступне від тарифу Starter; дивіться виявлення змін на сторінках.

Перший крок: зробіть резервну копію, перш ніж щось змінювати, звірте файли ядра за допомогою wp core verify-checksums і оновіть або видаліть вразливий плагін. Потім змініть паролі адміністраторів і ключі.

Вибір ключового слова для кожної перевірки

Перевірка ключового слова настільки добра, наскільки добра фраза, яку ви обрали. Беріть фразу, що є на сторінці, коли все працює, і зникає, коли щось не так:

Уникайте фраз, які часто змінюються, як-от заголовок новини чи дата, інакше перевірка падатиме щоразу, коли редактор щось опублікує. Також перевіряйте фразу після зміни теми або мови сайту: переклад інтерфейсу легко «зламає» рядок, який ви довго підбирали.

Хибні сповіщення і хто їх отримує

Оновлення плагінів, нічні резервні копії та перебудова кешу можуть на хвилину сповільнити сайт. Два налаштування зменшують шум: друга перевірка, що підтверджує збій перед надсиланням сповіщення, і вікно обслуговування навколо запланованих робіт, щоб заплановане оновлення не рахувалося простоєм. Першим сповіщайте себе, а не клієнта, і додавайте клієнта до контактів лише тоді, коли довіряєте налаштуванню. Якщо сповіщення надходять надто часто, не вимикайте їх, а виправте причину: одне хибне сповіщення на тиждень швидко привчає команду не реагувати й на справжні.

Мінімальний набір для сайту клієнта

Якщо ви створюєте лише жменю моніторів на кожен сайт, нехай це будуть ці:

1. Головна сторінка: код відповіді, обов’язковий текст, заборонені рядки помилок (покриває 1, 2, 4).
2. Сторінка, що приносить гроші (оформлення замовлення, бронювання): те саме.
3. Ключове слово на сторінці входу (5).
4. Heartbeat для wp-cron (3).
5. Термін дії SSL і домену (6).
6. Виявлення змін на головній сторінці (7), якщо ваш тариф його включає.

Це шість моніторів, тож портфель із 40 сайтів — це 240. У Tenium це вміщується в тариф Pro (300 моніторів, $29 на місяць); тариф Free покриває 30 моніторів із перевірками HTTP і ключових слів, а Starter ($7) додає heartbeat, перевірки SSL, домену та змін. Сторінка моніторингу WordPress описує повний набір, а якщо ви ще користуєтеся набором для керування WordPress, порівняння Tenium з ManageWP пояснює, як вони доповнюють один одного.

Поширені запитання

Читайте також

Пов’язані сторінки Tenium

• Моніторинг WordPress
• Безкоштовний інструмент для HTTP-заголовків
• Tenium проти ManageWP
• Усі матеріали блогу
• Тарифи