ТЗ для копирайтера

17.09.2019 (2583 дня) Обновлено: 11.10.2026 14357

Как составить SEO-ТЗ копирайтеру: поисковый интент, семантика, кластеры, сущности, заголовки, факты, примеры задания и чек-лист приёмки текста.

Лень читать статью? Посмотри видео:

Техническое задание на написание текста для копирайтера

Время прочтения:

SEO-техническое задание для автора — не перечень «вставить ключевую фразу 12 раз и написать 7 000 символов». Хорошее ТЗ описывает, для кого создаётся страница, какую задачу она решает, какие факты обязательны и по каким критериям можно принять результат. Семантика, заголовки и анализ конкурентов помогают, но не заменяют понимание предмета и редакционную работу.

В этой инструкции — схема, по которой можно подготовить ТЗ на информационную статью, коммерческую услугу или карточку товара. В конце есть заполняемый образец и чек-лист качества.

Что нужно выяснить до написания

Зафиксируйте целевой URL, тип страницы, поисковый интент и место в архитектуре сайта. Одна статья может отвечать на несколько близких вопросов, но не обязана одновременно продавать услугу, давать энциклопедическое определение и заменять сервисную инструкцию. Если уже есть похожая страница, сначала проверьте каннибализацию.

Вводные для автора: целевая аудитория, продукт или предмет, регион, условия, доказательства, обязательные источники, ограничения на обещания, требования к таблицам, примерам и визуалам, а также стиль сайта. Для юридической или медицинской темы обязательно нужен квалифицированный фактчек и указание даты актуальности.

Семантика: запросы, интенты и реальные SERP

Соберите приоритетный кластер с вариантами формулировок. Затем посмотрите реальные конкурирующие результаты в нужных Яндексе/Google, регионе и устройстве. Не используйте частотность одного сервиса как единственное доказательство того, что для двух запросов нужна отдельная страница.

Полезно сравнить не только H2, но и формат ответа: перечни, таблицы, видео, калькулятор, FAQ, пример документа, характеристики, условия, цены. Иногда конкурент удовлетворяет задачу за счёт интерактивного элемента, а не большого текста. В таком случае ТЗ должно предусматривать соответствующую функциональность или честную альтернативу.

Разметка смысловых зон

Зона	Что должно быть	Проверка
Начало	Прямой ответ на основной вопрос	Пользователь понимает тему без прокрутки
Основные H2	Этапы, критерии выбора, исключения	Нет пустых разделов ради ключей
Таблица	Сравнение параметров или сценариев	Значения проверены источником
Практика	Пример, шаги, код или кейс	Можно повторить действие
Ограничения	Когда метод не подходит	Нет ложных универсальных обещаний
FAQ	Неочевидные вопросы и ошибки	Каждый ответ содержит пользу
Следующий шаг	Ссылка на смежный материал или действие	Нет навязчивого CTA не по интенту

Не пытайтесь механически повторить всю структуру ТОП-10. Задача редактора — выделить базовые ожидания пользователя и добавить оригинальные решения, которых не хватает у конкурентов.

Как использовать сущности, LSI, биграммы и триплеты

Релевантный текст естественно содержит названия объектов, процессов, параметров и последствий. Для статьи о редиректах это 301, 302, Apache, mod_rewrite, RewriteRule, canonical, HTTP, soft 404. Биграммы вроде «постоянный редирект» и «цепочка перенаправлений» полезны, когда раскрывают задачу. Триплеты показывают смысловую связь: «сервер → возвращает → HTTP 301», «удалённый документ → отвечает → 404», «редирект → направляет → релевантный URL».

Однако требование «обязательно употребить 17 LSI-слов по 3 раза» не имеет методологического основания. Нужна проверка полноты объяснения. Если автор добавил «HTTP 308», он обязан корректно отличить этот статус от 301/302, а не просто включить термин в абзац.

Пример: ТЗ на страницу услуги SEO-аудита

URL: /uslugi/seo-audit (демонстрационный, перед внедрением сверить существующие маршруты сайта).

Аудитория: владелец сайта, маркетолог, руководитель разработки. Основной интент: понять состав аудита, ожидаемый результат, сроки, условия и следующий шаг. Неосновные интенты: инструкция «как провести самостоятельно» и подбор бесплатного сервиса — их лучше раскрыть в отдельных материалах со ссылками.

