Что описывает разметка хлебных крошек
BreadcrumbList — это структурированные данные для видимой цепочки хлебных крошек: навигационного маршрута, который помещает текущую страницу в контекст. Это не замена архитектуре сайта, внутренним ссылкам или каноническому URL. Она описывает путь, которым может пользоваться и посетитель. Google может использовать подходящую разметку, чтобы показать в результатах контекстную иерархию, но внешний вид остаётся решением Google и зависит от поверхности выдачи.
Моделируйте цепочку как упорядоченную последовательность реальных навигационных выборов. У товара или статьи может быть больше одного осмысленного маршрута, а документация Google допускает несколько цепочек хлебных крошек для одной страницы. Полезный выбор — путь, который человек видит в контексте, из которого пришёл на страницу, а не выдуманная цепочка ярлыков с ключевыми запросами.
Как собрать разметку из видимой навигации
Начинайте с отрисованной страницы, а не с таблицы URL. Запишите видимую подпись и адрес каждого звена, затем решите, включать ли текущую страницу последним элементом ListItem. Для адресов назначения используйте абсолютные URL. Позиции держите последовательными, начиная с 1, а названия — краткими, понятными человеку и согласованными с интерфейсом страницы. Не размечайте иерархию, которой на странице нет.
{\n "@context": "https://schema.org",\n "@type": "BreadcrumbList",\n "itemListElement": [\n {"@type":"ListItem","position":1,"name":"Home","item":"https://example.com/"},\n {"@type":"ListItem","position":2,"name":"Guides","item":"https://example.com/guides/"},\n {"@type":"ListItem","position":3,"name":"Technical SEO","item":"https://example.com/guides/technical-seo/"}\n ]\n}Генерируйте этот JSON-LD по тем же данным, что отрисовывают компонент хлебных крошек, когда это возможно. Так исчезает частое расхождение, при котором переименованную категорию обновили в интерфейсе, а в разметке она осталась старой. Шаблон CMS не должен выводить BreadcrumbList там, где у страницы нет полезной цепочки, например на простой главной.
Проверка, выкладка и мониторинг
- Проверьте отрисованную цепочку на основной странице и убедитесь, что каждый адрес ведёт на нужный канонический URL.
- Сравните DOM, JSON-LD и информационную архитектуру: подписи, порядок и пути должны совпадать.
- Запустите Google Rich Results Test, а после выкладки проверьте URL в инструменте проверки URL в Search Console, чтобы убедиться, что Google может загрузить страницу без аутентификации, блокировки в robots.txt и noindex.
- После повторного сканирования проверьте отчёт Search Console об улучшениях для хлебных крошек и выборочно проверяйте шаблоны, а не считайте, что один валидный URL покрывает все шаблоны.
Относитесь к валидации как к проверке синтаксиса и доступности, а не как к доказательству того, что результат покажет хлебные крошки. Google прямо рекомендует выкатить несколько основных страниц, посмотреть, как их видит Google, и дать время на повторное сканирование. Изменение таксономии требует повторного прохода, потому что может сразу затронуть сотни цепочек.
Частые ошибки внедрения
Для практической проверки регрессий после каждого релиза навигации или таксономии берите по одному URL из каждого шаблона хлебных крошек. Сравните подписи в отрисованной странице, последовательность JSON-LD, канонический адрес назначения и HTTP-ответ. Такая короткая процедура ловит дрейф шаблона раньше, чем он превратится в широкую проблему в отчёте об улучшениях.
Храните запись этой проверки вместе с заметками о релизе: какой URL проверен, какой шаблон, результат и что делать дальше, если нужно. Тогда будущее предупреждение Search Console можно будет разобрать, не превращая разметку в SEO-обещание, которое нельзя проверить.