Диагностика canonical в Google

rel="canonical" помогает поисковой системе понять, какой URL считать основным среди дублей и очень похожих страниц. При этом canonical — сигнал, а не жесткая директива: Google может выбрать другой URL, если остальные сигналы противоречат указанному адресу.

10 июля 2026 года Google уточнил troubleshooting-документацию по canonicalization. Один из практических ориентиров: даже после исправления проблемы URL может оставаться в прежнем duplicate cluster до двух недель. Если содержимое стало заметно отличаться, переоценка обычно происходит быстрее.

Поэтому после исправления canonical не стоит делать новый вывод через несколько часов. Сначала нужно проверить все сигналы, затем дать Google время переобойти страницы.

Какие сигналы использует Google

Google рекомендует несколько способов указать канонический URL.

По относительной силе сигнала:

• redirect — сильный сигнал;
• rel="canonical" — сильный сигнал;
• URL в sitemap — более слабый сигнал.

Сигналы можно усиливать друг другом. Например, основной URL одновременно:

• используется во внутренних ссылках;
• указан в sitemap;
• имеет self-canonical;
• является целью redirect со старых URL.

Чем меньше противоречий, тем проще поисковой системе выбрать ожидаемый canonical.

Симптом: Google выбрал другой canonical

В Search Console это обычно видно в URL Inspection:

User-declared canonical: https://example.com/page/
Google-selected canonical: https://example.com/page?ref=old

Само расхождение еще не означает ошибку Google. Оно означает, что стоит проверить остальные сигналы.

Алгоритм диагностики

1. Сравнить содержимое двух URL

Открыть оба адреса и проверить:

• заголовок и основной текст;
• изображения и структурированные данные;
• языковую версию;
• наличие параметров;
• HTTP status;
• доступность для Googlebot.

Если страницы практически идентичны, выбор другого URL может быть закономерным.

Если страницы должны быть самостоятельными, сначала нужно сделать их действительно различимыми по содержимому и назначению, а не только поменять canonical.

2. Проверить HTTP-ответ и redirect

curl -sSIL https://example.com/page/

Ищите:

• неожиданный 301, 302, 307 или 308;
• redirect chain;
• переход на другой host;
• HTTP → HTTPS;
• www → без www или наоборот.

Если URL сам перенаправляется на другую страницу, self-canonical внутри исходного HTML уже не спасает ситуацию.

3. Проверить canonical в HTML

curl -fsSL https://example.com/page/ \
  | grep -iE '<link[^>]+rel=["'"']canonical["'"']'

Нормальный вариант:

<link rel="canonical" href="https://example.com/page/">

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

• canonical ведет на staging-домен;
• canonical формируется с неправильным host;
• URL обрезается до категории;
• все страницы пагинации указывают на первую страницу без необходимости;
• два SEO-плагина выводят разные canonical;
• серверный шаблон и JavaScript генерируют разные значения.

4. Проверить HTTP Link header

Для PDF и других не-HTML документов canonical может передаваться HTTP-заголовком:

curl -sSI https://example.com/file.pdf | grep -i '^link:'

Пример:

Link: <https://example.com/file/>; rel="canonical"

Если HTML canonical и HTTP header противоречат друг другу, конфигурацию нужно исправить.

5. Проверить внутренние ссылки

Если весь сайт ссылается на:

/page?utm_source=menu

а canonical указывает на:

/page/

Google получает смешанные сигналы.

Внутренние ссылки лучше вести сразу на канонические URL, а параметры добавлять только там, где они действительно нужны.

Для быстрой проверки небольшого сайта можно использовать crawler или grep по исходникам проекта.

6. Проверить sitemap

В sitemap должны находиться URL, которые сайт считает каноническими.

Не стоит одновременно отправлять:

/product/1
/product/1?sort=price
/product/1?utm_source=email

если все три страницы являются одним и тем же документом.

Sitemap не переопределит сильный противоречащий сигнал, но неправильный sitemap усложняет диагностику.

7. Проверить hreflang

Для мультиязычных страниц Google рекомендует указывать canonical на URL того же языка или на максимально близкий вариант, если точного аналога нет.

