Большинство SEO-проблем нового сайта закладываются на этапе ТЗ, а не после запуска. Если в техзадании нет требований к URL, мета-тегам, редиректам, скорости и индексации, разработчик сделает «как удобно», а ты потом полгода будешь это чинить. Ниже — блоки, которые я вписываю в ТЗ до того, как кто-то откроет Figma.
Разбираем, что должно быть в техзадании на сайт, чтобы после релиза не пришлось переделывать половину. Не шаблон ТЗ целиком — там ещё дизайн, функционал, интеграции. Только SEO-часть, которую почему-то пропускают чаще всего.
Почему пропускают? Потому что сеошника зовут, когда сайт уже готов. «Мы запустились, сделай нам SEO». А сделать SEO на сайте, где все страницы услуг лежат на одном URL с якорями, — это уже не SEO, это переделка.
Когда подключать SEO к разработке
До прототипов. Структура сайта — это семантика, а не дизайнерское решение. Сколько страниц услуг, какие категории в каталоге, где будут статьи — это всё следует из того, что люди ищут, а не из того, что красиво смотрится в меню.
В 2023-м я пришёл на сайт производственной компании через месяц после запуска. Дизайн отличный. Все 12 направлений работ — на одной странице «Услуги» в аккордеоне. Под каждое направление в Wordstat был свой спрос, а страницы не было ни одной. Переделка структуры обошлась клиенту дороже, чем стоило бы SEO-сопровождение ТЗ с самого начала. Раза в три.
Блок 1. Структура и URL
- Карта сайта до дизайна. Список всех страниц с URL, H1 и основным кластером запросов. Это не sitemap.xml, это таблица в Google Sheets. Из неё дизайнер понимает, сколько шаблонов нужно, а разработчик — какие разделы.
- ЧПУ латиницей, в нижнем регистре, через дефис.
/uslugi/remont-dvigatelya/, а не/?page=17и не/Услуги/Ремонт%20двигателя. - Единый формат слеша на конце. Либо везде со слешем, либо везде без. Второй вариант — 301 на первый.
- Вложенность не глубже 3-4 уровней от главной.
Отдельно про каннибализацию: если на этапе структуры две страницы претендуют на один и тот же интент — склей их сразу. После запуска это обойдётся дороже. Подробно — в статье про каннибализацию ключей.
Блок 2. Управление мета-тегами
Требование к админке, которое забывают чаще всего: title, description и H1 должны редактироваться отдельно для каждой страницы. Не генерироваться из названия раз и навсегда. Не «title = H1». Отдельные поля.
Для каталогов и больших разделов — плюс шаблоны с подстановкой: {Название товара} — купить в Минске, цена {цена} BYN, с возможностью переопределить вручную для любой страницы. Как их составлять — в статье про title и description.
Ещё туда же: поле для canonical, чекбокс noindex, поле alt для каждого изображения, поля для Open Graph. Если CMS этого не умеет из коробки — это задача разработчику, а не «потом плагин поставим».
Блок 3. Индексация и служебные файлы
- robots.txt — редактируемый из админки или хотя бы через файл в корне. На тестовом домене — полный Disallow плюс закрытие паролем.
- sitemap.xml — генерируется автоматически, обновляется при добавлении страниц, содержит только 200-страницы без noindex.
- Коды ответа. Несуществующие URL отдают настоящий 404, а не 200 с текстом «страница не найдена». Своя страница 404 с навигацией.
- Зеркала. Один главный хост: https, с www или без — решите заранее, остальные варианты 301 на главный.
Самая дорогая ошибка из этого блока, которую я видел лично: тестовый поддомен разработчика открыт для индексации, Яндекс за месяц разработки съел его целиком. Запускаешь боевой сайт — а в выдаче дубль на dev.-поддомене с тем же контентом. Как правильно закрывать — в статье про robots.txt.
Блок 4. Скорость как требование, а не пожелание
«Сайт должен быстро грузиться» — это не требование. Это пожелание, которое разработчик с чистой совестью проигнорирует.
Требование выглядит так:
| Метрика | Порог в ТЗ | Как проверяем при приёмке |
|---|---|---|
| LCP | ≤ 2,5 с на мобильном | PageSpeed Insights, 3 ключевых шаблона |
| CLS | ≤ 0,1 | PageSpeed Insights / DevTools |
| INP | ≤ 200 мс | DevTools Performance, после запуска — CrUX |
| Вес главной | до 2 МБ без видео | DevTools Network |
| Изображения | WebP/AVIF, lazy-load ниже первого экрана, заданы width/height | Ручная проверка |
Пороги LCP/CLS/INP — официальные границы «хорошо» у Google, см. web.dev/vitals. Остальное — мои рабочие нормы для сайтов услуг. Проверять на лабораторных данных при приёмке, потому что полевых у нового сайта ещё нет. Разбор, что делать если не укладываетесь, — в статьях про Core Web Vitals и INP.
Блок 5. Рендеринг
Если разработчик предлагает SPA на React/Vue без серверного рендеринга — спроси прямо: какой HTML получит робот при первом запросе? Если в исходнике страницы пустой <div id="app"> — это проблема. Google JS рендерит, но с задержкой. Яндекс рендерит хуже.
В ТЗ пиши так: основной контент, заголовки, мета-теги, ссылки меню и хлебных крошек присутствуют в HTML-ответе сервера без выполнения JavaScript. Проверка при приёмке — «Просмотр кода страницы», не DevTools.
Блок 6. Микроразметка
Минимум, который прошу закладывать в шаблоны:
- Organization или LocalBusiness — на главной и в контактах;
- BreadcrumbList — на всех внутренних страницах, вместе с видимыми крошками;
- Product с Offer — в карточках товаров, если это магазин;
- Article/BlogPosting — в блоге.
Формат JSON-LD, данные подтягиваются из полей CMS, а не вписываются руками. Как проверить и что ещё можно разметить — в статье про Schema.org.
Блок 7. Переезд, если сайт не первый
Если это редизайн или переезд на новую CMS — самый важный блок из всех. Таблица соответствия старых URL новым, 301 с каждого старого адреса, который имел трафик или внешние ссылки. Не на главную оптом. Постранично.
Список старых URL берёшь из GSC (Эффективность → Страницы), Вебмастера и Метрики за последний год, плюс выгрузка краулером старого сайта. Сколько раз я видел переезд, после которого органика падала вдвое на 3-4 месяца, потому что «редиректы потом настроим». Когда решаешь, стоит ли вообще переезжать, — почитай про когда нужен редизайн.
Блок 8. Аналитика с первого дня
Счётчики Метрики и GA4 (или GTM) ставятся до запуска, цели на формы и звонки — тоже. Сайт без аналитики первые 2-3 недели — потерянные данные, которые не восстановить. Панели Вебмастера и GSC подтверждаются в день запуска, sitemap отправляется туда же.
Чек-лист приёмки
Это я прошу пройти до того, как подписывать акт с разработчиком:
- Прогнать сайт краулером (Screaming Frog или аналог): нет 404, нет цепочек редиректов, у каждой страницы уникальные title и H1.
- Проверить robots.txt и sitemap.xml на боевом домене — не тестовый Disallow.
- Открыть исходник трёх ключевых шаблонов — контент в HTML есть.
- PageSpeed по тем же трём шаблонам — пороги из таблицы.
- Отправить тестовую заявку — цель в Метрике сработала.
- Проверить 301 по 10-20 старым URL выборочно.
Звучит как много? Это полдня работы. Исправление этого же после запуска — месяцы.
Частые вопросы
Разработчик говорит, что SEO сделает сам. Верить?
Спроси, что конкретно он понимает под SEO. Если ответ «поставим плагин Yoast» или «пропишем мета-теги» — это не SEO, это поля в админке. Структура по семантике, редиректы, рендеринг — это то, о чём разработчики думают редко, не потому что плохие, а потому что это не их задача.
Сколько стоит SEO-часть ТЗ?
Зависит от размера. Для сайта услуг на 15-30 страниц — это семантика плюс структура плюс требования, обычно пара рабочих дней. Для магазина с каталогом — дольше, там ещё фильтры и шаблоны мета-тегов. Ориентиры по ценам — в статье сколько стоит SEO в Минске.
На каком движке делать, чтобы с SEO не было проблем?
Почти на любом нормальном, если выполнены требования из этой статьи. Движок вторичен, ТЗ первично. Сравнение вариантов — в статье про выбор движка для сайта услуг.
А если сайт уже запущен без всего этого?
Тогда то же самое, только в режиме аудита: прогоняешь чек-лист приёмки на живом сайте и чинишь по приоритету — индексация, редиректы, структура, скорость.
Готовишь ТЗ на новый сайт или редизайн и хочешь, чтобы SEO-часть была там с первого дня, — пиши на mostlycorp@gmail.com. Для интернет-магазинов ещё пригодится: SEO-фильтры и SEO карточек товара.