GEO для сети клиник: как устроить данные филиалов, врачей и услуг, чтобы нейросеть видела всю сеть
Про попадание в ответы нейросетей сейчас пишут много. Но у сетей клиник есть своя проблема, о которой говорят редко: нейросеть рекомендует не сеть, а конкретную точку. И если данные о филиалах, врачах и ценах разбросаны и противоречат друг другу, она легко отправит пациента не туда - в филиал, где нужного врача нет, или с прошлогодней ценой.
Сегодня разберу, как это выглядит в живых ответах и как устроить данные сети, чтобы нейросеть видела её целиком. Тут мы как раз в своей стихии: половина нашей работы - разработка.

GEO для сети - это три слоя
Сразу договоримся о рамке. Первый слой - данные, которые нейросеть может найти и склеить: сайт, карточки, фиды. Второй - внешние источники, которые эти данные повторяют: агрегаторы, подборки, обзоры. Третий - замер, который проверяет не упоминание, а правильность рекомендации.
Эта статья в основном про первый слой и про замер, а внешний разберём настолько, насколько он зависит от данных. Причина простая: без первого слоя два других работают вхолостую. Публиковаться можно сколько угодно, но если модель не может связать врача с филиалом, она будет упоминать сеть с чужим адресом.
Четыре ответа: нейросеть выбирает точку, а не бренд
9 октября я задал Алисе и ChatGPT два типовых вопроса: пациентский про больной зуб и выбор клиники для ЭКО. Это единичные прогоны, не замер. Но механику они показывают очень наглядно.
Алиса AI: стоматология рядом с домом

Город Алиса определила по геолокации, а прямо в ответ встроила карточку клиники из Яндекс Карт: адрес, часы, рейтинг, расстояние до метро, кнопка звонка. Аргументы "почему подходит" и цитаты из отзывов взяты с НаПоправку. Смотрим источники справа: ПроДокторов, НаПоправку, Zoon, 2ГИС, Яндекс Карты и ещё пара каталогов. Сайтов самих клиник там нет.
И обратите внимание: я просил "в пределах моего района", а Алиса прямо пишет, что подобрала варианты в разных частях города. Клиника в ответ попала? Попала. Получил ли пациент то, что просил? Нет. Запомним этот момент, он пригодится, когда дойдём до замеров.
ChatGPT: тот же вопрос

ChatGPT на тот же вопрос отвечает списком из картографического слоя. Названия латиницей - "Stomatologiya Lider", "Novodent, Stomatologicheskiy Salon", у части клиник всего по несколько десятков оценок. Откуда этот слой, интерфейс не говорит. Но вывод простой: у каждого филиала есть ещё одна карточка, которую клиника, скорее всего, ни разу не открывала, и бренд в ней может называться не так, как на вывеске.
ChatGPT: клиника для ЭКО в Москве

С ЭКО картина другая. ChatGPT ставит первой "Клинику Фомина" (нет, не родственники) и приводит цены программ со ссылкой на страницу цен на сайте клиники. То есть официальный сайт тут работает как источник. При этом в карточке один адрес на Мичуринском, хотя в тех же источниках клиника названа сетью.
Ещё две детали. В источниках три версии одного сайта - основной домен и два поддомена с одинаковым заголовком "официальный сайт". Для модели это три разных источника, а для владельца, вероятно, служебные копии, которые стоило закрыть от индексации. И строчка "Что проверить: полную смету, выбор конкретного врача". Модель прямо признаётся, что данных на уровне врача ей не хватило, и перекладывает проверку на пациента.
Алиса AI: клиника для ЭКО в Москве

