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, сканер только для чтения, который проверяет, может ли ИИ-агент прочитать сайт. Сканер серверно рендерит собственный контент как рабочий пример.