Аналитическая система для сети ресторанов: 12 локаций, 500 ключей и AI-рекомендации

Зачем ресторанам SEO-аналитика

У сети ресторанов задача продвижения одновременно и проще, и сложнее, чем у «обычного» бизнеса. Проще — потому что география фиксирована и запросы почти всегда с интентом «здесь и сейчас, рядом со мной». Сложнее — потому что у вас не одно юрлицо, а 12 юрлиц в 12 локациях, каждое со своими позициями в локальной выдаче, своим трафиком, своими конкурентами и своим меню.

Клиент — сеть из 12 ресторанов европейской кухни в Москве и области. До нас каждая локация жила своей жизнью: один ресторан раз в месяц забирал отчёт у подрядчика, три — не занимались SEO вообще, остальные жили в разных агентствах. Руководитель сети смотрел на выручку и не понимал, какие из локаций реально «тянет» органика, а какие — только тратят бюджет.

Задача — единый дашборд: увидеть всю сеть сразу, понять, где и что работает, и получать не только цифры, но и рекомендации «вот что стоит сделать на этой неделе».

Что отличает SEO-аналитику для локального бизнеса

Локальный ресторанный запрос — это почти всегда геосенситивная выдача. «Ресторан итальянской кухни» из одной точки Москвы и из другой — это два разных ТОП-10. Один и тот же ресторан может быть первым для своего района и вообще не показываться в соседнем. Классический мониторинг позиций «по одному запросу на город» — не работает.

Плюс у ресторанов есть отдельный источник трафика — Яндекс.Карты и Яндекс.Бизнес. Там своя механика ранжирования (отзывы, фото, рубрики, актуальность меню), и её нужно мерять параллельно с классическим веб-SEO.

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

Ядро из 500 запросов: как собрали

Первый шаг — семантика. По нашему стандартному пайплайну собрали ядро для ресторанной ниши:

• Seed-ключи: названия типов кухни (итальянская, грузинская, европейская), районы Москвы, коммерческие модификаторы («забронировать столик», «банкет», «детское меню», «завтрак»).
• Расширение через Yandex Suggest — алфавитная перебивка от seed-ов. Для локальной тематики даёт ~40% дополнительных ключей: «ресторан на Патриках с верандой», «кафе для детского праздника Марьино».
• Расширение через Bukvarix — ещё ~30%.
• Сбор частот через XMLRiver Wordstat с геобиндингом на Москву.
• Ручная чистка от мусора (бренды конкурентов, отзывы, тематически нерелевантные).

На выходе — 510 ключей, разбитых на кластеры:

Кластер                          Количество   Среднемесячная частота (Wordstat)
─────────────────────────────────────────────────────────────────────────────
Общие кухни + район              112          ████████████       ~180 000
Забронировать столик             78           ██████████         ~144 000
Банкеты и мероприятия            61           ██████             ~81 000
Детское меню / семейные          54           █████              ~62 000
Завтраки / ланчи                 48           █████              ~58 000
Веранда / терраса (сезон)        41           ████               ~47 000
Навигационные (бренд сети)       38           ██████             ~79 000
Меню и блюда                     52           ████               ~44 000
Отзывы                           26           ███                ~31 000

Ядро поделено глобально на сеть, но мониторинг и отчётность идут по каждой локации отдельно. Это значит: один и тот же ключ снимается 12 раз с разных геоточек.

Съём позиций: трюк с геоточкой

Как вообще снять позиции «из той точки, где стоит ресторан»? Большинство сервисов мониторинга позиций не умеют точной геолокации, они работают на уровне города. Для ресторанов это плохо — мы хотим видеть, как сайт ранжируется из своего района, а не «в среднем по Москве».

Мы используем XMLRiver с параметром geo-point — он принимает координаты точки, а не просто название города. XMLRiver возвращает нам ту же выдачу, которую пользователь увидел бы, стоя в этой точке с телефоном.

Стоимость: один запрос 25 копеек (тариф Basic, 25 ₽/1000). На одну локацию: 510 ключей × 1 снятие в неделю = 510 запросов, ~130 ₽/нед. На всю сеть: 12 × 130 = 1 560 ₽/нед, или ~6 200 ₽/мес. Это в разы дешевле любых сервисных подписок на мониторинг позиций, и мы получаем точную геовыдачу.

Дашборд: что видит клиент

Главный экран — карта всей сети. На ней 12 точек, каждая подсвечена по «состоянию»:

• зелёная — позиции стабильны или растут, трафик в норме, новых проблем нет;
• жёлтая — есть что-то заслуживающее внимания (просадка по одному кластеру, падение позиции у ключевых запросов, снижение рейтинга в Яндекс.Картах);
• красная — есть очевидная проблема, требующая вмешательства (сайт локации упал, контактные данные изменились и разошлись, каннибализация).

