Микроразметка на Tilda: внедрение JSON-LD, проверка и типовые ошибки

На связи Вадим из студии marmelad.digital. В этой статье разберу JSON-LD для сайтов на Tilda: что именно размечать, как разделять общий код и код конкретной страницы, где проверять микроразметку и какие ошибки чаще всего появляются после правок сайта.

Материал не про то, как скопировать готовый JSON из генератора. Такой вариант годится только для самых простых страниц.

На коммерческом сайте разметку лучше собирать от структуры: есть сайт, организация, конкретные страницы, услуги, статьи, контакты, изображения, хлебные крошки и вопросы.

Часть этих данных относится ко всему сайту, часть — только к одной странице.

Если это не разделить сразу, дальше начинаются дубли, старые URL, одинаковые схемы на всех страницах и странные предупреждения в валидаторах.

Для примеров возьму нейтральную нишу — учебный центр.

1. Что такое JSON-LD и зачем он нужен на Тильде

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

Для Tilda JSON-LD удобен тем, что его можно добавить отдельным скриптом. Не нужно размечать каждый HTML-элемент внутри блоков.

Но JSON-LD не должен жить отдельно от страницы.

Если в коде указана услуга, она должна быть описана на странице.

В разметке есть FAQ — пользователь должен видеть эти вопросы и ответы.

Если указан автор статьи, его лучше показать в самом материале.

Гугл в своей справке отдельно пишет, что структурированные данные должны соответствовать содержимому страницы, а наличие корректной разметки не гарантирует показ расширенного результата в выдаче.

На Тильде это особенно заметно.

Платформа позволяет быстро вставить код в head сайта или отдельной страницы, поэтому микроразметку часто добавляют без предварительной схемы.

На небольшом лендинге это может не вызвать проблем. А вот на сайте с услугами, блогом, контактами и несколькими посадочными страницами такой код быстро становится трудно поддерживать.

2. Почему генератора недостаточно

Генератор JSON-LD может быть полезен как черновик.

Он быстро создаёт базовый код для Organization, Article, FAQPage или другого типа.

Проблема начинается, когда такой код вставляют на сайт без проверки структуры.

Генератор не знает, как устроен конкретный сайт. Он не понимает, что одна часть кода должна быть общей для всего проекта, а другая относится только к странице курса, статье или контактам.

Он не проверяет, есть ли на странице видимый FAQ, совпадает ли дата публикации, доступна ли картинка, не остался ли технический домен в URL.

Всё это остаётся на стороне специалиста.

Я обычно начинаю не с генератора, а с небольшой таблицы.

Сначала выписываю типы страниц и главную сущность каждой страницы. Для учебного центра это может выглядеть так.

Уже понятно, что Organization и WebSite можно вынести в общий head сайта, а разметку конкретного курса, статьи или FAQ нужно добавлять на уровне отдельной страницы.

3. Основные элементы JSON-LD

Ниже разберу элементы, которые чаще всего используются на коммерческих сайтах.

Формально это свойства и ключи JSON-LD, но в рабочей речи их часто называют операторами.

Главное — понимать, за что отвечает каждый элемент и где его лучше применять.

@context

@context указывает словарь, по которому нужно читать данные.

Для Schema.org обычно используется такой вариант:

"@context": "https://schema.org"

Минимальный пример:

<script type="application/ld+json">{  "@context": "https://schema.org",  "@type": "Organization",  "name": "Учебный центр Практика",  "url": "https://example.ru/"}</script>

Если на странице несколько отдельных JSON-LD-блоков, @context может повторяться.

Это не всегда ошибка, но на страницах с несколькими связанными сущностями удобнее использовать @graph.

@type

@type задаёт тип сущности.

Например, Organization, WebSite, WebPage, Service, Course, Article, BlogPosting, BreadcrumbList, FAQPage.

"@type": "Service"

Ошибки чаще появляются из-за выбора типа.

Страницу учебного курса можно описывать по-разному, в зависимости от содержания.

Если это страница услуги обучения, можно использовать Service.

На странице подробно описан именно образовательный курс — логичнее смотреть в сторону Course.

Если это статья с методическими советами, подойдёт Article или BlogPosting.

@id

@id задаёт стабильный идентификатор сущности.

Без него разные блоки JSON-LD могут выглядеть как независимые объекты, даже если речь идёт об одной и той же организации или одном сайте.

Пример:

{  "@type": "Organization",  "@id": "https://example.ru/#organization",  "name": "Учебный центр Практика",  "url": "https://example.ru/"}

Теперь на эту организацию можно ссылаться из других объектов.

