Canonical, sitemap, hreflang и редирект решают разные задачи, но все затрагивают идентичность URL. Когда они направлены на разные адреса, поисковой системе приходится самостоятельно интерпретировать намерение сайта. Результатом может стать выбранная системой каноническая версия, выпадение языковой страницы из группы или обход URL, который всё равно перенаправляется.
Назначьте одну основную сущность
Сначала ответьте на вопрос: какой URL должен открываться пользователю и участвовать в поиске как основная версия этого содержания? После такого решения можно править разметку. Выбор опирается на актуальный протокол и домен, устойчивый путь, язык, бизнес-сущность и возможность поддерживать адрес в будущем.
Составьте таблицу для проблемной группы: запрошенный URL, конечный адрес, код, canonical, sitemap, hreflang, язык, индексируемость и входящие ссылки. Не объединяйте страницы только по похожему пути. /ru/product и /en/product представляют разные языковые версии; URL с сортировкой и чистая категория могут быть дублями; старый и новый адрес статьи — этапами миграции.
Решение запишите обычным предложением: «основная русская карточка — A, английская — B, старый адрес C окончательно переехал на A». Из этой записи выводятся технические сигналы, и команды работают с одной согласованной схемой.
Разберите роль каждого сигнала
Постоянный серверный редирект сообщает, что исходный URL больше не является конечным ресурсом. rel="canonical" указывает предпочтительную версию одинакового или очень похожего документа. Sitemap перечисляет URL, которые владелец хочет видеть в поиске. Hreflang связывает самостоятельные локализованные версии одной страницы.
Google относит редиректы и canonical к сильным сигналам канонизации, а включение в sitemap — к более слабым. Система всё равно оставляет за собой окончательный выбор. В официальном руководстве по canonical отдельно рекомендуется не указывать разные адреса разными методами и выбирать для hreflang canonical на том же языке.
Отсюда следует практическое правило: sitemap не должен содержать URL, который постоянно редиректит или канонизируется на другой. Hreflang не должен ссылаться на неканоническую, закрытую или перенаправляемую страницу. Canonical не заменяет языковую связь.
Найдите источник конфликта
Начните с исходного HTML, затем сравните его с DOM. Canonical может добавляться шаблоном, SEO-плагином и HTTP-заголовком одновременно. Hreflang нередко генерирует модуль локализации, тогда как sitemap строит другой плагин из базы. Редиректы живут в CMS, серверной конфигурации, CDN или middleware. Каждый слой может использовать собственное правило нормализации.
Сгруппируйте конфликты по шаблону. Если все URL со слешем канонизируются без слеша, но сервер ведёт обратно, проблема в глобальной нормализации. Если только переведённые карточки указывают canonical на русский оригинал, проверьте шаблон локализации. Если sitemap содержит старые адреса после миграции, генератор берёт неактуальное поле.
Сравните публичный ответ с origin, если доступен. CDN способен сохранить старый canonical или редирект после обновления приложения. Не очищайте весь кэш автоматически: сначала установите ключи и область затронутых страниц.
Согласуйте canonical, редиректы и sitemap
Страница A не должна отвечать редиректом на B и одновременно успевать объявлять canonical C: HTML исходного адреса поисковик обычно не использует как конечный документ. Проверьте цель перехода B. Если именно она выбрана основной, B возвращает 200 и ставит self-canonical на B; внутренние ссылки и sitemap также ведут на B.
Цепочку A → B → C сократите до прямого перехода A → C, когда C — окончательная версия. Убедитесь, что нет петли между правилами нормализации: HTTPS на HTTP, www на без www, слеш на без слеша и обратно. Практические методы проверки собраны в статье о редиректах.
Если A должна остаться самостоятельной, уберите перенаправление и верните содержательный 200. Нельзя одновременно считать URL доступной страницей и окончательно перемещённым адресом.
Очистите sitemap до канонических URL
В карту включайте абсолютные конечные адреса, которые отвечают 200, разрешены к индексированию и выбраны основными. Google рассматривает URL sitemap как предлагаемые canonical и советует перечислять именно те версии, которые владелец хочет показывать в поиске; это указано в документации по созданию sitemap.
После смены домена, протокола или структуры пути обновите генератор и все созданные им XML-файлы. Проверьте индекс sitemap, дочерние карты, ссылки в robots.txt и отправленные версии в поисковых консолях. Удалите редиректы, 404 и параметрические дубли.
Дата lastmod должна отражать существенное изменение страницы. Подстановка времени каждой сборки карты создаёт бессмысленные постоянные обновления и усложняет интерпретацию обхода. Другие типовые дефекты разобраны в материале об ошибках sitemap.
Соберите корректный hreflang-кластер
Каждая языковая страница должна иметь собственный canonical на своей локали, если она является самостоятельной версией, и ссылаться через hreflang на доступные канонические аналоги. Связи делают взаимными: если русская страница указывает английскую, английская подтверждает русскую. Целевые адреса отвечают 200, не закрыты и не перенаправляются.
Canonical русской страницы на английскую обычно выводит русскую из самостоятельной группы: один сигнал говорит «это дубль английской», другой — «это её языковая альтернатива». Если локализация слишком слаба и действительно считается дублем, сначала примите содержательное решение о её существовании. Hreflang не исправляет отсутствующий перевод.
Проверьте коды языка и региона, x-default, протокол, домен и слеши. Изолированные ошибки и способы массовой сверки описаны в статье о типичных ошибках hreflang.
Выпускайте изменение как карту соответствий
Для миграции подготовьте явную таблицу «старый URL → новый URL». Из неё должны генерироваться или проверяться редиректы, canonical, sitemap, hreflang и внутренние ссылки. Когда каждый слой ведут вручную разные люди, расхождение почти неизбежно.
Перед релизом прогоните контрольные группы: основная страница, старый адрес, языковые версии, URL с параметрами, пагинация, HTTP/www/слеш-варианты. После релиза повторите запросы к публичному домену, включая мобильный user-agent. Сверьте исходный HTML и заголовки, очистив только подтверждённо устаревшие кэш-объекты.
Полный аудит сайта reChecker собирает доступные URL и показывает canonical, hreflang, sitemap и переходы в техническом отчёте. Используйте его после утверждения карты соответствий, чтобы найти страницы, на которых один из сигналов остался старым.
Зафиксируйте критерий согласованности
Для обычной индексируемой страницы конечный адрес отвечает 200, ставит self-canonical, находится в sitemap и получает внутренние ссылки без редиректа. Для языковой версии к этому добавляется взаимный hreflang на канонические адреса соответствующих локалей. Старый URL прямо перенаправляет на выбранный новый и отсутствует в карте.
Прогоните критерии по каждому семейству из матрицы и сохраните результаты рядом с картой соответствий. Выбранная canonical в консоли может обновиться позже технической выкладки: повторный обход поисковой системы занимает время. При следующей проверке матрица покажет, какой конфликт сохранился на сайте, а где обновление ещё не дошло до поисковой базы.