Как настроить robots.txt в WordPress для закрытия технических разделов

robots.txt в WordPress часто правят по привычке: закрывают всё подряд, а потом удивляются, почему поисковик продолжает видеть служебные URL или, наоборот, перестаёт нормально обходить сайт. На практике задача обычно проще: убрать из обхода технические разделы, не трогая важные страницы, медиа и CSS/JS.

Если сайт уже в индексе, robots.txt не удаляет URL из поиска сам по себе. Он только управляет обходом. Поэтому сначала важно понять, что именно вы хотите решить: сократить лишние запросы бота, скрыть служебные разделы, уменьшить нагрузку или убрать мусорные URL из crawl budget.

Что обычно закрывают в WordPress и что не нужно трогать

В большинстве проектов имеет смысл ограничить обход служебных разделов, которые не несут ценности для поиска и часто создают мусор в логах. Но закрывать всё подряд — плохая идея. Поисковику нужны доступные CSS и JS, иначе он может некорректно оценить страницу.

Что обычно можно закрыть

• /wp-admin/ — кроме admin-ajax.php, если он нужен фронтенду;
• /wp-login.php — это не для индексации, а для входа;
• /wp-json/ — только если вы точно понимаете последствия и не используете REST API для публичного контента;
• служебные параметры и внутренние поисковые страницы, если они создают мусор;
• тестовые каталоги, если они случайно доступны на продакшене.

Что лучше не закрывать

• /wp-content/uploads/ — если изображения должны индексироваться;
• CSS и JS-файлы темы и плагинов;
• публичные страницы, рубрики, записи, страницы авторов, если они нужны в поиске;
• всё, что используется для рендеринга страницы в браузере.

Диагностика: почему robots.txt не работает так, как ожидается

Перед правкой проверьте, где именно проблема. Часто дело не в robots.txt, а в мета-теге noindex, заголовке X-Robots-Tag, кэше или в том, что файл вообще не отдается из корня сайта.

Минимальная проверка выглядит так:

• откройте https://example.com/robots.txt и убедитесь, что файл доступен;
• проверьте, нет ли нескольких правил User-agent: * с конфликтующими директивами;
• посмотрите, не переписывает ли robots.txt CDN, плагин безопасности или серверный конфиг;
• проверьте, не закрыты ли важные ресурсы вроде CSS/JS;
• сравните текущий файл с тем, что реально видит бот через Search Console или аналогичный инструмент.

Если сайт на Nginx или Apache, иногда robots.txt отдается не из WordPress, а как статический файл из корня. Это нормально, но тогда изменения в админке или через плагин могут не иметь эффекта, если статический файл уже существует.

Пошаговая настройка robots.txt без лишних рисков

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

Вариант 1: вручную через файл в корне сайта

Если у вас есть доступ к FTP или файловому менеджеру, создайте или отредактируйте robots.txt в корне сайта:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-login.php

Sitemap: https://example.com/sitemap_index.xml

Этот вариант удобен тем, что файл виден сразу и не зависит от плагинов. Но если сайт обслуживает несколько человек, легко потерять контроль над правками. Тогда лучше хранить шаблон в документации и фиксировать изменения.

Вариант 2: через код темы или мини-плагин

WordPress умеет отдавать robots.txt через фильтр robots_txt. Это полезно, если файл должен собираться динамически, например, для разных окружений или поддоменов.

<?php
add_filter('robots_txt', function ($output, $public) {
    $lines = [];

    $lines[] = 'User-agent: *';
    $lines[] = 'Disallow: /wp-admin/';
    $lines[] = 'Allow: /wp-admin/admin-ajax.php';
    $lines[] = 'Disallow: /wp-login.php';

    if (function_exists('wp_sitemaps_get_server')) {
        $lines[] = '';
        $lines[] = 'Sitemap: ' . home_url('/wp-sitemap.xml');
    }

    return implode("\n", $lines) . "\n";
}, 10, 2);

