Что такое структурированные данные
Schema.org задает словарь сущностей и свойств, а поисковые системы используют поддерживаемую структурированную разметку, чтобы точнее понять содержимое страницы и в некоторых случаях показать расширенный результат.
Google отдельно подчеркивает: наличие корректной разметки не гарантирует показ расширенного результата. У каждого типа есть свои требования и поддерживаемые свойства. Актуальные типы перечислены в галерее структурированных данных Google.
Почему для кастомной разметки удобен JSON-LD
JSON-LD хранится отдельным скриптом и не требует оборачивать каждый видимый элемент страницы атрибутами. Это удобно на Tilda, где визуальная верстка и данные могут редактироваться независимо.
Типовой фрагмент выглядит так:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Название компании",
"url": "https://example.ru/"
}
</script>Это только каркас. Свойства нужно заполнять реальными данными конкретного бизнеса.
Какие типы чаще нужны бизнес-сайту
| Тип | Когда использовать |
|---|---|
| Organization | данные компании или бренда |
| LocalBusiness | реальная локальная организация с адресом и соответствующим типом деятельности |
| Article / BlogPosting | редакционные статьи и публикации |
| Product | страница конкретного товара при соблюдении требований |
| BreadcrumbList | хлебные крошки и иерархия страницы |
Не нужно добавлять LocalBusiness на компанию без публичной точки только потому, что тип кажется сильнее Organization. Разметка должна описывать реальную сущность.
Что уже делает Tilda
Перед кастомным кодом проверьте штатные возможности платформы. Tilda указывает, что на страницах товарного каталога микроразметка Schema.org формируется автоматически. Для других сценариев можно использовать настройки платформы и собственный код. См. справку Tilda по микроразметке.
Если штатная разметка уже существует, не дублируйте ту же сущность вторым противоречащим JSON-LD без причины.
Рабочие шаблоны для сайта на Tilda
Пример Organization
Для студии или компании минимально полезны название, URL, логотип и корректные контактные данные, если они публичны. Google публикует отдельные рекомендации для Organization structured data.
Не добавляйте десятки полей только потому, что они существуют в Schema.org. Лучше меньше свойств, но без ошибок и выдуманных данных.
LocalBusiness
Для локальной организации дополнительно важны адрес и другие свойства, соответствующие реальному бизнесу. У Google есть отдельная документация для LocalBusiness.
Данные JSON-LD должны совпадать с тем, что пользователь видит на сайте и в карточках организации. Если телефон изменился, обновить нужно не только текст в футере, но и структурированные данные.
Пример BlogPosting для статьи
Для редакционного материала полезно связать сущность статьи с ее заголовком, URL, датой, автором и изображением. Упрощенный шаблон:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "Заголовок статьи",
"datePublished": "2026-09-29",
"dateModified": "2026-09-29",
"mainEntityOfPage": "https://example.ru/blog/article",
"author": {
"@type": "Person",
"name": "Имя автора"
},
"publisher": {
"@type": "Organization",
"name": "Название компании"
}
}
</script>Значения должны совпадать с самой публикацией. Если у статьи нет даты обновления, не нужно придумывать ее только ради поля.
Пример LocalBusiness без выдуманных данных
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"name": "Название",
"url": "https://example.ru/",
"telephone": "+7...",
"address": {
"@type": "PostalAddress",
"streetAddress": "Улица и дом",
"addressLocality": "Город",
"addressCountry": "RU"
}
}
</script>Используйте этот тип только для реального локального бизнеса. Если компания не принимает клиентов по адресу и фактически не является локальной точкой, Organization может описывать сущность точнее.
Как добавить JSON-LD на Tilda
Кастомный скрипт можно разместить через возможности добавления HTML-кода. Для небольшого проекта удобно использовать блок T123 на нужной странице или код в head, если разметка должна загружаться там и у вас есть соответствующая настройка тарифа.
После изменения обязательно опубликуйте страницу и проверяйте уже публичный URL, а не только редактор.
Как проверить разметку
- убедитесь, что JSON валиден;
- проверьте страницу инструментом Rich Results Test, если тип поддерживает расширенные результаты Google;
- проверьте, что свойства соответствуют видимому контенту;
- после индексации смотрите отчеты Search Console для поддерживаемых типов;
- при изменении шаблона повторите тест.
Ошибка синтаксиса может сломать весь объект. Поэтому при CMS или повторяющихся шаблонах особенно важно тестировать несколько разных страниц, включая записи с пустыми необязательными полями.
Частые ошибки
- размечать рейтинг, которого пользователь не видит;
- указывать фиктивный адрес;
- копировать один и тот же Article с одинаковым URL на все статьи;
- оставлять старые телефон и логотип после ребрендинга;
- дублировать автоматически созданную разметку противоречащими данными;
- ожидать, что Schema.org сама поднимет позиции.
Масштабирование через CMS
Для блога поля JSON-LD лучше связывать с данными статьи: заголовком, URL, датой публикации, датой обновления, автором и изображением. Тогда разметка обновляется вместе с контентом, а не хранится вручную в десятках страниц.
Именно так стоит проектировать большой блог на Tilda: шаблон отвечает за структуру, а CMS - за значения.
Как связать микроразметку с CMS
| Поле статьи | Свойство JSON-LD |
|---|---|
| Title | headline |
| Alias / публичный URL | mainEntityOfPage |
| date_published | datePublished |
| date_modified | dateModified, если дата реальная |
| Автор | author |
| Обложка | image |
Главный принцип - один источник данных. Если заголовок меняется в CMS, он не должен оставаться старым внутри ручного JSON-LD. Для большого блога это важнее количества размеченных свойств.
После публикации проверяйте не только синтаксис JSON, но и соответствие требованиям конкретного поискового результата. Schema.org шире набора разметки, который Google использует для rich results: валидный тип сам по себе не гарантирует специальное отображение.
Кто должен обновлять JSON-LD после запуска
Главный риск ручной микроразметки - рассинхронизация. На странице меняется адрес, цена или автор, а JSON-LD остается старым. Для повторяющихся страниц привязывайте значения к CMS, а для статических добавьте проверку структурированных данных в релизный чек-лист.
Особенно внимательно тестируйте шаблоны после массового изменения: одна ошибка в общем коде может затронуть десятки URL.
Что считать хорошей микроразметкой
Хорошая микроразметка незаметна пользователю, но точно повторяет смысл страницы, проходит техническую проверку и обновляется вместе с контентом. Ее задача - структурировать уже качественную информацию, а не компенсировать слабую страницу.
Если нужен системный разбор технической части сайта, микроразметку стоит проверять внутри аудита сайта на Tilda, вместе с индексированием, метаданными и шаблонами.
