Как найти и удалить дубли meta robots и canonical в WordPress

Автор: Дарья Данилова | Опубликовано: 28.08.2026

Если в Search Console появляются странные URL, а страницы то выпадают из индекса, то индексируются с неправильным каноническим адресом, часто проблема не в контенте, а в разметке: на странице одновременно присутствуют несколько meta robots или несколько rel=canonical. В WordPress это обычно случается после установки SEO-плагина, добавления кода в тему и подключения еще одного плагина, который тоже пытается управлять индексацией.

Сценарий типичный: один плагин ставит noindex на архивы, другой — выводит свой canonical, а тема или кастомный сниппет добавляет еще один тег в <head>. В итоге поисковик видит конфликтующие сигналы и выбирает не тот URL, который вы ожидали.

Как понять, что проблема именно в дублирующихся meta robots и canonical

Начинать стоит не с правки кода, а с проверки исходного HTML. Откройте проблемную страницу и посмотрите <head>. Если там есть несколько строк вида <meta name="robots" ...> или несколько <link rel="canonical" ...>, это уже повод чистить источник генерации.

Полезно проверить и то, как страницу видит Google. В Search Console откройте проверку URL и сравните:

декларируемый canonical;
выбранный Google canonical;
статус индексации;
наличие noindex в исходном коде.

Если в коде есть noindex, а страница все равно попадает в индекс, значит сигнал либо конфликтует с другим тегом, либо вы смотрите на кешированную версию страницы.

Что искать в исходнике

Откройте HTML страницы и проверьте, нет ли таких ситуаций:

два и более meta name="robots";
canonical на текущую страницу и canonical на другую страницу одновременно;
canonical на URL с параметрами, хотя должен быть чистый адрес;
noindex на страницах, которые должны индексироваться;
теги, которые добавляет SEO-плагин, и теги, которые добавлены вручную в теме.

Откуда берутся дубли в WordPress

На практике источников обычно три. Первый — SEO-плагин, который выводит canonical и robots автоматически. Второй — код в functions.php или в mu-plugin, где разработчик когда-то добавил свои мета-теги. Третий — шаблон темы, в котором в wp_head вставлен ручной вывод.

Отдельная история — плагины кеширования. Они не создают дубли в HTML сами по себе, но могут долго отдавать старую версию страницы после того, как вы уже исправили код. Поэтому после правок всегда нужно очищать кеш на всех уровнях: плагин, сервер, CDN, браузер.

Где обычно прячется лишний вывод

functions.php активной темы;
mu-plugins в wp-content/mu-plugins/;
кастомный плагин проекта;
SEO-плагин с собственными настройками индексации;
шаблон header.php или подключаемые части темы.

Пошаговое решение: как убрать конфликты без поломки индексации

Лучше идти по порядку: сначала найти все места, где выводятся мета-теги, потом оставить только один источник правды. Не пытайтесь «перекрыть» один тег другим через дополнительный вывод в head — это обычно заканчивается новым конфликтом.

Шаг 1. Найдите все места с выводом robots и canonical

Если есть доступ к серверу, быстро проверьте код по проекту:

grep -RniE "rel=['\"]canonical['\"]|name=['\"]robots['\"]|wp_head" wp-content/

Если доступа к SSH нет, ищите вручную в теме и в кастомных плагинах. Особое внимание — к хукy wp_head и к фильтрам SEO-плагина, если они уже используются.

Шаг 2. Оставьте только один источник canonical

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

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

add_action('wp_head', function () {
    if (!is_singular()) {
        return;
    }

    global $post;
    if (!$post instanceof WP_Post) {
        return;
    }

    $canonical = get_permalink($post);
    echo '<link rel="canonical" href="' . esc_url($canonical) . '" />' . "\n";
}, 1);

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

Шаг 3. Проверьте robots на уровне страницы, а не шаблона

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

