Сайт для сети филиалов: города, точки, маршрутизация заявок и SEO

Сначала опишите поведение сети, затем рисуйте страницы

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

До прототипа я бы разобрал восемь сценариев:

1. Человек знает город, но еще не выбрал точку.
2. Человек ищет конкретную услугу и хочет ближайший филиал, где она доступна.
3. В городе работает несколько точек с разными графиками и набором услуг.
4. Ближайшая точка временно не принимает обращения.
5. В выбранном городе нет нужной услуги, но ее оказывает соседний филиал или удаленная команда.
6. Пользователь перешел сразу на страницу точки из поиска, карты или рекламы.
7. Филиал переезжает, готовится к открытию или закрывается.
8. Сотрудник центра должен проверить, куда ушло обращение и почему.

Для каждого сценария фиксируют ожидаемый экран, доступное действие, данные для маршрута и запасной вариант. Так проект превращается из набора макетов в проверяемую логику.

Соберите модель данных филиала

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

Полезная модель включает несколько связанных сущностей.

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

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

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

Разделите роли общей, городской и локальной страниц

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

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

Общая архитектура разделов описана в материале о структуре сайта для бизнеса. Для сети поверх нее добавляются связи город -> филиал -> доступная услуга, а не параллельный каталог несвязанных страниц.

Помогите выбрать точку и не отнимайте управление

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

Рабочая схема выбора выглядит так:

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

Автоматическое определение города должно помогать, а не отнимать выбор. Ошибка геолокации не должна закрывать человеку доступ к нужной точке.

Управляйте доступностью услуг как отдельными данными

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

Для связи услуги и филиала стоит хранить:

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

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

Сформулируйте правила маршрутизации как таблицу решений

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

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

Запасной маршрут проектируют до запуска. Иначе первая временно закрытая или перегруженная точка превращает корректную заявку в потерянное обращение.

Сохраняйте выбранный контекст до ответственного сотрудника

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

В обращение полезно передавать автоматически:

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

Те же данные нужны не только форме. Для телефона используют номер или подмену, связанную с точкой. Мессенджер и онлайн-запись должны получать выбранный филиал. В письме подтверждения человеку стоит показать адрес, услугу и ожидаемое продолжение.

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

Предусмотрите состояния открытия, переезда и закрытия

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

Яндекс Бизнес объединяет в сеть действующие филиалы и требует публиковать их адреса на общем сайте; будущие точки нельзя объединить до начала работы: условия создания сети. Это еще одна причина отделять внутренний план открытия от публичного статуса точки.

Автоматизируйте выпуск страниц, но не решения о данных

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

Автоматизировать разумно:

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

Не стоит автоматически публиковать точку только потому, что запись появилась в таблице. Перед выпуском нужны подтвержденные адрес, график, услуги, контактный маршрут, ответственный и проверка формы. При массовой сети полезно также контролировать расхождения между CMS и внешними профилями. Для сетей более чем с 30 филиалами Яндекс Бизнес рекомендует обновление данных через XML и позволяет указывать страницу конкретного филиала в поле info-page: документация формата.

Отделите базовую SEO-готовность от региональной стратегии

Разработчик сайта должен обеспечить техническую основу: постоянные URL, обычные внутренние ссылки, доступность страниц без обязательной геолокации, корректные заголовки, canonical, Sitemap и данные реальных точек. Но решение о том, какие города и услуги получают самостоятельные индексируемые страницы, нельзя принимать только на уровне шаблона.

Для каждой локальной страницы проверьте:

1. Есть ли реальная точка или подтвержденная модель обслуживания.
2. Решает ли URL отдельную задачу человека.
3. Содержит ли он локальные факты, влияющие на выбор.
4. Связан ли он с общей услугой, городом и филиалом.
5. Совпадают ли адрес, график и контакты с источником данных.
6. Открывается ли страница по прямой ссылке независимо от выбранного ранее города.
7. Передает ли форма тот же филиал, который видит пользователь.

Глубокий выбор между разделами, поддоменами и доменами, а также canonical, дубли и региональность разобраны отдельно в материале о мультирегиональном SEO. WEB-011 не заменяет эту работу: он задает продуктовую и операционную модель самого сайта.

Для страницы реальной точки можно подготовить LocalBusiness с фактическим названием, адресом, графиком и другими применимыми свойствами. Google описывает name и физический address как обязательные свойства поддерживаемой разметки локального бизнеса: документация LocalBusiness. Разметка должна собираться из тех же данных, которые видит человек, а не из отдельной ручной копии.

Измеряйте качество маршрута, а не среднюю конверсию сети

Общий показатель сайта может скрыть ошибку одной точки. Поэтому я бы добавил к обычным метрикам несколько сигналов работы маршрута:

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

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

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

Запустите один маршрут как пилот

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

1. Подтвердите записи города, филиалов, услуг и ответственных.
2. Соберите страницы сети, города и точек в выбранной модели.
3. Проверьте выбор города с разрешенной и запрещенной геолокацией.
4. Откройте каждую страницу по прямой ссылке.
5. Пройдите формы для доступной и недоступной услуги.
6. Смоделируйте временно закрытую точку и запасной маршрут.
7. Проверьте письмо, CRM-карточку, телефон и мессенджер.
8. Сопоставьте адреса и графики с внешними профилями.
9. Проверьте мобильный список, карту, фильтры и клавиатурную навигацию.
10. Назначьте владельца исправления каждому найденному расхождению.

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

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