Статья:
Статус «Alternate page with proper canonical» в Google Search Console значит одно: робот нашёл на странице тег rel="canonical", указывающий на другой URL, согласился с этим выбором и исключил страницу из индекса в пользу «канонической» версии. Само по себе это не ошибка — но в 2026 году я регулярно вижу сайты, где под этим статусом прячутся сотни страниц, которые должны были индексироваться и приносить трафик. Разница между «нормой» и «утечкой контента» проверяется за 5 минут — вот как это сделать руками, без гаданий.
Шаг 1: смотрим глазами Google, а не своими
Не доверяйте тому, что видите в <head> через «Просмотр кода страницы» (Ctrl+U) — там показан исходный HTML, а не тот, что реально получил Googlebot после рендеринга JS. Разница критична для SPA и сайтов на React/Vue, где canonical может подставляться скриптом.
Порядок действий:
- Search Console → инструмент проверки URL (верхняя строка поиска в интерфейсе GSC) → вставляете адрес → Enter.
- Открываете блок «Покрытие» (Coverage) в результатах проверки. Там два ключевых поля:
- User-declared canonical — что прописано у вас в теге;
- Google-selected canonical — какой URL реально выбрал алгоритм.
- Если поля совпадают — Google согласен с вами, статус штатный. Если отличаются — Google проигнорировал ваш тег и выбрал canonical сам, а это уже повод разбираться с качеством или структурой страницы.
Параллельно проверьте HTTP-уровень через терминал:
curl -IL https://example.com/catalog/shoes?sort=price
Смотрите на итоговый код ответа целевого (canonical) URL. Если видите 404, 410 или 5xx в конце цепочки редиректов — это не «норма», это баг, который надо чинить сегодня, а не после квартального аудита.
Когда статус — это норма (реальные кейсы)
Ниже — сценарии, где Alternate page with proper canonical означает, что ваша индексация настроена правильно, и трогать ничего не нужно:
- Фильтры и сортировки каталога.
/catalog/shoes?sort=price&color=redс canonical на/catalog/shoes. У меня на клиентских проектах e-commerce такие URL составляют 60–80% всех «непроиндексированных» страниц в отчёте — это ожидаемо при десятках комбинаций фильтров. - Версии для печати (
?print=1) и AMP-дубли без собственного контента. - UTM-метки и идентификаторы сессий:
/page?utm_source=vk&utm_medium=cpc— canonical на чистый URL без параметров. Это правильно: без этого правила в индекс попадёт по копии страницы на каждую рекламную кампанию. - Один товар в двух категориях (
/obuv/nike-air/и/sport/nike-air/) с canonical на основной путь.
Правило простое: если целевой canonical отвечает 200 OK, содержит практически идентичный контент и это действительно та страница, которую вы хотите видеть в выдаче — статус не трогаем. Это признак чистого индекса, а не проблемы.
Когда статус сигнализирует об ошибке — 4 сценария с разбором
Сценарий 1: canonical ведёт на 404/410/5xx.
Проверка: curl -IL на target-URL из поля User-declared canonical. Если там не 200, а 404 — страница-донор потеряла и трафик, и цель для передачи веса. Делай: либо восстанови целевую страницу, либо убери canonical и сделай страницу самостоятельной (self-canonical), либо поставь 301 с A на реально работающий URL. Не делай: не оставляй как есть в надежде, что «само пройдёт» — робот не станет искать альтернативу сам.
Сценарий 2: цель закрыта в robots.txt или стоит noindex.
Логический тупик: страница A говорит «смотри на B», страница B отвечает noindex или блокируется в robots.txt. В итоге в индексе нет ни одной версии. Проверка: откройте B в режиме инкогнито и посмотрите <meta name="robots">, либо прогоните через URL Inspection — GSC прямо покажет «Заблокировано robots.txt» вместо статуса о canonical. Делай: снимай noindex с целевой страницы или меняй canonical на реально индексируемый URL. Подробнее о такой проблеме читайте в статье Indexed, though blocked by robots.txt: как найти причину и вычистить статус в 2026 году
.
Сценарий 3: цепочка канонических ссылок (A→B→C). Google предпочитает прямые указания на один шаг. Если у вас A→B→C, робот может обработать цепочку с задержкой в несколько недель либо остановиться на промежуточном звене. Я видел, как страница висела в этом статусе 3+ недели именно из‑за цепочки в 3 звена на сайте с фасетной навигацией. Делай: пройди по цепочке руками (или массово, см. ниже) и перепиши canonical у всех промежуточных страниц напрямую на финальный URL C.
Сценарий 4: canonical зашит в шаблон и указывает на главную/корень категории.
Самый неприятный баг: разработчик один раз прописал rel="canonical" со ссылкой на домен или на /category/ в шаблоне карточки товара или статьи — и теперь весь раздел сайта из десятков уникальных страниц никогда не попадёт в индекс, потому что «канонической» назначена одна и та же страница для всех. Обнаруживается через view-source на 3–5 разных страницах раздела: если у всех одинаковый canonical, а контент разный — это баг шаблона, а не осознанное решение. Делай: правь шаблон, чтобы canonical генерировался динамически (self-referencing по умолчанию), затем запрашивай переиндексацию.
Как проверить статус не по одной странице, а массово
Проверять URL по одному через инструмент проверки — нормально для 5–10 страниц, но если у вас под этим статусом тысячи URL (типично для каталогов), ручная проверка не масштабируется. Для массовой сверки статуса индексации по списку URL из sitemap или экспорта GSC удобно прогнать список через Rush Analytics — сервис делает пакетную проверку индексации и находит страницы, которые реально должны индексироваться, но выпали по ошибке шаблона. Если хотите узнать, как быстро находить такие проблемы, смотрите руководство Duplicate without user-selected canonical: как найти и починить проблему в Search Console .
Если нужен быстрый экспресс-анализ одной конкретной спорной страницы (контент, теги, дубли) без развёртывания полноценного аудита — подойдёт PR‑CY.
После исправления: как ускорить переиндексацию
Исправили canonical (сняли лишний тег, поправили шаблон, восстановили 404‑цель) — недостаточно просто ждать. В GSC на карточке URL Inspection нажмите «Request indexing» (Запросить индексирование), это отправит страницу в приоритетную очередь обхода. Но краулинговый бюджет у Google не резиновый, и на больших сайтах ожидание может растянуться на недели. Чтобы ускорить обход именно освобождённых страниц, можно параллельно прогнать их через индексатор вроде SpeedyIndex — это ускоряет попадание URL в очередь сканирования, особенно полезно, если таких страниц набралось сразу много после массового фикса шаблона.
Почему не нужно пытаться «исправить» все страницы подряд
Массовая зачистка отчёта «Страницы» от этого статуса — частая ошибка новичков. Если у вас интернет‑магазин с десятками фильтров, тысячи URL со статусом Alternate page with proper canonical — это норма, а не проблема. Принудительное удаление canonical ради «попадания в индекс» приводит к обратному эффекту:
- Краулинговый бюджет тратится на обход бесполезных дублей вместо новых страниц.
- Google хуже понимает, какую именно версию показывать по целевому запросу — падает релевантность в выдаче.
- Внешний вес размывается между десятком мелких дублей вместо концентрации на одной сильной странице.
Правило проверки: берите репрезентативную выборку из 10–15 URL со статусом, смотрите User-declared vs Google-selected canonical в GSC. Совпадают и ведут на рабочую страницу — оставляйте как есть.
Кросс‑проверка в других поисковиках
Логика обработки дублей похожа у всех систем, но названия статусов различаются. В Яндекс.Вебмастере смотрите раздел «Индексирование → Страницы в поиске» и статус «Исключены дублирующиеся страницы», в Bing Webmaster Tools — аналог в разделе Site Explorer. Если статус массово расходится между Google и Яндексом на одних и тех же URL — вероятная причина в том, что боты по‑разному интерпретируют вашу разметку canonical, и стоит проверить, нет ли у вас условной логики, отдающей разный canonical по User-Agent. Для углублённого понимания, как правильно ставить канонические URL без потери трафика, см. Canonical URL: как поставить правильно и не потерять страницы из индекса . Также полезно посмотреть материал Почему Google не индексирует страницу: диагностика по статусам Search Console .