GEO-чекліст перед публікацією: автор, дата, Article JSON-LD

Сторінка, яку ШІ не може атрибутувати, — це сторінка, яку ШІ не стане впевнено цитувати. Тому перед публікацією корисне запитання не «яка розмітка проштовхне мене в ШІ-відповіді?» — Google прямо каже, що жодна спеціальна розмітка цього не робить. Корисне запитання в тому, чи узгоджені три шари: те, що бачить читач (справжній автор, зрозуміла дата), те, що ваш JSON-LD повідомляє про ці самі факти, і чи можуть валідатор і краулер підтвердити і те, і інше.

Коли ці шари збігаються, пошукові та ШІ-системи можуть довіряти сторінці й цитувати її коректно. Коли вони розходяться, сторінка читається неоднозначно, а неоднозначні сторінки перефразовують, датують хибно або пропускають. Цей чекліст утримує їх в узгодженні — з чесним застереженням, що жоден пункт не є чарівним перемикачем.

Ключові висновки

• Видимий автор і дата — це шар довіри та прозорості, а не перемикач ранжування. Google вибудовує хороший контент навколо «Хто, Як, Чому» (Google).
• Показуйте помітну дату і відображайте її в datePublished/dateModified; видиме й структуроване значення мають збігатися, без майбутніх дат і дат події (Google).
• У Article/BlogPosting немає обовʼязкових полів, але додайте рекомендовані: author, datePublished, dateModified, headline, image (Google).
• FAQPage rich results зникли з Google Пошуку (7 травня 2026). Залишайте розмітку FAQ лише як чесну семантику для Q&A, який видно користувачу (Google).
• Перевіряйте у два цикли (Schema Markup Validator, потім Rich Results Test) і підтверджуйте робочий URL. aiSiteReady перевіряє все це й оцінює сайт від 0 до 100.

Чому видимий автор і дата важливі для ШІ-пошуку?

Вони важливі як шар довіри та прозорості, а не як важіль ранжування. Власний підхід Google до оцінювання контенту — «Хто, Як, Чому»: хто його створив, як і навіщо. Настанови щодо контенту, створеного за допомогою ШІ, кажуть, що точний підпис автора — це те, на що читачі обґрунтовано очікують (Google). Сам підпис Google не описує як чинник ранжування.

Це розрізнення легко перебільшити в обидва боки. «Автор і дата піднімають вашу сторінку» — надто сильно; «автор і дата марні для SEO» — надто слабко. Search Liaison Google казав, що підписи самі по собі не дають бонусу до ранжування. Але сторінки, які стабільно показують реальне авторство й зрозумілі дати, як правило, мають і решту властивостей корисного, гідного довіри контенту. Підпис автора — симптом доброї публікації, а не чит-код.

Для ШІ-цитування механізм конкретний. Система видобування може атрибутувати лише ту сторінку, у якої реально розпізнає автора й дату. Якщо підпис закопаний у тексті, приклеєний до першого абзацу або відсутній у розмітці, моделі доводиться вгадувати. Вгадану атрибуцію вона подасть із застереженнями або зовсім відкине. Дайте їй однозначні «хто» й «коли» — і сторінку стане безпечно цитувати.

Це стрижень того, що означає готовність до ШІ-агентів: сторінка має бути читабельною для машини, перш ніж бодай якийсь її факт зможе поширитися. Автор і дата — перші два факти, які потрібні цитуванню.

Розберіться з датами: published vs. modified

Настанови Google щодо дат — це інструкція з двох частин: додайте помітну, видиму користувачу дату, потім відобразіть її в структурованих даних через datePublished та/або dateModified у підтипі CreativeWork, наприклад Article чи BlogPosting (Google). Про узгодженість там сказано прямо: видима й структурована дати мають збігатися. Не використовуйте майбутні дати й не ставте дату події, яку описує сторінка, туди, де має бути дата публікації.

