Как мы перестали делать из JSON-LD «кашу» для SEO и создали машиночитаемый слой знаний для LLM
Мы только что закончили внедрение Schema.org для B2B-клиента из сферы промышленного оборудования. Все валидаторы выдавали зеленые чеклисты. Google Search Console не показывала ни одной ошибки и щедро раздавала расширенные сниппеты по всему каталогу.
Затем я запустил тест в ChatGPT-4o с просьбой сравнить характеристики флагманских промышленных насосов клиента.
Полный провал.
Модель выдумала половину технических допусков и подтянула гарантийные условия прямого конкурента. Мы работали с LLM как с обычными поисковиками, и это вышло нам боком.
Почему токенизация ломает сложные форматы
Суть проблемы проста:
LLM не читают веб-страницы. Они читают токены.
Когда ИИ-краулер сканирует сайт, он не видит аккуратный вложенный JSON-LD скрипт, как в DOM-инспекторе. Он стирает всю структуру, разбивая сырой текст на субсловные токены.
Мы выгрузили на страницу стандартную разметку Schema.org, наивно полагая, что нейросеть сохранит вложенную иерархию связанных сущностей.
Она этого не сделала.
Токенизация просто сплющила эти связи. Модель распознала отдельные термины, но потеряла предикатную логику между узлами. Получилась статистическая каша.
Это как дать человеку алфавитный глоссарий и ждать, что он перескажет сюжет технического руководства.
Обычной SEO-разметки уже мало. Если модель теряет связи сущностей при токенизации, ваши структурированные данные бесполезны.
Меня откровенно достали советы в духе «просто добавьте больше схемы». Установка типовых SEO-плагинов не решает проблему деградации связей при обработке токенов.
Если LLM не способна восстановить точные связи сущностей из потока байтов, вашего бренда для генеративного ответа просто нет.
Почему классическая Schema.org не работает в Generative Engine Optimization
Используют ли LLM разметку JSON-LD вообще?
Современные языковые модели активно опираются на структурированные данные JSON-LD в связке с графами знаний, чтобы извлекать точные связи сущностей без галлюцинаций.
Да, ИИ читает структурированные данные. Но он потребляет их иначе, чем классический поисковый робот, собирающий инвертированный индекс.
Большинство команд воспринимают Schema.org как формальный чеклист: воткнули Article, добавили блок FAQ и ждут сниппетов. Это работало для Google в 2020 году. Для Generative Engine Optimization сегодня это не годится.
Модели заходят на сайт не ради красивой разметки. Они ищут прямые связи между узлами.
Но даже понимая это, разработчики часто сами себе вредят перегруженным кодом.
Конфликт плагинов: дублирование и лишний вес
Недавно я провел три часа, разбирая e-commerce сайт на 15 000 SKU. Владельцы не понимали, почему Perplexity упорно игнорирует базовые спецификации их товаров.
В исходном коде творился полнейший хаос.
На сайте одновременно работали три плагина WordPress: один отвечал за метаданные, второй за отзывы, третий остался от старого магазина. Каждый генерировал собственный несогласованный блок @context. В итоге одна карточка товара отдавала три конфликтующих блока @type: Organization и дубликаты узлов с разными валютами.
Из-за циклических повторов разметки вес JSON-LD превысил 400 КБ еще до того, как бот доходил до основного контента.
Проблема очевидна: ИИ-краулеры жестко ограничены по лимитам токенов и таймаутам запросов. Наткнувшись на полмегабайта избыточного JSON, бот просто обрезает код или превращает его в неразобранный шум.
Отсюда вытекает главная загвоздка:
Большинство ИИ-краулеров не исполняют клиентский JavaScript.
Если отзывы или данные подгружаются лениво через динамические скрипты внизу страницы, бот видит лишь пустую оболочку. Обычный робот Google еще может отрендерить JS во вторичной очереди. Бот LLM, выполняющий поиск в реальном времени, ждать не станет.
Если данных нет в статическом HTML с первого байта, для машины их не существует.
Смена парадигмы: структурированные данные как слой знаний
Десять лет мы воспринимали JSON-LD как визуальную приманку. Добавил сниппет, скрестил пальцы и ждешь звездочек рейтинга или выпадающих списков в выдаче Google. Обычный косметический трюк.
Это время ушло.
Сегодня разметка служит базовым слоем знаний для языковых моделей, а не генератором сниппетов.
ИИ-движку не нужны картинки в высоком разрешении. Ему требуются однозначные факты: четкие узлы, валидированные свойства и конкретные связи. Если полагаться только на обычный текст, модель будет угадывать смысл по законам статистики.
Выход за рамки стандартного RAG
Многие считают, что классический RAG закрывает любые задачи. Закинул неструктурированные статьи в векторную базу, применил косинусное сходство, вытащил чанки и отдал на откуп LLM.
Но на практике это постоянно дает сбой.
Мы провели прямое сравнение: обычный векторный RAG против чистого графа знаний на JSON-LD при ответах на сложные вопросы по специализированному B2B-каталогу.
Векторный RAG отработал грязно. Он надергал разрозненных кусков, перепутал цены у похожих артикулов и выдал ложные характеристики из-за нечеткого описания в тексте.
Затем мы скормили модели выверенный граф JSON-LD.
Ноль галлюцинаций. Мгновенная идентификация сущностей. Модель сразу поняла иерархию, вложенные параметры и связи продуктов без лишнего расхода токенов контекста.
Векторный поиск находит похожий текст, но структурированные данные дают машине контекст. RAG выдает модели сырые ингредиенты, а правильная структура JSON-LD — готовый чертеж. Чтобы нейросеть ссылалась на вас без ошибок, прекратите кормить ее простынями текста и встраивайте слой знаний прямо в код страницы.
Наш фреймворк JSON-LD для видимости в ИИ
Как проверить, видит ли LLM вашу разметку JSON?
Чтобы убедиться в видимости JSON Schema для LLM, нужно анализировать логи сервера. Ищите user-agent ИИ-краулеров вроде GPTBot или ClaudeBot и проверяйте, загружают ли они статический HTML с вашим кодом JSON-LD. Панель Google Search Console здесь бесполезна, так как она фиксирует только классический поиск.
GSC ничего не знает о том, разобрали ли парсеры OpenAI или Anthropic сущность Organization. Консоль видит лишь Googlebot и стандартную выдачу.
Мы отказались от GSC для этих целей и настроили фильтрацию логов под запросы от GPTBot, ClaudeBot и PerplexityBot. Мы отслеживаем не статус индексации, а сырое тело ответа сервера.
Если бот забрал статичный HTML с единым графом JSON-LD, данные прочитаны. Если JSON-LD собирался через клиентский JavaScript после гидратации, бот фиксировал 200 OK, видел пустоту и уходил.
Разметка Organization и FAQPage для нейросетей
Для стабильного попадания в генеративную выдачу нужна строгая структура. Хаотичное добавление всех типов Schema подряд создает только шум.
Вот схема, которую мы используем на практике:
- Organization Schema (Якорь): Внедряется глобально на весь домен. Задает идентификатор бренда, сообщает модели, кто именно говорит, и связывает сущность с Wikidata ID и внешними авторитетными профилями через
sameAs. - Article / TechArticle Schema (Контекст): Без лишней воды. Упор на
author,datePublishedи явные массивыabout/mentions, привязывающие тему страницы к заданным узлам сущностей. - FAQPage Schema (Прямой источник): LLM отлично считывают детерминированный формат «вопрос-ответ». Мы переносим ключевые технические параметры и спецификации в пары Question/Answer прямо внутри структуры JSON-LD.
На этапе доставки данных ошибаются чаще всего.
Нельзя полагаться на клиентский рендеринг при работе с ИИ-ботами.
Мы убедились в этом на клиенте, у которого схема FAQ генерировалась динамически через React. Краулеры забирали первичный ответ сервера и закрывали соединение, не выполняя скрипты.
Правило простое: JSON-LD обязан присутствовать в статическом HTML-коде с самого первого байта. Никакой отложенной гидратации и клиентских скриптов.
Хватит оптимизировать под Google, пора проектировать под сущности
Классическая поисковая оптимизация уперлась в потолок. Фокус на синих ссылках не учитывает современные механики поиска. Происходит переход на уровень Machine-to-Machine коммуникации.
Пользователи перестают кликать по сайтам, если ИИ-ассистент собирает готовый ответ, сравнивает варианты и закрывает задачу прямо в чате. Если ассистент не может проверить параметры через разметку, ваш бренд просто не попадет в выборку.
Будущее M2M SEO
Когда разметку лепят как заплатку поверх раздутого DOM-дерева, она сжигает окно контекста. Разбор шумных токенов повышает задержку и вынуждает модели строить догадки вместо опоры на факты.
Если боту приходится угадывать связи сущностей из неструктурированного текста, он просто предложит пользователю вашего конкурента.
В AnswerShaper мы смотрим на разметку как на прямое API для автономных агентов, а не просто надстройку для SEO. Связывая плотные графы сущностей в статичном коде, вы убираете двусмысленность и отдаете проверенные данные с минимальным расходом токенов.
Игнорируя M2M-взаимодействие в SEO, вы работаете на уходящий формат выдачи. Вас либо цитирует генеративный ответ, либо вас нет на рынке. Заложите машиночитаемый слой знаний в архитектуру сайта сейчас или останьтесь невидимками для генеративного веба. Читайте наш подробный разбор Как мы перестали сжигать токены и перешли на Knowledge Graph Optimization для ИИ, чтобы изучить наш стек работы с сущностями.