Ресторан есть в Google, но ИИ его не рекомендует: где теряется видимость

Поиск по названию проверяет, может ли система узнать конкретное имя. Сценарий гостя проверяет другое: считает ли система ресторан подходящим под место, бюджет, кухню, повод, ограничения в питании и время.

Запросы «Avli Bali» и «греческий ресторан в Убуде для ужина компанией из восьми человек» не равнозначны. В первом название уже дано. Во втором система должна сама выбрать ресторан среди альтернатив и объяснить, почему он подходит.

Для диагностики разделите путь на четыре этапа:

• Доступ: может ли система получить публичную информацию?
• Соответствие: есть ли страница, которая отвечает на конкретную потребность гостя?
• Включение: попал ли ресторан в ответ и какие источники показаны?
• Действие: может ли гость проверить факты и перейти к бронированию, звонку или маршруту?

Если свести эти этапы к одной цифре, владелец не увидит, что именно нужно исправить.

В официальной документации Google сказано, что для обзоров от ИИ (AI Overviews) и режима ИИ (AI Mode) не нужны дополнительные технические требования или специальная разметка структурированных данных. Обычные основы поиска Google остаются в силе: страница должна быть доступна для обхода и пригодна для индексации, важная информация должна быть в виде текста, а структурированные данные должны соответствовать видимому содержанию.

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

Источник: Google Search Central — AI features and your website

В препринте Бенджамина Танненбаума (Benjamin Tannenbaum) от 19 сентября 2026 года проанализированы 34 960 наблюдений по 2 854 отслеживаемым небрендовым запросам в GPT и Gemini. Когда в наблюдаемом пути поиска не было ни самого бренда, ни его домена, бренд упоминался в 2,8% ответов GPT и 3,8% ответов Gemini. Когда появлялась ссылка на собственный домен, но не было поискового подзапроса с названием бренда, доля упоминаний составляла 49,0% и 58,4%.

Автор прямо называет работу наблюдательной, а не причинной. Это не исследование ресторанов, выборка коммерческая (Aiso), и работа пока опубликована как препринт. Видимые ссылки к тому же не раскрывают весь внутренний поиск системы. Поэтому из исследования нельзя вывести «добавьте текстовое меню — и ИИ начнёт рекомендовать ресторан».

Источник: Benjamin Tannenbaum — From Prompt to Recommendation

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

Если ИИ не может получить нужную информацию, улучшайте доступ или содержание. Если информация доступна, но система стабильно выбирает конкурентов, сравнивайте реальные ответы и процитированные страницы. Если ресторан уже появляется, но сведения неверны или бронирование не работает, проблема в точности и в следующем шаге гостя, а не просто в «ранжировании».

Для первой диагностики не нужны сотни запросов. Возьмите пять действительно разных ситуаций гостя, проверьте их в двух ИИ-сервисах, которыми пользуется ваша аудитория, и повторите каждый запрос три раза. Получится 30 наблюдений.

Примеры сценариев:

1. Где спокойно поужинать вдвоём в районе [район]?
2. Какой ресторан в городе [город] подойдёт человеку, которому нужно вегетарианское меню или блюда без глютена?
3. Где забронировать стол на восемь человек после 20:00?
4. Какой ресторан рядом с [ориентир] открыт сегодня допоздна?
5. Где попробовать [блюдо] по средней цене?

Подставьте город, район, кухню и ограничения реальной аудитории ресторана. Не используйте пять пересказов запроса «лучший ресторан»: так вы пять раз проверите одну и ту же потребность.

Для каждого ответа запишите:

• назван ли ресторан и на каком месте, если в ответе есть порядок;
• кого рекомендуют вместо него;
• какие ссылки или источники показаны;
• может ли гость подтвердить меню, цену, часы работы и следующий шаг.

Не меняйте язык, город, страну доступа, режим сервиса и формулировку запроса. Если сервис не позволяет задать местоположение или не показывает источники, запишите это как ограничение, а не превращайте в ноль.

Сейчас Selena Systems разделяет проверку готовности сайта и проверку ответов ИИ. Они отвечают на разные вопросы, и их нельзя подавать как один замер.

Бесплатная публичная проверка готовности смотрит до пяти публичных страниц и открытые ресурсы для поисковых роботов. Она оценивает то, что видно на сайте: ответ сервера, правила robots.txt, канонические адреса, возможность индексации, структурированные данные, понятность описания бизнеса и путь клиента к действию. Она не обращается к платным ИИ-сервисам и не утверждает, что ChatGPT, Gemini или другая система рекомендует ресторан.

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

Отдельный модуль в тестовой среде один раз проверяет один домен, приведённый к единому виду, в ChatGPT и Gemini. Он доступен подтверждённой учётной записи, если она соответствует условиям. Сейчас клиент видит по каждой системе только два результата: упомянут ли домен и сколько ссылок на источники вернулось. Полный текст ответа и адреса источников не показываются, и это не аудит конкурентов.

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

После самопроверки выберите один задокументированный сбой, а не пытайтесь «улучшить всё».

• Страница недоступна или не индексируется. Исправьте конкретную проблему: robots.txt, блокировку на стороне сети доставки контента, канонический адрес или индексацию.
• ИИ не может подтвердить блюдо, цену или ограничение в питании. Добавьте актуальную информацию видимым текстом на официальную страницу. Изображение меню можно оставить, но оно не должно быть единственным источником факта.
• Сайт, карточка на карте и сервис бронирования противоречат друг другу. Определите верную версию и синхронизируйте часы работы, адрес, меню, контакты или правила бронирования.
• Конкуренты появляются, а ресторан — нет. Изучите страницы, которые реально процитированы в этих ответах. Разница — это гипотеза для проверки, а не доказательство, почему выиграл конкурент.
• Ресторан назван, но следующий шаг не работает. Исправьте кнопку, форму, телефон, ссылку на мессенджер или маршрут. Видимость без работающего действия — ещё не готовый путь к брони.

У каждого действия должны быть ответственный, срок, ссылка на исходное наблюдение и заранее определённая повторная проверка.

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

Сравнивайте по отдельности:

• Доля упоминаний: в скольких действительных ответах назван ресторан?
• Доля ссылок на официальный сайт: в скольких действительных ответах есть официальный домен?
• Точность фактов: сколько проверяемых утверждений совпадает с актуальным официальным источником?
• Полнота пути к действию: есть ли верный путь к бронированию, звонку или маршруту?
• Набор конкурентов: какие заведения появляются вместо ресторана в каждом сценарии?

Если упоминаний стало больше, корректная формулировка такая: «После изменения мы наблюдали рост с X из Y до A из B в сопоставимом повторном тесте». Не пишите автоматически, что рост вызвало изменение: за это время могли измениться сама система, её индекс и конкуренты.

Если ничего не изменилось, тест всё равно полезен. Он исключает одну гипотезу и не даёт дальше тратить деньги на правку, которая не решила наблюдаемую проблему.

Ресторан может быть виден в Google и отсутствовать в рекомендациях ИИ — противоречия здесь нет. Поиск по названию подтверждает, что бренд существует. Рекомендация без названия проверяет, подходит ли заведение под конкретную ситуацию гостя и находит ли система в этот момент доказательства, которые считает полезными.

Рабочая модель простая:

проблема → факты → самопроверка → диагностика → одно действие → сопоставимый повторный тест

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