Обязательные блоки:

Что входит в аудит и какие задачи он решает.
Какие источники и доступы нужны: краулер, логи, Метрика, Вебмастер, GSC, CMS.
Какие проблемы проверяются: индексирование, URL, структура, контент, внутренние ссылки, конверсии.
Что клиент получает: отчёт, приоритеты, постановку задач, критерии проверки.
Сроки и факторы, влияющие на оценку; не обещать срок без объёма сайта.
Пример обезличенного фрагмента диагностики и рекомендаций.
Ответы по внедрению, повторной проверке и доступам.
Понятная форма обращения и контакт.

Сущности: краулинг, серверный HTML, robots, canonical, sitemap, индексируемый URL, кластер запросов, коммерческий интент, Search Console, Яндекс.Вебмастер, Метрика, чек-лист, приоритет P0/P1/P2. Контекстные связи: «проблема → диагностика → исправление → проверка». Факты: перечень работ должен соответствовать реальной услуге; любые проценты прироста или гарантии ТОП не указывать без доказательств.

SEO-метаданные: в Title — тип услуги и реальное отличие предложения, в Description — подтверждённый состав/результат, в H1 — понятная услуга. Не требуется дословная одинаковость всех трёх элементов.

Оригинальные материалы: образец проверки с изменёнными данными клиента, скрин процесса, таблица итоговых приоритетов. Нельзя публиковать приватные отчёты или реальные доступы без разрешения.

Чек-лист редактора и SEO-специалиста

Основной вопрос пользователя закрыт на странице, а не переадресован на общую главную.
Все численные утверждения, даты, цены и ограничения имеют проверяемый источник.
Структура соответствует типу страницы: услуга, инструкция, категория, продукт.
Сущности употреблены там, где объясняются отношения между ними.
Нет избыточного повторения одинаковых фраз в каждом H2.
Таблицы и код реально помогают сделать выбор или повторить действие.
Страница не дублирует соседний URL по главному интенту.
Внутренние ссылки ведут на опубликованные релевантные материалы.
Текст не содержит выдуманного опыта, чужих отзывов и неподтверждённых результатов.
Итог проверен специалистом предметной области и человеком, который будет отвечать за обновления.

Приёмка текста: измеримые, но не искусственные критерии

Объём — следствие достаточного раскрытия вопроса. Уникальность по автоматическому проценту не подтверждает экспертность; грамотность не заменяет точности, а количество ключевых слов не заменяет понятную структуру. Для приёмки полезнее задать фактические проверки: «есть три корректных сценария редиректа», «приведены команды для проверки», «все тарифы актуальны на указанную дату», «нет обещания гарантированного TOP-1».

После публикации нужно проверить HTML, метатеги, внутренние ссылки, мобильное отображение таблиц, canonical и анализ показов/переходов. Если после внедрения изменилась структура выдачи, ТЗ тоже может потребовать актуализации.

Как помогают программы, но где остаётся ответственность редактора

SEO Semantic Lab может использовать собранную семантику, SERP, кластеры и стратегию при подготовке данных к ТЗ. В её актуальном интерфейсе существуют отдельные вкладки «Стратегия» и «Промпты»: это разные функции. Не следует утверждать, что библиотека «Промпты» по умолчанию содержит готовый универсальный SEO-ТЗ для любых проектов. Подготовленный системой документ остаётся черновиком, требующим проверки фактов, ограничений, продуктовых данных и реальных требований клиента.

FAQ

Сколько ключевых слов нужно вставить? Столько, сколько требуется для естественного и точного ответа. Норма плотности сама по себе не является целью.

Можно ли использовать ИИ для черновика? Да, при проверке фактов, источников, отраслевых требований и текста человеком. ИИ не должен изобретать результаты компании.

Нужно ли писать длинный текст на карточке товара? Не всегда. Нередко важнее характеристики, цена, наличие, фото, варианты и ответы о совместимости.

См. также: SERP-анализ, внутренняя оптимизация, ТЗ на страницу в SEO Semantic Lab, вкладка «Промпты».

Источник принципов качества: Google — создание полезного и надёжного контента.

Пример таблицы фактологической проверки в ТЗ

