Більшість команд клеять FAQPage скрізь — і більшість роблять це неправильно

Ось патерн, який ми бачимо на дев’яти з десяти аудитів. Команда додала FAQ-блок до блог-посту, поставила @type: FAQPage, провалідувала у Google Rich Results Test, поставила галочку, пішла далі. У 2020 році це був прийнятний хід. У 2026 — це витік цитувань.

LLM-екстрактори стали перебірливі. ChatGPT, Perplexity і Gemini мають свої переваги щодо того, як має бути структурований Q&A-блок. І неправильний wrapper schema відправляє сторінку у відро “summarise, don’t cite”. Сторінка має відповідь. AI цитує конкурента.

Важать три патерни — FAQPage, QAPage і Article-with-FAQ-section. У кожного свій правильний use case. Нижче — що це реально таке, коли деплоїти, і JSON-LD, який екстрагується чисто.

FAQPage — що це і де його місце

FAQPage — це page-level тип, який каже “ця сторінка є кураторським FAQ”. Масив mainEntity — це список Question-обʼєктів, кожен з одним acceptedAnswer. Тут немає поняття конкуруючих відповідей, голосування або community-внеску. Це editorial Q&A, авторство сайту.

Правильний дім для FAQPage — service-сторінка, product-сторінка, pricing-сторінка, help-центр стаття. Десь, де є пʼять-десять стабільних питань, які команда курувала і за якими стоїть. Сторінка існує, щоб відповісти на ці питання. FAQ — це основний контент сторінки, не доповнення.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "@id": "https://answerly.agency/services/aeo-starter-audit#faq",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "How fast do we see results from an AEO audit?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "First citation lift typically appears 14–60 days after deploying the punch-list. Full effect lands by month 3."
      }
    },
    {
      "@type": "Question",
      "name": "Does the audit include implementation?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "No. Starter is audit-only — your team or another agency ships the punch-list. Growth and Scale include implementation."
      }
    }
  ]
}

Це чистий FAQPage. Один acceptedAnswer на Question. Жодного AnswerCount, upvoteCount, suggestedAnswer. Це поля для QAPage.

Зауваження про Google rich-result. Google відмінив FAQ rich result для більшості сайтів у серпні 2023 — тільки well-known авторитетні health- і government-домени все ще його отримують. Тому якщо твоя причина використовувати FAQPage була “щоб отримати rich snippet” — цієї причини більше немає. Причина використовувати його зараз — це LLM extraction, і у цієї цілі інші правила.

QAPage — що це і де його місце

QAPage моделює іншу форму. Один користувач запитав одне питання. Сторінка збирає accepted answer плюс нуль або більше suggested answers. Голосування, AnswerCount, dateCreated на кожній відповіді — все це має сенс, бо сторінка є forum thread, не editorial copy.

Якщо ти колись дивився на JSON-LD під питанням Stack Overflow — ти бачив QAPage у дикій природі. Це канонічний use case. Reddit, Quora, community forums, support-борди, де користувачі постять питання, а інші користувачі (або CX-команда бренду) постять відповіді.

{
  "@context": "https://schema.org",
  "@type": "QAPage",
  "mainEntity": {
    "@type": "Question",
    "name": "How do I migrate FAQPage schema from a WordPress site to Astro without losing citations?",
    "text": "I have 40 service pages on WP with FAQPage schema embedded by Yoast. Moving to Astro. Need the migration to not tank the citation lift we got over the last 6 months. What's the safest path?",
    "answerCount": 3,
    "upvoteCount": 12,
    "dateCreated": "2026-05-01T09:14:00Z",
    "author": { "@type": "Person", "name": "Asker Username" },
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "Generate the FAQPage JSON-LD at build time from the same markdown frontmatter Yoast was reading. Keep the @id stable across the migration. Validate every URL in Schema Markup Validator before flipping DNS.",
      "upvoteCount": 8,
      "dateCreated": "2026-05-01T11:42:00Z",
      "author": { "@type": "Person", "name": "Responder Username" }
    },
    "suggestedAnswer": [
      {
        "@type": "Answer",
        "text": "I'd also recommend running a 301 map and re-submitting the sitemap to Bing/IndexNow on cutover day.",
        "upvoteCount": 3,
        "author": { "@type": "Person", "name": "Other Responder" }
      }
    ]
  }
}

