Разработка сайта и SEO: что заложить до запуска

SEO-подготовка начинается ещё до дизайна и публикации. До разработки нужно определить поисковые интенты, архитектуру, правила URL, шаблоны метаданных, canonical, sitemap, внутренние ссылки, требования к скорости и план миграции. После запуска остаются контент, анализ спроса и улучшения — техническая подготовка не гарантирует позиции, но позволяет поисковым системам корректно обходить и понимать сайт.

Самая дорогая SEO-ошибка — сначала собрать страницы по внутренней структуре компании, а потом пытаться наложить на них реальный спрос. Вторая — менять адреса без карты редиректов. Третья — генерировать тысячи фильтров и дублей, которые конкурируют с каноническими страницами.

Содержание

• как связать семантику и архитектуру;
• какие правила URL определить заранее;
• как настроить canonical и sitemap;
• что влияет на скорость и доступность;
• как встроить аналитику;
• как перенести старый сайт;
• что проверить до и после запуска.

SEO — часть продуктового проектирования

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

Интенты удобно разделить:

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

Один URL получает один главный интент. На одной странице могут быть связанные вопросы, но два материала не должны одинаково конкурировать за одну формулировку. Например, хаб разработки объясняет форматы и ведёт к заявке, статья о цене раскрывает смету, а материал о выборе подрядчика — договор и приёмку.

Семантика превращается в карту страниц

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

• Запрос «заказать разработку». Подходящий формат — коммерческий хаб. Такая страница помогает сравнить формат и отправить вводные.
• Запрос «сколько стоит сайт». Подходящий формат — статья/гайд. Такая страница помогает понять состав сметы.
• Запрос «корпоративный сайт». Подходящий формат — услуга или кластер. Такая страница помогает оценить структуру и процесс.
• Запрос «исправить ошибку». Подходящий формат — сервисная страница. Такая страница помогает описать проблему и получить диагностику.
• Запрос «изучить реализованный проект». Подходящий формат — кейс. Такая страница помогает проверить опыт и подход.

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

Перелинковка следует смыслу. Статья ведёт на релевантную услугу и соседний материал, услуга — на доказательный кейс и полезный гайд. Анкор объясняет назначение ссылки вместо универсального «подробнее».

Правила URL

Адреса определяют до наполнения, потому что после индексации их изменение требует миграции.

Практичные правила:

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

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

Title, description и заголовки

У каждой индексируемой страницы нужны уникальный title, описание и H1. Они решают разные задачи:

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

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

Не нужно перечислять все запросы через запятую. Заголовок, который трудно прочитать человеку, не становится качественнее от плотности ключевых слов.

Canonical: какой URL считать основным

Canonical сообщает предпочтительный адрес среди доступных вариантов. Он должен указывать на индексируемую страницу с успешным ответом и совпадать с внутренними ссылками и sitemap.

Self-canonical полезен для обычных страниц: он фиксирует основной URL даже при попадании параметров. Но canonical не является заменой редиректу и не гарантирует, что поисковая система согласится с ошибочным выбором.

Типовые ошибки:

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

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

Sitemap и robots

XML sitemap — список канонических URL, которые сайт предлагает для обхода. В него не включают редиректы, ошибки, закрытые, неканонические и служебные страницы. lastmod должен меняться при содержательном обновлении, а не при каждой сборке.

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

robots.txt управляет обходом, а не удалением уже известного URL из индекса. Закрывать параметр после масштабной генерации дублей поздно: лучше не публиковать ненужные ссылки и определить канонизацию на уровне архитектуры.

Структурированные данные

JSON-LD описывает сущности страницы в машиночитаемом виде. Разметка должна соответствовать видимому содержимому. Нельзя добавлять рейтинг, цену или FAQ, которых пользователь не видит либо которые не подтверждены.

Для проекта заранее определяют единый источник разметки. Если CMS, плагин и frontend одновременно создают Article или BreadcrumbList, появляются дубли и расхождения. Лучше один контракт, который формирует данные из фактических полей страницы.

После изменения шаблонов проверяют итоговый HTML, а не только объект в коде.

