Если в WordPress одна и та же страница открывается по нескольким адресам, поисковик может считать это дублями. Чаще всего проблема возникает у записей, архивов, пагинации, фильтров и страниц с параметрами в URL. В таких случаях помогает canonical-ссылка: она подсказывает поисковым системам, какой адрес считать основным.
Canonical не удаляет дубли и не закрывает их от индексации. Он нужен, когда страницы должны оставаться доступными для пользователей, но в поиске должен ранжироваться один основной URL. Это как раз тот случай, когда не хочется ничего ломать на сайте, а нужно аккуратно навести порядок в индексации.
Когда canonical действительно нужен
Ставить canonical имеет смысл не на каждый URL подряд, а только там, где есть осмысленная основная версия страницы. В WordPress это обычно такие ситуации:
- запись открывается по нескольким адресам из-за параметров UTM, сортировки или трекинга;
- архив категории доступен и без пагинации, и на страницах
/page/2/,/page/3/и так далее; - страница товара или записи может открываться через разные пути навигации, но контент один и тот же;
- фильтры и параметры в URL меняют только способ просмотра, а не саму сущность страницы;
- есть отдельные версии для печати, предпросмотра или сортировки, которые не должны конкурировать с основной страницей.
Если же страницы реально разные по смыслу и содержанию, canonical на одну из них ставить не нужно. Например, у двух статей с разными текстами не должно быть одинакового canonical только потому, что у них похожие заголовки.
Как WordPress обычно формирует canonical
В современных версиях WordPress canonical для обычных записей, страниц и архивов часто добавляется автоматически через ядро и тему. Если тема не вмешивается в вывод <head>, на странице можно увидеть тег <link rel="canonical" ...> с основным URL.
Но на практике этого не всегда достаточно. Проблемы появляются, когда:
- SEO-плагин переопределяет canonical;
- тема выводит несколько одинаковых тегов;
- на страницах с параметрами canonical указывает на текущий URL с query string, хотя нужен чистый адрес;
- для архивов или кастомных типов записей canonical формируется не так, как ожидается.
Поэтому сначала стоит проверить, какой canonical уже есть на странице, а потом решать, нужно ли его менять.
Как проверить текущий canonical
Откройте нужную страницу в браузере и посмотрите исходный код. Проще всего использовать поиск по странице и найти canonical. В корректной разметке должен быть один тег, например:
<link rel="canonical" href="https://example.com/sample-page/" />Если тегов несколько, это уже повод искать конфликт между темой, SEO-плагином и кастомным кодом. Если canonical отсутствует совсем, поисковик будет ориентироваться на собственное понимание основной версии, а это не лучший сценарий при наличии дублей.
Дополнительно полезно проверить страницу через инструменты для вебмастеров поисковой системы: там обычно видно, какой URL выбран каноническим и совпадает ли он с тем, что вы ожидали.
Как задать canonical для записи, страницы или архива
Самый безопасный способ — не править шаблоны напрямую, а использовать фильтр WordPress, который меняет canonical на уровне вывода. Для этого подходит wp_get_canonical_url и фильтр get_canonical_url. Такой вариант удобен, если нужно задать правило для конкретного типа страниц.
Например, если вы хотите принудительно указать canonical для конкретной записи или страницы, можно добавить код в functions.php дочерней темы или в собственный мини-плагин:
add_filter( 'get_canonical_url', function( $canonical, $post ) {
if ( ! $post instanceof WP_Post ) {
return $canonical;
}
if ( (int) $post->ID === 123 ) {
return home_url( '/osnovnaya-stranitsa/' );
}
return $canonical;
}, 10, 2 );Здесь 123 — ID записи, а /osnovnaya-stranitsa/ — адрес, который должен считаться основным. Такой подход уместен, когда одна и та же сущность доступна по нескольким URL, но вы хотите явно закрепить один из них.
Если canonical нужен для архива, логика будет другой: чаще всего каноническим должен быть сам архив без параметров. В этом случае важно не подменять адрес на произвольную страницу, а убрать из canonical лишние query string и оставить чистый URL архива.
Что делать со страницами с параметрами
Параметры в URL — самый частый источник дублей. Это могут быть ?utm_source=, ?sort=, ?filter=, ?page= и другие значения. Если параметр не меняет сущность страницы, canonical должен указывать на чистый URL без параметров.
Например, адрес https://example.com/catalog/?sort=price обычно должен иметь canonical на https://example.com/catalog/, если сортировка не создаёт отдельную самостоятельную страницу. То же самое относится к UTM-меткам: они полезны для аналитики, но не должны становиться основной версией страницы.
Для таких случаев часто достаточно корректной настройки SEO-плагина, потому что многие из них умеют очищать canonical от параметров автоматически. Если же плагин этого не делает, придётся вмешаться кодом и вернуть нужный адрес вручную.
Когда параметр нельзя просто выкинуть из canonical
Есть и обратные ситуации. Если параметр реально меняет содержимое страницы и вы хотите, чтобы такая версия индексировалась отдельно, canonical на чистый URL будет ошибкой. Например, это может касаться отдельных посадочных страниц фильтра, если они создаются как полноценные SEO-страницы с уникальным контентом. Тогда canonical должен указывать на саму эту версию, а не на общий каталог.
Здесь важно не путать технический параметр и отдельную страницу. Если URL с параметром — это просто способ сортировки или фильтрации, canonical ведёт на основную страницу. Если это самостоятельная страница с уникальным смыслом, canonical остаётся сам на себя.
Как не сломать canonical в WordPress
Самая частая ошибка — пытаться решить проблему дублей сразу несколькими способами. Например, SEO-плагин уже выводит canonical, а в теме добавляют ещё один тег вручную. В результате поисковик видит конфликтующие сигналы.
Ещё одна типичная проблема — путаница между canonical и редиректом. Canonical не перенаправляет пользователя, а только подсказывает поисковику предпочтительный адрес. Если нужно полностью убрать дубль из обращения, тогда уже смотрят в сторону 301-редиректа. Но это другой инструмент и другая задача.
Перед изменениями лучше проверить три вещи:
- какой canonical уже выводится сейчас;
- не добавляет ли его SEO-плагин;
- нет ли в теме собственного кода, который меняет
<head>.
Если вы редактируете functions.php, делайте это в дочерней теме или через отдельный плагин. Иначе после обновления темы настройка пропадёт.
Как проверить, что настройка сработала
После правки откройте страницу снова и убедитесь, что в исходном коде остался один тег canonical и он указывает на нужный URL. Для страниц с параметрами проверьте, что canonical ведёт на чистый адрес без лишних query string. Для архивов — что канонический адрес совпадает с основным адресом архива, а не с внутренней страницей пагинации, если это не требуется по вашей логике.
Если используете поисковую консоль, отправьте страницу на повторную проверку после обновления. Не ждите мгновенного эффекта: поисковик может переоценивать канонический адрес не сразу, особенно если дублей много и они давно в индексе.
На практике canonical в WordPress работает лучше всего как часть общей чистки дублей: один основной URL для каждой сущности, аккуратная работа с параметрами и отсутствие конфликтов между темой и SEO-плагином. Если настроить это один раз внимательно, сайт остаётся доступным для пользователей, а поисковику становится проще понять, какую страницу показывать в выдаче.