Ці два поля не взаємозамінні. datePublished — момент, коли сторінка вперше вийшла в мережу; вважайте його незмінним і ніколи не зсувайте заради косметичної правки. dateModified фіксує останню суттєву зміну: нові дані, виправлене твердження, переписаний розділ. Воно не має рухатися щоразу, коли ви виправляєте одрук. Оновлення дати без реальної зміни — це рівно та «штучна свіжість», від якої застерігає Google.

Для матеріалів, чутливих до часу, пишіть повне значення ISO 8601 зі зсувом, наприклад 2026-06-20T09:30:00-04:00. Це не лишає неоднозначності в тому, коли було «сьогодні». У порядку вихідного коду тримайте підпис автора й дату поза першим абзацом тексту. Коли вони розташовані у власному блоці-шапці, краулер не сприйме їх за текст статті. Якщо ви ведете ще й news-sitemap, синхронізуйте його publication_date з тим самим значенням, щоб сигнали, які ви даєте краулерам, ніколи не суперечили одне одному.

Що покласти у ваш Article JSON-LD?

Почніть із правильного очікування: Article, NewsArticle і BlogPosting підтримуються всі, і Google заявляє, що обовʼязкових властивостей немає. Натомість ви додаєте ті, що застосовні (Google). Це водночас і звільняє, і є пасткою, бо «мінімально валідно» і «реально корисно» — різні планки. Schema лише з @type проходить валідацію чудово й майже нічого не повідомляє машині. Сам формат усталився: JSON-LD — стандартна серіалізація linked data від W3C (W3C). Робота в тому, щоб обрати, які факти включити.

Тому цільтеся вище мінімуму. Рекомендований Google набір для статті — author, datePublished, dateModified, headline і image, і саме ці поля несуть факти, які потрібні цитуванню. Ось чистий BlogPosting з одним автором, який їх покриває:

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://example.com/blog/agent-ready-checklist#article",
  "headline": "An agent-ready publishing checklist",
  "description": "How we verify author, date, and JSON-LD before a post goes live.",
  "url": "https://example.com/blog/agent-ready-checklist",
  "mainEntityOfPage": "https://example.com/blog/agent-ready-checklist",
  "inLanguage": "en-US",
  "image": [
    "https://example.com/images/checklist-16x9.png",
    "https://example.com/images/checklist-1x1.png"
  ],
  "author": {
    "@type": "Person",
    "name": "Dana Okafor",
    "url": "https://example.com/authors/dana-okafor"
  },
  "datePublished": "2026-06-20T09:30:00-04:00",
  "dateModified": "2026-06-20T09:30:00-04:00",
  "publisher": {
    "@type": "Organization",
    "name": "Example Labs",
    "url": "https://example.com/"
  }
}

Один автор чи кілька

Два правила про авторів збивають людей з пантелику. Перше: кожен автор, показаний на сторінці, має бути присутній у розмітці. Якщо їх кілька, кожен — окремий обʼєкт, а не один рядок через кому (Google). Друге: author.name містить лише імʼя: без «Опублікував», без посади, без видавця. Додайте url (або sameAs), щоб людину можна було розпізнати по всьому вебу.

"author": [
  { "@type": "Person", "name": "Dana Okafor", "url": "https://example.com/authors/dana-okafor" },
  { "@type": "Person", "name": "Lev Marchenko", "url": "https://example.com/authors/lev-marchenko" }
]

Поля, яких немає у списку Google

Поля на кшталт publisher, description, url і sameAs валідні за schema.org і їх варто додати для повноти. Просто їх немає в списку властивостей Article у Google, тому ставтеся до них як до семантичного оздоблення, а не як до гарантованого тригера функції. Повну карту того, які типи schema.org брати першими, див. у матеріалі структуровані дані для ШІ-агентів.

Чи варто все ще додавати FAQPage JSON-LD у 2026 році?

Так, але лише як чесну семантику, а не заради функції Google. FAQ rich result зник: документація Google повідомляє, що FAQ rich results перестали показуватися в Пошуку 7 травня 2026 року, а підтримку FAQ прибрано з Rich Results Test у червні 2026 року (Google). Тип FAQPage усе ще існує в schema.org, і валідний досі вручає машинам чистий, структурований Q&A.

