Структуровані дані JSON-LD: що потрібно звичайному сайту

Структуровані дані описують вміст сторінки за спільним словником schema.org. Замість того щоб вгадувати з верстки, що «Іван Петренко» є автором, а «24 жовтня 2026» — дата публікації, пошукова система читає ці факти з окремого блоку і порівнює їх з видимим текстом.

На практиці розмітка дає три речі:

• однозначність: сутності сторінки (організація, стаття, навігація) названі прямо, а не виведені з контексту;
• сумісність із можливими розширеними результатами: якщо сторінка відповідає вимогам, пошукова система може показати більше, ніж синє посилання;
• внутрішню узгодженість: коли всі сторінки описують автора, видавця і дати однаково, сайт простіше підтримувати і перевіряти.

Чого розмітка не робить: не піднімає сторінку у видачі сама по собі, не виправляє слабкий контент і не замінює базові технічні перевірки, як-от доступність для сканування й коректний canonical. Право на розширений результат визначає Google, і воно ніколи не гарантоване, навіть коли код ідеальний. Загальний огляд є в документації Google про структуровані дані.

Структуровані дані можна записати у трьох форматах: JSON-LD, мікродані (microdata) і RDFa. Google рекомендує JSON-LD, і причина проста. Мікродані вплітаються в HTML-теги, тому кожна зміна верстки може зламати розмітку. JSON-LD лежить окремим блоком і не залежить від структури сторінки.

Блок виглядає так:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebPage",
  "name": "Example page",
  "url": "https://example.com/page"
}
</script>

Його можна розмістити у head або в body, обидва варіанти працюють. Кілька правил, які варто запам'ятати:

• @context завжди дорівнює https://schema.org;
• @type називає тип сутності: Organization, BlogPosting, BreadcrumbList;
• усі адреси абсолютні, з https:// і доменом;
• це має бути чинний JSON: прямі лапки, жодних коми в кінці списку, жодних коментарів;
• сторінка може мати кілька блоків або один блок із масивом @graph.

Скрипт із типом application/ld+json браузер не виконує, це лише дані. Тому такі блоки зазвичай не потребують окремого дозволу в політиці безпеки контенту. Про цю політику докладніше в статті про заголовки безпеки та SEO.

Словник schema.org величезний, але сайту компанії, блогу чи невеликого сервісу майже ніколи не потрібні сотні типів. Розумний мінімум такий:

Решта типів потрібна лише тоді, коли сторінка справді така. Product потрібен сторінці конкретного товару, LocalBusiness бізнесу з фізичною адресою, SoftwareApplication застосунку, VideoObject сторінці з відео. Додавати їх «про запас» на сторінки іншого змісту не можна: політика Google вимагає, щоб розмітка відповідала тому, що бачить користувач.

Те саме стосується відгуків і рейтингів. Вигадані або власноруч написані «відгуки про себе» порушують правила, і за них можна втратити право на розширені результати. Якщо справжніх відгуків на сторінці немає, розмітки відгуків чи рейтингу теж немає. Повні вимоги зібрано в правилах Google щодо структурованих даних.

На головній сторінці зручно описати організацію й сайт одним блоком @graph. Вузли отримують ідентифікатори @id, і інші сторінки посилаються на них, а не копіюють дані.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example Studio",
      "url": "https://example.com/",
      "logo": "https://example.com/images/logo-512.png",
      "sameAs": ["https://www.linkedin.com/company/example"]
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com/",
      "name": "Example Studio",
      "inLanguage": "uk",
      "publisher": { "@id": "https://example.com/#organization" }
    }
  ]
}

Поле sameAs має вести тільки на реальні профілі, які належать вам. Якщо їх немає, поле просто пропускають. Логотип має бути доступним за вказаною адресою, а його файл достатньо великим і чітким. Вимоги до логотипа описані в документації Google про Organization.

Для багатомовного сайту inLanguage відповідає мові сторінки, на якій розміщено блок. Про те, як пов'язати мовні версії між собою, читайте в посібнику з hreflang.

Стаття блогу описується типом BlogPosting (підтип Article). Мінімальний набір полів: заголовок, дати, автор, видавець і зображення. Дати записують у форматі ISO 8601, наприклад 2026-10-24.

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://example.com/blog/robots-txt-guide#article",
  "headline": "How to write a robots.txt file",
  "description": "A practical guide to robots.txt rules and common mistakes.",
  "datePublished": "2026-10-24",
  "dateModified": "2026-10-24",
  "inLanguage": "en",
  "author": {
    "@type": "Organization",
    "name": "Example Studio",
    "url": "https://example.com/"
  },
  "publisher": { "@id": "https://example.com/#organization" },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/blog/robots-txt-guide"
  },
  "image": "https://example.com/images/robots-txt-cover.png"
}

