Если в WordPress в индекс попадают служебные страницы, дубли архивов, результаты поиска по сайту или тестовые разделы, проблема обычно не в одном теге. Чаще всего нужно выбрать правильный способ: robots.txt, noindex или канонический URL. Ошибка здесь стоит дорого: можно случайно закрыть важные страницы или, наоборот, оставить мусор в индексе.
Ниже разберём рабочую схему для типичных случаев в WordPress: что именно закрывать, чем закрывать и как проверить результат без гадания по логам.
Когда проблема действительно в индексации
Сначала стоит понять, что именно попало в поиск. Не все “лишние страницы” одинаковы. Иногда это реальные URL, которые должны существовать для пользователей, но не должны ранжироваться. Иногда это технические дубли, которые лучше вообще не отдавать поисковикам.
Типичные сценарии
- страницы внутреннего поиска вида
/?s=...; - архивы автора на сайте с одним автором;
- страницы пагинации, если они создают шум в индексе;
- теги и рубрики с пустым или почти пустым содержимым;
- страницы фильтров и параметров, если они не нужны в поиске;
- тестовые, служебные и временные разделы.
Если URL уже в индексе, одного Disallow в robots.txt часто недостаточно. Поисковик может перестать обходить страницу, но старый URL останется в выдаче без обновления сигнала. Для удаления из индекса обычно нужен noindex или корректный каноникал, а не только запрет обхода.
Что выбрать: robots.txt, noindex или canonical
У каждого инструмента своя задача. Если смешать их без понимания, получится либо лишняя индексация, либо закрытие нужных страниц.
| Подход | Когда использовать | Что важно помнить |
|---|---|---|
robots.txt | Чтобы не тратить краулинговый бюджет на служебные URL | Не удаляет уже проиндексированные страницы сам по себе |
noindex | Когда страница доступна пользователю, но не должна быть в поиске | Страница должна быть доступна для обхода, иначе робот не увидит мета-тег |
canonical | Когда есть дубликаты и нужно указать основной URL | Не подходит для скрытия мусорных страниц, если они реально не нужны |
Практически это выглядит так: служебные страницы поиска и фильтров чаще закрывают noindex, а тяжелые технические разделы можно дополнительно ограничить в robots.txt. Дубли архивов и пагинацию обычно решают через каноникал и настройки SEO-плагина.
Пошаговое решение в WordPress
Шаг 1. Определите тип URL
Не начинайте с правки robots.txt. Сначала проверьте, что за страница перед вами: реальный контент, дубликат или служебный URL. Для этого откройте страницу в браузере и посмотрите:
- есть ли у неё собственный контент;
- должна ли она быть доступна пользователю;
- есть ли у неё альтернативная основная версия;
- нужна ли она в поиске вообще.
Если это, например, страница поиска по сайту, её обычно не нужно индексировать, но и полностью закрывать от обхода не всегда полезно: поисковику надо увидеть noindex.
Шаг 2. Добавьте noindex там, где страница должна открываться, но не индексироваться
Для WordPress самый безопасный путь — использовать SEO-плагин, который умеет управлять мета-тегами и каноникалом. Если плагин уже стоит, настройка обычно делается в интерфейсе без кода. Если нужен точечный вариант, можно добавить noindex через wp_head для конкретного шаблона или типа страницы.
<?php
add_action('wp_head', function () {
if (is_search() || is_author() || is_tag()) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
});Этот пример показан только как ориентир. В реальном проекте лучше сузить условие. Например, не все архивы тегов стоит закрывать: если теговые страницы наполнены и реально приводят трафик, их лучше оставить индексируемыми.
Шаг 3. Для дублей задайте canonical
Если одна и та же запись доступна по нескольким адресам, канонический URL помогает поисковику выбрать основную версию. Это актуально для UTM-параметров, пагинации, сортировок и некоторых архивов.
<?php
add_action('wp_head', function () {
if (is_singular('post')) {
echo '<link rel="canonical" href="' . esc_url(get_permalink()) . '" />' . "\n";
}
});В обычном WordPress каноникал уже часто выводится SEO-плагином или ядром, поэтому не дублируйте его вручную без проверки. Два каноникала в одном документе — частая причина путаницы.
Шаг 4. Ограничьте обход в robots.txt только для служебных разделов
robots.txt полезен, когда нужно убрать из обхода технические URL, которые не несут ценности. Например, внутренний поиск, некоторые параметры или системные каталоги. Но не используйте его как единственный способ удаления из индекса.
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /?s=
Disallow: /search/
Disallow: /trackback/
Disallow: /comments/feed/Если у вас на сайте есть нестандартные URL поиска или фильтров, подставляйте реальные пути, а не копируйте шаблон вслепую. И не закрывайте /wp-content/ целиком, если там лежат изображения, которые должны индексироваться.
Диагностика: как понять, что решение сработало
Проверка нужна не только после внедрения, но и до него. Иначе легко закрыть не тот шаблон и потерять трафик.
- Откройте страницу в браузере и проверьте исходный код: есть ли
meta robotsсnoindex. - Проверьте, выводится ли один канонический URL и совпадает ли он с основной версией страницы.
- Посмотрите ответ сервера через
curl -I, если нужно убедиться, что страница не отдаёт неожиданные редиректы или ошибки. - В Google Search Console используйте проверку URL и посмотрите, как робот видит страницу.
Пример быстрой проверки через командную строку:
curl -s https://example.com/search/?s=test | grep -iE 'robots|canonical'Если страница должна быть закрыта от индексации, но в HTML нет noindex, значит правило не сработало или выводится не на том шаблоне. Если noindex есть, но URL всё равно висит в индексе, дайте поисковику время на переобход и проверьте, не блокирует ли robots.txt саму страницу раньше, чем робот увидит мета-тег.
Частые ошибки и как их исправить
Закрыли страницу в robots.txt, но не поставили noindex
Это самая частая ошибка. Страница остаётся в индексе, потому что робот не может её переобойти и увидеть новый сигнал. Исправление: уберите слишком жёсткий запрет обхода и добавьте noindex на саму страницу.
Поставили noindex на важный архив
Так бывает, когда под одну настройку попадают и мусорные, и полезные страницы. Например, закрыли все архивы рубрик, хотя часть из них даёт стабильный трафик. Исправление: пересмотрите логику по типам страниц, а не по принципу “всё архивы закрыть”.
Добавили два canonical
Один каноникал может приходить из темы, второй — из SEO-плагина, третий — из ручного кода. Поисковик в такой ситуации не всегда понимает, какой URL считать основным. Исправление: оставьте один источник каноникала.
Закрыли CSS и JS вместе с мусорными URL
Иногда в robots.txt по ошибке блокируют ресурсы темы или плагинов. В результате страница рендерится хуже, а диагностика в Search Console становится менее понятной. Исправление: не трогайте статические ресурсы без причины.
Что делать, если нужен более аккуратный контроль без ручного кода
Если на сайте много архивов, дублей и служебных страниц, удобнее управлять этим через SEO-плагин и отдельную чистку технических дублей. В таких задачах обычно помогает связка настроек для мета-тегов, каноникала и отключения лишних архивов. Например, в Clearfy Pro есть инструменты для удаления дублей и технической чистки сайта: https://wpshop.ru/plugins/clearfy.
Но даже с плагином логика остаётся той же: сначала определяете тип страницы, потом выбираете способ закрытия, затем проверяете исходный код и статус в поиске. Плагин не заменяет диагностику, он только упрощает внедрение.
Практический чек-лист перед публикацией изменений
- Проверил, что URL действительно не должен ранжироваться.
- Убедился, что страница не потеряет полезный трафик после закрытия.
- Выбрал один способ:
noindex,canonicalилиrobots.txt. - Проверил, что нет дублирующих каноникалов из темы и плагинов.
- Открыл исходный код и увидел нужный мета-тег.
- Проверил страницу в Google Search Console.
- Не заблокировал важные ресурсы и стили в
robots.txt.
Как быстро проверить результат после внедрения
После правки не ограничивайтесь одной ручной проверкой. Смотрите на три вещи: HTML страницы, поведение робота и состояние в индексе. Если noindex появился, каноникал один и правильный, а в Search Console URL помечается как исключённый или неиндексируемый, значит схема работает. Если же URL всё ещё индексируется, проверьте, не мешает ли старый кэш, не выводит ли тема свой собственный canonical и не перекрывает ли SEO-плагин ваши настройки.
Для сложных сайтов полезно сначала сделать изменения на одной группе URL, а не на всём сайте сразу. Так проще отловить конфликт темы, плагина кеша или SEO-модуля и не получить массовое выпадение страниц из поиска.