Что заложить в SEO ещё на этапе разработки сайта

SEO часто вспоминают после фразы «сайт уже почти готов, осталось заполнить метатеги». В этот момент можно написать title и description, но самые дорогие решения уже приняты: структура URL, набор страниц, модель контента, способ рендеринга, мобильная сетка и поведение фильтров.

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

Начните не с ключей, а с карты спроса

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

• какие разные задачи есть у будущих посетителей;
• где нужен отдельный коммерческий URL;
• какие запросы должен закрывать один общий раздел;
• где нужна статья, калькулятор, сравнение или инструкция;
• какие страницы могут конкурировать друг с другом;
• какие фильтры имеют самостоятельный спрос, а какие создадут мусор.

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

Результат этапа — не «семантическое ядро вообще», а карта: интент → будущая страница → роль в воронке → целевое действие → связанные материалы.

Спроектируйте структуру до макетов

Хорошая структура понятна человеку без знания внутренних терминов компании.

Например, у веб-студии могут быть:

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

Но каждый URL должен иметь собственную работу. Страница «сайт на WordPress» и страница «корпоративный сайт» могут пересекаться, однако первая отвечает за выбор платформы, а вторая — за формат бизнес-задачи. Их структура, аргументы и внутренние ссылки не должны быть копиями.

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

Зафиксируйте правила URL

Поменять адреса после запуска можно, но это всегда дополнительная миграция. Лучше заранее решить:

• используется ли транслитерация;
• нужен ли слеш на конце;
• как устроены категории и вложенность;
• что происходит при изменении названия услуги;
• какие параметры может генерировать сайт;
• как обрабатываются регистр, HTTP/HTTPS и www;
• какие URL являются постоянными идентификаторами материалов.

Адрес должен быть стабильным и читаемым, а не повторять всю цепочку меню. Не стоит включать в него цену, год или рекламную формулировку, которую придётся менять.

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

Опишите контентную модель

Контентная модель определяет, из каких полей собирается страница и что редактор сможет менять без разработчика.

Для услуги это могут быть:

• краткий оффер;
• задачи клиента;
• состав работ;
• ограничения и зависимости;
• этапы;
• стоимость или принцип расчёта;
• примеры;
• ответы на вопросы;
• связанные услуги;
• автор или экспертная проверка.

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

Если CMS позволяет только менять один большой HTML-текст, дальнейшая работа будет медленной и опасной.

Заложите метаданные как управляемые поля

На уровне шаблонов должны существовать:

• отдельный title;
• meta description;
• один управляемый H1;
• canonical;
• robots;
• Open Graph;
• данные для хлебных крошек;
• при необходимости — поля автора, даты и изображения статьи.

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

Проверьте, чтобы HTML корректно экранировал данные и не создавал два H1 или два canonical при подключении разных шаблонов.

Рендеринг и доступность содержимого

Поисковые системы умеют обрабатывать JavaScript, но это не причина прятать всю страницу до выполнения сложного клиентского приложения. Основной контент, ссылки и метаданные должны быть доступны стабильно.

Для проекта заранее определяют:

• серверный рендеринг, статическую генерацию или клиентское приложение;
• состояние страницы без JavaScript;
• поведение при ошибке API;
• индексацию параметров и пагинации;
• доступность ссылок как обычных <a href>;
• соответствие мобильного и десктопного контента;
• скорость появления главного содержимого.

Если используется React, Vue или Next.js, решение выбирают по задаче. SPA для кабинета и публичный каталог имеют разные требования к индексации и первому отображению.

Производительность начинается в макете

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

До вёрстки согласуйте:

• бюджет веса первого экрана;
• формат и размеры изображений;
• поведение видео;
• число начертаний шрифта;
• приоритет загрузки LCP-элемента;
• резервирование размеров медиа;
• ограничения на сторонние виджеты;
• упрощённое движение для prefers-reduced-motion.

Core Web Vitals — не отдельный плагин. Они являются результатом архитектуры, дизайна, фронтенда, сервера и контента.

Технические страницы и дубли

На этапе разработки перечислите всё, что система способна создать автоматически:

• поиск;
• теги;
• авторы;
• архивы дат;
• фильтры;
• сортировки;
• пагинация;
• UTM и служебные параметры;
• печатные версии;
• загрузочные файлы.

Для каждого типа нужен ответ: он индексируется, канонизируется, закрывается noindex, блокируется от обхода или вообще не генерируется.

Такой реестр предотвращает ситуацию, когда CMS незаметно создаёт тысячи комбинаций, а важные страницы получают меньше внимания робота.

Аналитика проектируется вместе с формами

Цель «отправка формы» недостаточна, если на сайте несколько сценариев.

До разработки определите события:

• открытие формы;
• успешная отправка;
• ошибка;
• клик по телефону;
• переход в мессенджер;
• скачивание документа;
• выбор тарифа;
• ключевые шаги калькулятора;
• источник и страница обращения.

Сразу решите, какие данные уходят в CRM и как исключить двойной учёт. После запуска будет проще проверить не только посещаемость, но и качество маршрута.

Нужен ли SEO-специалист на каждом созвоне

Нет. Но он должен участвовать в точках, где решение потом дорого менять:

1. исследование спроса и проектирование структуры;
2. согласование прототипов ключевых типов страниц;
3. техническое задание на URL, рендеринг и индексацию;
4. проверка тестовой версии;
5. миграция и запуск;
6. наблюдение после релиза.

Это дешевле, чем подключать специалиста после того, как дизайн, CMS и адреса уже зафиксированы.

Что должно остаться в документации

К запуску полезно иметь:

• карту страниц и интентов;
• правила URL;
• реестр индексируемых типов;
• карту редиректов;
• шаблоны метаданных и исключения;
• схему внутренней перелинковки;
• требования к изображениям и скорости;
• список событий аналитики;
• чек-лист приёмки.

Так SEO перестаёт быть набором устных пожеланий и становится частью продукта.

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

Источники и документы

1. Google Search Essentials
2. Google: основы JavaScript SEO
3. Google: mobile-first indexing
4. Google: перенос сайта с изменением URL
5. Google: canonical URLs
6. web.dev: Web Vitals
7. W3C WAI: планирование доступности