Микроразметка Organization: данные компании, логотип и связи
Микроразметка Organization помогает связать название организации, официальный сайт, логотип, контакты и внешние профили в одну понятную сущность Schema.org. Ниже — практический шаблон JSON-LD, правила выбора свойств и алгоритм проверки.
Какую проблему решает Organization
На обычной странице сведения о компании распределены между шапкой, подвалом, разделом контактов и юридической информацией. Машине приходится определять, относятся ли разные названия, телефоны, адреса и ссылки к одной сущности. Разметка Organization собирает эти данные в структурированный объект и явно задаёт связи между ними.
Это не замена видимому контенту. Значения в JSON-LD должны подтверждаться страницей или другими доступными пользователю разделами сайта. Если в разметке указано одно название, в реквизитах другое, а в профиле компании третье, добавление Schema.org не устраняет противоречие — сначала следует согласовать исходные данные.
JSON-LD обычно удобнее микроформатов в HTML: объект можно разместить отдельным блоком <script type="application/ld+json">, не привязывая каждое свойство к конкретному элементу интерфейса. При этом разметка остаётся частью исходного HTML и должна отдаваться поисковому роботу без авторизации.
Organization или LocalBusiness
Граница проходит по описываемой сущности. Organization представляет компанию, фонд, объединение, бренд или проект как организацию. LocalBusiness описывает физическую точку, в которую обращаются посетители: магазин, клинику, офис обслуживания, ресторан. Для локальной точки уместны адрес, географические координаты и часы работы.
Organization, а каждую точку — отдельным подходящим подтипом LocalBusiness со своим @id.
Одна страница может содержать несколько связанных сущностей, но их нельзя смешивать в один объект. Юридическое название и общий логотип относятся к организации; адрес и расписание конкретного отделения — к локальной точке. Для связи могут применяться свойства parentOrganization, subOrganization или осмысленные ссылки через идентификаторы.
Какие свойства заполнять
| Свойство | Что указывать | Критерий проверки |
|---|---|---|
@id |
Постоянный абсолютный URL с фрагментом, например https://example.ru/#organization |
Одинаковый идентификатор используется во всех связанных блоках |
name |
Основное публичное название | Совпадает с названием на сайте |
legalName |
Юридическое наименование, если оно опубликовано и действительно нужно | Не подменяет публичное название |
url |
Канонический адрес официального сайта | Абсолютный URL открывается без авторизации |
logo |
Абсолютный URL основного логотипа или объект ImageObject |
Изображение доступно роботу и относится к организации |
sameAs |
Официальные профили и страницы той же организации | Каждая ссылка подтверждает идентичность, а не просто упоминает компанию |
contactPoint |
Телефон, назначение контакта и доступные языки | Контакт актуален и опубликован для пользователей |
address |
Адрес организации в объекте PostalAddress, если применимо |
Не смешан с адресом случайного филиала |
Не существует требования заполнять все свойства Schema.org. Лучше передать небольшой согласованный набор, чем формально добавить пустые, неподтверждённые или неприменимые поля. ИНН или другой идентификатор можно описывать через подходящее свойство или объект PropertyValue, если значение публично и его публикация соответствует задаче сайта.
Рабочий пример JSON-LD
Шаблон ниже нужно адаптировать: заменить домен, название, изображение, контакты и внешние профили. Не копируйте демонстрационные значения на рабочую страницу.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://example.ru/#organization",
"name": "Пример",
"legalName": "ООО «Пример»",
"url": "https://example.ru/",
"logo": {
"@type": "ImageObject",
"@id": "https://example.ru/#logo",
"url": "https://example.ru/assets/logo.png",
"contentUrl": "https://example.ru/assets/logo.png",
"caption": "Логотип компании «Пример»"
},
"sameAs": [
"https://vk.com/example",
"https://t.me/example"
],
"contactPoint": {
"@type": "ContactPoint",
"telephone": "+7-000-000-00-00",
"contactType": "customer support",
"availableLanguage": ["ru"]
},
"address": {
"@type": "PostalAddress",
"addressCountry": "RU",
"addressLocality": "Москва",
"streetAddress": "Демонстрационный адрес"
}
}
</script>
Ключевой элемент шаблона — стабильный @id. Это идентификатор сущности, а не обязательно отдельная открываемая страница. С его помощью автор статьи, издатель, логотип и другие объекты могут ссылаться на одну организацию без дублирования полного набора полей.
Как разметить логотип
Для простого случая свойство logo может содержать URL изображения. Объект ImageObject полезен, когда нужно отдельно идентифицировать логотип и задать contentUrl или подпись. Адрес файла должен быть абсолютным, возвращать успешный HTTP-ответ и не блокироваться правилами доступа.
Не используйте в качестве логотипа снимок офиса, рекламный баннер или favicon низкого качества. Если файл заменили и его URL изменился, обновите JSON-LD. Если новый файл доступен по прежнему адресу, убедитесь, что сервер не отдаёт устаревший ответ или неподходящий MIME-тип.
Как задавать связи
sameAs предназначено для страниц, представляющих ту же сущность: официального профиля, подтверждённого каталога или страницы организации на внешней платформе. Ссылки на публикации, партнёров и сайты учредителей сюда не относятся. Связь с материнской компанией лучше выражать через parentOrganization, а не через sameAs: это разные сущности.
Диагностический алгоритм
- Определите сущность. Запишите, что именно описывает объект: компанию целиком, проект, бренд или локальную точку. Это предотвращает смешение Organization и LocalBusiness.
- Сверьте данные с интерфейсом. Проверьте название, официальный URL, логотип, телефон, адрес и профили. Существенные поля должны иметь видимое подтверждение.
- Проверьте синтаксис. JSON не допускает комментариев, одинарных кавычек и запятой после последнего элемента. Кавычки внутри названий необходимо экранировать.
- Проверьте модель Schema.org. Валидатор должен распознать тип
Organization, вложенныеImageObject,ContactPointиPostalAddress, а также свойства соответствующих типов. - Проверьте опубликованный URL. Анализ вставленного фрагмента не выявляет редиректы, блокировку изображения, серверную подмену HTML или отсутствие JSON-LD в версии страницы для робота.
- Сравните идентификаторы. Если Organization упоминается в Article, WebSite или других блоках, ссылка должна вести на тот же
@id. - Повторите проверку после публикации. Исходный HTML, DOM после выполнения JavaScript и содержимое JSON-LD могут различаться. Проверять нужно ту версию, которую реально получает внешний клиент.
Для синтаксической и типовой проверки подходит Schema.org Validator. Если разметка участвует в конкретном поисковом представлении, дополнительно применяют инструмент проверки расширенных результатов соответствующей поисковой системы. Отсутствие синтаксической ошибки означает лишь корректность структуры, но не подтверждает актуальность данных и не гарантирует специальное отображение.
Типовые ошибки
- Несколько конкурирующих Organization. Плагины темы, SEO-модуль и ручной JSON-LD создают объекты с разными названиями и идентификаторами.
- Относительные URL. Значения вроде
/logo.pngсложнее однозначно интерпретировать вне контекста страницы; в структурированных данных безопаснее использовать абсолютные адреса. - Подмена сущности брендом. Название продукта указывают как
nameюридической организации без явной модели отношений. - Неверный
sameAs. В массив добавляют все социальные ссылки, включая профили сотрудников, партнёров и страницы отдельных филиалов. - Недоступный логотип. Файл закрыт от внешних запросов, возвращает редирект на HTML, требует cookie или удалён после смены дизайна.
- Данные только в разметке. Телефон или адрес присутствуют в JSON-LD, но пользователь не может найти их на сайте.
- Смешение организации и точки. Общему объекту приписывают часы работы, координаты и адрес одного отделения.
- Ошибочная вложенность.
addressпередают строкой с неподходящими полями либо помещаютContactPointвнутрьPostalAddress.
Проверяемый чек-лист перед публикацией
- На странице присутствует ровно один основной объект организации или несколько объектов с явно различимыми ролями.
@contextравенhttps://schema.org, а@typeсоответствует сущности.@id,url,logoи ссылкиsameAsзаписаны абсолютными URL.- Название, контакты и адрес не противоречат видимым данным сайта.
- Логотип открывается без авторизации и возвращается как изображение.
- Профили в
sameAsпринадлежат именно описываемой организации. - Локальные адреса и часы работы вынесены в отдельные сущности, если сайт описывает филиалы.
- JSON-LD проходит синтаксическую проверку без ошибок типов и неизвестных свойств.
- Разметка присутствует на публичном каноническом URL, а не только в локальном шаблоне или панели CMS.
Границы метода
Organization передаёт структурированное описание, но не подтверждает юридический статус, владение внешним профилем или достоверность контакта. Валидатор также не знает, актуальны ли сведения: он проверяет форму данных и соответствие словарю. Содержательную сверку выполняют отдельно.
Разметка не исправляет проблемы индексирования, неверный canonical, закрытие страницы в robots.txt, ошибочные HTTP-ответы или недоступность ресурсов. Она также не заменяет отдельные типы для статей, хлебных крошек, товаров и локальных точек. Каждый объект должен решать собственную задачу и связываться с другими через устойчивые идентификаторы.
Итог
Корректная микроразметка Organization начинается не с максимального числа свойств, а с точного определения сущности. Для базового объекта обычно достаточно стабильного @id, названия, официального URL, доступного логотипа и проверенных связей. Контакты и адрес добавляют только тогда, когда они относятся к организации и подтверждаются содержимым сайта.
После внедрения проверьте JSON-синтаксис, соответствие типов Schema.org, согласованность данных и доступность каждого URL. Отдельно убедитесь, что карточка компании не поглотила сведения локального филиала: Organization отвечает за организацию, LocalBusiness — за конкретную точку и её режим работы.