Критична помилка на сайті WordPress після оновлення: що робити

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

Що означає «критична помилка» у WordPress

За написом стоїть фатальна помилка PHP (fatal error): збій, після якого PHP припиняє виконувати код сторінки. Причина майже завжди конкретна: плагін викликав функцію, якої в новій версії вже немає; тема передала у функцію дані не того типу; скрипту не вистачило пам’яті.

З версії 5.2 WordPress перехоплює такі збої: замість білого екрана відвідувач бачить сторінку з текстом помилки, а WordPress намагається визначити, який плагін чи тема її спричинили. Текст залежить від місця збою:

• «На сайті виникла критична помилка.» На звичайних сторінках, її бачать відвідувачі.
• «На сайті сталася критична помилка. Будь ласка, перевірте поштову скриньку адміністратора сайту, щоб отримати інструкції…» В адмінці та на сторінці входу.
• «На вашому сайті виникла критична помилка і він був переведений в режим відновлення…» У того, хто увійшов за посиланням із листа.

Дві інші поломки мають схожий вигляд, але влаштовані інакше. «Виникла помилка під час з’єднання з базою даних» означає, що WordPress не підключився до MySQL: у wp-config.php неправильні дані доступу або не працює сервер бази даних. Плагіни тут зазвичай не винні, розбиратися починають із хостингом. Порожня біла сторінка або «500 Internal Server Error» без тексту від WordPress означає, що сторінка про помилку не встигла з’явитися: збій стався на рівні сервера (наприклад, через помилку в .htaccess) або обробник фатальних помилок вимкнено константою WP_DISABLE_FATAL_ERROR_HANDLER. Тоді причину шукають у журналі помилок PHP у панелі хостингу (про нього в кроці 2).

Лист «На сайті виникли технічні проблеми»

Коли WordPress визначив винуватця, він надсилає лист із темою «[Назва сайту] На сайті виникли технічні проблеми» на адресу адміністратора з «Налаштування → Загальні». Іншу адресу задають константою RECOVERY_MODE_EMAIL у wp-config.php. У листі названо плагін або тему з помилкою, сторінку, де вона сталася, технічні подробиці та посилання для входу в режим відновлення.

Режим відновлення (recovery mode) призупиняє зламаний плагін або тему лише у браузері того, хто увійшов за посиланням. Відвідувачі, як і раніше, бачать помилку, зате ви потрапляєте в адмінку і можете вимкнути плагін або повернути його попередню версію.

Лист приходить не завжди, на це є три причини.

1. WordPress надсилає його, лише якщо помилка сталася в адмінці, на сторінці входу або в деяких службових фонових запитах адмінки (AJAX). Якщо падає лише сторінка оформлення замовлення, листа не буде, доки хтось не відкриє /wp-admin/. Тому насамперед відкрийте адмінку: якщо помилка повториться там і винен плагін або тема, лист надійде.
2. За замовчуванням лист надсилається не частіше ніж раз на добу, і посилання в ньому діє стільки ж. Якщо за останні 24 години лист уже був, нового не буде. Знайдіть попередній, зокрема у спамі: доки доба не минула, посилання працює.
3. Лист надсилається через звичайну пошту сайту. Якщо надсилання пошти не налаштоване, він може не дійти або потрапити у спам. Для цього випадку нижче є шлях без листа.

Як влаштовано механізм, розробники ядра описали в нотатці про захист від фатальних помилок у WordPress 5.2.

Чому WordPress падає після оновлення

На сайті три шари коду: ядро WordPress, тема і плагіни. Усі вони працюють на тій версії PHP, яку встановив хостинг. Оновили один шар, і код іншого може перестати з ним працювати. Типові випадки нижче.

Плагін не готовий до нової версії ядра. 19 серпня 2026 року вийшов WordPress 7.1. Наступного дня розробники плагіна кешування WP Rocket підтвердили: на 7.1 плагін валить сайти з фатальною помилкою, адмінка теж могла не відкриватися. Виправлену версію 3.23.2.2 випустили приблизно через дві з половиною години після того, як знайшли причину. Тим, хто залишився без адмінки, документація WP Rocket радила перейменувати папку плагіна через FTP. Сам плагін того дня не оновлювався: сайти зламало оновлення ядра.

Плагін оновився з помилкою. 29 липня 2026 року власник сайту написав на форумі wordpress.org: після оновлення YOP Poll із 7.0.7 до 7.0.8 адмінка перестала відкриватися через критичну помилку. Допоміг відкат на 7.0.7. Власник вимкнув автооновлення плагіна, і підтримка плагіна це рішення схвалила.

Тема або код у functions.php. Найчастіше ламаються теми, куплені багато років тому й відтоді жодного разу не оновлені, та правки прямо у файлах теми без дочірньої теми (теми-надбудови, правки в якій переживають оновлення основної).

