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

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

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

Почему SEO нужно учитывать до запуска сайта

Типичный сценарий знаком многим. Компания заказывает сайт, дизайнер рисует макеты, разработчики верстают страницы, тексты вставляют ближе к запуску. Потом кто-то вспоминает: «А SEO у нас будет?»

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

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

SEO после запуска часто превращается не в продвижение, а в ремонт.

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

Упрощённо это выглядит так:

структура → URL → шаблоны → индексация → скорость → редиректы → аналитика

Когда эта основа продумана заранее, сайт легче развивать. Можно добавлять новые услуги, публиковать статьи, расширять разделы, запускать рекламу, отслеживать заявки и не ломать всё при каждом изменении.

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

Структура сайта: какие страницы нужны для поиска

Поисковый трафик приходит не «на сайт вообще». Он приходит на конкретные страницы.

Человек ищет услугу, цену, инструкцию, сравнение, кейс, отзыв или ответ на вопрос. Если под этот запрос нет подходящей страницы, сайту нечего показывать в поиске.

Главная страница не должна отвечать за всё сразу. Она может объяснять, кто вы, чем занимаетесь и куда идти дальше. Но она не может одинаково хорошо закрывать запросы «разработка сайта под ключ», «SEO-аудит сайта», «создание CRM», «AI-бот для бизнеса», «стоимость сайта» и «как выбрать CMS».

Когда всё пытаются сложить на главную, она превращается в вокзал. Люди вроде приходят, но непонятно, куда ехать.

Для SEO нужна структура: отдельные страницы услуг, подуслуг, направлений, кейсов, статей, FAQ и контактов. Не всегда нужен огромный сайт. Но важные коммерческие и информационные задачи должны иметь свои страницы.

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

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

Семантика и интент: почему нельзя проектировать страницы вслепую

Семантика — это не таблица ключевых слов ради таблицы. Это понимание, какие задачи люди приносят в поиск.

Важно не только слово, но и намерение пользователя. В SEO это называют интентом.

Например, запрос «как выбрать CRM» чаще информационный. Человек хочет разобраться, сравнить варианты, понять критерии выбора. Ему нужна статья или экспертный материал.

Запрос «разработка CRM под заказ» уже коммерческий. Человек ближе к покупке. Ему нужна страница услуги: что входит в разработку, какие этапы, сроки, примеры, как оставить заявку.

Запрос «CRM для логистической компании» ещё конкретнее. Здесь может понадобиться отраслевая посадочная страница или кейс, где показано решение для логистики.

Если под все три запроса сделать одну страницу «CRM-системы», она будет слишком общей. Информационный запрос не получит нормального ответа. Коммерческий — не увидит конкретного предложения. Отраслевой — не узнает свою ситуацию.

Так сайт теряет и поисковую релевантность, и заявки.

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

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

CMS и SEO-поля: чем должен управлять редактор

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

Если для изменения Title, Description, H1 или адреса страницы нужно писать программисту, сайт будет развиваться медленно. SEO-специалист будет не продвигать, а ждать. Редактор будет не публиковать, а согласовывать. Бизнес будет платить за простые вещи дважды: сначала за разработку, потом за исправление того, что забыли предусмотреть.

CMS должна быть не просто админкой для текста. Она должна быть инструментом роста сайта: позволять создавать новые страницы услуг, публиковать статьи, добавлять кейсы, FAQ, блоки перелинковки, управлять шаблонами и SEO-настройками.

У каждой важной страницы должны быть SEO-поля. У шаблонных страниц должны быть понятные правила: где задаётся H1, как формируется Title, можно ли редактировать Description, что попадает в sitemap, какие страницы открыты для индексации.

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

Индексация: какие страницы поисковик должен видеть, а какие нет

• Индексация — это вопрос простого здравого смысла: поисковик должен видеть важные страницы и не должен видеть мусор.
• Важные страницы — это главная, услуги, подуслуги, статьи, кейсы, контакты, коммерческие посадочные и другие материалы, которые должны появляться в поиске.
• Мусор — это тестовые страницы, черновики, служебные URL, страницы с техническими параметрами, результаты внутреннего поиска, дубли, временные разделы и всё, что не должно попадать в выдачу.

Для управления этим есть технические инструменты. Robots.txt помогает управлять обходом сайта. Sitemap.xml показывает поисковику важные страницы. Canonical указывает основную версию страницы, если есть похожие или дублирующиеся варианты. Noindex закрывает страницы, которые не должны попадать в поиск.

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

Например, на тестовом сайте закрыли всё от индексации, потом перенесли настройку на боевой сайт и забыли открыть нужные страницы. Или наоборот: служебные страницы, фильтры и дубли случайно попали в индекс.

В одном случае поисковик не видит то, что должен видеть. В другом — видит то, что лучше бы не видел.

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

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

