Если в индексе появляются лишние URL с параметрами, архивы тегов, страницы поиска или служебные пути, проблема часто не в «плохом SEO», а в слабой технической настройке robots.txt и связанных с ним правил. В WordPress это особенно заметно на сайтах с фильтрами, сортировками, пагинацией и активными архивами таксономий.
Ниже разберём, что именно можно закрыть через robots.txt, где этот файл не помогает, как не переусердствовать с запретами и как проверить результат после внедрения.
Когда robots.txt действительно нужен
robots.txt управляет обходом, а не удалением страниц из индекса. Это важная оговорка: если URL уже проиндексирован, один только запрет в robots.txt не гарантирует его исчезновение из выдачи. Но файл полезен, когда нужно снизить расход краулингового бюджета и не пускать поискового робота в заведомо бесполезные разделы.
Типичные сценарии для WordPress
- страницы поиска вида
?s=; - URL с параметрами сортировки и фильтрации;
- служебные каталоги
/wp-admin/,/wp-includes/; - внутренние скрипты и системные файлы, которые не должны обходиться;
- дубли архивов, если у сайта уже есть каноникал и отдельная SEO-настройка.
Если у вас проблема именно с дублями контента, robots.txt — только часть решения. Часто параллельно нужно настроить noindex для архивов, убрать лишние таксономии, поправить канонические URL и закрыть параметры в генерации ссылок.
Диагностика проблемы перед правкой
Сначала посмотрите, какие URL реально создают мусор в индексе и обходе. Не стоит закрывать всё подряд только потому, что «так советуют в интернете».
Что проверить в первую очередь
- отчёт по страницам в Google Search Console;
- список URL с параметрами в логах сервера или аналитике;
- наличие дублей архивов категорий, тегов и авторов;
- страницы поиска WordPress и результаты внутреннего поиска;
- наличие фильтров, которые меняют URL, но не добавляют уникальный контент.
Полезно открыть несколько проблемных адресов вручную и посмотреть, чем они отличаются от основной страницы. Если контент одинаковый, а URL меняется только за счёт параметра, это кандидат на закрытие или нормализацию.
Какой подход выбрать: robots.txt, noindex или каноникал
Не все задачи решаются одним файлом. Для практики удобнее сравнить варианты заранее.
| Подход | Когда использовать | Ограничение |
|---|---|---|
| robots.txt | Закрыть обход служебных URL и бесполезных параметров | Не удаляет уже проиндексированные страницы |
noindex | Нужно убрать страницу из индекса, но оставить доступной для обхода | Страница должна быть доступна роботу |
| canonical | Есть дубли, но нужен один основной URL | Не всегда срабатывает, если дубли сильно отличаются по содержанию |
На практике robots.txt хорошо работает для служебных разделов и параметров, которые не должны обходиться вообще. Для архивов и страниц, которые уже попали в индекс, чаще нужен noindex или каноникал.
Пошаговая настройка robots.txt в WordPress
В WordPress robots.txt можно редактировать двумя способами: через корневой файл на сервере или через SEO-плагин, если он создаёт виртуальный robots.txt. Для контроля и предсказуемости я бы предпочёл реальный файл в корне сайта, если хостинг и права доступа это позволяют.
Базовый безопасный шаблон
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-includes/
Disallow: /wp-login.php
Disallow: /?s=
Disallow: /*?s=
Disallow: /*?replytocom=
Disallow: /*?orderby=
Disallow: /*?filter=
Disallow: /*?sort=
Sitemap: https://example.com/sitemap_index.xmlЭтот шаблон нужно адаптировать под сайт. Не все параметры стоит закрывать одинаково: если у вас сортировка создаёт полезные страницы, а не мусор, запрещать её не нужно. То же самое касается фильтров — иногда они формируют отдельные посадочные страницы, которые должны индексироваться.
Как добавить правило только для конкретного параметра
Если на сайте есть один проблемный параметр, лучше закрыть именно его, а не весь набор. Например, для страниц поиска и пагинации поиска:
User-agent: *
Disallow: /?s=
Disallow: /search/
Disallow: /*?s=Если фильтр живёт в URL как ?filter_color=red, можно закрыть только этот параметр. Но сначала убедитесь, что он не используется для полезных страниц, которые должны попадать в поиск.
Если robots.txt генерирует плагин
Некоторые SEO-плагины позволяют редактировать robots.txt из админки. Это удобно, но есть нюанс: плагин может перезаписывать правила при обновлении или подмешивать свои директивы. Поэтому после правки всегда проверяйте итоговый файл по адресу /robots.txt.
Если вы используете плагин для SEO и чистки дублей, проверьте, не создаёт ли он конфликт с ручными правилами. Например, один модуль может закрывать архивы, а другой — добавлять sitemap или менять структуру ссылок. В таких случаях лучше держать логику в одном месте.
Проверка результата после внедрения
После сохранения файла не ограничивайтесь открытием /robots.txt в браузере. Нужно проверить, как его видит поисковый робот и не заблокировали ли вы лишнее.
Чек-лист проверки
- откройте
https://site.ru/robots.txtи убедитесь, что файл отдаётся без редиректов и ошибок; - проверьте, что sitemap указан корректно и доступен;
- в Search Console протестируйте несколько URL с параметрами;
- убедитесь, что
/wp-admin/admin-ajax.phpне закрыт, если он нужен фронтенду; - проверьте, не заблокированы ли CSS и JS, если тема или плагин требуют их для рендеринга.
Если после правки важные страницы перестали обходиться, значит правило слишком широкое. Самая частая ошибка — закрыть не только параметр, но и целый путь, который используется для нормальных страниц.
Частые ошибки и как их исправить
Ошибка 1. Пытаются удалить страницы из индекса только через robots.txt
Это не работает как полноценное удаление. Если URL уже в индексе, поисковик может продолжать показывать его без сниппета. Решение: снять запрет на обход, добавить noindex или canonical, а затем дождаться переобхода.
Ошибка 2. Закрывают слишком много параметров одним правилом
Например, Disallow: /*? кажется удобным, но может отрезать полезные страницы с UTM-метками, фильтрами и сортировкой. Лучше закрывать только реально мусорные параметры.
Ошибка 3. Блокируют CSS и JS
Если в robots.txt случайно закрыть папки с темой или плагинами, робот может хуже рендерить страницу. Это особенно критично для сайтов, где важна проверка мобильной версии и корректного отображения блоков.
Ошибка 4. Не учитывают виртуальный robots.txt
На некоторых сайтах файл в корне отсутствует, а контент отдаёт WordPress или SEO-плагин. Тогда правка «через FTP» не даст результата, пока не отключён генератор или не изменён источник файла.
Практические советы по безопасности и производительности
robots.txt не защищает сайт от атак и не скрывает чувствительные данные. Если нужно закрыть административные зоны, используйте нормальную аутентификацию, ограничения по IP, 2FA и серверные правила доступа. Для производительности же важнее не перегружать файл лишними директивами и не превращать его в свалку из десятков исключений.
Если на сайте много дублей из-за фильтров и архивов, полезно параллельно проверить:
- не создаёт ли тема лишние архивы авторов и тегов;
- не плодят ли плагины служебные страницы без SEO-смысла;
- есть ли у страниц канонические URL;
- не генерируются ли дубли через параметры сортировки и UTM;
- не нужно ли закрыть отдельные разделы через
noindex, а не через robots.txt.
Если нужна более системная чистка дублей и технических хвостов, иногда проще собрать это в одном SEO-инструменте, чем держать набор разрозненных правок в теме и плагинах. Но даже в этом случае robots.txt стоит проверять вручную.
Как понять, что решение сработало
Признаки нормальной настройки обычно видны не сразу, но их можно отследить:
- в отчётах Search Console уменьшается количество обхода мусорных URL;
- в логах сервера поисковый бот реже ходит в служебные разделы;
- страницы с параметрами перестают накапливаться в индексе;
- важные URL продолжают обходиться и не теряют видимость;
- robots.txt остаётся коротким, читаемым и понятным для поддержки.
Если после внедрения вы видите падение обхода важных страниц, откатите последнее правило и проверьте, какой именно шаблон его заблокировал. В robots.txt лучше идти от минимального набора к точечным исключениям, чем наоборот.
/* Пример: проверка проблемного URL в логике robots.txt */
/* 1. Открыть URL в браузере */
/* 2. Проверить, есть ли параметр */
/* 3. Сравнить с правилами Disallow */
/* 4. Убедиться, что важные страницы не попали под маску */Если нужен следующий шаг после robots.txt, обычно это уже работа с canonical, noindex и настройкой архивов в WordPress. Именно в этой связке техническая индексация становится предсказуемой, а не случайной.