Canonical: настройка и проверка

Canonical связывает версии одного материала

rel="canonical" сообщает поисковой системе, какой адрес вы предпочитаете считать основным среди дублей или очень похожих документов. Посетитель при этом остаётся на открытой странице: адресная строка не меняется. Указание помогает поиску разобраться с версиями, но не гарантирует ни выбор нужного URL, ни высокие позиции.

Представьте страницу услуги /services/audit/ и тот же материал с рекламной меткой ?utm_source=newsletter. Для посетителя содержание одинаковое, а адреса различаются. Можно оставить оба доступными и обозначить чистый URL как предпочтительный. Другой случай — две разные услуги, у которых совпадает дизайн. Общий шаблон ещё не делает их дублями: у каждой могут быть собственные задачи, условия и аудитория.

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

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

Сначала решите, какие страницы действительно эквивалентны

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

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

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

Canonical, редирект, noindex и Clean-param решают разные задачи

Например, параметр рекламной кампании и параметр выбранной модели товара нельзя автоматически обрабатывать одинаково. Один может менять только учёт источника перехода, другой — сам документ. Перед массовым правилом проверьте реальные ответы сайта на нескольких значениях.

Справка Яндекса по Clean-param объясняет синтаксис и область действия директивы. Не переносите это правило на Google и не перечисляйте в нём полезные параметры без проверки. Общие ограничения обхода разобраны в руководстве по robots.txt.

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

Как выглядит канонический адрес в HTML и заголовке ответа

Для HTML-страницы указание размещают внутри <head>. В учебном примере основная страница услуги находится по адресу https://example.com/services/audit/. На её доступном дубле с рекламной меткой можно указать:

<link rel="canonical" href="https://example.com/services/audit/">

На самой основной странице тот же адрес означает ссылку на себя — self-referencing canonical. Используйте полный URL с правильным протоколом и доменом. Не добавляйте к нему якорь #section и проверьте завершающий слеш: указанный вариант должен открываться напрямую, без промежуточного перенаправления.

В документ вроде PDF нельзя вставить HTML-тег таким же способом. Если у файла есть равнозначные копии, сервер может передать отношение через HTTP-заголовок. Например, ответ по адресу копии PDF может содержать:

Link: <https://example.com/docs/audit-guide.pdf>; rel="canonical"

Этот заголовок настраивают в ответе сервера, а не печатают в тексте файла. Google описывает оба способа в инструкции по указанию основного URL. Практически удобнее определить один источник настройки и контролировать результат, чем независимо добавлять её сразу в тему, плагин и сервер.

Пример для WordPress с Yoast SEO

Сначала выясните, что уже формирует canonical: CMS, SEO-плагин, тема или собственный модуль. Отсутствие заполненного поля в редакторе не означает, что тега нет на сайте. Не добавляйте ручную строку поверх работающего автоматического вывода.

1. Откройте нужную страницу или запись в WordPress.
2. В панели Yoast SEO перейдите в раздел Advanced / «Дополнительно».
3. Если для этой страницы нужен другой основной адрес, укажите полный URL в поле Canonical URL.
4. Сохраните страницу и откройте её публичный адрес без авторизации.
5. Проверьте готовый HTML и целевой документ, а не только сохранённое значение поля.

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

После обновления очистите только нужные кеши и проверьте несколько страниц: обычную, с параметром, архив и страницу пагинации. Если исправление видно администратору, но не посетителю, сравните выдаваемые версии. Это повод проверить кеширование и условия шаблона, а не повторно нажимать «Сохранить».

Посмотрите исходный HTML, итоговый документ и ответ сервера

Откройте точный проверяемый адрес и зафиксируйте, куда он привёл после загрузки. Через «Просмотр кода страницы» найдите элементы link с rel="canonical". Запишите значения href. Просто подсчитать вхождения слова canonical недостаточно: оно может встречаться в статье, скрипте или комментарии и не быть действующей разметкой.

Затем откройте инструменты разработчика браузера, вкладку Elements / «Элементы», и сравните содержимое head после выполнения JavaScript. Google допускает установку canonical скриптом, но рекомендует не менять уже заданный адрес на другой. Детали — в документации по JavaScript SEO.

Во вкладке Network / «Сеть» перезагрузите страницу, выберите запрос самого документа и откройте Response Headers / «Заголовки ответа». Найдите заголовок Link, если он есть. HTML и заголовок не должны указывать разные основные адреса. Далее откройте саму цель и повторите проверку для неё.

• Адрес цели совпадает с утверждённым правилом.
• Документ доступен и содержит ожидаемый материал.
• Нет неожиданного перехода на другой URL.
• Цель не закрыта от индексирования.
• Нет цепочки A → B → C или цикла A → B → A.

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

