WordPress Critical Error: як виправити критичну помилку на сайті

Привіт:) Якщо замість сайту WordPress ви бачите повідомлення “There has been a critical error on this website”, це означає, що під час виконання PHP-коду сталася критична помилка, через яку WordPress не зміг нормально завершити формування сторінки.

Для власника сайту така ситуація часто виглядає серйозніше, ніж є насправді. У багатьох випадках проблему спричиняє один конкретний плагін, тема, фрагмент кастомного PHP-коду або несумісність із версією PHP.

Хороша новина полягає в тому, що WordPress має вбудований Recovery Mode, а також інструменти діагностики через WP_DEBUG і WP_DEBUG_LOG. Вони дозволяють не просто прибрати повідомлення про помилку, а визначити її реальну причину.

У цьому матеріалі розберу:

• що означає WordPress Critical Error;
• чому виникає критична помилка;
• як виправити її через Recovery Mode;
• що робити, якщо немає доступу до WordPress;
• як знайти помилку в debug.log;
• як перевірити плагіни та тему;
• як діагностувати PHP Fatal Error;
• що робити з помилками пам'яті;
• як перевірити сумісність PHP;
• коли потрібно відновлювати файли WordPress;
• як уникнути повторної появи Critical Error.

🔎 Що означає WordPress Critical Error?

Повідомлення:

There has been a critical error on this website.

означає, що WordPress зіткнувся з помилкою, яка перешкоджає нормальному виконанню PHP-коду.

Найчастіше за таким повідомленням стоїть PHP fatal error — критична PHP-помилка, через яку поточний процес припиняє виконання.

WordPress офіційно зазначає, що повідомлення про Critical Error означає проблему, яка заважає сайту працювати належним чином. Серед перших кроків рекомендується перевірити адміністративну пошту, а потім увімкнути режим діагностики та переглянути wp-content/debug.log.

Простими словами

Схема роботи приблизно така:

WordPress → плагін/тема/код → PHP → помилка → виконання зупиняється → Critical Error

Важливо розуміти: Critical Error — це не назва конкретної проблеми.

Це лише повідомлення про наслідок.

Справжня причина може бути зовсім іншою:

• помилка PHP-синтаксису;
• несумісний плагін;
• конфлікт двох плагінів;
• проблема в темі;
• кастомний код у functions.php;
• несумісність із новою версією PHP;
• нестача PHP memory limit;
• пошкоджений файл;
• невдале оновлення;
• проблема з Must-Use Plugin;
• серверна конфігурація;
• сторонній код або інтеграція.

⚠️ Основні симптоми Critical Error

Critical Error може проявлятися по-різному.

Наприклад:

• головна сторінка не відкривається;
• /wp-admin/ не працює;
• сайт показує білий екран;
• сторінки повертають помилку;
• помилка виникає тільки на окремих сторінках;
• помилка з'являється після оновлення плагіна;
• проблема виникає тільки після зміни PHP;
• WordPress працює для відвідувачів, але не працює адмінка;
• помилка виникає при відкритті редактора;
• помилка з'являється під час завантаження медіафайлів;
• сайт періодично падає при певній дії.

У деяких випадках WordPress автоматично активує Recovery Mode, який дозволяє адміністратору увійти до панелі керування та тимчасово ізолювати проблемний компонент.

🧩 Чому виникає WordPress Critical Error?

Найпоширеніші причини можна умовно поділити на кілька груп.

Причина	Наскільки типова	Приклад
Плагін	Дуже часто	Плагін несумісний з WordPress/PHP
Тема	Часто	Помилка в functions.php
PHP	Часто	Нова версія PHP несумісна зі старим кодом
Кастомний код	Часто	Неправильний PHP-код
Пам'ять PHP	Часто	Allowed memory size exhausted
Оновлення	Іноді	Перерване або невдале оновлення
Конфлікт плагінів	Іноді	Два компоненти змінюють одну функціональність
Must-Use Plugin	Рідше	Проблема в wp-content/mu-plugins
Сервер	Рідше	Некоректна PHP-конфігурація
Пошкоджені файли	Рідше	Файл WordPress або розширення пошкоджено

WordPress прямо рекомендує при подібних проблемах перевіряти плагіни, тему, пам'ять та PHP-конфігурацію.

🛟 Найперше: не панікуйте та не змінюйте все одразу

