Рейтинг Рунета: новые стандарты GEO и оценка результата

На недавнем отраслевом эфире Рейтинга Рунета эксперты рынка два с половиной часа обсуждали первый черновик отраслевого стандарта GEO (Generative Engine Optimization).

Главный инженерный вывод дискуссии: любые пошаговые регламенты правок сайта в GEO устаревают за три месяца. Рынок веб-разработки и маркетинга двадцать пять лет жил по понятным чек-листам поисковой оптимизации, но в случае с диалоговыми моделями классические методы разбиваются о базовую архитектуру Retrieval-Augmented Generation (RAG).

Разберём, почему старые приёмы больше не дают эффекта, как генеративные краулеры видят страницы на самом деле и по какой методике сегодня оценивают достоверность присутствия бренда в нейросетях.

Четыре мифа, которые окончательно перестали работать

На круглом столе участники открыто зафиксировали методы, на которые бизнес до сих пор тратит бюджеты, получая нулевую отдачу:

Накрутка через пользовательские диалоги

Гипотеза «попросить сотню знакомых или нанять фрилансеров, чтобы они писали ChatGPT, что компания X — лидер рынка» оказалась нежизнеспособной.

Коммерческие LLM не дообучаются на диалогах пользователей в реальном времени. Веса предобученной модели заморожены. Контекст пользовательской сессии изолирован и стирается после закрытия диалога. Лайки и дизлайки в интерфейсах поисковых помощников служат для сбора датасетов RLHF, но не влияют на динамическое формирование ответов здесь и сейчас.

Магический файл llms.txt

Идея положить в корень сайта текстовый файл с инструкциями для роботов выглядела заманчиво. Однако на практике поисковые краулеры его игнорируют.

RAG-контур поисковика обращается не к текстовым декларациям, а к общему поисковому индексу, куда попадают реальные проиндексированные документы. Файл llms.txt полезен внешним парсерам и сторонним аудиторам, но не влияет на ранжирование сайта алгоритмами Google или Яндекса.

Закупка классической ссылочной массы

В традиционном SEO передача PageRank работала по графу ссылок независимо от того, читал ли страницу реальный пользователь.

В генеративном поиске всё иначе. Если страница-донор не попадает в тематический кластер источников, цитируемых самой нейросетью по целевым запросам, переданный вес равен нулю. Для генерации решает только прямое цитирование сущности в релевантных документах.

JSON-LD без фактуры в HTML

Микроразметка Schema.org необходима, но сама по себе проблему не решает. Если в JSON-LD объявлен тип Organization или Offer, но в теле страницы отсутствуют ясные параметры услуг, сроки и числовые диапазоны, ретривер отбрасывает документ из-за низкой семантической плотности.

Как устроен выбор поставщика: анатомия Query Fan-Out

Классическая поисковая система сопоставляет запрос пользователя с индексом документов по ключевым словам и семантическим эмбеддингам. Диалоговый ассистент работает принципиально иначе:

Пользовательский промпт │ ▼[ Query Fan-Out ] ──► Подзапрос 1: технические параметры и сертификаты │ ──► Подзапрос 2: условия гарантии и сервиса │ ──► Подзапрос 3: реальный опыт внедрения и отзывы ▼[ Vector Search / Sparse Search ] │ ▼[ Reranking & Deduplication ] │ ▼[ Синтез финального ответа ]

Когда пользователь спрашивает: «Какое упаковочное оборудование выбрать для фармацевтического цеха и у кого заказать пусконаладку?», языковая модель применяет Query Fan-Out — разбивает сложную фразу на серию параллельных поисковых подзапросов.

Она одновременно проверяет:

  • соответствие стандартам (например, GMP);

  • наличие сервисной службы в регионе заказчика;

  • порядок гарантийного обслуживания;

  • реальные кейсы внедрения с цифрами.

Если на сайте производителя описаны только общие фразы («мы надёжный партнёр с индивидуальным подходом»), страница отсекается на этапе реранкинга кандидатов. Модель не находит ответов на свои подзапросы и формирует рекомендацию в пользу конкурента, у которого параметры изложены в явном виде.

