Когда в индексе начинают всплывать служебные, фильтровые или почти пустые страницы, обычно проблема не в одном теге, а в том, что WordPress и плагины одновременно отдают несколько сигналов поисковикам. Один URL можно закрыть через noindex, другой — через robots.txt, третий — склеить через canonical. Если перепутать эти инструменты, страница либо останется в индексе, либо выпадет из поиска вместе с нужным трафиком.
Ниже — рабочая схема, которая помогает точечно закрывать отдельные страницы в WordPress и при этом не ломать обход сайта, внутренние ссылки и аналитику.
Когда проблема действительно в индексации, а не в контенте
Перед правками стоит понять, что именно вы хотите убрать из поиска. Это важно: robots.txt запрещает обход, но не гарантирует удаление уже проиндексированного URL. noindex говорит поисковику не держать страницу в выдаче, но для этого он должен иметь возможность её увидеть. canonical помогает, когда есть дубль и нужно указать основную версию.
Типичные сценарии
- служебные страницы с тонким контентом: результаты поиска, страницы фильтров, тестовые посадочные;
- дубли одного и того же материала из-за параметров в URL;
- архивы, которые не нужны в поиске, но должны работать для пользователей;
- страницы, которые уже попали в индекс и не исчезают после удаления из меню.
Что проверить до изменений
- есть ли страница в индексе по запросу
site:example.com/URL; - отдаёт ли она код
200 OKили уже редиректит; - есть ли на ней
canonicalи не указывает ли он на саму себя или на другой URL; - не закрыта ли она уже в SEO-плагине, чтобы не получить конфликт настроек.
Диагностика: какой сигнал сейчас видит поисковик
Откройте исходный код страницы и найдите три вещи: meta robots, link rel="canonical" и, если используете SEO-плагин, его настройки для конкретного типа контента. На практике часто бывает так: страница закрыта в robots.txt, но при этом уже висит в индексе, потому что раньше была доступна. Или наоборот — стоит noindex, но плагин генерирует каноникал на главную, из-за чего поисковик путается в сигналах.
Если страница должна остаться доступной для пользователей, но не для поиска, не блокируйте её в robots.txt первой же правкой. Сначала добейтесь корректного noindex, а уже потом решайте, нужен ли запрет обхода.
Пошаговое решение: как закрыть страницу без лишних побочных эффектов
1. Выберите правильный способ для конкретного URL
Для одиночной страницы или шаблона лучше использовать noindex. Для дубля — canonical. Для технического раздела, который не должен обходиться ботами вообще, можно добавить правило в robots.txt, но только если вы понимаете последствия.
| Подход | Когда применять | Плюс | Минус |
|---|---|---|---|
noindex | Страница доступна, но не нужна в выдаче | Гибко и безопаснее для уже проиндексированных URL | Нужно, чтобы бот мог зайти на страницу |
canonical | Есть дубль основной страницы | Склеивает сигналы на нужный URL | Не всегда убирает мусорный URL быстро |
robots.txt | Технические разделы и лишний обход | Снижает нагрузку на обход | Не решает проблему уже проиндексированных страниц |
2. Добавьте noindex для конкретной страницы через фильтр WordPress
Если у вас нет SEO-плагина или нужно точечно переопределить поведение, можно добавить мета-роботы через wp_head. Пример ниже закрывает одну конкретную страницу по ID.
<?php
add_action( 'wp_head', function () {
if ( is_page( 123 ) ) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
} );Здесь важен именно noindex,follow: страница не должна попадать в индекс, но ссылки с неё могут продолжать передавать сигнал дальше. Для служебных страниц это обычно безопаснее, чем noindex,nofollow.
3. Для дубля укажите канонический URL
Если страница технически нужна, но должна считаться копией другой, задайте каноникал на основную версию. Это лучше, чем просто прятать дубль от индексации, потому что поисковик получает явный ориентир.
<?php
add_action( 'wp_head', function () {
if ( is_page( 456 ) ) {
echo '<link rel="canonical" href="https://example.com/osnovnaya-stranica/" />' . "\n";
}
} );Не ставьте каноникал на главную «на всякий случай». Если страницы действительно разные по смыслу, такой редирект сигнала только ухудшит ситуацию.
4. При необходимости ограничьте обход в robots.txt
Это уместно для технических директорий, которые не должны тратить краулинговый бюджет. Но не используйте robots.txt как единственный способ убрать уже проиндексированный URL.
User-agent: *
Disallow: /wp-admin/
Disallow: /?s=
Disallow: /tmp/
Allow: /wp-admin/admin-ajax.phpЕсли вы закрываете параметрический URL, убедитесь, что он не нужен для работы фильтров, поиска или AJAX-запросов. Иначе можно сломать фронтенд.
Если используете SEO-плагин: где обычно возникает конфликт
Большинство проблем появляется, когда ручной код и настройки плагина делают одно и то же по-разному. Например, плагин уже выводит noindex для архивов, а вы дополнительно прописали каноникал в теме. В результате поисковик видит противоречивые сигналы.
Проверьте, не включены ли одновременно:
- закрытие страницы в настройках SEO-плагина;
- ручной
meta robotsв теме или дочерней теме; - редирект на другую страницу;
- каноникал, который указывает не на ту версию URL.
Если нужен более управляемый контроль над дублями и служебными страницами, в WordPress часто удобнее централизовать это в одном SEO-инструменте, а не размазывать по теме и нескольким плагинам. Например, Clearfy Pro закрывает часть типовых технических дублей и чистит лишние элементы, но даже с ним логику лучше проверять вручную, а не полагаться на галочки без ревизии.
Как проверить, что решение сработало
После правок не ограничивайтесь просмотром кода страницы. Нужна проверка по нескольким уровням.
- Откройте страницу в браузере и убедитесь, что она отдаёт
200, если должна быть доступна. - Посмотрите исходный код: есть ли нужный
meta robotsилиcanonical. - Проверьте заголовки ответа, если редирект или защита реализованы на сервере.
- В Search Console отправьте URL на повторную проверку и посмотрите, как меняется статус.
Для быстрой проверки на сервере удобно использовать curl:
curl -I https://example.com/stranica/
curl -s https://example.com/stranica/ | grep -iE 'robots|canonical'Если после этого страница всё ещё в индексе, не делайте резких выводов. Удаление из выдачи может занять время, особенно если URL уже давно обходился и на него есть внешние ссылки.
Частые ошибки и как их исправить
Закрыли URL в robots.txt и ждёте удаления из индекса
Это самая частая ошибка. Если бот не может зайти на страницу, он может не увидеть noindex. Для уже проиндексированных URL сначала нужен доступ к странице, потом — сигнал на исключение.
Ставите noindex на страницу, которая должна передавать вес
noindex,follow обычно безопаснее, чем полное закрытие. Если поставить nofollow без причины, можно обрезать внутреннюю перелинковку.
Каноникал указывает на нерелевантную страницу
Это ломает склейку. Канонический URL должен быть максимально близок по смыслу и содержанию. Если страницы разные, лучше не использовать canonical как замену редиректу.
Правите шаблон, а не конкретный тип страниц
Иногда достаточно закрыть один архив или один шаблон записи, но правка вносится глобально. После этого из поиска пропадает то, что должно было остаться. Всегда проверяйте условие: is_page(), is_singular(), is_archive() или конкретный ID.
Оставляете несколько SEO-источников правды
Если один плагин генерирует canonical, второй — robots meta, а третий — редиректы, отладка превращается в угадайку. Лучше оставить один слой, который отвечает за индексацию, и документировать, где именно он настроен.
Практические советы по безопасности и производительности
Чем меньше ручных правок в functions.php без контроля, тем проще сопровождать сайт. Если логика закрытия страниц нужна надолго, вынесите её в небольшой mu-plugin или в дочернюю тему, чтобы она не потерялась после обновления.
- не закрывайте через
robots.txtто, что должно быть доступно для рендера фронтенда; - не дублируйте одинаковые
meta robotsв теме и SEO-плагине; - проверяйте, не создаёт ли плагин лишние архивы, теги и страницы пагинации;
- после изменений прогоняйте кэш: серверный, плагина и CDN, если он есть;
- для массовых правок сначала тестируйте на staging-копии.
Если задача не разовая, а системная — например, нужно регулярно убирать технические дубли, архивы и мусорные страницы, — имеет смысл централизовать это в одном инструменте и не размазывать логику по нескольким местам. Иначе через пару месяцев никто не вспомнит, почему конкретный URL закрыт именно так.
Самый надёжный критерий здесь простой: страница либо остаётся доступной пользователю и исчезает из поиска, либо корректно склеивается с основной версией. Если после правок у вас всё ещё есть конфликт между robots, noindex и canonical, значит, решение пока не собрано в одну понятную схему.