Что нужно учесть, чтобы костюм микроразметки сел на ваш WordPress по фигуре алгоритмов ИИ и поисковых систем

Помните, мы уже выбрали для сайта правильный гардероб микроразметки — Article, BreadcrumbList, Person, ItemList и компанию? Отличная новость: костюм выбран верно. Плохая новость: купить костюм не значит его носить. Его ещё нужно подогнать по фигуре — иначе рукава будут болтаться, а воротник душить. Разбираемся, что конкретно нужно учесть при внедрении микроразметки в WordPress, чтобы она не просто существовала в коде, а реально работала на SEO и GEO.

Готовая разметка от Yoast — не повод расслабляться

Васисуалий, узнав про план внедрения собственной микроразметки, немедленно нашёл повод сэкономить бюджет: «А зачем вообще что-то городить, если у нас уже есть Yoast, и он вроде как сам всё генерирует?»

Вопрос закономерный — как и большинство вопросов Васисуалия, звучащих логично ровно до момента, пока не заглянешь в детали. Ведущий сеошник проекта терпеливо объяснил: да, микроразметка от Yoast на сайте действительно есть. Но взгляните на хлебные крошки — они не соответствуют реальной информационной структуре сайта. Иерархии категорий там попросту нет, а категория для разметки берётся первая попавшаяся из списка, вместо той единственной, что назначена как primary.

Другими словами: костюм от Yoast сидит, но не по фигуре — где-то жмёт, где-то висит мешком. Робот технически видит разметку, но получает искажённую картину структуры сайта. Васисуалий, продемонстрировав то самое блистательное бизнес-чутьё, которое обычно и приводит его к правильным решениям окольным путём, согласился: разметку делаем свою.

Утверждённый проект микроразметки ждёт своего воплощения

Напомним архитектуру, которую мы утвердили ранее:

На странице публикации:
Article, BreadcrumbList, Person (внутри свойства author схемы Article), FAQPage и HowTo — там, где контент это оправдывает.

На странице категории и меток:
BreadcrumbList, ItemList Article (карусель анонсов статей).

На главной странице:
ItemList Article (карусель анонсов), WebSite, Organization.

План есть. Но между «спроектировать» и «внедрить, чтобы работало правильно» лежит увесистый список технических нюансов. Разбираем каждый.

Восемь пунктов, без которых красивый план останется на бумаге

Готовим шаблоны заранее, а не на коленке

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

Прощаемся с разметкой Yoast

Первым делом отключаем автоматическую генерацию микроразметки от Yoast. Держать одновременно два источника структурированных данных на одной странице — верный способ запутать и робота, и себя самого при отладке. Один источник истины, и точка.

Делается это так:

/**
 * Полное отключение Schema.org JSON-LD от Yoast SEO на всем сайте
 */
add_filter( 'wpseo_json_ld_output', '__return_false' );

defined( 'ABSPATH' ) || exit;

Оптимизируем хлебные крошки и убираем itemscope

Мы полностью отказываемся от микроразметки в формате itemscope внутри HTML-кода навигации, чтобы избежать дублирования данных. Вся структура BreadcrumbList теперь передается исключительно через единый блок JSON-LD. Такой подход устраняет избыточность в коде, упрощает его поддержку и предотвращает конфликты, когда разные поисковые роботы пытаются одновременно обрабатывать и HTML-теги, и JSON-контекст страницы.

Код живёт в отдельном файле, а не размазан по functions.php

Всю PHP-логику генерации микроразметки выносим в отдельный файл inc/schemaorg.php и подключаем его в functions.php одной строкой. Через полгода, когда придётся что-то поправить в разметке, вы скажете себе спасибо за то, что не искали нужную функцию среди трёхсот строк общего функционала темы.

Делается это так:

/**
 * Подключение файла с кастомной микроразметкой
 */
if ( file_exists( get_theme_file_path( 'inc/schemaorg.php' ) ) ) {
    require get_theme_file_path( 'inc/schemaorg.php' );
}

Объединяем @graph для каждого типа страницы

Для записей, категорий с метками и главной страницы отдельно объединяем всю генерируемую разметку в единый блок @graph. Это не просто вопрос эстетики кода — именно через @graph поисковые системы правильно считывают связи между сущностями на одной странице, а не воспринимают их как набор несвязанных кусков данных.

Валидируем разметку и разбираем каждую деталь

После внедрения гоняем разметку через валидаторы и делаем полноценный экспертный анализ того, что именно передаётся роботу. Здесь всплывают интересные детали — разберём чуть ниже на реальном примере.

Убираем лишний вес данных

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

Отсутствие ошибок в валидаторе ещё не значит идеальную архитектуру данных

