SEO Schema JSON-LD с Codex: готовый SKILL.md и процесс проверки

Коротко: Schema должна быть структурированной копией фактов со страницы

Если вы искали промпт SKILL.md для работы Codex с SEO Schema JSON-LD, ниже есть готовый вариант. Но правило важнее кода: структурированные данные должны описывать факты, которые посетитель может проверить на самой странице. Это не способ собрать максимально большой JSON.

Codex полезен тем, что до выбора типа и написания JSON-LD может проверить страницу, данные контента и существующую разметку. Порядок принципиален. Расплывчатая просьба «добавь всю возможную Schema» нередко приводит к выдуманным aggregateRating, цене, автору или дате публикации. Такой JSON может быть синтаксически корректным и при этом искажать содержание страницы.

Google рекомендует JSON-LD, когда архитектура сайта это позволяет: его обычно проще внедрять и поддерживать. При этом разметка должна описывать именно ту страницу, на которой находится, совпадать с видимым пользователю контентом и оставаться точной. Успешный Rich Results Test не гарантирует расширенный результат.

Сначала выберите основной тип страницы, затем вспомогательные объекты

Начните с простого вопроса: что посетитель в первую очередь видит на этой странице? Ответ определяет основной тип Schema.org. Хлебные крошки, сведения об организации и видео могут дополнять основной объект только тогда, когда описывают видимую информацию на той же странице.

Словарь Schema.org намного шире набора расширенных результатов Google. Для Google Search актуальное руководство Search Central по нужной функции важнее самого факта существования свойства в Schema.org.

Сначала определите назначение страницы. Тип следует из видимых фактов, а не наоборот.

В безопасном процессе Codex есть четыре контрольных этапа

1. Инвентаризация фактов. Берите данные только из видимого текста страницы, надежных полей CMS, которые на ней отображаются, или из явно подтвержденных пользователем сведений. Помечайте каждое поле как подтвержденное, отсутствующее или требующее проверки.
2. Выбор типа. Определите один основной тип, соответствующий главной цели страницы. Если есть альтернатива, объясните ее, а не складывайте все правдоподобные типы в один ответ.
3. Код и сопоставление. Для каждого значения JSON-LD укажите источник. Неизвестные свойства пропускайте, а не заполняйте заглушками.
4. Проверка и выпуск. Проверьте синтаксис JSON, требования конкретной функции, отрисованный DOM, URL Inspection и соответствующий отчет Search Console.

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

Готовый SEO Schema JSON-LD Codex Skill (SKILL.md)

Сохраните этот блок как конфигурацию Skill. В нем нет каталогов компьютера, имен пользователей, токенов, значений переменных окружения или закрытых путей. Он также запрещает Codex выводить чувствительный контекст.

---
name: seo-schema-jsonld
description: Audit visible page facts, recommend accurate Schema.org JSON-LD, implement it safely, and validate it against Google structured-data requirements.
---

# SEO Schema JSON-LD

Use this skill when a user asks to add, repair, review, or validate Schema.org JSON-LD / structured data for a website page, template, CMS entry, or component.

## Primary rule

Treat structured data as a structured representation of the page's user-visible facts. Never use it to invent, hide, exaggerate, or imply information that the page does not support.

## Privacy and output safety

- Never print absolute local paths, home directories, usernames, credentials, tokens, cookies, API keys, environment-variable values, private URLs, or repository-specific secrets.
- Refer to files with short, project-relative labels when needed, such as `src/pages/article.tsx` or `the page template`.
- Do not copy sensitive values into JSON-LD, examples, logs, commit messages, screenshots, or explanations.
- If input contains secrets or private identifiers, omit them and state that sensitive values were excluded.

## Required workflow

### 1. Inspect before generating

Read the relevant page, template, content data, and any existing structured data. Build a fact inventory using only:

- visible page text and user-visible UI;
- trusted CMS fields that are rendered on that page;
- verified product, organization, author, or breadcrumb data supplied by the user.

For every candidate property, label it `confirmed`, `missing`, or `needs human confirmation`. Do not infer missing values from brand names, URLs, conventions, or unrelated pages.

### 2. Choose the narrowest suitable type

Identify the page's primary purpose first. Recommend one primary Schema.org type that truthfully describes it. Add supporting objects only when they also describe user-visible information on the same page.

Explain the recommended primary type, supporting types, why each applies, and types deliberately rejected.

For Google rich-result eligibility, consult the current Google Search Central documentation for the target feature. Schema.org support alone does not establish Google feature support.

### 3. Apply strict data guardrails

Never generate these values unless they are confirmed and visible or otherwise explicitly verified by the user:

- `aggregateRating`, `review`, or review counts;
- price, currency, availability, offer dates, shipping, or return policy;
- author, publisher, logo, address, phone, social profile, or `sameAs`;
- publication dates, modification dates, images, video duration, or interaction counts;
- FAQ questions and answers that are not visibly present;
- event, job, medical, financial, legal, or local-business claims.

Never add misleading `FAQPage`, fake reviews, hidden content, keyword lists, or unrelated types. Prefer fewer complete and accurate properties over many uncertain ones.

### 4. Produce the implementation

Return these sections in order:

1. `Fact inventory` - property, value or status, and visible source.
2. `Schema decision` - primary type, supporting types, assumptions, and exclusions.
3. `JSON-LD` - valid JSON inside one `application/ld+json` script block. Use placeholders only in a clearly labeled illustrative example; never present placeholders as production-ready values.
4. `Implementation note` - the safe insertion point for the site's framework or CMS, without exposing private paths.
5. `Validation checklist` - syntax, rendered-page check, Google Rich Results Test when applicable, Schema Markup Validator, URL Inspection after deployment, and Search Console monitoring.
6. `Open questions` - every field that needs a human decision.

