← Oleksii Turovskyi

JSON-LD: як пояснити AI, про що ваша сторінка

· 10 хв читання · Оновлено

In English: How to Help AI Understand Your Content with JSON-LD — read in English

Коли розширення повідомляє, що на сторінці немає валідного JSON-LD з ключовими сутностями (Article, FAQPage, Product), це не косметичний дефект. Це сигнал. Великі мовні моделі й системи на кшталт Google AI Overviews бачать вашу сторінку як мішок незвʼязаних токенів, а не як структурований обʼєкт із чітко позначеним автором, датою публікації, заголовком, ціною чи відповіддю на конкретне питання.

Без розмітки модель здогадується. З розміткою вона знає.

Чому мовні моделі залежать від структурованих даних#

Великі мовні моделі генерують текст за ймовірностями, але коли запит торкається фактів - конкретного автора, дати, ціни, відповіді, - вони спираються на те, що Google називає grounding, тобто закріплення відповіді в джерелі. JSON-LD і стає тим джерелом правди в машиночитному форматі.

Кілька конкретних механізмів, які варто розуміти:

  • AI Overviews і генеративний пошук витягують абзаци й факти зі сторінок. Структурована розмітка суттєво піднімає шанс, що джерелом цитати оберуть ваш контент, а не контент конкурента, який моделі довелося розбирати з «голого» HTML.
  • Schema.org лишається спільним словником. Його розуміють пошуковики, парсери мовних моделей, голосові асистенти й краулери AI-платформ - від ChatGPT до Perplexity.
  • Точність без NLP-екстракції. Без розмітки модель витягує сутності через NLP-аналіз. Працює, але непередбачувано. Через JSON-LD ви віддаєте моделі однозначні поля: ось headline, ось author, ось datePublished. Місця для інтерпретації не лишається.

Важливий нюанс щодо FAQPage. У серпні 2023 року Google звузив FAQ-розширені результати до авторитетних урядових і медичних сайтів, а потім прибрав цю функцію зовсім: станом на 7 травня 2026 року документація FAQPage прямо каже, що розширений результат «більше не показується у видачі Google». Прибирати розмітку Google нікого не просив, і цей сайт її й далі віддає.

Вам трапиться широко цитоване число: сторінки з FAQPage нібито в 3,2 раза частіше потрапляють в AI Overviews. Я шукав його джерело й не знайшов. Число ходить по колу, і власник у нього щоразу інший - то власний індекс SEO-вендора, то «дослідження Princeton чи Moz», то дослідження свіжості, яке використало той самий множник узагалі для іншого. А сусідні статті наводять для тієї самої ідеї 2,3 раза, 28% і 61,7%. Жодна не веде на дані, які можна перевірити. Тож я його не повторюю. Чесна версія така: FAQPage віддає ретриверу пари питання-відповідь, уже розкладені по полях, і це дешево зробити, а скільки воно варте - доказів, яким я довіряю, ніхто не публікував.

Аналогія проста. HTML - це верстка сторінки для людей. JSON-LD - той самий зміст, переписаний у форматі, який не лишає машинам простору для здогадок.

Як виглядає правильна розмітка Article і FAQPage#

