На недавнем отраслевом эфире Рейтинга Рунета эксперты рынка два с половиной часа обсуждали первый черновик отраслевого стандарта 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-таблицы (<table>) в разы точнее, чем вёрстку на вложенных блоках <div> или маркированных списках <ul>. Табличная структура сохраняет семантическую связь атрибута и его числового значения даже при дроблении страницы на отдельные чанки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

import re
from typing import Dict, Any

def 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[\d\s]*)\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. Создавайте цифровой паспорт компании как эталон фактов: если нейросеть рекомендует вас, но называет устаревшие цены или условия, бизнес теряет лиды ещё до первого звонка в отдел продаж