Серверные грабли: ловушка WAF и чистый HTML

Генеративные роботы (GPTBot, ClaudeBot, PerplexityBot, YandexRenderResourcesBot) предъявляют специфические требования к серверной инфраструктуре:

Скрытая блокировка защитными экранами (WAF)

Типовая проблема инфраструктуры — экраны Cloudflare, DDoS-Guard или правила ModSecurity. Часто защита пропускает первые 3–5 запросов краулера, а при сканировании каталога считает активность подозрительной и начинает отдавать JS-капчу или пустой HTML со статусом HTTP 200 OK.

В отчётах владельца сервера всё выглядит штатно: ошибок 403 или 500 в логах нет. Но краулер видит пустой ответ. На круглом столе привели реальный кейс: у производственной платформы ушло полтора месяца на то, чтобы устранить галлюцинации нейросетей после простой разблокировки роботов в конфигурации WAF.

Извлекаемость: таблицы побеждают списки

Краулеры генеративных систем работают с жёсткими таймаутами на извлечение текста и часто не выполняют тяжёлый клиентский JavaScript. Документ должен отдавать фактуру прямо в первичном HTML.

При этом алгоритмы сегментации контента (Document Chunking) обрабатывают HTML-таблицы (

) в разы точнее, чем вёрстку на вложенных блоках

