Если в индексе всплывают страницы поиска, архивы тегов, служебные URL или внутренние фильтры, править robots.txt обычно поздно и не всегда правильно. Для таких задач в WordPress надежнее управлять индексацией на уровне HTML-мета, canonical и шаблонов архивов. Это позволяет точечно закрывать только нужные страницы, не ломая обход сайта поисковыми роботами.
Ниже разберем рабочую схему: как понять, что именно попало в индекс, чем отличается noindex от запрета в robots.txt, как внедрить решение через код или плагин и как проверить, что поисковик увидел изменения.
Когда проблема действительно в индексации, а не в контенте
Сначала стоит убедиться, что речь не о слабом контенте, а именно о техническом дубле или служебной странице. Типичный сценарий: в поиске находятся URL вида /page/2/, ?s=, архивы автора без смысла, страницы с параметрами сортировки или результаты внутреннего поиска. Такие страницы не должны конкурировать с основными посадочными.
Что проверить в первую очередь
- есть ли у страницы реальный контент или это пустой шаблон;
- открывается ли она по нескольким URL с одинаковым содержимым;
- не генерирует ли тема или плагин отдельные архивы без пользы для пользователя;
- не закрыта ли страница в
robots.txt, хотя ее нужно просто исключить из индекса; - есть ли у URL корректный
canonical.
Если страница должна обходиться роботом, но не должна попадать в выдачу, robots.txt — не лучший инструмент. Запрет в нем мешает поисковику увидеть мета-тег noindex, а значит, удаление из индекса может затянуться. Для таких случаев лучше оставить страницу доступной для обхода и явно пометить ее как неиндексируемую.
Что использовать: noindex, canonical или robots.txt
У каждого инструмента своя задача. Ошибка многих сайтов в том, что они пытаются решить все одним способом. Это приводит либо к лишним страницам в индексе, либо к тому, что поисковик не может нормально переобойти URL.
| Подход | Когда применять | Минус |
|---|---|---|
noindex | служебные страницы, поиск по сайту, архивы без ценности | страница остается доступной для обхода |
canonical | дубли с параметрами, сортировкой, пагинацией в некоторых сценариях | не всегда подходит для полностью уникальных страниц |
robots.txt | только для экономии crawl budget на явно ненужных разделах | не гарантирует удаление уже проиндексированного URL |
Если задача — убрать страницу из выдачи, но оставить ее доступной для обхода, выбирайте noindex. Если нужно показать поисковику основную версию страницы среди дублей, используйте canonical. Если URL вообще не должен обходиться, тогда уже имеет смысл ограничивать его в robots.txt, но это отдельный сценарий.
Пошаговое решение через код темы или плагина
Для точечного управления индексацией удобно добавить логику в дочернюю тему или в небольшой mu-plugin. Это надежнее, чем править шаблоны вручную в нескольких местах. Ниже пример, который ставит noindex,follow для страниц поиска, архивов автора и некоторых служебных архивов.
<?php
add_action('wp_head', function () {
if (is_search() || is_author() || is_date()) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
}, 1);
Этот вариант подходит, если у вас нет SEO-плагина, который уже управляет robots meta. Если плагин есть, не дублируйте теги. Два разных meta name="robots" на одной странице — частая причина некорректной интерпретации.
Если нужно исключить только внутренний поиск, а архивы оставить открытыми, сузьте условие:
<?php
add_action('wp_head', function () {
if (is_search()) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
}, 1);
Когда лучше использовать SEO-плагин
Если у вас уже стоит плагин для SEO, проще и безопаснее настроить индексацию там, а не вшивать логику в тему. Например, в Clearfy Pro есть инструменты для чистки сайта и управления дублями, что удобно, когда нужно закрыть сразу несколько технических страниц без ручного кода. Если вы работаете через интерфейс, проверьте, не конфликтует ли настройка плагина с вашим шаблоном и не выводит ли тема собственный meta robots.
Смысл не в том, чтобы обязательно ставить плагин, а в том, чтобы выбрать один источник правды для robots meta. Иначе одна часть сайта будет говорить поисковику одно, а другая — другое.
Как закрыть служебные архивы в шаблоне темы
Иногда проблема не в общем SEO, а в том, что тема WordPress генерирует слишком много архивных страниц: автора, даты, рубрики-пустышки. В таком случае можно не только добавить noindex, но и убрать лишние ссылки из навигации, чтобы не создавать новые точки входа.
Пример для functions.php дочерней темы:
<?php
add_action('wp_head', function () {
if (is_author() || is_date()) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
}, 1);
add_filter('author_link', function ($link) {
return $link;
});
Последний фильтр в примере ничего не меняет и показан только как напоминание: если вы хотите убрать ссылки на автора из шаблона, это делается не через author_link без причины, а через правку вывода в теме. Не отключайте архивы вслепую — сначала проверьте, не используются ли они для навигации по контенту.
Проверка результата после внедрения
После изменений не ограничивайтесь просмотром исходного кода в браузере. Нужно проверить, как страницу видит поисковый робот и не осталось ли конфликтов.
- Откройте страницу и убедитесь, что в
<head>есть один корректныйmeta name="robots". - Проверьте, что нет второго тега из SEO-плагина или темы.
- Посмотрите заголовок ответа и canonical через инструменты разработчика или расширение для SEO-проверки.
- В Google Search Console отправьте URL на повторную проверку, если страница уже была в индексе.
- Проверьте, не блокируется ли URL в
robots.txt, если вы рассчитываете на переобход.
Если страница уже была проиндексирована, удаление не происходит мгновенно. Для ускорения важно, чтобы робот мог снова зайти на URL и увидеть noindex. Поэтому не стоит одновременно ставить запрет в robots.txt и ждать быстрого исчезновения из выдачи.
Частые ошибки и как их исправить
Закрыли URL в robots.txt и удивились, что он все еще в индексе
Это нормальная ситуация. Если робот не может зайти на страницу, он не увидит noindex. В результате URL может оставаться в индексе дольше, чем ожидалось. Исправление простое: уберите запрет на обход, дайте странице отдать noindex, а потом уже решайте, нужен ли запрет на уровне robots.txt.
Добавили noindex в шаблон, но плагин SEO вывел свой тег
Проверьте, где именно формируется robots meta. В WordPress часто конфликтуют тема, SEO-плагин и кастомный код. Оставьте только один механизм управления. Если используете Yoast SEO, Rank Math или другой SEO-плагин, настройте индексацию там и удалите ручной вывод из темы.
Поставили noindex на все архивы подряд
Это частая ошибка после шаблонных советов. Архивы рубрик могут быть полезны, если они реально помогают навигации и содержат уникальные описания. Не закрывайте все подряд. Сначала проверьте, какие архивы приносят трафик и какие страницы нужны пользователю.
Забыли про canonical
Если у вас есть дубли с параметрами, одного noindex может быть недостаточно. Поисковик должен понимать, какая версия основная. В таких случаях canonical помогает склеить сигналы и уменьшить путаницу в индексации.
Практические советы по безопасности и производительности
Если вы вносите правки в тему, делайте это через дочернюю тему или mu-plugin. Так обновление не затрет изменения. Перед правкой сохраните резервную копию и проверьте изменения на staging-копии, особенно если сайт уже получает органический трафик.
Не ставьте несколько SEO-плагинов одновременно ради одной настройки. Это лишняя нагрузка и источник конфликтов. Если задача сводится к чистке дублей, служебных URL и управлению мета-тегами, лучше использовать один инструмент и один источник настройки. В ряде проектов для этого достаточно Clearfy Pro, но только если его функции действительно закрывают ваш сценарий и не дублируют уже существующую SEO-логику.
Еще один практический момент: не закрывайте от индексации страницы, которые используются в перелинковке или как посадочные под низкочастотные запросы, без анализа. Иногда проблема не в индексации, а в том, что на странице нет полезного текста, заголовка или внутренней связности.
Если вам нужно не только убрать дубли, но и системно почистить WordPress от лишних технических страниц, удобнее сначала составить список URL, которые должны остаться открытыми, а уже потом применять noindex точечно. Такой подход проще проверять и легче откатывать.