SEO-ТЗ для разработчика: как дать задачу так, чтобы ее сразу поняли и сделали правильно

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

Коротко о главном: зачем разработчику SEO-ТЗ

Разработчик не занимается оптимизацией контента и не ставит целью повысить позиции в поиске любой ценой. Его задача — сделать сайт технически корректным для индексации и удобным для пользователей.

Плохое ТЗ вызывает правки, недопонимания и лишние правки в коде. Хорошее ТЗ экономит время, снижает риски и ускоряет запуск изменений на бою.

Что подготовить до написания ТЗ

Перед тем как писать задачу, соберите базу: список страниц, целевые запросы, приоритеты, текущие метрики и доступы. Это избавит от необходимости дописывать детали по ходу работы.

Полезно иметь скриншоты текущего состояния страниц и отчёт инструментов: Google Search Console, PageSpeed Insights, Screaming Frog или аналог. Такие файлы лучше прикрепить прямо к задаче.

Карта приоритетов

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

Список приоритетов упрощает планирование спринтов и помогает разработчику понять очередность работ.

Доступы и окружение

Укажите доступы к стейджу и продакшену, учётные записи в Google Search Console и аналитике, а также контакт ответственного DevOps. Если тесты нужно запускать на стейдже — дайте ссылку.

Без точных логинов и адресов многие задачи будут простаивать в ожидании менеджера.

Структура понятного и полного SEO-ТЗ

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

Ниже — минимальный набор блоков, которые стоит включить в каждое ТЗ.

Шаблон задачи в одном предложении

Начинайте с краткого резюме: одна строка, что нужно сделать и почему. Это помогает быстро понять задачу даже тем, кто не читает детали.

Пример: «Добавить canonical на страницы категории, чтобы убрать дублирование и направить вес на страницу фильтра X».

Контекст и цель

Опишите, почему нужна правка. Укажите бизнес-цель и метрику, которую хотите улучшить: рост органического трафика, снижение ошибок индексации, улучшение скорости. Это поможет выбрать подход к реализации.

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

Технические требования: формулируйте как чек-лист

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

Например: «Вставить тег rel=canonical с атрибутом pointing на /category/ — только 301-редиректы не трогать».

Критерии приёма работы

Опишите, как будете проверять результат. Укажите инструменты и ожидаемые значения. Это ускорит приём и снизит количество корректировок.

Пример: «Проверить через curl: ответ 200, в присутствует rel=canonical, URL совпадает с ожидаемым. Убедиться, что Google Search Console не показывает ошибку duplicate.»

Требования к производительности и устойчивости

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

Например: «Не повышать TTFB более чем на 150 мс. Внедрение кеша должно работать с существующим CDN».

Тестовые данные и сценарии

Дайте конкретные URL для тестирования и сценарии: что кликать, какие параметры указывать. Чем точнее сценарий, тем меньше сомнений у исполнителя.

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

Частые технические задачи и как их прописать

Ниже перечислены типичные пункты SEO-ТЗ и шаблонные формулировки, которые можно адаптировать под проект.

Мета-теги и заголовки

Формулируйте требование так: где и как должны генерироваться title и meta description, какие шаблоны использовать и какие переменные подставлять.

Пример формулировки: «Title для карточек товара: {brand} {model} — купить в Москве | {site_name}. Ограничение длины 60 символов. Meta description — шаблон: Купить {brand} {model} по цене {price}. Максимум 160 символов.»

Каноникализация и дубли

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

Пример: «Для фильтров: если фильтр изменяет только сортировку — canonical на основную страницу категории; если фильтр сузит ассортимент — canonical на сам URL фильтра.»

Редиректы

Укажите тип редиректа (301 или 302), что редиректить и на какой URL. Добавьте таблицу старых и новых урлов, если это массовая операция.

Для массовых правок полезно приложить CSV с парой старый|новый и указать, нужно ли сохранять query string.

Sitemap и robots.txt

Напишите, какие урлы включать в sitemap, частоту обновления и приоритеты. Для robots.txt укажите, какие разделы закрывать и почему.

Пример: «В sitemap.xml должны быть все страницы категории и товара, исключая страницы фильтров. Обновление — раз в 24 часа».

Структурированные данные (schema.org)

Укажите типы схем, которые нужно добавить, и обязательные поля. Если есть пример JSON-LD — приложите его.

Пример: «Добавить schema Product с полями name, sku, brand, offers.price, offers.availability. Пример JSON-LD приложен в файле schema-example.json».

International и hreflang

