Как правильно выбирать canonical для страниц сайта

Сначала установите, действительно ли это дубли

Одна услуга может открываться по нескольким техническим адресам, а две разные услуги — иметь похожие формулировки. В первом случае нужна работа с дублями, во втором — ясное различие содержания. Начните со сравнения результата страницы, состава данных и задачи посетителя. Общий корень в ключевом запросе не делает материалы эквивалентными.

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

Выберите целевой адрес по назначению

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

Согласуйте связанные сигналы

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

Не используйте robots.txt и noindex как взаимозаменяемые способы назначения canonical. Они решают другие задачи и могут мешать поиску обработать нужные сведения. Различия разобраны в статье о robots, noindex и sitemap. Для каждого изменения сформулируйте цель: объединить дубли, ограничить обход или исключить содержание.

Не канонизируйте все страницы раздела на первую

У страницы второй части каталога другой набор элементов. Если она нужна для доступа к материалам, её нельзя автоматически объявить копией первой только ради одного короткого адреса. Аналогично отдельный фильтр может быть самостоятельной посадочной или технической комбинацией — решение зависит от содержания и плана структуры.

Для переводов canonical не заменяет hreflang. Языковые версии требуют согласованных связей и проверки соответствия, рассмотренных в материале о многоязычном сайте. Отдельные темы блога тоже не следует скрывать одной канонизацией, если реальная проблема — повторяющийся текст. В таком случае сначала исправляют редакционную структуру.

Проверьте реализацию на ответе страницы

Посмотрите, какое значение получает посетитель и робот, а не только поле в CMS. Проверьте разные шаблоны, параметры, мобильный рендеринг и переходы между страницами приложения. Если адрес формируется динамически, убедитесь, что он обновляется вместе с материалом и не остаётся от предыдущего маршрута. Случайная общая настройка может затронуть весь сайт.

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

Учебный пример параметров

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

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

Что сохранить в документации

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

Пример конфликта canonical и внутренних ссылок

Учебная статья имеет основной адрес A и технический вариант B с параметром кампании. В исходном HTML варианта B указан canonical на A. После запуска приложения он меняется на главную, а карточки в блоге продолжают ссылаться на B. В этой ситуации найден не один изолированный тег, а несколько несогласованных сигналов.

По документации Google, canonical и редирект являются сильными сигналами выбора, включение в sitemap — более слабым. Противоречащие значения не нужно рассматривать как полезное «усиление». Google рекомендует согласовывать сигналы и не менять заданный в HTML canonical на другой адрес через JavaScript.

После исправления сохраните исходный ответ и документ после перехода из другой статьи. Для A ожидается значение A; для B — та же согласованная цель A. Отдельно проверьте материал C, чтобы исправление не превратилось в общий canonical для всех страниц. Это техническая проверка реализации, а не подтверждение выбора поисковика.

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