Утверждение автора	Что должно подтверждать	Решение редактора
«Подходит для всех CMS»	Список поддерживаемых платформ и версий	Сузить обещание или удалить
«Гарантирует рост SEO-трафика»	Доказательство причинности и условий	Удалить как необоснованную гарантию
«API бесплатно для всех»	Действующий тариф, лимиты, условия использования	Уточнить режим, стоимость, дату
«Canonical передаёт вес категории»	Документация о канонизации похожих URL	Исправить методику
«Время внедрения — один день»	Тип проекта, объём, ресурсы, предпосылки	Сформулировать как конкретный кейс
«Результат проверен на реальном сайте»	Дата, среда, лог/скрин, URL проверки	Добавить доказательство или оговорку

Это превращает редакционный фактчек из формального «проверили текст» в процесс с конкретными основаниями. Если автор не может подтвердить коммерческое обещание, лучше убрать обещание, чем прятать оговорку внизу страницы.

Шаблон задания: структура для копирования в работу

Название и URL страницы:
Тип: статья / услуга / категория / карточка / FAQ
Главный интент и целевая аудитория:
Подинтенты: 3–6 конкретных вопросов пользователя
Что не должно дублировать соседние страницы:
Основные запросы: кластер, без нормы плотности
Поисковая система и регион конкурентного SERP:
Типы конкурирующих URL и отличия их подхода:
Уникальное преимущество нашего материала:
Обязательные факты и источник каждого:
Предлагаемые H2/H3 и назначение каждого блока:
Таблица/пример/инструмент/видео, которые нужны:
Какие сущности и отношения необходимо объяснить:
Какие слова встречаются у конкурентов, но требуют проверки:
Какие продуктовые данные утверждены владельцем:
Запрещённые обещания, непроверенные цифры и юридические риски:
Ссылки на родительский раздел и соседние инструкции:
Предполагаемые Title, Description, H1:
Кто проверяет факты, UX и публикацию:
Критерии приёмки по пунктам:
Дата обновления и основания для следующей ревизии:

Этот шаблон не привязан к конкретной программе. Его можно применить в Google Docs, таск-трекере, CMS или SEO Semantic Lab. Для большого проекта удобнее хранить таблицу «кластер → URL → редакторский статус → исполнение», иначе десятки ТЗ начнут конфликтовать друг с другом.

ТЗ на инструкцию и ТЗ на коммерческую страницу: различия

В информационном материале основная ценность — способность пользователя выполнить действие. Поэтому важны входные условия, порядок шагов, результат, исключения и диагностика ошибок. Человек, ищущий «как настроить редирект в Apache», должен увидеть работающее выражение и способ проверить HTTP-код, а не только призыв заказать SEO.

В коммерческой странице задача иная — помочь выбрать продукт или услугу. Нужны точный состав предложения, стоимость или способ расчёта, условия, доступность, доверительные доказательства, отличие от альтернатив и понятное действие. Большой обучающий текст может мешать решению, если цена и форма спрятаны на несколько экранов ниже.

В каталоге товаров часто важны параметры фильтрации, наличие, совместимость и уникальные характеристики. Обязательный «текст категории на 5 000 символов» не должен вытеснять полезную навигацию или ассортимент.

Редакционная работа с SERP и конкурентами

Прежде чем ставить в ТЗ «добавить FAQ», посмотрите, действительно ли пользователям нужны вопросы такого типа. Отдельно сравните результаты по интенту, а не по одному высокочастотному слову. Указания «у конкурента заголовок в ТОПе» недостаточно: он мог ранжироваться за счёт сильной структуры сайта, предметной экспертности, ссылок или целого комплекса факторов.

В конкурентной таблице храните три слоя:

Наблюдение: у трёх релевантных страниц есть блок о совместимости и таблица моделей.
Гипотеза: нашим посетителям тоже важно быстро выбрать совместимую модель.
Редакторское решение: добавить таблицу совместимости, но наполнять её по первичным документам производителя, а не копировать конкурентные значения.

Таким образом вы используете SEO-сравнение для поиска незакрытого запроса, но не превращаете его в копирование чужого текста.

Отдельный проход по языку и стилю

Проверяйте терминологию: «индексация» не равна «сканированию», «переходы из поиска» не равны «показам», «достижения цели» не равны «продажам». Для B2B текст часто требует уточнения единиц измерения, технических допусков, стандартов и эксплуатационных условий. Для юридической темы важно указать юрисдикцию и дату применимости нормы.

