Сайт под ключ: что должно входить в услугу

Что скрывается за «сайтом под ключ» на самом деле

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

В нашей практике SEO-продвижения это особенно важно. Бывает, что новый сайт визуально полностью готов, но после запуска выясняется, что:

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

В результате бизнес получает новый дизайн, но одновременно создаёт проблемы для дальнейшего продвижения сайта. Поэтому ещё до подписания договора необходимо определить, что именно подрядчик понимает под «готовым сайтом».

Типовой состав проекта может включать:

• аналитику и проектирование;
• разработку структуры;
• прототипы;
• дизайн;
• адаптивную вёрстку;
• программирование;
• установку и настройку CMS;
• перенос или подготовку контента;
• интеграцию форм;
• подключение CRM;
• тестирование;
• базовую SEO-подготовку;
• настройку аналитики;
• размещение на основном домене;
• передачу доступов.

Для CMS могут использоваться WordPress, «1С-Битрикс» и другие платформы — выбор зависит от задач проекта. Базовая техническая подготовка также обычно включает HTTPS, корректное отображение на мобильных устройствах и настройку основных систем аналитики.

Если сайт планируется продвигать в поиске, мы рекомендуем ещё до запуска проверить:

• Title и Description важных индексируемых страниц;
• H1;
• человекопонятные URL;
• robots.txt;
• sitemap.xml;
• canonical;
• коды ответа;
• 404-страницу;
• внутренние ссылки;
• отсутствие случайного noindex;
• скорость и Core Web Vitals;
• доступность контента для поисковых роботов.

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

За что чаще всего просят доплатить

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

Отдельно могут рассчитываться:

• копирайтинг;
• SEO-тексты;
• фотосъёмка;
• видео;
• иллюстрации;
• сложная анимация;
• калькуляторы;
• конфигураторы;
• нестандартные фильтры;
• личные кабинеты;
• интеграции с внешними сервисами;
• CRM;
• телефония;
• онлайн-оплата;
• сквозная аналитика.

Отдельный вопрос — обучение сотрудников.

Одни подрядчики включают в проект:

• инструкцию по CMS;
• консультацию;
• запись экрана;
• обучение контент-менеджера.

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

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

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

Работу над коммерческим сайтом мы рекомендуем начинать не с цвета кнопок, а с аналитики и проектирования.

Необходимо определить:

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

Например, для интернет-магазина один из сценариев может выглядеть так:

Категория → фильтр → карточка товара → корзина → оформление → оплата.

Для сайта услуг:

Поисковый запрос → страница услуги → изучение условий → форма → заявка.

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

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

Помимо основных экранов желательно предусмотреть состояния:

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

Отдельно проектируется адаптация.

В 2026 году правильнее говорить не о дизайне строго для «трёх разрешений», а о корректном поведении интерфейса в согласованном диапазоне экранов. Google продолжает использовать мобильную версию содержания для индексирования и ранжирования и рекомендует responsive design как наиболее простой в поддержке подход. Поэтому на мобильной версии нельзя просто убрать половину важной информации ради компактности.

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

• тяжёлое фоновое видео без необходимости;
• несколько семейств шрифтов;
• десятки сторонних скриптов;
• изображения исходного размера по несколько мегабайт.

На этапе вёрстки проверяется не только визуальное совпадение с макетом, но и функциональность.
Вместо требования «сайт должен работать во всех старых браузерах» лучше заранее определить матрицу поддерживаемых браузеров и устройств на основании аудитории проекта. Поддерживать давно устаревшие версии браузеров без бизнес-причины обычно нецелесообразно. Исходные материалы также нужно обсудить заранее.

Если по договору заказчику передаются:

• Figma;
• исходный код;
• репозиторий;
• документация;
• файлы проекта,

это должно быть прямо зафиксировано.

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

Тестирование и запуск — отдельный этап, а не нажатие одной кнопки.
Перед публикацией необходимо проверить:

• основные пользовательские сценарии;
• мобильную версию;
• формы;
• оплату;
• интеграции;
• ссылки;
• 404;
• редиректы;
• мета-теги;
• robots.txt;
• Sitemap;
• canonical;
• аналитику;
• скорость;
• безопасность подключения.

Если сайт заменяет уже существующий ресурс, SEO-проверка становится ещё важнее.

При изменении адресов необходимо заранее составить соответствие: Старый URL → Новый URL.

Google рекомендует использовать постоянные серверные редиректы, например 301 или 308, обновлять внутренние ссылки, canonical и Sitemap и контролировать миграцию через Search Console. Просто удалить старые страницы и опубликовать новые адреса — плохой сценарий для проекта, который уже получает органический трафик.

