Разметка SoftwareApplication для приложения: пошаговый пример

Разметка — это не магия и не способ обмануть нейросеть. Это перевод вашего честного описания продукта на язык, который поисковики и языковые модели читают однозначно. Слабый продукт сильным она не сделает. Но хорошему продукту она мешает модели ошибиться в фактах — а это для App AEO уже половина дела.

Что такое SoftwareApplication и чем от него отличается MobileApplication?

SoftwareApplication — это базовый тип schema.org для описания любой программы: десктопной, веб- или мобильной. Он сообщает машине, что объект на странице — приложение, и задаёт его свойства: имя, категорию, операционную систему, цену, рейтинг. MobileApplication — это уточняющий подтип SoftwareApplication специально для мобильных приложений. Оба официально документированы на schema.org, и это публичный факт, на который можно опираться смело. Разница между ними на практике невелика, но важна для точности. Если ваш продукт — мобильное приложение для Android и iOS, корректнее использовать "@type": "MobileApplication": вы сразу даёте машине более конкретный класс объекта. Если приложение существует и как веб-сервис, и как мобильное, и как десктоп, можно остаться на родительском SoftwareApplication — он шире и покрывает все формы. У MobileApplication есть несколько специфичных полей вроде carrierRequirements (требования к оператору связи), но в большинстве случаев набор свойств у них одинаковый. Я обычно рассуждаю так. Чем точнее тип, тем меньше у модели простора для домысливания. Поэтому для чисто мобильного продукта беру MobileApplication, а SoftwareApplication оставляю для случаев, когда у приложения несколько платформенных воплощений и хочется описать их одной сущностью. Ошибкой ни один из вариантов не будет — оба валидны и оба читаются. Зачем это вообще нужно нейросети? Когда модель формирует ответ на запрос «посоветуй приложение для учёта расходов», она опирается на источники, которые понимает. Простой текст на лендинге она интерпретирует — и может ошибиться: спутать платформу, неверно понять, платное приложение или бесплатное. Разметка убирает эту неоднозначность. Поля applicationCategory, operatingSystem, offers становятся не предложениями для разбора, а готовыми фактами. Это резко повышает то, что я называю извлекаемостью: модель достаёт нужные данные без догадок.

Какие поля обязательны, а какие рекомендованы?

Строго обязательное поле в разметке приложения по сути одно — name, само имя продукта. Без него объект бессмысленный. Но «минимально достаточная» разметка, которую стоит делать на практике, шире: к имени добавляют категорию, платформу и блок предложения с ценой. Это тот набор, по которому машина уверенно классифицирует приложение и понимает его базовые условия. Всё остальное — рекомендованные поля, которые усиливают картину, но не ломают разметку своим отсутствием. Я делю поля на три группы по приоритету, и в работе иду именно в таком порядке. Первая группа — каркас, без которого разметка не имеет смысла: name, applicationCategory, operatingSystem. Это «кто я, к какому классу задач отношусь и на чём работаю». Если заполнить только их, модель уже понимает сущность продукта. Вторая группа — коммерческие и доверительные сигналы: offers (цена и валюта) и aggregateRating (рейтинг и число оценок). Здесь начинается зона риска, о которой я подробно скажу ниже: offers заполняйте всегда, а aggregateRating — только если рейтинг реально есть. Третья группа — обогащение: downloadUrl, screenshot, softwareVersion, author, publisher, description, operatingSystem с точными версиями. Эти поля дают модели больше зацепок и связывают приложение с компанией-разработчиком, но без них разметка остаётся валидной. Важная оговорка по поисковым системам. Раньше Google показывал по такой разметке богатый сниппет приложения со звёздами в выдаче, но он отказался от этого формата ещё несколько лет назад. Значит ли это, что разметка бесполезна? Нет. Звёзды в обычной выдаче — это лишь один сценарий. Для App AEO важнее другое: структурированные данные остаются машиночитаемым описанием продукта, которое считывают и краулеры, и языковые модели через веб-поиск. Так что размечать имеет смысл не ради звёздочек, а ради ясности сущности.

Как выглядит рабочий пример JSON-LD?

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

{
  "@context": "https://schema.org",
  "@type": "MobileApplication",
  "name": "Кошелёк: учёт расходов",
  "description": "Приложение для учёта личных расходов и планирования бюджета: категории трат, статистика по неделям, работа офлайн.",
  "applicationCategory": "FinanceApplication",
  "operatingSystem": "Android 9.0+, iOS 15.0+",
  "softwareVersion": "3.4.1",
  "downloadUrl": "https://www.rustore.ru/catalog/app/ru.example.wallet",
  "screenshot": [
    "https://example.ru/app/screen-1.png",
    "https://example.ru/app/screen-2.png"
  ],
  "offers": {
    "@type": "Offer",
    "price": "0",
    "priceCurrency": "RUB"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "ratingCount": "1280",
    "bestRating": "5",
    "worstRating": "1"
  },
  "author": {
    "@type": "Organization",
    "name": "ООО «Пример»",
    "url": "https://example.ru"
  },
  "publisher": {
    "@type": "Organization",
    "name": "ООО «Пример»",
    "url": "https://example.ru"
  }
}