Избегайте пустых вступлений, шаблонных фраз «в современном цифровом мире» и многократных повторов преимуществ без доказательств. Каждый абзац должен давать новое объяснение, условие, пример, проверку или конкретное действие.

Протокол приёмки после публикации

Сначала проверяют смысл: ответ на интент, отсутствие фактических ошибок, согласованность товарных данных. Затем HTML и техническое состояние: заголовки, таблицы на телефоне, доступность картинок, корректность ссылок, canonical, robots и серверные коды. Только потом — динамику запросов и посещений. Изменения метрик в первую неделю без контроля индексации и сезонности не позволяют надёжно оценить качество текста.

В идеале каждый обновлённый материал имеет владельца, дату последней фактологической проверки, перечень основных источников и повод для следующего обновления. Такая дисциплина особенно важна для API, сервисов, тарифов и инструкций по интерфейсам, которые могут измениться за несколько месяцев.

Второй пример: ТЗ на статью «Почему клики в Search Console не совпадают с Метрикой»

Целевой интент здесь диагностический, а не коммерческий. Пользователь видит два разных числа и хочет понять, ошибка ли это, где искать причину и как исправить измерение. Соответственно полезный материал начинается с прямого ответа «системы измеряют разные события», а не с общего рассказа о важности SEO.

Обязательная структура: определение клика/визита; таблица различий по точке измерения; причины расхождений (таймзона, блокировщики, фильтры, повторные визиты, редиректы); алгоритм проверки одного периода и одной посадочной; примеры, когда число различается без ошибки; ситуации, когда действительно нужно чинить код счётчика. В FAQ допустимы вопросы о поддоменах, кросс-доменных переходах и разных системах атрибуции.

Фактчекинг: официальные определения кликов Google и визитов Яндекса; уточнение, что чистое вычитание одной метрики из другой не даёт количества «недополученных пользователей». Уникальный элемент: наглядная таблица с тестовым сценарием из двух переходов и одного визита, помеченная как демонстрационная модель. Результат: человек может самостоятельно проверить, какой из источников ведёт к расхождению.

Такой бриф заметно отличается от SEO-ТЗ для страницы услуги. Если использовать один и тот же шаблон «преимущества, отзывы, цена» для обеих задач, статья о диагностике останется без настоящего решения.

Приоритеты для автора в условиях ограниченного времени

Если бюджет и срок ограничены, не надо механически отказываться от фактов ради достижения необходимого объёма. Разделите требования на три уровня:

Обязательное: достоверные ответы на основной интент, проверенная терминология, работающие ссылки, основные сценарии, отсутствие вводящих в заблуждение обещаний. Желательное: дополнительный пример, расширенная таблица исключений, собственные иллюстрации или интерактивная проверка. Дополнительное: связанные подтемы, которые можно вынести в отдельные материалы, если их раскрытие ухудшает фокус страницы.

Эта система упрощает приёмку: критическое отсутствие нельзя компенсировать «хорошей уникальностью», а второстепенный вопрос не должен задерживать публикацию готового экспертного документа без причины.

Контроль обновлений после передачи текста в CMS

ТЗ должно учитывать то, как контент живёт в системе управления: какой шаблон формирует H1, где меняются SEO-TV, кто отвечает за canonical, есть ли автоматические блоки похожих материалов, как формируются хлебные крошки и не теряется ли форматирование кодовых примеров. Если копирайтер отдаёт H1 внутри HTML, а шаблон уже печатает заголовок, после публикации появится дубль, которого не было в документе.

Перед следующей редакцией полезно сравнить исходный HTML и фактический результат после рендера. Особенно внимательно проверьте таблицы на мобильных устройствах, внешние источники, длинные ссылки и технические фрагменты с угловыми скобками, которые WYSIWYG-редактор может преобразовать.

Архивные иллюстрации и первоначальные наблюдения

Ниже — скриншоты из первоначального разбора подготовки ТЗ, проверки Wordstat, кластеризации и редакторских сервисов. Интерфейсы и условия работы сервисов могли измениться; используйте иллюстрации как историю метода.

Показать архивные иллюстрации (15)

История подхода. Первая версия задания для копирайтера была опубликована мной в блоге веб-студии. Этот ранний материал и скриншоты помогают сравнить эволюцию работы с семантикой и требованиями к тексту.