Структурированные данные: какие действительно нужны сайту компании
Структурированные данные — не фактор ранжирования. Это перевод: они говорят машинам, что означает фрагмент текста, вместо того чтобы заставлять их угадывать. Именно это всё больше решает, попадёт ли страница в ответы вообще.
Самое важное вкратце
- Четырёх типов достаточно почти для любого корпоративного сайта: Organization, WebPage или Article, BreadcrumbList и FAQPage.
- Доставляется JSON-LD в
<head>— не как разметка в основном тексте. - Самая частая ошибка тихая и дорогая: сведения в структурированных данных, которых нет на самой странице.
- Три активно обсуждаемых типа сервисная компания может опустить — они срабатывают только при подходящем предложении или настоящих отзывах.
Машина, которая читает страницу, сначала видит только текст. Что «Emma Woelk» — человек, «TEISENDA GmbH» — компания, а «22 августа 2026» — дата публикации, ей приходится угадывать — или это явно указано.
Структурированные данные и есть эта явность. Они не улучшают позицию. Они решают, годится ли страница для расширенного отображения и для генерируемых ответов вообще.
Четыре, которых достаточно
1. Organization — один раз, на главной странице
Кто вы: название, адрес, логотип, год основания, профили в других сетях. Это запись, благодаря которой рядом с результатом поиска может появиться логотип — самая частая причина, почему его нет, — попросту отсутствие этой записи.
Важно: логотип должен быть растровым изображением. SVG в этом месте не обрабатывается.
2. WebPage или Article — на каждой странице
Что это за страница: заголовок, описание, язык, дата публикации и последней переработки. У статей дополнительно Article или BlogPosting с автором как отдельной записью Person — с ролью, а не только с именем.
Важно: дата изменения должна быть верной. Дата, которая заново устанавливается при каждой отрисовке страницы, — сигнал, который обесценивает сам себя.
3. BreadcrumbList — на всех подстраницах
Где эта страница находится в структуре. Видимо как путь вверху страницы, машиночитаемо в области заголовка. И то, и другое идёт вместе — путь в данных, которого нет на странице, это ложное сведение.
4. FAQPage — там, где есть настоящие вопросы
Раздел вопросов в конце статьи. Для ответных машин это самый ценный тип вообще, потому что он уже поставляет вопрос и ответ парой — именно в той форме, в какой цитируют.
Важно: только для действительно видимых вопросов на странице. Выдуманные вопросы, которые есть только в данных, — нарушение правил.
Три, которые можно опустить
Product и Offer. Для услуг с предложением по запросу они ничего не дают — без цены и наличия их всё равно не покажут. Имеют смысл только при настоящем магазине.
AggregateRating. Звёзды в результате поиска заманчивы и связаны со строгими условиями: отзывы должны быть настоящими, проверяемыми и видимыми на странице. Самостоятельно проставленные оценки — нарушение правил с реальным риском.
HowTo. В отображении был заметно урезан и уже не оправдывает затрат на сопровождение для большинства корпоративных сайтов.
А ты знал?
Структурированные данные — не фактор ранжирования, это Google неоднократно разъяснял. Они решают вопрос отображения, а не позиции.
Для ответных машин дело обстоит несколько иначе. Модель, которая должна собрать из страницы ответ, предпочтительно использует то, что однозначно размечено: пары вопрос-ответ, автор с ролью, дата последней проверки. Тогда ей не приходится угадывать, что к чему относится. Польза, стало быть, не столько в ранжировании, сколько в цитируемости.
Как их встраивают
Три правила, которые избавляют от большинства проблем.
- JSON-LD, в
<head>. Не как атрибуты в основном тексте. JSON-LD можно сопровождать отдельно от вёрстки, и он не теряется при изменениях оформления. - Один блок на страницу, не пять. Несколько записей относятся к одному
@graphи связываются между собой через@id. Так статья ссылается на ту же организацию, что стоит на главной странице, вместо того чтобы повторять её. - Создавать из того же источника, что и видимое содержимое. Если заголовок, дата и автор берутся из тех же полей, что и сама страница, они вообще не могут разойтись. Это самая действенная профилактика вообще.
Самая дорогая ошибка — самая тихая: структурированные данные говорят то, чего нет на странице. Дата изменения вчерашним числом при тексте 2023 года. Автор, который не появляется в видимой области. Вопросы в данных, которых нет на странице.
Этого не заметит ни один проверочный инструмент — данные формально действительны. Это замечается при ручной проверке, и тогда последствие касается не только затронутой разметки. Поэтому правило «создавать из того же источника» важнее любой полноты.
Проверять — в таком порядке
| Шаг | Чем | Что вы видите |
|---|---|---|
| 1. Синтаксис | Валидатор разметки Schema | Действителен ли JSON и верен ли тип |
| 2. Отображаемость | Тест расширенных результатов поиска | Возможно ли расширенное отображение |
| 3. Реальность | Search Console, раздел улучшений | Что действительно распознано, по всем страницам |
| 4. Соответствие | Прочитать самому | Есть ли каждое сведение видимо и на странице |
Шаг четыре — единственный, который не берёт на себя ни один инструмент, и единственный, на котором всплывают серьёзные ошибки.
Проверь структурированные данные этой страницы на полноту и на соответствие видимому содержимому. Видимое содержимое страницы: [вставить текст страницы] JSON-LD страницы: [вставить блок] Задачи: 1. Назови каждое сведение в JSON-LD, которого нет в видимом содержимом. Это важнейший пункт — будь здесь тщателен. 2. Назови каждое видимое сведение, которое следовало бы разметить, но которого нет (автор с ролью, дата изменения, вопросы, путь). 3. Проверь, осмысленно ли заполнены четыре базовых типа: Organization, WebPage/Article, BreadcrumbList, FAQPage. 4. Назови типы в блоке, которые для сервисной компании без магазина и без проверяемых отзывов не приносят пользы. 5. Укажи на каждое нарушение правил, особенно самостоятельно проставленные оценки и вопросы, которых на странице нет. Выведи исправленный JSON-LD в конце полностью. Не выдумывай значений — отмечай недостающее как [дополнить].
Вывод
Структурированные данные быстро переоценивают и так же быстро делают неправильно. Четыре типа покрывают потребность корпоративного сайта, и их польза не столько в позиции, сколько в том, чтобы быть цитируемым.
Единственное правило, на котором держится всё: не размечать ничего, чего нет на странице. Кто создаёт данные из того же источника, что и видимое содержимое, решил эту проблему структурно — и может почти полностью обойтись без последующих проверок.
Частые вопросы
Какие структурированные данные нужны корпоративному сайту?
Четырёх типов достаточно: Organization один раз на главной странице, WebPage или Article на каждой странице, BreadcrumbList на всех подстраницах и FAQPage везде, где есть настоящие, видимые вопросы. Product, AggregateRating и HowTo сервисной компании, как правило, не оправдываются.
Улучшают ли структурированные данные ранжирование?
Нет. Это не фактор ранжирования, а решение об отображении — например о том, могут ли появиться в результате поиска логотип, путь или раскрывающиеся вопросы. Для ответных машин они повышают цитируемость, потому что пары вопрос-ответ, автор и дата однозначно размечены, а не должны угадываться.
Почему Google не показывает наш логотип?
Самая частая причина — отсутствующая или неполная запись Organization на главной странице. Вторая по частоте причина: заложенный логотип есть только в виде SVG — в этом месте нужен растровый файл. Даже при правильной разметке права на показ нет.
Какая самая частая ошибка в структурированных данных?
Сведения, которые есть в данных, но не в видимом содержимом: неверная дата изменения, не названный автор, выдуманные вопросы. Проверочные инструменты этого не сообщают, потому что данные формально действительны. Избежать этого можно, создавая разметку из того же источника, что и видимый текст.
JSON-LD или Microdata?
JSON-LD в <head>. Это рекомендованная Google форма, её можно сопровождать отдельно от вёрстки, и она не теряется при изменениях оформления. Microdata распределяет разметку по основному тексту и ломается при каждой перестройке страницы.
Маркетинг, который настраивается сам
Бета Studio Engine уже открыта. Забронируй место и участвуй в развитии с самого начала.
Присоединиться к бете →