SEOProvision
В задаче написано: «Настроить правильные редиректы для SEO». Разработчик меняет несколько правил, проверяет главную страницу и закрывает тикет.
Через неделю часть старых URL всё ещё отдаёт временный редирект, цепочки не исчезли, а параметры ведут на неожиданные адреса. Проверить результат невозможно: в ТЗ нет исходной ошибки и критериев приёмки.
SEO-ТЗ разработчику должно превращать поисковую проблему в воспроизводимое техническое изменение. В нём есть конкретный объект, текущее поведение, ожидаемый результат, границы воздействия и способ проверки. Чем дороже ошибка, тем меньше места остаётся для фраз «сделать корректно», «улучшить индексацию» и «учесть SEO».
Хорошее ТЗ начинается с воспроизводимой ошибки
До формулировки решения покажите, что происходит сейчас. Для одной страницы достаточно URL, последовательности действий и фактического ответа. Для шаблонной ошибки нужен небольшой, но разнообразный набор примеров: категория, карточка, страница с параметром, адрес со слешем и без него. Один удачный URL не доказывает, что правило работает во всём разделе.
Исходное состояние записывают так, чтобы другой человек смог повторить проверку без созвона:
- точный адрес и окружение: production, staging или локальная сборка;
- дата и инструмент проверки, если результат зависит от кэша или ответа сервера;
- фактический код, заголовок, HTML-фрагмент или маршрут;
- почему это проблема для пользователя или поискового робота;
- минимум один контрольный URL, который уже работает правильно и не должен сломаться.
Фраза «Яндекс плохо индексирует фильтры» для разработки слишком широкая. Воспроизводимая версия выглядит иначе: «URL с параметром ?sort=price отвечает 200, содержит self-canonical и доступен по внутренним ссылкам; на трёх примерах приложен HTML и путь перехода». Теперь видно, какой технический механизм нужно обсуждать, а какие SEO-выводы ещё предстоит подтвердить.
Не подменяйте наблюдение диагнозом. «Страница не индексируется из-за JavaScript» — гипотеза. «В исходном HTML нет карточек, после выполнения JavaScript они появляются» — проверяемый факт, с которого можно начать задачу.Требование связывает изменение и критерий приёмки
Основная формула технического требования проста: какие объекты меняются, какое состояние должно получиться и как его проверить. Она не навязывает реализацию, если способ зависит от архитектуры проекта, но не оставляет двусмысленности в результате.
Техническое задание не бывает универсальным: структура зависит от объекта. Для шаблона нужны заголовки и описание ожидаемых полей, для события — аналитика, а для маршрута — примеры входных и конечных ссылок.
| Поле | Что указать | Слабая формулировка |
|---|---|---|
| Объект | Шаблон, URL-маска, компонент или набор страниц | «На сайте» |
| Текущее состояние | Наблюдаемый ответ с примерами | «Работает неправильно» |
| Ожидаемое состояние | Код, значение, содержимое или маршрут после изменения | «Сделать SEO-friendly» |
| Исключения | Что правило не должно затронуть | Не указаны |
| Приёмка | Набор позитивных и негативных тестов | «Проверить после релиза» |
SEO-обоснование нужно, но оно не заменяет требование. Разработчику полезно понимать, зачем устраняется цепочка редиректов или почему canonical должен формироваться на сервере. Однако длинная лекция об индексации не отвечает на вопрос, какой ответ должен вернуть конкретный URL.
Если изменение затрагивает шаблон, перечислите инварианты: страницы остаются доступными пользователю, параметры аналитики не теряются, служебная область не попадает под правило, карта сайта не начинает содержать редиректы. Такие ограничения часто важнее подробного описания кода.
Заполненный пример: заменить временный редирект постоянным
Контекст. После переноса раздела старые адреса вида /blog/topic-name перенаправляются на /seo-blog/topic-name с кодом 302. Миграция завершена, старые URL не будут возвращены.
Фактическое состояние. Три приложенных старых URL отвечают 302, затем ведут на конечную страницу с кодом 200. Один адрес со старым слешем образует цепочку из двух переходов. Новый раздел и административные адреса работают без редиректа.
Требование. Для адресов, которые точно соответствуют маске старого публичного раздела, возвращать один постоянный редирект непосредственно на эквивалентный URL в /seo-blog/. Сохранять завершающую часть пути. Не применять правило к панели управления, файлам и адресам, которых нет в карте переноса.
Критерии приёмки. Каждый позитивный пример возвращает 301 и один заголовок Location с ожидаемым адресом. Конечный URL отвечает 200, а контрольные URL вне маски сохраняют прежнее поведение.
Внутренние ссылки и sitemap ведут сразу на новые адреса, без промежуточного перехода.
Откат. До релиза сохранить прежнее правило. Если контрольные адреса начинают перенаправляться ошибочно или появляется цикл, новое правило отключается, а задача возвращается в разработку с примерами. План отката особенно нужен для изменений, которые действуют на целый шаблон.
Такой пример не требует от SEO-специалиста выбирать конфигурационный файл или писать код. Архитектурное решение остаётся за разработчиком. Зато итог нельзя выдать за готовый, если код ответа, Location или область действия не совпадают с приёмкой.
Вопросы и ответы
Нужно ли прикладывать к SEO-ТЗ макет?
Макет нужен, если результат содержит новый интерфейс или расположение элементов влияет на задачу. Для серверного кода ответа, canonical или sitemap полезнее приложить примеры входных и ожидаемых данных. Артефакт выбирают под проверяемый результат, а не по привычке.
Когда одно большое ТЗ лучше разделить?
Когда части имеют разные риски, исполнителей, релизы или способы приёмки. Например, изменение маршрутов, обновление внутренних ссылок и очистку sitemap можно связать общей задачей миграции, но проверять отдельными тикетами с зависимостями.
Кто должен проводить финальную приёмку?
Разработчик проверяет реализацию и технические тесты, а автор SEO-требования независимо воспроизводит критерии на нужном окружении. Для рискованного релиза полезна дополнительная проверка человека, который не участвовал в реализации.
Приёмка проверяет результат, а не отчёт исполнителя
Комментарий «сделано, проверил» — это статус, а не доказательство. Приёмка начинается с тех же примеров, которые были сохранены до разработки, и включает контрольные случаи. Если задача меняет генерацию метатегов, нельзя открыть одну страницу: проверяют разные шаблоны, пустые значения, пагинацию и экранирование символов.
- Зафиксируйте версию и окружение, где находится изменение.
- Повторите исходную ошибку и убедитесь, что она больше не воспроизводится.
- Пройдите все критерии приёмки, включая исключения.
- Проверьте соседние функции, которые могло затронуть общее правило.
- Сохраните фактический результат: ответ сервера, HTML, скриншот или выгрузку.
- После production-релиза повторите критические тесты без кэша staging.
При расхождении сравните фактический ответ с ожидаемым, добавьте новый пример в тесты и уберите двусмысленность из требования. Затем оцените, затронуты ли соседние шаблоны.
Поисковый эффект отделяют от технической готовности. Если canonical появился в HTML и соответствует правилу, разработка принята. Переобход и изменение данных в Яндекс Вебмастере проверяют отдельным наблюдением позже. Нельзя держать тикет разработчика открытым до роста позиций, но нельзя и называть релиз успешным, пока требование не появилось на production.
Когда SEO-задачи регулярно затрагивают шаблоны, аналитику и контент, их безопаснее вести как часть комплексного SEO-продвижения сайта: специалист отвечает не только за формулировку тикета, но и за исходную диагностику, приёмку и проверку последствий.
Хорошее ТЗ можно передать другому разработчику без потери смысла. Хорошую приёмку можно повторить независимо. Если оба условия выполнены, обсуждение становится короче, а риск получить формально закрытую, но нерешённую SEO-проблему — заметно ниже.