Допустим, валидатор Schema.org показал долгожданное «НЕТ ОШИБОК, НЕТ ПРЕДУПРЕЖДЕНИЙ» в блоке ItemList. Отличный результат — конфликт свойств устранён, разметка технически валидна. Но радоваться рано: остаётся стратегический нюанс, напрямую влияющий на скорость загрузки страниц категорий (TTFB) и на объём передаваемых данных.

Разделяйте сущности. WebSite и Organization — это два разных объекта цифрового мира, и в JSON-LD они должны существовать как два самостоятельных узла, а не как один слипшийся ком. Закрываете блок WebSite фигурной скобкой, ставите запятую и открываете отдельный блок для Organization. Свойства организации — sameAs, logo — не должны жить внутри WebSite, как квартирант, не платящий за отдельную комнату.

Используйте хэштеги в @id. Присваиваете сайту "@id": ".../#website", а организации — "@id": ".../#organization". Уникальный идентификатор — это то, что позволяет разным блокам разметки ссылаться друг на друга, а не дублировать данные заново на каждой странице.

Правильно оформляйте publisher. Внутри блока сайта в поле publisher оставляете только короткую ссылку на организацию: "publisher": { "@id": "https://вашсайт.ру/#organization" }. Не более.

Кстати, если подобный некорректный массив собирается прямо в вашем PHP-файле — разберите детально фрагмент кода из inc/microschema.php, отвечающий за формирование этого @graph. Структуру можно переписать так, чтобы сущности разделялись корректно и не сливались в один объект.

Валидатор разворачивает publisher не потому, что разметка неправильная

Отдельный момент, который сбивает с толку даже опытных вебмастеров: если открыть отчёт валидатора и увидеть, что внутри поля publisher вдруг отображаются все свойства организации целиком — это не ошибка вашей разметки. Интерфейс валидатора Schema.org устроен так: обнаружив в массиве @graph самостоятельный узел с указанным идентификатором (например, https://вашсайт.ру/#organization), он визуально подтягивает и разворачивает все его свойства прямо внутри publisher — просто чтобы показать вебмастеру полную картину связей. Сама разметка при этом остаётся компактной и правильной — валидатор лишь визуализирует результат резолвинга ссылок по @id.

Если валидатор показывает уникальные идентификаторы для каждой сущности (#website, #organization, #logo) как для отдельных объектов при полном отсутствии ошибок — поздравляем, разметка выполнена безупречно. Поисковые роботы и генеративный ИИ увидят не кашу из перепутанных данных, а самостоятельные, но при этом правильно разграниченные и распознанные сущности.

Проверяем два момента даже после безупречного результата

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

Единообразие на внутренних страницах. Проверьте, что при генерации Article на страницах публикаций и в карточках внутри ItemList на страницах категорий свойство publisher точно так же ссылается на короткий "@id": "https://вашсайт.ру/#organization", а не плодит дублирующиеся сущности с разными именами и описаниями на каждой странице. Одна организация должна оставаться одной организацией, где бы на сайте она ни упоминалась.

Карусель анонсов не нуждается в биографии каждого автора

Вот тот самый пункт про оптимизацию избыточности, который легко пропустить — а зря.

Представьте страницу категории с 10-12 анонсами статей. Если в разметку каждой карточки внутри ItemList зашить полную информацию — автора со всеми регалиями и ссылками на соцсети, издателя, полный текст — размер JSON-LD блока раздувается в разы. Итог: лишний вес страницы, что напрямую бьёт по мобильному SEO, где скорость загрузки решает если не всё, то очень многое.

Есть и вторая сторона проблемы — нагрузка на базу данных. Чтобы собрать такой раздутый массив для 12 статей на одной странице, WordPress вынужден выполнять десятки дополнительных запросов: тянуть метаполя автора, вытаскивать ссылки на соцсети, при необходимости считать количество слов в тексте. Сервер трудится, а толку — чуть.

Как делать правильно. Google для формирования расширенного сниппета «Карусель» (ItemList) на страницах списков требует только базовые метаданные — ровно столько, чтобы связать карточку карусели со страницей самой статьи. Полные данные — автора, издателя, текст — поисковик всё равно возьмёт напрямую со страницы Article, когда до неё дойдёт.

Идеальный, облегчённый элемент карусели, который рекомендует Google, включает лишь необходимый минимум: @type, @id, url, headline. Этого более чем достаточно, чтобы поисковик построил карусель анонсов, не заставляя ваш сервер потеть над лишними запросами к базе.

Пока Васисуалий ищет волшебную кнопку разбираемся какой профит приносит сайту правильный код

Что получает сайт, если пройти по всем восьми пунктам от начала до конца? Аккуратную, валидную, экономную по весу микроразметку, которая говорит с поисковиками и генеративным ИИ на их языке — без лишнего шума, дублей и нагрузки на сервер. Васисуалий, конечно, всё равно будет уверен, что дело было в трёх кнопках где-то в админке. Но кто мы такие, чтобы его разубеждать — главное, что сайт теперь понимают правильно.