Три сценария, в которых SEO нужно до запуска
Формально это одна услуга, но задачи в ней разные. От того, в каком вы сценарии, зависит и состав работ, и то, что считать результатом.
| Сценарий |
Главная задача |
Главный риск, если не делать |
| Новый сайт |
Заложить структуру под спрос и технические требования сразу |
Сайт запускается без страниц под часть спроса; перестройка после запуска |
| Редизайн существующего |
Сохранить то, что уже работает, и исправить то, что мешало |
Исчезают страницы и адреса, которые приносили трафик |
| Переезд на другую CMS или домен |
Перенести без разрывов: адреса, содержимое, разметку, настройки |
Потеря позиций из-за ненастроенных переадресаций |
Разница между первым сценарием и двумя остальными принципиальна. У нового сайта терять нечего — там задача построить. В редизайне и переезде есть накопленный результат, и главное — не разрушить его по дороге.
Почему это дешевле, чем исправлять после запуска
Аргумент об экономии звучит у всех, поэтому стоит объяснить, откуда она берётся конкретно.
До запуска решение стоит обсуждения и строки в техническом задании. После запуска то же решение — это уже:
- новое техническое задание и повторная работа разработчиков;
- перенос существующего контента в новую структуру;
- карта соответствий старых и новых адресов плюс настройка переадресаций;
- обновление внутренних ссылок по всему сайту;
- период, пока поисковая система переиндексирует изменения, — а на это время часть позиций просаживается.
Последний пункт не имеет денежного выражения, но для работающего бизнеса он обычно самый дорогой.
Что входит в работу
Семантика и структура
Сбор запросов в нише, группировка по намерениям, сравнение с тем, как устроены сайты конкурентов в выдаче. На выходе — перечень страниц, которые должен содержать сайт, с привязкой к группам запросов. Это основа будущей навигации, а не отдельный документ «для SEO».
Подробнее о самом процессе — в материале о семантическом ядре.
Логика URL-адресов
Правила формирования адресов для всех типов страниц: категорий, подкатегорий, карточек, фильтров, страниц пагинации. Здесь же решается, какие страницы фильтров вообще должны существовать как отдельные адреса, а какие — закрыты от индексации. Для интернет-магазина это один из самых дорогих пунктов, если его пропустить.
Техническое задание для разработчиков
Документ, по которому работает команда: требования к шаблонам, к формированию метаданных, к обработке ошибок, к переадресациям, к разметке. Пишется под конкретную платформу — то, что легко реализуется на одной CMS, на другой требует другого решения.
Шаблоны метаданных
Правила автоматического формирования Title и Description для типовых страниц, чтобы при запуске тысяча карточек не вышла с пустыми или одинаковыми метаданными. Для ключевых страниц метаданные пишутся вручную.
Скорость и Core Web Vitals
Требования к скорости закладываются в макет и вёрстку: вес изображений и их форматы, порядок загрузки, отложенные скрипты, стабильность макета при загрузке. После запуска часть этого приходится переделывать вместе с дизайном.
Структурированные данные
Разметка организации, товаров, услуг, хлебных крошек, отзывов — в зависимости от типа сайта. Закладывается в шаблоны, а не добавляется потом на каждую страницу отдельно.
Индексация и служебные настройки
robots.txt, карта сайта, канонические адреса, обработка дублей, языковые версии и их связи. Отдельно — закрытие тестовой среды от индексации: типичная и очень неприятная ситуация, когда в поиск попадает незапущенная версия сайта.
Аналитика с первого дня
Счётчики, цели и события настраиваются до запуска, а не через месяц после него. Иначе первый месяц жизни сайта — самый интересный для понимания поведения — просто не измерен.
Проверка перед публикацией
Сверка реализованного с техническим заданием: сканирование тестовой версии, проверка адресов, метаданных, разметки, скорости, переадресаций. Ошибка, найденная здесь, стоит исправления; та же ошибка, найденная через месяц после запуска, стоит ещё и потерянного времени.
Редизайн и переезд: как не потерять трафик
Это отдельный блок работ, и его логика отличается от работы с новым сайтом.
Фиксация того, что есть сейчас
Перед началом изменений снимается полная картина: все существующие адреса, их трафик и позиции, страницы с внешними ссылками, текущие метаданные. Без этого среза невозможно проверить, всё ли перенесено, — и невозможно понять, что именно сломалось, если трафик просядет.
Что сохраняем, а что меняем
Страницы, которые приносят трафик и имеют ссылки, сохраняются по возможности по тем же адресам. Переименовывать рабочий адрес ради красоты — самое дорогое из возможных решений. Меняется то, что не работало: дубли, пустые страницы, разделы под несуществующий спрос.
Карта переадресаций
Каждый старый адрес сопоставляется с новым. Страницы, у которых нет прямого соответствия, ведут на ближайший по смыслу раздел, а не на главную — массовая переадресация на главную воспринимается поисковой системой как ошибка.
Контроль после запуска
Первые недели после публикации — самые важные. Проверяются ошибки сканирования, скорость переиндексации, сохранение позиций по ключевым страницам. Часть проблем обнаруживается только на работающем сайте, и реагировать на них нужно сразу, а не по итогам месяца.
Форматы участия
Объём зависит от того, на каком этапе проект и кто его делает.
| Формат |
Когда подходит |
Что вы получаете |
| Техническое задание перед стартом |
Есть концепция или макеты, разработка ещё не началась |
Структура сайта, логика URL, требования к реализации — документ, по которому работает команда |
| Сопровождение разработки |
Проект в работе, нужен контроль по ходу |
Участие в постановке задач, ответы на вопросы команды, проверка реализации поэтапно |
| Проверка перед запуском |
Сайт почти готов, нужен взгляд со стороны до публикации |
Отчёт с ошибками по приоритетам и перечень того, что нужно исправить до запуска |
| Сопровождение редизайна или переезда |
Сайт работает, планируется смена дизайна, CMS или домена |
Срез текущего состояния, карта переадресаций, чек-лист запуска, контроль в первые недели |
Какой формат нужен именно вам, становится понятно после короткого разговора о проекте: размер сайта, платформа, стадия, кто выполняет разработку. Стоимость приведена на странице цен и зависит от объёма проекта.
Как мы работаем с командой разработки
Не имеет значения, кто делает сайт — мы, ваш внутренний отдел или сторонний подрядчик. Меняется только формат взаимодействия.
Если разработку ведём мы, SEO-специалист работает внутри проекта и задачи ставятся напрямую. Если разработчик сторонний — мы формулируем требования так, чтобы их можно было выполнить без дополнительных пояснений: с указанием типов страниц, примеров и ожидаемого результата, а не в формате общих пожеланий.
Отдельно важна работа с ограничениями платформы. Часть требований на конкретной CMS реализуется иначе, чем в учебнике, а часть не реализуется вообще. У нас есть опыт работы с WordPress, Shopify, Хорошоп, OpenCart и рядом других платформ, поэтому требования формулируются с учётом того, что реально можно сделать.
Подробнее о подходе — в нашей публикации на dev.ua.
Что отличает наш подход
Требования пишутся под платформу, а не вообще. Техническое задание, которое не учитывает возможностей CMS, возвращается разработчиком с вопросами — и этап начинается заново.
Реализацию проверяем мы. Передать требования и узнать о результате после запуска — самая распространённая схема и самая плохая. Проверка делается на тестовой среде, до публикации.
Прогнозных цифр до аудита не называем. Сколько трафика даст сайт после запуска, зависит от ниши, конкуренции и объёма дальнейшей работы. Показатели согласовываются после того, как собрана семантика и видна реальная картина спроса.
Мы говорим, когда делать не нужно. Если сайт небольшой, спрос в нише минимальный, а бюджет ограничен, отдельное сопровождение разработки может быть лишним — и об этом мы скажем прямо.
Как начать
Обратиться можно и с готовым техническим заданием, и с идеей будущего сайта.
- Короткая консультация-знакомство. Уточняем задачу, стадию проекта, платформу, размер сайта и кто ведёт разработку. Разбор сайта на этом этапе мы не делаем — это уже сама работа.
- Согласование формата и объёма. Из таблицы выше выбирается тот формат, который соответствует вашей ситуации, после чего фиксируются состав работ, сроки этапов и стоимость.
- Работа. Семантика, структура, техническое задание, сопровождение реализации — в зависимости от выбранного формата.
- Проверка перед публикацией. Сверка реализованного с требованиями и перечень того, что нужно исправить до запуска.
Если сайт уже работает и вопрос не в разработке, а в текущем состоянии, — начать логичнее с SEO-аудита. Если сайт уже запущен и нужно системное продвижение — это SEO-продвижение или разовая оптимизация сайта.
Примеры проектов, где разработка и поисковое продвижение велись вместе, собраны в кейсах по разработке и кейсах по SEO.
Частые вопросы
Можно ли подключить SEO, если разработка уже началась?
Да, и это распространённая ситуация. Чем раньше, тем лучше, но даже проверка перед запуском успевает снять большую часть технических проблем. Безнадёжный вариант только один — когда сайт уже опубликован и выяснилось, что структура не соответствует спросу.
Сколько времени это занимает?
Зависит от формата и размера сайта. Сбор семантики и формирование структуры для небольшого сайта — несколько дней, для крупного магазина — недели. Сопровождение разработки длится столько, сколько длится сама разработка. Сроки фиксируются после того, как понятен объём.
Обязательно ли делать сайт у вас?
Нет. Мы работаем и с вашим внутренним отделом, и со сторонним подрядчиком. В этом случае наша часть — требования и проверка реализации.
Что делать, если разработчик говорит, что требование невозможно реализовать?
Разбираться, в чём именно ограничение. Часть требований имеет альтернативные решения на той же платформе, часть действительно не реализуется — тогда ищется компромисс. Это нормальный рабочий этап, поэтому мы и формулируем требования с учётом конкретной CMS.
Можно ли сохранить позиции при полной смене дизайна?
Если адреса и контент сохраняются, а техническая часть не ухудшается — преимущественно да. Риск возникает там, где вместе с дизайном меняют структуру, адреса и тексты одновременно. Именно поэтому перед редизайном фиксируется текущее состояние, а изменения разносятся по приоритетам.
Нужен ли отдельный аудит перед редизайном?
Перед редизайном нужен срез текущего состояния — какие страницы приносят трафик, где внешние ссылки, что уже работает. Это меньше по объёму, чем полный аудит, и входит в формат сопровождения редизайна. Полный аудит нужен тогда, когда сайт остаётся как есть, а задача — понять, почему он не работает.
Когда будут первые результаты?
Новый сайт начинает индексироваться в течение нескольких недель после запуска, но позиции по конкурентным запросам накапливаются месяцами — это нормальный срок для любого нового ресурса. При редизайне и переезде результатом считается другое: сохранение текущих показателей, а не рост. Какие именно показатели отслеживаем, разобрано в материале о SEO-метриках.