add_filter('wp_robots', function (array $robots) {
    if (is_search() || is_404()) {
        $robots['noindex'] = true;
        $robots['nofollow'] = true;
    }

    return $robots;
});

Этот подход лучше, чем вручную печатать отдельный <meta name="robots"> в шаблоне. WordPress сам соберет корректный тег, а вы не получите второй экземпляр из другой части кода.

Шаг 4. Уберите ручные теги из темы

Если в header.php или в подключаемом шаблоне есть прямой вывод canonical или robots, удалите его. В теме не должно быть нескольких мест, которые решают одну и ту же задачу. Для индексации это особенно критично: поисковик не обязан угадывать, какой из тегов считать главным.

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

Подход	Когда подходит	Плюсы	Минусы
SEO-плагин	Нужна стандартная логика canonical и robots	Меньше ручного кода, проще поддержка	Легко получить конфликт, если добавить свой вывод сверху
Код в теме или mu-plugin	Есть точечные исключения для отдельных шаблонов	Гибко, можно контролировать условия	Нужно аккуратно следить за дублированием логики
Ручная правка шаблона	Только для разовой диагностики или временного теста	Быстро проверить гипотезу	Плохо масштабируется и легко ломается при обновлении темы

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

После удаления дублей не ограничивайтесь просмотром страницы в браузере. Браузер может показать уже обновленный файл, а поисковик — старый кеш или старую версию из индекса.

Проверка должна быть такой:

Откройте HTML страницы и убедитесь, что meta robots и canonical выводятся один раз.
Очистите кеш плагина, сервера и CDN.
Проверьте страницу в режиме инкогнито или через curl.
В Search Console отправьте URL на повторную проверку.
Сравните выбранный Google canonical с тем, который вы ожидаете.

Для быстрой проверки через консоль можно использовать:

curl -s https://example.com/page/ | grep -iE "canonical|robots"

Если после очистки кеша в исходнике остался только один canonical и один robots-тег, а Search Console больше не показывает конфликт, значит правка сработала.

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

Оставили canonical и в SEO-плагине, и в теме

Это самая частая причина. Решение простое: оставьте один источник. Если плагин уже умеет управлять canonical, ручной вывод в теме нужно удалить.

Поставили `noindex` через мета-тег, но не убрали старый кеш

Визуально кажется, что все исправлено, но поисковик продолжает видеть старую версию. Очистите кеш на всех уровнях и проверьте ответ сервера повторно.

Использовали несколько SEO-плагинов одновременно

Даже если они «не мешают друг другу» в настройках, оба могут печатать свои мета-теги. Для одного сайта должен быть один основной инструмент управления индексацией.

Добавили canonical на страницы с параметрами без нормализации URL

Если страница доступна с ?utm= или другими параметрами, canonical должен указывать на чистый адрес без мусора. Иначе вы сами закрепляете дубли.

Закрыли от индексации не ту страницу

Иногда проблема не в дубле, а в неверном условии. Перед публикацией правки проверьте, что is_search(), is_404(), is_page() или нужный архив действительно срабатывают только там, где надо.

Чек-лист перед публикацией правок

В проекте остался один источник canonical.
В HTML выводится только один meta name="robots".
Кеш очищен на сайте, сервере и CDN.
Проверка URL в Search Console показывает ожидаемый canonical.
Технические страницы закрыты точечно, а не глобально.
На страницах, которые должны индексироваться, нет случайного noindex.

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

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

Если в проекте много технических дублей и ручных исключений, имеет смысл вынести часть рутинной SEO-логики в отдельный инструмент. Например, в Clearfy Pro есть функции для чистки сайта и управления техническими дублями, но даже с плагином все равно нужно понимать, какой именно тег и откуда выводится. Плагин не спасает от конфликта, если в теме уже есть свой canonical.

Главное правило здесь простое: один URL — один canonical, одна логика robots, один ответственный источник. Все остальное только усложняет диагностику и делает индексацию менее предсказуемой.