Как закрыть от индексации технические страницы WordPress: robots.txt, noindex и canonical без лишних ошибок

Технические страницы в WordPress часто попадают в индекс не потому, что сайт «плохой», а потому что поисковик видит лишние URL: архивы автора, страницы тегов, вложения медиафайлов, результаты поиска по сайту, служебные страницы пагинации и параметры сортировки. Если их не контролировать, в индексе появляется шум, а важные страницы получают меньше внимания краулера.

Ниже — рабочая схема, которая помогает закрыть именно служебные страницы, не ломая доступность сайта для пользователей и не создавая конфликтов между robots.txt, noindex и canonical.

Какие страницы обычно нужно закрывать

Не все технические URL одинаково вредны. Одни можно оставить открытыми, но убрать из индекса. Другие лучше вообще не отдавать поисковым роботам в карте сайта и навигации. Для WordPress чаще всего речь идет о таких типах страниц:

• страницы внутреннего поиска вида /?s=;
• архивы автора на сайтах с одним автором;
• тонкие архивы тегов, если они не несут самостоятельной ценности;
• вложенные страницы медиафайлов;
• служебные параметры, которые создают дубли контента;
• страницы пагинации, если они индексируются без смысла для структуры сайта.

Если у вас новостной или контентный проект, не спешите закрывать все архивы подряд. Иногда категории и архивы авторов дают нормальный трафик и помогают структуре. Сначала смотрим на фактическую пользу, потом принимаем решение.

Диагностика проблемы: где именно появляются лишние URL

Перед правками проверьте, что именно уже попало в индекс и откуда поисковик берет эти адреса. Это можно сделать без плагинов и без сложной аналитики.

Что смотреть в первую очередь

• отчет «Страницы» в Google Search Console;
• поиск по оператору site:example.com с типовыми шаблонами URL;
• XML-карту сайта: нет ли там архивов, вложений и страниц поиска;
• исходный код страниц: есть ли meta robots и корректный canonical;
• файл robots.txt: не закрывает ли он случайно нужные разделы.

Типичная ошибка — закрыть URL в robots.txt, а потом удивляться, что он все равно висит в индексе как «запрещено robots.txt». Поисковик может знать о странице, даже если не может ее сканировать. Если задача именно убрать URL из индекса, одного Disallow часто недостаточно.

Что использовать: robots.txt, noindex или canonical

У каждого инструмента своя роль. Если перепутать их назначение, можно получить обратный эффект: страницы останутся в индексе или перестанут передавать сигналы на нужный URL.

Практически это выглядит так: служебные страницы поиска и вложений лучше помечать noindex, follow, а дубли с параметрами — приводить к основной версии через canonical. robots.txt используйте аккуратно, только там, где действительно не хотите сканирования.

Пошаговое решение для WordPress

1. Закрываем внутренний поиск и вложения от индексации

Если тема или SEO-плагин не управляет этим корректно, можно добавить фильтр в functions.php дочерней темы или в собственный мини-плагин. Пример ниже ставит noindex, follow на страницы поиска и вложений.

<?php
add_action('wp_head', function () {
    if (is_search() || is_attachment()) {
        echo '<meta name="robots" content="noindex, follow" />' . "\n";
    }
}, 1);

Это не универсальное решение для всех тем, потому что некоторые SEO-плагины уже выводят свои мета-теги. Если у вас Yoast SEO, Rank Math или аналог, сначала проверьте их настройки, чтобы не получить два тега robots одновременно.

2. Настраиваем canonical для архивов с параметрами

Если на сайте появляются дубли из-за параметров сортировки, фильтров или UTM-меток, canonical должен указывать на чистую версию URL. Для простых случаев можно отфильтровать canonical на уровне WordPress.

<?php
add_filter('get_canonical_url', function ($canonical, $post) {
    if (is_singular() && $canonical) {
        return remove_query_arg(array('utm_source', 'utm_medium', 'utm_campaign', 'sort', 'filter'), $canonical);
    }

    return $canonical;
}, 10, 2);

Важно: этот код не решает все сценарии. Он полезен там, где canonical строится на основе текущего URL и в него попадают лишние параметры. Если у вас сложная фильтрация или AJAX-подгрузка, лучше отдельно проверить, как именно формируются адреса.

