Если rel="canonical" страницы указывает на чужой домен, считайте это ошибкой конфигурации, пока не доказано обратное. Посетителя такой тег не перенаправляет, но поисковая система может принять другой URL за предпочтительную версию страницы и объединить сигналы с ним.
Начните с одного проблемного URL: сравните исходный HTML, итоговый DOM и HTTP-заголовки. Так можно отделить ошибку шаблона от настройки CMS, клиентского скрипта, прокси или кэша и не делать массовую замену вслепую.
Что именно сообщает canonical
Canonical связывает дубли или очень похожие страницы и подсказывает, какой URL считать основным. Для Google это сильный сигнал, но не безусловная команда: поисковик сопоставляет его с редиректами, внутренними ссылками, sitemap и другими признаками. Это указано в документации Google о выборе канонического URL.
Тег не заменяет редирект. Если старый домен больше не должен обслуживать посетителей, нужен корректный перенос и постоянный редирект; canonical лишь описывает отношение между URL. Для HTML его обычно размещают в <head>, а сервер может передать то же отношение в заголовке Link, формат которого определён RFC 8288.
Проверяйте слой за слоем
1. Зафиксируйте фактический адрес страницы
Откройте точный URL в приватном окне и запишите адрес после всех редиректов. Не смешивайте в одной проверке HTTP и HTTPS, версии с www и без www, языковые разделы и URL с параметрами: у каждой комбинации может быть свой шаблон или правило.
Ответьте на два вопроса: какой URL открывается посетителю и какой должен быть основным для поиска. Если ответы различаются без понятной причины, проверяйте и редиректы, и canonical.
2. Посмотрите исходный HTML
Используйте «Просмотр кода страницы» и найдите все вхождения rel="canonical". Важен HTML, который отдал сервер, а не только панель Elements после выполнения JavaScript.
Проверьте href: схему, домен, поддомен, путь, завершающий слеш и параметры. Абсолютный URL проще проверить и меньше зависит от контекста.
3. Сравните с итоговым DOM
Откройте инструменты разработчика и повторите поиск в Elements. Если в исходном HTML адрес верный, а после загрузки стал чужим, canonical меняет клиентский скрипт, менеджер тегов или компонент приложения.
Не добавляйте второй тег поверх ошибочного. Противоречащие декларации делают сигнал неоднозначным; найдите и отключите источник лишней.
4. Проверьте HTTP-заголовок Link
Canonical может находиться не в HTML, а в ответе сервера:
curl -sS -D - -o /dev/null https://example.ru/problem-pageНайдите заголовок вида Link: <https://example.ru/page>; rel="canonical". Если HTML указывает на ваш домен, а заголовок — на другой, проверьте веб-сервер, reverse proxy, CDN и правила для отдельных типов ответа.
Как результат указывает на источник
| Наблюдение | Где искать | | --- | --- | | Чужой домен уже в исходном HTML | шаблон, SEO-модуль, настройка основного URL или серверный кэш | | Исходный HTML верный, DOM неверный | JavaScript, менеджер тегов или клиентский компонент | | HTML верный, заголовок Link неверный | конфигурация сервера, прокси или CDN | | Ошибка есть только у группы страниц | шаблон материала, категория, язык или персональная SEO-настройка | | Ошибка видна только через CDN | edge-правило, сохранённый ответ или различие origin и CDN |
Где остаётся старый или чужой домен
После переноса проверьте базовый URL в настройках CMS и окружения. Затем найдите точное имя домена в шаблонах, SEO-модулях и индивидуальных полях страницы. Значение могло попасть в общий layout, поэтому ошибка проявится на множестве URL, хотя правка нужна одна.
Отдельно проверьте:
- серверный и CDN-кэш;
- шаблоны карточек, категорий, пагинации и языковых версий;
- настройки staging-копии, из которой переносили сайт;
- правила прокси, добавляющие заголовок
Link; - генерацию URL из входящего заголовка
Host.
Безопаснее задавать основной origin явной разрешённой настройкой, а не доверять непроверенному Host. Не заменяйте домен вслепую во всей базе: сначала определите поля, которыми действительно управляет CMS.
Как исправить без нового конфликта
- Выберите один предпочтительный URL для каждой группы дублей.
- Настройте self-referencing canonical на основной странице и согласованный canonical на её дублях.
- Удалите лишние декларации из HTML и заголовков.
- Согласуйте с выбранным URL постоянные редиректы, внутренние ссылки, sitemap и
hreflang, если он используется. - Очистите нужные кэши и разверните исправление.
- Повторите проверку на нескольких типах страниц, а не только на главной.
Canonical-цель должна открываться ожидаемо и не вести на ошибку или ещё одну цепочку перенаправлений. Если страница закрыта от индексации, сначала разберите конфликт: полезен материал о том, почему поисковый робот не видит сайт.
Как проверить исправление
Возьмите главную, категорию, карточку, страницу с параметром и языковую версию. Для каждой запишите конечный URL, canonical в исходном HTML, canonical в DOM, заголовок Link и ожидаемый основной адрес.
После публикации повторите проверку без авторизации и из внешней сети. Затем используйте инспекцию URL в Google Search Console: там можно сравнить canonical, указанный владельцем, с URL, выбранным Google. Поисковые данные обновляются не мгновенно, поэтому сначала подтверждайте технический ответ сайта, а затем наблюдайте за переобходом.
Когда одной правки шаблона мало
Если чужой домен появился без переноса или известного изменения, проверьте историю развёртываний, учётные записи администраторов, целостность шаблонов и правила CDN. Неожиданный внешний canonical может быть следствием не только ошибки, но и компрометации; одной замены тега тогда недостаточно.
Разовая проверка также не показывает, останется ли конфигурация стабильной после следующего релиза. Web-Puls помогает регулярно контролировать доступность и конечный адрес важных страниц, но выбранный поисковиком canonical всё равно нужно проверять в инструментах вебмастера.
После исправления добавьте критичные страницы в мониторинг, чтобы быстрее заметить недоступность или неожиданный переход на другой адрес.