Как закрыть старые отладочные логи WordPress через PHP и .htaccess

Автор: Юлия Лебедева | Опубликовано: 16.09.2026

Если на сайте когда-то включали WP_DEBUG и WP_DEBUG_LOG, а потом просто забыли про это, в корне или в wp-content часто остаётся доступный с веба лог-файл. На живом сайте это плохая идея: в логе могут оказаться пути к файлам, SQL-ошибки, названия плагинов, фрагменты запросов и другая служебная информация, которую не стоит отдавать наружу.

Проблема обычно всплывает не сразу. Сайт работает, админка открывается, ошибок «на глаз» нет. Но если открыть /wp-content/debug.log или похожий файл напрямую, он может отдаваться как обычный текст. Ниже — рабочая схема, как это проверить и закрыть без поломки отладки на локальной машине.

Как понять, что лог уже доступен из браузера

Сначала не правьте конфиги вслепую. Проверьте, действительно ли файл читается по HTTP. Самый простой тест — открыть лог в браузере или выполнить запрос через curl.

curl -I https://example.com/wp-content/debug.log

Если в ответе видите 200 OK и тип вроде text/plain, файл доступен. Если сервер отдаёт 403 Forbidden или 404 Not Found, с доступом уже лучше. Но даже в этом случае стоит проверить, не лежат ли в публичной зоне другие служебные файлы: .log, .sql, .bak, .old, .zip.

Что именно искать

wp-content/debug.log;
старые архивы резервных копий в корне сайта;
файлы от плагинов с расширением .log;
временные дампы и копии конфигов;
остатки после ручной отладки, например phpinfo.php.

Что лучше: закрыть через PHP, .htaccess или nginx

Способ зависит от того, где именно лежит файл и какой у вас сервер. Если речь только о debug.log в wp-content, можно закрыть его на уровне веб-сервера. Если нужно ещё и не писать лог в публичную папку, тогда правится сам wp-config.php.

Подход	Когда использовать	Плюс	Минус
`wp-config.php`	Нужно убрать сам факт записи в публичную папку	Решает причину	Требует аккуратности, особенно на проде
`.htaccess`	Apache/LiteSpeed, нужно быстро закрыть доступ	Просто внедрить	Не работает на nginx
nginx location	Сайт на nginx	Надёжно и быстро	Нужен доступ к конфигу сервера

Пошагово: убираем запись лога в публичную папку

Если отладка нужна только локально или на staging, не держите лог в открытом доступе. В wp-config.php проверьте настройки отладки и путь к файлу.

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

Если вам всё же нужен лог на время диагностики, лучше писать его не в публичный каталог. Например, можно указать путь вне web-root, если хостинг это позволяет:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/var/log/wp-debug.log' );
define( 'WP_DEBUG_DISPLAY', false );

Такой вариант безопаснее, потому что файл не лежит в директории, доступной по URL. Но путь должен быть доступен PHP-процессу на запись. Если прав на запись нет, лог просто не появится, и это легко пропустить без проверки.

Как закрыть доступ через .htaccess

Если сайт работает на Apache или LiteSpeed, добавьте правило в .htaccess внутри wp-content или в корне, если нужно закрыть несколько типов файлов. Для debug.log достаточно точечного правила:

<FilesMatch "^(debug\.log)$">
    Require all denied
</FilesMatch>

Если сервер старый и использует Apache 2.2, иногда встречается синтаксис с Deny from all, но на современных установках лучше использовать Require all denied. Не смешивайте оба варианта без необходимости.

Чтобы закрыть сразу несколько расширений, можно использовать более широкий шаблон:

<FilesMatch "\.(log|sql|bak|old|zip)$">
    Require all denied
</FilesMatch>

Это уже более жёсткая мера. Перед применением проверьте, не раздаёт ли какой-то плагин свои служебные файлы из публичной папки по задумке. Обычно не должен, но на старых проектах встречаются странные решения.

Если у вас nginx: правило для конфигурации

На nginx .htaccess не работает вообще, поэтому нужен блок в конфиге сайта. Для точечного закрытия debug.log подойдёт такой вариант:

location = /wp-content/debug.log {
    deny all;
    access_log off;
    log_not_found off;
}

Если нужно закрыть все лог-файлы, можно сделать отдельный location по расширению:

location ~* \.(log|sql|bak|old|zip)$ {
    deny all;
    access_log off;
    log_not_found off;
}

После изменения конфига не забудьте проверить синтаксис и перезагрузить nginx. Иначе можно получить простой сайта из-за одной лишней скобки.

nginx -t
systemctl reload nginx

Проверка результата после внедрения

После правки нужно убедиться, что файл больше не отдаётся по HTTP, а сам WordPress не пишет лог в публичную директорию, если вы это отключали.

откройте /wp-content/debug.log в браузере;
проверьте ответ через curl -I;
сделайте тестовую ошибку на staging и посмотрите, появился ли лог в ожидаемом месте;
проверьте, не сломалась ли отладка в админке или на локальной копии;
убедитесь, что сервер отдаёт 403, а не просто пустую страницу с 200.

Полезно проверить и заголовки ответа. Если файл закрыт правильно, в браузере не должно быть содержимого лога, даже если URL угадан.

curl -I https://example.com/wp-content/debug.log

Для контроля можно временно добавить в лог заведомо тестовую запись на staging и убедиться, что она ушла в нужный файл, а не в публичный каталог.

Частые ошибки и как их исправить

Файл закрыли, но WordPress продолжает писать в публичную папку

Это значит, что вы только запретили чтение по HTTP, но не поменяли путь записи. Решение — отключить WP_DEBUG_LOG на проде или перенести лог вне web-root.

Правило в .htaccess не сработало

Чаще всего причина в том, что сайт работает на nginx, а не Apache. Ещё один вариант — .htaccess лежит не в той директории, где реально доступен файл. Для debug.log правило должно применяться именно к пути, по которому он отдаётся.

После правки nginx сайт не открывается

Обычно виноват синтаксис. Проверьте конфиг через nginx -t до перезагрузки. Ошибки в location-блоках легко ломают весь виртуальный хост.

Лог закрыт, но в публичной папке остались старые архивы

Это уже отдельная уборка. Закрытие debug.log не удаляет .zip, .sql и резервные копии. Их нужно найти и перенести вне веб-каталога или удалить, если они больше не нужны.

Что ещё стоит проверить на сайте после чистки

Если вы уже полезли в техническую часть, имеет смысл заодно пройтись по другим служебным файлам и настройкам. На практике часто остаются:

включённый WP_DEBUG_DISPLAY на проде;
старые тестовые файлы в корне сайта;
публичные бэкапы базы данных;
лишние логи плагинов;
неактуальные правила в .htaccess после миграций.

Для более широкой чистки и удаления технического мусора в WordPress иногда используют плагины уровня Clearfy Pro, но даже с ними полезно понимать, что именно вы закрываете и где лежит файл. Автоматизация не заменяет проверку URL и конфигурации сервера.

Если нужен быстрый рабочий сценарий, логика простая: отключить запись в публичную папку, закрыть доступ на уровне веб-сервера и проверить ответ по прямому URL. Это занимает меньше времени, чем потом разбирать утечку служебных данных из старого debug.log.