3. Убираем служебные страницы из sitemap

Если технические URL попали в XML-карту сайта, поисковик получит прямой сигнал, что эти страницы важны. В большинстве SEO-плагинов это настраивается в интерфейсе, но если вы пишете собственную логику, исключайте такие типы контента из sitemap заранее.

Для вложений и поисковых страниц обычно достаточно не добавлять их в карту сайта вообще. Для архивов тегов и авторов решение зависит от структуры проекта: если архив не нужен в поиске, его лучше не включать в sitemap и дополнительно закрыть от индексации.

4. Проверяем robots.txt

Файл robots.txt нужен для управления сканированием, а не для маскировки дублей. Его стоит использовать для явных служебных разделов, но без фанатизма. Пример аккуратного варианта:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /?s=
Disallow: /search/
Disallow: /attachment/

Не стоит закрывать в robots.txt все подряд, включая CSS, JS и важные публичные разделы. Если робот не может загрузить ресурсы страницы, вы получите проблемы с рендерингом и оценкой качества.

Проверка результата после внедрения

После правок не ограничивайтесь визуальной проверкой. Нужно убедиться, что поисковик видит именно то, что вы задумали.

• Откройте проблемный URL в браузере и проверьте исходный код страницы.
• Убедитесь, что на нужных страницах есть meta robots с noindex.
• Проверьте, что canonical ведет на чистый URL без параметров.
• Посмотрите, исчезли ли служебные URL из XML-sitemap.
• В Search Console отправьте страницу на повторную проверку после изменения.

Если страница уже была в индексе, удаление может занять время. Это нормально. Важнее, чтобы новый обход видел корректные сигналы: noindex, правильный canonical и отсутствие лишних ссылок на служебный URL.

Частые ошибки и как их исправить

Закрыли страницу в robots.txt, но не поставили noindex

Такой URL может остаться в индексе как известный, но недоступный для сканирования. Если нужно именно убрать страницу из поиска, откройте ее для обхода и добавьте noindex.

Поставили noindex через плагин и через код одновременно

В исходнике появляются два одинаковых мета-тега, а иногда еще и конфликтующие директивы. Оставьте один источник управления: либо SEO-плагин, либо собственный код.

Canonical указывает на несуществующую или редиректящую страницу

Поисковик может проигнорировать такой сигнал. Canonical должен вести на живой, конечный URL без лишних редиректов.

Закрыли архивы, которые реально дают трафик

Это частая ошибка на контентных сайтах. Сначала смотрите статистику и поисковые запросы, потом принимайте решение. Если архив полезен, лучше доработать его контент и шаблон, а не прятать от индекса.

Практические советы по безопасности и производительности

Чистка индекса помогает не только SEO. Меньше мусорных URL — меньше лишней нагрузки на обход и меньше шансов, что в поиске всплывут технические адреса после обновления темы или плагина.

• Не редактируйте functions.php основной темы: используйте дочернюю тему или мини-плагин.
• Перед изменениями сохраните текущий robots.txt и шаблоны SEO-плагина.
• Если используете кэш, очистите его после правок, иначе проверка покажет старую версию.
• Не закрывайте CSS/JS в robots.txt, если они нужны для рендеринга страниц.

Если вам нужен более системный контроль дублей, служебных URL и мусорных мета-данных, имеет смысл посмотреть в сторону инструментов вроде Clearfy Pro: у него есть набор настроек для чистки сайта и SEO-оптимизации. Подробности можно проверить на странице https://wpshop.ru/plugins/clearfy.

Когда лучше не писать код вручную

Если на сайте уже стоит SEO-плагин и у вас нет своей системы тестирования, ручные правки могут создать больше проблем, чем пользы. В таком случае безопаснее сначала использовать настройки плагина, а код добавлять только для узких исключений, которые не покрываются интерфейсом.

Код оправдан, когда нужно закрыть один конкретный тип URL, а плагин либо не умеет это делать, либо делает слишком грубо. Во всех остальных случаях важнее предсказуемость, чем «красивое» решение в коде.