Короткий ответ. SEO-ТЗ для разработчика — это не просьба «сделать сайт удобным для поисковых систем». У каждого требования должны быть конкретное поведение, пример и критерий приёмки: какой URL открыть, какой код вернуть, что отдать в canonical и как проверить результат.
Чем SEO-ТЗ отличается от аудита
Аудит описывает уже найденную проблему: например, у сортировок появились дубли. Техническое ТЗ должно превратить вывод в проверяемую задачу: сохранить сортировку для пользователя, не создавать на неё внутренние индексируемые ссылки, поставить canonical на основную категорию и исключить адрес из Sitemap.
Разработчику нужны не общие рекомендации, а поведение, исключения, примеры URL и способ проверки.
Плохое требование: «сайт должен хорошо индексироваться»
Такую формулировку нельзя однозначно принять. Лучше написать: индексируемые страницы возвращают 200 OK, разрешены robots.txt, не содержат noindex, имеют self-canonical и доступны хотя бы по одной обычной ссылке <a href>. Яндекс отдельно рекомендует именно такие ссылки и предупреждает, что глубокие страницы обнаруживаются медленнее.
Начинайте с матрицы типов страниц
Составьте список шаблонов: главная, услуги, категории, подкатегории, товары, бренды, фильтры, статьи, пагинация, внутренний поиск и служебные страницы. Для каждого зафиксируйте:
- индексируется ли страница;
- какой у неё URL и canonical;
- какие Title, H1 и Description формируются;
- попадает ли она в Sitemap;
- откуда получает внутренние ссылки.
Зафиксируйте правила URL и дублей
В ТЗ должны быть нижний регистр, дефисы, единый формат слеша, кириллица или транслитерация, структура категорий и товаров, параметры и поведение при переименовании. Для каждой альтернативы нужна таблица:
| Альтернативный URL | Ожидаемое поведение |
|---|---|
/Catalog/Page/ | 301 на /catalog/page/ |
http://site.ru/ | 301 на основную HTTPS-версию |
/page?sort=price | Функциональность сохраняется, canonical на базовую страницу |
| Старый адрес после миграции | 301 на максимально релевантный новый URL |
HTTP-коды и редиректы
Пропишите назначение каждого ответа: 200 — существующая страница, 301/308 — постоянный перенос, 404/410 — удалённый адрес без замены, 503 — временное обслуживание. Пустая страница, ошибка приложения и снятый товар не должны маскироваться под 200.
Редирект должен вести за один переход, без циклов и цепочек. При миграции отдельный mapping-файл позволяет сопоставить старые и новые адреса.
Canonical: логика по шаблонам
Для каждого типа определите self-canonical, поведение дублей и исключения. Особенно это важно для фильтров, вариантов товаров, параметров и пагинации. Не канонизируйте все страницы на родителя автоматически: это может скрыть самостоятельные полезные документы.
Если canonical меняется JavaScript, значение в исходном HTML и после обработки не должно противоречить друг другу.
Robots.txt не заменяет noindex
В robots.txt перечисляют конкретные служебные зоны: /admin/, технические параметры и ловушки обхода. Если страницу нужно исключить именно из индекса, роботу нужно дать прочитать noindex; закрытый robots.txt мешает увидеть эту директиву. Файл должен лежать в корне и возвращать 200 OK.
Sitemap и lastmod
Автоматический Sitemap должен содержать только канонические индексируемые страницы с ответом 200. В нём не должно быть редиректов, 404, noindex и параметрических дублей. lastmod меняют при существенном изменении текста, товара, цены или наличия, а не при каждом запросе страницы.
Внутренние ссылки и глубина
Важные страницы должны быть доступны через обычные ссылки из меню, категорий, хлебных крошек и тематических блоков. Sitemap не заменяет навигацию, а JavaScript-обработчик клика без полноценного href не должен быть единственным способом попасть на страницу. Не задавайте механическое правило «всё максимум в три клика»: требование должно быть связано с приоритетом и логикой структуры.
Title, Description, H1 и контентные поля
Для каждого шаблона задайте шаблон по умолчанию, поля в CMS и возможность ручного переопределения. Предусмотрите отсутствие двойных разделителей, работу с пустыми значениями и уникальность метаданных. На индексируемой странице должен быть один управляемый смысловой H1, не обязательно совпадающий с Title.
CMS должна позволять добавлять текст, таблицы, изображения, FAQ и экспертные блоки без постоянного участия программиста.
Фильтры, сортировки и поиск
Разделите технические фильтры и SEO-посадочные. У SEO-фильтра есть стабильный URL, Title/H1, self-canonical, правила индексации, внутренняя ссылка и при необходимости запись в Sitemap. Сортировка вроде ?sort=price_asc обычно не является отдельной посадочной.
Для внутреннего поиска заранее определите URL результатов, запрет индексации и защиту от бесконечной генерации страниц под любой запрос.
Пагинация и удалённые товары
У страниц пагинации должны быть уникальные URL и доступные ссылки на соседние страницы. Не канонизируйте всю пагинацию на первую страницу без проверки архитектуры. Для товара отдельно задайте сценарии: временно отсутствует — 200; снят и есть близкая замена — возможно 301; снят без замены — 404 или 410.
JavaScript нужно принимать по обработанному HTML
Сам JavaScript не является проблемой: Google умеет обрабатывать его. Проблема возникает, когда после обработки исчезают контент, ссылки, Title, canonical, robots или разметка. Проверяйте исходный HTML и DOM после рендеринга, а также то, как страницу видит поисковый робот Яндекса.
Критичные SEO-директивы не должны зависеть от неподтверждённого действия скрипта или конфликтовать между исходной и обработанной версиями.
Структурированные данные и изображения
В ТЗ укажите тип разметки, шаблон, обязательные поля и источник данных: Product, BreadcrumbList, Organization или Article. Разметка должна соответствовать видимому содержанию и проходить проверку.
Для изображений предусмотрите alt, размеры, адаптивные варианты и отложенную загрузку вне первого экрана. Главное изображение не нужно бездумно делать lazy.
404, серверные ошибки и staging
Несуществующий URL возвращает настоящий 404, даже если на странице есть поиск и ссылки на разделы. Пустые страницы и ошибки приложения не должны отвечать 200. Массовые 500, 503 и 429 снижают скорость обхода сайта.
Тестовая версия закрывается авторизацией и noindex. В критерии релиза отдельно включите проверку удаления временного запрета индексации с production.
Аналитика и формы
До запуска внедрите Яндекс Метрику, события успешной отправки форм, электронную торговлю при необходимости и согласие на обработку данных. Для SEO важна именно успешная заявка, а не клик по кнопке.
Формат «что — как — проверка»
Удобный формат одной задачи:
| Что | Требование | Проверка |
|---|---|---|
| URL | Только lowercase | Верхний регистр → 301 на основной адрес |
| Canonical | Self-canonical у категории | Проверить исходный HTML |
| Sitemap | Только indexable 200 | Обход XML и URL |
| 404 | Настоящий HTTP 404 | Проверить ответ сервера |
| Ссылки | Обычные <a href> | Проверить исходный и обработанный HTML |
Разделите требования на обязательные, важные и желательные. Критичны индексация, HTTP-коды, canonical и редиректы; дополнительные поля CMS и новые схемы разметки можно планировать отдельным приоритетом.
Кто согласует и принимает SEO-ТЗ
Минимальный состав — SEO-специалист, разработчик или тимлид и руководитель проекта. Для интернет-магазина нужен также человек, отвечающий за каталог. После реализации SEO-специалист отдельно проверяет тестовую и рабочую версии через обходчик, DevTools, HTTP-проверки, Search Console и Яндекс Вебмастер.
«Разработчику мало написать “убрать дубли” или “правильно настроить индексацию”. В хорошем SEO-ТЗ должно быть понятно, какой URL открыть, какой код вернуть и что поставить в canonical. Если выполнение нельзя однозначно проверить, требование сформулировано недостаточно точно».
— Константин Шипилов
Частые вопросы
Что входит в SEO-ТЗ разработчику?
Типы страниц, URL, индексация, canonical, robots.txt, Sitemap, HTTP-коды, метаданные, ссылки, фильтры, JavaScript, разметка, аналитика и критерии приёмки.
Нужно ли учитывать JavaScript?
Да. Проверяйте не только браузер, но и исходный и обработанный HTML: контент, ссылки и SEO-директивы.
Кто принимает работу?
SEO-специалист после реализации проверяет staging, а затем production.
Нужно ли описывать каждый canonical?
Нужна логика по каждому типу страницы и отдельные правила для фильтров, параметров, вариантов и пагинации.
Когда проводить SEO-приёмку?
До релиза на тестовой версии и повторно сразу после публикации.
Итог
Главный принцип SEO-ТЗ: проблема → требуемое поведение → пример → критерий приёмки. Такая спецификация помогает разработчику оценить объём, а SEO-специалисту — проверить результат без разных трактовок слова «готово».
Бесплатный первый шаг
Проверить SEO-требования к разработке
Можем разобрать структуру и технические требования проекта, расставить приоритеты и подготовить понятные критерии приёмки.