🎧 Прослушать аудио
Подкаст: Cross-domain canonical
Cross-domain canonical нужен, когда одинаковый или почти одинаковый контент доступен на разных доменах, а поисковику нужно показать, какая версия должна считаться основной. Но это не замена 301-редиректу, не способ “склеить всё со всем” и не гарантия передачи всех SEO-сигналов.
Коротко: используйте междоменный canonical только там, где копия действительно похожа на оригинал, обе страницы доступны для обхода, целевой URL отдаёт 200 OK, а редирект невозможен или нежелателен для пользователя.
Что такое cross-domain canonical простыми словами
Обычный canonical помогает выбрать главный URL среди дублей внутри сайта: например, между страницей без параметров и страницей с UTM-метками. Cross-domain canonical делает то же самое, но каноническая страница находится на другом домене.
Пример: статья опубликована на основном сайте, а её копия размещена на партнёрском портале. На копии можно указать canonical на оригинал, чтобы поисковик понял: главной версией вы считаете страницу на основном сайте.
partner-site.ru/article/
main-site.ru/article/
Важно не переоценивать этот тег. Canonical - это сигнал, а не жёсткая команда. Поисковая система может принять его, а может выбрать другой URL, если видит противоречия: разные тексты, закрытую от обхода копию, редирект на целевой странице, конфликт с hreflang, noindex или внутренними ссылками.
Когда междоменный canonical действительно нужен
Главный критерий - у пользователя должна оставаться причина видеть копию, а у поиска должна быть понятная основная версия. Если копия не нужна людям, чаще логичнее использовать 301-редирект.
| Сценарий | Когда уместно | Что проверить |
|---|---|---|
| Переезд между доменами без доступа к серверным редиректам | Временное решение, если 301 пока нельзя настроить | Карта URL 1:1, доступность копий для роботов, отсутствие robots.txt-блокировки |
| Публикация одного материала в сети своих сайтов | Когда страницы должны оставаться доступными пользователям на разных доменах | Одинаковый смысл материала, согласованность внутренних ссылок, self-canonical на оригинале |
| Партнёрские описания товаров или услуг | Когда партнёр согласен указать первоисточник | Не конфликтует ли это с интересами партнёра: он может потерять видимость копии |
| PDF, DOCX или другие файлы-дубли | Когда у файла нет HTML-раздела head | Нужен HTTP-заголовок Link, а не HTML-тег внутри файла |
Когда cross-domain canonical лучше не использовать
Страницы разные по смыслу
Если тексты похожи только частично, но закрывают разные интенты, canonical может навредить. Поисковик может не принять сигнал, а вы запутаете диагностику индексации.
Нужен полный переезд
Если старую страницу больше не нужно показывать пользователям, правильнее делать 301-редирект. Он понятнее и для ботов, и для людей.
Копия закрыта от обхода
Если страница запрещена в robots.txt, поисковик может не увидеть canonical. Нельзя передать сигнал, который робот не смог прочитать.
Вы пытаетесь канонизировать всё на главную
Canonical должен вести на релевантный аналог страницы. Массовая ссылка всех дублей на главную - частая ошибка, которая ломает смысловую карту сайта.
Canonical, 301, noindex, robots.txt и hreflang: что выбрать
Ошибки часто начинаются не в коде, а в выборе инструмента. Canonical, noindex и 301 решают разные задачи. Нельзя выбирать их по принципу “что быстрее вставить”.
| Инструмент | Что делает | Когда выбирать | Риск ошибки |
|---|---|---|---|
| rel=»canonical» | Показывает предпочтительный URL среди похожих страниц | Копии должны оставаться доступными | Может быть проигнорирован, если сигналы противоречат друг другу |
| 301 redirect | Перенаправляет пользователя и бота на новый URL | Старая страница больше не нужна как отдельная | Ошибочная карта редиректов может увести трафик на нерелевантные страницы |
| noindex | Просит не показывать страницу в индексе | Служебные или тонкие страницы, которые не нужны в поиске | Не подходит как способ выбрать каноническую страницу |
| robots.txt | Ограничивает обход, но не гарантирует удаление URL из поиска | Контроль краулинга, а не управление канонизацией | Робот может не увидеть canonical на закрытой странице |
| hreflang | Связывает языковые и региональные версии | Мультиязычные сайты и региональные версии | Конфликт с canonical может нарушить выбор версии в поиске |
Если задача связана не только с canonical, но и с управлением обходом, полезно отдельно проверить логику robots.txt и crawl-delay. Эти инструменты часто путают, хотя они отвечают за разные части индексации.
Как поставить cross-domain canonical в HTML
На странице-копии тег ставится в раздел head. В тело статьи или в визуальный редактор его вставлять нельзя: поисковики могут не учитывать такой вариант.
<link rel="canonical" href="https://main-site.ru/original-page/" />
Что должно быть в норме
- URL абсолютный: с протоколом https и полным доменом.
- На странице только один canonical.
- Целевой URL отдаёт 200 OK и не ведёт в цепочку редиректов.
- Текст копии и оригинала действительно одинаковый или очень близкий по смыслу.
- Копия не закрыта от обхода в robots.txt.
Для WordPress обычно удобнее управлять canonical через SEO-плагин, тему или шаблон. Если сайт сделан на SPA или метаданные формируются JavaScript-ом, проверьте, попадает ли canonical в исходный HTML или корректно отображается в отрендеренной версии. По этой теме полезен отдельный разбор про динамические метатеги title и description на SPA.
Canonical для PDF и других не-HTML файлов
У PDF, DOCX и других файлов нет обычного HTML-раздела head. Поэтому canonical для них указывают через HTTP-заголовок Link.
Link: <https://main-site.ru/original-file.pdf>; rel="canonical"
Это важно, если один и тот же документ доступен по разным адресам или если PDF дублирует HTML-страницу. В таких случаях сначала решите, что должно получать поисковый трафик: HTML-страница, PDF или оба документа с разным назначением.
Если тема актуальна для вашего сайта, посмотрите материал про SEO для PDF-файлов: там логика похожая - важно не просто загрузить документ, а правильно управлять индексацией, ссылками и дублями.
Пошаговая схема внедрения
Соберите пары URL
Для каждой копии найдите конкретный канонический аналог. Не делайте “все страницы на главную”. Нужна карта соответствий 1:1.
Проверьте похожесть контента
Если копия сильно отличается, лучше доработать текст под отдельный интент или использовать другой метод управления индексацией.
Добавьте canonical
HTML-страницы - через link в head. Файлы - через HTTP-заголовок. На оригинале желательно оставить self-referencing canonical.
Согласуйте остальные сигналы
Sitemap, внутренние ссылки, hreflang, редиректы и robots.txt не должны спорить с canonical.
Проверьте после переобхода
Смотрите не только наличие тега в коде, но и то, какую каноническую версию выбрала поисковая система после индексации.
Если внедрение требует правки серверных заголовков, 301-редиректов или конфигурации Nginx/Apache, нужен нормальный доступ к хостингу. Для небольших проектов можно рассмотреть Beget, но сам выбор хостинга не заменяет техническую проверку canonical.
Как проверить, что canonical работает
В коде страницы
Откройте исходный код или используйте краулер. Найдите один тег canonical в head и проверьте, что URL указан без ошибок.
В HTTP-заголовках
Для PDF и других файлов проверьте ответ сервера. Важно увидеть Link-заголовок, а не просто ссылку внутри документа.
В Google Search Console
Через проверку URL смотрите, какой адрес указан пользователем и какой выбран Google. Если они расходятся, ищите противоречивые сигналы.
В Яндекс.Вебмастере
Проверяйте, как Яндекс видит канонический адрес и нет ли дублей. Для Яндекса особенно опасно полагаться только на междоменный canonical без редиректов и чистой структуры.
Типичные ошибки
Красные флаги при аудите
- На странице несколько canonical, и они указывают на разные URL.
- Canonical ведёт на страницу с 404, 500, noindex или длинной цепочкой редиректов.
- В sitemap указана копия, а canonical ведёт на другой домен.
- Внутренние ссылки продолжают вести на неканонические URL.
- hreflang указывает на одну группу URL, а canonical - на другую.
- Копии закрыли в robots.txt, поэтому робот не видит canonical.
- В отчёте обещают “передачу 90-100% веса” без проверки индексации. Это нельзя гарантировать универсально.
Пример плохого и хорошего варианта
Плохой вариант
На старом домене все страницы указывают canonical на главную нового сайта. Часть старых страниц закрыта в robots.txt. В sitemap остаются старые URL. Внутренние ссылки ведут куда попало.
Почему плохо: поисковик получает набор противоречивых сигналов и может выбрать канонические адреса самостоятельно.
Хороший вариант
Для каждой старой страницы есть релевантный новый URL. Копии доступны для обхода. Canonical указывает на конкретный аналог. Sitemap содержит только нужные канонические страницы.
Почему лучше: все сигналы говорят одно и то же, поэтому шанс корректной канонизации выше.
Что спросить у подрядчика перед внедрением
- Какие URL считаются копиями, а какие должны остаться самостоятельными страницами?
- Есть ли карта соответствий старый URL → новый URL?
- Почему выбран canonical, а не 301-редирект?
- Как будут проверяться HTTP-статусы, robots.txt, sitemap, hreflang и внутренние ссылки?
- Что будет считаться успешным результатом после переобхода?
- Какой план отката, если поисковик выберет не тот канонический URL?
Честно: canonical не решает все SEO-проблемы
Если сайт теряет позиции, причина может быть не только в дублях. На результат влияют качество контента, структура каталога, скорость загрузки, коммерческие факторы, доверие к бренду, цена, сезонность, обработка заявок и поведение отдела продаж.
Canonical помогает поисковикам разобраться с версиями URL. Но он не сделает слабую страницу полезной, не заменит нормальный оффер и не исправит ситуацию, когда пользователь не понимает, почему должен оставить заявку.
Если нужно смотреть шире, полезно разбирать не только тег, а всю систему: техническое SEO, контент, коммерческие блоки, внутреннюю перелинковку и конверсию. Для такой задачи подходит SEO-продвижение сайта с нормальной диагностикой, а не точечная правка одного тега.
FAQ по cross-domain canonical
Cross-domain canonical работает как редирект?
Нет. Пользователь остаётся на текущей странице, а поисковику передаётся сигнал о предпочтительном URL. Если старую страницу больше не нужно показывать, обычно правильнее 301-редирект.
Можно ли ставить canonical с копии на главную страницу?
Только если главная действительно является релевантным аналогом, что бывает редко. Для статей, товаров и услуг нужна точная пара URL.
Нужно ли закрывать копию в noindex?
Обычно нет. Если страница закрыта от индексации или обхода, поисковику сложнее обработать canonical. Сначала определите цель: исключить страницу из поиска или объединить дубли.
Как быстро поисковик учтёт canonical?
Срок зависит от частоты обхода, качества сайта и количества противоречивых сигналов. Проверять нужно после переобхода, а не сразу после публикации тега.
Можно ли использовать cross-domain canonical для партнёрских публикаций?
Можно, если партнёр согласен и контент действительно похож. Но для новостной синдикации и площадок с собственной редакционной ценностью нужно оценивать риски отдельно.
Почему поисковик игнорирует мой canonical?
Частые причины: разные тексты, неверный HTTP-статус целевого URL, несколько canonical, закрытие в robots.txt, конфликт с sitemap, hreflang или внутренними ссылками.
Что делать дальше
Если на сайте есть дубли, переезд между доменами, PDF-копии, зеркала или партнёрские публикации, не начинайте с массовой вставки canonical. Сначала соберите карту URL, проверьте статусы, sitemap, robots.txt и внутренние ссылки.
Так вы снизите риск, что поисковик выберет не ту страницу, а после внедрения будет непонятно, где искать ошибку.
