Если в Search Console всплывают страницы, которые не должны попадать в поиск, проблема обычно не в «плохом SEO», а в том, что WordPress по умолчанию публикует слишком много служебных URL: архивы автора, метки, результаты поиска, вложения, страницы пагинации, параметры сортировки и фильтров. Их не всегда нужно удалять. Чаще достаточно правильно закрыть индексацию и не ломать навигацию для пользователей и ботов.
Ниже разберём, как понять, какие страницы действительно стоит закрывать, чем отличаются noindex, nofollow, robots.txt и canonical, и как проверить, что настройка сработала.
Какие страницы WordPress обычно не должны индексироваться
Сначала стоит отделить полезные страницы от технических. Ошибка здесь дорогая: если закрыть лишнее, можно потерять трафик; если не закрыть нужное, поисковик начнёт тратить краулинговый бюджет на мусор и плодить дубли.
Типичные кандидаты на закрытие
- страницы внутреннего поиска сайта, например
?s=; - архивы автора на сайте с одним автором;
- служебные страницы пагинации, если они не несут самостоятельной ценности;
- страницы вложений медиафайлов, если они пустые и не используются как посадочные;
- метки и таксономии, которые дублируют рубрики или не имеют контента;
- URL с параметрами сортировки, фильтров, UTM и прочими служебными хвостами.
Не стоит автоматически закрывать рубрики, если они реально собирают трафик и содержат уникальные описания. То же касается страниц автора в многопользовательском блоге: иногда они полезны и для пользователей, и для поиска.
Диагностика: где именно появляются дубли и мусорные URL
Перед правками посмотрите, какие страницы уже попали в индекс. Самый быстрый путь — отчёт «Страницы» в Google Search Console и поиск по сайту через оператор site:example.com. Если в выдаче видны архивы, вложения или результаты поиска, это сигнал на настройку.
Полезно проверить и сам HTML. Откройте проблемную страницу и посмотрите, есть ли в <head> мета-тег robots и какой у неё canonical. Если canonical указывает на саму себя, а индексировать страницу не нужно, этого недостаточно — нужен именно noindex.
Для быстрой проверки можно использовать такой набор признаков:
- страница отдаёт
200 OKи доступна без авторизации; - в коде нет
noindex; - canonical ведёт на ту же техническую страницу;
- страница уже проиндексирована или попала в «Просканировано — сейчас не проиндексировано».
Что выбрать: noindex, robots.txt или canonical
Эти инструменты решают разные задачи. Их часто смешивают, из-за чего настройка работает не так, как ожидается.
| Инструмент | Когда использовать | Ограничение |
|---|---|---|
noindex | Страница доступна, но не должна попадать в поиск | Страница должна быть доступна для обхода, чтобы робот увидел директиву |
robots.txt | Нужно ограничить обход раздела или шаблона URL | Не гарантирует удаление уже проиндексированных URL |
canonical | Есть похожие страницы, и нужно указать основную | Не заменяет noindex для откровенно технических страниц |
Практически это выглядит так: для страниц поиска и вложений лучше ставить noindex, follow; для параметров в URL — нормализовать canonical; для совсем служебных путей можно дополнительно ограничить обход в robots.txt, но не рассчитывать только на него.
Пошаговое решение через код темы или мини-плагин
Если не хочется полагаться только на SEO-плагин, можно добавить точечную логику в мини-плагин. Это удобнее, чем править тему: настройка не пропадёт при обновлении шаблона.
1. Закрываем внутренний поиск, вложения и архивы автора
Ниже пример, который добавляет noindex, follow для внутренних поисковых страниц, attachment-страниц и архивов автора на сайте с одним автором. Код не трогает обычные записи и страницы.
<?php
/**
* Plugin Name: Site SEO Noindex Rules
*/
add_filter('wp_robots', function (array $robots) {
if (is_search() || is_attachment() || (is_author() && count_users()['total_users'] === 1)) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
});
Этот вариант использует штатный фильтр wp_robots, который есть в современных версиях WordPress. Если у вас уже стоит SEO-плагин, проверьте, не перетирает ли он мета-robots своими настройками.
2. Убираем индексацию страниц вложений через редирект
Если attachment-страницы не нужны вообще, лучше не только закрыть их от индексации, но и отправлять пользователя на сам файл или родительскую запись. Это уменьшает количество бесполезных URL в обходе.
<?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. Добавляем canonical для параметров сортировки и фильтров
Если на сайте есть URL с параметрами, которые меняют только представление списка, canonical должен указывать на чистую версию страницы. Это особенно полезно для архивов и страниц каталога, где фильтры создают десятки комбинаций.
<?php
add_filter('wp_get_canonical_url', function ($canonical, $post) {
if (!$canonical) {
return $canonical;
}
if (!empty($_GET)) {
$canonical = remove_query_arg(array_keys($_GET), $canonical);
}
return $canonical;
}, 10, 2);
Здесь важно не переборщить. Если параметр реально меняет содержимое страницы и должен индексироваться, его нельзя бездумно выкидывать из canonical. Для сложных фильтров лучше настраивать правила точечно, а не глобально.
Если используете SEO-плагин
Во многих случаях проще закрыть технические страницы в интерфейсе SEO-плагина, чем писать код. Но даже тогда полезно понимать, что именно он делает: ставит noindex, меняет canonical или правит robots.txt. Это разные уровни контроля.
Например, в Clearfy Pro есть инструменты для чистки сайта и управления дублями. Такой подход удобен, когда нужно быстро отключить индексацию служебных архивов, убрать лишние элементы и не собирать это вручную по файлам темы. Но перед включением любой автоматической настройки проверьте, не конфликтует ли она с уже установленным SEO-плагином.
Проверка результата после внедрения
После правок не ограничивайтесь визуальной проверкой страницы. Нужно убедиться, что поисковый робот видит именно то, что вы задумали.
- Откройте страницу в браузере и проверьте исходный код: должен быть
meta name="robots" content="noindex, follow"или эквивалентная директива. - Проверьте canonical: он должен вести на основную версию URL без лишних параметров.
- В Search Console отправьте URL на повторную проверку через инспектор URL.
- Если использовали редирект, убедитесь, что ответ сервера —
301, а не302. - Для страниц, закрытых через
robots.txt, проверьте, что они не блокируют обход там, где робот должен увидетьnoindex.
Хороший практический тест — открыть проблемный URL в режиме инкогнито и через curl посмотреть заголовки и код ответа:
curl -I https://example.com/?s=test
Если страница должна редиректиться, вы увидите 301 и новый адрес в заголовке Location. Если должна оставаться доступной, но не индексироваться, проверьте HTML-мета-теги, а не только заголовки.
Частые ошибки и как их исправить
Закрыли страницу в robots.txt и ждёте исчезновения из индекса
Это частая ошибка. Если URL уже в индексе, одного запрета в robots.txt может быть недостаточно. Поисковик не всегда сможет зайти на страницу и увидеть noindex. В итоге URL может висеть в индексе дольше, чем вы ожидаете. Для уже проиндексированных страниц безопаснее сначала дать роботам доступ и поставить noindex, а потом при необходимости ограничить обход.
Поставили noindex на всё подряд
Иногда под раздачу попадают рубрики, страницы пагинации и даже обычные записи. Это происходит, когда настройку делают через слишком общий фильтр без проверки условий. Перед деплоем обязательно протестируйте несколько типов страниц: запись, рубрику, поиск, вложение, страницу автора.
Canonical указывает на URL с параметрами
Если canonical не нормализован, поисковик продолжит видеть несколько версий одной страницы. Особенно это заметно на страницах с UTM, сортировкой и фильтрами. Canonical должен вести на чистый адрес, а не на текущий URL с хвостом.
Редирект вложений ломает медиа-страницы, которые реально нужны
Если на сайте есть трафик на attachment-страницы, массовый редирект может ухудшить поведение пользователей и сломать старые ссылки. Сначала проверьте аналитику и индекс, потом принимайте решение. Универсального ответа здесь нет.
Чек-лист перед публикацией изменений
- Проверил, какие URL уже в индексе и какие только появляются в обходе.
- Разделил страницы на полезные и технические.
- Для технических страниц выбрал правильный механизм:
noindex, canonical или редирект. - Не закрыл важные рубрики и записи.
- Проверил исходный код и HTTP-ответы.
- Отправил ключевые URL на переобход в Search Console.
- Убедился, что SEO-плагин и код темы не конфликтуют друг с другом.
Практические советы по безопасности и производительности
Если вы вносите правки кодом, не добавляйте их в functions.php активной темы без необходимости. Мини-плагин безопаснее: он не исчезнет после обновления темы и проще отключается при конфликте. Для сайтов с большим количеством архивов и параметров это ещё и удобнее в сопровождении.
Не стоит закрывать всё через robots.txt ради «экономии краулинга», если у вас нет подтверждённой проблемы с обходом. Сначала уберите явные дубли, потом уже ограничивайте технические разделы. Иначе можно случайно спрятать от робота страницы, которые должны быть переобходиться регулярно.
Если нужен более прикладной набор инструментов для чистки дублей, архивов и служебных страниц, посмотрите Clearfy Pro: он закрывает часть типовых задач без ручного кода, но всё равно требует проверки после включения.
В итоге рабочая схема обычно такая: сначала находите технические URL, затем решаете, что закрывать через noindex, что нормализовать canonical, а что лучше убрать редиректом. После этого обязательно проверяете HTML, заголовки и статус в Search Console — только так видно, что настройка действительно сработала.