Видимые хлебные крошки на странице и BreadcrumbList в JSON-LD — два разных слоя, их путают постоянно. Разметка может быть идеальной, зелёная галочка в Rich Results Test — и крошки в выдаче всё равно не появятся, потому что показывать их или нет решает алгоритм, а не твой тег. Разбираю, что реально ломает BreadcrumbList, чем отличается поведение Google от Яндекса, и свою ошибку с last item, которую полгода не замечал на одном сайте из портфолио.
Ставишь BreadcrumbList, прогоняешь через Rich Results Test — всё зелёное, ни одной ошибки. Открываешь выдачу по своему же запросу, а под сниппетом вместо «Главная › Каталог › Насосы» висит голый URL домена с косой чертой. Крошки то есть у конкурента на три позиции ниже, то нет у тебя. Бесит — потому что кажется, что ты сделал всё правильно, а Google просто не считается.
Два слоя, которые путают постоянно
Первый слой — видимые крошки на самой странице, HTML-навигация типа той, что висит у нас в верху этой статьи: «Главная → Блог → Микроразметка и техничка». Это для человека, обычный UX-элемент, никакого отношения к структурированным данным не имеет сам по себе.
Второй слой — JSON-LD с типом BreadcrumbList, массив ListItem с позицией, именем и ссылкой. Это для машины. Google читает именно его, чтобы решить, рисовать ли путь в сниппете вместо домена. Путаница начинается, когда эти два слоя расходятся: на странице крошки ведут по одному пути, а в разметке прописан другой — например, после переезда раздела в структуре каталога забыли обновить JSON-LD, а видимую навигацию обновили. Google это видит как несогласованность сигналов и в лучшем случае просто не берёт разметку в расчёт.
Google решает сам — показывать или нет
Вот здесь на самом деле и кроется главный источник разочарования. Валидная разметка — это билет на лотерею, не гарантированный результат. Google прямо пишет в документации по rich results: даже при полностью корректной разметке отображение не гарантируется, решение принимает алгоритм на основе множества сигналов — качество страницы в целом, соответствие мобильным требованиям, общая репутация домена. Будет расти аудит и технически безупречной разметки, и Google всё равно может предпочитать показывать голый URL — просто потому что домен в целом не набрал нужных баллов доверия.
Отсюда вывод, который сложно принять: нельзя «починить» крошки только правкой JSON-LD, если корень проблемы — слабый сайт в целом. Но в 80% случаев, которые реально разбираю на аудитах, причина банальнее — не в доверии к домену, а в конкретной ошибке разметки.
Чеклист: что реально ломает разметку
| Ошибка | Почему это проблема | Как чинить |
|---|---|---|
У последнего ListItem (текущая страница) указан item с URL | По руководству Google последний элемент — это сама страница, у неё поле item быть не должно, только name. Лишний URL — сигнал кривой разметки | Удалить item у последнего элемента массива, оставить только name и position |
URL в item не совпадает с видимой ссылкой крошки на странице | Рассинхрон между разметкой и тем, что реально на странице — Google может просто игнорировать блок целиком | Генерировать JSON-LD из той же структуры данных, что рендерит видимую навигацию, не вручную отдельным куском |
| Пропущен промежуточный уровень иерархии | Крошки «Главная → Статья» вместо «Главная → Блог → Категория → Статья» — технически валидно, но не несёт пользы, Google реже берёт такое в сниппет | Прописывать полный путь, который реально отражает структуру сайта, не сокращённый вариант |
Нумерация position не последовательна или с пропуском | 1, 2, 4 вместо 1, 2, 3 — формальная ошибка валидатора, в Rich Results Test иногда проскакивает незамеченной | Генерировать позиции программно по индексу массива, не руками |
| Разные URL в BreadcrumbList и в canonical страницы | Ещё один сигнал нестыковки для краулера — какая версия страницы «настоящая» | Брать URL для последнего (или любого) ListItem из того же источника, что и canonical-тег |
Яндекс ведёт себя иначе
У Яндекса логика мягче в одном и жёстче в другом. Мягче — потому что Яндекс может построить крошки в выдаче сам, опираясь на структуру URL сайта, даже без единой строчки микроразметки, если структура путей читается однозначно (например, /catalog/nasosy/model-x/). Жёстче — потому что если микроразметка есть, но противоречит тому, что Яндекс видит по URL, предпочтение часто отдаётся его собственному разбору структуры, а не твоему JSON-LD.
Практический вывод для сайтов, которые работают на оба рынка: не рассчитывай, что одна и та же разметка даст идентичный результат в обоих поисковиках. Для Яндекса не менее важна человеко-читаемая структура URL сама по себе, чем формальный BreadcrumbList.
Моя ошибка, которую не замечал полгода
На одном из сайтов из портфолио (не будем уточнять, каком — архив кейсов и так открыт) крошки не показывались вообще ни по одному запросу, при этом Rich Results Test был зелёный каждый раз, когда проверял. Дело было в последнем ListItem — он шёл с полем item и полным URL текущей страницы, потому что генератор разметки на движке сайта просто копировал логику с предыдущих элементов массива без исключения для последнего. Валидатор это не ловит как ошибку — формально массив ListItem валиден. А по факту это ровно тот случай «технически правильно, но Google такое недолюбливает», про который пишут в их собственных рекомендациях мелким шрифтом.
Убрал item у последнего элемента — через три недели крошки начали появляться по части запросов. Не у всех сразу, процентов 30-40 выдачи по этому сайту на тот момент. Три недели — это нормальный срок для переоценки сигналов, не жди эффекта на следующий день после правки.
Ты вообще в последний раз запускал Rich Results Test после того, как переделывал структуру каталога или категорий? Или разметка живёт на автопилоте с момента первой настройки, а ты просто веришь, что раз работало тогда — работает и сейчас?
Больше по теме разметки: обзор типов Schema.org, разметка отзывов Review и AggregateRating и как работает canonical и когда его игнорируют.