Зміна версії PHP. Хостинг перевів сайт на PHP 8.2 або 8.3, а старий плагін використовує функції, яких у новій версії немає. Терміни підтримки PHP і порядок переходу розібрано у статті про те, що робити власнику сайту, коли PHP 8.1 і 8.2 залишаються без підтримки.

Не вистачило пам’яті. У журналі це запис «Allowed memory size of … bytes exhausted». Після оновлення плагін може отримати важку функцію і впертися в ліміт пам’яті PHP. За замовчуванням WordPress намагається виділити собі 40 МБ на звичайному сайті та 64 МБ на мультисайті (мережі сайтів на одній інсталяції WordPress). Ліміт піднімають константою WP_MEMORY_LIMIT, верхню межу задає хостинг. Піднятий ліміт прибирає симптом; якщо плагіну перестало вистачати пам’яті, якої до оновлення вистачало із запасом, розбиратися потрібно з плагіном.

Оновлення перервалося. Хостинг обірвав процес через тайм-аут, закінчилося місце на диску, закрилася вкладка браузера. Частина файлів залишилася старою, частина стала новою. Ознака такого збою — напис «Сайт ненадовго закритий на технічне обслуговування. Зайдіть через хвилину». На час оновлення WordPress створює в корені сайту файл .maintenance і через 10 хвилин перестає його враховувати. Якщо напис тримається довше, ви, найімовірніше, бачите збережену копію сторінки: скиньте кеш плагіна, сервера і CDN (мережі серверів, яка роздає копії сторінок, наприклад Cloudflare). Сам файл .maintenance після невдалого оновлення можна видалити вручну.

Конфлікт двох плагінів. Окремо кожен працює, разом падають. Часті пари: плагін кешування і конструктор сторінок; два плагіни в оформленні замовлення WooCommerce.

Сайт лежить: порядок дій

Якщо сайт приносить заявки або продажі, спочатку повертають його до роботи, потім шукають причину. Виконуйте кроки по черзі, нічого не пропускаючи.

Крок 1. Увійдіть за посиланням із листа

Перейдіть за посиланням, увійдіть як адміністратор і відкрийте «Плагіни» або «Вигляд → Теми». WordPress позначить винуватця і покаже текст помилки. Далі два варіанти: деактивувати плагін або встановити його попередню версію (крок 5). Потім вийдіть із режиму відновлення кнопкою у верхній панелі та перевірте сайт у звичайному вікні браузера, без входу в адмінку.

Листа немає? Відкрийте адреса-сайту/wp-admin/ (чому це допомагає, сказано вище), зачекайте кілька хвилин і перевірте папку «Спам». Якщо лист так і не надійшов, переходьте до кроку 2.

Крок 2. Знайдіть помилку в журналі

Спочатку відкрийте панель хостингу. У більшості хостингів там є журнал помилок PHP (error_log), і фатальна помилка зазвичай уже записана в ньому з ім’ям файлу та номером рядка, без налаштувань у WordPress. Якщо журналу немає або він порожній, увімкніть журнал самого WordPress, файл debug.log. Потрібен доступ до файлів сайту: файловий менеджер у панелі хостингу, FTP або SFTP. У wp-config.php перед рядком /* That's all, stop editing! Happy publishing. */ додайте (або виправте, якщо такі рядки вже є):

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Відкрийте зламану сторінку ще раз. Помилка запишеться у wp-content/debug.log. Знайдіть рядок із «PHP Fatal error» і подивіться шлях до файлу: wp-content/plugins/назва-папки/… вказує на плагін, wp-content/themes/… на тему.

WP_DEBUG_DISPLAY зі значенням false обов’язковий: інакше текст помилки зі шляхами до файлів побачать відвідувачі. Друге застереження: папка wp-content відкрита в інтернет, і на багатьох серверах debug.log можна скачати за прямою адресою. Коли причину знайдено, поверніть WP_DEBUG у false і видаліть файл. Якщо журнал потрібен надовго, вкажіть у WP_DEBUG_LOG шлях до файлу поза публічною папкою (так можна з версії 5.1). Усі параметри описано в офіційному посібнику з налагодження WordPress.

Крок 3. Вимкніть плагін без адмінки

Відкрийте wp-content/plugins/ і перейменуйте папку плагіна з журналу, наприклад wp-rocket на wp-rocket-off. WordPress не знайде плагін і деактивує його. Сайт, найімовірніше, відкриється.

Якщо хостинг надає доступ через SSH і WP-CLI (консольну утиліту для керування WordPress), підійде команда wp plugin deactivate wp-rocket --skip-plugins. Ключ --skip-plugins не дає зламаному плагіну завантажитися і зламати саму команду.