Если сайт многоязычный, укажите карту доменов/поддоменов/папок и список языковых версий. Приложите таблицу соответствий и правила по default/alternates.

Пример: «Для /en/* ставить hreflang x-default на главную в корне и на соответствующие локализации; проверить через GSC после релиза».

Примеры шаблонов задач для системы трекинга

Ниже три варианта шаблона — для простой правки, для комплексной фичи и для миграции. Копируйте и подставляйте поля.

Шаблон 1 — простая задача

Заголовок: Добавить rel=canonical на страницу /category/

Описание: На странице /category/ появляются дубли при фильтрации. Добавить rel=canonical в head с указанием основного URL /category/.

• Контекст: минимизировать дубли в индексации.
• Техническое требование: вставить тег в head.
• Критерий приёма: при curl содержится ссылка canonical; в GSC нет ошибок duplicate спустя 48 часов.

Шаблон 2 — комплексная задача

Заголовок: Обновить генерацию meta для карточки товара

Описание: Перенести генерацию title и description из front-end в back-end, чтобы избежать FOUC и ускорить загрузку.

• Контекст: SEO и скорость.
• Требования: шаблон title — {brand} {name} — купить в {city} | {site}. description — до 160 символов, включать ключевой benefit и цену.
• Проверка: посмотреть исходный HTML, title должен быть на сервере; локальные тесты на stage.
• Ограничения: не менять структуру URL, не ломать микроразметку.

Шаблон 3 — миграция/редизайн

Заголовок: Миграция структуры URL — карта 1:1 + редиректы

Описание: Перенести старые урлы на новую структуру. Приложена CSV с соответствиями.

• Требование: настроить 301-редиректы, проверить отсутствие петлей, сохранить параметры utm.
• Проверка: тестировать выборочно через curl и средствами SEO-краулеров; GSC — снижение ошибок 404 до 0 за 3 дня.

Таблица приоритетов и оценка времени

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

Тип задачи	Приоритет	Оценка	Комментарий
Исправление 404, мешающих индексации	Высокий	1–2 ч	Часто критично для CRO/SEO
Добавление schema.org	Средний	2–6 ч	Зависит от количества шаблонов
Улучшение LCP	Средний/Высокий	1–5 дн	Зависит от фронтенда и сторонних скриптов

Как правильно формулировать «критерии приёма»

Критерии приёма — неформальные пожелания не подходят. Формулируйте измеримо и объективно, чтобы не было споров при проверке.

Используйте инструменты как часть проверки: curl для проверки заголовков, Lighthouse для LCP, Google Search Console для ошибок индексации. Пропишите точные шаги проверки.

Примеры конкретных критериев

«При миграции 301-редиректы настроены для 100% урлов из CSV; curl старого урла возвращает статус 301 и Location равен новому урлу».

«После внедрения schema Product, в разметке присутствуют поля name, offers.price и availability для каждой карточки товара. Проверить через structured data testing tool.»

Тестирование и валидация: что проверять и когда

Нельзя считать задачу закрытой, если изменения видны только на локалке. Всегда прогоняйте чек-лист на стейдже и, после деплоя, на продакшене.

Составьте регламент тестирования: какие страницы проверять, какие инструменты использовать и сколько ждать перед повторной проверкой в GSC.

Быстрый чек-лист перед релизом

• Проверить HTTP-статусы ключевых URL через curl.
• Проверить наличие метатегов и canonical в исходном HTML.
• Запустить Lighthouse для ключевых страниц и сравнить метрики до/после.
• Проверить sitemap.xml и robots.txt на соответствие требованиям.
• Отправить обновлённый sitemap в Google Search Console, если это необходимо.

Как оформить задачу в тикете: пример полного текста

Ниже — пример, который можно вставить в JIRA, Trello или любую другую систему трекинга. Он покрывает всё, что нужно разработчику для быстрого выполнения.

Пример тикета

Заголовок: Добавить server-side meta title для карточки товара

Описание: На текущих карточках title и meta description генерируется на клиенте. Это мешает поисковому роботу и тормозит рендер. Нужно переносить генерацию на сервер.

• Контекст: Улучшение индексируемости и сокращение FOUC.
• Технические требования:
  • Title: {brand} {name} — купить в {city} | {site}, max 60 символов.
  • Description: шаблон до 160 символов, включать benefit и цену.
  • Генерация должна выполняться на сервере и быть видна в исходном HTML.
• Критерии приёма:
  • curl https://stage.site.ru/product/slug/ возвращает title в HTML.
  • Lighthouse не увеличивает FCP более чем на 150 мс.
  • Regression тест: проверка микроразметки на отсутствие нарушений.
• Прикреплённые файлы: шаблоны title/description, скрин current HTML, список тестовых URL.

Коммуникация с разработчиком: тон и формат

Говорите конкретно и коротко. Укажите, какие решения принимают разработчики самостоятельно, а какие требуют согласования. Это экономит время обеих сторон.

Старайтесь указывать примерные оценки времени и предпочтительный порядок реализации, но оставляйте пространство для технической инициативы — разработчик видит код лучше вас.

Как отвечать на вопросы разработчика

Если разработчик спрашивает «как именно», дайте короткий ответ и, если нужно, ссылку на пример или код. Не присылайте длинные теоретические объяснения — в большинстве случаев достаточно одного-двух предложений и примера.

Формат общения: первая строка — суть, далее ссылка на документ или пример. Это сокращает время на разбор и обсуждение.

Типичные ошибки и как их избежать

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

Неполные критерии приёма

Если критерии размыты, задача может считаться выполненной, хотя проблема осталась. Всегда прописывайте измеримые критерии и тесты, которыми будете пользоваться.

Добавляйте примеры URL, скриншоты и ожидаемый вывод — это снимает двусмысленность.

Отсутствие контекста

Без бизнес-цели разработчик не понимает, почему важно то или иное решение. Кратко объясняйте, чего вы хотите добиться, и укажите метрики.

Контекст помогает выбрать оптимальное техническое решение и избежать излишних изменений.

Слишком общий язык

Фразы типа «оптимизировать под SEO» бесполезны. Конкретизируйте: «сгенерировать title на сервере, добавить canonical, убрать индексацию дубликатов».

Четкие команды позволяют выполнить задачу с первого раза.

Мой опыт: практические кейсы

В одном из проектов поведение метатегов генерировалось клиентским JS. Мы перенесли генерацию на сервер, прописали критерии приёма и дали разработчикам CSV тестов. Релиз прошёл без багов, падение времени до первого байта составило 90 мс, а в поисковом трафике спустя 2 месяца наблюдался стабильный рост.

Другой кейс — массовые редиректы после реструктуризации. Мы подготовили CSV со 1200 строк и прогнали его в staging. Перед деплоем сделали автоматический тест на отсутствие циклических редиректов. Это сэкономило нам несколько дней исправлений на бою.

Рекомендации по инструментам и автоматизации

Используйте простые инструменты для автоматической проверки: curl, lighthouse-ci, собственные скрипты на node/python. Автоматизация снижает число ручных проверок и ускоряет релиз.

Для массовых изменений удобны CSV и скрипты, которые применяют правки и сразу проверяют HTTP-ответы и наличие тегов в HTML.

Набор обязательных инструментов

• curl или httpie — для быстрой проверки ответов сервера.
• Lighthouse / PageSpeed Insights — для измерения Core Web Vitals.
• Screaming Frog или аналог — для краулинга и поиска дублей.
• Google Search Console — для контроля индексации и ошибок.

Как интегрировать SEO-ТЗ в процесс разработки

SEO не должно быть частью ad-hoc правок. Встраивайте задачи в бэклог и делайте их частью sprint planning. Это помогает согласовывать сроки и ресурсы.

Когда SEO-задачи включены в регулярный процесс, меньше риск, что они будут отложены или реализованы впопыхах.

Взаимодействие с продуктовой командой

Согласуйте с продакт-менеджером приоритеты и возможные риски. Если правки могут повлиять на UX, включайте UX-дизайнера в обсуждение.

Синхронизация помогает находить компромиссы между SEO и пользовательскими сценариями.

Итоговые рекомендации: чек-лист перед отправкой ТЗ

Перед тем как ставить задачу в систему, прогоните этот короткий чек-лист. Он экономит время и снижает вероятность переделок.

• Есть краткая однострочная формулировка задачи.
• Прописан контекст и цель с метрикой.
• Даны точные технические требования в виде чек-листа.
• Прописаны критерии приёма и тестовые сценарии.
• Прикреплены скриншоты, CSV или примеры JSON-LD при необходимости.
• Указаны доступы и ссылки на стейдж/прод.
• Есть оценка приоритета и примерная трудоемкость.

Если вы выполните все пункты, разработчик получит чёткое задание и сможет выполнить его быстро и корректно. Это снижает число правок и ускоряет достижение результатов в поиске.

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

ПОЛУЧИТЬ БЕСПЛАТНУЮ КОНСУЛЬТАЦИЮ