Как настроить canonical в WordPress

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

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

Когда canonical нужен, а когда он не решает проблему

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

страница открывается с параметрами вроде ?utm_source=, ?sort=, ?filter=;
один и тот же материал доступен по нескольким путям из-за настроек темы или плагина;
есть пагинация архивов, категорий или списка записей;
фильтры и сортировка создают почти одинаковые страницы;
страница доступна и со слешем, и без него из-за ошибок настройки сервера или редиректов.

Canonical не заменяет редирект. Если у вас есть явные дубли, которые не должны открываться пользователю, сначала лучше настроить 301-редирект на основную версию. Canonical — это подсказка для поисковика, а не жёсткое правило. Если обе версии продолжают отдавать 200 OK, поисковик может всё равно выбрать не ту страницу, особенно если на сайте есть внутренние ссылки на разные адреса.

Ещё один важный момент: canonical не должен использоваться для маскировки разных по смыслу страниц. Если у страниц разный контент, разные товары, разные статьи или разные посадочные, у каждой должен быть свой canonical на саму себя, а не на «похожую» страницу.

Как WordPress обычно выводит canonical

В современных версиях WordPress canonical для обычных записей, страниц, архивов и таксономий часто формируется автоматически ядром через функцию rel_canonical(). Во многих случаях этого достаточно, если тема не вмешивается в вывод head и не отключает стандартные действия WordPress.

Но на практике проблемы появляются в трёх ситуациях:

тема вручную выводит свой canonical и дублирует стандартный;
SEO-плагин подменяет canonical, но делает это не для всех типов страниц;
на странице есть нестандартная логика: фильтры, AJAX-подгрузка, кастомные архивы, отдельные шаблоны.

Поэтому настройка canonical в WordPress — это не только «включить в плагине», а ещё и проверить, какой именно тег реально попадает в HTML.

Как проверить canonical на странице

Проверка нужна до любых правок и после них. Самый простой способ — открыть исходный код страницы и найти строку с rel="canonical". В браузере это обычно делается через просмотр исходника страницы, а не через инспектор DOM, потому что canonical должен присутствовать именно в исходном HTML.

Что нужно проверить:

canonical есть только один раз;
адрес в нём совпадает с основной версией страницы;
протокол правильный — https, если сайт работает по HTTPS;
нет лишних параметров, если они не нужны;
canonical не указывает на другую страницу без причины.

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

Для быстрой проверки после изменений удобно сравнить исходный код и фактический URL в адресной строке. Если canonical указывает на другой адрес, а страница открыта по текущему URL, это не всегда ошибка. Ошибка начинается тогда, когда canonical ведёт не на ту версию, которую вы хотите считать основной.

Как настроить canonical в WordPress без конфликтов

Если у вас обычный сайт на WordPress без сложной фильтрации, чаще всего достаточно убедиться, что:

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

Если canonical нужно задать вручную в коде, обычно это делают через фильтр get_canonical_url. Он позволяет изменить адрес, который WordPress считает каноническим для конкретной страницы. Такой подход имеет смысл только если вы понимаете, почему стандартный адрес неверный. Например, для нестандартного шаблона или кастомного архива.

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

add_filter( 'get_canonical_url', function( $canonical, $post ) {
    if ( $post instanceof WP_Post && (int) $post->ID === 123 ) {
        return home_url( '/osnovnaya-stranica/' );
    }

    return $canonical;
}, 10, 2 );

Такой код нужно использовать осторожно. Если поставить неверный URL, поисковик начнёт считать основной совсем другую страницу. Перед правкой сделайте резервную копию и проверьте, что ID записи и целевой адрес указаны верно.

Пагинация: как не сломать canonical на страницах 2, 3 и дальше

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

Практически это выглядит так:

страница категории 1 должна иметь canonical на саму себя;
страница категории 2 должна иметь canonical на себя, а не на первую страницу, если она доступна пользователю и индексируется;
не нужно склеивать все страницы пагинации в один canonical на первую, если вы хотите, чтобы поисковик понимал структуру архива.

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

Проверяйте пагинацию отдельно: откройте страницу 2 или 3 и посмотрите, какой canonical выводится в head. Если он указывает на первую страницу без веской причины, это нужно исправлять в теме или SEO-плагине.

Фильтры, сортировка и параметры URL: что делать с похожими страницами

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

Здесь есть три рабочих сценария:

Параметр не создаёт отдельную ценную страницу. Тогда canonical должен вести на чистый URL без параметра. Например, ?utm_source= и похожие рекламные параметры обычно не должны менять canonical.
Параметр меняет только сортировку или представление. В этом случае canonical чаще всего тоже ведёт на базовую страницу без параметров, чтобы не плодить дубли.
Параметр создаёт самостоятельную посадочную страницу. Тогда такой URL может иметь собственный canonical на себя, если контент действительно уникален и вы хотите его индексировать.

Если фильтры реализованы через GET-параметры, не пытайтесь решать всё одним правилом для всех случаев. Например, параметры ?sort= и ?page= ведут себя по-разному. Сортировка обычно не должна создавать отдельную каноническую страницу, а пагинация — это отдельный контентный слой, который нельзя бездумно склеивать с первой страницей.

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

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

После настройки проверьте не только HTML, но и поведение сайта в поиске. Полезно пройтись по такому чек-листу:

у основной страницы canonical указывает на неё саму;
у параметрических URL canonical указывает на чистую версию, если это задумано;
у пагинации canonical не ломает структуру архива;
в исходном коде нет двух тегов canonical;
редиректы не конфликтуют с canonical;
внутренние ссылки ведут на основную версию URL.

Если Google Search Console уже подключена, посмотрите отчёты по индексированию и проверку URL. Там можно увидеть, какую страницу поисковик считает канонической. Это особенно полезно, когда вы уверены, что на странице всё настроено правильно, а поисковик всё равно выбирает другой адрес. В таком случае проблема часто не в одном теге, а в совокупности сигналов: внутренних ссылках, редиректах, sitemap и дублирующемся контенте.

Типичные ошибки, из-за которых поисковик выбирает не ту версию

На практике чаще всего мешают не сложные баги, а простые несостыковки:

canonical указывает на URL с http вместо https;
на странице есть и ручной canonical из темы, и автоматический от WordPress или SEO-плагина;
в canonical попадают параметры, которые не должны там быть;
страница открывается по одному адресу, а внутренние ссылки ведут на другой;
пагинация склеена с первой страницей без учёта реальной структуры архива;
фильтры создают слишком много похожих URL без понятной логики.

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

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

}