Тонкие страницы в WordPress обычно не ломают сайт сразу, но постепенно размывают индекс: в поиск попадают архивы без смысла, страницы поиска, пагинация, теги без контента, служебные шаблоны и результаты фильтров. Проблема не в самом наличии таких URL, а в том, что поисковик тратит на них обход и может считать их дублями или малополезными страницами.
Задача здесь не «закрыть всё подряд», а аккуратно разделить URL на три группы: что должно индексироваться, что лучше оставить для обхода, но закрыть от индексации, и что можно полностью отсечь через robots.txt или серверную логику. Если перепутать эти уровни, легко получить обратный эффект: страницы исчезнут из поиска, но останутся в индексе как URL без сниппета или перестанут нормально переобходиться.
Какие страницы обычно создают проблему
В WordPress чаще всего приходится разбирать не контентные записи, а служебные и полуслужебные URL. Они появляются автоматически и часто не несут самостоятельной ценности для поиска.
- страницы поиска вида
?s=; - архивы тегов и рубрик с пустым или слабым содержимым;
- страницы автора на небольших сайтах, где один автор и дублирующийся контент;
- пагинация архивов, если она не даёт новой ценности;
- страницы медиа-вложений, если они индексируются отдельно;
- служебные страницы плагинов, фильтров и параметров.
Если у вас уже есть статья про дубли страниц, не путайте её с этой задачей: здесь речь не о поиске одинаковых URL, а о контроле индексации и обхода. Это разные проблемы и решаются по-разному.
Диагностика: что именно индексируется сейчас
Перед правками нужно понять, где именно проблема. Самый быстрый путь — посмотреть, какие URL уже попали в индекс и как они отдаются в HTML.
Проверка через поиск и исходный код
Откройте подозрительную страницу и проверьте:
- есть ли в
<head>тег<meta name="robots" content="noindex,follow">или другой вариант; - какой canonical указан;
- не закрыта ли страница одновременно в
robots.txtи черезnoindex; - не генерирует ли плагин SEO свои правила поверх ваших.
Для быстрой проверки в консоли браузера можно искать robots-мета и canonical прямо в HTML:
document.querySelector('meta[name="robots"]')?.content;
document.querySelector('link[rel="canonical"]')?.href;Проверка через WP-CLI
Если есть доступ к серверу, удобно проверить, как WordPress отдает конкретный URL, и не мешает ли кэш или редирект. Например, можно посмотреть заголовки ответа:
curl -I https://example.com/stranica-poiska/?s=testЕсли страница должна быть закрыта от индексации, но отвечает как обычный HTML без noindex, значит проблема в шаблоне, SEO-плагине или в том, что правило применяется не к тому типу страниц.
Что лучше использовать: noindex, canonical или robots.txt
У каждого инструмента своя роль. Ошибка многих сайтов — пытаться решить всё одним способом. Ниже короткое сравнение.
| Подход | Когда использовать | Плюс | Минус |
|---|---|---|---|
noindex | Страница должна обходиться, но не индексироваться | Гибко и безопасно для большинства случаев | Страница может ещё какое-то время оставаться в индексе до переобхода |
canonical | Есть основная версия страницы и дублирующая | Помогает склеивать сигналы | Не заменяет noindex для слабых страниц |
robots.txt | Нужно ограничить обход технических URL | Снижает нагрузку и мусорный crawl | Не гарантирует удаление URL из индекса, если он уже известен |
Практически всегда для тонких страниц лучше начинать с noindex,follow. robots.txt используйте только там, где действительно не хотите тратить обход на технические URL. Если закрыть страницу в robots и при этом она уже в индексе, поисковик может не увидеть мета-тег и не понять, что страницу нужно убрать.
Пошаговое решение для WordPress
Шаг 1. Определите типы страниц, которые нужно закрыть
Не закрывайте всё подряд. Сначала составьте список шаблонов URL. Обычно это:
- поиск;
- архивы тегов с малым количеством записей;
- страницы автора на сайте с одним автором;
- вложения;
- служебные страницы плагинов;
- страницы пагинации, если они не нужны в поиске.
Если у вас SEO-плагин уже умеет отключать индексацию архивов, сначала проверьте его настройки. Код нужен только там, где штатных опций не хватает или нужно точечное правило.
Шаг 2. Добавьте noindex для конкретных типов архивов
Ниже пример для functions.php темы или для небольшого mu-plugin. Он добавляет noindex,follow на поиск, архивы автора и вложения. Логика простая: если страница не несёт самостоятельной ценности, но должна быть доступна для обхода, закрываем её от индексации.
<?php
add_filter('wp_robots', function (array $robots): array {
if (is_search() || is_author() || is_attachment()) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
});Для рубрик и тегов лучше не использовать универсальное правило без анализа. Если рубрика — основной входной раздел с нормальным текстом и внутренней перелинковкой, её можно оставить в индексе. Если это пустой архив ради автоматической таксономии, тогда уже имеет смысл закрывать.
Шаг 3. Закройте отдельные таксономии точечно
Если нужно закрыть только определённые рубрики или теги, можно проверить ID термина и подставить noindex только для них. Это безопаснее, чем отключать всю таксономию целиком.
<?php
add_filter('wp_robots', function (array $robots): array {
if (is_category()) {
$term = get_queried_object();
if ($term && !empty($term->term_id)) {
$closed_categories = [12, 34, 56];
if (in_array((int) $term->term_id, $closed_categories, true)) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
}
}
return $robots;
});Такой подход удобен, когда часть рубрик нужна для SEO, а часть создана только для внутренней навигации или импорта.
Шаг 4. Проверьте canonical на служебных страницах
Если страница должна быть закрыта, canonical не должен указывать на саму себя как на основную SEO-страницу, если у неё нет ценности. Для поиска и пагинации это особенно важно. В большинстве случаев canonical должен вести на более сильную каноническую страницу или отсутствовать как отдельный сигнал, если SEO-плагин уже управляет им корректно.
Если вы пишете собственную логику, не подменяйте canonical вручную без необходимости. Ошибки здесь часто появляются после установки нескольких SEO-плагинов одновременно.
Шаг 5. Отсеките технический мусор через robots.txt только там, где это оправдано
robots.txt полезен для технических URL, которые не должны расходовать crawl budget. Но не используйте его как замену noindex для обычных страниц. Пример осторожного правила:
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /?s=
Disallow: /search/
Disallow: /attachment/Последние строки стоит применять только если вы уверены в структуре сайта. На некоторых установках поиск и вложения имеют другие URL-формы, и слепое копирование здесь только навредит.
Если используете SEO-плагин
В большинстве проектов проще и надёжнее управлять индексацией через SEO-плагин, а код оставить для исключений. Это снижает риск конфликтов между темой и плагином. Если нужен аккуратный контроль дублей и служебных страниц, в Clearfy Pro есть инструменты для закрытия лишних архивов и технической чистки, но перед включением любых опций всё равно проверьте, какие шаблоны реально используются на сайте.
Важно не включать одновременно несколько механизмов, которые делают одно и то же: например, если плагин уже ставит noindex на архивы тегов, не дублируйте это вторым фильтром в теме. В результате можно получить странные комбинации canonical, robots и sitemap.
Как проверить, что решение сработало
После внедрения не ограничивайтесь визуальной проверкой. Нужно убедиться, что страница отдает нужные сигналы и что они не ломаются кэшем.
- Откройте страницу в браузере и проверьте исходный код.
- Убедитесь, что в
<head>появился нужныйmeta robots. - Проверьте canonical.
- Сделайте запрос заголовков через
curl -Iи убедитесь, что нет неожиданного редиректа. - Если используется кэш, очистите его и проверьте страницу в приватном окне.
- В Search Console отправьте URL на повторную проверку, если страница уже была в индексе.
Для быстрой ручной проверки можно использовать такой шаблон:
curl -s https://example.com/page/ | grep -iE 'robots|canonical'Если страница всё ещё индексируется, это не всегда ошибка. Поисковику нужно время, чтобы переобойти URL и обновить состояние. Но если спустя несколько обходов в HTML нет нужных сигналов, значит правило не срабатывает на нужном шаблоне.
Частые ошибки и как их исправить
Закрыли страницу в robots.txt, но не поставили noindex
Это самая частая ошибка. Если URL уже известен поисковику, он может остаться в индексе без возможности переобхода. Исправление: временно уберите запрет в robots.txt, дайте поисковику увидеть noindex, затем снова оцените необходимость блокировки.
Поставили noindex на важные страницы архива
Иногда рубрики и архивы — это не мусор, а нормальные посадочные страницы. Если закрыть их без анализа, можно потерять трафик и внутреннюю структуру. Исправление: откройте такие архивы обратно и добавьте на них нормальный текст, хлебные крошки и внутренние ссылки.
Конфликтуют тема и SEO-плагин
Тема может выводить свои мета-теги, а SEO-плагин — свои. В итоге в коде появляются дублирующиеся robots или canonical. Исправление: оставьте один источник управления SEO-метками и отключите лишний вывод в теме.
Проверили только главную страницу
Часто правило работает на главной и не работает на архиве автора, поиске или вложениях. Исправление: тестируйте каждый тип URL отдельно, а не по одному примеру.
Не очистили кэш после изменений
Если на сайте есть серверный или плагинный кэш, старый HTML может жить дольше, чем вы думаете. Исправление: очистите кэш страницы, объектный кэш, CDN, если он есть, и проверьте ответ заново.
Практические советы по безопасности и производительности
Любые изменения в индексации лучше вносить через дочернюю тему или mu-plugin, а не прямо в обновляемую тему. Так вы не потеряете правки после апдейта. Если правите robots.txt через файл, убедитесь, что его не перезаписывает плагин или панель хостинга.
С точки зрения производительности полезно не только закрывать мусор от индексации, но и уменьшать количество генерируемых служебных страниц. Например, если на сайте десятки пустых тегов, лучше не просто поставить им noindex, а пересмотреть таксономии и структуру контента. Иначе вы будете лечить симптом, а не причину.
Если нужно массово привести сайт в порядок, удобно сначала собрать список проблемных шаблонов, затем по одному закрыть их через wp_robots или настройки SEO-плагина и только после этого править robots.txt. Такой порядок снижает риск случайно отрезать от индекса нужные страницы.