Если в индексе появляются похожие URL, задача одна: явно указать поисковикам основную версию страницы. В WordPress это обычно делают через тег canonical в <head>. Он не удаляет дубли сам по себе, но помогает поисковым системам понять, какой адрес считать главным, когда одна и та же страница доступна по нескольким URL.
Для WordPress это особенно актуально на записях, страницах, архивах, пагинации и URL с параметрами сортировки, фильтров или UTM-меток. Ниже разберём, когда canonical нужен, как проверить текущую настройку и как задать его вручную, если штатного поведения недостаточно.
Когда canonical действительно нужен
В WordPress дубли чаще всего появляются не из-за ошибки, а из-за особенностей структуры сайта. Один и тот же контент может открываться по разным адресам:
- с параметрами в URL, например
?utm_source=...или?sort=price; - через архивы рубрик, меток, авторов и дат;
- через пагинацию, если контент разбит на несколько страниц;
- через версии с
wwwи без него, сhttpиhttps; - через технические или альтернативные URL, которые формируются темой или плагином.
Canonical нужен не для всех страниц подряд, а там, где есть риск, что поисковик увидит несколько равнозначных адресов одного и того же или очень похожего контента. Если у страницы есть одна очевидная основная версия, canonical должен указывать именно на неё.
Как WordPress формирует canonical по умолчанию
В современных версиях WordPress для записей, страниц и многих архивов canonical обычно выводится автоматически. За это отвечает ядро, и в типовом случае вручную ничего добавлять не нужно. Но на практике этого бывает недостаточно, если:
- тема или SEO-плагин меняют поведение
<head>; - на сайте есть нестандартные типы записей и архивы;
- нужно убрать параметры из canonical;
- нужно задать канонический адрес для страниц с фильтрами, сортировкой или пагинацией по своему правилу.
Перед правками полезно посмотреть исходный код страницы и найти строку вида <link rel="canonical" href="..." />. Если её нет, либо она указывает не туда, сначала проверьте, не отключает ли её SEO-плагин или тема.
Как задать canonical для записей и страниц вручную
Если нужно изменить canonical только для отдельных записей или страниц, самый надёжный способ — вывести свой тег через wp_head. Делать это лучше в дочерней теме или в небольшом функциональном плагине, а не в файле основной темы: обновление темы не должно стирать правки.
Перед изменениями сделайте резервную копию и проверьте сайт на тестовой копии, если она есть. Ошибка в логике canonical обычно не ломает сайт, но может быстро испортить индексацию.
Пример: для конкретной записи canonical должен указывать на чистый URL без параметров. Код можно добавить в functions.php дочерней темы:
add_action( 'wp_head', function () {
if ( is_singular( 'post' ) ) {
$canonical = get_permalink();
echo '<link rel="canonical" href="' . esc_url( $canonical ) . '" />' . "\n";
}
}, 1 );Здесь get_permalink() берёт основной адрес записи, а esc_url() безопасно выводит его в HTML. Если на сайте уже есть canonical от ядра или SEO-плагина, не нужно выводить второй такой же тег: у страницы должен быть один canonical. В противном случае поисковик может проигнорировать оба.
Если canonical нужен только для отдельных страниц, добавьте более точное условие, например по ID или шаблону страницы. Это лучше, чем пытаться переопределить всё подряд.
Canonical для архивов, пагинации и страниц с параметрами
На архивах и страницах с параметрами важно не перепутать основную версию и служебные варианты. Здесь логика зависит от задачи.
Архивы рубрик, меток и авторов
Для архивов canonical обычно должен указывать на сам архив без лишних параметров. Если пользователь открыл рубрику с UTM-метками, canonical всё равно должен вести на чистый адрес рубрики. Это помогает не плодить дубли из-за рекламных или аналитических параметров.
Если архивы на сайте не нужны для индексации, одного canonical мало: тогда обычно дополнительно ограничивают индексацию через noindex. Но это уже отдельная задача, и смешивать её с canonical не стоит. Canonical говорит о предпочтительном URL, а не о запрете индексации.
Пагинация
Для страниц пагинации canonical чаще всего должен указывать на саму текущую страницу пагинации, а не на первую страницу архива. Это важно, если на второй, третьей и следующих страницах есть уникальные товары, записи или элементы списка. Если же пагинация техническая и не несёт самостоятельной ценности, иногда канонизируют первую страницу, но это решение нужно принимать аккуратно: не для всех сайтов оно подходит.
В WordPress пагинация архивов обычно уже обрабатывается корректно ядром или SEO-плагином. Если canonical на страницах /page/2/ и дальше задан неправильно, сначала проверьте настройки плагина, а уже потом пишите собственную логику.
Страницы с параметрами
Самый частый случай — URL с параметрами сортировки, фильтрации и меток кампаний. Если содержимое страницы не меняется по смыслу, canonical должен указывать на чистый URL без параметров. Например, адрес /catalog/?sort=price может иметь canonical /catalog/.
Если же параметр реально меняет содержимое страницы и создаёт отдельную полезную версию, canonical на чистый URL может быть неверным. В таких случаях сначала оценивают, является ли параметр частью основной структуры сайта или это только техническая надстройка.
Как проверить, что canonical работает правильно
После настройки не ограничивайтесь визуальной проверкой страницы в браузере. Откройте исходный код и найдите тег canonical. Он должен:
- быть один на странице;
- указывать на абсолютный URL;
- вести на основную версию страницы без лишних параметров;
- совпадать с тем адресом, который вы считаете главным для индексации.
Полезно проверить несколько типов страниц: обычную запись, страницу, архив рубрики, пагинацию и URL с параметром. Если на одном из них canonical отличается от ожидаемого, ищите источник в теме, SEO-плагине или в собственном коде.
Ещё один практичный способ — открыть страницу с параметром и сравнить canonical с чистым адресом. Если canonical по-прежнему содержит лишние параметры, значит, где-то в шаблоне формируется неправильный URL или плагин переопределяет вывод.
Что чаще всего ломает canonical в WordPress
На практике проблемы почти всегда сводятся к нескольким вещам:
- тема выводит свой canonical поверх штатного;
- SEO-плагин и код в теме одновременно добавляют один и тот же тег;
- в canonical попадают параметры сортировки, фильтра или UTM;
- для архивов и пагинации используется одна и та же логика без учёта типа страницы;
- после смены домена или перехода на HTTPS canonical продолжает указывать на старый адрес.
Если canonical ведёт на несуществующий URL, это уже не просто косметическая ошибка. Поисковик может проигнорировать подсказку, а в худшем случае начать считать основным не тот адрес. Поэтому после любых изменений структуры сайта стоит пройтись по ключевым страницам и перепроверить canonical вручную.
Когда лучше не писать код, а использовать готовую настройку
Если сайт уже работает на SEO-плагине, сначала проверьте его возможности. Во многих случаях canonical на записях и архивах настраивается штатно, без правки шаблонов. Это безопаснее, чем дописывать собственный код, особенно если сайт поддерживает не один разработчик.
Если же нужна точечная логика для фильтров, параметров или нестандартных архивов, ручной код даёт больше контроля. Но и здесь лучше держать решение в одном месте: либо в плагине, либо в дочерней теме. Когда canonical размазан по нескольким файлам, отладка становится лишне сложной.
Если вам нужен именно инструмент для удаления технических дублей и чистки SEO-настроек на WordPress, можно посмотреть Clearfy Pro. Но в любом случае сначала проверьте, не решает ли задачу уже установленный SEO-плагин или сама тема.
В итоге рабочая схема простая: определите, где у вас появляются дубли, убедитесь, что на странице есть один canonical, и направьте его на основную версию URL. Для записей и страниц это обычно делается штатно, для архивов и параметров — через аккуратную донастройку. Если canonical совпадает с тем адресом, который вы хотите видеть в индексе, задача выполнена.