Алиса начинает с "СМ-Клиники", причём не с бренда, а с конкретного подразделения - центра репродуктивного здоровья на Ленинградском проспекте. Для ЭКО это правильная точка. Но у карточки пометка "Мало оценок": отзывы, которые сеть собрала по другим адресам, к этой карточке не переходят. Источники тоже другие, чем в стоматологии: подборки и рейтинги на kp.ru, vc.ru, sapiens-med, docdoc. Моё предположение по этим и прошлым замерам: чем специализированнее запрос, тем больше модель опирается на подборки "топ-10", а в локальном - на карты и каталоги.
Итого по четырём ответам: нейросеть рекомендует не сеть, а точку. И данные об этой точке берёт из карточек и каталогов, которые клиника контролирует лишь частично.
Нейросеть не помнит клинику, а собирает её из источников
Нейросети с поиском клиники не помнят, они ищут. Яндекс в справке Вебмастера пишет об этом прямо: Алиса AI разбирает запрос, при необходимости задаёт себе уточняющие подвопросы, ищет по ним и собирает ответ из источников, которые высоко ранжируются. У ChatGPT свой поисковый индекс, его собирает робот OAI-SearchBot. Если сайт его закрыл, в поисковых ответах ChatGPT его не будет.
Возьмём запрос "детский ЛОР по субботам на Уралмаше". Модель может разложить его на три вопроса: есть ли в клинике детский ЛОР, где он принимает и до скольки работает этот филиал. На каждый нужна страница или карточка, которая отвечает однозначно. Если хоть одна часть не находится или противоречит другим, ответ собирается из чужих источников.
А теперь посмотрим, как обычно выглядит сайт сети:
- общая страница "Врачи" на 80 фамилий, и ни у кого не указано, где он принимает;
- одна таблица "Цены" на всю сеть, хотя по филиалам прайсы разные;
- страница филиала - это адрес, телефон и карта, без врачей и услуг;
- в Яндекс Бизнесе филиалы названы кто во что горазд: по улице, по району, со старым названием бренда.
Чтобы ответить "этот врач принимает на Малышева, детей с трёх лет, приём 2 500 рублей", модели нужно склеить источники, которые никак друг на друга не ссылаются. Не получается - ответ уходит к ПроДокторов или НаПоправку, где эта связка уже собрана за клинику. Хуже, когда склеить получается неправильно: тогда сеть в ответе есть, но с чужим адресом.

Начинать нужно с единого справочника
Первое, что стоит сделать, - не переписывать тексты и не вешать разметку, а описать модель данных сети. По сути это справочник с постоянными ID, из которого потом генерируется всё остальное: страницы, разметка, фид для Яндекса, выгрузки для агрегаторов.
Модель данных сети клиник
Сеть. Бренд, варианты написания, сайт, список юрлиц и филиалов, которые к нему реально относятся.
Юрлицо. Полное наименование, ИНН, лицензия и адреса с видами работ, на которые она выдана.
Филиал. ID, название и адрес ровно как в Яндекс Бизнесе, юрлицо, часы, вход, ОМС, возраст пациентов.
Врач. ID, ФИО, специальности, образование, квалификация, стаж, возраст пациентов.
Услуга. Название, код по номенклатуре Минздрава, состав, подготовка, ограничения.
Предложение. Связка "врач × филиал × специальность × услуга" с ценой, условиями оплаты и ссылкой на запись.

