Служебные страницы WordPress часто попадают в индекс не потому, что сайт «плохо настроен», а потому что им никто отдельно не задал правила. В результате в поиске всплывают страницы авторов, архивы дат, служебные результаты поиска, вложения медиафайлов и другие URL, которые не несут ценности для пользователя. Если их не контролировать, поисковик тратит обход на мусор, а в отчётах появляются лишние страницы.
Ниже — рабочая схема: сначала быстро понять, что именно индексируется, потом закрыть лишнее через robots.txt, noindex или настройки SEO-плагина, и в конце проверить, что изменения реально сработали.
Что именно считать системными страницами
Под системными страницами здесь я имею в виду не контентные записи и не важные посадочные, а URL, которые WordPress создаёт автоматически. Обычно это:
- архивы автора, если на сайте один автор или у авторов нет уникальной ценности;
- архивы по датам;
- страницы поиска вида
?s=; - вложения медиафайлов, если они открываются как отдельные страницы;
- служебные таксономии и пустые архивы;
- страницы пагинации, если они не нужны в индексе;
- технические URL, которые создаёт тема или плагин.
Не стоит закрывать всё подряд. Например, архив категории может быть полноценной страницей входа в контент и должен оставаться в индексе. Ошибка здесь — не в том, что архив существует, а в том, что его не разделили на полезный и бесполезный тип.
Диагностика: какие URL уже попали в индекс
Перед правками проверьте, что именно поисковик видит сейчас. Самый надёжный путь — взять данные из Google Search Console и сопоставить их с реальными шаблонами WordPress.
На что смотреть в Search Console
Откройте отчёт по страницам и найдите группы URL, которые не должны ранжироваться. Типичные признаки:
- много URL с параметрами или служебными путями;
- страницы без кликов и показов, но в индексе;
- дубли одного и того же контента через архивы и вложения;
- страницы поиска, которые индексируются вместо полезных материалов.
Если у вас есть доступ к логам сервера, полезно посмотреть, как часто бот ходит по этим URL. Иногда проблема не в индексации, а в том, что бот тратит слишком много обхода на мусорные страницы.
Быстрая проверка через поиск
Для первичной оценки можно использовать запросы вида site:example.com inurl:author или site:example.com inurl:?s=. Это не замена Search Console, но хороший способ быстро увидеть, что уже всплыло в выдаче.
Что лучше: плагин, код или robots.txt
У каждого варианта свой сценарий. Ниже — короткое сравнение, чтобы не делать лишнюю работу.
| Подход | Когда использовать | Плюсы | Минусы |
|---|---|---|---|
| SEO-плагин | Нужно быстро закрыть архивы, таксономии и вложения | Удобно, меньше риска ошибиться в шаблонах | Зависимость от интерфейса плагина |
| Код в теме или мини-плагине | Нужен точечный контроль без лишних модулей | Прозрачно, можно версионировать | Нужно аккуратно тестировать |
robots.txt | Нужно ограничить обход, но не обязательно индексацию | Просто и быстро | Не всегда убирает URL из индекса, если они уже известны |
Если цель именно убрать URL из индекса, одного robots.txt часто недостаточно. Он запрещает обход, но не гарантирует удаление уже проиндексированной страницы. Для индексации нужен noindex или корректный канонический URL, а иногда — и удаление самой страницы.
Пошаговое решение: закрываем лишние страницы правильно
Шаг 1. Отключите индексацию вложений
Страницы вложений — частая причина дублей. Если у медиафайла открывается отдельная страница без полезного контента, её лучше перенаправить на сам файл или на родительскую запись. В SEO-плагинах это обычно настраивается отдельной опцией. Если плагина нет, можно сделать редирект кодом:
<?php
add_action('template_redirect', function () {
if (is_attachment()) {
$parent = wp_get_post_parent_id(get_queried_object_id());
if ($parent) {
wp_redirect(get_permalink($parent), 301);
} else {
wp_redirect(home_url('/'), 301);
}
exit;
}
});Такой вариант полезен, если вложения уже успели попасть в индекс и вы хотите убрать их из выдачи без ручной чистки каждого URL.
Шаг 2. Закройте архивы автора и даты, если они не нужны
Если на сайте один автор или архивы не дают дополнительной ценности, их можно закрыть от индексации. В SEO-плагинах это обычно делается через настройку мета-тегов. Если нужен кодовый вариант, добавьте noindex в <head> для конкретных шаблонов:
<?php
add_action('wp_head', function () {
if (is_author() || is_date() || is_search()) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
}, 1);Здесь важно не перепутать noindex и nofollow. Для таких страниц обычно достаточно noindex,follow: страница не индексируется, но ссылки с неё могут учитываться.
Шаг 3. Уберите страницы поиска из индекса
Внутренний поиск WordPress почти никогда не должен ранжироваться. Если у вас в индексе есть URL с ?s=, это почти всегда лишний шум. Для таких страниц достаточно того же правила noindex,follow. Дополнительно можно запретить их обход в robots.txt, но это не замена мета-тегу.
User-agent: *
Disallow: /?s=
Disallow: /search/Обратите внимание: директива Disallow: /?s= не всегда решает проблему полностью, потому что поисковик может увидеть URL через ссылки или внешние упоминания. Поэтому сначала ставим noindex, а затем уже ограничиваем обход.
Шаг 4. Проверьте канонические URL
Если одна и та же страница доступна по нескольким адресам, у неё должен быть один канонический URL. Это особенно важно для архивов, пагинации и страниц с параметрами. В WordPress многие SEO-плагины делают это автоматически, но после кастомизаций стоит проверить исходный код.
Если каноникал указывает не туда, поисковик может продолжать считать страницу дублем. В таком случае исправляйте не только noindex, но и сам шаблон ссылки.
Как проверить результат после внедрения
После правок не ограничивайтесь визуальной проверкой страницы в браузере. Нужно убедиться, что поисковик видит именно то, что вы задумали.
- Откройте страницу и посмотрите исходный код: должен быть
<meta name="robots" content="noindex,follow" />там, где вы его добавили. - Проверьте заголовок ответа сервера для страниц, которые вы закрывали редиректом: вложения должны отдавать
301. - В Search Console отправьте URL на повторную проверку через инспекцию страницы.
- Через несколько обходов проверьте, исчез ли URL из отчёта по индексированию.
Если URL всё ещё в индексе, это не всегда ошибка настройки. Поисковику нужно время, чтобы переобойти страницу и обновить статус. Но если через несколько обходов ничего не меняется, ищите конфликт: другой плагин мог перезаписать мета-теги или каноникал.
Частые ошибки и как их исправить
Закрыли страницу в robots.txt, но она осталась в индексе
Это классическая ситуация. Если бот не может зайти на страницу, он не всегда получает сигнал на удаление. Решение: временно уберите запрет, добавьте noindex, дождитесь переобхода и только потом при необходимости снова ограничьте обход.
Поставили noindex на полезный архив
Такое часто случается с архивами категорий, когда их закрывают «на всякий случай». В итоге из поиска исчезает нормальная посадочная страница. Исправление простое: проверьте, есть ли у архива уникальный текст, навигация и поисковый смысл. Если да — оставляйте индексируемым.
Редирект вложений ведёт не туда
Иногда код отправляет все вложения на главную, хотя у них есть родительская запись. Это ухудшает поведение пользователя и может выглядеть как мягкая ошибка для поисковика. Лучше сначала проверять родителя, а уже потом использовать главную как запасной вариант.
SEO-плагин и тема пишут разные robots-метки
Если в <head> одновременно появляются разные директивы, поисковик может интерпретировать их не так, как вы ожидаете. Оставьте один источник правды: либо SEO-плагин, либо код в теме, либо мини-плагин. Не смешивайте всё сразу.
Чек-лист перед публикацией изменений
- Проверены страницы, которые реально должны остаться в индексе.
- Для вложений настроен редирект или отключена отдельная страница вложения.
- Для архивов автора, даты и поиска задано
noindex,follow, если они не нужны. - В
robots.txtнет запретов, которые мешают переобходу важных страниц. - Канонические URL не указывают на служебные страницы.
- Изменения проверены в исходном коде и в Search Console.
Когда лучше использовать плагин, а когда код
Если у вас типовой сайт и нужно быстро навести порядок, удобнее сделать это через SEO-плагин. Если же вы ведёте несколько проектов, хотите контролировать поведение шаблонов в git и не зависеть от интерфейса, кодовый вариант надёжнее. Для точечной чистки сайта и контроля дублей часто используют Clearfy Pro: он закрывает типовые служебные страницы и помогает убрать лишние элементы без ручной правки шаблонов. Подробности можно посмотреть на странице плагина: https://wpshop.ru/plugins/clearfy.
Но какой бы вариант вы ни выбрали, логика одна: сначала определить, какие URL действительно мусорные, потом дать поисковику понятный сигнал, и только после этого ждать обновления индекса. Если просто «спрятать» страницу, не меняя мета-теги и каноникал, проблема обычно возвращается.