Це QAPage. Одне Question, обгорнуте у mainEntity. AnswerCount, upvoteCount, dateCreated, кілька Answer-обʼєктів — повний набір.

Якщо твій блог-пост не є forum thread — це не твоя schema. Не використовуй QAPage для editorial Q&A, як би принадно “QA” не звучало у назві типу.

Третій варіант — Article з FAQ-розділом

Ось патерн, який реально треба використовувати на більшості блог-постів. Сторінка є статтею. Article — це wrapper schema. FAQ внизу — це supplementary контент: корисний, цитований, але не primary entity сторінки.

У цьому випадку FAQPage на page-level — неправильно (сторінка не є кураторським FAQ, вона є статтею, що випадково закінчується FAQ). QAPage — неправильно (сторінка не є community thread). Чиста відповідь — лишити Article як page-level тип і вмонтувати Question-обʼєкти всередину Article через hasPart або як окремий @graph-вузол.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Article",
      "@id": "https://answerly.agency/blog/faqpage-vs-qapage-schema#article",
      "headline": "FAQPage vs QAPage: which schema AI citers actually trust",
      "datePublished": "2026-05-08",
      "dateModified": "2026-05-08",
      "author": { "@type": "Person", "name": "Dmytro Popryadukhin" },
      "publisher": {
        "@type": "Organization",
        "name": "Answerly Agency",
        "url": "https://answerly.agency"
      },
      "mainEntityOfPage": {
        "@type": "WebPage",
        "@id": "https://answerly.agency/blog/faqpage-vs-qapage-schema"
      }
    },
    {
      "@type": "FAQPage",
      "@id": "https://answerly.agency/blog/faqpage-vs-qapage-schema#faq",
      "mainEntity": [
        {
          "@type": "Question",
          "name": "Can a single page emit both Article and FAQPage schema?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "Yes — use a @graph with two top-level nodes and distinct @id values. The Article describes the page; the FAQPage describes the FAQ section."
          }
        }
      ]
    }
  ]
}

Два вузли, обидва top-level, з різними @id, в одному wrapper-обʼєкті. Article робить сторінку eligible до Article-style цитування. Вмонтований FAQPage дає LLM чистий Q&A-блок для екстракції. Best of both — і саме це ми відвантажуємо на кожному блог-пості у цій колекції.

Як кожен LLM citer парсить ці патерни

Три великих LLM-side citer-и поводяться по-різному. Те, що ми міряємо у власному tracker, і те, що ми чуємо від команд з власними prompt-панелями — узгоджено настільки, щоб бути операційним керівництвом.

ChatGPT екстрагує FAQPage чисто, коли він є primary entity на service- або product-сторінці. На блог-постах ChatGPT трохи більше любить патерн Article з вмонтованим FAQPage у @graph. Спочатку він підхоплює контекст статті, потім цитує Q&A. Single-Q&A QAPage рідко зʼявляється у цитуваннях ChatGPT, якщо тільки сторінка не з визнаного forum-домену.

Perplexity історично over-cites Q&A-патерни. Тобто він сильно лежить на FAQPage, навіть коли Article-wrapper був би доречнішим. Це ок, якщо ти хочеш Perplexity-обсяг. Але не дивуйся, коли він цитує тільки FAQ-рядки і ігнорує решту сторінки. І Perplexity — це той citer, який зрідка показує QAPage-формат сторінки з не-forum-доменів. Тому тип все ще має маленьку операційну роль навіть поза Stack Overflow і Reddit.

