На небольших и средних сайтах WordPress поисковый мусор чаще всего появляется не из-за контента, а из-за служебных страниц: архивов авторов, дат, тегов, вложений, страниц пагинации и результатов поиска. Если их не контролировать, в индексе быстро оказываются дубли, а полезные страницы получают меньше внимания поисковика.
Ниже разберём, как понять, что именно индексируется лишнее, чем закрывать такие страницы — настройками темы, плагином или кодом — и как проверить, что изменения реально сработали.
Когда проблема уже есть: как это увидеть в Search Console и на сайте
Первый признак — в отчётах Google Search Console растёт число страниц без трафика, а в поиске всплывают архивы вида /author/username/, /tag/..., /date/... или страницы вложений с тонким содержимым. Второй признак — при запросе site:example.com видно слишком много служебных URL, которые не должны конкурировать с основными материалами.
Проверьте несколько вещей вручную:
- открываются ли архивы авторов и дат без полезного контента;
- есть ли у тегов и категорий нормальные описания или это пустые страницы;
- не создаёт ли тема отдельные страницы вложений для изображений;
- не индексируются ли внутренние результаты поиска;
- не дублируются ли записи через пагинацию и архивы.
Если сайт небольшой и архивы не несут ценности, их обычно проще закрыть от индексации, чем пытаться «докормить» контентом.
Что именно закрывать: не все архивы одинаково полезны
Ошибка многих сайтов — закрыть всё подряд. Это тоже плохо: можно случайно убрать из поиска полезные рубрики или страницы авторов, если они реально работают как витрина контента. Поэтому сначала разделите типы страниц.
| Тип страницы | Обычно индексировать? | Комментарий |
|---|---|---|
| Рубрики | Да, если есть смысловая структура | Полезны для навигации и SEO, если заполнены и не пустые |
| Теги | Часто нет | Если теги создаются хаотично, они дают дубли и слабые страницы |
| Архивы авторов | Чаще нет | Особенно если автор один или у каждого автора мало материалов |
| Архивы по датам | Почти всегда нет | Обычно не несут самостоятельной ценности |
| Страницы вложений | Почти всегда нет | Лучше редиректить на файл или запись-родитель |
| Внутренний поиск | Нет | Это технические страницы, не для индекса |
Пошаговое решение через SEO-плагин
Если на сайте уже стоит SEO-плагин, самый безопасный путь — использовать его настройки. Это проще поддерживать, чем править шаблоны руками, и меньше риск сломать мета-теги на отдельных типах архивов.
1. Отключите индексацию для архивов, которые не нужны
В большинстве SEO-плагинов можно задать noindex для архивов авторов, дат, тегов или конкретных таксономий. Логика простая: страница остаётся доступной пользователю, но поисковик получает сигнал не включать её в индекс.
Если у вас, например, теги создаются автоматически и не модерируются, их лучше закрыть. Если рубрики — это основная структура сайта, их обычно оставляют открытыми.
2. Уберите страницы вложений из индекса
Страницы attachment часто создаются автоматически и почти всегда бесполезны для поиска. Правильный вариант — либо редирект на родительскую запись, либо закрытие от индексации, если редирект не настроен.
3. Проверьте robots.txt только как вспомогательный слой
Запрет в robots.txt не заменяет noindex. Если страница уже в индексе, одного запрета на обход может быть недостаточно. Robots.txt полезен для экономии краулингового бюджета, но не как единственный способ убрать URL из поиска.
Если нужен инструмент для чистки дублей и технических SEO-настроек, уместно посмотреть на Clearfy Pro: у него как раз есть набор настроек для отключения лишних архивов, дублей и служебных элементов. Но даже с плагином всё равно стоит понимать, что именно вы закрываете.
Решение через код: когда нужен точечный контроль
Код полезен, если вы не хотите зависеть от интерфейса плагина или если тема/плагин не дают нужной гибкости. Ниже два практических сценария: добавить noindex в архивы и убрать страницу вложения из выдачи.
Добавить noindex для архивов авторов, дат и тегов
Этот вариант подходит, если вы хотите управлять индексированием на уровне темы или небольшого mu-plugin. Код не выдумывает ничего лишнего: он только меняет robots-мета для нужных типов страниц.
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_author() || is_date() || is_tag() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );Что здесь важно: follow оставляет возможность перехода по ссылкам на странице, а noindex просит поисковик не включать саму страницу в индекс. Это не магия, а рекомендация для робота, поэтому проверять результат всё равно нужно.
Редиректить страницы вложений на родительскую запись
Если у изображения есть родительская запись, можно отправлять пользователя и робота туда. Это уменьшает число пустых страниц и убирает лишние URL из индекса.
<?php
add_action( 'template_redirect', function() {
if ( is_attachment() ) {
$parent_id = wp_get_post_parent_id( get_queried_object_id() );
if ( $parent_id ) {
wp_redirect( get_permalink( $parent_id ), 301 );
exit;
}
}
} );Если родителя нет, лучше не делать случайный редирект на главную. В таком случае либо оставляйте страницу как есть и закрывайте её от индексации, либо настраивайте отдельную логику под медиа-раздел.
Как проверить, что решение сработало
После изменений не ограничивайтесь визуальной проверкой. Нужно убедиться, что поисковик видит именно тот сигнал, который вы задали.
- Откройте архив автора, тега или даты и проверьте исходный код страницы: должен быть
noindexв robots-мета, если вы его добавляли. - Проверьте HTTP-ответ для вложения: если настроен редирект, должен возвращаться
301на целевую страницу. - В Google Search Console используйте проверку URL и посмотрите, какой статус видит Googlebot.
- Через несколько дней сравните отчёты по индексированию: служебные URL должны постепенно уходить из индекса, а не расти.
Для быстрой локальной проверки удобно смотреть заголовки и редиректы через curl:
curl -I https://example.com/author/admin/
curl -I https://example.com/wp-content/uploads/2024/10/image.jpgЕсли на архиве авторов вы видите 200 OK и в HTML нет noindex, значит настройка не применена. Если вложение отдаёт 200 OK вместо 301, редирект не работает или конфликтует с темой/плагином.
Частые ошибки и как их исправить
Закрыли в robots.txt, но URL остался в индексе
Это типичная ситуация. Robots.txt не удаляет уже проиндексированные страницы. Чтобы убрать их, нужен noindex или редирект, а затем повторная переобходка.
Поставили noindex на всё подряд
Иногда после установки SEO-плагина закрывают и рубрики, и теги, и авторов, и пагинацию, а потом удивляются падению видимости. Проблема не в самом noindex, а в том, что вы убрали из поиска полезные посадочные страницы. Сначала оцените, какие архивы реально нужны пользователю.
Редирект вложений ведёт на главную
Это плохой запасной вариант: пользователь теряет контекст, а поисковик получает неочевидную связку. Лучше редиректить на родительскую запись или закрывать вложение от индексации, если родителя нет.
Тема переопределяет robots-мета
Некоторые темы и плагины выводят свои мета-теги, конфликтуя с SEO-плагином. Если после настройки в исходнике страницы нет нужного значения, проверьте, не дублируется ли вывод в header.php или через сторонний плагин.
Практические советы по безопасности и производительности
Чем меньше служебных страниц индексируется и обходитcя роботами, тем меньше лишней нагрузки на сайт. Это не даст мгновенного прироста скорости, но уменьшит технический шум и упростит поддержку.
- Не правьте код в родительской теме: используйте дочернюю тему или mu-plugin.
- После изменений очистите кэш страницы и кэш CDN, если он есть.
- Если используете плагин для SEO, не дублируйте одну и ту же логику в functions.php и в настройках плагина.
- Не закрывайте полезные архивы только потому, что они «похожи на дубли» — сначала посмотрите на их трафик и структуру.
Если на сайте много технических дублей и служебных страниц, иногда проще сначала привести в порядок базовую SEO-гигиену через плагин, а уже потом точечно дописывать код. Так меньше шансов сломать индексирование полезных разделов и проще объяснить логику другим разработчикам или редакторам.