Ещё раз, без этого никак: значения ratingValue «4.6» и ratingCount «1280» в примере — выдуманные, для демонстрации структуры. У вашего приложения они должны точно совпадать с реальным рейтингом — например, с тем, что показывает карточка в RuStore или ваша собственная честная агрегация отзывов на сайте. То же касается цены, версии и ссылок: всё это надо заменить на свои фактические данные. Несколько практических замечаний по примеру. Поле operatingSystem я указал с минимальными версиями ОС — это полезный уровень детализации, но допустимо написать и просто «Android, iOS». Поле screenshot принимает массив URL — давайте по одному снимку на ключевой экран. Блоки author и publisher я заполнил одной организацией, потому что чаще всего разработчик и издатель совпадают; если у вас это разные юрлица, укажите оба честно. А offers с price: "0" — это корректный способ обозначить бесплатное приложение; если у вас платная версия или подписка, поставьте реальную цену и валюту. Синтаксис в примере валидный: это полноценный JSON-объект, где строки в двойных кавычках, вложенные сущности оформлены своими @type, а массив скриншотов — в квадратных скобках. Если будете править руками, следите за запятыми: лишняя запятая после последнего поля в объекте ломает JSON, и валидатор это поймает.

Где размещать разметку на странице и как проверить валидатором?

Размещают JSON-LD в коде страницы приложения на вашем сайте — на том самом лендинге, который вы контролируете полностью. Технически это блок <script type="application/ld+json">…</script>, который ставят либо в <head>, либо в конце <body>. Для языковых моделей и поисковиков место в коде роли почти не играет, главное — чтобы блок присутствовал на странице, отдавался в исходном HTML и содержал валидный JSON. JSON-LD удобен именно тем, что не вплетается в вёрстку: это отдельный блок данных, который не зависит от того, как оформлен видимый контент. Принципиальный момент — разметка должна описывать ту же страницу, на которой стоит. Не нужно вешать разметку приложения на главную, если приложение описано на отдельном лендинге: ставьте её туда, где есть видимый человеку контент про этот продукт. Структурированные данные и видимое содержимое должны соответствовать друг другу — это требование и поисковиков, и здравого смысла. После внедрения разметку обязательно проверяют валидатором. Я пользуюсь двумя инструментами и советую прогонять через оба:

• Schema.org Validator (validator.schema.org) — показывает, корректно ли разобрана разметка по типам и свойствам, и подсвечивает синтаксические ошибки.
• Google Rich Results Test — проверяет, видит ли разметку Google и нет ли в ней критичных ошибок с точки зрения поисковика.

Логика проверки простая: вставляете URL страницы или сам код, запускаете и смотрите на ошибки и предупреждения. Ошибки (errors) — это то, что ломает разметку, их чинят обязательно. Предупреждения (warnings) — обычно про необязательные поля, которые стоило бы добавить; на них смотрят по ситуации. Если валидатор разобрал объект как MobileApplication и показал ваши поля без ошибок, синтаксис в порядке. Это та же процедура, что и при разметке обычного сайта в GEO, — отличается только тип объекта. Кто уже размечал FAQ или статьи через JSON-LD, тот делает приложение по точно такому же сценарию: написал блок, проверил валидатором, выложил.

Какие типичные ошибки делают в разметке приложения?

Главная и самая опасная ошибка — выдуманный aggregateRating. Это когда в разметку вписывают красивый рейтинг «4.9» с тысячами оценок, которых на самом деле нет. Соблазн понятен: рейтинг выглядит как сигнал доверия. Но это прямой обман и поисковика, и нейросети, и за ложные структурированные данные Google применяет ручные санкции — вплоть до исключения сниппета или понижения страницы. Правило железное: в aggregateRating идут только реальные, проверяемые числа. Нет рейтинга — поле просто не заполняют. Это не повредит разметке: каркас работает и без него. Разберу остальные частые ошибки, которые я вижу при аудитах.

• Несоответствие разметки и видимого контента. В JSON-LD цена «0», а на странице написано «по подписке 299 ₽/мес». Поисковик считает это попыткой манипуляции. Данные в разметке и на экране должны совпадать.
• Невалидный JSON. Лишняя или пропущенная запятая, незакрытая кавычка, кириллица без экранирования в неподходящем месте. Любая такая мелочь ломает весь блок — валидатор покажет, где.
• Неверный тип объекта. Размечают приложение как Product или WebSite вместо SoftwareApplication/MobileApplication. Машина классифицирует продукт неправильно.
• Устаревшие данные. Цена изменилась, версия обновилась, число оценок выросло — а в разметке всё по-старому. Поисковик и модель верят разметке буквально, поэтому старые данные хуже отсутствия.
• Разметка без видимого контента. JSON-LD есть, а на странице про приложение почти ничего нет. Структурированные данные должны опираться на реальный контент, а не заменять его.
• Разные названия в разметке и в сторах. Если в JSON-LD одно имя, в RuStore другое, нейросеть может не связать это в один продукт.

