На WordPress технические страницы часто попадают в индекс не потому, что сайт «плохо настроен», а потому что их просто никто не ограничил: архивы автора, страницы с параметрами, внутренний поиск, служебные таксономии, тестовые шаблоны, пагинация фильтров. В итоге в поиске появляются дубли и мусорные URL, а краулинговый бюджет уходит не туда.
Ниже — рабочая схема: что именно закрывать, чем это делать и как проверить, что вы не сломали нормальную индексацию.
Какие страницы действительно стоит закрывать
Не все «неважные» страницы нужно прятать от поисковиков. Если URL полезен пользователю и может получать трафик, его лучше оставить в индексе и работать с canonical, контентом или структурой. Закрывать имеет смысл именно технические страницы, которые не несут самостоятельной ценности.
Типичные кандидаты на закрытие
- страницы внутреннего поиска вида
?s=; - архивы автора на сайтах, где один автор и архивы дублируют блог;
- архивы дат, если они не используются как отдельная навигационная сущность;
- страницы с параметрами сортировки, фильтрации и трекинга;
- тестовые или служебные страницы, которые не должны индексироваться;
- страницы пагинации, если они создаются только технически и не нужны в поиске.
Диагностика: как понять, что проблема есть
Начните не с robots.txt, а с поиска уже проиндексированных URL. Самая частая ошибка — закрыть что-то «на всякий случай», не проверив, что именно уже попало в индекс.
Что смотреть в первую очередь
- отчет «Страницы» в Google Search Console;
- поиск по сайту через
site:example.comс подозрительными параметрами; - логи сервера, если нужно понять, какие URL реально сканирует бот;
- исходный код страниц на наличие
meta robotsи canonical.
Если у вас уже есть индексированные дубли, одного robots.txt обычно недостаточно: поисковик может перестать обходить URL, но не всегда быстро уберет его из индекса. Для удаления из индекса нужен либо noindex, либо корректный canonical, либо ручное удаление через инструменты вебмастера.
Что лучше: robots.txt, noindex или canonical
У каждого инструмента своя задача. Смешивать их без понимания смысла — прямой путь к хаосу в индексации.
| Подход | Когда использовать | Плюс | Минус |
|---|---|---|---|
| robots.txt | Для запрета обхода служебных URL | Снижает нагрузку на обход | Не гарантирует удаление из индекса |
noindex | Для страниц, которые уже доступны, но не должны индексироваться | Работает именно на индексацию | Страница должна быть доступна для обхода |
| canonical | Для дублей, которые должны указывать на основную страницу | Сохраняет сигналы на основной URL | Не подходит для полностью бесполезных страниц |
Практически всегда лучше так: служебные URL закрыть от индексации через noindex, а в robots.txt ограничить только действительно технические разделы, которые не должны тратиться на обход.
Пошаговое решение в WordPress
1. Закрываем служебные страницы через meta robots
Если страница должна открываться пользователю, но не должна индексироваться, добавьте noindex, follow. Для этого удобно использовать хук wp_robots, который есть в современных версиях WordPress.
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_search() || is_author() || is_date() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );Этот вариант хорош тем, что не зависит от темы и не требует править шаблоны вручную. Но применять его нужно аккуратно: если на сайте авторские архивы реально полезны, не закрывайте их автоматически.
2. Убираем из индекса страницы с параметрами
Для URL с параметрами фильтрации или сортировки лучше не пытаться «ловить все подряд» в robots.txt. Надежнее определить конкретные сценарии и отдать им noindex.
<?php
add_filter( 'wp_robots', function( array $robots ) {
$query_args = array( 'sort', 'filter', 'view', 'utm_source', 'utm_medium', 'utm_campaign' );
foreach ( $query_args as $arg ) {
if ( isset( $_GET[ $arg ] ) ) {
$robots['noindex'] = true;
$robots['follow'] = true;
break;
}
}
return $robots;
} );Здесь важно не переусердствовать. UTM-параметры обычно не должны создавать отдельные индексируемые страницы, но если вы используете их только в аналитике, закрывать такие URL — разумно.
3. Настраиваем robots.txt для обхода мусорных разделов
robots.txt нужен не для удаления из индекса, а для ограничения обхода. Например, можно запретить сканирование служебных путей, которые не должны тратить ресурсы бота.
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /?s=
Disallow: /*?replytocom=
Disallow: /*?sort=
Disallow: /*?filter=
Sitemap: https://example.com/sitemap_index.xmlНе стоит бездумно закрывать в robots.txt страницы, которые уже в индексе и которые вы хотите оттуда убрать. В этом случае поисковик может просто перестать их обходить, но URL останется в выдаче дольше, чем нужно.
4. Для дублей используем canonical
Если у вас есть несколько URL с одинаковым контентом, canonical часто полезнее, чем запрет индексации. Например, для страниц с сортировкой или параметрами, которые не меняют смысл контента, canonical должен указывать на основную версию.
В WordPress canonical обычно уже выводится ядром, но при нестандартной логике его нужно проверять. Если тема или плагин подменяют canonical, поисковик может выбрать не тот URL.
Проверка результата после внедрения
После изменений не ограничивайтесь визуальной проверкой страницы. Нужно убедиться, что бот видит именно то, что вы задумали.
- Откройте исходный код и проверьте наличие
<meta name="robots" content="noindex,follow">или эквивалентной директивы. - Проверьте, не блокируется ли URL в robots.txt раньше, чем вы успели отдать
noindex. - В Google Search Console используйте проверку URL и посмотрите, что видит Googlebot.
- Сравните индекс через
site:до и после, но не делайте выводы по одному запросу — поисковая выдача обновляется не мгновенно.
Если страница уже была в индексе, удаление может занять время. Это нормально. Главное — не создавать новые дубли и не мешать поисковику увидеть корректную директиву.
Частые ошибки и как их исправить
Закрыли страницу в robots.txt, но не поставили noindex
Так делают часто, когда хотят «быстро убрать из поиска». Проблема в том, что robots.txt запрещает обход, а не удаляет URL из индекса. Решение: сначала дайте странице noindex, дождитесь переобхода, потом при необходимости ограничьте сканирование в robots.txt.
Случайно закрыли важные страницы
Это происходит, когда правило написано слишком широко: например, is_archive() без уточнения или проверка по параметру, который используется и на полезных страницах. Исправление простое: сузьте условие и проверьте, какие шаблоны реально попадают под фильтр.
Поставили canonical на главную для всех дублей
Такой подход ломает смысловую связь между страницами. Canonical должен указывать на максимально близкую основную версию, а не просто «куда-нибудь». Если дубль относится к категории, canonical должен вести на категорию, а не на главную.
Ожидали мгновенного исчезновения из выдачи
Поисковики не обновляют индекс моментально. Если URL уже в индексе, дайте время на переобход и не меняйте правила каждые несколько часов. Иначе вы сами усложняете диагностику.
Практические советы по безопасности и производительности
Если на сайте много параметрических URL, полезно не только закрыть их от индексации, но и ограничить генерацию лишних вариантов на уровне шаблонов и фильтров. Чем меньше мусорных URL создается, тем проще поддерживать SEO и тем меньше нагрузка на сервер.
Для больших сайтов удобно вынести правила в отдельный мини-плагин или mu-plugin, а не держать их в functions.php темы. Тогда логика не потеряется при смене темы и будет проще контролировать изменения.
<?php
/**
* Plugin Name: Technical Noindex Rules
*/
add_filter( 'wp_robots', function( array $robots ) {
if ( is_search() || is_author() || is_date() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
if ( isset( $_GET['sort'] ) || isset( $_GET['filter'] ) ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );Если вам нужно быстро навести порядок в дублях и технических страницах без ручной правки десятков шаблонов, в экосистеме WPShop есть Clearfy Pro — он как раз закрывает часть типовых SEO-задач, связанных с дублями и чисткой сайта. Но даже с плагином полезно понимать, какие правила он применяет и где именно они срабатывают.
Что проверить в конце
- служебные URL отдают
noindex, а не только закрыты в robots.txt; - важные страницы не получили случайный запрет;
- canonical у дублей указывает на правильную основную версию;
- в Search Console нет роста мусорных URL в отчете по индексированию;
- robots.txt не блокирует то, что нужно сначала удалить из индекса.
Если после внедрения правила работают точечно и не затрагивают полезные страницы, значит схема настроена правильно. В WordPress это как раз тот случай, когда лучше один раз аккуратно разделить индексацию и обход, чем потом разбирать последствия массового закрытия URL.