Є одне правило без компромісів, яке застарівання не скасовує: запитання й відповіді мають бути видимі користувачам на сторінці. Розмічати Q&A, який бачить лише бот, — це структуровані дані, що вводять в оману, а акордеон припустимий лише тому, що читач може його розкрити. Жодних відповідей тільки в schema.

Коли в матеріалу є справжній FAQ, найчистіша модель лишає статтю головним вузлом, а FAQ виносить в окремий вузол, обʼєднуючи їх в одному @graph:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "BlogPosting",
      "@id": "https://example.com/blog/agent-ready-checklist#article",
      "headline": "An agent-ready publishing checklist",
      "url": "https://example.com/blog/agent-ready-checklist",
      "mainEntityOfPage": "https://example.com/blog/agent-ready-checklist",
      "author": { "@type": "Person", "name": "Dana Okafor", "url": "https://example.com/authors/dana-okafor" },
      "datePublished": "2026-06-20T09:30:00-04:00",
      "dateModified": "2026-06-21T14:05:00-04:00"
    },
    {
      "@type": "FAQPage",
      "@id": "https://example.com/blog/agent-ready-checklist#faq",
      "url": "https://example.com/blog/agent-ready-checklist",
      "mainEntity": [
        {
          "@type": "Question",
          "name": "Is FAQ markup still useful in 2026?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "Yes, as machine-readable structure for a Q&A users can already see. It is not a Google rich result, which no longer shows."
          }
        }
      ]
    }
  ]
}

Ось що можна перевірити просто на цій сторінці. Прокрутіть до FAQ під статтею, потім відкрийте перегляд вихідного коду. Один і той самий список faq у front-matter рендерить видимі запитання й генерує FAQPage JSON-LD. Одне джерело — тому розмітка ніколи не зможе описати відповіді, яких читач не бачить. Шапка сторінки робить той самий трюк із підписом автора й датою «Оновлено», які безпосередньо живлять вузол BlogPosting.

Як перевірити Article і FAQ JSON-LD перед публікацією?

Перевіряйте у два цикли, бо «валідно за schema.org» і «має право на функцію Google» — різні запитання. Використовуйте Schema Markup Validator для коректності словника й Rich Results Test для того, чи може Google справді зібрати Article rich result. Потім, після деплою, підтвердьте робочу сторінку в Search Console.

Два інструменти, дві сліпі зони

У кожного інструмента є сліпа зона, про яку варто знати. Rich Results Test судить лише про підтримувані Google результати, вимагає, щоб сторінка була доступна анонімно, і ігнорує коментарі всередині блоку JSON-LD. Приберіть будь-які // нотатки перед публікацією — вони в будь-якому разі не валідний JSON. Schema Markup Validator — це той, хто перевіряє поля, які Rich Results Test не стане, наприклад FAQPage, publisher і sameAs. Після застарівання FAQ саме цей валідатор — ваш головний тест FAQ, бо перегляду rich result, на який можна було спертися, більше немає.

Що ламає перевірку насамперед

Два режими відмови ламають перевірку ще до запуску будь-якого з інструментів. Якщо сторінка заблокована через robots.txt чи noindex, краулер взагалі не бачить розмітку — тому те, як ви керуєте ШІ-краулерами, важливо й тут. А якщо ваш JSON-LD зʼявляється лише після запуску клієнтського JavaScript, багато ШІ-краулерів, які не рендерять JavaScript, пропускають його повністю. Розміщуйте семантичне ядро і JSON-LD у першому HTML. Search Console закриває цикл після запуску, хоча його звіти вибіркові, а не вичерпні: вони показують лише підтримувані типи, які Google уже знайшов.

Чи є спеціальна «GEO-схема» для ШІ?

