Микроразметка LocalBusiness: адрес, график и локальная организация

Когда нужен LocalBusiness, а когда достаточно Organization

Тип LocalBusiness уместен для магазина, офиса обслуживания, клиники, кафе, мастерской и другой организации, чья деятельность привязана к физической точке или локальной зоне обслуживания. Для более точного описания желательно использовать подходящий дочерний тип Schema.org: например, Restaurant, Store, Dentist или AutoRepair. Если точного подтипа нет, базовый LocalBusiness остаётся допустимым выбором.

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

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

Какие свойства следует проверить

У Schema.org нет универсального набора полей, обязательного для всех сценариев. Практическая обязательность определяется смыслом страницы и требованиями конкретного потребителя данных. Однако локальная организация без идентифицируемого названия и достоверных контактных характеристик описана неполно.

Рабочий пример JSON-LD

JSON-LD обычно проще поддерживать, чем атрибуты, распределённые по HTML. Пример ниже нужно адаптировать под конкретную организацию. Значения-заглушки нельзя публиковать как реальные данные.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "@id": "https://example.ru/contacts/#business",
  "name": "Название организации",
  "url": "https://example.ru/contacts/",
  "telephone": "+7-000-000-00-00",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Улица, дом",
    "addressLocality": "Город",
    "addressRegion": "Регион",
    "postalCode": "000000",
    "addressCountry": "RU"
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": [
        "https://schema.org/Monday",
        "https://schema.org/Tuesday",
        "https://schema.org/Wednesday",
        "https://schema.org/Thursday",
        "https://schema.org/Friday"
      ],
      "opens": "09:00",
      "closes": "18:00"
    }
  ],
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 00.000000,
    "longitude": 00.000000
  }
}
</script>

Идентификатор @id должен быть стабильным и уникальным в пределах сайта. Удобно использовать канонический URL страницы с фрагментом, например #business. Это позволяет ссылаться на тот же объект из другой разметки, не создавая дубликаты сущности.

Как описать график

Для регулярного расписания используйте openingHoursSpecification. Время записывается в 24-часовом формате. Если интервалы различаются, создайте отдельные спецификации: например, одну для будней и другую для субботы. Круглосуточную работу можно обозначить интервалом 00:00–23:59, если точка действительно работает без перерыва.

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

Диагностический алгоритм

1. Определите сущность. Убедитесь, что страница относится к одной локальной точке, а выбранный тип соответствует её основной деятельности.
2. Соберите видимые факты. Выпишите название, адрес, телефон и график непосредственно со страницы. Микроразметка не должна быть единственным местом, где опубликованы эти сведения.
3. Найдите JSON-LD. Проверьте исходный HTML и итоговый DOM. Скрипт может добавляться CMS, модулем или клиентским JavaScript.
4. Проверьте синтаксис. JSON должен разбираться без ошибок: двойные кавычки, отсутствие лишних запятых, корректные вложенные объекты и массивы.
5. Сопоставьте значения. Сверьте каждое свойство с видимым содержимым страницы и официальными контактными данными организации.
6. Проверьте URL. Значения url и image должны быть абсолютными и публично доступными. URL страницы не должен противоречить canonical.
7. Проверьте адрес и координаты. Маркер должен указывать на заявленный объект, а не на центр города, соседнее здание или головной офис.
8. Исключите дубли. Несколько блоков от разных модулей не должны описывать одну точку с расходящимися телефонами или графиками.

Типовые ошибки

• Разметка несуществующей точки. Виртуальный офис или адрес регистрации выдают за место обслуживания клиентов.
• Смешение филиалов. Адрес относится к одной точке, телефон — к другой, а график — ко всей сети.
• Обобщённый тип без причины. Используется LocalBusiness, хотя в словаре есть точный дочерний тип.
• Невидимые пользователю сведения. В JSON-LD указан круглосуточный режим, но на странице опубликован другой график или режим отсутствует.
• Строка вместо структуры адреса. Текстовый адрес допустим не во всех задачах и хуже разделяет город, регион, индекс и страну; предпочтителен PostalAddress.
• Неверные дни недели. Произвольные сокращения вроде «Пн» используются вместо значений Schema.org.
• Шаблонные данные. После запуска остаются тестовый телефон, координаты разработчика или домен example.ru.
• Ошибочная вложенность. Свойства адреса размещаются непосредственно в LocalBusiness, хотя должны находиться внутри объекта address.

Границы метода

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

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

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

Итоговый чек-лист

• Страница описывает реальную локальную организацию или отдельный филиал.
• Выбран LocalBusiness либо подходящий дочерний тип.
• Название, адрес, телефон и график видимы пользователю и совпадают с JSON-LD.
• Адрес структурирован через PostalAddress.
• Расписание разделено на интервалы с фактическими днями и временем.
• Координаты, если они указаны, относятся именно к этой точке.
• Абсолютный url согласован с каноническим адресом страницы.
• В коде нет тестовых значений, конфликтующих блоков и синтаксических ошибок.

После внедрения проверьте публичную версию страницы, а не только шаблон в CMS или локальную сборку. SiteVisor анализирует публичный URL без доступа к CMS и проверяет технические, SEO/GEO и конверсионные сигналы. Можно запустить бесплатную проверку, а дополнительные практические материалы найти в блоге SiteVisor.