Одна з найпоширеніших помилок під час виправлення Critical Error — одночасно:

• оновити WordPress;
• змінити PHP;
• вимкнути всі плагіни;
• змінити тему;
• редагувати wp-config.php;
• видалити кеш;
• замінити файли.

У результаті важко визначити, що саме спричинило проблему.

Краще працювати за принципом:

зафіксувати → діагностувати → ізолювати → виправити → перевірити.

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

📧 Крок 1. Перевірте email адміністратора WordPress

Якщо WordPress виявляє критичну PHP-помилку, він може автоматично активувати Recovery Mode та надіслати адміністратору повідомлення з посиланням для входу.

У листі можуть бути дані про:

• проблемний плагін;
• тему;
• файл;
• тип помилки;
• місце виникнення помилки.

Recovery Mode з'явився у WordPress 5.2 і призначений саме для ситуацій, коли fatal error не дозволяє нормально завантажити сайт. Проблемний плагін або тема можуть бути тимчасово призупинені для сесії адміністратора.

Де шукати лист?

Перевірте:

1. основну поштову скриньку;
2. Spam/Junk;
3. Promotions;
4. папки фільтрів;
5. поштову скриньку, яка вказана як адміністративна в WordPress.

Якщо листа немає, це не означає, що проблему неможливо виправити.

У такому випадку переходьте до діагностики через файловий менеджер, FTP/SFTP або панель хостингу.

🛠️ Крок 2. Використайте WordPress Recovery Mode

Якщо WordPress надіслав спеціальний Recovery Mode link, це один із найзручніших способів діагностики.

У Recovery Mode проблемний компонент може бути тимчасово призупинений для адміністративної сесії, після чого в адмінці з'являються повідомлення про помилку.

Що робити?

1. Відкрийте Recovery Mode link із листа.
2. Увійдіть у WordPress.
3. Подивіться повідомлення про помилку.
4. Визначте плагін або тему, які вказані як джерело проблеми.
5. Тимчасово деактивуйте проблемний компонент.
6. Перевірте сайт.
7. Виправте або оновіть компонент.
8. Вийдіть із Recovery Mode.
9. Перевірте сайт повторно.

Важливо

Деактивація плагіна — це не завжди остаточне рішення.

Наприклад, якщо плагін старий і несумісний із поточним PHP, його просте вимкнення лише прибере симптом.

Правильніше:

визначити причину → оновити/замінити/виправити компонент → перевірити сайт.

🔍 Крок 3. Увімкніть WordPress Debug Mode

Якщо Recovery Mode не допоміг, наступний крок — діагностика через WordPress Debugging.

WordPress має кілька спеціальних констант:

• WP_DEBUG;
• WP_DEBUG_LOG;
• WP_DEBUG_DISPLAY;
• SCRIPT_DEBUG.

Офіційна документація рекомендує використовувати debugging насамперед у середовищах розробки та тестування, а не залишати детальний вивід помилок увімкненим на production-сайті.

📄 Крок 4. Перевірте файл wp-content/debug.log

Після ввімкнення:

WP_DEBUG

і

WP_DEBUG_LOG

WordPress може записувати діагностичну інформацію до:

wp-content/debug.log

Саме цей файл часто дозволяє перейти від загального повідомлення:

Critical Error

до конкретної причини:

Fatal error → файл → рядок → плагін/тема → причина.

WordPress прямо рекомендує переглядати wp-content/debug.log, щоб визначити, що саме спричинило Critical Error.

Як читати PHP Fatal Error?

Уявімо, що в логах ви бачите приблизно таку структуру:

PHP Fatal error: Uncaught Error: Call to undefined function ...
in /wp-content/plugins/example-plugin/includes/file.php on line 123

Не обов'язково запам'ятовувати всі терміни.

Шукайте насамперед три речі:

1. PHP Fatal error

Це означає, що виконання PHP-коду було перервано.

2. Шлях до файлу

Наприклад:

/wp-content/plugins/example-plugin/...

Якщо шлях містить plugins, це сильний сигнал перевірити конкретний плагін.

Якщо:

/wp-content/themes/example-theme/...

— перевіряйте тему.

Якщо:

/wp-content/mu-plugins/...

— проблема може бути у Must-Use Plugin.

3. Номер рядка

Наприклад:

line 123

