В WordPress чаще всего индексируются не те страницы, которые реально нужны пользователю: внутренний поиск, архивы по датам, авторские архивы, страницы вложений и пустые результаты поиска. На небольшом сайте это выглядит как мусор в отчётах, а на контентном проекте — как размывание краулингового бюджета и дубли в индексе. Закрывать такие URL лучше точечно: не через массовое удаление из sitemap и не через запрет всего раздела в robots.txt, а через корректный noindex там, где это действительно уместно.
Какие страницы обычно стоит закрывать
Сначала имеет смысл разделить URL на две группы: те, которые должны быть доступны пользователю, но не нужны в поиске, и те, которые вообще не должны появляться в выдаче. Для WordPress это разные задачи. Например, страница поиска /?s=... должна работать для посетителя, но почти никогда не приносит ценности поисковику. Архивы по датам и автору тоже часто создают дубли, особенно если на сайте есть рубрики и теги с похожими материалами.
Типичные кандидаты на noindex
- страницы внутреннего поиска;
- архивы по датам, если они не используются как отдельный контентный раздел;
- архивы авторов на сайтах с одним автором;
- страницы вложений медиафайлов;
- пустые или малоценные архивы тегов.
При этом не стоит закрывать всё подряд. Если архив рубрики — это полноценная посадочная страница с текстом, подборкой и внутренней перелинковкой, её лучше оставить открытой. Ошибка здесь обычно одна: вместо точечной настройки ставят глобальный запрет, а потом удивляются падению видимости.
Диагностика проблемы: где именно появляются лишние URL
Перед правками проверьте, что именно уже попало в индекс и откуда поисковик берёт эти адреса. Самый простой путь — посмотреть отчёты в Google Search Console и сделать выборку по шаблонам URL. Если в индексе есть страницы вида /page/2/, /?s=, /author/ или вложения /sample-image/, это хороший сигнал, что настройка индексации не закрыта или закрыта не там.
Полезно также проверить исходный код страницы. На проблемном URL должен быть либо тег noindex, либо корректный канонический адрес, если страница является дублем и должна передавать вес основной версии. Если на странице поиска стоит обычный индексируемый шаблон, поисковик будет продолжать её обходить.
Что проверить вручную
- есть ли на странице мета-тег robots с
noindex; - не закрыт ли URL только в
robots.txtбезnoindex; - не попадает ли страница в XML-карту сайта;
- не создаёт ли тема отдельные архивы для вложений и авторов;
- не дублируются ли заголовки и description у архивных страниц.
Пошаговое решение через код темы или мини-плагин
Если нужен контроль без тяжёлых SEO-плагинов, настройку можно сделать кодом. Для этого удобно использовать фильтр wp_robots — он позволяет добавить noindex на нужных типах страниц, не ломая остальную разметку. Такой подход лучше, чем вставлять мета-теги вручную в шаблон: логика остаётся в одном месте и проще поддерживается.
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_search() ) {
$robots['noindex'] = true;
$robots['nofollow'] = true;
}
if ( is_author() && count_users()['total_users'] <= 1 ) {
$robots['noindex'] = true;
}
if ( is_attachment() ) {
$robots['noindex'] = true;
}
return $robots;
} );
Этот пример показывает базовую логику, но его лучше адаптировать под сайт. Например, условие с count_users() не стоит использовать на каждом запросе на крупном проекте без необходимости: это лишняя нагрузка. Если у вас один автор, проще зафиксировать правило через отдельную проверку или настройку темы.
Для архивов по датам можно добавить отдельное правило:
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_date() ) {
$robots['noindex'] = true;
}
return $robots;
} );
Если вы используете SEO-плагин, проверьте, не конфликтует ли он с кодом темы. Два источника, которые одновременно пишут robots meta, часто дают непредсказуемый результат. В таком случае оставьте один способ управления индексацией.
Когда лучше использовать плагин, а когда код
Если задача ограничивается несколькими типами страниц, код обычно надёжнее. Если же нужно управлять десятками шаблонов, пользовательскими типами записей и таксономиями, удобнее SEO-плагин с интерфейсом. Но даже тогда важно понимать, что именно он делает: закрывает страницу от индексации, ставит canonical или исключает её из карты сайта — это разные механизмы.
| Подход | Плюсы | Минусы |
|---|---|---|
Код через wp_robots |
Точно, без лишних зависимостей | Нужна аккуратность и тестирование |
| SEO-плагин | Удобно для редактора и массовых правил | Может конфликтовать с темой и другими плагинами |
| robots.txt | Просто закрыть обход | Не заменяет noindex и не решает уже проиндексированные URL |
Если нужен более широкий контроль над дублями и техническими страницами, имеет смысл посмотреть в сторону инструментов вроде Clearfy Pro: там есть готовые настройки для чистки сайта и отключения лишних сущностей. Но даже в этом случае логику лучше сверять вручную, а не полагаться только на чекбоксы.
Проверка результата после внедрения
После правок не ограничивайтесь просмотром исходника. Сначала откройте проблемный URL в браузере и проверьте, что в <head> появился корректный robots meta. Затем используйте инструмент проверки URL в Google Search Console: он покажет, видит ли робот страницу как noindex и не мешает ли этому canonical или редирект.
Если страница уже была в индексе, удаление не произойдёт мгновенно. Обычно нужно дождаться повторного обхода. Чтобы ускорить процесс, убедитесь, что URL не попадает в sitemap и не связан внутренними ссылками из меню, хлебных крошек или блока похожих записей.
Мини-чек-лист проверки
- в исходнике есть
noindexна нужных шаблонах; - страница не добавлена в XML sitemap;
- canonical указывает на правильный адрес или отсутствует, если это отдельная страница поиска;
- в Search Console статус URL меняется после повторной проверки;
- внутренние ссылки не продолжают массово вести на закрытый раздел.
Частые ошибки и как их исправить
Ошибка 1: закрывают URL только в robots.txt. Это не убирает уже проиндексированные страницы из выдачи. Если адрес уже в индексе, нужен noindex или удаление через инструменты поисковика, а не только запрет обхода.
Ошибка 2: ставят noindex на всё подряд. Так легко потерять полезные архивы и посадочные страницы. Сначала оцените, есть ли у шаблона ценность для поиска и внутренней перелинковки.
Ошибка 3: конфликтуют плагин и тема. Один компонент пишет noindex, другой переопределяет canonical, третий добавляет страницу в sitemap. В итоге поисковик получает противоречивые сигналы. Решение простое: оставьте один источник управления индексацией.
Ошибка 4: забывают про страницы вложений. На многих сайтах они создаются автоматически и индексируются как отдельные URL. Если медиа-страницы не нужны как самостоятельные посадочные, их лучше закрыть или перенаправить на файл/родительскую запись.
Практические советы по безопасности и производительности
Настройка индексации сама по себе не ускоряет сайт, но помогает убрать технический шум. Это особенно заметно на проектах с большим количеством архивов и поисковых запросов. Меньше мусора в индексе — меньше лишних обходов и меньше шансов, что поисковик будет тратить ресурсы на пустые страницы.
Если вы вносите код вручную, не правьте его напрямую в родительской теме. Используйте дочернюю тему или небольшой mu-plugin. Так настройка не слетит после обновления. И обязательно держите резервную копию перед изменениями: ошибка в условии может случайно закрыть от индексации весь сайт.
Для сайтов с редакционной нагрузкой полезно периодически пересматривать список закрытых страниц. Иногда архивы, которые были техническими на старте, позже становятся полезными. В таком случае лучше вернуть им индексируемость и добавить нормальный контент, чем навсегда держать их в noindex.