Как проверить canonical на всех страницах сайта

Что делает тег canonical и чего он не делает

Элемент <link rel="canonical" href="…"> сообщает поисковику предпочтительную версию. Он полезен, когда одна сущность доступна по нескольким URL: с параметрами, сортировками, слешем, страницами печати или похожими карточками. Но canonical — рекомендация: робот сопоставляет её с контентом, ссылками, sitemap, редиректами и доступностью.

Семантика статьи

Основной кластер: «как проверить canonical на всех страницах сайта», «аудит canonical», «проверить rel canonical». Вспомогательные темы: канонические URL, дубли, self canonical, параметры, sitemap, robots, 301 и индексация.

Self-canonical и межстраничный canonical

Self-canonical указывает URL на себя и защищает от дублей. Межстраничный вариант допустим для почти идентичных страниц. Разные по смыслу категории, товары или статьи объединять опасно.

Canonical не заменяет 301

Если старый URL навсегда переехал, используйте 301. Canonical подходит для доступных параллельных версий.

Один сигнал не должен спорить с другим

Не отправляйте URL в sitemap и во внутренние ссылки, если canonical ведёт на другую страницу.

Какие страницы включить в проверку

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

Особенно внимательно проверьте

• страницы с UTM и другими параметрами;
• HTTP/HTTPS и www/без www;
• фильтры, сортировки и пагинацию;
• страницы после миграции или изменения CMS;
• адреса, выпавшие из индекса.

Для PDF и изображений обычно важнее корректный HTTP-ответ и внутренняя ссылка, чем HTML-тег canonical.

Как проверить canonical на всех страницах: алгоритм

1. Обойдите URL. Для каждой HTML-страницы сохраните конечный адрес, код ответа, robots, title, H1 и значение canonical.
2. Нормализуйте ссылки. Приведите относительные и абсолютные адреса к единому виду: протокол, хост, слеш и кодировка должны сравниваться корректно.
3. Проверьте целевой URL. Canonical должен отвечать кодом 200, быть доступным роботу и не содержать цепочку перенаправлений.
4. Сгруппируйте повторы. Один canonical на тысячи разных страниц — повод вручную проверить шаблон. Иногда это норма для фильтров, но часто ошибка переменной.
5. Сопоставьте сигналы. Сравните canonical с sitemap, внутренними ссылками, robots и редиректами.

Начать техническую диагностику удобно с проверки HTTP-ответа и заголовков конкретного URL. Для сложных переездов добавьте анализ цепочки редиректов: canonical на адрес с 301 или 302 — плохой кандидат для основной версии.

Типовые ошибки canonical

Параметры и фильтры

Не указывайте canonical автоматически на базовую категорию, если фильтр создаёт отдельную полезную посадочную с уникальным спросом. Сначала определите, нужно ли её индексировать. Если нет — уберите внутренние ссылки, настройте параметры или ограничьте обход; если да — дайте самостоятельный контент, self-canonical и понятное место в структуре.

Языковые и региональные версии

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

Как исправить ошибки и проверить результат

1. Составьте таблицу: исходный URL, текущий canonical, код целевого URL, тип проблемы и решение.
2. Исправляйте сначала шаблонные ошибки, затрагивающие много страниц.
3. После релиза повторно обойдите URL и убедитесь, что canonical ведёт сразу на 200.
4. Проверьте sitemap и внутренние ссылки: они должны поддерживать выбранную версию.
5. Наблюдайте за индексированием и динамикой важных запросов несколько недель.

Короткий анкор «канонические URL», средний «проверка дублей сайта» и как проверить внутреннюю перелинковку и обнаружить ссылки на неканонические адреса помогут связать техаудит с контентной структурой. Для поиска последствий проблем с доступностью изучите как найти страницы с HTTP 301, 302 и 500.

Хороший canonical-аудит — не разовая галочка. Добавьте его в процесс релизов и повторяйте после изменения шаблонов, фильтров, домена или CMS. Так поисковик всегда получает согласованный и проверяемый набор сигналов.