Служебные страницы в WordPress часто попадают в индекс не потому, что сайт «плохой», а потому что их никто отдельно не настраивал. Это архивы авторов, страницы поиска, вложения медиафайлов, служебные результаты фильтров, иногда даже страницы пагинации с тонким контентом. В итоге поисковик тратит краулинговый бюджет на мусор, а в отчётах Search Console появляются дубли и малополезные URL.
Ниже — практический сценарий: что именно закрывать, чем это делать и как не сломать индексацию нормальных страниц.
Какие страницы действительно стоит закрывать
Не нужно запрещать индексацию «всего подряд». В WordPress есть несколько типов URL, которые обычно не несут самостоятельной ценности для поиска:
- страницы внутреннего поиска вида
?s=; - архивы автора на сайтах с одним автором;
- вложения медиафайлов, если они открываются как отдельные страницы без полезного текста;
- служебные страницы пагинации, если они дублируют основной список и не нужны в выдаче;
- страницы с параметрами сортировки и фильтрации, если они создают много почти одинаковых URL.
При этом не стоит закрывать категории, теги или архивы, если они реально приводят трафик и содержат уникальные описания. Для таких страниц решение нужно принимать отдельно, а не по шаблону.
Диагностика проблемы: где именно появляется мусор в индексе
Сначала посмотрите, какие URL уже попали в поиск. Самый простой способ — отчёт «Страницы» в Google Search Console и поиск по шаблонам URL. Если видите много адресов с ?s=, /author/, /attachment/ или параметрами фильтра, это уже сигнал.
Полезно проверить и сам сайт:
- откройте несколько служебных URL в браузере и посмотрите, есть ли у них осмысленный контент;
- проверьте исходный код страницы на наличие
meta name="robots"; - посмотрите, не отдаются ли такие страницы с canonical на самих себя;
- сравните, не создаёт ли тема или плагин отдельные архивы для таксономий, которые дублируют друг друга.
Если страница доступна по прямой ссылке и не закрыта от индексации, поисковик может продолжать её обходить даже тогда, когда она вам не нужна.
Как запретить индексацию: сравнение подходов
| Способ | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| meta robots noindex | Для отдельных шаблонов и страниц | Гибко, не ломает доступ по ссылке | Нужно правильно повесить на нужный шаблон |
| robots.txt | Для массового ограничения обхода | Быстро и просто | Не гарантирует удаление из индекса, если URL уже известен |
| Плагин SEO | Если нужно управлять без кода | Удобно для редакторов | Лишняя зависимость от интерфейса и настроек |
На практике лучше сочетать meta robots для страниц, которые должны оставаться доступными, но не индексироваться, и robots.txt — только там, где действительно нужно ограничить обход.
Пошаговое решение через код
Если задача точечная, удобнее добавить правило в functions.php дочерней темы или в небольшой mu-plugin. Так вы не зависите от интерфейса SEO-плагина и можете контролировать логику по шаблонам.
1. Закрываем поиск, архив автора и вложения
<?php
add_action('wp_head', function () {
if (is_search() || is_author() || is_attachment()) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
});Этот вариант простой, но у него есть ограничение: он работает только на фронтенде и только если тема вызывает wp_head(). Для обычных тем этого достаточно.
2. Более надёжно через фильтр robots meta
Если у вас установлен SEO-плагин, он может сам формировать robots meta. Тогда лучше использовать фильтр, а не печатать тег вручную. В WordPress ядро не даёт универсального фильтра для всех случаев, поэтому здесь важно ориентироваться на конкретный SEO-плагин. Если такого фильтра нет, оставайтесь на варианте выше.
Для чистого WordPress можно закрыть индексацию через заголовок X-Robots-Tag на уровне сервера, но это уже зависит от конфигурации Nginx или Apache и не всегда удобно в типовом хостинге.
3. Закрываем вложения и редиректим их на исходный файл
Страницы вложений часто бесполезны для поиска. Если они не нужны как отдельные посадочные, лучше редиректить их на сам файл или на родительскую запись.
<?php
add_action('template_redirect', function () {
if (is_attachment()) {
$attachment_id = get_queried_object_id();
$parent_id = wp_get_post_parent_id($attachment_id);
if ($parent_id) {
wp_safe_redirect(get_permalink($parent_id), 301);
exit;
}
$file = wp_get_attachment_url($attachment_id);
if ($file) {
wp_safe_redirect($file, 301);
exit;
}
}
});Такой подход полезен, если у вас накопились страницы вложений из старых загрузок изображений. Но если вложение уже используется как отдельная посадочная страница, редирект делать не нужно.
Что делать с robots.txt
Файл robots.txt помогает ограничить обход, но не заменяет noindex. Если URL уже в индексе, запрет в robots.txt не гарантирует его исчезновение. Поэтому используйте его аккуратно.
Пример для служебных разделов:
User-agent: *
Disallow: /?s=
Disallow: /search/
Disallow: /author/
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.phpНе добавляйте туда слишком широкие правила вроде Disallow: / или запрет на папки темы и плагинов без понимания последствий. Это легко ломает обход важных ресурсов.
Проверка результата после внедрения
После изменений не ограничивайтесь просмотром страницы в браузере. Проверьте несколько уровней:
- в исходном коде страницы должен появиться
noindex,follow; - страница поиска или архив автора не должна попадать в карту сайта;
- в Search Console статус URL должен начать меняться после повторного обхода;
- при запросе
site:example.comслужебные URL постепенно должны исчезать, если они больше не нужны в индексе; - редиректы для вложений должны отдавать код 301, а не 200.
Если используете кэш-плагин или серверный кэш, очистите его после правок. Иначе вы будете проверять старую версию страницы и решите, что код не работает.
Частые ошибки и как их исправить
Закрыли robots.txt, но не поставили noindex
Это частая ошибка. Если URL уже известен поисковику, он может остаться в индексе как «запрещённый к обходу». Для удаления из выдачи нужен именно noindex или удаление страницы с корректным редиректом/404.
Случайно закрыли полезные архивы
Иногда под раздачу попадают категории и теги, которые реально дают трафик. Перед внедрением проверьте, какие архивы уже ранжируются. Если архив полезен, не ставьте на него noindex только потому, что он «похож на дубль».
Редирект вложений ведёт в никуда
Если у вложения нет родительской записи и нет прямого файла, редирект должен вести на понятную страницу, а не на 404. Иначе вы создадите цепочку ошибок и ухудшите поведение краулера.
Правило конфликтует с SEO-плагином
Если у вас уже есть Yoast SEO, Rank Math или другой SEO-плагин, он может сам управлять robots meta. В таком случае проверьте, не дублируете ли вы логику в теме. Два разных источника noindex обычно не ломают сайт, но усложняют диагностику.
Практические советы по безопасности и производительности
Не вносите такие правки прямо в родительскую тему. После обновления они исчезнут. Лучше использовать дочернюю тему или mu-plugin. Если правка только одна, mu-plugin удобнее: она не зависит от активации темы.
Если на сайте много служебных URL, полезно дополнительно:
- убрать из sitemap страницы поиска, вложения и служебные архивы;
- проверить canonical на шаблонах архива;
- не плодить параметры фильтрации без необходимости;
- сократить количество страниц с одинаковым заголовком и пустым описанием.
Для сайтов, где нужно быстро навести порядок в дублях и служебных страницах, иногда проще использовать набор инструментов вроде Clearfy Pro, но даже тогда полезно понимать, какие именно URL закрываются и почему. Автоматическая настройка без проверки может скрыть важные страницы от индексации.
Если хотите, чтобы служебные страницы не мешали SEO, а не просто «были отключены», ориентируйтесь на три вещи: точечный noindex, аккуратный robots.txt и проверку в Search Console. Тогда решение будет предсказуемым и не затронет нормальные разделы сайта.