Определите, действительно ли URL являются дубликатами
Канонический URL — это представительный адрес для дублирующих или близких по содержанию страниц. Атрибут rel=canonical уместен, когда целевой URL содержит дублирующийся контент или надмножество контента страницы-источника. Это не способ скрыть разные продукты, полезные фильтры, статьи или локализации.
Спросите себя: потеряет ли посетитель важный контент, выбор или возможность выполнения задачи, если этот URL будет представлен кандидатом? Если да — оставьте его отдельным и улучшите его содержание или локализацию. Если нет — выберите один стабильный URL и задокументируйте правила по протоколу, хосту, пути, завершающему слэшу и параметрам.
Поместите self-referencing rel=canonical на каждую предпочитаемую индексируемую HTML-страницу, даже если сегодня явных дубликатов нет.
Указывайте необходимый дубликат, например маршрут с аналитическим параметром, на предпочитаемый URL только если обе страницы возвращают одно и то же основное содержимое.
Используйте перенаправление, когда старый URL должен исчезнуть
Применяйте постоянное серверное перенаправление (301) когда старый путь, устаревший хост или версия по HTTP не должны больше быть назначением для посетителей или краулеров. Google рассматривает редиректы как сильный сигнал канонизации и рекомендует их при выводе из обращения дубликатов.
Используйте rel=canonical когда оба URL должны возвращать контент, но один должен представлять кластер в поиске. Тег не меняет адрес в браузере и не удаляет другой маршрут. Целевой URL должен успешно отдавать контент и не перенаправлять или не быть канонизированным в другое место.
Отправляйте устаревший HTTP-URL напрямую на финальный HTTPS-адрес и используйте этот HTTPS-адрес везде далее.
robots.txt, URL-удаления и noindex не выражают предпочтительного дубликата. Noindex блокирует страницу от поиска, но не устанавливает канонику.
Публикуйте одну ясную аннотацию
Для HTML поместите один абсолютный rel=canonical в head. Проверяйте сгенерированный исходный код, а не только настройку в CMS: тема, плагин, правило на edge или JavaScript могут заменить значение. Google советует указывать его в HTML-исходнике и следить, чтобы JavaScript не менял значение.
Для не-HTML-документа, например PDF, при необходимости используйте заголовок ответа HTTP Link (Link response header) с каноническим адресом. Избегайте конфликтующих значений в HTML и в заголовках. Целевой URL должен быть доступен, не возвращать 4xx и не быть перенаправляющим или цепочным URL.
Публикуйте один canonical-цель для каждого ресурса; множественные цели делают предпочтение неясным.
После изменений в шаблонах, CDN, CMS или маршрутизации выборочно запросите страницы и заголовки и подтвердите финальную цель.
Согласуйте сопутствующие сигналы
Ссылайтесь внутри сайта на предпочитаемый URL в навигации, хлебных крошках, текстовых ссылках и генерируемых фидах. Включайте в sitemap только те URL, которые вы хотите видеть в выдаче. Включение в sitemap — более слабый сигнал, но он подкрепляет выбор, когда согласуется с редиректами и аннотациями.
Генерируйте полностью квалифицированные URL в sitemap с тем же хостом, протоколом и стилем завершающего слэша, что и canonical. Удаляйте перенаправляемые и параметризованные дубликаты. Тестируйте автоматически генерируемые sitemaps после изменений в permalink, домене, языке или каталогах e‑commerce.
Заменяйте ссылки на отслеживаемые, устаревшие или альтернативные хосты ссылками на выбранный канонический URL.
Поддерживайте согласованность HTTPS в редиректах, канонических целях, sitemap и ссылках; проблемы с сертификатом или обратный переход HTTPS→HTTP создают противоречивые сигналы.
Обрабатывайте параметры, пагинацию и языки по назначению
Параметры не являются автоматически дубликатами. Аналитические параметры могут не менять контент, тогда как фильтры и сортировка меняют набор результатов. Протестируйте типичные комбинации. Сохраняйте любые параметры, нужные для корзины, логина, согласия или конфигурации; canonical не должен ломать пользовательский поток.
Не канонизируйте все страницы пагинации на первую: на последующих страницах обычно есть элементы или контент, отсутствующие на первой. Для языковых или страновых URL указывайте каноническим URL на странице того же языка, если он существует, и используйте hreflang для альтернатив. Канонизация не заменяет дизайн локализации.
Задокументируйте, какие фильтры — это отдельные посадочные страницы, а какие — дублирующие перестановки, чтобы продукт и инженерия оставались в синхроне.
Используйте одну только если она действительно является удобным надмножеством контента; протестируйте её загрузку и навигацию перед выбором.
Отлаживайте конфликты с индексированными и живыми данными
В Search Console (Google Search Console) инспектируйте затронутый URL и сравните индексированный Google-ом выбранный канонический с тем, что вы объявили. Также проверьте кандидатный целевой URL. Отчёт об индексировании отражает то, что Google обработал в последний раз; живый тест полезен для текущего фетча, рендеринга, заголовков и ресурсов, но не может предсказать окончательный выбор каноники.
Если значения расходятся, подумайте, выбрал ли Google более подходящий представитель. В противном случае проследите редиректы, HTML- и HTTP‑заголовки с аннотациями, рендеренный вывод, ссылки, sitemap-записи, hreflang и сходство контента. Устраните расхождение, задокументируйте изменения и дайте время на повторную оценку.
Проверьте шаблоны, заголовки, маршрутизацию хоста и изменения безопасности. Необъяснимая кросс-доменная каноника или редирект требует расследования по безопасности.
Сравните отданный исходник и заголовки с настройками CMS; плагин или платформа может выдавать иное значение.
Добавьте проверки canonical в усиление релизов SIU
Перед релизами домена, HTTPS, CDN, CMS, шаблонов или каталога выборочно протестируйте главную страницу, контент- и продуктовые страницы, маршрут с параметром, локаль, устаревший URL и публикуемые документы. Запишите статус, финальный URL, целевой canonical, включение в sitemap и пример внутренней ссылки.
Держите исправления обратимыми: сохраните текущую карту, измените один набор правил, проверьте затронутые маршруты и имейте план отката. Это помогает проактивной оптимизации доступности, защищая стабильные публичные пути при изменениях; это не даёт обнаружения простоев или гарантии индексирования.
Распределите правила canonical между маркетингом и инженерией и логируйте за каждым обновлением изменённый шаблон, редирект, sitemap или платформенное правило.
Прикрепляйте к релизному тикету небольшой пример URL и образцы заголовков до и после для ускорения исправления.