Микроразметка Schema.org: что это и как использовать для SEO в 2026 году
Микроразметка Schema.org, или структурированные данные, — это способ явно сообщить поисковой системе, какие сущности находятся на странице и что они означают.
Например, с помощью структурированных данных можно обозначить, что перед Google не просто набор текста и цифр, а конкретный товар с ценой и наличием, статья с автором и датой публикации, локальная компания с адресом или цепочка хлебных крошек.
Schema.org сама по себе не повышает позицию страницы и не гарантирует расширенный сниппет. Но корректная разметка помогает Google понимать содержание страницы и для поддерживаемых типов может сделать её подходящей для специальных форматов поисковой выдачи.
Актуально на сентябрь 2026 года.
Что такое Schema.org простыми словами
Обычный посетитель видит на странице:
Competent Agency
Алматы
SEO-продвижение
Поисковая система тоже умеет анализировать этот текст, но структурированные данные позволяют дополнительно сообщить:
это организация;
это её название;
это местоположение;
это официальный сайт;
это логотип;
это страница определённого типа.
То есть Schema.org — это общий словарь сущностей и свойств, которыми сайты могут описывать своё содержимое в машинно-читаемом формате.
Важно различать два понятия:
Schema.org — большой словарь типов и свойств.
Google structured data — часть этого словаря, которую Google использует для своих поисковых функций.
Не каждый тип, существующий на Schema.org, создаёт специальный rich result в Google.
Например, Schema.org содержит Service, но отдельного rich result «Service» в актуальной галерее поддерживаемых Google форматов нет. Поэтому бессмысленно обещать клиенту специальный сниппет услуги только потому, что на страницу добавлен Service.
Влияет ли микроразметка на позиции в Google
Не следует рассматривать Schema как самостоятельный способ поднять страницу в ТОП.
Корректнее разделить два эффекта.
1. Понимание содержимого
Google использует structured data как явные подсказки о содержании и классификации страницы.
Например, можно точнее описать:
организацию;
товар;
автора;
статью;
локальный бизнес;
хлебные крошки.
2. Право на определённые поисковые функции
Некоторые типы структурированных данных позволяют странице претендовать на расширенное отображение.
Но eligible не означает guaranteed.
Google отдельно указывает, что наличие полностью корректной разметки не гарантирует показ rich result. Поисковая система самостоятельно выбирает формат результата в зависимости от запроса, устройства, местоположения пользователя и других условий.
Поэтому цепочка:
добавили Schema → выросли позиции
некорректна.
Как и:
добавили Schema → обязательно вырос CTR.
Расширенный результат действительно может изменить визуальное представление страницы и взаимодействие пользователя с ней, но результат нужно измерять на конкретном сайте.
Ускоряет ли Schema индексацию
Нет оснований обещать более быструю индексацию только благодаря микроразметке.
Чтобы Google обнаруживал и индексировал страницу, по-прежнему важны:
доступность URL;
внутренние ссылки;
sitemap;
корректные HTTP-коды;
robots;
canonical;
качество самой страницы.
Structured data помогает описать уже доступное содержание, но не заменяет нормальную техническую индексацию.
После внедрения разметки Google рекомендует проверить страницу, опубликовать изменения и дать поисковой системе повторно просканировать URL. Это не означает, что сама Schema является механизмом ускоренной индексации.
В каком формате лучше добавлять Schema.org
Google поддерживает три основных формата:
JSON-LD
Microdata
RDFa
Для большинства проектов наиболее удобен JSON-LD. Google также рекомендует его как наиболее простой для внедрения и дальнейшего сопровождения вариант.
JSON-LD обычно выглядит как отдельный блок:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "..."
}
</script>
Основное преимущество — разметку не приходится распределять по десяткам HTML-элементов страницы.
Это особенно удобно на Tilda.
Какие типы Schema особенно полезны бизнес-сайту
Нет задачи поставить на сайт максимальное количество типов.
Нужно использовать только ту разметку, которая соответствует реальному содержимому страницы.
Для обычного коммерческого сайта чаще всего имеет смысл рассматривать несколько типов.
Organization — данные о компании
Organization помогает описать организацию как сущность.
Можно передавать, например:
название;
официальный URL;
логотип;
контакты;
адрес, если он применим;
связанные официальные профили.
Google рекомендует размещать информацию об организации на главной странице либо на отдельной странице, описывающей компанию.
Нет необходимости копировать несколько разных Organization на каждую страницу сайта без причины.
Особенно важно, чтобы информация в коде соответствовала фактическим данным компании.
LocalBusiness — для реального локального бизнеса
LocalBusiness подходит компаниям, связанным с конкретным физическим местоположением.
Например:
ресторану;
стоматологии;
автосервису;
салону;
магазину;
медицинской клинике;
локальной сервисной компании с реальным адресом.
Google позволяет передавать через такую разметку информацию о местной компании, включая адрес и часы работы. Для нескольких физических точек каждая локация может быть описана отдельно.
Желательно использовать наиболее конкретный подтип.
Например, если это ресторан, использовать подходящий тип ресторана, а не абстрактный LocalBusiness, когда более точный вариант существует.
Поможет ли LocalBusiness попасть в Google Maps
Не стоит обещать это как прямой результат.
Разметка помогает Google понимать информацию о компании, однако для присутствия и управления компанией в Google Maps также нужен нормальный Google Business Profile.
Schema не заменяет бизнес-профиль.
И тем более нет смысла создавать фальшивые адреса в Алматы, Астане или других городах только ради разметки.
Информация должна отражать реальный бизнес.
Article и BlogPosting — для статей Competent
Для блога один из наиболее логичных вариантов — Article или более конкретный BlogPosting.
Google указывает, что Article structured data может помочь лучше понять:
заголовок;
изображения;
дату публикации;
дату изменения;
автора статьи.
Для обновляемого блога особенно полезно корректно передавать:
headline;
image;
datePublished;
dateModified;
author.
Если статья была опубликована в 2024 году и существенно обновлена в сентябре 2026 года, не нужно притворяться, что она впервые появилась в 2026-м.
Правильнее сохранить обе даты:
дату первой публикации;
дату существенного обновления.
BreadcrumbList — хлебные крошки
BreadcrumbList описывает место страницы в иерархии сайта.
Например:
Главная → Блог → SEO → Микроразметка Schema.org.
Google может использовать такую информацию при формировании представления пути страницы в выдаче.
Для большого сайта это также соответствует нормальной информационной архитектуре: пользователь понимает, где находится и как перейти выше по структуре.
При этом хлебные крошки желательно иметь не только в коде, но и в реальном интерфейсе там, где они полезны пользователю.
Product — для товаров
Если на странице действительно находится конкретный товар, Product позволяет передавать поисковой системе данные о нём.
В зависимости от реализации и требований Google это могут быть:
название;
изображение;
цена;
предложение;
наличие;
рейтинг;
отзывы;
варианты товара;
доставка;
условия возврата.
Страницы с корректным Product могут быть eligible для товарных поисковых форматов.
Но цена в Schema должна совпадать с реальной ценой, которую видит пользователь на странице.
Нельзя написать в JSON-LD:
10 000 ₸
если на самой странице указано:
25 000 ₸.
Разметка должна описывать фактическое содержимое.
Review и AggregateRating — со звёздами всё сложнее
В старых SEO-статьях часто советовали:
Поставьте AggregateRating на страницу компании — и получите звёзды в Google.
Для собственного бизнеса это больше не является универсальной схемой.
Google ограничивает использование review snippets для LocalBusiness и Organization.
Если компания контролирует страницу и размещает на ней отзывы о самой себе, такая страница не имеет права на звёздочный review feature для организации. Это касается и отзывов, встроенных через сторонний виджет.
Кроме того:
реальные отзывы должны быть доступны пользователю на странице;
нельзя создавать фиктивные рейтинги;
нельзя разметить скрытые отзывы;
данные в Schema должны соответствовать видимому содержанию.
Поэтому разметка:
"aggregateRating": {
"ratingValue": "5",
"reviewCount": "500"
}
не является способом просто добавить пять звёзд сайту.
Если этих 500 реальных отзывов нет — такую информацию использовать нельзя.
FAQPage — важное изменение 2026 года
Раньше FAQPage был одним из самых популярных советов в SEO.
Сайт добавлял вопросы и ответы, размечал их Schema, и Google в определённых случаях мог показывать раскрывающиеся FAQ непосредственно в выдаче.
С 7 мая 2026 года Google прекратил показ FAQ rich results.
В июне 2026 года документация этого поискового формата была удалена из Google Search Central.
Поэтому добавлять FAQPage исключительно ради получения раскрывающихся блоков Google больше нет смысла.
Это не означает, что сами FAQ нужно удалять.
Хороший блок вопросов и ответов по-прежнему полезен пользователю.
Но:
FAQ полезен как контент ≠ FAQPage гарантирует специальный результат Google.
В 2026 году второе утверждение уже неверно.
Можно ли вместо FAQPage поставить QAPage
Для обычного FAQ компании — нет.
Google описывает QAPage как страницу с одним вопросом и несколькими ответами, которые могут публиковать пользователи.
Например:
форум;
сообщество;
страница технической поддержки, где пользователи отвечают друг другу.
Обычная страница:
«Часто задаваемые вопросы о SEO»
с ответами, написанными самой компанией, не соответствует этому формату.
Менять FAQPage на QAPage только ради rich result — неправильная практика.
Service — нужно ли размечать услуги
На Schema.org существует тип Service.
Им можно описывать услугу как сущность.
Однако важный нюанс: наличие типа в словаре Schema.org не означает наличие отдельного rich result Google.
В актуальной галерее поддерживаемых Google структурированных данных отдельного поискового формата Service нет.
Поэтому можно использовать такую разметку как структурированное описание данных, если она действительно полезна архитектуре сайта, но нельзя обещать:
«Добавим Service Schema — ваша услуга получит расширенный сниппет».
Google такого результата не гарантирует.
Нужно ли ставить все возможные Schema на одну страницу
Нет.
Принцип:
чем больше Schema — тем лучше SEO
не работает.
Для статьи может быть достаточно:
BlogPosting;
BreadcrumbList;
а данные Organization могут быть описаны на уровне компании.
Для карточки товара:
Product;
BreadcrumbList.
Для страницы физической компании:
подходящий LocalBusiness.
Не нужно одновременно добавлять Product, Article, LocalBusiness, FAQPage, Review, Event и десять других типов, если страница фактически ими не является.
Google рекомендует качество и корректность данных вместо попытки заполнить максимальное количество свойств.
Может ли неправильная Schema навредить
Да, как минимум можно потерять право на rich results.
Google требует, чтобы структурированные данные:
соответствовали основному содержимому;
не вводили пользователя в заблуждение;
были видимы на странице, когда требования конкретного типа этого требуют;
Google также предупреждает, что нарушения правил structured data могут привести к manual action именно в отношении расширенных результатов. Такая мера сама по себе не означает автоматическое удаление обычной страницы из органической выдачи, но rich-result eligibility может быть потеряна.
Как добавить Schema.org на Tilda
Для Tilda наиболее удобный вариант — JSON-LD.
В официальной инструкции Tilda используется следующий путь:
Настройки страницы → Дополнительно → HTML-код для вставки внутрь Head.
Туда добавляется JSON-LD, после чего страницу нужно сохранить и заново опубликовать.
То есть для каждой страницы можно добавить соответствующую ей разметку без изменения визуальных блоков.
Например, для конкретной статьи шаблон может выглядеть так:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "ЗАГОЛОВОК СТАТЬИ",
"description": "ОПИСАНИЕ СТАТЬИ",
"image": "URL ИЗОБРАЖЕНИЯ",
"datePublished": "ДАТА ПУБЛИКАЦИИ",
"dateModified": "ДАТА ОБНОВЛЕНИЯ",
"author": {
"@type": "Person",
"name": "ИМЯ АВТОРА"
},
"publisher": {
"@type": "Organization",
"name": "НАЗВАНИЕ КОМПАНИИ"
},
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "CANONICAL URL СТАТЬИ"
}
}
</script>
Это шаблон.
Нельзя копировать его на сайт, оставив условные значения.
Каждое поле необходимо заполнить реальными данными конкретной страницы.
Нужно ли добавлять JSON-LD через блок T123
Технически код на Tilda можно внедрять разными способами, но для page-level structured data удобнее использовать Head страницы, если задача не требует другой реализации.
Так код:
не смешивается с дизайном;
легче поддерживается;
не зависит от положения HTML-блока;
проще проверяется.
Для глобальных сущностей и шаблонных решений нужно отдельно следить, чтобы разметка не дублировалась некорректно на всех страницах.
Как проверить микроразметку после внедрения
Проверку лучше разделить на два уровня.
Google Rich Results Test
Показывает, распознаёт ли Google поддерживаемый тип structured data и подходит ли страница с технической точки зрения для соответствующего rich result.
Но успешный тест не гарантирует показ расширенного результата.
Schema.org Validator
Полезен для проверки самой структуры и синтаксиса Schema.org, в том числе типов, которые Google не использует для отдельных rich results.
Это важное различие.
Ситуация:
Schema.org Validator говорит, что Service корректен
не означает:
Google обязан показать специальный Service rich result.
После публикации также стоит использовать URL Inspection в Google Search Console и отслеживать отчёты по поддерживаемым типам структурированных данных там, где они доступны.
Почему Rich Results Test показывает всё правильно, а Google ничего не выводит
Это нормальная ситуация.
Google прямо предупреждает: корректная structured data делает страницу подходящей, но не гарантирует отображение специальной функции.
Причины могут быть разными:
Google выбрал обычный сниппет;
конкретный поисковый запрос не требует rich result;
функция недоступна для этого типа результата;
содержание не соответствует требованиям;
разметка не отражает основной контент;
изменения ещё не переобработаны;
функция изменилась или была прекращена.
FAQPage в 2026 году — хороший пример последнего случая: сам словарь Schema может продолжать существовать, но соответствующего FAQ rich result Google уже нет.
Стоит ли добавлять Schema ради AI Search
Не нужно рассматривать structured data как секретный переключатель для AI Overviews, AI Mode или других AI-систем.
Schema может помогать машинам точнее понимать сущности и отношения между ними, но она не заменяет:
качественный контент;
ясную структуру;
доступность для обхода;
первичные данные;
понятную информацию о компании;
внешние подтверждения;
нормальную внутреннюю перелинковку.
То есть подход:
добавим 15 типов Schema и попадём в ответы нейросетей
не имеет достаточных оснований.
Structured data — один из технических слоёв сайта, а не полноценная GEO-стратегия.
Какие Schema я бы использовал на обычном сайте услуг
Для типичного коммерческого сайта логика может выглядеть так.
Главная / страница компании
Organization
или подходящий LocalBusiness, если компания действительно является локальным бизнесом с соответствующими данными.
Страницы услуг
BreadcrumbList;
при необходимости корректное описание сущности услуги, но без ожидания специального Service rich result.
Блог
BlogPosting или Article;
BreadcrumbList.
Карточки реальных товаров
Product;
Offer;
при соответствующих условиях Review / AggregateRating;
BreadcrumbList.
Физические филиалы
отдельный соответствующий LocalBusiness для каждой реальной локации.
Главный принцип:
разметка должна описывать страницу, а не пытаться превратить страницу во что-то, чем она не является.
Частые ошибки Schema.org
Ошибка 1. Добавлять тип только ради звёзд или расширенного сниппета.
Сначала должен существовать соответствующий контент.
Ошибка 2. Размечать отзывы собственной компании и ожидать звёзды Organization.
Google ограничивает self-serving review snippets.
Ошибка 3. Использовать FAQPage как стратегию Google SEO в 2026 году.
Соответствующий rich result прекращён.
Ошибка 4. Заменять FAQPage на QAPage.
QAPage имеет совершенно другое назначение.
Ошибка 5. Добавлять несуществующую цену или рейтинг.
Structured data должна совпадать с реальным содержанием.
Ошибка 6. Считать каждый тип Schema Google rich result.
Schema.org значительно шире набора функций Google Search.
Ошибка 7. Ставить одинаковую разметку товара, статьи или локальной компании на все страницы сайта.
Тип должен соответствовать конкретной странице.
Ошибка 8. Не проверять разметку после обновления сайта.
Шаблон, CMS или редизайн могут сломать даже ранее корректный JSON-LD.
Чек-лист внедрения микроразметки
Перед публикацией ответьте на несколько вопросов:
Какую реальную сущность описывает эта страница?
Существует ли соответствующий тип Schema.org?
Поддерживает ли Google отдельный поисковый формат для этого типа?
Выполнены ли требования именно Google, а не только Schema.org?
Все ли значения соответствуют видимому содержимому?
Нет ли выдуманного рейтинга, цены, адреса или автора?
Не дублируется ли конфликтующая Schema?
Корректны ли URL и изображения?
Правильно ли указаны datePublished и dateModified?
Проходит ли страница проверку после публикации?
Такой подход полезнее, чем установка универсального плагина «Schema SEO» с автоматическим включением всех типов сразу.
Нужна ли микроразметка небольшому сайту в Алматы
Размер сайта не является основным критерием.
Если компания имеет реальное физическое присутствие, полезной может быть корректная информация о компании.
Если на сайте есть статьи — можно использовать Article или BlogPosting.
Если есть настоящие карточки товаров — Product.
Если сайт имеет иерархию — BreadcrumbList.
Но нет отдельной «Schema для Алматы», которая повышает сайт именно в Алматы.
Локальные данные должны быть реальными:
адрес;
телефон;
режим;
компания;
географическая информация.
Нельзя создавать фиктивные филиалы или размечать адрес, которого у бизнеса нет, ради локального SEO.
Нужно ли внедрять микроразметку на каждой странице
Не обязательно.
Начинать лучше с страниц, где разметка имеет понятный смысл:
главная;
контакты или страница компании;
ключевые товарные карточки;
статьи;
страницы с хлебными крошками;
реальные страницы филиалов.
После этого проверить результат и только затем масштабировать решение.
На большом сайте Schema лучше внедрять на уровне шаблонов, чтобы информация генерировалась из реальных данных CMS, а не поддерживалась вручную на сотнях URL.
Что Schema.org реально даёт SEO
Корректная формулировка выглядит так:
Structured data помогает поисковым системам лучше интерпретировать структурированную информацию страницы и может сделать контент подходящим для поддерживаемых расширенных форматов выдачи.
Но Schema:
не гарантирует ТОП;
не является самостоятельным фактором успеха;
не исправляет слабый контент;
не заменяет внутреннюю перелинковку;
не решает проблемы индексации;
не заменяет Google Business Profile;
не гарантирует рост CTR;
не даёт право выдумывать рейтинг;
не обеспечивает автоматическое попадание в AI-ответы.
Именно поэтому микроразметку нужно рассматривать как часть технического SEO, а не как «хак» для поисковой выдачи.
Итог
В 2026 году Schema.org остаётся полезным техническим стандартом, но подход к ней должен быть намного точнее, чем несколько лет назад.
Для большинства сайтов приоритетны не десятки типов разметки, а несколько правильно реализованных сущностей:
Organization или LocalBusiness → Article / BlogPosting → BreadcrumbList → Product там, где действительно продаются товары.
Особенно важно следить за актуальной документацией Google.
Хороший пример — FAQPage: ещё несколько лет назад эту разметку массово внедряли ради расширенных результатов. С мая 2026 года соответствующий FAQ rich result в Google больше не показывается.
Поэтому главный принцип работы со structured data:
сначала определить реальное содержимое страницы → проверить актуальную поддержку Google → выбрать подходящий тип → добавить только реальные данные → проверить после публикации.
Так Schema становится нормальным техническим слоем сайта, а не набором SEO-мифов.
Рекомендуемые внутренние ссылки
Анкор: SEO-продвижение сайтов в Казахстане
URL: /services/seo-promotion/
Анкор: Разработка сайтов
URL: /services/website-development/
Анкор: GEO и продвижение в AI-поиске
URL: /services/geo-ai/
Анкор: Другие статьи о SEO
URL: /blog/
Источники и методология
Материал актуализирован на сентябрь 2026 года по документации Google Search Central и официальной справке Tilda. Проверены текущий список поддерживаемых Google structured data, правила rich results, Article, Product, LocalBusiness, Review, BreadcrumbList и изменения FAQ rich results.
Что изменилось относительно старой версии
Статья полностью пересобрана.
Удалены обещания роста позиций, ускоренной индексации и CTR +20–30%. Исправлены правила Review/AggregateRating и self-serving reviews.
Удалён устаревший совет использовать FAQPage для раскрывающихся вопросов: Google прекратил показ FAQ rich results 7 мая 2026 года.
Добавлена разница между Schema.org и типами, реально поддерживаемыми Google; разобраны Organization, LocalBusiness, Article/BlogPosting, Product, BreadcrumbList, Review, Service и QAPage.
Добавлена отдельная инструкция по JSON-LD на Tilda, проверке через Rich Results Test, ограничениям structured data и правильному выбору разметки под конкретный тип страницы.