"publisher": {  "@id": "https://example.ru/#organization"}

"provider": {  "@id": "https://example.ru/#organization"}

Удобно заранее зафиксировать схему идентификаторов.

На Тильде это полезно, потому что часть кода может стоять в настройках всего сайта, а часть — в настройках конкретной страницы.

@graph

@graph позволяет собрать несколько сущностей в одном JSON-LD-блоке.

Для главной страницы это может быть Organization, WebSite и WebPage.

Для страницы курса — WebPage, Course или Service, BreadcrumbList.

Для статьи — WebPage, BlogPosting, ImageObject, BreadcrumbList.

<script type="application/ld+json">{  "@context": "https://schema.org",  "@graph": [    {      "@type": "Organization",      "@id": "https://example.ru/#organization",      "name": "Учебный центр Практика",      "url": "https://example.ru/"    },    {      "@type": "WebSite",      "@id": "https://example.ru/#website",      "url": "https://example.ru/",      "name": "Учебный центр Практика",      "publisher": {        "@id": "https://example.ru/#organization"      }    }  ]}</script>

Можно обойтись несколькими отдельными скриптами, но @graph проще читать и проверять.

В одном блоке сразу видно, какие сущности есть на странице и как они связаны.

name, description, url

name — название сущности.

"name": "Курс Python для начинающих"

description — короткое описание.

"description": "Очный и онлайн-курс Python для начинающих: основы синтаксиса, практика, домашние задания и итоговый проект."

url — полный адрес страницы или сущности.

"url": "https://example.ru/courses/python/"

Лучше использовать абсолютные URL.

mainEntity и mainEntityOfPage

mainEntity показывает основную сущность страницы.

На странице курса это может быть Course или Service.

На статье — Article или BlogPosting.

"mainEntity": {  "@id": "https://example.ru/courses/python/#course"}

mainEntityOfPage часто используется внутри статьи.

"mainEntityOfPage": {  "@id": "https://example.ru/blog/kak-vybrat-kurs/#webpage"}

Эти свойства помогают разделить саму страницу и объект, который она описывает.

isPartOf

isPartOf связывает страницу с сайтом.

"isPartOf": {  "@id": "https://example.ru/#website"}

Я обычно добавляю это свойство в WebPage.

Оно помогает держать граф аккуратным: конкретная страница относится к конкретному сайту.

publisher, author, provider

publisher — издатель материала.

Для статьи в блоге учебного центра издателем может быть организация.

"publisher": {  "@id": "https://example.ru/#organization"}

author — автор статьи.

"author": {  "@type": "Person",  "@id": "https://example.ru/#person-editor",  "name": "Редакция учебного центра"}

provider — поставщик услуги или курса.

"provider": {  "@id": "https://example.ru/#organization"}

Если автор указан в JSON-LD, его лучше показать на странице.

Для статьи это важно. Иначе код описывает данные, которых пользователь не видит.

sameAs

sameAs связывает организацию с официальными внешними профилями.

"sameAs": [  "https://vk.com/example",  "https://t.me/example"]

Сюда лучше добавлять только контролируемые профили: социальные сети, официальные страницы, подтверждённые площадки.

Случайные каталоги и старые публикации лучше не использовать.

image

Для статьи, новости, кейса или курса может понадобиться изображение.

"image": {  "@type": "ImageObject",  "@id": "https://example.ru/blog/kak-vybrat-kurs/#primaryimage",  "url": "https://example.ru/images/course-guide-cover.jpg",  "width": 1200,  "height": 630}

Проверяйте, что URL изображения открывается без авторизации и ведёт на актуальный файл.

datePublished и dateModified

Для статьи:

"datePublished": "2026-06-19","dateModified": "2026-06-19"

dateModified стоит менять после реального обновления статьи: добавили раздел, изменили данные, обновили примеры, переписали блок.

breadcrumb и itemListElement

В WebPage можно сослаться на хлебные крошки.

"breadcrumb": {  "@id": "https://example.ru/courses/python/#breadcrumb"}

Внутри BreadcrumbList используется itemListElement.

"itemListElement": [  {    "@type": "ListItem",    "position": 1,    "name": "Главная",    "item": "https://example.ru/"  },  {    "@type": "ListItem",    "position": 2,    "name": "Курсы",    "item": "https://example.ru/courses/"  }]

Порядок должен соответствовать реальной структуре сайта.

offers, areaServed, courseMode

Для страницы курса или услуги иногда нужны дополнительные свойства.

Если на странице указана цена:

"offers": {  "@type": "Offer",  "price": "25000",  "priceCurrency": "RUB",  "url": "https://example.ru/courses/python/"}

