Каталог переехал из /shop/ в /catalog/. Посетитель уже видит новые хлебные крошки, но в JSON-LD — структурированных данных страницы для поисковых систем — остались старые ссылки. Это происходит, когда видимая навигация и разметка получают адреса из разных настроек или одна из них осталась в кеше.
Откройте конкретную карточку товара и сравните оба пути. Хлебные крошки показывают место страницы в структуре сайта; они не заменяют canonical и не определяют сами по себе, какой адрес должен индексироваться.
Сравните названия и адреса каждого шага
Допустим, на странице светильника получилось так:
| Шаг | Видимая ссылка | Адрес в JSON-LD | Нужный адрес |
|---|---|---|---|
| Каталог | /catalog/ | /shop/ | https://example.com/catalog/ |
| Освещение | /catalog/lighting/ | /shop/light/ | https://example.com/catalog/lighting/ |
Откройте новые ссылки и убедитесь, что они ведут в соответствующие разделы. Нельзя исправить разметку заменой одного префикса, если при переезде изменились также названия и адреса отдельных категорий.
Для товара в нескольких категориях выясните, какой путь сайт показывает как основной. Возможны и несколько осмысленных путей. Важно, чтобы каждый отражал настоящую структуру, а не случайную страницу, с которой пришёл текущий посетитель.
Прочитайте все BreadcrumbList на странице
Найдите BreadcrumbList — описание цепочки хлебных крошек — во всех блоках JSON-LD. Один может выводить шаблон, другой — SEO-плагин. Исправленный блок не устраняет старые ссылки во втором. Проверьте исходный HTML и результат после выполнения JavaScript, если разметка создаётся в браузере.
Сохраните name, position и item каждого шага. Нумерация начинается с 1 и отражает порядок пути. Адрес должен соответствовать указанному разделу, а не вести на главную по общей заглушке.
В требованиях Google item у последнего шага может отсутствовать: тогда используется URL содержащей страницы. Поэтому отсутствие этого поля в последнем элементе само по себе не повод дописывать ошибку в отчёт. Подробности есть в документации BreadcrumbList.
Исправьте генератор и источник категорий
Попросите разработчика определить, откуда разметка берёт старый путь. Возможные места — поле категории, настройка плагина, жёстко записанный адрес в шаблоне или кеш. Обновление видимого меню не обязательно меняет эти данные.
Пример разметки для нового пути:
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem", "position": 1, "name": "Каталог",
"item": "https://example.com/catalog/"
},
{
"@type": "ListItem", "position": 2, "name": "Освещение",
"item": "https://example.com/catalog/lighting/"
},
{ "@type": "ListItem", "position": 3, "name": "Светильник Пример" }
]
}Замените пример собственными данными. После очистки кеша проверьте обычное сохранение товара в CMS: старый адрес не должен появиться снова при штатном обновлении карточки.
Отдельно проверьте старые URL
Изменение JSON-LD не настраивает редиректы. Если раздел перенесён, старый адрес должен обрабатываться согласно плану переезда. Проверьте, куда он ведёт и нет ли цепочки лишних перенаправлений.
Внутренние ссылки лучше вести сразу на действующий адрес. Просмотрите меню, ссылки в тексте и карту сайта: старые пути могут остаться там независимо от крошек. При удалении категории без замены поведение будет другим, чем при простом переименовании.
Проверьте карточку при разных способах входа
Откройте товар напрямую, затем через новую категорию и через старую сохранённую ссылку. Разметка должна описывать нужный путь в каждом случае, без зависимости от истории текущего сеанса. Для другой категории повторите ту же проверку на отдельном товаре.
Вставьте публичный URL в Rich Results Test Google и запустите проверку. Откройте найденные хлебные крошки, посмотрите ошибки и порядок элементов. Сохраните этот результат вместе с таблицей исправленных адресов. О других несоответствиях — в разборе ошибок Schema.org, о построении разметки — в руководстве по структурированным данным. После переезда проверьте затронутые страницы техническим аудитом.