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

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

На связи Вадим из студии marmelad.digital.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример:

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

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

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

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

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

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

Статьи - WebPage, BlogPosting, ImageObject, BreadcrumbList.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для статьи:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это данные, которые относятся ко всем страницам.

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

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

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

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

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

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

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

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

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

В зависимости от содержания её можно описать как Course или как Service.

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

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

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

Если цена на странице не указана или рассчитывается после консультации, блок offers лучше убрать.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обычно это Organization и WebSite.

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

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

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

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

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

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

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

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

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

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

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

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

Ссылка:

https://validator.schema.org/

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

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

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

Ссылка:

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

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

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

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

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

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

Ссылка:

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

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

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

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

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

https://jsonlint.com/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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