Це допомагає розробнику знайти конкретне місце в коді.

Водночас номер рядка не завжди означає, що саме цей рядок містить першопричину. Помилка може бути наслідком коду трохи вище.

🔌 Крок 5. Перевірте плагіни

Плагіни — одна з перших категорій, яку варто перевірити.

Особливо якщо Critical Error з'явився:

• відразу після встановлення плагіна;
• після оновлення плагіна;
• після зміни PHP;
• після оновлення WordPress;
• після зміни налаштувань плагіна.

Якщо є доступ до адмінки

Перейдіть:

Плагіни → Встановлені плагіни

і тимчасово вимкніть підозрілий плагін.

Після цього перевірте:

• головну сторінку;
• проблемну сторінку;
• /wp-admin/;
• редактор;
• основні функції сайту.

Що робити, якщо wp-admin не відкривається?

Тоді можна використати файловий менеджер хостингу або FTP/SFTP.

Знайдіть:

wp-content/plugins

і тимчасово перейменуйте папку:

plugins

наприклад на:

plugins-disabled

Це дозволяє тимчасово деактивувати плагіни, коли доступ до адміністративної панелі неможливий. Такий спосіб описаний і в офіційній документації WordPress.

Після цього перевірте сайт.

Якщо сайт запрацював

Ймовірно, причина пов'язана з одним із плагінів.

Тоді:

1. поверніть назву папки plugins;
2. активуйте плагіни по одному;
3. після кожної активації перевіряйте сайт;
4. знайдіть компонент, після активації якого виникає Critical Error.

Це називається методом поетапної ізоляції проблеми.

⚔️ Крок 6. Перевірте конфлікт між плагінами

Не завжди винен один плагін сам по собі.

Може існувати конфлікт:

Plugin A ↔ Plugin B

Наприклад, два плагіни можуть:

• змінювати одну й ту саму функцію;
• підключати несумісні бібліотеки;
• використовувати однакові хуки;
• змінювати один і той самий API;
• по-різному працювати з PHP;
• конфліктувати з редактором або конструктором сторінок.

Саме тому після деактивації всіх плагінів варто повертати їх по одному, а не активувати всі одночасно. Такий підхід рекомендується WordPress для пошуку проблемного компонента.

🎨 Крок 7. Перевірте тему WordPress

Якщо вимкнення плагінів не допомогло, наступний кандидат — активна тема.

Особливо підозріло, якщо помилка виникла після:

• оновлення теми;
• зміни дочірньої теми;
• редагування functions.php;
• додавання PHP-коду;
• зміни шаблону;
• оновлення PHP.

Як перевірити тему?

Якщо є доступ до адмінки:

Зовнішній вигляд → Теми

тимчасово активуйте стандартну тему WordPress.

Якщо адмінка недоступна, можна скористатися FTP/SFTP або файловим менеджером.

Потрібно тимчасово перейменувати каталог активної теми.

WordPress може перейти до іншої встановленої стандартної теми.

Особлива увага до functions.php

Одна з типових причин Critical Error — неправильна зміна:

functions.php

Наприклад:

• пропущена ;;
• неправильна дужка;
• неправильна назва функції;
• виклик неіснуючої функції;
• неправильна кількість аргументів;
• використання функції, видаленої в новій версії PHP;
• конфлікт із функцією плагіна;
• синтаксична помилка.

WordPress зазначає, що PHP syntax errors можуть містити інформацію про файл і приблизний номер рядка, де виникла проблема.

🐘 Крок 8. Перевірте версію PHP

Версія PHP має велике значення для WordPress.

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

Тому потрібно перевірити не лише:

“Чи працює WordPress із PHP?”

а й:

“Чи сумісні всі мої плагіни, тема та кастомний код із поточною версією PHP?”

Чому оновлення PHP може викликати Critical Error?

Старий PHP-код може використовувати:

• застарілі функції;
• видалені конструкції;
• змінені API;
• несумісні типи даних;
• старий синтаксис;
• deprecated-функції.

Наприклад, сайт міг роками працювати на старішій версії PHP, а після переходу на новішу версію певний старий плагін перестав працювати.

Тому після зміни PHP завжди варто перевірити:

1. WordPress Core;
2. активну тему;
3. дочірню тему;
4. усі плагіни;
5. кастомний PHP-код.