Плохой сценарий:

/ru/page/ → canonical /en/page/

при этом обе страницы содержат полноценные разные языковые версии и участвуют в hreflang.

Canonical и hreflang должны описывать согласованную архитектуру, а не бороться друг с другом.

8. Проверить CMS и плагины

Google отдельно относит ошибки CMS и плагинов к частым причинам неожиданного canonical.

Для WordPress стоит проверить:

• SEO-плагин;
• тему;
• WooCommerce и плагины фильтров;
• multilingual-плагин;
• кеш;
• custom hooks в wp_head.

Для серверных приложений:

• middleware, которое определяет host;
• reverse proxy и X-Forwarded-*;
• базовый URL приложения;
• environment variables production/staging;
• генератор sitemap.

Особенно часто ошибка появляется после переноса сайта за proxy/CDN или смены домена.

9. Исключить серверную ошибку

Проверить, что разные URL действительно отдают то, что ожидается.

Например, неправильная конфигурация virtual host может отдавать одинаковый HTML на десятках доменов. В таком случае canonical — только симптом более крупной проблемы.

Полезно сравнить:

curl -sS -D- https://example.com/page/ -o /tmp/page.html
curl -sS -D- https://wrong.example.com/page/ -o /tmp/wrong.html
sha256sum /tmp/page.html /tmp/wrong.html

10. Проверить взлом и инъекции

Если Google внезапно выбрал неизвестный внешний домен, а в шаблонах такого canonical нет, нужно рассматривать security-сценарий.

Google прямо упоминает случаи, когда злоумышленник внедряет:

• rel="canonical" на чужой URL;
• redirect;
• условный ответ только для crawler/user-agent.

Проверять нужно не только исходный код в браузере, но и ответ сервера через curl, плагины, шаблоны, .htaccess, Nginx-конфигурацию и историю изменений.

Параметры URL

Canonical особенно полезен, когда один документ доступен по нескольким техническим адресам:

/article/
/article/?utm_source=telegram
/article/?ref=partner

Если параметры не меняют содержимое, все варианты могут указывать на чистый URL.

Но нельзя механически canonical-изировать любые параметры. Например, фильтр каталога может формировать самостоятельную полезную страницу с другим ассортиментом и поисковым спросом. Сначала нужно решить, является ли URL дублем с точки зрения содержания и продукта.

Синдицированный контент

Для контента, опубликованного у партнеров, Google отдельно предупреждает: rel="canonical" не всегда является рекомендуемым способом запретить индексирование копии.

Если важно, чтобы партнерская версия не участвовала в Search, надежнее договориться с партнером об ограничении индексации этой копии. Canonical остается сигналом и может быть интерпретирован иначе.

После исправления

Подождать переобход

После устранения причины Google может держать страницу в старом duplicate cluster до двух недель.

Не нужно менять canonical каждый день, если конфигурация уже стала согласованной.

Request Indexing

Для нескольких важных URL можно использовать Request Indexing в URL Inspection.

Это не подходит для массовой переиндексации: у инструмента есть квоты, а запрос не гарантирует немедленное изменение canonical.

Снова сравнить Search Console

После переобхода проверить:

• User-declared canonical;
• Google-selected canonical;
• состояние индексации;
• sitemap;
• связанные дубли.

Чек-лист

• [ ] Основной URL возвращает 200 OK.
• [ ] Нет неожиданного redirect.
• [ ] В HTML один корректный rel="canonical".
• [ ] HTTP Link header не противоречит HTML.
• [ ] Внутренние ссылки ведут на канонический URL.
• [ ] Sitemap содержит канонические URL.
• [ ] hreflang согласован с canonical.
• [ ] Параметры действительно являются дублями, если canonical ведет на чистый URL.
• [ ] CMS и плагины не создают второй canonical.
• [ ] Production не ссылается на staging/старый домен.
• [ ] Нет признаков взлома или инъекции.
• [ ] После исправления прошло достаточно времени для переобхода.

Источники

• Google Search Central: Canonicalization troubleshooting
• Google Search Central: How to specify a canonical URL
• Google Search Central: Documentation updates