Розмітка йде блоком <script type="application/ld+json"> у <head> або ближче до кінця <body>. Можна ставити кілька окремих скриптів, а можна обʼєднати сутності в один @graph. Другий варіант чистіший: він дозволяє звʼязувати обʼєкти через @id.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Article",
      "@id": "https://example.com/posts/json-ld-guide#article",
      "headline": "How to help AI understand your content with JSON-LD",
      "description": "A step-by-step guide on adding structured data for AI Overviews and LLMs.",
      "image": [
        "https://example.com/images/cover-1x1.jpg",
        "https://example.com/images/cover-4x3.jpg",
        "https://example.com/images/cover-16x9.jpg"
      ],
      "datePublished": "2026-05-01T08:00:00+00:00",
      "dateModified": "2026-05-01T08:00:00+00:00",
      "inLanguage": "en-US",
      "author": {
        "@type": "Person",
        "name": "Olena Koval",
        "url": "https://example.com/authors/olena-koval"
      },
      "publisher": {
        "@type": "Organization",
        "name": "Example Media",
        "logo": {
          "@type": "ImageObject",
          "url": "https://example.com/logo.png"
        }
      },
      "mainEntityOfPage": {
        "@type": "WebPage",
        "@id": "https://example.com/posts/json-ld-guide"
      }
    },
    {
      "@type": "FAQPage",
      "@id": "https://example.com/posts/json-ld-guide#faq",
      "mainEntity": [
        {
          "@type": "Question",
          "name": "Does JSON-LD replace Microdata markup?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "Yes. Google recommends JSON-LD as the primary format for structured data. Microdata remains valid, but JSON-LD is easier to maintain — it's decoupled from HTML markup and doesn't break during redesigns."
          }
        },
        {
          "@type": "Question",
          "name": "Will an LLM see my markup if it renders via JavaScript?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "Most modern crawlers do execute JS, but the reliable path is to ship JSON-LD in the initial HTML — via SSR or static generation. That way you avoid render races and guarantee inclusion in AI-platform indexes."
          }
        },
        {
          "@type": "Question",
          "name": "Will I get a FAQ rich snippet in Google search?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "No, unless your site is in an authoritative government or medical category. But FAQPage is still worth adding — AI Overviews, ChatGPT, Perplexity, and Gemini actively pull content from this markup."
          }
        }
      ]
    }
  ]
}
</script>