💾 Крок 9. Перевірте помилки memory limit

Окремий клас Critical Error пов'язаний із нестачею PHP memory.

У логах це може виглядати приблизно як:

Allowed memory size exhausted

Це означає, що PHP-процесу не вистачило доступної пам'яті.

WordPress документує WP_MEMORY_LIMIT як параметр, який визначає обсяг пам'яті, який WordPress намагається запросити для PHP. Для адміністративної частини також існує WP_MAX_MEMORY_LIMIT.

Чому може закінчитися пам'ять?

Причиною можуть бути:

• важкий плагін;
• великий конструктор сторінок;
• імпорт великого обсягу даних;
• обробка зображень;
• резервне копіювання;
• складний запит;
• велика кількість активних плагінів;
• неефективний кастомний код;
• недостатній серверний memory limit.

Як збільшити WordPress memory limit?

У wp-config.php може використовуватися, наприклад:

define( 'WP_MEMORY_LIMIT', '128M' );

Для адміністративних операцій може використовуватися:

define( 'WP_MAX_MEMORY_LIMIT', '256M' );

Однак важливо розуміти: зміна WP_MEMORY_LIMIT не завжди збільшує реальний PHP memory_limit на сервері.

Якщо хостинг забороняє збільшувати ліміт, необхідно звернутися до хостинг-провайдера. WordPress прямо зазначає, що деякі хостинги не дозволяють автоматично збільшувати PHP memory limit.

⏱️ Крок 10. Перевірте Maximum Execution Time

Інша проблема може виглядати як:

Maximum execution time exceeded

Це означає, що PHP-операція не завершилася протягом дозволеного часу.

Таке може траплятися під час:

• імпорту;
• експорту;
• резервного копіювання;
• масової обробки зображень;
• міграції;
• складних операцій плагіна;
• великих API-запитів.

WordPress описує max_execution_time як одну з потенційних причин проблем із тривалими PHP-операціями.

Якщо ви не впевнені, як змінювати PHP-конфігурацію, краще звернутися до хостинг-провайдера.

🧱 Крок 11. Перевірте Must-Use Plugins

Іноді звичайний список:

Плагіни → Встановлені

не показує проблемний компонент.

Причиною можуть бути Must-Use Plugins, які зберігаються в:

wp-content/mu-plugins

Такі плагіни автоматично активуються і не керуються звичайним способом через список стандартних плагінів. WordPress зазначає, що Must-Use Plugins завантажуються автоматично, а для їх деактивації потрібна робота з відповідними файлами.

Це особливо важливо на:

• managed hosting;
• корпоративних сайтах;
• сайтах із CDN/кешуванням;
• multisite;
• хостингах із власними службовими плагінами.

🗄️ Крок 12. Перевірте базу даних

Не кожен Critical Error безпосередньо пов'язаний із базою даних, але проблеми БД також можуть спричиняти помилки сайту.

Зверніть увагу на:

• помилки підключення;
• пошкоджені таблиці;
• проблеми з MySQL/MariaDB;
• нестачу ресурсів;
• некоректні запити;
• помилки після міграції;
• проблеми з кодуванням.

Якщо в логах є SQL-повідомлення, не варто навмання редагувати таблиці через phpMyAdmin.

Спочатку зробіть резервну копію бази даних.

🔄 Крок 13. Перевірте, чи не виникла проблема після оновлення

Якщо Critical Error з'явився одразу після оновлення, це дуже важлива підказка.

Складіть просту хронологію:

Подія	Що змінилося?
До проблеми	Сайт працював
Оновлення	Оновлено плагін
Після оновлення	Critical Error
Діагностика	Fatal Error
Файл	/wp-content/plugins/...
Висновок	Перевіряємо плагін

Це значно скорочує час пошуку.

🧩 Крок 14. Перевірте сумісність компонентів

Для стабільної роботи важливо, щоб між собою були сумісні:

WordPress Core + PHP + тема + плагіни + сервер

Наприклад:

новий PHP → старий плагін → несумісний код → PHP Fatal Error → WordPress Critical Error

Або:

оновлений WordPress → стара тема → deprecated/несумісний код → Fatal Error

Саме тому перед великими оновленнями бажано перевіряти сумісність компонентів.

🧯 Крок 15. Що робити, якщо Critical Error виник після оновлення плагіна?

