Каталог перенесли из /shop/ в /catalog/. В меню и на карточках новые ссылки, но хлебные крошки в JSON-LD продолжают описывать старую структуру. Посетитель этого не замечает, потому что два представления навигации создают разные модули. Проверка начинается с их сопоставления, а не с удаления всей разметки.
Хлебные крошки показывают место страницы в структуре сайта. Их назначение отличается от canonical и карты сайта: это навигационный путь, а не список всех адресов и не способ назначить основную версию документа. Рассмотрим учебный магазин с разделом «Освещение» и карточкой настольной лампы.
Зафиксируйте видимый путь до товара
Откройте карточку без авторизации и перепишите крошки в том порядке, который видит посетитель. Например: «Главная → Каталог → Освещение → Настольная лампа». Для каждого кликабельного элемента сохраните фактический href, а не адрес, который вы ожидали увидеть. Текущая карточка может быть последним текстовым элементом без ссылки.
Нажмите на раздел «Освещение»: он должен приводить к понятному списку соответствующих товаров. Если ссылка открывает общий каталог, навигация потеряла смысл даже при правильном статусе 200. Проверьте, что название элемента соответствует странице назначения, а не осталось от удалённой категории.
Запишите конечный URL после всех перенаправлений. Ссылка на старый раздел может пока работать через редирект, скрывая незавершённую миграцию. Для диагностики важно сохранить и исходное назначение ссылки, и конечный адрес: эти значения отвечают на разные вопросы.
Найдите все варианты BreadcrumbList
Посмотрите исходный HTML и DOM после выполнения JavaScript. Найдите BreadcrumbList, затем каждый ListItem внутри itemListElement. Разметка может быть в JSON-LD, микроданных или другом поддерживаемом формате; ограничиваться поиском одного скрипта недостаточно.
Если тема и SEO-модуль выводят два маршрута, выясните, намеренно ли это сделано. У товара действительно могут быть несколько навигационных путей: например, через тип изделия и через коллекцию. Несколько списков не являются автоматической ошибкой, если каждый описывает осмысленную структуру. Но маршрут через удалённую категорию требует исправления.
Составьте таблицу «видимый элемент → адрес ссылки → name в разметке → item в разметке». В учебном случае расхождение обнаружится сразу: видимая ссылка указывает /catalog/lighting/, а item — /shop/light/. Сохраните пример до внесения изменений, чтобы повторная проверка имела конкретный предмет.
Проверьте адреса, порядок и последнюю крошку
В каждом списке должны быть понятные названия элементов и последовательные позиции. После удаления промежуточной категории проверьте, что генератор не сохранил старый номер и старое название. Порядок в массиве и значения position должны описывать один путь, который можно объяснить посетителю.
Адрес раздела должен относиться к соответствующей странице сайта. Не подставляйте URL изображения, адрес поисковой формы или фрагмент карточки вместо страницы категории. Для ссылок удобно использовать абсолютные адреса с принятой схемой и основным хостом, чтобы результат не зависел от места вставки фрагмента.
В документации Google по BreadcrumbList описаны свойства элементов и допустимость отсутствия item у последней крошки. Поэтому валидатор, который не видит ссылку на текущую страницу в последнем элементе, ещё не доказывает ошибку. Проверяйте требования к конкретному положению элемента.
Обновите генератор, а не отдельную карточку
Причина старых адресов часто находится в шаблоне, настройках базового пути или отдельном кеше навигации. Найдите функцию, которая строит item, и сравните её источник с источником видимых крошек. Ручная замена JSON-LD в одной карточке не исправит другие товары и может исчезнуть после следующего обновления.
Для карточек с несколькими категориями определите правило выбора пути. Это может быть основная категория товара или явно настроенная иерархия. Случайная первая запись из базы создаёт нестабильный маршрут: один и тот же товар начинает менять крошки после импорта, хотя его назначение не изменилось.
Если URL берётся из старого поля CMS, мигрируйте данные либо переведите генератор на действующий источник. Проверьте языковые версии, региональные поддомены и работу кеша. В задаче разработчику укажите не только устаревший пример, но и правило, которое должно действовать для следующих карточек.
Проверьте перенаправления старых категорий
Исправление крошек не отменяет работу со старым URL. Если раздел переехал и сохранил назначение, старый адрес обычно должен вести к соответствующей новой странице. При отсутствии подходящей замены решение зависит от судьбы раздела; перенаправление всех удалённых категорий на главную плохо объясняет посетителю, куда исчез нужный ассортимент.
Проверьте старые адреса из разметки отдельно. Запишите статус, цепочку переходов и конечное содержимое. Старый раздел может вернуть 200 с пустым шаблоном, попасть в цикл или отправить на нерелевантную категорию. Все эти случаи требуют собственной задачи, даже если после обновления JSON-LD старый URL больше нигде не упоминается.
Новые ссылки в крошках желательно направлять сразу на действующие адреса. Правильный редирект полезен для прежних ссылок и закладок, но не является основанием оставлять устаревший путь в генераторе. Так навигация и техническая история миграции остаются согласованными.
Выберите выборку по устройству каталога
Не проверяйте только товар с простой иерархией. Добавьте карточку из вложенной категории, товар с несколькими категориями, страницу коллекции и раздел после переименования. Если у магазина есть другой язык, включите его в выборку: базовый домен может обновиться в одной версии и остаться прежним в другой.
Для каждого адреса проверьте путь в интерфейсе, данные разметки и конечные страницы разделов. Отдельно откройте карточку через поиск и прямую ссылку. Если крошки зависят от предыдущего действия посетителя, нужно понять, какое постоянное представление публикуется в HTML без этой истории переходов.
После очистки кеша повторите ту же выборку. В учебном магазине критерием будет отсутствие /shop/ в новых навигационных данных и соответствие «Освещения» действующему разделу. Само увеличение количества найденных структурированных элементов не является целью приёмки.
Отделите исправление от появления оформления в поиске
Тест расширенных результатов помогает проверить поддерживаемую Google разметку на доступной странице. Он не обещает, что поисковая выдача немедленно покажет нужный путь. Между исправлением, новым обходом и изменением отображения может пройти время, а выбор представления остаётся за поисковой системой.
В отчёте для команды разделите два результата: «генератор публикует согласованный маршрут» и «внешняя система обработала изменение». Первое можно проверить сразу на странице; второе требует наблюдения. Не закрывайте задачу только по красивому сниппету и не объявляйте исправление неудачным лишь потому, что выдача ещё старая.
В разборе ошибок Schema.org описаны дополнительные проверки структуры. Общее руководство по разметке поможет отличить хлебные крошки от сведений о товаре, организации и статье, которые могут находиться рядом в одном графе.
Добавьте крошки в приёмку следующей миграции
Перед будущим переносом каталога выгрузите используемые категории и сохраните несколько типовых маршрутов. После изменения сверяйте меню, видимые крошки, JSON-LD и внутренние ссылки как отдельные источники. Наличие правильного меню не подтверждает автоматически правильную разметку карточек.
Для повторного сбора технических сведений можно использовать аудит страницы, а окончательную навигационную модель согласовать с владельцем каталога. Особенно важно сделать это при объединении разделов: технически действующий URL не всегда является подходящей ступенью маршрута для покупателя.
Хороший результат — посетитель и машина получают понятное описание одной структуры. В карточке нет скрытого пути через удалённые разделы, у старых адресов определена судьба, а новые товары получают корректные крошки из действующих данных автоматически.