Скорость сайта: почему тяжёлый сайт мешает SEO и заявкам

Медленный сайт теряет людей ещё до того, как они увидели ваше предложение.

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

И это не каприз. На мобильном интернете терпение короткое. Особенно если человек выбирает услугу, сравнивает подрядчиков или просто хочет быстро понять стоимость.

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

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

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

Здесь не нужно превращать владельца бизнеса в инженера по производительности. Но требование к скорости должно быть в проекте с самого начала.

Медленный сайт может быть красивым. Просто его не дождутся.

Редиректы при редизайне: как не потерять старые страницы

1. Редизайн сайта — один из моментов, где SEO можно сломать особенно быстро.
   Старый сайт уже мог получать трафик из поиска. Какие-то страницы могли быть в индексе, иметь внешние ссылки, приводить заявки, собирать брендовые переходы или держать позиции по важным запросам.
2. Старые URL — это не мусор. Это накопленный актив. Там могут быть позиции, ссылки, переходы и заявки.
3. Потом запускают новый сайт. Структуру меняют. URL меняют. Старые страницы удаляют. Редиректы не настраивают. Поисковик и пользователи получают 404.
   Снаружи — красивый новый сайт. Внутри — потерянные адреса и просевший трафик.
4. Перед редизайном нужно снять текущую SEO-картину: какие страницы дают трафик, какие получают заявки, какие имеют внешние ссылки, какие URL уже индексируются. После этого нужно составить карту старых и новых адресов.

Простой пример:

старый URL: /services/site-development/

новый URL: /razrabotka-saitov/

Если страницу просто удалить, поисковик увидит ошибку. Если настроить 301-редирект со старого адреса на новый, переход будет корректным.

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

Редиректы обязательны при смене CMS, домена, структуры разделов, адресов услуг, протокола, вложенности страниц или объединении материалов.

После запуска нужно проверить 404-ошибки, редиректы, sitemap и индексацию. Запустить новый сайт и не проверить старые URL — это как переехать в новый офис и не оставить новый адрес клиентам.

Микроразметка: что лучше предусмотреть сразу

Микроразметка — не волшебная кнопка SEO.

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

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

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

Лучше закладывать это на этапе разработки, потому что микроразметка хорошо работает в шаблонах. Если есть шаблон статьи, можно сразу предусмотреть корректную разметку Article. Если есть хлебные крошки — BreadcrumbList. Если есть FAQ-блок — соответствующую разметку, если она действительно подходит по формату.

Главное — не делать микроразметку «чтобы было». Ошибочная или натянутая разметка не помогает. Она создаёт ещё один технический долг.

Аналитика и цели: что настроить до публикации

Сайт нельзя запускать вслепую.

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

Трафик без целей показывает посещения, но не показывает результат.

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

Иначе получится красивая иллюзия контроля. Почти как весы без батареек.

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

Без этого после запуска снова начнётся клуб ощущений.

«SEO не работает». «Реклама не работает». «Сайт не работает».

А может, работает. Просто никто не настроил цели, и результат не видно.

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

Когда нужен SEO-специалист до разработки, а не после

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

Но если сайт должен расти из поиска, SEO нужно подключать до разработки.

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

SEO-специалист на старте помогает не «продвинуть макет». Он помогает не заложить ошибки в фундамент.

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

Чем сложнее сайт и чем важнее поисковый трафик, тем раньше SEO должно появиться в проекте.

Иначе после запуска бизнес платит дважды: сначала за сайт, потом за исправление сайта.

SEO-чек-лист перед запуском сайта

Перед публикацией сайта стоит пройти короткую проверку.

• Структура и страницы. Есть ли отдельные страницы под важные услуги, направления, кейсы, статьи и коммерческие интенты? Не пытается ли главная страница закрыть всё сразу?
• URL и навигация. Понятны ли адреса страниц? Есть ли логичная структура разделов, хлебные крошки и внутренние ссылки между важными страницами?
• CMS и мета-данные. Можно ли управлять Title, Description, H1, slug, canonical, meta robots, Open Graph и SEO-полями без обращения к разработчику?
• Индексация. Проверены ли robots.txt, sitemap.xml, canonical, noindex, дубли, служебные страницы, тестовые URL и важные посадочные?
• Скорость. Оптимизированы ли изображения, скрипты, шрифты, мобильная загрузка, хостинг и тяжёлые виджеты?
• Редиректы. Если это редизайн или переезд, есть ли карта старых и новых URL, настроены ли 301-редиректы, проверены ли 404-ошибки?
• Микроразметка. Предусмотрена ли разметка организации, хлебных крошек, статей, FAQ и других подходящих блоков?
• Аналитика. Настроены ли Метрика или другая аналитика, цели, события, формы, клики по телефону, мессенджерам, CTA, UTM и передача заявок в CRM?