Что вы должны получить на руки после запуска

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

В зависимости от выбранной технологии и условий договора это может включать:

• доступ к рабочим макетам;
• доступ к CMS;
• доступ к домену;
• доступ к хостингу;
• доступ к репозиторию;
• резервную копию;
• базу данных;
• доступ к аналитическим системам;
• доступ к Яндекс Вебмастеру;
• доступ к Google Search Console;
• доступ к CRM и другим интеграциям.

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

FTP и SSH могут понадобиться не каждому проекту. На управляемом хостинге или SaaS-платформе их может вообще не быть. Поэтому правильнее требовать не конкретный технический протокол, а достаточный уровень доступа для управления и переноса проекта в рамках выбранной технологии.

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

• где хранится база;
• как создаётся backup;
• как его восстановить;
• как часто выполняется резервное копирование.

Также стоит получить список всех внешних сервисов:

• CRM;
• телефония;
• email;
• рассылки;
• онлайн-касса;
• платёжный шлюз;
• коллтрекинг;
• аналитика;
• карты;
• captcha;
• CDN.

У компании должны быть административные доступы либо понятная процедура их получения.

Чек-лист для проверки подрядчика перед стартом

Что должно быть в договоре и смете

Одна из главных проблем договоров на разработку — слишком общие формулировки.

Например: «Разработать современный удобный сайт».

Проверить выполнение такого требования практически невозможно.

Намного лучше:

«Разработать корпоративный сайт из 20 шаблонов страниц с адаптивной версией, формой заявки, интеграцией с CRM и функциональностью согласно приложенному ТЗ».

До начала работ желательно зафиксировать:

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

Отдельно определяется график платежей.

Этапная оплата часто удобна обеим сторонам, например: старт → прототип → дизайн → разработка → запуск.

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

Вопрос прав на дизайн и программный код тоже необходимо фиксировать отдельно.
Нужно заранее определить:

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

Юридические формулировки по передаче исключительных прав лучше отдельно проверять с профильным специалистом.

То же относится к штрафам и ответственности за нарушение сроков. Нет универсальной «правильной» пени в 0,1%, 0,5% или 1%. Размер, основания и порядок её применения должны соответствовать договору и применимому законодательству.

Вопросы, которые стоит задать до подписания

До старта проекта стоит спросить подрядчика:

Что подразумевается под SEO-готовностью?

Ответ:

«Мы установим SEO-плагин»

недостаточен.

Базовая SEO-подготовка может включать:

• индексируемую структуру;
• корректные URL;
• управление Title и Description;
• H1;
• canonical;
• robots.txt;
• sitemap.xml;
• 404;
• редиректы;
• внутреннюю перелинковку;
• доступ поисковых роботов;
• скорость;
• мобильную версию.

Следующий вопрос:

Кто отвечает за структуру страниц и пользовательские сценарии?

Удержание посетителя на главной странице зависит не только от работы дизайнера. Здесь важны проектирование, содержание, оффер, структура и логика переходов.

Стоит узнать и то, на основании чего создаётся дизайн:

• исследования;
• аналитика;
• интервью;
• анализ конкурентов;
• существующие данные сайта;
• только пожелания заказчика.

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

Сравним основные подходы.

Важно: выбор технологии не определяется одним SEO.

Современная CMS не становится «тупиком» только потому, что она шаблонная. На WordPress, «1С-Битрикс» и других системах можно создавать крупные проекты с развитой SEO-структурой. И наоборот, индивидуальный код не гарантирует идеальной поисковой оптимизации. Если разработчики не предусмотрели управление метаданными, canonical, редиректами и другими техническими параметрами, работать с таким проектом может быть сложнее, чем с готовой CMS.

Выбор должен зависеть от:

• функциональности;
• нагрузки;
• интеграций;
• бюджета;
• внутренних ресурсов;
• требований к развитию.

Перед подписанием договора полезно запросить проекты, похожие не столько внешне, сколько по сложности задачи.

Скрытые работы, которые часто не входят в базовую цену

Низкая цена разработки сама по себе не означает проблему. Но её обязательно нужно сопоставлять с объёмом работ.

Часть подрядчиков выносит отдельно:

• тексты;
• фотографии;
• иллюстрации;
• SEO;
• аналитику;
• интеграции;
• загрузку каталога;
• наполнение;
• лицензии;
• платные модули;
• техническую поддержку.

Например, одна смета может включать: дизайн + вёрстку + программирование,

