Неправильный canonical: проверка выгрузки с ИИ

Неправильный canonical — это не когда атрибут указывает на страницу, которую вы не любите. Это когда объявленный в HTML или HTTP-заголовке адрес конфликтует с таблицей сайта: ведёт на 404, замыкает цепочку, расходится с группой похожего контента или с другими способами нормализации. Проверка canonical в выгрузке начинается не с правки страниц, а с построчной сверки: где URL находится, какой адрес объявлен, куда он ведёт и что об этом известно поиску. Ниже — учебная таблица, полный промпт для агента и эталонный журнал, который вы сверяете с результатом модели. Пример полностью вымышленный: это не клиентский кейс и не запуск сервиса.

Соберите таблицу URL и целей canonical

Для каждой строки нужны поля, без которых сверка превращается в догадки: адрес, HTTP-статус, индексируемость, объявленный canonical и группа похожего контента. Origin берите один — https://example.org. Относительные адреса вроде /a нормализуйте к этому origin, но значимые параметры не удаляйте: /a?sort=1 и /a остаются разными строками, даже если один из них объявлен копией другого.

Группа контента в этой таблице задана вручную. В реальном проекте сходство страниц требуется проверять отдельно — совпадающая метка не доказывает, что робот увидит тот же текст. Отдельно храните источник canonical: HTML-разметка, HTTP-заголовок или Sitemap. Google прямо предупреждает, что не стоит указывать разные URL каноническими для одной страницы разными способами Как указать канонический URL с помощью атрибута rel="canonical" и другими способами | Центр Google Поиска.

Такой же запрет действует для фрагмента URL: Google, как правило, не поддерживает фрагменты в качестве канонических Как указать канонический URL с помощью атрибута rel="canonical" и другими способами | Центр Google Поиска. И отдельная строка про индексируемость: noindex в качестве способа запретить выбор страницы канонической приводит к полной блокировке страницы в Поиске — предпочтительным решением остаются аннотации link с rel="canonical" Как указать канонический URL с помощью атрибута rel="canonical" и другими способами | Центр Google Поиска.

Собранная таблица должна давать одну строку на URL. Вот учебный набор:

{
  "base": "https://example.org",
  "rows": [
    { "url": "/a", "status": 200, "indexable": true, "canonical": "/a", "group": "A" },
    { "url": "/a?sort=1", "status": 200, "indexable": true, "canonical": "/a", "group": "A" },
    { "url": "/b", "status": 200, "indexable": true, "canonical": "/gone", "group": "B" },
    { "url": "/gone", "status": 404, "indexable": false, "canonical": null, "group": null },
    { "url": "/c", "status": 200, "indexable": true, "canonical": "/d", "group": "C" },
    { "url": "/d", "status": 200, "indexable": true, "canonical": "/a", "group": "D" }
  ]
}

Найдите конфликты и корректные отрицательные случаи

Не каждая строка с непустым canonical — ошибка. Два учебных случая специально оставлены без конфликта. Self-canonical на /a допустим: страница указывает сама на себя. Копия /a?sort=1 тоже в порядке: параметрический вариант той же группы A ведёт на доступную /a. Google отдельно предупреждает не тратить обход на копии одних и тех же страниц и не использовать robots.txt для нормализации Как указать канонический URL с помощью атрибута rel="canonical" и другими способами | Центр Google Поиска.

Конфликты видны по статусу цели и по группам:

URL	Статус	Canonical	Группа	Вердикт таблицы
/a	200	/a	A	без конфликта: self-canonical
/a?sort=1	200	/a	A	без конфликта: копия той же группы
/b	200	/gone	B	проверка: цель возвращает 404
/gone	404	—	—	не индексируется: отдельная проблема URL
/c	200	/d	C	проверка: цепочка и чужая группа
/d	200	/a	D	проверка: чужая группа

У /gone canonical не исправляет статус: 404 — самостоятельная проблема, её решает не атрибут, а доступность адреса. /b объявляет канонической страницу, которой нет, — это строка для проверки, а не автоматическая команда массово переписать все canonical. Таблица не различает причину: цель могла исчезнуть после переезда, а могла никогда не существовать. Причину уточняет человек, у которого есть бизнес-контекст.

Разберите цепочку и содержимое

/c объявляет /d, а /d объявляет /a. Это два перехода до цели при разных группах C, D и A. Такая строка попадает в список на проверку, потому что неясно, какая страница действительно основная и совпадает ли содержимое. Яндекс описывает это как объединение страниц в группу дублей с выбором одной, наиболее информативной и релевантной запросу Канонический адрес страницы | Вебмастер.

Робот Яндекса воспринимает указание на канонический адрес как рекомендацию и может проигнорировать его Канонический адрес страницы | Вебмастер. В частности, указание игнорируется, если содержимое канонической страницы значительно отличается от неканонической Канонический адрес страницы | Вебмастер. Поэтому строка с расхождением групп — не доказанный дефект, а повод проверить текст и назначение.