Клик по точке — уходим на страницу локации, где всё по этой локации: позиции по 510 ключам, трафик из Яндекс.Метрики, статистика Яндекс.Бизнеса (звонки, просмотры, маршруты), список рекомендаций от AI-ассистента.

Сведение Метрики: чанкинг и ограничения API

Y.Metrika API имеет лимит в 31 день на один запрос при выборке с разбивкой по дням. Для двухмесячного периода надо делить на чанки и клеить обратно. Мы держим параметры MAX_DAYS_PER_CHUNK=31 и METRIKA_CHUNK_DELAY_MS=350 — для двухмесячного периода суммарно получается ~2,8 секунды задержки; фронт батчит 8 запросов по 2 штуки с паузой 600 мс (итого ~1,8 сек простоя), что субъективно ощущается быстрым.

На каждую локацию есть счётчик Метрики. Итого 12 счётчиков, и все они прокачиваются в единую базу каждую ночь. Исторические данные за 12 месяцев — чтобы можно было сравнивать год-к-году и понимать сезонность.

Прогноз трафика: модель сезонности + погода + события

Это самая нетривиальная часть. Ресторанный трафик нельзя прогнозировать в лоб («в прошлом месяце было X, значит и в этом будет X») — потому что на него влияют:

• День недели (пятница-суббота × 2–3 к будням);
• Время года (летом сезон веранд — +30–50% к апрелю);
• Праздники (8 марта, Новый год — пики в 3–5 раз);
• Погода (дождь в июне — минус 40%);
• События города (ближайший концерт, футбольный матч, фестиваль).

Мы сделали простую регрессионную модель, которая учитывает первые четыре фактора (день недели, сезон, праздники, погода через API) и накладывает на исторические данные. Пятый фактор — события — пришлось оставить ручным: клиент отмечает в календаре ожидаемые события («концерт в парке Горького 20 мая, обычно приносит +20% пешего трафика»), и прогноз корректируется.

Точность прогноза — средняя ошибка ~12% на горизонте двух недель, ~18% на горизонте месяца. Этого достаточно, чтобы планировать закупки и графики смен.

AI-рекомендации: превращаем данные в действия

Самый «продуктовый» модуль дашборда — рекомендации. Клиент не хочет разбираться в позициях, конверсиях и Метрике, клиент хочет знать что сделать на этой неделе, чтобы стало лучше. Раньше это была функция SEO-специалиста агентства: собрать данные, подумать, сформулировать 3–5 задач. Теперь это делает AI-модуль.

Как работает рекомендатель:

1. На входе — все данные по локации: позиции по ядру (с историей), трафик (с трендом), показатели Яндекс.Бизнеса, список опубликованных материалов на сайте за последний месяц.
2. AI анализирует данные: ищет просадки, каннибализацию, новые возможности (запросы, которые почти в ТОП-10).
3. Формулирует 3–5 конкретных задач в формате «проблема → что сделать → ожидаемый эффект → срок».

Пример реальной рекомендации за прошлый квартал:

Проблема: «детское меню Сокольники» выпало с 7 на 14 позицию за неделю; по данным Метрики, страница /deti имеет CLS 0.42 на мобиле.

Что сделать: оптимизировать CLS страницы /deti (reserve space для фото меню, preload критичных шрифтов). Добавить schema.org Menu к детскому блоку.

Ожидаемый эффект: возврат страницы в ТОП-10 за 2–3 недели, рост страничного трафика на 15–25%.

Срок: до конца следующей недели.

Рекомендации уходят на e-mail управляющему сетью (не отдельно по локациям — он не захочет читать 12 писем) и собираются в Trello-доску как задачи для подрядчика.

Результаты

После 5 месяцев работы:

Отдельно отмечу — выравнивание сети. Раньше среди 12 локаций был разброс в 5–10 раз по органическому трафику на объект: три локации тянули почти весь органический поток, остальные жили на платной рекламе и Яндекс.Бизнесе. За 5 месяцев разрыв сократился до 2–3 раз, и отстающие локации подтянулись. Это было достигнуто не каким-то одним действием, а серией локальных правок, которые выдал рекомендатель.

Главное

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

AI-рекомендации в этой истории — не магия, а формализация того, что делал бы хороший SEO-специалист. Разница в том, что специалист доходит до ваших 12 локаций раз в месяц, а алгоритм — каждую ночь. На дистанции это разные скорости реакции, и в ресторанном бизнесе, где трафик может просесть на 30% за неделю из-за одного релиза конкурента, скорость реакции — это деньги.