Настройка robots.txt в WordPress для закрытия системных страниц

Служебные страницы WordPress часто попадают в индекс не потому, что сайт «плохой», а потому что поисковик видит технические URL и не всегда понимает, что они не нужны в выдаче. Типичный пример — страницы поиска, архивы автора, feed-адреса, вложения, служебные endpoints и внутренние результаты фильтрации. Если их не ограничить, в индексе появляется мусор, а краулинговый бюджет уходит на обход того, что не приносит трафик.

Важно сразу разделить две задачи: robots.txt управляет обходом, а meta robots / X-Robots-Tag / canonical — индексацией. Если закрыть URL только в robots.txt, но не убрать ссылку на него и не настроить canonical, поисковик может продолжать учитывать адрес как известный, а в выдаче иногда останется только URL без сниппета. Поэтому robots.txt — это не единственный инструмент, а часть схемы.

Какие страницы WordPress обычно стоит проверить в первую очередь

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

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

• /search/ и результаты внутреннего поиска;
• /author/, если архивы авторов не несут самостоятельной ценности;
• /feed/ и RSS-ленты, если вы сознательно не используете их как канал;
• страницы вложений, если они индексируются отдельно и дублируют медиа;
• служебные URL плагинов, которые не должны обходиться роботами;
• тестовые, staging и dev-поддомены, если они случайно доступны извне.

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

Диагностика проблемы: что проверить до правки robots.txt

Сначала посмотрите, какие URL реально индексируются и какие из них не должны быть в поиске. Самая практичная проверка — поиск по сайту и отчёты в Search Console. Если в индексе есть страницы вида ?s=, /feed/, /author/ или вложения без контента, значит, ограничение обхода и индексации нужно пересмотреть.

Полезно также проверить текущий robots.txt напрямую:

https://example.com/robots.txt

И посмотреть, не перекрывает ли он важные разделы. Частая ошибка — слишком широкое правило вроде Disallow: /wp-, которое ломает доступ к критичным ресурсам или создаёт проблемы с рендерингом.

Мини-чек-лист перед изменениями

• Проверить, какие служебные URL уже в индексе.
• Убедиться, что нужные CSS и JS не закрыты в robots.txt.
• Посмотреть, не использует ли тема или плагин архивы автора и feed-адреса.
• Понять, есть ли отдельная логика для мультиязычности или поддоменов.
• Сохранить текущую версию robots.txt, чтобы быстро откатиться.

Пошаговое решение: как закрыть системные страницы без лишнего риска

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

Базовый пример robots.txt для WordPress

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /search/
Disallow: /author/
Disallow: /feed/
Disallow: /*?s=
Disallow: /?s=

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

Здесь есть несколько важных моментов. /wp-admin/ закрывается почти всегда, но admin-ajax.php обычно оставляют доступным, потому что его используют темы и плагины. Поисковый запрос закрывается и по ЧПУ-варианту, и по параметру ?s=, потому что на разных сайтах поиск может формироваться по-разному.

Если у вас есть отдельные архивы автора, которые нужны пользователям, не закрывайте их автоматически. Лучше сначала проверить, есть ли на них уникальный контент, биография, список публикаций и внутренняя перелинковка. Если архивы пустые или дублируют страницу «О сайте», их можно закрыть.

Когда лучше не полагаться только на robots.txt

Если URL уже в индексе, одного Disallow часто недостаточно. Робот перестанет обходить страницу, но сам адрес может ещё долго оставаться в базе поисковика. В таких случаях нужно дополнительно:

• убрать внутренние ссылки на этот URL;
• поставить noindex там, где это возможно;
• настроить canonical на основную страницу, если это дубль;
• при необходимости вернуть 301 на релевантный адрес.

То есть robots.txt — это про «не ходить сюда дальше», а не про «удалить всё из индекса немедленно».

Если нужно закрывать robots.txt программно

На проектах с деплоем через Git или с несколькими окружениями удобнее генерировать robots.txt из кода. В WordPress это можно сделать через фильтр robots_txt. Такой подход полезен, если правила отличаются для production и staging или если нужно не забывать про sitemap.

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

    $lines[] = 'User-agent: *';
    $lines[] = 'Disallow: /wp-admin/';
    $lines[] = 'Allow: /wp-admin/admin-ajax.php';
    $lines[] = 'Disallow: /search/';
    $lines[] = 'Disallow: /author/';
    $lines[] = 'Disallow: /feed/';
    $lines[] = 'Disallow: /*?s=';
    $lines[] = 'Disallow: /?s=';
    $lines[] = '';
    $lines[] = 'Sitemap: ' . home_url('/sitemap_index.xml');

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

Такой код лучше размещать в дочерней теме или в небольшом mu-plugin, а не в основной теме, которую вы можете обновить и потерять правку. Если сайт обслуживается командой, это ещё и проще ревизировать в pull request.

Сравнение подходов: вручную, через код или через плагин

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

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

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

1. Откройте /robots.txt и убедитесь, что правила отдаются без ошибок.
2. Проверьте, не закрыт ли /wp-admin/admin-ajax.php, если он нужен теме или плагинам.
3. В Search Console отправьте проверку robots.txt, если инструмент доступен для вашего домена.
4. Посмотрите, исчезают ли из отчётов новые обходы служебных URL.
5. Проверьте, не сломались ли формы, AJAX-фильтры, поиск и загрузка медиа на фронтенде.

Если после изменения robots.txt перестали работать элементы интерфейса, почти всегда причина в том, что закрыли не тот путь. В таком случае откатите правку и проверьте сетевые запросы в браузере: часто проблема видна сразу в DevTools.

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

Слишком широкое Disallow

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

Закрыли CSS и JS, а потом удивились проблемам с рендерингом

Если поисковик не может получить стили и скрипты, он хуже понимает страницу. Не закрывайте каталоги с ресурсами темы без необходимости. Проверяйте, что в robots.txt нет случайных правил на /wp-content/ или /wp-includes/, если они не обоснованы отдельной архитектурой.

Ожидали мгновенного удаления из индекса

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

Оставили sitemap в старом месте

После смены SEO-плагина или структуры карты сайта часто забывают обновить строку Sitemap:. В результате робот видит старый адрес, а новый sitemap не подхватывается. Проверьте, какой файл реально генерируется на сайте.

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

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

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

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