Как настроить robots.txt для закрытия от индекса служебных страниц WordPress

Автор: Евгения Данилова | Опубликовано: 28.08.2026

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

Ниже — рабочий сценарий: что именно закрывать, как не сломать сайт, чем robots.txt отличается от noindex, и как проверить, что всё сработало после правки.

Что именно стоит закрывать в robots.txt

Смысл настройки не в том, чтобы запретить всё подряд. Если закрыть важные разделы, поисковый робот перестанет видеть контент, а в Search Console появятся странные статусы. Для типового WordPress-сайта обычно имеет смысл ограничить обход служебных страниц и технических URL, которые не несут ценности для поиска.

Типовые кандидаты на закрытие

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

Важно: robots.txt не удаляет URL из индекса мгновенно и не гарантирует, что страница не появится в выдаче, если на неё есть внешние ссылки. Для удаления из индекса чаще нужен noindex или корректная настройка каноникал.

Диагностика: почему служебные страницы вообще попадают в обход

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

Что посмотреть в первую очередь

отчёт «Страницы» в Google Search Console;
список URL, которые робот обходит чаще всего;
лог сервера, если он доступен;
результаты поиска по сайту: site:example.com и отдельные служебные URL;
наличие дублей с параметрами, например ?replytocom=, ?amp, ?s=.

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

Пошаговая настройка robots.txt в WordPress

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

Шаг 1. Проверьте текущий robots.txt

Откройте https://ваш-домен.ru/robots.txt и посмотрите, что уже отдаётся. Частая ошибка — редактировать файл у себя локально, но не загрузить его на сервер, либо забыть, что SEO-плагин тоже может генерировать правила.

Шаг 2. Добавьте базовые правила

Для большинства сайтов достаточно аккуратного набора правил без лишней агрессии:

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

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

Здесь есть важная деталь: admin-ajax.php часто нужен фронтенду и плагинам, поэтому его обычно разрешают отдельно. Если вы закроете весь /wp-admin/ без исключения, это не всегда проблема для SEO, но некоторые интеграции могут начать вести себя странно.

Шаг 3. Добавьте точечные запреты для мусорных URL

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

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-login.php
Disallow: /search/
Disallow: /*?s=
Disallow: /*?replytocom=
Sitemap: https://example.com/sitemap_index.xml

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

Шаг 4. Не закрывайте sitemap и важные CSS/JS без причины

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

Когда robots.txt не подходит и нужен noindex

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

Подход	Когда использовать	Минус
`robots.txt`	Для служебных URL, которые не должны обходиться	Не удаляет уже проиндексированные страницы
`noindex`	Для публичных страниц без SEO-ценности	Робот должен иметь доступ к странице
Каноникал	Для дублей и параметров	Не всегда достаточно без других мер

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

Пример: как добавить правила через functions.php

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

add_filter('robots_txt', function ($output, $public) {
    $rules = array(
        'User-agent: *',
        'Disallow: /wp-admin/',
        'Allow: /wp-admin/admin-ajax.php',
        'Disallow: /wp-login.php',
        'Sitemap: ' . home_url('/sitemap_index.xml'),
    );

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

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

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

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

Откройте /robots.txt в браузере и убедитесь, что файл отдаётся без ошибок;
проверьте, что sitemap указан корректно и доступен по прямой ссылке;
в Google Search Console используйте проверку URL для нескольких страниц, которые должны быть закрыты;
посмотрите, не исчезли ли из обхода важные CSS/JS и публичные разделы;
сравните отчёт о сканировании до и после изменения, если у вас есть доступ к логам.

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

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

Закрыли весь сайт по ошибке

Иногда в файл попадает Disallow: /, и сайт перестаёт нормально обходиться. Такое бывает после копирования правил из тестовой среды. Исправление простое: уберите общий запрет, оставьте только точечные строки и проверьте доступность sitemap.

Запретили CSS и JS

Если в robots закрыты каталоги темы или плагинов, поисковик может хуже рендерить страницы. Уберите запрет на публичные ресурсы, особенно если они нужны для отображения контента.

Путают robots.txt и noindex

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

Оставили конфликтующие правила от плагина

Если SEO-плагин генерирует свой robots.txt, а вы добавили физический файл с другим содержимым, результат может отличаться от ожидаемого. Проверьте, какой вариант реально отдаётся сервером. Иногда нужно отключить генерацию в плагине или перенести правила в его настройки.

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

Закрытие служебных URL помогает не только SEO, но и снижает шум в логах. Однако не стоит пытаться спрятать безопасность только через robots.txt: это не защита, а рекомендация для роботов. Админку и логин нужно защищать нормальными средствами — сложными паролями, ограничением попыток входа, 2FA и актуальными обновлениями.

Если задача шире и вам нужно одновременно чистить дубли, управлять индексированием и убирать лишние технические сущности, удобнее делать это через один SEO/cleanup-инструмент, а не разносить по десятку плагинов. В таких сценариях полезно смотреть в сторону решений вроде Clearfy Pro, если вам подходит именно набор функций, а не отдельная точечная правка.

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