Кілька принципів, які роблять цей блок справді корисним, а не декоративним:

  • @graph дозволяє покласти кілька сутностей в один скрипт і звʼязати їх через @id. Чистіше, ніж два окремі теги.
  • @id - це не URL сторінки, а унікальний ідентифікатор сутності. Фрагмент після решітки (#article, #faq) робить його стабільним.
  • mainEntityOfPage привʼязує Article до конкретного канонічного URL - того самого, який мають називати <link rel="canonical"> і og:url. Три місця, що стверджують одне й те саме про канонічний URL, - нормально; три місця, що сперечаються між собою, - це і є спосіб розмазати потенціал цитування по варіантах однієї сторінки.
  • image масивом із трьох співвідношень сторін (1:1, 4:3, 16:9) - пряма вимога Google для отримання розширених результатів Article.
  • inLanguage допомагає платформам зрозуміти мову контенту й коректно цитувати його в мовно-специфічних запитах.

Реалізація в Next.js (App Router)#

Робочий приклад сторінки для Next.js 16 з Tailwind CSS. Ключове технічне рішення тут - JSON.stringify замість шаблонного рядка, щоб безпечно екранувати дані.

app/posts/[slug]/page.tsx
import type { Metadata } from "next";
 
interface PageProps {
  params: Promise<{ slug: string }>;
}
 
export async function generateMetadata({ params }: PageProps): Promise<Metadata> {
  const { slug } = await params;
  return {
    title: `Article ${slug}`,
    alternates: { canonical: `https://example.com/posts/${slug}` },
  };
}
 
export default async function PostPage({ params }: PageProps) {
  const { slug } = await params;
  const canonicalUrl = `https://example.com/posts/${slug}`;
 
  const jsonLd = {
    "@context": "https://schema.org",
    "@graph": [
      {
        "@type": "Article",
        "@id": `${canonicalUrl}#article`,
        "headline": "How to help AI understand your content with JSON-LD",
        "description":
          "A step-by-step guide on adding structured data for AI Overviews and LLMs.",
        "image": [
          "https://example.com/images/cover-1x1.jpg",
          "https://example.com/images/cover-4x3.jpg",
          "https://example.com/images/cover-16x9.jpg",
        ],
        "datePublished": "2026-05-01T08:00:00+00:00",
        "dateModified": "2026-05-01T08:00:00+00:00",
        "inLanguage": "en-US",
        "author": {
          "@type": "Person",
          "name": "Olena Koval",
          "url": "https://example.com/authors/olena-koval",
        },
        "publisher": {
          "@type": "Organization",
          "name": "Example Media",
          "logo": {
            "@type": "ImageObject",
            "url": "https://example.com/logo.png",
          },
        },
        "mainEntityOfPage": {
          "@type": "WebPage",
          "@id": canonicalUrl,
        },
      },
      {
        "@type": "FAQPage",
        "@id": `${canonicalUrl}#faq`,
        "mainEntity": [
          {
            "@type": "Question",
            "name": "Does JSON-LD replace Microdata markup?",
            "acceptedAnswer": {
              "@type": "Answer",
              "text": "Yes — Google recommends JSON-LD as the primary format. Microdata is still valid, but JSON-LD is easier to maintain because it's decoupled from HTML.",
            },
          },
          {
            "@type": "Question",
            "name": "Will an LLM see my markup if it renders via JavaScript?",
            "acceptedAnswer": {
              "@type": "Answer",
              "text": "The reliable path is to ship JSON-LD in the initial HTML — via SSR or static generation.",
            },
          },
        ],
      },
    ],
  };
 
  return (
    <>
      <script
        type="application/ld+json"
        dangerouslySetInnerHTML={{ __html: JSON.stringify(jsonLd) }}
      />
      <article className="max-w-3xl mx-auto py-10 px-4 sm:px-6 lg:px-8">
        <header className="mb-8">
          <h1 className="text-3xl font-bold tracking-tight text-gray-900">
            How to help AI understand your content with JSON-LD
          </h1>
          <div className="mt-2 text-sm text-gray-500">
            <time dateTime="2026-05-01T08:00:00+00:00">May 1, 2026</time>
          </div>
        </header>
        <div className="prose prose-blue lg:prose-lg">
          <p>
            Correct data structure is foundational for effective interaction
            with AI algorithms. Without it, crawlers fall back on basic NLP
            text analysis.
          </p>
          <h2>Adding the markup</h2>
          <p>
            Using a built-in script of type <code>application/ld+json</code>{" "}
            guarantees that search systems can identify entities on your page
            without ambiguity.
          </p>
        </div>
      </article>
    </>
  );
}

Як перевірити розмітку без зайвих інструментів#

Щоб переконатися, що розмітка валідна, не потрібні ні локальний CLI, ні SaaS. Досить трьох офіційних кроків.

Крок 1. DevTools браузера - миттєва перевірка наявності#

Відкрийте сторінку й виконайте цей сніпет у консолі:

browser-devtools-jsonld-check.js
const blocks = document.querySelectorAll('script[type="application/ld+json"]');
console.log(`JSON-LD blocks found: ${blocks.length}`);
 
blocks.forEach((block, i) => {
  try {
    const parsed = JSON.parse(block.textContent);
    console.group(`Block #${i + 1}`);
    console.log(parsed);
 
    if (parsed["@graph"]) {
      const types = parsed["@graph"].map((item) => item["@type"]);
      console.log("Entity types in @graph:", types);
    } else if (parsed["@type"]) {
      console.log("Entity type:", parsed["@type"]);
    }
 
    console.groupEnd();
  } catch (err) {
    console.error(`Block #${i + 1} contains invalid JSON:`, err.message);
  }
});

Сніпет одразу показує: скільки блоків, чи кожен парситься, які сутності містить. Якщо лічильник показує нуль - розширення мало рацію, розмітки немає. Якщо JSON.parse кидає помилку, у вас поламаний синтаксис, і жоден валідатор далі по ланцюжку не допоможе, доки ви його не полагодите.

Крок 2. Schema Markup Validator - синтаксис і словник#

Ідіть на validator.schema.org. Це інструмент самої спільноти schema.org. Він перевіряє синтаксис JSON-LD проти словника, показує кожну знайдену сутність, поля й невідомі властивості. Базова перевірка, не привʼязана до конкретного пошуковика.

Крок 3. Rich Results Test - погляд очима Google#

Заходьте на search.google.com/test/rich-results. Інструмент Google рендерить вашу сторінку як Googlebot, виконує JavaScript і показує, на які розширені результати ваш контент потенційно претендує. Саме тут ловляться проблеми, які Schema Validator пропускає: відсутні обовʼязкові поля для конкретного типу (наприклад, немає image в Article) або помилки після JS-рендеру.

Порядок і чому він важливий:

  1. Сніпет у DevTools - переконатися, що блоки взагалі доїжджають до відрендереної сторінки.
  2. Schema Markup Validator - перевірити синтаксис і відповідність словнику.
  3. Rich Results Test - перевірити, що бачить Google після рендеру.

Зелено на всіх трьох - і ваш контент готовий до того, щоб AI Overviews, ChatGPT, Perplexity і класичний пошук Google прочитали його точно, а не переказали приблизно.

Який синтаксис структурованих даних обрати#

Усі три валідні для парсера. Приємний у супроводі лише один.

JSON-LD Microdata RDFa
Де живе Один <script> у <head> Атрибути в розмітці Атрибути в розмітці
Переживає редизайн Так, бо відвʼязаний від DOM Ні, ламається разом із шаблоном Ні
Рекомендація Google Пріоритетний Підтримується Підтримується
Генерація на сервері Тривіально Звʼязано з компонентами Звʼязано з компонентами
Читається в одному місці Так Розкидано Розкидано

Колонка про супровід і є весь аргумент. Microdata розʼїжджається з першим же переставлянням розмітки, коли itemprop опиняється поза своїм itemscope: на рев'ю зміна виглядає суто візуальною і тихо прибирає сутність.

FAQ#

Чому структуровані дані важливіші для AI, ніж для пошуку#

Пошуковик може ранжувати сторінку, яку зрозумів наполовину, бо далі клікне людина й прочитає сама. Модель мусить переказати сторінку у власній відповіді, тож неоднозначність стає не трохи гіршою позицією, а хибною цитатою. JSON-LD прибирає здогадки: хто написав, коли, і що це взагалі за річ.

Чи потрібні Article і FAQPage на одній сторінці разом#

Так, коли сторінка - це стаття зі справжньою секцією питань і відповідей. Кладіть обидві в один @graph, а не двома конкурентними скриптами. Article описує документ, FAQPage описує пари питання-відповідь усередині нього. Це різні твердження про один URL.

Що буде, якщо розмітка й видима сторінка розходяться#

Google трактує це як оманливі структуровані дані, а це категорія ручних санкцій, а не мʼякий сигнал ранжування. Це ж і найпоширеніший спосіб нарватися на проблеми з FAQPage, бо відповіді зазвичай набирають двічі - раз у тілі, раз у схемі, - і копії розходяться. Генеруйте розмітку з видимого тексту, а не поряд із ним.

Як переконатися, що мій JSON-LD справді валідний#

Три проходи, від найдешевшого: DevTools - щоб переконатися, що скрипт узагалі є у відданому HTML; Schema Markup Validator - на помилки словника; Rich Results Test - на те, що саме Google візьме до уваги. Розширення AEO Checker робить перший прохід на будь-якій відкритій сторінці, зокрема на тих, що за логіном.

Джерела#

Частина кластера Answer Engine Optimization - повний порядок читання і глосарій усіх термінів, що трапляються в цих статтях.

Ваш сайт досі втрачає AI-трафік через невидимий контент?

Підписуйтесь у LinkedIn, щоб стежити за новими стандартами AEO-архітектури. Якщо шукаєте досвідченого архітектора для аудиту платформи, глибокого впровадження схем або оптимізації headless-архітектури - напишіть.

Показати як Markdown

Нові статті на пошту

Одна стаття раз на два тижні - про AI-пошук і код за ним. Підтвердження листом, відписка в один клік.