Я предлагаю начинать техническое задание на статью с трёх вопросов: кому мы помогаем, какое решение должен принять читатель и на каких доказательствах будет построен ответ. Ключевые запросы, заголовки и объём я добавляю после этого.
ТЗ на статью для SEO и AI-поиска — это документ, который связывает задачу аудитории, вопросы читателей, структуру ответов, доказательства и критерии проверки материала.
В таком задании автору должно быть понятно, что написать, какие сведения проверить и какие материалы запросить у заказчика.
Ниже я разберу подход к составлению такого задания и дам готовый шаблон. Редакционные правила в нём — мои рекомендации по организации работы. Требования поисковой системы я отмечаю отдельно.
Что действительно требуется для AI-поиска
Сначала я уточняю, для каких площадок готовится материал. Формулировка «продвинуть статью в нейросетях» слишком широкая для технического задания.
Например, Google прямо сообщает, что для появления в AI Overviews и AI Mode не нужны специальные SEO-приёмы или дополнительные требования сверх базовых. Чтобы страница могла использоваться как источник со ссылкой, она должна быть проиндексирована и допускать показ поискового фрагмента. Соответствие требованиям при этом не гарантирует показ.
Из этого я делаю практический вывод: в ТЗ стоит работать над полезностью и проверяемостью ответа, а не обещать автору секретную формулу цитирования.
Вопросы в подзаголовках, понятные определения и таблицы я предлагаю как редакционные инструменты. Я не могу подтвердить, что определённая длина абзаца или обязательный FAQ гарантируют цитирование в AI-поиске. Рекомендации Google также нельзя автоматически объявлять правилами всех остальных систем.
1. Определяю читателя и результат статьи
Вместо описания «целевая аудитория — предприниматели» я предлагаю зафиксировать конкретную ситуацию:
Владелец небольшой компании выбирает CRM. Он хочет разобраться в критериях выбора, подготовить вопросы поставщикам и понять, как проверить систему до оплаты.
Это учебный пример постановки задачи. В реальном проекте такое описание нужно подтвердить интервью, обращениями клиентов или другими доступными данными.
Для ТЗ я заполняю следующие поля:
| Поле | Что нужно записать |
|---|---|
| Кто читатель | Должность, роль, уровень подготовки |
| В какой ситуации он читает | Что произошло и почему возник вопрос |
| Что он уже знает | Какие объяснения можно сократить |
| Чего он опасается | Ошибки, расходы, ограничения, неопределённость |
| Что должен получить | Решение, расчёт, инструкцию, критерии выбора |
| Следующее действие | Скачать шаблон, проверить условия, запросить консультацию |
Отдельно я формулирую границы темы. Например «Помочь составить список требований к CRM; не делать рейтинг всех систем и не описывать техническое внедрение».
Так я задаю автору область работы и критерий завершённости материала.
2. Превращаю семантику в вопросы аудитории
Список запросов я предлагаю использовать вместе с картой вопросов. Для каждого вопроса нужно указать, откуда он появился.
В качестве исходных материалов я запрашиваю:
- поисковые запросы из доступных отчётов сайта;
- обезличенные обращения в продажи и поддержку;
- записи интервью с клиентами;
- комментарии и обсуждения по теме;
- результаты изучения выдачи с указанием даты и региона.
При этом я разделяю наблюдения и гипотезы. Вопрос из переписки клиента — наблюдение. Вопрос, придуманный редактором или предложенный нейросетью, — гипотеза для проверки. Без подтверждения я не называю его популярным или частотным.
Моя рабочая таблица выглядит так:
| Вопрос читателя | Откуда он взят | Что должен дать ответ | Чем подтвердить |
|---|---|---|---|
| С чего начать выбор CRM? | Указать обращение или исследование; иначе отметить гипотезой | Порядок подготовки требований | Согласованный процесс компании, комментарий специалиста |
| Как сравнить стоимость? | Указать источник вопроса | Состав расходов и условия сравнения | Официальные тарифы, предложения поставщиков |
| Как проверить интеграцию? | Указать источник вопроса | Сценарий проверки нужной операции | Документация конкретной интеграции, результат теста |
| Что сделать перед оплатой? | Указать источник вопроса | Проверочный список | Условия поставщика и требования заказчика |
Вопросы я группирую по задаче: понять, сравнить, выполнить, проверить, избежать ошибки. После этого определяю, какие из них обязательны для статьи, какие можно раскрыть кратко, а какие относятся к отдельному материалу.
Для каждого обязательного вопроса я хочу видеть ожидаемый результат ответа. Формулировка «рассказать об интеграциях» меня не устраивает. «Объяснить, как проверить передачу заявки из формы сайта в CRM» — уже конкретное задание.
3. Для ключевых ответов задаю доказательства
Формулировку «написать экспертный текст» я заменяю конкретными заданиями: проверить документ, показать расчёт, получить комментарий, описать методику теста.
Google в рекомендациях по полезному контенту предлагает оценивать оригинальность материала, глубину раскрытия темы, наличие источников и сведения о компетентности автора. На эти пункты я опираюсь при подготовке требований к доказательной части.
Я предлагаю заранее составить реестр доказательств:
| Тип утверждения | Что требую от автора |
|---|---|
| Правило поисковой системы | Ссылку на актуальную официальную документацию |
| Возможность продукта | Документацию для нужной версии, тарифа и региона |
| Цена | Источник, валюту, состав предложения и дату проверки |
| Статистика | Первичную публикацию, период, выборку и ограничения |
| Собственный результат | Исходные данные, методику, период и сопутствующие изменения |
| Экспертная оценка | Имя, роль, основание компетентности и согласованный комментарий |
| Расчёт | Исходные значения, формулу, единицы измерения |
| Учебный пример | Явную пометку об условности данных |
В задании я отдельно запрещаю придумывать опыт от первого лица. Формулировки «я проверил», «мы внедрили» или «клиент получил результат» допустимы только при наличии соответствующих материалов.
Если данных нет, я предлагаю показать условный пример, описать способ проверки или сузить вывод.
Какие требования я предъявляю к источникам
Для каждого существенного внешнего факта я прошу автора сохранить прямую ссылку, название источника, дату проверки и фрагмент, который подтверждает утверждение.
В моём ТЗ действуют следующие правила:
- Начинать с первоисточника. Для правил, тарифов и характеристик искать документацию, официальный документ или оригинальное исследование.
- Проверять содержание страницы. Не ограничиваться поисковым фрагментом.
- Ставить ссылку рядом с утверждением. Общий список литературы можно добавить отдельно.
- Проверять применимость. Учитывать страну, дату, версию продукта, тариф и категорию пользователей.
- Разделять сведения и оценку. Заявление поставщика о своём продукте не выдавать за независимую оценку эффективности.
- Объяснять расхождения. Если источники дают разные значения, выяснить различия в периодах, определениях и методике.
- Обозначать неопределённость. Неподтверждённое утверждение убрать либо прямо написать, что подтвердить его не удалось.
Для изменчивых сведений я назначаю проверку перед публикацией. Единого правила «использовать только источники за последний год» не устанавливаю: актуальность предлагаю оценивать по содержанию и действующей редакции документа.
4. Собираю структуру вокруг решения читателя
Для практической статьи я предлагаю такой порядок:
- Краткий ответ на главный вопрос.
- Область применения и существенные ограничения.
- Критерии выбора или пошаговые действия.
- Пример, расчёт либо демонстрация.
- Ошибки и способы проверки.
- Шаблон, таблица или проверочный список.
- Ответы на оставшиеся вопросы.
- Следующее действие.
Это редакционная схема, которую я адаптирую к теме. Для обзора, исследования или новости структура будет другой.
К каждому разделу я добавляю мини-задание:
Заголовок: «Как сравнить стоимость CRM».
Вопрос: какие расходы учитывать в нашем сценарии?
Результат: таблица сравнения выбранных предложений.
Доказательства: актуальные тарифы и коммерческие предложения.
Ограничения: одинаковые условия расчёта, явно указанные исключения.
Такой уровень детализации я считаю достаточным, чтобы автор понимал ожидаемый результат, сохраняя свободу объяснения.
Как я формулирую требования к отдельному ответу
Я предлагаю начинать смысловой блок с ответа, затем давать обоснование, пример и условия применимости.
Например, вместо фразы «стоимость необходимо оценивать комплексно» в ТЗ я пишу:
Подготовить сравнение по единому сценарию. Указать выбранный тариф, число пользователей, период оплаты и дополнительные расходы из предложения каждого поставщика. Если состав предложений различается, объяснить различие до итогового вывода.
Также я прошу расшифровывать сокращения, называть предмет сравнения и сохранять оговорки рядом с выводом.
Эти правила я использую для ясности текста. Гарантии выбора страницы AI-системой из них не следует.
5. Добавляю SEO-требования с понятным назначением
В SEO-части задания я фиксирую основной запрос, связанные формулировки, поисковую задачу и страницы сайта, с которыми нужно связать материал.
При этом я не назначаю обязательную плотность ключей. Моё требование к автору — естественно использовать нужные термины и раскрыть согласованные вопросы.
Объём я определяю как ориентир для планирования и стоимости работы. Если тема раскрыта, не прошу дописывать абзацы ради числа символов. Google прямо указывает, что у него нет предпочтительной длины текста.
В комплект сдачи я включаю:
- H1, отражающий содержание статьи;
- варианты Title и Description без неподтверждённых обещаний;
- внутренние ссылки с объяснением их пользы;
- задания на иллюстрации и подписи;
- сведения об авторе и проверяющем, если такой специалист участвовал;
- перечень изменчивых данных для последующего обновления.
Технические условия публикации я закрепляю за редактором или специалистом сайта. Google рекомендует обеспечивать доступность важного содержания в текстовом виде, использовать внутренние ссылки и согласовывать структурированные данные с видимым контентом. Специальная разметка для ИИ-функций Google не требуется.
6. Готовый шаблон ТЗ на статью для SEO и AI-поиска
Ниже — заготовка для копирования. Поля в квадратных скобках нужно заполнить до передачи задания автору.
*Паспорт материала
Тема: [тема статьи].
Сайт и раздел: [адрес, раздел].
Формат: [инструкция / сравнение / разбор / исследование].
Язык и регион: [указать].
Автор / редактор / эксперт: [имена и роли; эксперт — при необходимости].
Сроки: [структура, черновик, проверка, итоговая версия].
Целевые поисковые площадки: [перечислить конкретно].
*Аудитория и цель
Кто читает: [роль, подготовка].
Ситуация: [почему возник вопрос].
Главная задача: [что нужно решить].
Ожидаемый результат: [что читатель сможет сделать после прочтения].
Следующее действие: [полезное действие и уместный призыв].
Основание описания аудитории: [данные / интервью / гипотеза].
*Границы и самостоятельная ценность
Раскрыть обязательно: [вопросы и подтемы].
Не включать: [смежные задачи].
Что материал добавляет к доступным публикациям: [собственный пример, проверку, расчёт, интервью, шаблон].
Кто предоставляет эти материалы: [ответственный, срок].
*Семантика и вопросы
Основной запрос: [запрос].
Связанные запросы и термины: [список].
Источник семантики: [инструмент, дата, регион; частотность — только при наличии данных].
Поисковая задача: [понять / сравнить / выполнить / проверить].
| Вопрос аудитории | Источник вопроса или пометка «гипотеза» | Приоритет | Раздел статьи | Ожидаемый ответ | Доказательство |
|---|---|---|---|---|---|
| [вопрос] | [источник] | [обязательно / дополнительно] | [раздел] | [результат] | [материал] |
*Структура
H1: [рабочий заголовок].
Вступление: [ситуация читателя, краткий ответ, область применения].
Для каждого H2/H3 заполнить:
- вопрос, который раскрывает раздел;
- основные тезисы;
- требуемый пример, таблицу или инструкцию;
- источники и материалы;
- ограничения и исключения.
Финальный блок: [проверочный список и следующее действие].
*Доказательства и источники
Предоставленные материалы: [документы и ссылки].
Что автор должен проверить самостоятельно: [список].
Какие комментарии запросить: [у кого и по каким вопросам].
| Проверяемое утверждение | Источник и прямая ссылка | Дата / версия / регион | Подтверждающий фрагмент | Ограничения | Статус проверки |
|---|---|---|---|---|---|
| [утверждение] | [источник] | [условия] | [фрагмент или раздел] | [оговорки] | [проверено / уточнить] |
Правила работы:
- Не придумывать факты, цифры, опыт, цитаты и ссылки.
- Внешние факты сопровождать источниками рядом с утверждениями.
- Для расчётов показывать исходные данные и формулы.
- Учебные примеры обозначать.
- Неподтверждённые тезисы выносить редактору на решение.
*Требования к изложению
Тон и лицо повествования: [указать].
Объём: [ориентир, который можно пересмотреть после согласования структуры].
Терминология: [обязательные названия и определения].
Начинать раздел с содержательного ответа. Объяснять выводы и сохранять важные условия рядом с ними. Таблицы использовать для сопоставимых параметров, списки — для действий и перечислений. Не повторять ответ ради дополнительного FAQ. Не имитировать личный опыт автора.
*Комплект сдачи
[Статья, варианты Title и Description, источники, реестр проверенных фактов, внутренние ссылки, задания на иллюстрации, сведения об авторе, список открытых вопросов.]
Техническая проверка публикации: [ответственный и отдельный перечень задач].
*Критерии приёмки
- Все обязательные вопросы получили ответы.
- Заголовок соответствует содержанию.
- Внешние факты проверены и снабжены подходящими источниками.
- Цифры, даты, версии и единицы измерения согласованы.
- Расчёты воспроизводимы.
- Примеры и реальные результаты чётко различаются.
- Выводы учитывают ограничения исходных данных.
- Личный опыт и комментарии подтверждены.
- Ссылки ведут на нужные материалы.
- Нерешённые вопросы явно отмечены.
*Обновление и оценка
Что может устареть: [тарифы, правила, характеристики, инструкции].
Повод для проверки: [изменение документации, продукта или условий].
Ответственный: [имя / роль].
Что оцениваем после публикации: [поисковые переходы, целевые действия, видимость по выбранным вопросам].
Как фиксируем наблюдения в AI-поиске: [система, дата, запрос, режим, ссылка на процитированную страницу].
7. Как я принимаю статью по такому ТЗ
При проверке я предлагаю идти от задачи читателя к доказательствам, а затем к формулировкам.
Сначала — можно ли выполнить обещанное заголовком действие. Затем — подтверждён ли каждый существенный вывод. После этого — удобны ли структура, язык и оформление.
Например, таблицу сравнения я не принимаю только за наличие таблицы: проверяю, совпадают ли условия сравнения и можно ли проследить происхождение значений. Указанную ссылку открываю и сопоставляю с утверждением, которое она должна подтверждать.
Результаты публикации я предлагаю оценивать отдельно от качества выполнения ТЗ. Сам факт приёмки текста не означает достижения поисковых позиций или получения цитирований.
Для наблюдений в AI-поиске я рекомендую сохранять систему, дату, формулировку вопроса, режим поиска и URL источника. Такой журнал помогает сравнивать зафиксированные ответы, но сам по себе не доказывает, что изменение видимости вызвала конкретная правка статьи.
Мой основной критерий готовности ТЗ таков: у каждого обязательного вопроса читателя должны быть ожидаемый ответ, место в структуре и способ проверки. Именно эту связку я предлагаю согласовать до начала написания — вместе с исходными материалами и ответственными за недостающие данные.
