# Вёрстка сайта под ключ: что уточнить в составе работ

Что означает вёрстка под ключ в предложении исполнителя: код, CMS, подключения, публикация и передача — как проверить границы ответственности

Автор: Редакция KEIVO
Дата публикации: 2026-10-29
Обновлено: 2026-10-29
Канонический URL: https://keivo.ru/blog/verstka-sayta-pod-klyuch/

У «вёрстки под ключ» нет одного обязательного состава — до заказа нужно уточнить, получите ли вы код, установленную страницу или опубликованный сайт с проверенными подключениями



В предложении может быть одна короткая строка, а у участников — разные ожидания

Заказчик ждёт страницу на домене, дизайнер считает работу законченной после макетов, разработчик готовит архив с кодом — каждый может выполнить свою часть и всё равно не получить общий результат

Разберём, как расшифровать формулировку «под ключ» и распределить ответственность до начала работы

## Назовите конечный результат

Начните с того, что должно появиться у вас после завершения

Это может быть комплект вёрстки для своей команды, страница в действующей системе управления или работающая публичная версия

Ни один из вариантов не является плохим сам по себе — важно, чтобы предложение описывало именно тот, который нужен вам




| Результат | Что передаёт исполнитель | Что ещё может понадобиться |
|---|---|---|
| Комплект вёрстки | Исходники, ресурсы и согласованная сборка | Подключение к системе и публикация |
| Страница в действующей CMS | Реализованный шаблон и способ редактирования | Проверка внешних сервисов и рабочей среды |
| Опубликованная версия | Страница по публичному адресу и результаты проверок | Поддержка и дальнейшие изменения по отдельным условиям |




CMS — система, через которую сотрудники меняют содержание сайта

Если своей технической команды нет, выясните, кто возьмёт оставшиеся задачи — обещание «передадим готовый код» не назначает такого человека автоматически


![Генеративная иллюстрация адаптивного сайта: один интерфейс на ноутбуке, планшете и телефоне](/blog/_media/p1-20261029/a13-cover-813e2abd3364.webp)

Генеративная иллюстрация KEIVO — вымышленные интерфейсы, не клиентский проект



## Отделите интерфейс от обработки данных

В интерфейсе можно показать каталог, форму, оплату и личный кабинет — это ещё не означает, что системы за ними созданы и подключены

Для формы нужно определить получателя данных, обработку ошибки и способ проверки доставки

Для каталога — источник содержимого и обновления, для кабинета — правила доступа, для оплаты — выбранный сервис и ответственного за интеграцию

Внешний вид и поведение элементов обсуждаются вместе с этими зависимостями, но не заменяют их

Проверка полей в браузере не заменяет серверную — это отмечено в [руководстве MDN](https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Forms/Form_validation)

О составе самой услуги можно прочитать в [отдельном объяснении вёрстки](/blog/chto-vhodit-v-uslugu-verstki/)

## Что уточнить по содержанию

Зафиксируйте, кто предоставляет тексты, изображения, документы и данные каталога

Если работа начинается с примерного содержания, нужно предусмотреть проверку после заполнения — длинные названия и реальные абзацы могут изменить расположение блоков

Проверьте права на используемые материалы и условия выбранных платных сервисов

Укажите, кто в дальнейшем будет менять содержание и какой способ редактирования ему нужен — это помогает выбрать подходящий формат передачи

## Как описать обязанности без общих слов

Представим учебный заказ: сайт уже работает на CMS, новый макет страницы услуги готов, но форму нужно связать с существующей системой обращений

В проекте участвуют заказчик, верстальщик и разработчик действующего сайта — слова «всё под ключ» не объясняют, кто из них будет устанавливать шаблон

Вот как может выглядеть заполненный список ответственности для этой ситуации




| Работа | Исполнитель в примере | Что принимает заказчик |
|---|---|---|
| Финальные тексты и фотографии | Маркетолог заказчика | Одна папка материалов и утверждённый макет |
| Страница и мобильное меню | Верстальщик | Версия в браузере, в которой открываются меню и ответы на вопросы |
| Установка шаблона в CMS | Разработчик действующего сайта | Текст и изображение меняются через редактор без правки кода |
| Подключение формы | Тот же разработчик | Тестовое обращение появилось в выбранной системе, посетитель увидел подтверждение |
| Размещение на домене | Разработчик действующего сайта | Открывается нужный URL, работает скачивание, форма повторно проверена |
| Приёмка и замечания | Маркетолог заказчика | Общий список с проверенными исправлениями и оставшимися вопросами |


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

