На рабочем сайте отладка WordPress часто включается случайно: после переноса, при проверке плагина или из-за старого wp-config.php. В результате в wp-content/debug.log начинают сыпаться предупреждения, лог растёт, а в некоторых случаях сайт ещё и отдаёт сообщения об ошибках посетителям. Это не только шум, но и лишняя нагрузка на диск и риск утечки служебной информации.
Ниже — рабочая схема: как понять, что отладка действительно включена, как отключить её без побочных эффектов и как проверить результат.
Когда проблема уже видна
Сначала стоит убедиться, что речь именно об отладочном выводе WordPress, а не о фатальной ошибке плагина или темы. Типичные признаки:
- в корне сайта или в
wp-contentпоявился или постоянно растётdebug.log; - на страницах фронтенда видны строки
Notice,WarningилиDeprecated; - в
wp-config.phpестьdefine('WP_DEBUG', true);или включён вывод ошибок; - хостинг жалуется на переполнение диска из-за логов.
Если сайт работает, но в логах много предупреждений, это не всегда критично для посетителя. Но на продакшене такие сообщения лучше не держать включёнными: они мешают диагностике и могут раскрывать пути к файлам, названия плагинов и структуру проекта.
Что именно нужно отключить
В WordPress за отладку обычно отвечают несколько констант. Их часто путают, хотя смысл разный:
| Параметр | Что делает | Что ставить на рабочем сайте |
|---|---|---|
WP_DEBUG | Включает режим отладки WordPress | false |
WP_DEBUG_LOG | Пишет ошибки в debug.log | false или убрать строку |
WP_DEBUG_DISPLAY | Показывает ошибки на экране | false |
SCRIPT_DEBUG | Подключает неминифицированные скрипты core | false |
На практике для продакшена обычно отключают всё, что связано с выводом и записью отладки. Если нужен сбор ошибок, лучше делать это точечно и осознанно, а не держать открытым весь debug-режим.
Пошаговое решение в wp-config.php
Самый надёжный способ — проверить wp-config.php и привести настройки к рабочему виду. Файл находится в корне установки WordPress, рядом с wp-admin и wp-includes.
1. Найдите блок с отладкой
Обычно он выглядит так:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', true);
@ini_set('display_errors', 1);Для рабочего сайта это неудачная конфигурация. Если отладка не нужна постоянно, замените блок на такой вариант:
define('WP_DEBUG', false);
define('WP_DEBUG_LOG', false);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);Если строки WP_DEBUG_LOG или WP_DEBUG_DISPLAY у вас отсутствуют, это нормально. Важнее, чтобы не было включённого вывода ошибок и постоянной записи в лог без необходимости.
2. Проверьте, нет ли дублирующих настроек
Иногда отладка включается не только в wp-config.php, но и в файлах окружения, в mu-плагинах или через панель хостинга. Если после правки лог всё равно растёт, ищите повторное определение констант:
grep -R "WP_DEBUG\|WP_DEBUG_LOG\|WP_DEBUG_DISPLAY" .Если доступа к SSH нет, проверьте хотя бы wp-config.php, mu-plugins и настройки хостинга. На некоторых панелях есть отдельный переключатель «режим отладки» или «логирование ошибок PHP».
Что делать с уже созданным debug.log
Отключить отладку недостаточно, если файл уже разросся. Его можно удалить или обнулить после того, как вы убедились, что он больше не пополняется. Но сначала проверьте, не используется ли лог для активной диагностики.
- Если сайт уже стабилен — удалите
wp-content/debug.log. - Если нужен контроль, сначала переименуйте файл и проверьте, создаётся ли новый.
- Если лог возвращается — значит, отладка включена где-то ещё.
Удалять лог безопасно, если вы не используете его как единственный источник диагностики. Но не стоит оставлять его доступным на публичном сервере надолго: это лишний мусор и потенциальный источник информации для посторонних.
Проверка результата после внедрения
После правки нужно убедиться, что WordPress больше не пишет отладочные сообщения и не показывает их пользователю.
Проверка в браузере
- Откройте несколько страниц сайта в режиме инкогнито.
- Проверьте исходный код и видимую часть страницы на наличие
Notice,Warning,Deprecated. - Обновите страницу несколько раз и посмотрите, не появляются ли новые сообщения.
Проверка на сервере
Если есть SSH, посмотрите размер и время изменения файла:
ls -lh wp-content/debug.log
stat wp-content/debug.logЕсли файла нет — это нормально, когда WP_DEBUG_LOG выключен. Если файл есть, но время изменения не меняется после посещения сайта, значит запись остановлена.
Проверка через админку и логи хостинга
Иногда ошибки продолжают идти не в debug.log, а в системный лог PHP на стороне хостинга. Это уже отдельный слой диагностики. Если после отключения WordPress-отладки сайт всё равно пишет ошибки, смотрите логи PHP-FPM, Apache или Nginx в панели хостинга.
Частые ошибки и как их исправить
WP_DEBUG выключили, но сообщения остались
Причина обычно в том, что ошибки выводит не WordPress, а сам PHP или плагин. Проверьте display_errors на уровне сервера и настройки хостинга. Ещё один вариант — в теме или плагине вручную вызывается ini_set('display_errors', 1).
Лог не исчезает после правки
Значит, где-то есть ещё одно определение констант. В WordPress константы нельзя переопределить обычным способом, поэтому важно найти первое включение. Ищите в wp-config.php, mu-plugins, кастомных плагинах и файлах автозагрузки.
Сайт перестал показывать ошибки, но проблема не решена
Это частая ловушка. Вы просто скрыли симптомы. Если на сайте есть предупреждения или deprecated-сообщения, их нужно исправлять в коде темы или плагина, а не только прятать. Иначе после обновления WordPress проблема вернётся уже в более жёсткой форме.
Файл debug.log удалили, а он создался снова
Это означает, что отладка всё ещё включена. Проверьте, не стоит ли define('WP_DEBUG_LOG', true); в другом месте, и не активирует ли логирование плагин безопасности, сборщик ошибок или настройка хостинга.
Когда отладку лучше оставить включённой
Есть сценарии, где постоянное отключение не лучший вариант: staging-окружение, тестовый клон сайта, локальная разработка. Там логирование помогает ловить регрессии после обновлений темы и плагинов. Но даже в таком случае лучше разделять окружения: на продакшене — минимум вывода, на тестовом стенде — полноценная диагностика.
Если у вас несколько окружений, удобно держать разные конфигурации через отдельные файлы или переменные окружения, а не руками править wp-config.php перед каждым деплоем. Это снижает шанс случайно оставить отладку включённой на боевом сайте.
Практические советы по безопасности и производительности
- Не оставляйте
WP_DEBUG_DISPLAYвключённым на публичном сайте. - Регулярно проверяйте
wp-contentна большие логи и временные файлы. - После обновлений темы и плагинов просматривайте логи на предмет новых предупреждений.
- Если нужен сбор ошибок, ограничьте его тестовым окружением или временным окном диагностики.
- Не храните в логах чувствительные данные дольше, чем это нужно для разбора проблемы.
Если вам нужен более широкий набор инструментов для чистки WordPress и контроля технических дублей, в некоторых проектах удобно использовать Clearfy Pro: https://wpshop.ru/plugins/clearfy?utm_source=wpbuy.ru&utm_medium=article&utm_campaign=kak-otklyuchit-otladku-wordpress-i-ubrat-logi-debug-log
Главная проверка простая: после правки wp-config.php сайт открывается без сообщений об ошибках, а wp-content/debug.log больше не пополняется. Если это так, отладка действительно отключена, а не просто скрыта от глаз.