Разбор промпта для микроразметки Schema.org под локальный адрес
Разметка LocalBusiness пишется один раз, но ошибиться в ней легко. Ниже промпт, который собирает её из ваших данных, и разбор полей, где чаще всего врут.
Полный текст промпта
«Ты — специалист по структурированным данным. Сгенерируй валидный JSON-LD по схеме Schema.org для локального бизнеса. Тип выбери из списка: LocalBusiness или более точный подтип, если он подходит. Обязательные поля: name, image, url, telephone, priceRange, address (PostalAddress со streetAddress, addressLocality, addressRegion, postalCode, addressCountry в формате ISO), geo (GeoCoordinates), openingHoursSpecification массивом по дням, sameAs массивом ссылок на соцсети. Требования: телефон в международном формате начиная с +998, addressCountry — UZ, время в 24-часовом формате, дни недели английскими сокращениями по спецификации. Не добавляй поля, для которых я не дал данных, и не придумывай координаты. Верни только JSON-LD внутри тега script, без пояснений. Данные: [здесь ваш список]».
Ключевая часть — последние два предложения. Без прямого запрета модель уверенно подставляет вымышленные координаты и рейтинг, а это ровно те поля, за которые прилетает ручная санкция.
Почему выбор типа важнее остального
LocalBusiness — общий тип. Если у вас стоматология, ресторан, автосервис или салон, точный подтип даёт поиску больше понимания и открывает дополнительные поля вроде меню или списка услуг.
Не пытайтесь указать несколько типов сразу, чтобы «охватить больше». Это частая самодеятельность, которая приводит к невалидной разметке. Один объект — один тип.
Если у вас несколько филиалов, каждому нужна своя страница со своей разметкой и своим адресом. Одна страница с пятью адресами в разметке — сигнал низкого качества, а не преимущество.
Поля адреса под Узбекистан
addressCountry всегда двухбуквенный код UZ, а не слово. addressLocality — город: Toshkent или Tashkent, но одинаково во всех источниках. addressRegion — область или город республиканского значения.
streetAddress пишите так же, как в Google Картах и в справочниках: те же сокращения, тот же порядок. Расхождение написания между сайтом, картами и справочниками — главная причина, по которой локальная выдача не связывает страницу с организацией.
postalCode заполняйте, если он у вас реально есть. Пустое или выдуманное поле хуже отсутствующего.
Телефон, часы и оплата
Телефон только в формате +998 XX XXX XX XX без букв и добавочных в том же поле. Локальный формат вида 71-200-00-00 в разметке не распознаётся однозначно.
openingHoursSpecification задавайте массивом объектов, а не строкой. Отдельно вынесите сокращённые дни и выходные — не сводите всю неделю к одной записи, если график различается.
priceRange не выдумывайте. Если не хотите раскрывать вилку, пишите условное обозначение или уберите поле. Указание диапазона в сумах допустимо, но должно совпадать с ценами на сайте.
Что нельзя размечать
Самая опасная ошибка — разметка отзывов и рейтинга, которых нет на странице. AggregateRating допустим только если отзывы реально опубликованы на этой же странице и собраны от клиентов, а не написаны вами.
Не размечайте акции и скидки, которых нет, и не ставьте разметку услуг, которые вы не оказываете. Эти поля проверяются вручную, а санкция снимается месяцами.
Не дублируйте разметку: если её ставит и шаблон CMS, и ваш вставленный скрипт, получится два конфликтующих объекта. Проверьте исходный код страницы перед добавлением.
Проверка результата
Прогоните готовый JSON-LD через валидатор структурированных данных и через отчёт по расширенным результатам в Google Search Console. Валидатор ловит синтаксис, отчёт показывает, что реально распознано поиском.
Отдельно проверьте страницу в Яндекс.Вебмастере: его валидатор строже к части полей и подсвечивает то, что валидатор Google пропускает.
После внедрения подождите две-три недели и посмотрите отчёт по расширенным результатам: если объект не появился, чаще всего дело в неполном адресе или в конфликте двух разметок на странице.