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

marmeladigital15 часов назад

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

Уровень сложностиСреднийВремя на прочтение17 минОхват и читатели8.3KПоисковая оптимизация*Поисковые технологии*Веб-разработка*Веб-аналитика*На связи Вадим из студии 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, WebPageСтраница курсаКонкретный курс или услуга обученияWebPage, Service или Course, BreadcrumbListСтатья в блогеМатериал с автором и датойArticle или BlogPosting, WebPage, BreadcrumbListКонтактыКонтактная информацияContactPage, OrganizationО центреИнформация об организацииAboutPage, OrganizationFAQВопросы и ответыFAQPage, если блок есть на страницеУже понятно, что Organization и WebSite можно вынести в общий head сайта, а разметку конкретного курса, статьи или FAQ нужно добавлять на уровне отдельной страницы.

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

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

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

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

@context

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

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

"@context": "https://schema.org"Минимальный пример:

Это не всегда ошибка, но на страницах с несколькими связанными сущностями удобнее использовать @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"
}Удобно заранее зафиксировать схему идентификаторов.

СущностьПример @idОрганизацияhttps://example.ru/#organizationСайтhttps://example.ru/#websiteГлавная страницаhttps://example.ru/#webpageСтраница курсаhttps://example.ru/courses/python/#webpageКурс или услугаhttps://example.ru/courses/python/#courseСтатьяhttps://example.ru/blog/kak-vybrat-kurs/#articleХлебные крошкиhttps://example.ru/blog/kak-vybrat-kurs/#breadcrumbАвторhttps://example.ru/#person-editorНа Тильде это полезно, потому что часть кода может стоять в настройках всего сайта, а часть - в настройках конкретной страницы.

@graph

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

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

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

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

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

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 не нужно использовать десятки типов.

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

Тип страницыПодходящие типыКомментарийГлавнаяOrganization, WebSite, WebPageБаза сайтаСтраница курсаWebPage, Course или Service, BreadcrumbListВыбор зависит от содержания страницыСтраница услугиWebPage, Service, BreadcrumbListДля сервисных компаний и подрядчиковСтатьяArticle или BlogPosting, WebPage, BreadcrumbListДля блога, медиа, базы знанийКонтактыContactPage, OrganizationКонтакты должны совпадать с видимыми даннымиО компанииAboutPage, OrganizationСтраница о компанииFAQFAQPageТолько при наличии видимого блока вопросовКаталогCollectionPage, иногда ItemListЕсли есть список услуг, курсов или материаловСначала определяем роль страницы, потом выбираем тип.

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

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

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

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

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

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

Что проверитьКакой рискДоменВ коде может остаться технический адресЛоготипURL может не открываться напрямуюСоцсетиВ sameAs могут попасть неофициальные страницыНазваниеВ разметке и на сайте могут быть разные варианты@idБез стабильных идентификаторов появятся дубли

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

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

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

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

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

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

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

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

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

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

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

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

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

ПолеЧто проверитьheadlineСовпадает с заголовком статьи или очень близок к немуdescriptionОписывает материал без набора ключевых словdatePublishedСоответствует дате публикацииdateModifiedМеняется после реального обновленияauthorАвтор указан в видимой части статьиpublisherСсылается на организацию через @idimageИзображение открывается по прямому URLmainEntityOfPageВедёт на WebPage этой статьи

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

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

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

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

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

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

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

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

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

СитуацияЧто делатьВопросы и ответы видны на страницеМожно добавлять FAQPageFAQ скрыт в кодеНе добавлятьОтветы рекламныеПереписать блок или не размечатьОдин и тот же FAQ стоит на множестве страницПроверить, соответствует ли он каждой страницеВопросы связаны с конкретной услугой или курсомХороший вариант для FAQPage

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.

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

Что проверятьЗачемНайдены ли нужные сущностиПроверяем, распознался ли нужный типНет ли лишних сущностейЛовим дубли и случайные схемыКорректны ли @idПроверяем связность объектовЕсть ли предупрежденияРазбираем вручнуюСовпадают ли свойстваСмотрим, не потерялись ли name, url, image

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-инструментами.

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

Что проверятьКомментарийВидит ли Яндекс разметкуПроверяем опубликованный URLЕсть ли ошибкиИсправляем обязательноЕсть ли предупрежденияРазбираем по смыслуСовпадают ли данныеСверяем с видимой страницейНе проверяется ли технический доменURL должен быть основным

4. JSON Validator

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

https://jsonlint.com/

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

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

ОшибкаПример проблемыЛишняя запятаяЗапятая перед закрывающей скобкойОдинарные кавычкиJSON требует двойные кавычкиКомментарииВ чистом JSON их быть не должноНезакрытый массивПотеряли ]Незакрытый объектПотеряли }

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

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

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

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

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

ВопросЧто ловимКод есть на опубликованной странице?Публикация могла не обновитьсяКод стоит на нужной странице?Постраничная схема могла попасть в общий headURL основного домена?Остатки технического адресаКартинка открывается?Битый ImageObjectFAQ виден на странице?Несоответствие JSON-LD и контентаАвтор есть в статье?Расхождение с authorЦена есть на странице?Лишний OfferХлебные крошки соответствуют структуре?Выдуманные разделы@id не меняются от страницы к странице без причины?Дубли сущностей

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

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

URLТип страницыГлавная сущность/ГлавнаяOrganization/courses/Раздел курсовCollectionPage или WebPage/courses/python/Страница курсаCourse/blog/БлогBlog или WebPage/blog/kak-vybrat-kurs/СтатьяBlogPosting/contacts/КонтактыContactPage/about/О центреAboutPage

Типы JSON-LD

СтраницаЧто внедрятьВесь сайтOrganization, WebSiteГлавнаяWebPageРаздел курсовCollectionPage или WebPageСтраница курсаWebPage, Course, BreadcrumbListСтатьяWebPage, BlogPosting, BreadcrumbListКонтактыContactPageFAQ-блокFAQPage, если вопросы видны

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

Уровень TildaЧто размещатьОбщий код сайтаOrganization, WebSiteКод главной страницыWebPageКод страницы курсаWebPage, Course, BreadcrumbList, FAQPage при наличииКод статьиWebPage, BlogPosting, BreadcrumbListКод контактовContactPage

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

ЭтапИнструментJSON-синтаксисhttps://jsonlint.com/Общая Schema.org-проверкаhttps://validator.schema.org/Проверка Google rich resultshttps://search.google.com/test/rich-resultsПроверка в Яндексеhttps://webmaster.yandex.ru/site/tools/microtest/Наличие кода на страницеИсходный код опубликованного URLСовпадение с контентомРучная проверка страницы

14. Вывод

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

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

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

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

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

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

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

Если в интерфейсе нет автора, FAQ, цены, изображения или конкретной услуги, не стоит прятать это в коде. Сначала приводится в порядок страница, потом микроразметка.Теги:• JSON-LD
• Schema.org
• микроразметка
• Tilda
• SEO на Tilda
• структурированные данные
• техническое SEO
• no-code SEO.
• seo-продвижение
• seo-оптимизацияХабы:• Поисковая оптимизация
• Поисковые технологии
• Веб-разработка
• Веб-аналитика

Получайте больше инсайтов о систематизации бизнеса

Подписывайтесь на Telegram-канал Business Operations — ежедневные материалы о бизнес-процессах, операционном управлении и повышении эффективности

💬 Подписаться на канал

Источник: Habr
→ Оригинальная статья