Ні, і це найкорисніше, що варто засвоїти. Google прямо каже, що немає додаткових вимог і спеціальної розмітки, щоб зʼявитися в AI Overviews чи AI Mode. Твердження «потрібна окрема ШІ-оптимізація» компанія відносить до міфів і додає, що надмірний фокус на структурованих даних не потрібен (Google). Для Google Пошуку «GEO» і «AEO» — це досі просто дисципліноване SEO.

Тому GEO-чекліст перед публікацією виглядає майже так само, як хороший редакційний: справжній контент, справжній автор, зрозуміла дата, доступна для обходу сторінка і коректна розмітка Article, що віддзеркалює те, що на екрані. Структуровані дані досі виправдовують своє місце. Вони знижують неоднозначність, щоб система видобула ваші канонічні факти, а не реконструювала менш точну версію з тексту. Але це шар ясності, а не чорний хід, і гонитва за екзотичною «ШІ-схемою» — зусилля, витрачені не туди.

Чекліст перед публікацією

Ось робочий список. Він навмисно короткий і починається зі сторінки, а не з розмітки.

• Видимий автор (або всі автори) і щонайменше одна зрозуміла, помітна дата розташовані в шапці сторінки, а не в першому абзаці.
• Видиме імʼя автора точно збігається з author.name, без домішку «Опублікував», посади чи видавця.
• Кілька авторів — це окремі обʼєкти в масиві author, а не один рядок через кому.
• У кожного автора правильний @type (Person чи Organization) і є url або sameAs.
• datePublished і dateModified записані в ISO 8601, краще з часовим поясом, і видима дата їм відповідає.
• datePublished ніколи не переписується заради косметичних правок, і сторінка не освіжається штучно.
• Вузол Article/BlogPosting несе щонайменше headline, author, datePublished і справжній image.
• image — це власне зображення статті, доступне для обходу й індексації, а не логотип сайту.
• Будь-який FAQ, розмічений як FAQPage, справді видно читачу; жодних відповідей тільки в schema.
• Коментарі з JSON-LD прибрані, а сторінка доступна анонімно (без noindex, без блокування).
• Розмітка розташована в першому HTML, а не за клієнтським JavaScript.
• Вона проходить Schema Markup Validator і Rich Results Test, а робочий URL підтверджується в Search Console.

Як aiSiteReady перевіряє весь ваш сайт

Перевірити один шаблон вручну реально; перевіряти кожен шаблон на кожному релізі, охоплюючи і видимий шар, і розмітку під ним — ні. Цю роботу робить aiSiteReady. Він завантажує ваші сторінки так, як це зробив би агент, і звітує про meta й структуровані дані (JSON-LD, Open Graph), HTML без JavaScript, robots.txt, sitemap.xml, правила для ШІ-краулерів і виявлення протоколів. Результат — єдина оцінка від 0 до 100 з блокерами й пріоритизованими виправленнями.

Це стосується перевірок виявлюваності й доступності контенту в оцінці; точні перевірки й ваги описані на сторінці методології. І сканер дотримується того, що проповідує. Стаття, яку ви читаєте, постачається з видимим підписом автора, датованою шапкою і JSON-LD BlogPosting плюс FAQPage, згенерованими з того самого чесного front-matter. Усе це рендериться на сервері, тому краулер, що не запускає JavaScript, усе одно це бачить.

Запустіть безкоштовне сканування, щоб побачити, чи можуть ChatGPT, Claude, Perplexity і Google AI прочитати вашого автора, дату й JSON-LD до того, як ви опублікуєте, — англійською, українською чи російською.

Якщо коротко: не напихайте сторінку розміткою заради «GEO». Побудуйте прозору сторінку, де читач бачить автора й дату, і нехай чесний JSON-LD віддзеркалює цю реальність. Для ШІ-пошуку у 2026 році це краще за будь-яку спробу обіграти функцію структурованих даних, якої більше не існує.

У IMozz 20 років у розробці ПЗ, а останній рік він будує продукти за допомогою LLM. Він розвиває aiSiteReady, сканер лише для читання, який перевіряє, чи може ШІ-агент прочитати сайт. Сканер серверно рендерить власний контент як робочий приклад.