Если в индексе появляются служебные URL, дубли архивов, страницы поиска или параметры фильтров, первым делом стоит проверить не только мета-теги, но и robots.txt. В WordPress это частая точка ошибок: файл либо слишком агрессивно закрывает сайт, либо вообще не помогает, потому что в нём нет нужных директив.
Ниже разберём, какие технические страницы действительно имеет смысл закрывать, как собрать рабочий robots.txt без лишнего риска и как проверить, что поисковик видит именно то, что вы задумали.
Какие страницы WordPress обычно стоит закрыть от индексации
Не все служебные URL нужно запрещать в robots.txt. Этот файл не удаляет страницы из индекса, а только ограничивает обход. Поэтому его задача — не «спрятать всё подряд», а убрать мусорные разделы из краулинга и не тратить бюджет обхода на бесполезные адреса.
Типовые кандидаты на закрытие
- страницы поиска вида
?s=; - архивы авторов на сайтах, где один автор и они не нужны для SEO;
- служебные URL плагинов и тем, если они доступны по публичным адресам;
- параметры сортировки и фильтрации, если они создают много дублей;
- feed-адреса, если вы не используете их как отдельный канал;
- страницы пагинации в тех разделах, где они не несут ценности для поиска.
При этом не стоит закрывать в robots.txt CSS, JS и изображения, если они нужны для рендеринга страницы. Современные поисковые системы должны видеть страницу так же, как пользователь.
Диагностика проблемы: что именно мешает индексации
Перед правкой файла полезно понять, что вы исправляете. Иногда проблема не в robots.txt, а в неправильных canonical, мета-тегах noindex или в том, что шаблон генерирует лишние URL.
Проверьте три вещи
- Откройте
/robots.txtв браузере и убедитесь, что файл вообще доступен. - Посмотрите, нет ли в нём директивы
Disallow: /или слишком широких запретов вродеDisallow: /wp-. - Проверьте в Google Search Console, какие именно URL попали в индекс и как они были обнаружены.
Если в индексе уже есть технические страницы, одного robots.txt может быть недостаточно. Для удаления из индекса часто нужен noindex на самой странице или корректный canonical, а не только запрет обхода.
Рабочая схема: что писать в robots.txt для WordPress
У WordPress нет единственного универсального файла для всех сайтов. Но есть безопасная базовая схема, от которой удобно отталкиваться. Её можно адаптировать под конкретную структуру проекта.
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /?s=
Disallow: /search/
Disallow: /author/
Disallow: /feed/
Disallow: /*?replytocom=
Disallow: /*?orderby=
Disallow: /*?filter=
Sitemap: https://example.com/sitemap_index.xmlЗдесь есть важный нюанс: директивы с параметрами вроде /*?orderby= работают не одинаково у всех роботов. Для Google это обычно понятный паттерн, но не стоит рассчитывать, что он решит проблему дублей сам по себе. Если фильтры создают отдельные посадочные страницы, лучше управлять ими на уровне шаблона и canonical.
Когда лучше не закрывать раздел целиком
Архивы категорий, теги и пагинацию нельзя закрывать автоматически только потому, что они «похожи на дубли». Если раздел приносит трафик и имеет уникальные сниппеты, его лучше оставить доступным, а проблему решать через контент, canonical и внутреннюю перелинковку.
| Подход | Когда подходит | Минус |
|---|---|---|
| robots.txt | Служебные URL, которые не должны обходиться | Не удаляет уже проиндексированные страницы |
| noindex | Страницы, которые можно открыть, но не показывать в поиске | Нужно, чтобы робот мог зайти на страницу |
| canonical | Дубли с разными параметрами | Не всегда срабатывает, если структура хаотичная |
Пошаговая настройка через код в WordPress
Если файл генерируется автоматически или вы хотите контролировать его из темы/плагина, можно использовать фильтр robots_txt. Это штатный механизм WordPress, без выдуманных API.
<?php
add_filter( 'robots_txt', function( $output, $public ) {
$lines = array(
'User-agent: *',
'Disallow: /wp-admin/',
'Allow: /wp-admin/admin-ajax.php',
'Disallow: /?s=',
'Disallow: /search/',
'Disallow: /author/',
'Disallow: /feed/',
'Disallow: /*?replytocom=',
'Sitemap: ' . home_url( '/sitemap_index.xml' ),
);
return implode( "\n", $lines ) . "\n";
}, 10, 2 );Такой вариант удобен, если вы хотите хранить правила в репозитории вместе с кодом сайта. Но если у вас уже есть SEO-плагин, проверьте, не перезаписывает ли он robots.txt своими настройками. Иначе вы внесёте изменения в код, а на фронте увидите старую версию файла.
Если нужен только один дополнительный запрет
Иногда не нужно переписывать весь файл. Достаточно добавить одну строку, например для поиска:
<?php
add_filter( 'robots_txt', function( $output ) {
$output .= "Disallow: /?s=\n";
return $output;
} );Но этот способ стоит использовать аккуратно. Если вы просто дописываете строку в конец, убедитесь, что в файле не появятся дубли директив и что базовые правила не конфликтуют между собой.
Проверка результата после внедрения
После правки важно не ограничиться открытием файла в браузере. Проверка должна быть практической: вы смотрите и сам robots.txt, и реакцию поисковика.
- Откройте
https://ваш-домен/robots.txtи проверьте, что файл отдаётся без редиректов и ошибок. - Убедитесь, что sitemap указан корректно и ведёт на реальный файл.
- Проверьте в Search Console, не заблокированы ли важные страницы случайно.
- Посмотрите, исчез ли обход мусорных URL в логах сервера или в отчётах краулинга.
Если вы закрывали параметры, проверьте несколько реальных адресов с этими параметрами. Например, URL поиска, сортировки или пагинации. Важно убедиться, что правило действительно совпадает с форматом URL, который генерирует ваш сайт.
Частые ошибки и как их исправить
Слишком широкая блокировка
Ошибка выглядит так: в robots.txt попадает что-то вроде Disallow: /wp- или даже Disallow: /. В результате поисковик перестаёт обходить не только мусор, но и нужные страницы. Исправление простое: оставьте только точечные запреты и проверьте, что публичные разделы доступны.
Пытаются убрать индекс через robots.txt
Если страница уже в индексе, запрет обхода не гарантирует её удаление. Для удаления используйте noindex на самой странице или корректный canonical. robots.txt здесь вспомогательный инструмент, а не основной.
Файл редактируют не там, где он реально формируется
На части сайтов robots.txt создаёт SEO-плагин или серверная конфигурация. Тогда правка физического файла в корне может не дать эффекта. Проверьте, кто именно отдаёт ответ: WordPress, плагин или веб-сервер.
Закрывают CSS и JS
Это старая ошибка, которая до сих пор встречается в проектах после «жёсткой» оптимизации. Если закрыть ресурсы стилей и скриптов, робот может хуже отрендерить страницу и неверно оценить её содержимое. Не трогайте эти файлы без явной причины.
Практические советы по безопасности и производительности
robots.txt не защищает от доступа к файлам и не является механизмом безопасности. Если у вас есть приватные данные, закрывать их нужно не через robots, а через права доступа, авторизацию и серверные правила.
С точки зрения производительности полезно держать файл коротким и понятным. Чем меньше в нём хаотичных правил, тем проще сопровождать сайт после обновления темы, смены плагина или редизайна структуры URL. Если проект большой, имеет смысл разнести ответственность: SEO-правила — в одном месте, технические ограничения — в другом, а не собирать всё вручную в одном файле без контроля версий.
Если нужно регулярно чистить сайт от дублей, служебных архивов и лишних мета-данных, можно посмотреть в сторону инструментов вроде Clearfy Pro: он помогает навести порядок в технических настройках WordPress и убрать часть типовых SEO-дублей. Но даже с таким плагином всё равно стоит понимать, какие правила вы применяете и зачем.
В итоге хороший robots.txt для WordPress — это не длинный список запретов, а аккуратный набор правил, который не мешает индексации полезных страниц и не тратит краулинговый бюджет на мусорные адреса.