Canonical: как указать канонический URL и убрать дубли

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

Ниже — выбор адреса, рабочий синтаксис для HTML и файлов, обработка фильтров и проверка результата. Если вы только собираете проект, сначала зафиксируйте структуру адресов: в инструкции о том, как создать сайт, разобраны базовые варианты платформ, а здесь мы занимаемся уже существующими дублями.

Что такое canonical и какие дубли он объединяет

Канонический URL — адрес, который владелец сайта предлагает поисковой системе считать основной версией страницы. Остальные URL из группы дублей могут обходиться роботом, но в поиске система старается показывать выбранную каноническую страницу и объединять с ней часть сигналов.

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

Это не запрет индексации и не средство скрыть страницу. Google прямо называет canonical сильным сигналом, однако оставляет за алгоритмом окончательный выбор. Справка Яндекс Вебмастера также описывает указание как рекомендацию: робот вправе его не учесть, если страницы заметно различаются или основной адрес недоступен.

У canonical своя работа. Микроразметка описывает сущности на странице, но не выбирает главный URL; её синтаксис и поддержку поисковиков смотрите в материале про Schema.org. И сама каноникализация не делает страницу полезнее для нейроответов: для этого нужны доступность, ясный ответ и подтверждённые факты, как в разборе GEO-продвижения.

Как выбрать канонический URL

Выбирайте адрес, который сохранится надолго и который вы готовы показывать людям во внутренних ссылках, рекламе и поисковой выдаче. Он должен отдавать содержательный ответ с кодом 200 OK, быть доступен роботу, не содержать временных параметров и не вести дальше по редиректу.

1. Соберите группу дублей. Откройте чистый адрес, варианты с параметрами, слешем, другим регистром, HTTP, HTTPS, www и без www.
2. Сравните содержимое. Заголовок, основной текст, товар, цена и назначение должны совпадать либо отличаться несущественно.
3. Выберите устойчивую версию. Обычно это HTTPS-адрес без аналитических и сессионных параметров, в принятом на сайте формате со слешем или без него.
4. Проверьте доступность. Основной URL возвращает 200 OK, разрешён для обхода и индексации, не требует входа и не перенаправляет робота.
5. Согласуйте сигналы. С дублей укажите выбранный URL, на нём поставьте self-canonical, а внутренние ссылки ведите сразу на него.

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

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

Как поставить rel=canonical в head и HTTP Link

Для HTML-страницы добавьте элемент link внутрь head. Рабочая запись выглядит так:

<link rel="canonical" href="https://example.ru/catalog/drill/">

Элемент должен находиться в исходном или корректно отрендеренном head. Запись в body поисковик может не принять. На каждом URL оставляйте одно ясное указание. Если шаблон CMS уже выводит canonical, исправьте его настройку вместо добавления второго тега.

Для PDF, DOCX и другого не-HTML-документа используйте заголовок HTTP-ответа:

Link: <https://example.ru/guides/drill.pdf>; rel="canonical"

Документация Google Search Central поддерживает оба способа и советует выбрать один: одновременная настройка HTML и HTTP повышает риск отдать разные адреса. Яндекс также описывает HTML и HTTP Link, в том числе пример для PDF.

Проверяйте именно ответ нужного URL. Команда curl -I 'https://example.ru/file.pdf?download=1' покажет HTTP-заголовки, а просмотр исходного кода — серверный HTML. Инспектор браузера полезен для страницы после JavaScript, но сначала убедитесь, что исходный ответ не содержит другого canonical.

Если CMS автоматически генерирует метаданные, изменение темы или SEO-плагина может задеть canonical вместе с title и description. Отделить технические поля от видимого текста помогает обзор сервисов проверки текста: орфографическая проверка не заменяет просмотр исходного кода и HTTP-ответа.

Зачем нужны абсолютный URL и self-canonical

В href указывайте полный адрес: протокол, домен и путь. Например, https://example.ru/catalog/drill/, а не /catalog/drill/. Google рекомендует абсолютные URL, а Яндекс прямо приводит абсолютный путь как требование. Так разметка не зависит от базового адреса документа, зеркала, тестового домена или ошибки в теге base.

Self-canonical — canonical страницы на саму себя. На https://example.ru/catalog/drill/ он указывает тот же адрес. Такая запись допустима у Google и Яндекса и фиксирует предпочитаемую форму URL: HTTPS, вариант домена, регистр и наличие слеша.

Self-canonical особенно полезен, когда к любой странице можно добавить UTM или иной служебный параметр. Чистая версия подтверждает собственный статус, а параметрические копии ссылаются на неё. Генерируйте значение из нормализованного публичного адреса, а не из полного текущего запроса: иначе страница с ?utm_source=max объявит канонической саму себя.

• На основном URL canonical совпадает с адресом страницы.
• На дубле canonical ведёт прямо на основной URL.
• В адресе нет UTM, якоря #section и идентификатора сессии.
• Выбран единый протокол, домен, регистр и формат слеша.
• Адрес открывается без цепочки перенаправлений.

UTM нужны аналитике, поэтому удалять их из рекламных ссылок ради canonical не требуется. Как составлять метки и читать переходы, разобрано в инструкции про UTM-метки и короткие ссылки. На целевой странице метка остаётся в адресной строке, а canonical указывает на чистую версию.