Проверка границы между двумя подрядчиками

Верстальщик передаёт шаблон разработчику CMS — попросите их заранее сверить формат компонентов, способ сборки и требования редактора на одном блоке, пока не собрана вся страница



Для своего проекта замените названия ролей конкретными участниками — если строка остаётся без исполнителя, сохраните её как открытый вопрос, а не как готовую часть заказа

Проверки доступности тоже стоит распределить: W3C рекомендует назначать ответственных и включать оценку в работу над сайтом в [руководстве по планированию](https://www.w3.org/WAI/planning-and-managing/)

## Почему запуск стоит выделить в отдельный пункт

Работающая тестовая версия не всегда означает готовность на основном домене

Могут отличаться пути к файлам, настройки HTTPS, доступность внешних сервисов и параметры аналитики

Перед размещением определите, кто сохраняет предыдущую версию, кто переключает сайт и кто проходит проверку уже после выпуска

Если меняются адреса существующих страниц, нужен отдельный план соответствий и перенаправлений — рекомендации Google приведены в [руководстве по смене URL](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes)

Для нового лендинга состав запуска разобран в [статье об оценке вёрстки лендинга](/blog/verstka-lendinga/)

## Что получить вместе с результатом

Следующий разработчик должен получить редактируемые файлы проекта, используемые изображения и шрифты, инструкцию запуска и перечень подключённых сервисов — например, редактор содержания и сервис получения обращений

Попросите принимающую команду открыть переданную версию по инструкции — если для запуска требуется неизвестный аккаунт или отсутствующий файл, передача ещё не завершена

У готовой сборки для размещения и исходников для изменений разные роли — оба комплекта должны относиться к одной принятой версии, иначе на домене окажется одно, а в работе у команды другое

Сотруднику, который будет менять содержание через редактор, предложите самостоятельно заменить текст на тестовой странице — так станет видно, хватает ли ему инструкции и прав

Аккаунты сервисов тоже требуют передачи: у заказчика должен остаться доступ, который позволит продолжить работу после ухода временного исполнителя

Не включайте пароли и токены в открытый бриф или публичную инструкцию

Зафиксируйте, как сообщать об ошибках, какие исправления входят в условия и как согласуются новые задачи — поддержка не становится бессрочной только из-за слов «под ключ»

## Самопроверка предложения

Отметьте, какие вопросы уже закрыты в обсуждении — список покажет, что ещё стоит уточнить




- [ ] Конечный результат назван однозначно


- [ ] Состав страниц и материалов понятен


- [ ] У подключений есть ответственные


- [ ] Понятно, кто выпускает сайт


- [ ] Передача и дальнейшие изменения описаны






Отметки помогают найти пробелы в договорённостях, но не подтверждают работоспособность сайта — для этого нужно пройти приёмку

## Как сравнить стоимость

Сопоставьте одинаковый результат: если один вариант заканчивается передачей кода, а другой включает установку и выпуск, итоговые суммы описывают разный объём

Добавьте работы вашей команды и необходимые внешние расходы, чтобы увидеть общий состав

Попросите перечислить предположения и неизвестные условия — подробнее этот подход разобран в [статье о стоимости вёрстки](/blog/stoimost-verstki-sayta/)

Порядок вопросов к исполнителю есть в [гайде о заказе по макету](/blog/kak-zakazat-verstku-po-maketu/)

## Что предлагает KEIVO

Основа [услуги вёрстки KEIVO](/services/verstka/) — реализация согласованного интерфейса по макету, адаптивы, состояния и проверка результата

Установку в CMS, обработку формы и подключение оплаты обсуждаем отдельно от реализации интерфейса

Можно [скачать бриф](/materials/brief-na-verstku.md) и отметить нужные части вашего проекта — приём заявок на новой странице пока не открыт

## Вопросы о формулировке «под ключ»


### Под ключ всегда означает публикацию на домене?

Это нужно проверить в составе предложения — формулировка сама по себе не определяет обязанности исполнителя и формат передачи



### Можно оставить подключения своей команде?

Да, если ответственные, формат передачи и проверка стыка между работами согласованы — важно, чтобы нужная часть не осталась без исполнителя



### Нужно ли включать всё в один заказ?

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



## Источники и границы

- [MDN — валидация формы](https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Forms/Form_validation)
- [W3C — планирование доступности](https://www.w3.org/WAI/planning-and-managing/)
- [Google — смена URL](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes)

Источники проверены 29 октября 2026 года — таблица ответственности и вопросы подготовлены редакцией KEIVO