Если курс доступен онлайн и офлайн, это можно отразить в видимом тексте страницы.

Для услуг можно использовать areaServed.

"areaServed": {  "@type": "Country",  "name": "Россия"}

4. Какие типы Schema.org нужны сайту услуг

Для сайта на Tilda не нужно использовать десятки типов.

В большинстве проектов хватает понятного набора.

Сначала определяем роль страницы, потом выбираем тип.

Если начинать с типа, легко получить искусственную разметку: например, поставить Product на страницу, где нет товарной карточки, или добавить FAQPage ради сниппета, хотя на странице нет полноценного блока вопросов.

5. Общая разметка сайта: Organization и WebSite

Общий код сайта лучше держать коротким.

На уровне всего проекта обычно достаточно Organization и WebSite. Это данные, которые относятся ко всем страницам.

Пример для учебного центра:

<script type="application/ld+json">{  "@context": "https://schema.org",  "@graph": [    {      "@type": "Organization",      "@id": "https://example.ru/#organization",      "name": "Учебный центр Практика",      "url": "https://example.ru/",      "logo": {        "@type": "ImageObject",        "url": "https://example.ru/images/logo.png"      },      "sameAs": [        "https://vk.com/example",        "https://t.me/example"      ]    },    {      "@type": "WebSite",      "@id": "https://example.ru/#website",      "url": "https://example.ru/",      "name": "Учебный центр Практика",      "publisher": {        "@id": "https://example.ru/#organization"      }    }  ]}</script>

Перед вставкой проверьте домен, название, логотип и внешние профили.

Если сайт ещё на техническом домене Тильды, лучше не спешить с финальным JSON-LD или сразу запланировать замену URL после подключения основного домена.

6. Разметка главной страницы

Главная страница описывает сайт и организацию, но сама тоже является страницей.

Если Organization и WebSite уже добавлены в общий head, на уровне главной можно добавить только WebPage.

<script type="application/ld+json">{  "@context": "https://schema.org",  "@graph": [    {      "@type": "WebPage",      "@id": "https://example.ru/#webpage",      "url": "https://example.ru/",      "name": "Учебный центр Практика",      "description": "Курсы для школьников: программирование, английский язык, подготовка к экзаменам и корпоративное обучение.",      "isPartOf": {        "@id": "https://example.ru/#website"      },      "about": {        "@id": "https://example.ru/#organization"      }    }  ]}</script>

Если вы хотите держать всю разметку главной в одном блоке, можно объединить Organization, WebSite и WebPage.

Но тогда не нужно дублировать Organization и WebSite в общем коде сайта.

На Tilda проще использовать разделение: общие сущности в настройках сайта, конкретная страница в настройках страницы.

7. Разметка страницы услуги или курса

Возьмём страницу курса Python.

В зависимости от содержания её можно описать как Course или как Service. Если страница действительно про образовательный курс, с программой, форматом, сроками и стоимостью, логично использовать Course.

Если это больше страница услуги обучения от центра, можно использовать Service.

Ниже пример с Course.

<script type="application/ld+json">{  "@context": "https://schema.org",  "@graph": [    {      "@type": "WebPage",      "@id": "https://example.ru/courses/python/#webpage",      "url": "https://example.ru/courses/python/",      "name": "Курс Python для начинающих",      "description": "Курс Python для начинающих с практикой, домашними заданиями и итоговым проектом.",      "isPartOf": {        "@id": "https://example.ru/#website"      },      "mainEntity": {        "@id": "https://example.ru/courses/python/#course"      },      "breadcrumb": {        "@id": "https://example.ru/courses/python/#breadcrumb"      }    },    {      "@type": "Course",      "@id": "https://example.ru/courses/python/#course",      "name": "Курс Python для начинающих",      "description": "Базовый курс Python для взрослых: синтаксис, функции, работа с файлами, основы ООП и итоговый проект.",      "provider": {        "@id": "https://example.ru/#organization"      },      "url": "https://example.ru/courses/python/",      "offers": {        "@type": "Offer",        "price": "25000",        "priceCurrency": "RUB",        "url": "https://example.ru/courses/python/"      }    },    {      "@type": "BreadcrumbList",      "@id": "https://example.ru/courses/python/#breadcrumb",      "itemListElement": [        {          "@type": "ListItem",          "position": 1,          "name": "Главная",          "item": "https://example.ru/"        },        {          "@type": "ListItem",          "position": 2,          "name": "Курсы",          "item": "https://example.ru/courses/"        },        {          "@type": "ListItem",          "position": 3,          "name": "Курс Python для начинающих",          "item": "https://example.ru/courses/python/"        }      ]    }  ]}</script>

