В SEO почти все действия проходят через задачи: вы нашли проблему или точку роста, а дальше это нужно превратить в понятное ТЗ, которое команда сможет внедрить без гаданий и переписок на 20 сообщений.
Что такое хорошее ТЗ в SEO
Хорошее ТЗ отвечает на три вопроса:
- что именно делаем (и где именно);
- зачем делаем (ожидаемый эффект, но без обещаний мгновенного роста);
- как поймем, что сделано правильно (критерии приемки).
Если этих трех частей нет, задача превращается в обсуждение. Если они есть, задача превращается в внедрение.
SEO-специалист отвечает за то, что нужно сделать и почему это важно. Команда (или подрядчики) отвечает за то, как именно это внедрить.
Важно: критерии приемки в SEO - это не “вырасти в ТОП”. Рост зависит от времени, конкурентов и апдейтов, а задача должна быть проверяемой сразу - по факту внедрения.
Универсальный каркас ТЗ
Один и тот же каркас можно использовать и для разработки, и для контента. Меняется только наполнение.
| Блок ТЗ | Что написать | Пример формулировки |
|---|---|---|
| Заголовок задачи | Коротко, предметно, без общих слов | ”Закрыть индексацию параметров фильтра /?color= и задать canonical” |
| Контекст | В чем проблема и где видно | ”В индексе есть страницы с параметрами. Они размывают релевантность и расходуют краулинговый бюджет.” |
| Цель | Какой результат ожидаем на уровне внедрения | ”Оставить в индексе только чистые категории без параметров.” |
| Объем | Список URL или правило | ”Все URL вида /catalog/? кроме параметра ?page=“ |
| Требования | Точные правила или структура | ”Параметры закрываем meta robots noindex,follow. Canonical на базовую категорию без параметров.” |
| Критерии приемки | Как проверяем, что сделано | ”На 10 тестовых URL в коде есть meta robots, canonical, статус 200. В sitemap параметрических URL нет.” |
| Приоритет и дедлайн | Насколько срочно и почему | ”Высокий приоритет - растет число дублей в индексе, важна фиксация до следующего релиза.” |
| Ответственные | Кто делает, кто принимает | ”Исполнитель: dev. Приемка: SEO + QA (тестировщик).” |
| Материалы | Ссылки, скрины, примеры | ”Список URL, скрин из GSC, ссылка на макет/пример у конкурентов.” |
Совет по форме: одна задача - один понятный результат. Если в ТЗ одновременно “поправьте canonical”, “ускорьте сайт” и “перепишите тексты”, это три разных задачи с разными проверками и разными исполнителями.
ТЗ разработчику: как ставить задачи так, чтобы внедрили с первого раза
Разработчику важно понимать точные правила и точку применения. Чем меньше интерпретаций, тем меньше риска, что внедрение получится “почти так”.
1) Всегда указывайте где меняем
Варианты “где” (выберите то, что относится к задаче):
- конкретные URL (списком);
- шаблон/тип страниц (карточка товара, категория, статья, поиск по сайту);
- правило для всего раздела (маска URL);
- конкретный модуль (фильтр, сортировка, пагинация).
Плохо: “закрыть от индексации фильтры”.
Хорошо: “закрыть URL с параметрами фильтра в /catalog/ - все URL с ?color=, ?size=, ?brand=; пагинацию ?page= не закрывать”.
2) Пишите правила в виде проверяемых условий
Формулировка, которая помогает разработке:
- условие - что считаем “параметрической страницей”;
- действие - что должно появиться на странице;
- исключения - что не трогаем.
Пример структуры:
- если URL содержит любой параметр, кроме page - добавляем meta robots noindex,follow;
- canonical всегда на URL без параметров;
- ссылки фильтра оставляем кликабельными, чтобы пользователь мог пользоваться.
3) Уточняйте ожидаемое поведение для SEO элементов
Частые зоны, где возникают “почти правильно”:
- редиректы (301 или 302, правила, цепочки, сохранение параметров);
- canonical (на себя, на базовую);
- robots/meta robots/X-Robots-Tag;
- sitemap (что включаем, что исключаем);
- пагинация (как формируем ссылки, canonical, статус коды);
- микроразметка (какой тип, где встраиваем, валидность).
Если вы ожидаете конкретный вариант, назовите его прямо и добавьте критерий проверки.
4) Пропишите критерии приемки, которые можно проверить сразу
Критерии приемки для разработки обычно состоят из набора проверок:
- статус код (200/301/404) на тестовых URL;
- наличие нужных тегов в HTML (robots, canonical, hreflang, JSON-LD);
- отсутствие побочных эффектов (не сломалась навигация, фильтр, скорость);
- корректность на мобайле и десктопе;
- обновился sitemap, если это часть задачи.
Хороший прием - приложить 5-15 “тестовых URL”: пару типовых, пару пограничных и пару исключений.
5) Добавляйте риски и ограничения
Если задача может повлиять на бизнес-логику, это нужно сказать заранее:
- “редиректы не должны ломать рекламные UTM”;
- “фильтр важен для пользователей - не отключаем, только управляем индексом”;
- “страницы поиска дают конверсии - закрывать только мусорные варианты”.
Так разработка и SEO быстрее договорятся о компромиссе, который не убьет продажи.
Сервисы для работы с семантикой
ТЗ редактору: как ставить задачи на контент, чтобы получилось полезно и по делу
Редактору важно понять интент, аудиторию и структуру ответа. Ключевая ошибка SEO ТЗ для текста - когда в нем только “впишите ключи”. Это дает не статью, а набор фраз.
1) Дайте контекст и цель страницы
Минимум:
- кто читатель (новичок/профи/покупатель);
- что человек хочет решить (вопрос, выбор, сравнение, действие);
- какую роль играет страница в воронке (привести лид, объяснить, снять возражения).
Пример: “Страница под запросы про выбор кондиционера. Цель - помочь выбрать тип и мощность, затем привести к заявке на расчет/подбор.”
2) Согласуйте структуру, а не только объем
В ТЗ редактору полезнее дать:
- план разделов (H2-H3);
- какие вопросы обязательно закрыть;
- какие термины и сущности должны быть объяснены;
- где нужен пример, таблица, чек-лист или короткий вывод.
Если вы хотите, чтобы страница была легко читаемой, можно задать рамки:
- короткие абзацы;
- списки там, где есть перечисления;
- один тезис - один блок.
3) Уточните требования к фактам и довериям
Если тема требует точности (здоровье, деньги, безопасность, юридические вопросы), в ТЗ стоит добавить:
- что проверяем по первоисточникам;
- где нужны ссылки на документы/нормы/официальные страницы (если у вас это принято);
- что нельзя утверждать без подтверждения.
Даже в не YMYL темах полезно попросить редактора проверять цифры, термины и определения.
4) Критерии приемки для текста
Чтобы не спорить “нравится/не нравится”, договоритесь о проверяемых критериях:
- структура соблюдена, заголовки отражают смысл;
- нет воды, текст отвечает на вопросы интента;
- ключевые термины раскрыты, нет явных фактических ошибок;
- читабельность нормальная (короткие абзацы, понятные формулировки);
- Title/H1/Description и важные элементы страницы подготовлены, если это часть задачи.
Если нужно, добавьте ограничения: “не обещать результатов”, “не давать опасных советов”, “не использовать канцелярит”.
Как формулировать критерии приемки, чтобы “готово” было понятно всем
В SEO удобно разделять два типа результата:
- результат внедрения - то, что можно проверить сразу (теги, код, структура, опубликованный текст);
- результат эффективности - то, что проверяется позже (изменение индексации, трафик, конверсии).
В ТЗ фиксируйте первое как обязательное, а второе - как ожидаемый эффект и план проверки.
Пример: “После внедрения проверяем 20 URL и валидатор микроразметки. Через 2-4 недели смотрим динамику дублей и показов по разделу.”
Типовые ошибки в ТЗ и как их избежать
- Слишком общие формулировки: “улучшить SEO”, “сделать тексты”, “оптимизировать скорость”.
- Нет списка URL или правила - непонятно, где внедрять.
- Смешаны разные задачи - невозможно принять и оценить.
- Нет критериев приемки - каждый понимает “готово” по-своему.
- Не указаны исключения - ломаются важные страницы или функции.
- Нет приоритета и срока - задача провисает в бэклоге.
- Нет владельца приемки - внедрили, но никто не проверил.
Итог
Хорошее ТЗ в SEO - это короткий документ, который переводит идею в внедрение:
- фиксируем контекст и цель;
- точно описываем объем (URL или правило) и требования;
- задаем критерии приемки, которые можно проверить сразу;
- cначала проверяем, что сделано по ТЗ, а эффект в метриках оцениваем позже - так меньше разночтений по ожиданиям и срокам.