а другая: исследование + прототип + дизайн + разработку + контент + SEO-подготовку + аналитику + запуск.

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

Для SEO-проекта недостаточно поставить на сайт случайные тексты. Необходимо учитывать:

• поисковый спрос;
• интент;
• структуру страниц;
• характеристики продукта;
• вопросы аудитории;
• коммерческие факторы.

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

Ещё один блок — аналитика и SEO.

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

• какие цели отслеживаются;
• какие формы являются конверсионными;
• какие события передаются;
• куда поступают заявки;
• подключена ли Метрика;
• нужен ли GA4;
• подключены ли панели вебмастеров.

С технической точки зрения новый сайт также должен позволять управлять:

• мета-тегами;
• URL;
• canonical;
• редиректами;
• robots;
• Sitemap.

Если всё это оставляется «на потом», первые недели после запуска могут пройти без полноценного контроля трафика и конверсий.

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

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

За что чаще всего просят доплатить

• Копирайтинг. Тексты для главной, услуг, категорий и карточек.
• Индивидуальный дизайн. Особенно если изначально предложение рассчитывалось на готовый шаблон.
• Фотосъёмка и видео. Для продукции, сотрудников, производства, объектов или интерьеров.
• CRM и сквозная аналитика. Интеграция заявок с продажами.
• Расширенная SEO-проработка. Семантика, структура, контентные ТЗ, технический аудит.
• Перенос большого количества контента.
• Платные лицензии и модули.
• Обучение сотрудников.
• Расширенная техническая поддержка.

Главное правило здесь простое: заказчик должен видеть эти позиции до начала разработки, а не после того, как половина проекта уже выполнена.

Как понять, что сайт сделали хорошо: критерии приемки

Принимать сайт только по внешнему виду нельзя.
Мы рекомендуем проверять четыре направления:

1. пользовательский сценарий;
2. техническое состояние;
3. SEO;
4. передачу проекта.

Начните со скорости. PageSpeed Insights в 2026 году показывает два разных типа данных: реальные данные пользователей из CrUX, если их достаточно, и лабораторные показатели Lighthouse. Они могут отличаться, потому что измеряются в разных условиях.

Поэтому требование: «PageSpeed обязательно 80 баллов» само по себе недостаточно.
Lighthouse действительно считает 90–100 хорошей лабораторной оценкой производительности, но такой результат не гарантирует аналогичный опыт реальных пользователей.

Для SEO и пользовательского опыта мы прежде всего рекомендуем контролировать Core Web Vitals.
Google указывает следующие ориентиры:

• LCP — до 2,5 секунды;
• INP — менее 200 мс;
• CLS — менее 0,1.

Оценка проводится по 75-му перцентилю реальных загрузок. У нового сайта сразу после запуска может ещё не быть достаточного количества реальных данных CrUX. В таком случае используются лабораторные тесты, а показатели реальных пользователей контролируются после накопления статистики.

Важно также понимать: хорошие Core Web Vitals — не автоматическая гарантия высоких позиций. Google рекомендует оценивать качество пользовательского опыта комплексно, включая мобильную версию, безопасность, отсутствие навязчивых элементов и доступность основного контента.

Следующий этап — техническое сканирование.

С помощью Screaming Frog или аналогичного краулера можно проверить:

• битые ссылки;
• 404;
• цепочки редиректов;
• дубли Title;
• пропущенные H1;
• canonical;
• index/noindex;
• глубину вложенности;
• внутренние ссылки.

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

Отдельно тестируются формы.
Проверьте:

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

Если есть корзина:

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

Если есть фильтр или калькулятор — тестируйте не только обычный сценарий, но и пограничные значения.

SEO-приёмка должна включать:

• доступность сайта для роботов;
• отсутствие тестового noindex;
• корректный robots.txt;
• Sitemap;
• canonical;
• 404;
• редиректы;
• метатеги;
• внутренние ссылки;
• мобильную версию;
• Search Console;
• Яндекс Вебмастер.

Если редизайн заменяет старый сайт, отдельно проверяется миграция URL. Google рекомендует заранее составлять карту старых и новых адресов и использовать постоянные серверные редиректы вместо массового перенаправления удалённых страниц на главную.

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

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

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

Для нас «сайт под ключ» — это не просто момент, когда страницы открываются по адресу. Это проект, которым бизнес может пользоваться, управлять, анализировать и дальше развивать, в том числе с точки зрения SEO. Поэтому критерии приёмки мы рекомендуем определять ещё до старта разработки. Тогда и заказчик, и подрядчик заранее понимают, какой именно результат считается готовым сайтом.