Gemini любить структурований Article + FAQ section. @graph з двома top-level вузлами — це те, що екстрагується найчистіше у нашому tracker. Gemini читає Article-контекст, валідує його проти entity graph, потім цитує з FAQ-блоку. Сторінка з FAQPage у root і без Article-wrapper іноді парситься як “ця сторінка є списком FAQ”, і article body отримує менше ваги.

Це спрощення. Твоя панель може відрізнятися, і поведінка зміщується, бо моделі ітерують. Але правило працює — якщо сторінка editorially є статтею, обгортай її як Article і вмонтовуй FAQ як вузол, не як root.

Типові помилки, які ми бачимо на аудитах

FAQPage на тонкій сторінці. Три Q&A-пари по 12 слів кожна. Сторінка без body, без Quick Facts, без автора. LLM читає її як low-density контент і пропускає. Підлога — пʼять Q&A зі змістовною глибиною. І сама сторінка має бути більше, ніж FAQ.

Неправильний @id або відсутність @id взагалі. Кожен JSON-LD-вузол має мати стабільний @id. Без нього LLM (і Google) не може зрозуміти, чи описують два schema-блоки одну сутність, чи дві різні. І логіка дедуплікації стає непередбачуваною.

mainEntity vs about — плутанина. mainEntity — це “сторінка принципово про цю штуку, і ця штука є контентом сторінки”. about — це “сторінка згадує цю штуку”. На FAQPage mainEntity — це масив Questions, не about. На Article mainEntity зазвичай є саме статтею. FAQ-блок живе під окремим вузлом, не під Article.mainEntity.

AnswerCount на FAQPage. Це той самий tell-tale. AnswerCount живе на Question у QAPage (бо у QAPage Question дійсно має кілька відповідей — accepted плюс suggested). На FAQPage — рівно один acceptedAnswer на Question. AnswerCount тут безглуздий. Якщо ти бачиш його у себе на видачі — твій schema-генератор зламаний.

Кілька acceptedAnswer на одному Question. Та сама проблема з іншого боку. Кожен Question отримує рівно один acceptedAnswer. Якщо у тебе кілька “accepted” відповідей — тобі потрібен QAPage з suggestedAnswer для решти.

Прихований FAQ-контент. Q&A у твоєму JSON-LD має збігатися з тим, що видно на сторінці. Schema-only FAQ, які не зʼявляються у відрендереному HTML — це порушення Google guideline і LLM-trust сигнал, який ти не хочеш викидати.

Валідація — schema, rich result і LLM-check

Три гейти перед деплоєм.

Schema Markup Validator (validator.schema.org). Це структурна перевірка — чи парситься JSON-LD, чи резолвляться типи, чи присутні обовʼязкові поля. Запускай на кожній сторінці перед merge.

Google Rich Results Test. Корисний менше, ніж раніше (FAQ rich result у більшості відмінений), але все ще ловить malformed-типи і показує те, що реально бачить Google-parser. Warnings трактуй як блокери деплою.

LLM-check. Встав свій URL у ChatGPT і попроси резюмувати FAQ на сторінці. Потім — у Perplexity. Потім — Gemini. Якщо хтось з них не може чисто екстрагувати Q&A — неправильний wrapper, відсутній контекст, неоднозначний entity graph — у тебе реальна проблема, яку валідатори не зловили. Це тест, який важить найбільше для citation-цілі. І саме його команди пропускають.

Підсумок 2026

FAQPage став дефолтним “я додав schema” ходом десь з 2018 року. У 2026 це також дефолтний “я додав schema неправильно” хід. Формат, який тобі потрібен, залежить від того, чим сторінка реально Є — service-сторінка зі сталим кураторським Q&A, community thread з одним питанням і багатьма відповідями, або стаття, що випадково закінчується FAQ. Три різні форми, три різні схеми.

Обери ту, яка відповідає сторінці. Провалідуй. Протестуй на трьох великих LLM citer-ах. І відвантажуй.

Якщо хочеш зробити це по всьому сайту одразу — Growth engagement розгортає schema правильно на кожній пріоритетній сторінці, з @graph-патерном, вшитим у твою CMS, щоб редактори не могли його зламати.