В WordPress robots.txt часто правят по привычке: добавляют Disallow для поиска, архивов, служебных URL и надеются, что этого достаточно. На практике именно здесь чаще всего появляются ошибки: закрывают не то, дублируют правила SEO-плагина или пытаются решить robots.txt задачу, которую он не решает. Если цель — убрать из обхода мусорные URL и не трогать важные страницы, настройка должна быть точечной.
Какие страницы действительно стоит закрывать
Сначала полезно разделить URL на три группы. Это помогает не мешать индексации контента, который нужен поиску, и не закрывать лишнее.
- Служебные страницы: внутренний поиск, страницы входа, админка, feed-ленты, технические endpoints.
- Мусорные или бесполезные для поиска URL: параметры сортировки, фильтры, служебные архивы, если они создают дубли.
- Страницы, которые не надо закрывать через robots.txt: важные категории, записи, страницы пагинации с полезным контентом, если они реально нужны в индексе.
Если у вас уже есть проблемы с дублями, сначала проверьте, не решается ли задача через noindex, canonical или настройку SEO-плагина. Robots.txt не удаляет URL из индекса, он только ограничивает обход.
Диагностика проблемы перед правкой
Перед изменением файла посмотрите, что именно сейчас отдаёт сайт. В WordPress robots.txt может быть виртуальным, а не физическим файлом в корне. Это важно: вы можете редактировать файл на сервере и не увидеть эффекта, если его перекрывает правило в плагине или конфигурации хостинга.
Что проверить вручную
- Откройте
/robots.txtв браузере и посмотрите текущие правила. - Проверьте, нет ли дублирующих блоков
User-agent: *. - Посмотрите, не закрыт ли случайно
/wp-content/uploads/или важные CSS/JS-файлы. - Проверьте, не добавляет ли SEO-плагин свой robots.txt поверх вашего.
Если сайт уже проиндексирован с мусорными URL, robots.txt сам по себе не исправит ситуацию быстро. Для уже попавших в индекс страниц обычно нужен отдельный план: убрать внутренние ссылки, поставить noindex там, где это уместно, и дождаться переобхода.
Рабочий способ: задать robots.txt через WordPress-код
Если нужен предсказуемый результат без ручного редактирования файла, проще добавить правила через фильтр robots_txt. Это штатный механизм WordPress, он не требует выдуманных API и нормально работает в теме или небольшом must-use плагине.
<?php
add_filter( 'robots_txt', function( $output, $public ) {
$lines = array(
'User-agent: *',
'Disallow: /wp-admin/',
'Disallow: /wp-login.php',
'Disallow: /search/',
'Disallow: /?s=',
'Disallow: /feed/',
);
// Разрешаем доступ к admin-ajax.php, если он нужен фронтенду.
$lines[] = 'Allow: /wp-admin/admin-ajax.php';
return implode( "\n", $lines ) . "\n";
}, 10, 2 );Этот вариант удобен, если вы хотите хранить правила в коде проекта и не зависеть от ручных правок в админке. Но есть нюанс: если SEO-плагин тоже генерирует robots.txt, нужно понять, кто именно отдаёт финальный ответ. Иначе вы будете редактировать код, а на сайте останется старый набор правил.
Когда лучше не использовать код
Если сайт ведётся контент-менеджером и правила меняются часто, удобнее держать их в SEO-плагине или в физическом robots.txt на сервере. Код хорош там, где конфигурация должна быть версионируемой и одинаковой на staging и production.
Сравнение подходов: плагин, код или физический файл
| Подход | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| SEO-плагин | Удобно править из админки | Может конфликтовать с другими источниками robots.txt | Если правит редактор или SEO-специалист |
Код через robots_txt | Контроль в репозитории, повторяемость | Нужен доступ к коду и понимание приоритетов | Для проектов с разработкой и деплоем |
| Физический файл в корне | Просто и прозрачно | Легко случайно перезаписать при обновлениях или деплое | Если хостинг и процесс публикации это позволяют |
Пошаговая настройка без лишних рисков
- Составьте список URL, которые реально не должны обходиться поисковиком.
- Проверьте, не решается ли часть задач через
noindexили canonical. - Выберите один источник robots.txt: код, плагин или физический файл.
- Добавьте только нужные правила, без «на всякий случай».
- Сохраните копию текущей версии файла или фрагмента кода.
- Проверьте итоговый
/robots.txtв браузере и через инструменты для вебмастеров.
Если у вас есть сайт на поддоменах или мультиязычность, проверьте, что правила не закрывают лишние разделы. Например, шаблонное Disallow: / в тестовой конфигурации иногда случайно уезжает на боевой сайт после деплоя.
Как проверить, что всё сработало
Проверка должна быть не только визуальной. После внедрения откройте https://ваш-домен.ru/robots.txt и убедитесь, что:
- нет дублирующихся блоков для одного и того же user-agent;
- важные ресурсы не закрыты случайно;
- правила соответствуют тому, что вы добавили в код или плагин;
- страницы поиска, логина и служебные URL действительно закрыты для обхода.
Дальше проверьте конкретный URL в панели вебмастера поисковой системы. Если страница уже была в индексе, помните: robots.txt не удаляет её мгновенно. Для удаления из индекса нужен отдельный процесс.
Частые ошибки и как их исправить
Закрывают всё подряд
Ошибка выглядит как Disallow: / или слишком широкий набор правил. В результате поисковик перестаёт обходить даже нужные страницы. Исправление простое: оставьте только конкретные служебные пути и проверьте, не закрыт ли контентный раздел.
Пытаются убрать страницы поиска только robots.txt
Если внутренний поиск уже попал в индекс, одного запрета на обход мало. Нужны дополнительные меры: noindex на самих страницах поиска, корректные ссылки и ожидание переобхода.
Дублируют правила из SEO-плагина
Когда один источник отдаёт одни правила, а второй — другие, итоговый файл становится непредсказуемым. Выберите один источник правды. Если используете код, отключите редактирование robots.txt в плагине или наоборот.
Закрывают CSS и JS
Это частая причина проблем с рендерингом в поиске. Если закрыть каталоги, где лежат стили и скрипты темы или плагинов, поисковый робот может увидеть страницу не так, как пользователь. Проверяйте, что в robots.txt нет лишних запретов на /wp-content/ целиком.
Практические советы по безопасности и производительности
Robots.txt не защищает сайт от атак и не ускоряет сервер напрямую, но помогает сократить обход мусорных URL. Это полезно для больших сайтов, где поисковый бот тратит ресурсы на служебные страницы, фильтры и бесконечные комбинации параметров.
- Не используйте robots.txt как замену авторизации.
- Не закрывайте через него то, что должно быть скрыто по безопасности.
- Для параметров и фильтров сначала проверьте, можно ли убрать генерацию лишних ссылок на уровне темы или плагина.
- Если сайт большой, следите, чтобы sitemap не содержал URL, которые вы одновременно закрыли от обхода без необходимости.
Если нужна более широкая чистка технических дублей и служебных URL, иногда удобнее делать это комплексно через SEO-инструменты и настройки индексации. Но даже тогда robots.txt должен оставаться коротким и понятным: только то, что реально нужно закрыть от обхода.