Цепочка из двух переходов — не приговор. Она означает, что в журнале проверок у разработчика должно стоять отдельное задание: подтвердить основную страницу, убрать промежуточный переход или обосновать его. Массовая правка всех строк сразу скрывает настоящую причину и создаёт новые расхождения.

Передайте ИИ журнал и проверьте результат

Агент получает только таблицу и правила, ничего не меняет на сайте и не публикует. Его результат — журнал конфликтов с основаниями и явными неизвестными. Промпт ниже работает сам по себе: в нём есть входные строки, правила, схема вывода и допущения.

Ты помощник по проверке таблицы URL и объявленных canonical. Работай только по входу ниже. Не добавляй неизвестные значения, не меняй сайт и не публикуй ничего.
Правила: 1) относительные адреса нормализуй к base, значимые параметры сохраняй; 2) self-canonical допустим; 3) копия той же группы, ведущая на доступный URL, допустима; 4) цель с HTTP 404 — конфликт строки, но статус 404 у самой строки отмечай как отдельную проблему индексируемости; 5) цепочку переходов и разные группы помечай как строку на проверку, не как установленную ошибку; 6) выбранный поиском canonical в экспорте отсутствует — не угадывай его.
Верни JSON: { "rows": [{ "url", "verdict", "reason" }], "unknowns": [строки], "exceptions": [строки], "search_engine_selected_canonical": "unknown_not_in_export" }.
Схема verdict: "no_table_conflict" | "review" | "not_indexable". В reason — короткое основание со ссылкой на вход.
INPUTS: {"base": "https://example.org", "rows": [{"url": "/a", "status": 200, "indexable": true, "canonical": "/a", "group": "A"}, {"url": "/a?sort=1", "status": 200, "indexable": true, "canonical": "/a", "group": "A"}, {"url": "/b", "status": 200, "indexable": true, "canonical": "/gone", "group": "B"}, {"url": "/gone", "status": 404, "indexable": false, "canonical": null, "group": null}, {"url": "/c", "status": 200, "indexable": true, "canonical": "/d", "group": "C"}, {"url": "/d", "status": 200, "indexable": true, "canonical": "/a", "group": "D"}]}

Эталонный результат для этой же таблицы:

{
  "rows": [
    { "url": "/a", "verdict": "no_table_conflict", "reason": "self-canonical допустим" },
    { "url": "/a?sort=1", "verdict": "no_table_conflict", "reason": "параметрическая копия той же группы A указывает на доступную /a" },
    { "url": "/b", "verdict": "review", "reason": "цель /gone возвращает 404" },
    { "url": "/gone", "verdict": "not_indexable", "reason": "404 — отдельная проблема URL, canonical не исправляет статус" },
    { "url": "/c", "verdict": "review", "reason": "цепочка /c → /d → /a, группы C, D, A различны" },
    { "url": "/d", "verdict": "review", "reason": "группы D и A различны" }
  ],
  "unknowns": ["выбранный поиском canonical"],
  "exceptions": [],
  "search_engine_selected_canonical": "unknown_not_in_export"
}

Независимую сверку графа переходов и статусов поручите коду или отдельному агенту и сравните с ответом модели, а расхождения вынесите в отдельный список. Ручной подсчёт остаётся необязательным способом разобрать маленький учебный пример. Шесть строк входа должны дать шесть строк выхода. Эталон — не ответ реально запущенной модели, а ожидаемый результат для проверки.

Учебный пример

Отдельно о том, что показывает эталон и чего он не доказывает. Экспорт объявленного canonical не говорит, какой URL выбрали Google или Яндекс: это разные величины. Строка search_engine_selected_canonical остаётся unknown_not_in_export, пока вы не запросите выбор робота отдельно — через инструменты диагностики поиска или панель вебмастера.

Выбранный роботом адрес проверяется по индексу, а не по вашей выгрузке. Яндекс предлагает смотреть исключённые страницы в разделе индексирования и упоминает Clean-param для адресов с параметрами и метками Канонический адрес страницы | Вебмастер. Google советует внутренние ссылки направлять на канонические, а не на дубли Как указать канонический URL с помощью атрибута rel="canonical" и другими способами | Центр Google Поиска.

Общий совет Disallow вместо исследования индексации здесь не годится: это скрывает страницы из обхода и не решает конфликт canonical. Границы задачи простые. Группы контента заданы условно — в реальном проекте сходство требуется проверять. Журнал из шести строк не заменяет аудит сайта и не является отчётом о запуске модели. Когда падают клики, а в выгрузке остаются такие строки, следующий шаг — проверить индекс и запросить выбранный роботом canonical, а не переписывать атрибуты по всей таблице. Смежные задачи разбирают разбор падения кликов в Search Console и потерю UTM-меток после редиректа.