Как отладить robots.txt и meta robots в WordPress без потери индексации

Автор: Татьяна Тарасова | Опубликовано: 22.08.2026

Если страницы выпали из поиска, а в Search Console одновременно всплывают сигналы про noindex, заблокированные ресурсы и странные canonical, проблема часто не в одном месте. В WordPress это обычно смесь настроек темы, SEO-плагина, кастомного кода и старых правил в robots.txt. Разбирать это нужно по слоям: сначала понять, кто именно отдаёт директиву, потом убрать конфликт, и только после этого просить поисковик переобойти сайт.

Когда проблема действительно в robots.txt и meta robots

Типичный сценарий выглядит так: страница открывается в браузере, но в индексе её нет; или наоборот, URL уже давно закрыт от индексации, а поисковик продолжает показывать его в отчёте. Ещё один частый случай — в исходном коде страницы есть <meta name="robots" content="noindex,follow">, хотя в админке всё выглядит нормально. Это уже не «глюк Google», а конфликт между источниками правил.

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

Файл /robots.txt — не закрывает ли он нужные разделы или CSS/JS.
Исходный код страницы — есть ли там noindex, nofollow или неожиданный canonical.
Настройки SEO-плагина — не переопределяют ли они шаблонные правила.
Тему и кастомные плагины — нет ли фильтров, которые добавляют мета-теги на лету.
Кэш — не отдаёт ли сервер старую версию страницы с прежними директивами.

Диагностика: где именно WordPress подставляет запрет на индексацию

Начинать лучше не с правки файлов, а с проверки фактического ответа сервера и HTML. Это экономит время: иногда в админке всё уже исправлено, но кэш или CDN продолжают отдавать старую версию.

Проверка robots.txt

Откройте https://example.com/robots.txt и посмотрите, нет ли там слишком широких запретов. Опасные варианты — блокировка всего сайта через Disallow: / или закрытие папок, из которых поисковику нужны стили, скрипты и изображения. Для WordPress это особенно критично, если в отчётах Search Console появляются проблемы с рендерингом.

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://example.com/sitemap_index.xml

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

Проверка meta robots и canonical

Откройте исходный код страницы и найдите строки с robots и canonical. Если SEO-плагин и тема одновременно выводят canonical, поисковик может получить два разных сигнала. Это не всегда ломает индексацию, но создаёт лишний шум. Для проверки удобно смотреть HTML напрямую, а не через визуальный инспектор браузера.

<?php
add_action('wp_head', function () {
    if (is_singular()) {
        global $post;
        $noindex = get_post_meta($post->ID, '_my_noindex', true);

        if ($noindex === '1') {
            echo '<meta name="robots" content="noindex,follow" />' . "\n";
        }
    }
}, 1);

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

Пошаговое решение без лишнего риска

Сначала уберите конфликтующие источники, потом проверьте результат на одной странице, и только после этого переносите изменения на весь сайт.

Шаг 1. Зафиксируйте текущие правила

Сохраните копию robots.txt и сделайте скриншот настроек индексации в SEO-плагине. Это пригодится, если после правок что-то перестанет индексироваться. На живом сайте лучше не править вслепую: одна лишняя директива может закрыть весь раздел.

Шаг 2. Уберите дублирующие директивы

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

Шаг 3. Настройте robots.txt через WordPress-фильтр

Если нужно добавить правила программно, используйте фильтр robots_txt. Это безопаснее, чем редактировать файл вручную на каждом деплое, особенно если сайт живёт в Git.

<?php
add_filter('robots_txt', function ($output, $public) {
    $output .= "\nUser-agent: *\n";
    $output .= "Disallow: /search/\n";
    $output .= "Disallow: /tag/\n";
    $output .= "Allow: /wp-admin/admin-ajax.php\n";

    return $output;
}, 10, 2);

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

Шаг 4. Для отдельных страниц задайте noindex точечно

Если нужно закрыть только служебные страницы, делайте это через мета-поле или условие в шаблоне. Так проще контролировать логику и не ломать весь сайт.

<?php
add_action('wp_head', function () {
    if (is_page(array('thanks', 'privacy-policy'))) {
        echo '<meta name="robots" content="noindex,follow" />' . "\n";
    }
}, 1);

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

Сравнение подходов: плагин, код или ручная правка

Подход	Когда подходит	Минус
SEO-плагин	Если нужно управлять индексацией без разработки	Легко получить дубли с темой или кастомным кодом
Код в теме/плагине	Если правила зависят от типа страницы или роли	Нужен контроль при обновлениях и деплоях
Ручная правка robots.txt	Для быстрого точечного изменения	Файл легко перезаписать при обновлении или миграции

Как проверить, что исправление сработало

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

Откройте страницу в режиме инкогнито и проверьте исходный код.
Убедитесь, что в HTML остался только один источник meta robots.
Проверьте robots.txt по прямому URL.
В Search Console отправьте URL на переобход.
Если есть CDN или серверный кэш, очистите его отдельно от WordPress-кэша.

Если страница всё ещё помечается как noindex, ищите не только в теме, но и в mu-plugins, сниппетах в functions.php и настройках плагинов, которые могли остаться после удаления.

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

Закрыли весь сайт через robots.txt

Ошибка выглядит банально, но встречается часто после переноса с тестового домена. Исправление простое: уберите Disallow: /, проверьте доступ к важным разделам и не забудьте про sitemap.

Два разных canonical на одной странице

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

Noindex висит на страницах из-за кэша

После исправления настройки страница может ещё какое-то время отдавать старый HTML. Очистите объектный кэш, page cache и CDN. Если используется серверный кэш, проверьте заголовки ответа.

Закрыли служебные файлы, которые нужны для рендеринга

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

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

Не храните критичные правила только в админке, если у вас несколько окружений. Для проекта с Git лучше держать логику индексации в коде или в управляемом конфиге, а не в ручных правках на проде. И ещё: не ставьте несколько SEO-плагинов одновременно ради «дополнительной проверки» — это почти гарантированный источник дублей мета-тегов.

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

Главная мысль простая: сначала найдите источник директивы, потом уберите конфликт, и только затем проверяйте индексацию. В WordPress это почти всегда быстрее, чем пытаться «починить SEO» одной общей настройкой.