Якщо журнал нічого не показав, перейменуйте всю папку plugins на plugins_old: вимкнуться всі плагіни одразу. Потім поверніть ім’я і вмикайте плагіни в адмінці по одному, доки помилка не повернеться. У робочому магазині так робити не варто: разом із плагінами вимкнуться оплата, доставка і форми. Цей спосіб — для пошуку причини на копії сайту.

«Обов’язкові» плагіни з папки wp-content/mu-plugins так не вимикаються. Вони завантажуються завжди, кнопки вимкнення в них немає, у звичайному списку плагінів їх не видно. Їх часто встановлює хостинг або попередній розробник, і під час пошуку причини про них забувають.

Якщо винна тема, перейменуйте її папку у wp-content/themes/. WordPress перемкнеться на стандартну тему, якщо її встановлено. Оформлення зміниться, зате адмінка запрацює.

Крок 4. Якщо напередодні змінювали версію PHP

Поверніть попередню версію PHP у панелі хостингу, якщо хостинг її ще пропонує. Сайт запрацює, а несумісний плагін або тему ви спокійно оновите чи заміните на тестовій копії. Затримуватися на старій версії PHP надовго не варто: терміни підтримки розібрано у статті PHP 8.1 і 8.2 без підтримки.

Крок 5. Відкотіть версію або відновіть резервну копію

У плагінів із каталогу wordpress.org на вкладці «Додатково» є блок «Previous Versions». Звідти можна скачати попередню версію і встановити її замість зламаної. Каталог попереджає, що старі версії можуть бути небезпечними, тому відкат — тимчасовий захід, доки розробник не випустить виправлення. У платних плагінів попередні версії зазвичай лежать в особистому кабінеті на сайті продавця.

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

Чого не робити

• Не видаляйте плагін кнопкою «Видалити». Деякі плагіни під час видалення стирають свої налаштування і таблиці. Для вимкнення достатньо перейменувати папку.
• Не перевстановлюйте WordPress поверх сайту наосліп. Під час ручної заміни ядра зберігають wp-config.php і папку wp-content, інакше разом із помилкою зникнуть завантажені файли і теми.
• Не піднімайте ліміт пам’яті до максимуму «про всяк випадок» і не залишайте журнал помилок увімкненим.
• Не правте код плагіна на робочому сайті. Виправлення зникне під час наступного оновлення.

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

Який відкат уже вбудовано у WordPress

У WordPress є два механізми відкату і правило автооновлення ядра. Від критичної помилки після оновлення вони захищають лише у вузьких випадках.

• З версії 6.3 під час ручного оновлення плагіна або теми стара версія тимчасово переноситься у wp-content/upgrade-temp-backup/. Якщо встановлення зірвалося (не скачався архів, не скопіювалися файли), WordPress поверне стару версію. Якщо нова версія встановилася і вже потім вивела сайт з ладу, механізм не спрацює.
• З версії 6.6 після автооновлення активного плагіна WordPress сам запитує головну сторінку і перевіряє її на фатальну помилку. У разі помилки повертається попередня версія, адміністратор отримує лист. Перевіряється лише головна: помилку в кошику, особистому кабінеті або адмінці перевірка не помітить. Теми не перевіряються взагалі.
• Мінорні оновлення ядра, тобто виправлення і патчі безпеки на кшталт 7.1.3 → 7.1.4, WordPress встановлює сам (станом на листопад 2026 актуальна версія 7.1.4, вийшла 28 жовтня). З мажорними інакше. Сайт, встановлений на WordPress 5.6 або новішій версії, за замовчуванням сам переходить і на нову мажорну версію, наприклад із 7.0 на 7.1. Перевірте це у «Майстерня → Оновлення». Якщо там написано «Цей сайт автоматично оновлюється при виході кожної нової версії WordPress», натисніть посилання «Перемкнути на автоматичне встановлення тільки випусків технічного оновлення та безпеки». Хостинг або плагін можуть змінювати це налаштування.

Як оновлювати WordPress без простою

Нижче регламент, який ми вважаємо мінімально достатнім для сайту, що приносить гроші. Для візитівки на п’ять сторінок частину кроків можна спростити, для магазину не можна.

1. Перевірена резервна копія

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

2. Тестова копія (staging)

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

Копію роблять свіжою, безпосередньо перед оновленням. Staging тримісячної давності з іншим набором плагінів нічого не перевіряє.

3. Порядок оновлення

На тестовій копії:

1. Прочитайте список змін і вимоги великих плагінів (WooCommerce, конструктор сторінок, кешування, платіжні модулі): чи є згадки про несумісність, яка версія WordPress потрібна.
2. Вирішіть, що оновлювати першим. Якщо нова версія плагіна вимагає новіше ядро, починайте з ядра: так, WooCommerce 10.8 вимагає WordPress 6.9 або новіший і прямо радить спочатку оновити WordPress. Якщо таких вимог немає, ми радимо спочатку оновити плагіни і тему до версій, які працюють на поточному ядрі, а мажорну версію ядра встановлювати окремим кроком. Тоді у разі збою одразу видно, що його спричинило.
3. Оновлюйте плагіни по одному, починаючи з тих, від яких залежать інші: спочатку WooCommerce, потім його розширення. Після кожного відкривайте сайт.
4. Оновіть тему. Якщо тема дочірня, оновлюється батьківська.
5. Пройдіть перевірочні сценарії (нижче).

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

