На живом WordPress почти всегда накапливаются страницы, которые не должны попадать в поиск: архивы по датам, служебные результаты поиска, страницы авторов на небольшом сайте, вложения медиафайлов, тестовые таксономии, пагинация слабоценных архивов. Проблема не в самом факте их существования, а в том, что поисковик тратит на них обход, а в индексе появляется мусор, который мешает основным страницам.
Ниже — рабочая схема, как найти такие URL, выбрать способ закрытия и проверить, что вы не сломали индексацию важных разделов.
Какие страницы действительно стоит закрывать
Не надо закрывать всё подряд. Для WordPress обычно речь идет о страницах, которые не несут самостоятельной ценности для поиска и дублируют уже опубликованный контент или навигацию.
- страницы внутреннего поиска вида
?s=...; - архивы по датам, если на сайте нет редакционной логики для их индексации;
- страницы вложений медиафайлов, когда они открываются как отдельные тонкие страницы;
- служебные страницы пагинации архивов, если они не нужны в поиске;
- страницы авторов на сайте с одним автором;
- тестовые таксономии, теги-однодневки и пустые рубрики;
- страницы с параметрами сортировки, фильтров и UTM, если они создают дубли.
Важно различать noindex и запрет обхода через robots.txt. Если страница уже известна поисковику, но вы хотите убрать ее из индекса, обычно нужен именно noindex, а не блокировка в robots. Если закрыть URL в robots до того, как поисковик увидит директиву noindex, он может продолжать держать адрес в индексе без содержимого страницы.
Диагностика: где искать лишние URL
Начните не с настроек плагина, а с проверки фактической картины. Иначе легко закрыть не то, что нужно, и оставить открытыми реальные дубли.
Что смотреть в первую очередь
- отчет «Страницы» в Google Search Console;
- поиск по сайту через
site:example.comс типовыми шаблонами URL; - логи сервера, если нужно понять, что чаще всего обходит бот;
- исходный код страниц: есть ли
meta robotsи какие канонические URL выставлены; - карта сайта: не попали ли туда служебные адреса.
Если у вас есть доступ к командной строке, быстро посмотреть, какие URL отдает WordPress, можно через WP-CLI. Это не заменяет аудит, но помогает поймать очевидные ошибки в шаблонах и таксономиях.
wp post list --post_type=page --fields=ID,post_title,post_status --format=tableДля медиа и вложений полезно отдельно проверить, не создаются ли у них собственные страницы. Часто это происходит автоматически, и именно они потом всплывают в индексе как тонкие документы.
Какой способ выбрать: плагин, код или robots.txt
У каждого варианта есть своя зона применения. Если задача локальная и понятная, код дает больше контроля. Если нужно быстро закрыть несколько типов страниц без правки темы, удобнее плагин. Robots.txt — не универсальная замена, а инструмент для ограничения обхода, когда это действительно уместно.
| Подход | Когда использовать | Плюс | Минус |
|---|---|---|---|
| Плагин SEO/чистки | Нужно закрыть архивы, теги, автора, медиа без кода | Быстро и безопасно для редактора | Меньше контроля над точечными исключениями |
| Код в теме или mu-plugin | Нужна точная логика по типам страниц | Прозрачное поведение и минимум лишнего | Требует проверки после обновлений |
robots.txt | Нужно сократить обход второстепенных URL | Просто ограничить ботов | Не решает задачу индексации сам по себе |
Если на сайте уже используется SEO-плагин, сначала проверьте его настройки. Часто нужные переключатели уже есть: закрытие архивов автора, дат, тегов, медиа-страниц. Если же плагин перегружен и вы хотите убрать лишние архивы, удобно делать это через код или через инструменты чистки сайта. Например, в Clearfy Pro есть набор настроек для отключения технических сущностей и дублей: Clearfy Pro.
Пошаговое решение через код
Если нужен предсказуемый результат, лучше добавить логику в mu-plugin или в дочернюю тему. Так вы не потеряете настройки при обновлении темы и сможете точечно управлять мета-роботами.
1. Закрываем служебные страницы от индексации
Пример ниже добавляет noindex, follow для страниц поиска, архивов дат, вложений и авторских архивов на сайте с одним автором. Логику можно расширить под конкретный проект.
<?php
add_filter('wp_robots', function ($robots) {
if (is_search() || is_attachment() || is_date() || is_author()) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
});Этот вариант работает на уровне стандартного фильтра WordPress и не привязан к конкретному SEO-плагину. Но если SEO-плагин уже выводит свои robots-мета, нужно убедиться, что он не перезаписывает вашу логику.
2. Убираем вложения с отдельной страницы
Если у медиафайлов есть отдельные страницы, часто лучше перенаправить их на сам файл или на родительскую запись. Для этого можно использовать редирект на уровне шаблона или через фильтр, если тема это поддерживает.
<?php
add_action('template_redirect', function () {
if (is_attachment()) {
$parent = wp_get_post_parent_id(get_queried_object_id());
if ($parent) {
wp_safe_redirect(get_permalink($parent), 301);
exit;
}
wp_safe_redirect(home_url('/'), 301);
exit;
}
});Такой редирект полезен, когда attachment-страницы уже успели попасть в индекс. Но если на медиа-страницы есть внутренние ссылки и они реально используются, сначала проверьте, не ломаете ли вы навигацию редакции.
3. Исключаем технические URL из sitemap
Если URL не должен индексироваться, он не должен попадать и в карту сайта. Это не всегда автоматически решается одним noindex. В SEO-плагине проверьте, что архивы, теги, медиа и служебные таксономии не включены в sitemap.
Если вы генерируете sitemap вручную или через код, исключайте такие сущности на этапе формирования списка, а не после публикации файла.
Что делать, если нужен быстрый вариант без кода
На небольших сайтах проще закрыть лишние архивы через настройки SEO-плагина или через плагин для чистки WordPress. Это особенно удобно, если у вас нет разработчика под рукой, а проблема типовая: теги, авторы, даты, вложения, пагинация архивов.
Но не путайте удобство с универсальностью. Плагин хорош, когда нужно быстро привести сайт в порядок. Код лучше, когда логика зависит от типа контента, языка, роли пользователя или структуры каталога.
Проверка результата после внедрения
После изменений не ограничивайтесь визуальной проверкой страницы в браузере. Нужно убедиться, что поисковик видит именно то, что вы задумали.
- Откройте проблемный URL и проверьте исходный код на наличие
meta name="robots". - Убедитесь, что в ответе нет случайного
noindexна важных страницах. - Проверьте, что URL не попал в sitemap.
- Посмотрите заголовки ответа, если используете редирект для вложений.
- В Google Search Console отправьте URL на повторную проверку, если он уже был в индексе.
Для быстрой проверки через консоль можно посмотреть заголовки ответа:
curl -I https://example.com/sample-page/Если вы закрывали страницу через noindex, в исходнике должен быть соответствующий robots-метатег. Если делали редирект, в ответе должен быть статус 301 и корректный Location.
Частые ошибки и как их исправить
Закрыли в robots.txt, но страница осталась в индексе
Это типичная ошибка. Если поисковик уже знает URL, блокировка обхода не всегда убирает его из индекса. Сначала дайте странице увидеть noindex или настройте редирект, а уже потом ограничивайте обход, если это нужно.
Поставили noindex на важный архив
Такое часто случается, когда под одну настройку попадают и служебные, и полезные архивы. Например, на новостном сайте архивы рубрик могут быть важными посадочными страницами, а на корпоративном блоге — нет. Решение: разделить логику по типам контента, а не закрывать все архивы одной галочкой.
Оставили URL в sitemap
Если страница закрыта от индексации, но продолжает висеть в карте сайта, вы отправляете поисковику противоречивые сигналы. Уберите ее из sitemap и перепроверьте генерацию после обновлений плагина.
Сделали редирект без проверки внутренних ссылок
Редирект вложений или авторских архивов может быть правильным, но если на них ссылается тема, хлебные крошки или блоки похожих материалов, вы получите лишние переходы и потерю удобства. Сначала проверьте, где эти URL используются.
Практические советы по безопасности и производительности
Чем меньше технического мусора в индексе и на обходе, тем проще поддерживать сайт. Но не стоит делать это ценой хаотичных правок в теме.
- выносите код в
mu-plugins, если он должен жить независимо от темы; - не редактируйте родительскую тему напрямую;
- проверяйте изменения на staging, если сайт уже получает органический трафик;
- не закрывайте массово URL, не посмотрев на Search Console и карту сайта;
- следите, чтобы SEO-плагин и кастомный код не дублировали друг друга.
Если задача шире, чем одна-две настройки, иногда проще собрать ее в одном инструменте. Для сайтов, где нужно одновременно убрать дубли, почистить технические сущности и не лезть в код, Clearfy Pro может быть удобной отправной точкой: https://wpshop.ru/plugins/clearfy.
Главный критерий успеха здесь простой: в индексе остаются только те URL, которые реально должны приводить пользователей на контент. Все остальное либо получает noindex, либо уходит в редирект, либо не попадает в sitemap и не мешает обходу.