Если цена на странице не указана или рассчитывается после консультации, блок offers лучше убрать. Когда формат обучения, длительность, преподаватель или программа меняются, JSON-LD нужно обновлять вместе со страницей.

8. Разметка статьи

Для статьи в блоге можно использовать Article или BlogPosting.

Если это публикация в блоге учебного центра, BlogPosting будет понятным вариантом.

<script type="application/ld+json">{  "@context": "https://schema.org",  "@graph": [    {      "@type": "WebPage",      "@id": "https://example.ru/blog/kak-vybrat-kurs/#webpage",      "url": "https://example.ru/blog/kak-vybrat-kurs/",      "name": "Как выбрать курс программирования для начинающих",      "isPartOf": {        "@id": "https://example.ru/#website"      },      "mainEntity": {        "@id": "https://example.ru/blog/kak-vybrat-kurs/#article"      },      "breadcrumb": {        "@id": "https://example.ru/blog/kak-vybrat-kurs/#breadcrumb"      }    },    {      "@type": "BlogPosting",      "@id": "https://example.ru/blog/kak-vybrat-kurs/#article",      "headline": "Как выбрать курс программирования для начинающих",      "description": "Разбор критериев выбора курса программирования: программа, практика, преподаватель, формат обучения и проверка домашних заданий.",      "datePublished": "2026-06-19",      "dateModified": "2026-06-19",      "author": {        "@type": "Person",        "@id": "https://example.ru/#person-editor",        "name": "Редакция учебного центра"      },      "publisher": {        "@id": "https://example.ru/#organization"      },      "image": {        "@type": "ImageObject",        "@id": "https://example.ru/blog/kak-vybrat-kurs/#primaryimage",        "url": "https://example.ru/images/how-to-choose-course.jpg",        "width": 1200,        "height": 630      },      "mainEntityOfPage": {        "@id": "https://example.ru/blog/kak-vybrat-kurs/#webpage"      }    }  ]}</script>

Перед публикацией стоит отдельно проверить соответствие полей странице.

9. BreadcrumbList: хлебные крошки

BreadcrumbList описывает путь до страницы.

На Тильде визуальные хлебные крошки часто не выводят, особенно на небольших сайтах.

Если структура сайта есть, лучше показать её и в интерфейсе, и в JSON-LD. Так меньше расхождений между тем, что видит пользователь, и тем, что описывает код.

Пример для статьи:

<script type="application/ld+json">{  "@context": "https://schema.org",  "@type": "BreadcrumbList",  "@id": "https://example.ru/blog/kak-vybrat-kurs/#breadcrumb",  "itemListElement": [    {      "@type": "ListItem",      "position": 1,      "name": "Главная",      "item": "https://example.ru/"    },    {      "@type": "ListItem",      "position": 2,      "name": "Блог",      "item": "https://example.ru/blog/"    },    {      "@type": "ListItem",      "position": 3,      "name": "Как выбрать курс программирования",      "item": "https://example.ru/blog/kak-vybrat-kurs/"    }  ]}</script>

Проверка простая: все URL должны открываться, порядок должен совпадать со структурой, последний пункт должен вести на текущую страницу.

10. FAQPage: когда использовать

FAQPage уместен, если на странице есть полноценный видимый блок вопросов и ответов.

Для страницы курса это могут быть вопросы о длительности обучения, формате занятий, домашней работе, сертификате, оплате и записи.

<script type="application/ld+json">{  "@context": "https://schema.org",  "@type": "FAQPage",  "@id": "https://example.ru/courses/python/#faq",  "mainEntity": [    {      "@type": "Question",      "name": "Сколько длится курс Python для начинающих?",      "acceptedAnswer": {        "@type": "Answer",        "text": "Курс длится 8 недель. Занятия проходят два раза в неделю, дополнительно студенты выполняют домашние задания."      }    },    {      "@type": "Question",      "name": "Нужен ли опыт программирования для старта?",      "acceptedAnswer": {        "@type": "Answer",        "text": "Нет, курс рассчитан на начинающих. Достаточно уверенно пользоваться компьютером и быть готовым регулярно выполнять практические задания."      }    }  ]}</script>

FAQPage не стоит использовать для блока преимуществ, рекламных формулировок и вопросов, которых нет на странице.

Если вопросы добавлены только в код, разметку лучше убрать или сначала вывести нормальный FAQ-блок на странице.

11. Как внедрять JSON-LD на Tilda

На Тильде лучше разделять общий код сайта и код конкретной страницы.

Общий код относится ко всему сайту.