Такой способ хорош, если вы не хотите держать отдельный файл в корне. Но есть важная оговорка: если физический robots.txt уже существует, WordPress-фильтр может не использоваться так, как вы ожидаете. Сначала проверьте, какой именно файл отдается сервером.

Вариант 3: через плагин SEO или чистки сайта

Если на сайте уже стоит SEO-плагин, настройка robots.txt может быть удобной через интерфейс. Это снижает риск синтаксической ошибки, но добавляет зависимость от плагина. На проектах, где нужен еще и контроль дублей, служебных страниц и мусорных URL, часто используют инструменты уровня Clearfy Pro: там удобно централизовать часть технических настроек. Но даже в этом случае итоговый robots.txt нужно проверять вручную.

Подход	Плюсы	Минусы	Когда выбирать
Файл в корне	Просто, прозрачно, быстро	Ручное сопровождение	Нужен стабильный статический файл
Фильтр robots_txt	Гибко, можно собирать динамически	Неочевидно при наличии физического файла	Нужно управлять правилами из кода
Плагин	Удобно для редактора или администратора	Зависимость от стороннего кода	Технические настройки ведет не разработчик

Как проверить, что настройка сработала

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

• откройте /robots.txt в браузере и убедитесь, что отдается нужная версия;
• проверьте HTTP-ответ: должен быть 200 OK;
• посмотрите, не закрылись ли CSS/JS в отчете о проверке URL;
• если используете Search Console, отправьте страницу на повторную проверку и посмотрите, как бот видит ресурсы;
• проверьте логи сервера: бот должен перестать ходить в закрытые служебные разделы, но продолжать обходить публичные страницы.

Если вы закрывали только /wp-admin/ и /wp-login.php, это не должно влиять на индексацию контента. Если после правки просела видимость важных страниц, проблема обычно в слишком широком Disallow, а не в самом robots.txt.

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

Закрыли слишком много

Самая частая ошибка — правило вроде Disallow: / или слишком общий шаблон, который перекрывает весь сайт. Исправление простое: сначала уберите широкое правило, потом добавьте точечные исключения. Если сайт уже успел пострадать, проверьте, не остался ли старый robots.txt в кэше CDN.

Ожидали, что robots.txt удалит страницы из поиска

Не удалит. Если URL уже в индексе, нужен другой механизм: noindex, редирект, удаление страницы с корректным кодом ответа или настройка каноникал. robots.txt здесь только ограничивает обход.

Закрыли ресурсы, нужные для рендера

Если поисковик не видит CSS/JS, он может хуже оценить мобильную версию и структуру страницы. Не закрывайте каталоги с ассетами темы и плагинов без реальной необходимости.

Правили не тот файл

На сайте может лежать статический robots.txt, а вы меняли фильтр в коде или настройки плагина. Проверьте, какой файл реально отдается по URL, и внесите изменения именно туда.

Забыли про кэш

После правки очистите серверный кэш, кэш плагина и CDN. Иначе бот и вы можете видеть разные версии файла.

Практические советы по безопасности и производительности

robots.txt не защищает от доступа к закрытым разделам. Если вам нужно реально ограничить вход, используйте авторизацию, серверные правила или базовую защиту на уровне приложения. Для /wp-admin/ и /wp-login.php это особенно важно: закрытие от бота не мешает атакующему отправлять запросы напрямую.

С точки зрения производительности полезно не только закрыть служебные URL, но и убрать причины их появления: лишние тестовые страницы, мусорные параметры, дубли архивов и неиспользуемые публичные эндпоинты. Иногда проще исправить генерацию URL, чем потом пытаться спрятать последствия в robots.txt.

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

Короткий чек-лист перед публикацией

• robots.txt открывается по /robots.txt и отдает 200 OK;
• не закрыты CSS, JS и публичные изображения без причины;
• есть строка с sitemap, если она нужна вашему проекту;
• нет широкого Disallow, который перекрывает весь сайт;
• после правки очищен кэш сервера, плагина и CDN;
• проверено, что изменения видны именно в той версии файла, которую читает бот.

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