Сравните заявленный адрес с выбором Google

В Search Console выберите нужный ресурс и вставьте полный URL в инструмент проверки. Откройте сведения об индексировании и найдите канонический адрес, указанный пользователем, и адрес, выбранный Google. Если данных ещё нет, зафиксируйте это как отсутствие сведений, а не как успешную настройку.

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

Если Google выбрал другую страницу, проверьте оба документа. Возможно, они действительно почти одинаковые; возможно, основной материал отдал неполный ответ, оказался недоступен или получил противоречивые сигналы. Не меняйте canonical туда и обратно только ради совпадения строк отчёта.

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

Что проверить при статусе «Неканоническая»

В Яндекс Вебмастере откройте «Индексирование → Страницы в поиске» и список исключённых страниц. Найдите нужный URL и причину. Статус «Неканоническая» описан в справке отчёта: страница обработана по каноническому адресу, указанному в её разметке.

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

У поисковиков есть различия. В правилах Яндекса указано ограничение для canonical на другой домен или поддомен. Там же перечислены причины игнорирования: недоступная цель, существенно различающийся контент, несколько адресов и цепочки. Для переезда между HTTP и HTTPS нужно отдельно настраивать перенаправление, а не рассчитывать только на этот тег.

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

Пагинация, фильтры и переводы требуют отдельных правил

Пагинация. Если /catalog/?page=2 показывает следующий набор товаров, не делайте первую страницу каталога её канонической версией. Google рекомендует собственные адреса и canonical для страниц последовательности; см. правила пагинации. Оставьте доступные ссылки между частями каталога и на товары. Один неверный тег не доказывает, что все товары исчезли из индекса: это проверяют по конкретным URL.

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

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

Языки. Перевод не нужно автоматически канонизировать на оригинал другого языка. Для связи языковых версий используют hreflang; canonical и языковая разметка должны быть согласованы. Практические ошибки таких связей разобраны в документации Google по диагностике.

Исправляйте правило, которое создаёт неверный адрес

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

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

Как собрать отчёт в Screaming Frog

Для большого сайта используйте Screaming Frog SEO Spider. В настройках Spider → Crawl проверьте сбор и обход canonical, затем укажите адрес сайта в поле Enter URL to spider и запустите Start. После завершения откройте вкладку Canonicals. Порядок и отчёты описаны в инструкции разработчика.

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

Краулер показывает, что отдал сайт, и не подтверждает выбор поисковой системы. Сверьте важные примеры с кабинетами вебмастеров. Добавьте в проверку адреса из CMS и Sitemap: обход по ссылкам может не найти страницу, на которую никто не ссылается.

В итоговом журнале храните исходный URL, ожидаемую цель, HTML-canonical, HTTP-canonical, код ответа цели, запреты индексирования, выбранный Google адрес, статус Яндекса и дату проверки. Пустое поле обозначайте «нет данных». Оно не равно положительному результату.

Проверьте изменение на одной группе и только затем расширяйте

Учебный пример: у сайта 90 страниц услуг и 30 доступных вариантов с рекламными параметрами. Во время проверки обнаружили, что 12 самостоятельных услуг получили canonical на общий раздел. Это не 42 одинаковые ошибки: варианты с параметрами могут соответствовать правилам, а 12 услуг требуют отдельного разбора.

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

1. Подтвердите, что HTML и заголовки содержат нужный результат.
2. Проверьте доступность и содержание целевой страницы.
3. Согласуйте внутренние ссылки и Sitemap с выбранными адресами.
4. Повторите массовый обход по сохранённому списку.
5. Зафиксируйте дату релиза и отправьте важные изменения на переобход.
6. Позже сравните поисковые сведения с новыми датами обхода.

Разделяйте завершение технического исправления и обновление поиска. Ни рост трафика, ни срок выбора основного URL нельзя гарантировать одной правкой. Полный порядок наблюдения описан в руководстве по проверке индексации.

Что должно остаться после работы

• Карта типов страниц и правил выбора основного адреса.
• Список проверенных URL, включая параметры и пагинацию.
• Подтверждение фактического вывода после публикации.
• Доступные целевые документы без конфликтующих ограничений.
• Согласованные внутренние ссылки и XML-карта сайта.
• Отдельные результаты Google и Яндекса с датами.
• Список исключений, по которым решение ещё не принято.
• Проверка после обновления темы, CMS и переноса сайта.

Включите эти результаты в приёмку сайта у разработчика. Задача не закрывается фразой «теги расставлены»: владелец должен понимать, какие страницы остаются самостоятельными и как проверено правило.

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

Частые вопросы о canonical