На небольшом сайте технические страницы часто не мешают. На живом проекте они быстро начинают засорять индекс: страницы поиска, вложения медиафайлов, служебные архивы, страницы пагинации, параметры фильтров, внутренние результаты поиска. Проблема не в самом факте их существования, а в том, что поисковик тратит на них обход, а в отчётах появляются дубли и мусорные URL.
Задача здесь не «закрыть всё подряд», а аккуратно оставить в индексе только то, что реально нужно. Ниже — рабочий сценарий: как найти такие страницы, чем их закрывать и как проверить, что вы не сломали важные разделы.
Какие страницы обычно нужно закрывать от индексации
Сначала полезно отделить технические URL от полезных. В WordPress к первым обычно относятся:
- страницы внутреннего поиска вида
?s=запрос; - архивы вложений, если у медиафайлов есть отдельные страницы;
- страницы с параметрами сортировки и фильтров, если они создают дубли;
- служебные архивы автора и даты, если они не несут самостоятельной ценности;
- страницы пагинации в разделах, где они не должны ранжироваться отдельно;
- черновые таксономии и пустые архивы.
Не стоит автоматически закрывать категорию, тег или страницу пагинации только потому, что она «похожа на дубль». Если на ней есть уникальный контент и она приводит трафик, решение должно быть точечным.
Диагностика: как понять, что именно мешает
Перед правками откройте отчёты поисковой системы и посмотрите, какие URL уже попали в индекс. В Search Console это обычно видно в отчётах по страницам и исключённым URL. Дополнительно проверьте сайт через поиск по домену и оператор site:, чтобы увидеть, какие служебные адреса всплывают чаще всего.
Полезно пройтись и по самому сайту:
- выполнить поиск по шаблону URL в логах или в отчётах аналитики;
- проверить, есть ли у вложений отдельные страницы;
- посмотреть, не генерирует ли тема или плагин параметры в URL;
- сравнить количество страниц в индексе с реальным количеством полезных материалов.
Если проблема массовая, сначала решайте источник дублей, а не только ставьте noindex. Иначе новые URL будут появляться снова.
Что выбрать: robots.txt, noindex или каноникал
Для разных типов страниц подходят разные инструменты. Коротко это выглядит так:
| Подход | Когда использовать | Ограничение |
|---|---|---|
noindex | Когда страницу можно открыть, но не нужно показывать в поиске | Поисковику всё равно нужно зайти на страницу, чтобы увидеть мета-тег |
robots.txt | Когда нужно ограничить обход, а не только индекс | Не гарантирует удаление уже проиндексированного URL |
rel=canonical | Когда есть основной URL и его дубли с параметрами | Не подходит для полностью служебных страниц без аналога |
На практике часто используют комбинацию: закрывают от индекса через noindex, а для дублей ещё и настраивают канонический URL на основную страницу. Для совсем бесполезных служебных адресов иногда добавляют запрет обхода в robots.txt, но только если понимают последствия.
Пошаговое решение без плагина
1. Закрыть результаты внутреннего поиска
Если у вас в индексе появляются страницы поиска, их обычно имеет смысл закрыть. В WordPress это можно сделать через хук wp_robots:
add_filter( 'wp_robots', function( $robots ) {
if ( is_search() ) {
$robots['noindex'] = true;
$robots['nofollow'] = true;
}
return $robots;
} );Такой вариант не ломает сам поиск на сайте, но подсказывает поисковику не индексировать результаты.
2. Отключить индексацию страниц вложений
Если у медиафайлов есть отдельные страницы, они часто выглядят пустыми или почти пустыми. В этом случае лучше либо редиректить их на сам файл или родительскую запись, либо закрывать от индексации. Если вы не хотите трогать редиректы, можно поставить noindex для attachment-страниц:
add_filter( 'wp_robots', function( $robots ) {
if ( is_attachment() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );Если при этом у вас уже есть плагин, который делает редирект вложений, не дублируйте логику в двух местах. Иначе получите конфликт поведения.
3. Закрыть архивы автора или даты, если они не нужны
Для некоторых сайтов архивы автора и даты полезны. Для других — это почти чистые дубли. Если вы решили их закрыть, делайте это осознанно и не удаляйте из шаблона ссылки на них без проверки. Для noindex можно использовать тот же фильтр:
add_filter( 'wp_robots', function( $robots ) {
if ( is_author() || is_date() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );Если архивы уже в индексе, одной правки может быть мало: поисковику нужно время на переобход и переоценку страниц.
4. Добавить каноникал для дублей с параметрами
Если у вас есть URL с параметрами сортировки или фильтрации, лучше указывать канонический адрес на основную версию страницы. Для этого в WordPress можно использовать фильтр wp_get_canonical_url или логику темы, если она уже выводит canonical. Пример для простого случая:
add_filter( 'wp_get_canonical_url', function( $canonical, $post ) {
if ( is_singular() && $canonical ) {
return remove_query_arg( array( 'utm_source', 'utm_medium', 'utm_campaign' ), $canonical );
}
return $canonical;
}, 10, 2 );Этот пример убирает только маркетинговые параметры. Не используйте его для всех query string без разбора: некоторые параметры могут быть частью реальной функциональности.
Если нужен плагин: когда это оправдано
Плагин имеет смысл, если вы не хотите поддерживать код в теме или в mu-plugin, либо если нужно быстро управлять мета-тегами без правки шаблонов. Для технической чистки и SEO-правил удобно использовать решения, где есть управление noindex, canonical и служебными архивами. Например, Clearfy Pro уместен именно как инструмент для типовых SEO и технических настроек, если нужен интерфейс вместо кода: https://wpshop.ru/plugins/clearfy.
Но плагин не отменяет диагностику. Если вы не понимаете, какие URL создают дубли, можно просто скрыть симптом и оставить источник проблемы.
Как проверить, что решение сработало
После внедрения не ограничивайтесь просмотром исходника страницы. Проверьте несколько уровней:
- в HTML страницы должен появиться мета-тег robots с нужным значением;
- в Search Console URL должен перейти в статус, соответствующий закрытию или исключению;
- страница должна оставаться доступной для пользователя, если вы не делали редирект;
- канонический URL должен указывать на основную версию, если вы его настраивали;
- через несколько обходов поисковик должен перестать активно показывать технический URL в отчётах.
Для быстрой локальной проверки откройте исходный код страницы и найдите noindex или canonical. Если вы добавляли код в тему, убедитесь, что он действительно загружается на нужных шаблонах, а не только в админке.
Частые ошибки и как их исправить
Закрыли страницу в robots.txt, но она всё ещё в индексе
Это нормальная ситуация. Запрет обхода не равен удалению из индекса. Если URL уже известен поисковику, чаще нужен noindex или редирект, а не только Disallow.
Поставили noindex на полезную страницу
Такое часто случается с пагинацией, категориями или страницами фильтров. Перед закрытием проверьте, есть ли у URL входящий трафик, внутренние ссылки и уникальный контент. Если страница полезна, закрывать её не стоит.
Добавили код в functions.php и забыли про обновления темы
Если правка живёт в родительской теме, она может потеряться при обновлении. Для постоянной логики лучше использовать дочернюю тему или отдельный mu-plugin.
Смешали несколько SEO-плагинов
Когда один плагин ставит canonical, а другой меняет robots, результат бывает непредсказуемым. Оставьте один источник правды для мета-тегов и проверьте итоговый HTML.
Практические советы по безопасности и производительности
Если вы добавляете код вручную, делайте это через staging-копию и храните правки в отдельном файле. Для небольших фрагментов удобно использовать mu-plugin: так код не зависит от темы и не исчезает после обновления.
Не закрывайте в robots.txt всё подряд ради «чистоты». Иногда это мешает поисковику увидеть canonical или обновлённый noindex. Сначала исправляйте источник дублей, потом ограничивайте обход там, где это действительно нужно.
Если на сайте много технических URL, полезно периодически пересматривать правила. После смены темы, плагина фильтров или структуры архивов старые настройки часто становятся неактуальными и начинают вредить индексации вместо помощи.