SEO на этапе разработки - это набор решений по структуре, URL, техническим настройкам и шаблонам контента, которые закладываются до релиза, чтобы сайт корректно индексировался и не терял трафик из‑за ошибок. Если внедрить это как процесс, seo оптимизация сайта перед публикацией становится предсказуемой: меньше переделок, быстрее запуск, проще масштабирование.
Что обязательно учесть в проекте перед публикацией
- Согласовать семантические кластеры и превратить их в понятную навигацию и посадочные страницы, а не в список ключей.
- Зафиксировать правила URL, редиректов и каноникализации до появления контента и внешних ссылок.
- Определить стратегию индексации: что открываем, что закрываем, и как это отражается в robots.txt и мета-тегах.
- Подготовить шаблоны метаданных (title/description), хлебные крошки и микроразметку для всех ключевых типов страниц.
- Проверить мобильность и производительность в сборке (CI), чтобы оптимизации не были разовыми.
- Встроить контроль качества: роли, чек-листы и проверки перед релизом, включая seo аудит сайта перед запуском.
Формирование семантической структуры: от кластеров до навигации
Кому подходит. Это базовый этап для коммерческих сайтов, контентных проектов, маркетплейсов и любых проектов, где важны посадочные страницы и масштабирование. Практически всегда seo для сайта при разработке дешевле, чем последующая перестройка структуры после индексации.
Когда НЕ стоит углубляться. Не тратьте недели на кластеризацию, если: проект - временный лендинг без расширения; есть только 1-3 страницы и нет планов на рост; домен/бренд/оффер не подтверждены и структура может кардинально измениться. В этих случаях достаточно минимальной структуры и корректных технических настроек.
- Соберите группы запросов (кластеры) и назначьте каждому кластеру тип страницы: категория, листинг, карточка, статья, справка.
- Проверьте, что каждое назначение имеет смысл для пользователя: понятный фильтр/листинг, сравнение, навигация, ответы.
- Зафиксируйте карту сайта (site map) как документ: разделы, вложенность, будущие расширения.
Архитектура сайта и URL: правила, влияющие на индексирование
Чтобы техническое seo при разработке сайта не превратилось в спор "на вкус", заранее подготовьте доступы, артефакты и правила, с которыми можно работать в разработке и на стейджинге.
- Доступы: стейджинг/превью-среда, доступ к конфигурации веб-сервера (Nginx/Apache), доступ к CMS/админке, возможность менять шаблоны и HTTP-заголовки.
- Артефакты проекта: актуальная карта страниц (план), список типов страниц и их назначение (коммерческая/информационная), макеты/компоненты, список фильтров и параметров.
- Правила URL: единый регистр, единый слеш в конце или без, правила транслитерации, запрет "мусорных" параметров, политика для пагинации и фильтров.
- Инструменты диагностики: любой краулер (для обхода сайта), валидатор микроразметки, Lighthouse/аналог в CI, просмотр заголовков (curl/DevTools), логирование 404/500.
- Соглашение о редиректах: 301 для постоянных изменений, запрет цепочек и циклов, единый слой конфигурации (чтобы не плодить правила в нескольких местах).
Технические требования: сервер, роботы, канонические и hreflang
Риски и ограничения, которые нужно учесть заранее:
- Стейджинг может случайно попасть в индекс из-за отсутствия базовой защиты (robots + авторизация) и утечек ссылок.
- Неверный canonical или редиректы "по месту" могут склеить не те страницы и обнулить видимость нужных URL.
- Фильтры/параметры без политики индексации создают тысячи дублей и размывают краулинговый бюджет.
- hreflang без строгой симметрии и корректных canonical часто даёт ошибки связности и неправильную выдачу регионов.
-
Закройте стейджинг от индексации безопасным способом.
Используйте базовую авторизацию или IP-allowlist как основной барьер, а robots/noindex - как дополнительный. Не полагайтесь только на robots.txt для защиты непубличной среды.- Проверьте, что стейджинг не отдаёт карту сайта и не имеет внешних ссылок.
- Проверьте, что на проде эти ограничения сняты и не мигрировали в релиз.
-
Настройте корректные коды ответов и единый "хост".
Договоритесь о единственной каноничной версии домена (www/без www, http→https) и обеспечьте 301-редиректы без цепочек. Все "битые" URL должны возвращать 404/410, а не 200 с шаблоном ошибки. -
Определите политику robots.txt и мета-роботов по типам страниц.
Составьте список разделов и служебных URL, которые нужно закрыть, и список страниц, которые обязаны индексироваться. Для тонких случаев (фильтры, внутренний поиск, сортировки) используйте правила, согласованные с архитектурой URL.- Не закрывайте CSS/JS, если они нужны для корректного рендеринга.
- Для страниц, которые должны быть доступны пользователю, но не нужны в индексе, используйте meta robots noindex (а не запрет в robots, если требуется сканирование для обнаружения noindex).
-
Внедрите canonical по шаблонам и проверьте edge-cases.
Каноникал должен быть самоссылочным на "чистом" URL и строго соответствовать выбранным правилам (слеш, регистр, параметры). Для параметризованных дублей и пагинации заранее определите, что является каноном. -
Сгенерируйте sitemap.xml по индексируемым страницам.
В карту сайта включайте только URL, которые должны индексироваться и отдают 200. Разделяйте карты по типам (если нужно для контроля) и проверьте, что они обновляются автоматически при изменении контента. -
Настройте hreflang для языков/регионов только при реальной мультирегиональности.
Делайте hreflang, если есть отдельные версии страниц для языков/регионов и они поддерживаются контентом, валютой/доставкой/контактами. Для каждой страницы обеспечьте взаимные ссылки hreflang и согласованный canonical.
Контентные шаблоны и микроразметка: как обеспечить качество и однозначность
- Для каждого типа страницы описаны правила генерации title и description (переменные, порядок, ограничения по дублям).
- На странице есть ровно один основной заголовок (H1), совпадающий по смыслу с интентом страницы, без переспама.
- Хлебные крошки формируются из реальной иерархии и не ломаются на фильтрах/параметрах.
- Микроразметка (Schema.org) выбрана по типу страницы и не конфликтует между собой (нет взаимоисключающих сущностей).
- Картинки имеют осмысленные alt там, где это помогает пониманию (товары, инфографика), и не используются для набивки ключей.
- Есть блоки, повышающие полноту ответа: характеристики/FAQ-блок/сравнение/доставка/условия - по типу страницы.
- Шаблон учитывает пустые состояния: нет товара, нет результатов фильтра, нет отзывов - без отдачи "тонкого" контента в индекс.
- Внутренние ссылки проставляются из логики навигации, а не случайным образом: категории→подкатегории→карточки, статьи→релевантные разделы.
Мобильность и производительность: метрики, профайлинг и оптимизация в CI
- Оптимизация "вручную в последний день": нет бюджета производительности и нет проверки в CI, поэтому регрессии повторяются.
- Тяжёлые шрифты и изображения без адаптивной загрузки (srcset/sizes), нет ленивой загрузки там, где она уместна.
- Критический CSS не выделен, рендер блокируется большими пакетами JS, гидрация "съедает" время на мобильных.
- Сторонние виджеты (чаты, аналитика, A/B) подключены без контроля: грузятся до интерактивности, нет отложенной загрузки.
- Дублирующиеся запросы данных и отсутствие кэширования на уровне CDN/сервера при повторных посещениях.
- "Бесконечные" листинги без продуманной пагинации/URL и без контроля индексации создают проблемы и для UX, и для обхода.
- Ошибки responsive-верстки: кликабельные элементы слишком близко, модалки перекрывают контент, нестабильные блоки вызывают сдвиги.
Процессы контроля: тесты, чек-листы и роли перед релизом
Выберите процесс, который соответствует масштабу команды и рискам. В любом варианте закрепите "владельца" SEO-требований и критерии готовности, иначе seo аудит сайта перед запуском будет находить одни и те же проблемы.
- Лёгкий режим (подходит небольшим сайтам и 1-2 релизам в месяц): ручной чек-лист + обязательный SEO-ревью PR перед релизом. Уместно, если сайт небольшой и URL/шаблоны меняются редко.
- Смешанный режим (универсальный): чек-лист + автопроверки (коды ответов, canonical, robots, sitemap) в CI. Уместно, когда несколько разработчиков и регулярные изменения шаблонов.
- Инженерный режим (для больших проектов): контрактные тесты на шаблоны (метатеги/микроразметка), мониторинг логов краулинга, алерты по всплескам 404/500. Уместно при частых релизах и множестве типов страниц.
- Аутсорс-контроль (когда нет экспертизы внутри): внешний аудит требований и приёмка релиза по техзаданию. Уместно, если команда небольшая, а цена ошибки высока.
Разбор частых проблем при внедрении SEO и пути их решения
Почему страницы на стейджинге попадают в индекс?
Обычно закрывают только robots.txt, но забывают про базовую авторизацию и утечки ссылок. Делайте защиту на уровне доступа (Basic Auth/IP), а robots/noindex используйте как дополнительный слой.
Что делать, если после релиза изменились URL и трафик просел?
Срочно проверьте 301-редиректы, цепочки и соответствие "старый→новый" без потерь. Затем обновите внутренние ссылки и sitemap, чтобы ускорить переобход.
Почему в индексе много дублей из-за фильтров и параметров?
Нет единой политики URL и canonical для параметризованных страниц. Зафиксируйте, какие фильтры индексируются, остальное нормализуйте каноникалами и/или закрывайте от индексации.
Когда canonical начинает вредить вместо пользы?
Когда он указывает на нерелевантную страницу (например, на категорию вместо фильтра, который должен ранжироваться) или формируется с ошибками хоста/слеша. Проверьте генерацию canonical по шаблонам и крайние случаи.
Почему поисковик "не видит" контент на JS-сайте?
Часто критический контент появляется только после тяжёлой загрузки JS или API-ошибок. Добавьте SSR/пререндер для ключевых страниц и контролируйте ошибки данных на проде.
Зачем делать SEO-проверки в CI, если есть ручная приёмка?
Ручная приёмка не ловит регрессии в каждом релизе и зависит от внимательности. Минимальные автопроверки (robots, коды, canonical, sitemap) снижают риск повторяющихся ошибок.