Обычно это Organization и WebSite. Код конкретной страницы относится к текущему URL: WebPage, Course, Service, BlogPosting, BreadcrumbList, FAQPage, ContactPage.

Если вставить всё в общий head, разметка будет появляться на каждой странице.

Общий код сайта

В настройках сайта добавляется HTML-код для head.

Туда можно поместить Organization и WebSite.

На уровне сайта размещаем только общие сущности.

Для конкретных курсов, статей, FAQ и контактов используем настройки отдельных страниц.

Код конкретной страницы

В настройках страницы добавляется HTML-код для head именно этой страницы.

Например, для страницы курса туда ставится WebPage, Course и BreadcrumbList.

Постраничная разметка должна находиться на странице, к которой она относится.

Так Course не попадёт в блог, а BlogPosting не появится на странице контактов.

После изменения кода страницу нужно опубликовать заново.

Проверять нужно опубликованный URL, а не предпросмотр.

12. Где проверять микроразметку

Проверку лучше делать в несколько этапов.

Один инструмент не закрывает всё: где-то видно синтаксис, где-то сущности Schema.org, где-то поддерживаемые расширенные результаты, где-то реакцию Яндекса.

1. Schema Markup Validator

Ссылка:

https://validator.schema.org/

Этот инструмент удобно использовать для общей проверки Schema.org.

Он показывает найденные сущности, свойства и ошибки. Подходит, когда нужно понять, что именно распознано на странице: Organization, WebPage, Course, Service, BlogPosting, BreadcrumbList.

Что смотреть:

2. Google Rich Results Test

Ссылка:

https://search.google.com/test/rich-results

Этот инструмент показывает, какие расширенные результаты Google может сформировать на основе структурированных данных страницы.

Он проверяет публичный URL или фрагмент кода. Это официальный инструмент Google для проверки.

Что важно понимать: Rich Results Test не является полной проверкой качества Schema.org.

Он смотрит на поддерживаемые Google типы расширенных результатов. Если инструмент не показывает результат для какого-то типа, это не всегда значит, что вся разметка бесполезна.

Часть структурированных данных может быть полезна для понимания страницы, но не давать отдельный расширенный блок в выдаче.

3. Яндекс.Вебмастер — Валидатор микроразметки

Ссылка:

https://webmaster.yandex.ru/site/tools/microtest/

Валидатор Яндекса проверяет популярные форматы микроразметки, включая Schema.org, Open Graph, microdata, микроформаты и RDFa.

Для проектов под русскоязычную выдачу его стоит использовать отдельно, а не ограничиваться Google-инструментами.

Что смотреть:

4. JSON Validator

Для проверки чистого JSON можно использовать любой валидатор. Например:

https://jsonlint.com/

Он не проверяет Schema.org, но помогает поймать синтаксис: лишнюю запятую, неправильные кавычки, незакрытую скобку, сломанный массив.

Что ловит JSON-валидация:

5. Проверка исходного кода страницы

После публикации откройте страницу в браузере и проверьте исходный код.

Нужно убедиться, что JSON-LD действительно попал на опубликованную страницу.

Обычно достаточно открыть страницу, нажать Ctrl+U и найти application/ld+json.

Что проверить вручную:

13. Рабочая схема внедрения

Для сайта учебного центра на Тильде схема может быть такой.

Типы JSON-LD

Где вставлять

Как проверять после внедрения

14. Вывод

Микроразметка на Tilda нормально работает, если не вставлять её одним универсальным куском на весь сайт.

Общие сущности лучше держать отдельно: Organization и WebSite относятся ко всему проекту.

Всё, что описывает конкретную страницу, нужно добавлять на уровне этой страницы: Course, Service, BlogPosting, BreadcrumbList, FAQPage, ContactPage.

Перед кодом стоит собрать простую карту страниц и понять, какая сущность главная для каждой из них. Это занимает меньше времени, чем последующая чистка дублей и старых URL.

Стабильные @id помогают связать сайт, организацию, страницы и материалы в понятную структуру. Без них разметка может оставаться валидной, но будет выглядеть как набор отдельных фрагментов.

Проверку лучше делать не одним инструментом, а цепочкой: JSON-синтаксис, Schema Markup Validator, Google Rich Results Test, валидатор Яндекса, исходный код опубликованной страницы и ручное сравнение с видимым контентом.

Главное правило простое: JSON-LD должен описывать страницу, а не дописывать за неё недостающие данные.

Если в интерфейсе нет автора, FAQ, цены, изображения или конкретной услуги, не стоит прятать это в коде. Сначала приводится в порядок страница, потом микроразметка.