Про юрлицо часто забывают, а для сети это важно. Сеть может работать через несколько юрлиц, а лицензия выдаётся не бренду, а конкретному лицу на конкретные адреса. Проверяется она в Едином реестре лицензий Росздравнадзора, и одного номера на всю сеть недостаточно. На сайте реквизиты лучше дать текстом и прямо написать, какое юрлицо стоит за каким филиалом. Скан лицензии этого не объясняет ни пациенту, ни роботу.
Самый важный уровень - последний. Цена и запись принадлежат не врачу и не филиалу, а их сочетанию. Ровно так думает и Яндекс: в фиде "Врачи" предложение - это связка врача, клиники, специальности и услуги. Если врач делает одну услугу в трёх клиниках по двум специальностям, справка Вебмастера требует шесть отдельных предложений. Сеть, у которой такая таблица уже есть, закрывает половину работы одной выгрузкой.
Источником справочника должна быть МИС, а не контент-менеджер. Врачи уходят и переходят между филиалами чаще, чем обновляется сайт. Если сайт, запись и внешние профили питаются из одной базы, перевод врача видно везде сразу, а не через полгода после жалобы пациента.
Когда одна сеть существует в нескольких версиях
Похожую картину мы разбирали в проекте Coffee Way. Это сеть кофеен, которая продаёт франшизу. Информация о франшизе жила на двух адресах, часть региональных страниц отдавала 404, а ключевые цифры были нарисованы в SVG, откуда их не прочитать ни поиску, ни модели.
Мы переработали контент, региональную структуру сайта и внешние публикации. За четыре месяца видимость Coffee Way в ответах нейросетей по данным Georank выросла с 3,57% до 29,85%.
Врачей и филиалов там нет, но принцип тот же: модель правильно описывает компанию, только когда данные о ней доступны и нигде себе не противоречат. Подробнее - в кейсе Coffee Way.
Сайт собирается из справочника
Когда справочник есть, у каждой сущности появляется своя страница, и страницы ссылаются друг на друга по тем же связям. На странице филиала - врачи, которые там принимают, и цены именно этой точки. На странице врача - филиалы и дни приёма. На странице услуги - где её делают и сколько она стоит в каждом филиале. Модель, попав на любую из них, за пару переходов видит всю ветку.
Тут легко перестараться. Отдельная страница "УЗИ щитовидки на Малышева" нужна, только если там реально что-то отличается: врач, цена, оборудование, возраст пациентов. Двадцать копий одной услуги с разными адресами никому не помогут. Если отличий нет, хватит общей страницы услуги с таблицей "где делаем".
Отдельно продумайте страницу ушедшего врача. Удалите её - в выдаче и в ответах останутся только старые карточки на агрегаторах. Лучше оставить страницу с пометкой "больше не принимает" и ссылками на коллег той же специальности. И в крупной сети обязательно будут тёзки, поэтому на странице врача нужно несколько отличающих признаков: филиал, специальность, образование, фото.
Разметка schema.org повторяет справочник. Каждый филиал описывается как MedicalClinic со ссылкой на сеть, каждый врач - как IndividualPhysician. Этот тип появился в schema.org в январе 2024 года вместе со свойством practicesAt: где врач принимает. Для сетей это лучшее, что случилось со словарём за последние годы, раньше привязать врача к нескольким филиалам было почти нечем.
// врач, который принимает в двух филиалах
{
"@type": "IndividualPhysician",
"@id": "https://clinic.ru/vrachi/ivanova#doctor",
"name": "Иванова Анна Сергеевна",
"practicesAt": [
{ "@id": "https://clinic.ru/filialy/malysheva#clinic" },
{ "@id": "https://clinic.ru/filialy/uralmash#clinic" }
]
}Главное тут не сама разметка, а сквозные ID: у филиала один @id, и на него ссылаются все страницы. И разметка должна совпадать с текстом. Врач, который в JSON-LD принимает в двух филиалах, а на странице в одном, - это ровно то противоречие, от которого мы уходим.
Ожидания от разметки держите трезвыми. Google в руководстве по генеративному поиску прямо пишет: специальная разметка для AI-функций не нужна, а llms.txt его поиск не использует. Разметка - это порядок в данных, а не волшебная кнопка.
Тот же справочник кормит Яндекс и внешние площадки
У Яндекса есть отдельный формат для медицины - фид "Врачи" в Вебмастере. Его структура почти один в один повторяет справочник выше. Два момента, на которых сети обычно спотыкаются:
- название и адрес клиники в фиде должны совпадать с карточкой в Яндекс Бизнесе, а дубли карточек одной организации справка Яндекса называет одной из причин кривого отображения;
- до отправки фида нужны согласия врачей на передачу их данных, и лучше заложить это в процесс сразу, а не выяснять после отклонения.
Влияет ли фид на ответы Алисы напрямую, Яндекс не раскрывает. Но карточка из Яндекс Бизнеса в ответах видна прямо, мы это видели на примере со стоматологией. Так что порядок в карточках филиалов - это не "для карт", а для ответов тоже.
С агрегаторами та же история. Если на ПроДокторов врач числится в филиале, из которого ушёл год назад, у модели два противоречащих источника, и выберет она не обязательно в вашу пользу. Поэтому у справочника должен быть владелец, который при любом изменении обновляет не только сайт, но и Яндекс Бизнес, 2ГИС и агрегаторы. По справке Яндекса, после исправления на сайте-первоисточнике карточка врача в поиске обновляется в течение двух недель. В генеративных ответах, по нашим наблюдениям, лаг обычно длиннее.
Отзывы в сети тоже читайте по филиалам, а не по средней оценке бренда. Жалобы на регистратуру одного адреса - задача для этого адреса. И в публичных ответах на отзывы не подтверждайте факт обращения и не упоминайте диагноз: это врачебная тайна, разбор уводите в личный канал.
Справочник отвечает не только на "где", но и на "почему"
Вспомните ответ Алисы про стоматологию: блок "почему подходит" и цитаты из отзывов модель взяла с НаПоправку. Аргументы у клиники наверняка были, просто модель нашла их не у неё.
А справочник как раз хранит материал для таких аргументов: детей принимают с трёх лет, есть ОМС, филиал работает до 21:00, у врача 15 лет стажа, в этой точке стоит МРТ на 3 Тесла. Это ровно те модификаторы, которые пациенты добавляют в запрос: "по субботам", "детский", "по ОМС", "рядом с метро". Нейросеть ищет под них подтверждения, и выигрывает тот, у кого подтверждение сформулировано однозначно.
Поэтому эти поля мало хранить в базе, их нужно показывать текстом на страницах филиала и врача - короткими конкретными фразами. "Принимаем детей с 3 лет" модель перескажет. "Заботимся о каждом маленьком пациенте" - нет. Чем конкретнее факт на вашей странице, тем больше шансов, что в "почему подходит" окажется ваш аргумент, а не пересказ чужого отзыва.
Подборки решают специализированный выбор
В примере с ЭКО Алиса опиралась на подборки и рейтинги: kp.ru, vc.ru, sapiens-med, docdoc. Для узких направлений это типичная картина: когда выбор сложный, модель ищет того, кто уже сравнил клиники за неё.
Работа с подборками для сети - это не "попасть в топ-10 любой ценой". Задача в том, чтобы в обзорах, рейтингах и статьях стояли те же данные, что в справочнике: те же названия филиалов, те же направления по адресам, те же врачи. Если в подборке написано, что ЭКО делают в центре на Ленинградском, а у вас программа идёт в двух филиалах, модель повторит подборку, а не ваш сайт.
Отсюда практическое правило: при каждой публикации о сети, своей или внешней, данные берутся из справочника, а не пишутся по памяти. Старые подборки с устаревшими сведениями стоит найти и попросить обновить так же, как карточки на агрегаторах. И не забывайте, что платное размещение остаётся рекламой медицинских услуг: нужны маркировка и предупреждение о противопоказаниях.
Как понять, что нейросеть видит сеть правильно
Помните Алису, которая проигнорировала "мой район"? Обычный GEO-замер посчитал бы этот ответ успехом: клиника упомянута. Для сети этого мало. Нам важно не "назвала ли", а "назвала ли правильно". Поэтому я смотрю на три вещи:
- доля корректных рекомендаций - клиника рекомендована, и рекомендация подходит под все условия запроса;
- доля ошибок - назван не тот филиал, врач, цена или услуга;
- рекомендации по каждому филиалу - причём считаем только по запросам, под которые этот филиал реально подходит.
Срез по филиалам нужен потому, что общая цифра сети может расти за счёт одного сильного отделения, пока остальные адреса невидимы. А долю ошибок стоит снять до начала работ, чтобы было с чем сравнивать.
И пара слов про встроенные отчёты. В Вебмастере есть инструмент "Видимость сайта в Алисе AI" с показателем SoV. Только не путайте его с SoV из GEO-замеров, где считается доля рекомендаций бренда среди конкурентов. У Яндекса SoV - это доля запросов с ответом Алисы, в которых упомянут ваш сайт, причём только по запросам, где сайт уже достаточно высоко в выдаче. Считается по домену, а не по бренду: рекомендация клиники со ссылкой на ПроДокторов туда, скорее всего, не попадёт. И тот ли филиал назван, отчёт тоже не скажет. Штука полезная, но свою панель замеров не заменяет.
С чего начать завтра
Подрядчик для первого шага не нужен. Выгрузите из МИС список врачей с филиалами и сверьте его с сайтом, Яндекс Бизнесом и ПроДокторов. Число расхождений в этой таблице - честная оценка того, насколько нейросеть сейчас видит вашу сеть целиком. А дальше уже понятно, что чинить первым.
Максим Фомин, основатель Vverh.Digital и сообщества GEOMI. Telegram: @Mr_MaxFomin