Дата dateModified змінюється лише тоді, коли ви справді оновили зміст, а не при кожній зміні шаблону. Усі поля Article пояснено в документації Google про статті.

Для навігації додайте BreadcrumbList. Кожен елемент має позицію, назву й адресу, а останній елемент відповідає поточній сторінці.

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://example.com/" },
    { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://example.com/blog" },
    { "@type": "ListItem", "position": 3, "name": "robots.txt guide", "item": "https://example.com/blog/robots-txt-guide" }
  ]
}

Ланцюжок у розмітці має збігатися з тим, що користувач бачить у хлібних крихтах на сторінці. Докладніше про цю розмітку в документації про breadcrumb.

На цьому сайті кожна стаття несе BlogPosting і BreadcrumbList у JSON-LD.

FAQPage описує сторінку, на якій є запитання з відповідями. Головна умова: ці запитання і відповіді видно на сторінці, а відповіді в розмітці збігаються з видимим текстом. Розмітка прихованого або іншого тексту порушує правила.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Does JSON-LD improve rankings?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Not by itself. It helps search engines interpret the page, and eligibility for rich results is decided by Google."
      }
    },
    {
      "@type": "Question",
      "name": "Where do I place the JSON-LD block?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "In the head or the body of the page, as a script block of type application/ld+json."
      }
    }
  ]
}

Чесно про очікування. Від серпня 2023 року Google показує розширені результати з запитаннями лише для відомих урядових та медичних сайтів. Для звичайного сайту розмітка залишається чинною і нешкідливою, але розгорнутого сніпета, найімовірніше, не буде. Тому писати FAQ варто для читача, а розмітку розглядати як бонус: вона зберігає узгодженість із видимим вмістом і не заважає. Правила описано в документації про FAQPage.

На цьому сайті FAQ внизу кожної статті видно на сторінці, і той самий FAQ позначено в JSON-LD як FAQPage.

Більшість проблем із JSON-LD нудні й повторюються. Ось ті, що трапляються найчастіше:

• розмітка не парситься як JSON: зайва кома, типографські лапки замість прямих, незакритий блок;
• відсутній @context, і валідатор не знає, який словник використано;
• відносні адреси замість абсолютних;
• розмітка описує те, чого немає на сторінці: ціну без товару, автора, якого не показано, відгуки, написані власником;
• дублювання: шаблон додає Organization у кожен блок, а плагін ще раз;
• застарілі значення: дата, яка не змінюється після редагування, або старий логотип.

Дивіться, як виглядає зламаний блок і його виправлена версія:

{
  "@type": "Organization",
  "name": "Example Studio",
  "url": "/",
  "logo": "/images/logo.png",
}

Тут три помилки: немає @context, адреси відносні, а кома після останнього поля робить JSON недійсним. Виправлений варіант:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Example Studio",
  "url": "https://example.com/",
  "logo": "https://example.com/images/logo-512.png"
}

Якщо розмітку генерує CMS чи плагін, перевіряйте не налаштування, а результат у вихідному коді сторінки.

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

1. Вихідний код сторінки (view-source) показує, що справді віддає сервер, без роботи скриптів. Знайдіть application/ld+json і переконайтеся, що блок є.
2. Schema Markup Validator (validator.schema.org) перевіряє розмітку на відповідність словнику schema.org.
3. Rich Results Test від Google показує, які розширені результати розмітка може підтримувати і чи немає критичних помилок.
4. Звіти про вдосконалення в Google Search Console збирають помилки й попередження по всьому сайту після того, як сторінки проскановано.

Безкоштовний сканер SEOAudit працює пасивно: він читає вказану адресу та кілька публічних ресурсів. У частині структурованих даних він повідомляє, чи є JSON-LD, чи розбираються блоки як JSON, чи вказано @context, які значення @type оголошено, і дає детерміновані підказки щодо рекомендованих полів для поширених типів. Він розбирає до десяти блоків розміром до 200 КБ кожен. Сканер не перевіряє відповідність schema.org по суті й не стверджує, що сторінка отримає розширений результат, для цього є Rich Results Test.

Розмітка це лише одна з частин технічного SEO-аудиту. Поруч стоять доступність для сканування, canonical і безпека. Для останньої є окрема перевірка безпеки. А якщо цікавить, як сайт читають ШІ-помічники, дивіться сторінку про видимість у ШІ-пошуку.