If editing code is requested, make the smallest scoped change. Preserve existing valid markup, avoid duplicate entities, and explain any conflict before replacing it.

## JSON-LD quality checks

Before finalizing, verify all of the following:

- JSON parses and uses `https://schema.org` as `@context`.
- The main type matches the page's main user-visible purpose.
- Every emitted value has a page-level source or explicit user confirmation.
- Required fields for the intended Google feature are present and accurate.
- URLs are canonical, publicly reachable URLs when the property requires a URL.
- Dates use ISO 8601 where required.
- Multiple entities are connected deliberately, not duplicated accidentally.
- The markup remains available to crawlers in the rendered response.
- The result contains no secrets, local paths, private identifiers, or fabricated claims.

## Limitations to state plainly

Valid structured data can help search engines understand a page and make it eligible for certain search appearances. It does not guarantee rich results, rankings, traffic, citations, or inclusion in AI answers.

Используйте Skill с этапом согласования

Не ограничивайтесь фразой «добавь Schema на эту страницу». Передайте Codex страницу и критерии приемки. Начать можно с такого запроса:

Use the SEO Schema JSON-LD skill to review this article page.

Goal: add accurate Article and BreadcrumbList JSON-LD if the visible content supports them.
First return the fact inventory and schema decision. Do not edit code until I approve the decision.
Do not create ratings, reviews, author details, dates, images, or organization fields that are absent from the page.
After approval, make the smallest implementation change and provide the validation checklist.

Для большого шаблона сохраните правило «сначала инвентаризация фактов и решение по типу». Дополнительная короткая проверка не даст ошибочному предположению распространиться на тысячи URL.

Путь от аудита до выпуска за 30 минут

После выпуска проверьте через URL Inspection, что Google получает и разбирает страницу. Затем используйте соответствующий отчет Search Console, чтобы найти массовые сбои шаблона, развертывания или источника данных. Первый инструмент проверяет отдельный URL, второй лучше выявляет системные проблемы.

Каждый этап находит свой класс ошибок. Корректный синтаксис еще не доказывает правильность фактов или развертывания.

Намеренно минимальный пример страницы статьи

Это иллюстрация, а не готовый объект для продакшена. Она показывает форму BlogPosting и BreadcrumbList. Заголовок, описание, URL, автора, дату и изображение берите только из подтвержденных данных страницы. Если факта на странице нет, не добавляйте его ради полноты объекта.

В примере намеренно нет рейтинга, автора, даты публикации, изображения и издателя. Это не декоративные SEO-поля, а утверждения, которым нужен надежный источник.

Пять причин, почему технически валидная разметка все равно ошибочна

Разбор JSON не проверяет правдивость

Валидатор JSON сообщает, разбирается ли синтаксис. Он не знает, есть ли на странице заявленные отзывы, цена или автор и действительно ли Product описывает продукт, а не обычную услугу. Инвентаризация фактов ловит большинство таких ошибок заранее.

Больше объектов не означает лучше

Страница рецепта с видимым видео может обоснованно содержать Recipe, VideoObject и хлебные крошки. Но ее главная цель должна оставаться ясной. Набор из Article, Product, FAQPage и HowTo на обычной контентной странице чаще увеличивает стоимость поддержки и риск несоответствий.

За видимость и актуальность должен отвечать один владелец

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

FAQPage — не универсальное украшение вопросов и ответов

В FAQ-разметку входят только вопросы и ответы, которые действительно видит пользователь. У функций Google могут быть дополнительные условия. Сначала опубликуйте полноценный реальный FAQ, затем проверьте актуальное руководство. Не создавайте вопросы только ради внешнего вида результата.

Schema не обходит сканирование, индексирование и качество страницы

Страница, закрытая через noindex, контроль доступа или правила сканирования, не станет доступной поиску из-за JSON-LD. Schema — один слой технического SEO, а не замена доступности, полезному содержанию и качеству страницы. Для более широкого аудита выберите подходящий процесс в каталоге SEO-инструментов Auspia .

Проверка перед публикацией

• [ ] Основной тип страницы указан и объясняется одним предложением.
• [ ] У каждого значения JSON-LD есть видимый или надежный отображаемый источник.
• [ ] Рейтинги, отзывы, цена, наличие, автор, дата, изображение и сведения об организации не выдуманы.
• [ ] Изменение не дублирует сущности CMS, плагина или другого компонента.
• [ ] JSON разбирается, а разметка присутствует в отрисованном DOM после развертывания.
• [ ] Обязательные свойства функции Google сверены с актуальной официальной документацией.
• [ ] Использованы Rich Results Test, если применим, и Schema Markup Validator.
• [ ] Запланированы URL Inspection и проверка Search Console после выпуска.
• [ ] Команда понимает: валидная разметка дает понятность и право на участие, но не гарантирует результат или позицию.

Частые вопросы

Может ли SKILL.md сам определить нужную Schema?

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

Где размещать JSON-LD: в <head> или <body>?

Google поддерживает JSON-LD и в <head>, и в <body>. Выберите стабильное место, которое фреймворк или CMS синхронизирует с содержанием. Важно, чтобы Google мог просканировать валидную разметку, соответствующую отрисованной странице.

Почему после успешного Rich Results Test ничего не изменилось?

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

Нужно ли просить Codex заполнить все свойства Schema.org?

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

Официальные источники

• Google Search Central: Introduction to structured data markup
• Google Search Central: General structured data guidelines
• Google Rich Results Test
• Schema.org

Автор: Julian Mercer, специалист Auspia с 14-летним опытом технического SEO. Пишет о сканировании, рендеринге, структурированных данных и технических процессах, которые команды могут надежно поддерживать.