Если на сайте включали отладку, а потом забыли убрать файлы логов из публичной зоны, поисковик может увидеть не только технический мусор, но и пути, запросы, имена плагинов, фрагменты кода и иногда чувствительные данные. Это не редкая история: debug.log лежит в wp-content, а error_log создаётся там, где PHP получил право писать файл. Проблема не в самом логе, а в том, что он доступен по прямой ссылке.
Ниже — рабочая схема: как найти такие файлы, закрыть их от веб-доступа, проверить результат и не потерять возможность смотреть ошибки на сервере.
Когда это действительно проблема
Сценарий обычно один из трёх. Лог лежит в корне сайта или в wp-content и открывается по URL. Лог попал в индекс после временной отладки на staging, а потом сайт переехал в прод. Или хостинг пишет error_log в каталог, который отдаётся веб-сервером как обычный файл.
Опасность не только в индексации. Если файл доступен по HTTP, его может скачать любой, кто угадает путь. Внутри часто оказываются:
- пути к файлам и структуре проекта;
- названия активных плагинов и тем;
- SQL-ошибки и фрагменты запросов;
- служебные сообщения с токенами или ID, если разработчик их выводил в лог.
Диагностика: где именно лежит лог и открыт ли он наружу
Сначала нужно понять, какой файл вообще доступен. На практике проверяют wp-content/debug.log, корневой error_log, а иногда ещё логи, которые создаёт сам хостинг в домашнем каталоге сайта. Если есть SSH, проще всего найти свежие файлы по имени.
find /path/to/site -type f \( -name "debug.log" -o -name "error_log" \) -lsЕсли SSH нет, проверьте вручную через браузер или curl. Для WordPress-лога типичный путь такой:
curl -I https://example.com/wp-content/debug.logЕсли ответ 200 OK, файл открыт. Если 403 Forbidden или 404 Not Found, уже лучше. Но этого мало: иногда сервер отдаёт файл без индексации, а поисковик всё равно успел его сохранить в выдаче. Тогда нужно закрыть и доступ, и индексацию.
Что искать в robots.txt, а что — в настройках сервера
robots.txt помогает только с индексацией. Он не запрещает скачивание файла. Поэтому строка вроде Disallow: /wp-content/debug.log полезна, но не решает вопрос безопасности. Основной барьер должен быть на уровне веб-сервера или прав доступа к файлу.
| Способ | Что решает | Минус |
|---|---|---|
| .htaccess / nginx rules | Блокирует прямой HTTP-доступ | Нужно править конфиг под свой сервер |
| Права на файл | Ограничивает чтение на уровне ОС | Не всегда достаточно, если веб-сервер и PHP работают от одного пользователя |
| robots.txt | Снижает риск индексации | Не защищает от прямого запроса |
Пошаговое решение для Apache и nginx
Если сайт работает на Apache, проще всего закрыть конкретный файл или весь набор логов через .htaccess. Для nginx правило добавляют в конфиг сервера. В обоих случаях задача одна: не отдавать debug.log и error_log по HTTP.
Apache: блокировка через .htaccess
Добавьте правило в корень сайта или в wp-content/.htaccess, если лог лежит именно там. Для одного файла достаточно такого варианта:
<Files "debug.log">
Require all denied
</Files>Если нужно закрыть несколько типовых логов, можно расширить правило:
<FilesMatch "^(debug\.log|error_log)$">
Require all denied
</FilesMatch>На старых конфигурациях Apache 2.2 встречается синтаксис Deny from all, но если сайт уже работает на современном сервере, лучше использовать Require all denied.
nginx: запрет на отдачу логов
В nginx правило обычно добавляют в блок server. Для конкретных файлов подойдёт такой вариант:
location ~* /(debug\.log|error_log)$ {
deny all;
access_log off;
log_not_found off;
}Если лог лежит в отдельной папке, можно закрыть весь каталог. Но не делайте это вслепую: сначала проверьте, не храните ли там ещё что-то нужное для сайта.
Если доступ к конфигу сервера ограничен
На shared-хостинге часто можно править только файлы сайта. Тогда минимум — убрать лог из публичной директории, если это возможно, и отключить прямую запись в wp-content/debug.log после завершения отладки. Для WordPress это делается в wp-config.php:
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );Если отладка нужна, но лог не должен лежать в webroot, можно указать собственный путь вне публичной директории. Важно, чтобы PHP имел право туда писать:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/var/log/site/wp-debug.log' );
define( 'WP_DEBUG_DISPLAY', false );Такой путь нужно подставлять реальный, а не выдуманный. На хостинге он зависит от структуры аккаунта и прав пользователя.
Как проверить, что решение сработало
Проверка должна быть не на глаз, а через HTTP-ответ. Сначала запросите файл напрямую:
curl -I https://example.com/wp-content/debug.logНужный результат — 403 или 404. Если всё ещё 200, правило не применилось или файл отдаётся из другого места. Затем проверьте, не осталась ли страница в индексе поисковика: иногда старый URL ещё виден в выдаче, даже если файл уже закрыт. В этом случае можно отправить его на переобход через инструменты для вебмастеров и дождаться обновления.
Полезно проверить и сам серверный лог ошибок. Если вы перенесли путь для WP_DEBUG_LOG, создайте тестовую ошибку в безопасной среде и убедитесь, что файл записывается туда, куда вы указали. Иначе можно случайно отключить отладку совсем.
Частые ошибки и как их исправить
- Закрыли только robots.txt. Это не защита. Нужно блокировать прямой доступ через сервер или права на файл.
- Поставили правило не в тот каталог. Для Apache
.htaccessдолжен находиться там, где его реально читает сервер. Для nginx правка в файле сайта без перезагрузки конфигурации ничего не даст. - Отключили
WP_DEBUG_LOG, но файл остался доступен. Старый лог не исчезает сам. Его нужно удалить или переместить, а потом закрыть доступ. - Спрятали лог в публичной папке с нестандартным именем. Если имя файла не попадает под правило, он всё равно откроется. Проверьте все варианты, которые использует хостинг.
- Поставили слишком широкое правило. Например, закрыли весь
wp-contentили папку с медиа. После этого ломаются загрузки, стили или кэш. Блокируйте только конкретные файлы и каталоги.
Что делать с безопасностью и производительностью дальше
Если отладка нужна постоянно, лучше не держать её в публичной директории. Лог вне webroot — более безопасный вариант, но следите за размером файла: на шумном сайте он быстро разрастается и начинает мешать диагностике. Старые логи стоит чистить вручную или через ротацию на уровне сервера.
Ещё один практический момент: не оставляйте WP_DEBUG включённым на боевом сайте без необходимости. Даже если вывод на экран отключён, лишние предупреждения и записи в лог могут замедлять запросы и засорять файл. Для разовой диагностики включайте отладку точечно, а после проверки возвращайте настройки в исходное состояние.
Если нужен более прикладной контроль над техническим мусором и дублирующимися служебными элементами, в проектах иногда используют Clearfy Pro: он помогает убрать часть лишнего технического шума и навести порядок в базовых SEO-настройках. Но для логов это не замена серверной блокировке — доступ к файлу всё равно нужно закрывать на уровне веб-сервера или прав.
Мини-чек-лист перед публикацией
- Проверен фактический путь к
debug.logиerror_log. - Файл закрыт от прямого HTTP-доступа через Apache или nginx.
- Старый лог удалён или перенесён из публичной директории.
WP_DEBUG_LOGлибо выключен, либо указывает на безопасный путь.- Проверка через
curl -Iвозвращает403или404. - В поиске больше не находится открытый URL лога.
Если после всех правок файл всё ещё открывается, почти всегда проблема в одном из трёх мест: правило не подхватилось, лог лежит в другом каталоге, или доступ к нему отдаёт не тот слой — например, CDN или кэширующий прокси. В таком случае проверять нужно уже цепочку целиком, а не только WordPress.