Скорость и Core Web Vitals

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

До реализации задают бюджет:

• формат и максимальный размер cover-изображений;
• правила responsive images;
• ограниченный набор начертаний шрифта;
• отложенная загрузка некритичных виджетов;
• размеры для медиа и динамических блоков;
• кэширование и стратегия обновления;
• мониторинг реальных ошибок и производительности.

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

Мобильная версия и доступность

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

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

Аналитика до публикации

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

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

События называют стабильно и документируют. Персональные данные, текст сообщения, телефон и email в параметры аналитики не передают.

Важный контур — проверка фактической доставки обращения. Цель form_success подтверждает ответ приложения, но не гарантирует, что уведомление дошло и менеджер его увидел. Для этого нужен отдельный операционный контроль.

Миграция старого сайта

Перенос начинается с инвентаризации, а не с отключения старой CMS. Собирают:

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

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

До переключения редиректы тестируют на копии списка. После запуска повторяют обход, проверяют sitemap, canonical, ошибки сервера и поисковые панели. Старый хостинг не отключают, пока правила перенаправления зависят от него и не перенесены.

Цена разработки с SEO-подготовкой

Публичные базовые форматы Za IT: лендинг — 4 999 ₽, корпоративный сайт — 19 999 ₽, интернет-магазин — 29 999 ₽. В них входит базовая SEO-подготовка соответствующего формата, но не регулярное продвижение, сбор большого семантического ядра и выпуск контента.

Отдельно оцениваются:

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

Если нужна диагностика действующего проекта, публичная цена аудита сайта — 4 999 ₽. Дальнейшая работа оценивается по найденным проблемам, а не обещанию «вывести в топ».

Этапы SEO-ready разработки

• Исследование. Результат этапа — карта интентов и ограничений.
• Архитектура. Результат этапа — дерево страниц и внутренние связи.
• Контракт URL. Результат этапа — slug, canonical, параметры, статусы.
• Прототип. Результат этапа — содержание и иерархия каждой страницы.
• Реализация. Результат этапа — метаданные, sitemap, JSON-LD, производительность.
• Миграция. Результат этапа — карта редиректов и перенос контента.
• Проверка. Результат этапа — обход, HTML, аналитика, мобильная версия.
• Наблюдение. Результат этапа — ошибки, индексация и приоритеты улучшений.

На каждом этапе есть артефакт, который можно проверить. Формулировка «SEO будет потом» заменяется конкретным контрактом до начала разработки.

Чек-лист перед запуском

1. Каждый целевой интент имеет один основной URL.
2. Title, description и H1 уникальны и соответствуют содержимому.
3. Self-canonical ведёт на успешный основной адрес.
4. Sitemap содержит только канонические индексируемые страницы.
5. Внутренние ссылки не ведут через редиректы.
6. Удалённые и перенесённые URL имеют решение.
7. Основной контент доступен на мобильном устройстве.
8. Изображения оптимизированы и не сдвигают раскладку.
9. JSON-LD не дублируется и соответствует видимым данным.
10. Аналитика фиксирует полезные события без персональных данных.
11. Production не закрыт случайным noindex или защитой тестового стенда.
12. После публикации назначен ответственный за контроль ошибок.

Практический сценарий

Компания заменяет корпоративный сайт и одновременно хочет расширить раздел услуг. До макетов существующие URL собираются в таблицу, запросы группируются по четырём направлениям, а дубли объединяются. Для каждой страницы определяется задача, H1 и связанный кейс.

Новые адреса сохраняют прежние там, где смысл не меняется. Для остальных готовится точная карта 301-редиректов. Шаблон статьи получает CMS-поля для метаданных, self-canonical и единый frontend JSON-LD. Sitemap использует дату реального обновления. Перед переключением команда обходит стенд, затем повторяет проверку на production и отслеживает ошибки. Такой процесс не обещает позиции, но сохраняет управляемость миграции.

Следующий шаг

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

Техническая реализация сложных сценариев описана в услуге разработки веб-приложений. Пример проекта с большим контентным контуром — кейс myapsny, а соседний материал поможет выбрать формат сайта для бизнеса.