Как обрабатывать параметры, сортировки и фильтры

Сначала разделите параметры по смыслу. Аналитическая метка или порядок сортировки часто не создают новую поисковую страницу. Фильтр «аккумуляторные дрели» меняет ассортимент и может отвечать на отдельный спрос. Если отправить оба варианта на категорию «Дрели», полезная посадочная страница фильтра потеряет шанс участвовать в поиске.

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

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

Что делать с HTTP, HTTPS, www и разными доменами

Для вариантов HTTP/HTTPS и www/без www выберите один основной формат. Внутренние ссылки, canonical и адреса в шаблонах должны совпадать с ним. Если альтернативная версия больше не нужна людям, настройте прямое серверное перенаправление на соответствующую основную страницу. Canonical можно оставить как согласующий сигнал на конечных HTML-страницах, но он не заменяет переход пользователя.

Для Яндекса переход с HTTP на HTTPS проводят редиректом: его справка отдельно указывает, что rel="canonical" для такого переезда не поддерживается. Google также считает редирект сильным сигналом каноникализации. Здесь достаточно границы: один старый URL должен вести сразу на парный новый URL, без цепочки через www, HTTP и промежуточный путь.

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

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

Как ставить canonical на страницах пагинации

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

Базовый вариант — self-canonical на каждой доступной странице серии: /catalog/ указывает на себя, /catalog/?page=2 — на себя. Навигация должна давать обычные ссылки между страницами, чтобы робот мог дойти до глубоких товаров. Если есть полноценная страница «Показать все», её можно рассматривать отдельно только когда она быстро загружается и действительно содержит весь набор.

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

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

Как проверить canonical в Google и Яндексе

Сначала проведите техническую проверку без ожидания переобхода. Откройте основной URL и два-три дубля, посмотрите код ответа, HTML или HTTP Link, доступность для робота и конечный адрес редиректа. Затем переходите к инструментам поисковиков: они показывают уже известную системе версию и помогают отделить ошибку разметки от ещё не завершившегося обхода.

1. Проверьте дубль в Google Search Console. В инструменте проверки URL откройте блок индексирования страницы и сравните поля user-declared canonical и Google-selected canonical.
2. Проверьте основной URL. Он должен быть доступен, индексирование разрешено, заявленный canonical совпадает с ожидаемым.
3. Запустите live test. Он показывает доступность текущей версии, но, по справке Google, не предсказывает будущий выбор канонического URL.
4. Проверьте URL в Яндекс Вебмастере. Раздел «Индексирование → Проверка страницы» показывает код ответа, доступность и состояние страницы.
5. Посмотрите исключённые страницы. В разделе о страницах в поиске найдите дубль и причину исключения; статус «неканоническая» подтверждает найденное роботом указание.
6. Дождитесь нового обхода. Изменение в шаблоне не меняет индекс мгновенно. После переобхода повторите проверку обеих версий.

Официальная справка URL Inspection предупреждает: Google может выбрать другой адрес, даже когда владелец указал свой. Сравнивайте обе строки, а не только наличие тега. Для Яндекса используйте «Проверку страницы» и сведения об исключённых URL.

Проверяйте не один красивый пример, а выборку: основную страницу, дубль с UTM, сортировку, один полезный фильтр, одну страницу пагинации и старый протокол. Так обнаруживаются ошибки шаблона. Внешнюю заметность сайта рассматривайте отдельно; статья о видимости в поиске посвящена каналу MAX и не заменяет проверку URL сайта в кабинетах вебмастеров.

Почему поисковик игнорирует rel=canonical

Чаще всего заявленный адрес противоречит тому, что видит робот. Canonical ведёт на 404, закрытую страницу или URL с редиректом; дубль заметно полнее основной версии; внутренние ссылки продолжают указывать на параметрический адрес; два модуля выводят разные теги. Алгоритму приходится выбирать документ по совокупности сигналов.

• Несколько canonical. Тема, CMS и плагин выводят по одному тегу. Оставьте единый источник генерации.
• Цепочка. URL A указывает на B, а B — на C. С A и B ставьте прямое указание на окончательный C.
• Canonical на редирект. В href записан старый адрес. Укажите конечную страницу с кодом 200.
• Основная страница закрыта. Робот не может оценить документ и выбирает доступный дубль.
• Слишком разное содержание. Фильтр с другим ассортиментом объявлен дублем общей категории. Пересмотрите сам выбор.
• Динамическая ошибка. JavaScript меняет или добавляет canonical после загрузки, а исходный HTML говорит другое.
• Текущий URL копируется целиком. UTM и sessionid попадают в self-canonical и закрепляют дубли.
• Массовая ссылка на главную. Все карточки заявляют один URL, хотя содержат разные товары.

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

Не оценивайте результат по оператору site: и одному поисковому запросу. Эти наблюдения годятся как подсказка, а выбранный Google canonical смотрите в Search Console, состояние Яндекса — в Вебмастере. Расхождение после свежего обхода означает, что надо искать конфликт сигналов, а не повторно вставлять тот же тег.

Чек-лист