Краткий вывод
Что важно понять до чтения деталей
- Organization описывает компанию
- @id объединяет сведения
- LocalBusiness описывает точку
- Точные данные важнее числа свойств
01
Где размещать основную сущность
Основной объект Organization обычно описывают на главной или странице о компании и связывают с WebSite через устойчивый @id. На внутренних страницах можно ссылаться на тот же идентификатор как на publisher или provider, не копируя противоречивый набор реквизитов вручную.
Если сайт принадлежит одному юридическому лицу, это одна базовая сущность. Несколько брендов или дочерних компаний требуют осознанной модели отношений, а не случайных объектов с похожими именами. Сначала нарисуйте, какие реальные организации существуют, затем переносите модель в JSON-LD.
02
Какие свойства действительно полезны
Укажите name, URL и logo; при наличии — legalName, telephone, email, address, foundingDate, taxID и официальные профили sameAs. Используйте наиболее конкретный подтип Organization, если он точно описывает компанию. Все реквизиты должны быть реальными и доступными пользователю в соответствующем разделе.
Logo должен открываться по стабильному индексируемому URL и представлять компанию, а не отдельную акцию. В sameAs добавляют официальные страницы организации, а не любой каталог со ссылкой. TaxID передают только в корректном формате и там, где публикация реквизитов уместна.
03
Organization и LocalBusiness — не синонимы
Organization описывает компанию в целом. LocalBusiness — конкретную физическую точку, которую может посетить клиент. Сеть клиник может иметь одну головную Organization и несколько сущностей MedicalClinic с разными адресами. Онлайн-сервис без приема посетителей обычно ограничивается Organization.
Не добавляйте LocalBusiness только ради предполагаемого преимущества в локальной выдаче. Неверный тип создает ожидание посещения и конфликтует с контактами. Поисковая разметка должна отражать бизнес, а не придумывать его устройство.
04
Как избежать дублей сущности
Дайте организации постоянный @id, например канонический URL главной с якорем, и используйте его во всех связанных объектах. Если каждый шаблон создает Organization с другим логотипом, телефоном или названием, робот видит несколько похожих сущностей вместо одной согласованной.
Формируйте данные из централизованных настроек CMS. При смене телефона или юридического имени обновление должно попасть одновременно в футер, контакты и JSON-LD. Регулярно проверяйте исходный HTML, потому что несколько SEO-плагинов могут незаметно добавить дублирующие объекты.
05
Проверка и ожидания
Валидатор подтверждает синтаксис, но не юридическую точность. Сверьте название, ИНН, адрес, телефон и ссылки с официальными данными компании. Проверьте логотип без cookies и авторизации. После миграции домена обновите URL и @id во всех связанных объектах.
Organization не гарантирует панель знаний, логотип или другой специальный элемент выдачи. Это понятное описание сущности, которое работает вместе с содержанием сайта и внешними авторитетными источниками. Цель — непротиворечивые данные, а не максимальное число свойств.
Практика
Что проверить на своем сайте
- Определить базовую организацию
- Назначить постоянный @id
- Сверить name и legalName
- Проверить logo и контакты
- Добавить только официальные sameAs
- Найти дубли от плагинов
Применить к проекту
Что можно сделать после статьи
Если тема похожа на вашу ситуацию, следующий шаг простой: проверить сайт на спрос, структуру, технические ограничения и точки, где пользователь не доходит до заявки.
Источники
Какие источники использовали
Сведения об организации, логотипе, юридическом названии, контактах и профилях.
Яндекс Вебмастер: адреса и организацииРазметка данных организации, адреса, телефона и режима работы.
Google: общие правила структурированных данныхРазметка должна соответствовать видимому содержанию и не гарантирует расширенное отображение.