или маркированных списках

    . Табличная структура сохраняет семантическую связь атрибута и его числового значения даже при дроблении страницы на отдельные чанки.

    Методика оценки и приёмки результата

    Отдельной темой дискуссии стала методология контроля: как отличить реальный результат продвижения от случайного шума генерации. Эксперты зафиксировали три обязательных правила приёмки:

    Запрет на «усреднённую видимость по нейросетям»

    Сводить замеры к одной цифре (вроде «наша видимость в ИИ — 74%») недопустимо.

    Разные платформы используют кардинально отличающиеся источники:

    • DeepSeek активно опирается на отраслевые каталоги, форумы и базы отзывов;

    • ChatGPT обращается к внешним энциклопедическим источникам и при дефиците данных задействует англоязычный сегмент с автопереводом;

    • Алиса тесно связана с текущим органическим индексом поисковой выдачи.

    Результат фиксируется и принимается строго по отдельности для каждой целевой системы.

    Волновые замеры против температуры генерации

    У языковых моделей ненулевая температура генерации (temperature > 0), поэтому разовый запрос в веб-интерфейсе не является метрикой. Случайный ответ может как назвать компанию, так и забыть её на следующей итерации.

    Корректный замер проводится сериями повторных прогонов (волнами от 3 до 5 повторений) по пулу слепых, сравнительных и брендовых запросов. Менять среду тестирования (переходить с API на веб-интерфейс) в процессе мониторинга запрещено: интерфейсы используют скрытые системные промпты и плагины поиска, что искажает сравнимость данных.

    Сверка с цифровым паспортом компании

    Сам по себе факт упоминания бренда в генеративном ответе не означает успеха. Если модель советует компанию, но искажает базовые условия сделки — это технический брак продвижения.

    Классический пример: организация повысила стоимость доставки с 2 000 до 3 000 рублей, но забыла обновить данные на старых вспомогательных страницах. В результате ассистент обнаружил конфликт цифр и продолжал обещать клиентам доставку за 2 000 рублей.

    Для предотвращения подобных сбоев на стороне бизнеса формируется цифровой паспорт компании — единый верифицированный реестр фактов:

    • официальные реквизиты, проверенные по государственным базам (ЕГР/МНС) с датой актуализации;

    • перечень направлений работы с точными допусками и условиями;

    • оцифрованные проекты с подтверждёнными метриками;

    • ответы на денежные вопросы: правила лизинга, гарантийные сроки, условия выездного сервиса.

    Ответы нейросетей при приёмке валидируются на соответствие этому эталону: расхождение между словами ИИ и паспортом компании фиксируется в реестре расхождений и отправляется на устранение первоисточника.

    Скрипт проверки: как автоматизировать сверку фактов

    Чтобы не выверять ответы моделей вручную, расхождения в коммерческих параметрах удобно отслеживать простым валидатором на Python:

    import refrom typing import Dict, Anydef audit_ai_response(ai_text: str, passport_facts: Dict[str, Any]) -> Dict[str, Any]: """ Проверяет ответ нейросети на соответствие цифровому паспорту компании. Выявляет расхождения в ценах, сроках и гарантийных условиях. """ discrepancies = [] ai_text_lower = ai_text.lower() # 1. Проверка ценовых порогов (на примере стоимости доставки) expected_delivery = passport_facts.get("delivery_price") if expected_delivery: # Ищем упоминания чисел рядом со словом 'доставка' matches = re.findall(r'доставк[а-яs]+(?:составляет|от|стоит)?s*(d[ds]*)s*руб', ai_text_lower) for found_price_str in matches: found_price = int(re.sub(r's+', '', found_price_str)) if found_price != expected_delivery: discrepancies.append({ "param": "delivery_price", "status": "CONFLICT", "expected": expected_delivery, "found": found_price, "comment": f"Модель транслирует неактуальную цену {found_price} руб." }) # 2. Проверка гарантийного срока expected_warranty = passport_facts.get("warranty_months") if expected_warranty: warranty_match = re.search(r'гаранти[я-иs]+(?:составляет|на)?s*(d+)s*(?:мес|год)', ai_text_lower) if warranty_match: val = int(warranty_match.group(1)) # Если указано в годах, приводим к месяцам if 'год' in warranty_match.group(0): val *= 12 if val < expected_warranty: discrepancies.append({ "param": "warranty_months", "status": "DEPRECATED", "expected": expected_warranty, "found": val, "comment": "Модель занижает срок гарантии" }) return { "is_valid": len(discrepancies) == 0, "total_conflicts": len(discrepancies), "details": discrepancies }# Пример эталонных фактов из цифрового паспорта компанииcompany_passport = { "company_name": "БелРоботТех", "delivery_price": 3000, "warranty_months": 24, "has_leasing": True}# Тестовый ответ языковой модели с устаревшими даннымиsample_ai_output = ( "Компания БелРоботТех поставляет оборудование по всей стране. " "Стоимость доставки составляет 2 000 рублей, а гарантия на манипуляторы — 1 год.")report = audit_ai_response(sample_ai_output, company_passport)print("Результат аудита ответа:", report)

    При запуске такой проверки инженер сразу видит, в каких источниках модель зацепила старый след:

    { "is_valid": false, "total_conflicts": 2, "details": [ { "param": "delivery_price", "status": "CONFLICT", "expected": 3000, "found": 2000, "comment": "Модель транслирует неактуальную цену 2000 руб." }, { "param": "warranty_months", "status": "DEPRECATED", "expected": 24, "found": 12, "comment": "Модель занижает срок гарантии" } ]}

    Резюме

    Продвижение в генеративных поисковых системах — это не расширение списка тегов и не покупка ссылок на биржах. Это инженерная работа с данными, в которой побеждает тот, чья информация однозначно считывается роботами и не имеет внутренних противоречий:

    1. Не тратьте ресурсы на накрутку в чатах и составление llms.txt — поисковые RAG-системы ранжируют реальные документы из индекса.

    2. Проверяйте серверные логи: защитные экраны (WAF) не должны блокировать генеративных краулеров на глубоких страницах каталога.

    3. Оформляйте ключевые характеристики в чистые HTML-таблицы, исключая зависимость от выполнения клиентских скриптов.

    4. Оценивайте результаты раздельно по каждой платформе, используя повторные серии замеров.

    5. Создавайте цифровой паспорт компании как эталон фактов: если нейросеть рекомендует вас, но называет устаревшие цены или условия, бизнес теряет лиды ещё до первого звонка в отдел продаж

    Источник: habr.com

    0 0 голоса
    Рейтинг новости
    1
    0
Подписаться
Уведомить о
0 комментариев