Алгоритм:

1. Визначте плагін

Перевірте:

• Recovery Mode;
• debug.log;
• дату виникнення проблеми.

2. Тимчасово вимкніть плагін

Якщо сайт відновився — причина, ймовірно, пов'язана з ним.

3. Перевірте новішу версію

Можливо, розробник уже випустив виправлення.

4. Перевірте вимоги до PHP

Особливо якщо одночасно оновлювався PHP.

5. Перевірте changelog плагіна

Зверніть увагу на:

• PHP compatibility;
• WordPress compatibility;
• breaking changes;
• required dependencies.

6. Якщо проблема залишається

Розгляньте:

• rollback до стабільної версії;
• альтернативний плагін;
• звернення до розробника.

🧪 Крок 16. Як знайти проблемний плагін методом половинного пошуку?

Якщо на сайті десятки плагінів, необов'язково активувати їх строго по одному.

Можна використовувати метод поділу:

1. вимкнути всі плагіни;
2. увімкнути половину;
3. перевірити сайт;
4. якщо помилка з'явилася — проблема в цій половині;
5. якщо помилки немає — проблема в іншій половині;
6. повторювати поділ.

Наприклад:

20 плагінів → 10 → 5 → 2 → 1

Такий підхід може значно прискорити діагностику.

🧑‍🔧 Крок 17. Якщо проблема в кастомному PHP-коді

Якщо debug.log показує:

functions.php

або інший файл вашої теми/кастомного плагіна, потрібно перевірити останні зміни.

Особливо:

• код, який було додано нещодавно;
• нові хуки;
• нові функції;
• AJAX-код;
• REST API;
• WooCommerce hooks;
• фільтри;
• shortcode;
• інтеграції зі сторонніми API.

Не редагуйте код навмання

Якщо ви не працюєте з PHP професійно, краще:

1. зробити backup;
2. зберегти поточний файл;
3. знайти точний рядок помилки;
4. перевірити документацію функції;
5. протестувати виправлення на staging.

🧰 Крок 18. Що робити, якщо пошкоджені файли WordPress?

Іноді проблема виникає через:

• невдале оновлення;
• неповне завантаження файлів;
• пошкоджений файл;
• проблеми з файловою системою.

У такому випадку може знадобитися повторне завантаження чистих файлів WordPress.

Не слід видаляти wp-content, wp-config.php або інші важливі файли навмання.

Для операцій із файлами WordPress рекомендує мати резервні копії як файлів, так і бази даних.

🔐 Крок 19. Перевірте сайт на ознаки злому

Не кожен Critical Error є результатом злому.

Але якщо помилка виникла раптово без оновлень або змін, варто врахувати і цей сценарій.

Зверніть увагу на:

• невідомі PHP-файли;
• незнайомі плагіни;
• підозрілі адміністративні акаунти;
• змінені файли;
• незнайомий код;
• дивні редиректи;
• спам-сторінки;
• невідомі cron-завдання.

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

Потрібна комплексна перевірка:

• файлів;
• бази даних;
• користувачів;
• паролів;
• доступів FTP/SFTP;
• хостингу;
• API keys;
• адмінських акаунтів.

📊 Швидка діагностика WordPress Critical Error

Симптом	Що перевірити першочергово
Помилка після оновлення плагіна	Плагін
Помилка після зміни PHP	Сумісність PHP
Помилка після зміни functions.php	Код теми
Allowed memory size exhausted	PHP memory limit
Maximum execution time exceeded	Execution time
Call to undefined function	Плагін/тема/PHP
Call to undefined method	Несумісність коду
Parse error	Синтаксис PHP
Помилка лише в адмінці	Плагіни/адмінські функції/пам'ять
Помилка лише на frontend	Тема/шаблон/плагін
Не відкривається навіть після вимкнення плагінів	Тема/PHP/Core/сервер
Помилка в mu-plugins	Must-Use Plugin
Помилка після міграції	PHP/шляхи/БД/сервер

🗺️ Правильний алгоритм виправлення Critical Error

Необхідно рухатися від найпростішого до найглибшого рівня.

1. Перевірити Recovery Mode
     ↓
2. Перевірити email адміністратора
     ↓
3. Переглянути debug.log
     ↓
4. Визначити файл і компонент
     ↓
5. Вимкнути підозрілий плагін або тему
     ↓