Мажорні версії ядра на робочий сайт у день виходу ми встановлювати не радимо. Дочекайтеся виправлень в основних плагінах і перевірте сайт на копії. Випадок WP Rocket і WordPress 7.1 показує, навіщо: сайти, які відклали оновлення ядра хоча б на кілька днів, до того часу вже могли встановити виправлену версію плагіна. Відкладати на пів року теж погано: нові версії плагінів перестають підтримувати старе ядро, як у прикладі з WooCommerce. Наступну мажорну версію, WordPress 7.2, заплановано на 8 грудня 2026 року.

З оновленнями безпеки плагінів логіка зворотна: їх встановлюють швидко. За звітом Patchstack за 2025 рік, у масово атакованих вразливостей зважена медіана часу до першої атаки становила 5 годин. Якщо у списку змін плагіна написано «security fix», оновлення встановлюють того ж дня, перевіривши хоча б головні сценарії.

4. Перевірочні сценарії

«Головна відкрилася» ще не означає, що сайт працює. Запишіть сценарії один раз і проходьте їх після кожного оновлення:

• головна, каталог, картка товару (для варіативних товарів виберіть кілька варіантів);
• пошук і фільтри;
• кошик, оформлення замовлення, тестова оплата або хоча б перехід на сторінку платіжної системи;
• лист про замовлення надійшов покупцеві та менеджеру, замовлення з’явилося в адмінці та, якщо є інтеграція, в обліковій системі або CRM;
• форми заявок: заявка дійшла до пошти або CRM, а не лише показала «Дякуємо»;
• вхід в особистий кабінет і в адмінку;
• мобільна версія;
• усе те саме після скидання кешу плагіна, сервера і CDN.

5. Моніторинг після оновлення

Частина помилок виявляється не одразу: на рідко відвідуваній сторінці, у фоновому завданні, під час оплати певним способом. Моніторинг доступності повідомить, якщо сайт перестав відповідати. Журнал помилок PHP у панелі хостингу (не debug.log, його ми вимкнули) у перші дні після оновлення переглядайте окремо. Резервну копію, зняту перед оновленням, не видаляйте, доки не переконаєтеся, що все працює.

Автооновлення: вмикати чи ні

З версії 5.5 WordPress дає змогу ввімкнути автооновлення для кожного плагіна і кожної теми окремо: колонка «Автоматичні оновлення» на сторінці «Плагіни» і посилання в картці теми. За замовчуванням вони вимкнені. Про проведене або зірване автооновлення WordPress пише адміністратору на пошту; ці листи потрібно читати, а не відсилати у фільтр. Докладніше в документації wordpress.org про автооновлення.

Наша позиція:

• Мінорні оновлення ядра залиште ввімкненими. Це виправлення і патчі безпеки; розробники ядра пишуть, що вимикати їх наполегливо не рекомендується.
• Мажорні оновлення ядра на сайті, який продає, встановлюйте вручну за регламентом, а автоматичний перехід на нові версії вимкніть (як це зробити, написано в розділі про вбудований відкат).
• Плагіни, через які йдуть гроші (WooCommerce і його розширення, оплата, доставка, конструктор сторінок, кешування), оновлюйте вручну через тестову копію. Випадок YOP Poll показує, що одне оновлення плагіна може закрити доступ до адмінки. Автооновлення відбувається без вас, часто вночі, а вбудована перевірка стосується лише головної. Помилку в оформленні замовлення першими побачать покупці.
• Прості плагіни без впливу на замовлення і верстку (наприклад, редирект або карта сайту) можна залишити на автооновленні.

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

Коли впораєтеся самі, а коли потрібен спеціаліст

Власник сайту або маркетолог впорається сам, якщо:

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

Кличте спеціаліста, якщо:

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

Як із цим допомагає RIVERIT

Пропонуємо взяти сайт на техпідтримку WordPress. Оновлення ядра, тем і плагінів зазвичай проводимо раз на місяць, резервні копії входять у підтримку, сайт і домен перебувають під моніторингом. Клієнтам на підтримці відповідаємо протягом години, іншим протягом робочого дня; якщо сайт упав уночі або у вихідний, лагодимо і поза робочим часом, коли це входить у тариф. Для сайтів на Laravel або Django є загальний розділ підтримки та супроводу сайтів. Вартість розраховуємо під обсяг і складність сайту.