Как держать разметку в синхроне с реальностью?

Разметка — это не «сделал и забыл», а живой слепок продукта, который надо обновлять вместе с ним. Цена изменилась, добавилась поддержка новой платформы, вышла крупная версия, выросло число оценок — всё это должно отразиться в JSON-LD. Поисковик и нейросеть читают структурированные данные буквально и доверяют им, поэтому устаревшая разметка вводит их в заблуждение активнее, чем её отсутствие. На практике я привязываю обновление разметки к событиям в жизни продукта, а не к календарю. Удобно встроить это в существующие процессы: выкатываете релиз — заодно правите softwareVersion; меняете тариф — правите offers; обновляете скриншоты в сторе — обновляете screenshot. Так разметка не отрывается от реальности и не превращается в забытый артефакт. Отдельно про aggregateRating, если вы его ведёте. Рейтинг — самое подвижное поле: число оценок растёт постоянно. Держать его абсолютно точным «до последней оценки» нереально и не нужно — но грубое расхождение (в разметке 4.9, а реально 3.8) недопустимо. Разумный подход — периодически синхронизировать значение с фактическим, например при каждом релизе или раз в обозначенный период. Если поддерживать точность тяжело, честнее не указывать рейтинг в разметке вообще, чем держать заведомо устаревший. Чтобы синхронизация не была мучением, я советую завести короткий чек-лист «что проверить в разметке при релизе»: версия, цена, платформы, ссылки на сторы, рейтинг. Пять пунктов, минута работы — но именно эта минута отделяет разметку, которой можно верить, от разметки, которая тихо врёт. И ещё одно: один раз пройдитесь по этим полям и спросите себя, по каким уточняющим запросам вы хотите попадать в ответы нейросети («бесплатное», «офлайн», «для Android») — и проследите, чтобы соответствующие поля и видимый текст это подтверждали. Последнее, что часто упускают, — синхронизация разметки с перелинковкой. Когда у приложения появляется новый раздел сайта или новый материал (обзор, кейс, страница функции), важно не только поставить ссылку в тексте, но и обновить связанные поля разметки: sameAs у бренда, isPartOf у дочерних страниц, хлебные крошки. Если этого не сделать, нейросеть будет видеть устаревшую карту связей и хуже понимать структуру продукта. Поэтому я отношусь к разметке и перелинковке как к единому слою: меняется один — проверяется второй.

Таблица: поля схемы, назначение и примеры

Свёл ключевые поля в одну таблицу — это карта того, что и зачем заполнять. Значения в колонке «пример» — образцы, не реальные данные.

Поле	Назначение	Пример значения
@type	Тип объекта: приложение или мобильное приложение	MobileApplication
name	Название приложения (единое со сторами)	«Кошелёк: учёт расходов»
description	Краткое описание сути продукта	«Учёт расходов и бюджет, статистика, офлайн»
applicationCategory	Класс задач приложения	FinanceApplication
operatingSystem	Платформы и минимальные версии ОС	«Android 9.0+, iOS 15.0+»
softwareVersion	Текущая версия приложения	«3.4.1»
offers → price / priceCurrency	Цена и валюта (0 — для бесплатного)	«0» / «RUB»
aggregateRating → ratingValue / ratingCount	Рейтинг и число оценок (ТОЛЬКО реальные)	примерные: «4.6» / «1280»
downloadUrl	Ссылка на карточку в сторе	URL карточки в RuStore
screenshot	Скриншоты ключевых экранов	массив URL изображений
author / publisher	Разработчик и издатель приложения	Organization «ООО „Пример»»

Колонку aggregateRating я намеренно подписал «ТОЛЬКО реальные»: это единственное поле в таблице, ошибка в котором грозит санкциями, а не просто неточностью. Все остальные при необходимости можно оставить пустыми без последствий для валидности.

Закажите технический аудит приложения за 5000 ₽

Разметка — это один из пунктов технического аудита, с которого мы начинаем работу над видимостью приложения в нейросетях. На аудите я проверяю, читаема ли карточка и лендинг для ИИ, есть ли валидная SoftwareApplication/MobileApplication schema, не врут ли структурированные данные и какие барьеры мешают модели рекомендовать ваш продукт. По итогам вы получаете список проблем и понятный план, что чинить в первую очередь. Аудит стоит 5000 ₽ при подписке на наш Telegram-канал (или 15 000 ₽ без подписки) — это сознательно низкий порог входа против агентских прайсов в 150–200 тысяч рублей в месяц. Написать можно в Telegram @optimentor, по телефону +79531650000 или на help@optimentor.ru.

Частые вопросы (FAQ)

Читайте по теме

Этот разбор — часть пакета по продвижению приложений в ответах нейросетей.

• Обзорный гид со всей системой — Продвижение приложений в ответах нейросетей.
• Про то, где разместить разметку и как собрать страницу под ИИ, — Лендинг приложения для ИИ.
• Про источник данных для полей downloadUrl и name — Карточка в сторах.