6. Перевірити PHP
     ↓
7. Перевірити memory limit
     ↓
8. Перевірити кастомний код
     ↓
9. Перевірити WordPress Core
     ↓
10. Перевірити сервер
     ↓
11. Перевірити безпеку
     ↓
12. Відновити сайт із backup, якщо причина не локалізована

Цей підхід набагато ефективніший, ніж випадкове вимкнення або перевстановлення компонентів.

🛡️ Як запобігти WordPress Critical Error у майбутньому?

Виправити помилку — лише половина завдання.

Набагато краще зменшити ймовірність її повторення.

1. Регулярно створюйте backup

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

• базу даних;
• файли WordPress;
• wp-content;
• тему;
• завантажені медіафайли;
• конфігурацію.

Важливо не просто створювати backup, а періодично перевіряти, чи можна з нього реально відновити сайт.

2. Не оновлюйте все одночасно на production

Для важливого сайту краще:

backup → staging → update → test → production

Це особливо важливо перед:

• оновленням PHP;
• великим оновленням WordPress;
• оновленням WooCommerce;
• оновленням конструктора;
• оновленням великої кількості плагінів.

3. Слідкуйте за PHP

WordPress рекомендує сучасну версію PHP. Водночас фактичну сумісність потрібно оцінювати для всієї конфігурації сайту, а не лише WordPress Core.

4. Не використовуйте застарілі плагіни

Плагін, який не оновлювався роками, може стати проблемою після:

• оновлення PHP;
• оновлення WordPress;
• зміни іншого плагіна;
• зміни серверного середовища.

5. Тестуйте кастомний PHP-код

Не варто вставляти випадкові PHP-сніпети без:

• backup;
• тестування;
• перевірки сумісності;
• розуміння того, що робить код.

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

🔧 Що робити після успішного виправлення?

Після того як сайт знову запрацював, не варто завершувати діагностику одразу.

Зробіть контрольну перевірку:

Frontend

• головна сторінка;
• записи;
• сторінки;
• категорії;
• пошук;
• форми;
• меню;
• мобільна версія.

Backend

• /wp-admin/;
• редактор;
• медіатека;
• налаштування;
• плагіни;
• тема.

Технічна частина

• PHP error log;
• debug.log;
• Site Health;
• PHP version;
• memory limit;
• cron;
• loopback requests.

Site Health у WordPress знаходиться в Tools → Site Health і показує технічну інформацію про конфігурацію сайту та потенційні критичні проблеми.

🧹 Не забудьте вимкнути Debug Mode на production

Після завершення діагностики перевірте wp-config.php.

Якщо debugging був увімкнений тимчасово, його потрібно повернути до нормальної конфігурації.

Наприклад:

define( 'WP_DEBUG', false );

Особливо важливо не залишати відкритим виведення PHP-помилок для відвідувачів.

WordPress наголошує, що debugging-інструменти призначені насамперед для розробки та тестування, а детальні помилки не варто без потреби показувати на live-сайті.

❓ FAQ: WordPress Critical Error

✅ Висновок

WordPress Critical Error — це не конкретна помилка, а сигнал про те, що під час виконання сайту виникла критична проблема.

У більшості випадків правильна стратегія полягає не в тому, щоб одразу перевстановлювати WordPress, а в тому, щоб знайти першопричину.

Оптимальна послідовність:

1. Перевірити Recovery Mode.
2. Перевірити email адміністратора.
3. Увімкнути WP_DEBUG та WP_DEBUG_LOG.
4. Переглянути wp-content/debug.log.
5. Знайти файл, плагін або тему, що спричинили Fatal Error.
6. Перевірити сумісність PHP.
7. Перевірити memory limit та execution time.
8. Вимкнути або оновити проблемний компонент.
9. Перевірити тему та кастомний код.
10. Перевірити Must-Use Plugins і серверну конфігурацію.
11. За необхідності відновити пошкоджені файли з backup.
12. Після виправлення вимкнути debug-вивід на production.

Головний принцип простий: не боріться з повідомленням “Critical Error” — знайдіть PHP-помилку, яка стоїть за ним.

Саме Recovery Mode, debug.log та точний аналіз PHP Fatal Error найчастіше дозволяють перетворити незрозумілу помилку WordPress на конкретну проблему з конкретним рішенням.