Как принять сайт у подрядчика: чек-лист

Коротко. Как проверить сайт после разработчика: до подписания акта убедитесь, что у компании есть все доступы, исходный код и права на него, домен оформлен на вас, хостинг и резервные копии под вашим контролем, базовое SEO не сломано, сайт выполняет требования закона 99-З о персональных данных, а защита закрывает типовые уязвимости. Внешний вид и работа форм — только часть приёмки. Главный риск другой: сайт выглядит готовым, но домен записан на подрядчика, доступ к серверу есть только у него, а резервных копий нет. Ниже — чек-лист из 25 пунктов, порядок приёмки и что делать, если нашлись недочёты.

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

Почему приёмка — это не только «посмотреть, как выглядит»

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

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

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

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

Попросите подрядчика собрать всё в одном документе заранее — до даты приёмки.

Как проверить сайт после разработчика: чек-лист из 25 пунктов

Доступы

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

Код и права

• 5. Исходный код лежит в репозитории, владельцем которого является компания, последняя версия совпадает с работающим сайтом.
• 6. В договоре или акте прямо указана передача исключительных прав на код, дизайн и материалы сайта.
• 7. Есть список сторонних компонентов, платных тем, плагинов и шрифтов с лицензиями, оформленными на компанию.
• 8. Есть документация: как развернуть сайт, где настройки, как обновлять систему управления и компоненты.

Домен

• 9. Администратором домена у регистратора указана ваша организация.
• 10. Известны дата окончания регистрации и порядок продления, настроено автопродление или напоминание ответственному.

Хостинг

• 11. Договор с хостинг-провайдером или облаком заключён от имени компании и оплачивается компанией.
• 12. Работают HTTPS-сертификат и автоматическое продление, все версии адреса (с www и без, http) перенаправляют на одну основную.
• 13. Тестовая версия сайта закрыта паролем или от индексации, режим отладки на рабочем сайте выключен.

Резервные копии

• 14. Настроено автоматическое резервное копирование файлов и базы данных, копии хранятся отдельно от сервера сайта — по принципам правила 3-2-1.
• 15. При вас выполнено пробное восстановление из резервной копии, и сайт после него работает.

SEO

• 16. Сайт открыт для индексации: нет запрета в robots.txt и метатега noindex на рабочих страницах.
• 17. У страниц уникальные title, description и один заголовок H1, есть карта сайта sitemap.xml.
• 18. При переезде или редизайне старые адреса страниц перенаправлены на новые постоянным редиректом 301, битых ссылок нет.
• 19. Установлены счётчики аналитики, подключены инструменты для вебмастеров, сайт быстро загружается на мобильных устройствах.

Закон 99-З

• 20. Опубликована политика обработки персональных данных, ссылка на неё есть рядом с каждой формой.
• 21. Формы собирают только нужные данные, согласие получается отдельно и фиксируется.
• 22. Cookie-баннер соответствует рекомендациям НЦЗПД: необходимые cookie работают без согласия, аналитические и рекламные — только после явного согласия, кнопки «Принять» и «Отклонить» равнозначны, есть «Настройки cookie» и отдельная политика cookie.

Безопасность

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

Подробнее о требованиях к формам и политике — в статье о законе 99-З для сайта, о баннере — в разборе cookie-баннера в Беларуси.

Порядок приёмки: как не пропустить важное

1. За неделю до приёмки отправьте подрядчику чек-лист и попросите подготовить пакет передачи.
2. Проверьте владение (пункты 1–11) — это нельзя откладывать: пока доступы у подрядчика, остальные исправления зависят от него.
3. Проверьте работу на реальных сценариях: отправьте все формы, оформите заказ, пройдите путь клиента с телефона.
4. Проверьте восстановление из резервной копии — вместе с подрядчиком, при вас.
5. Проверьте SEO, 99-З и безопасность (пункты 16–25) самостоятельно или с независимым специалистом.
6. Зафиксируйте замечания письменно, со скриншотами и сроком исправления.
7. Подпишите акт после исправлений или с перечнем оставшихся замечаний и сроками.

Если нашли недочёты

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

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

Типичные проблемы, которые всплывают при приёмке

• Домен или хостинг оформлены на подрядчика «для удобства». Технически сайт работает, но при конфликте или смене подрядчика вы не можете ни продлить домен, ни перенести сайт.
• Резервные копии хранятся на том же сервере. При сбое диска или взломе пропадают и сайт, и копии.
• Рабочий сайт закрыт от индексации. Запрет, поставленный на время разработки, забыли снять — сайт не появляется в поиске неделями.
• Тестовые данные и учётные записи остались на рабочем сайте. Пароли вида «admin/admin» и демо-пользователи — один из самых простых путей к взлому.
• Персональные данные из форм уходят на личную почту разработчика или в сторонний сервис без политики и согласий.

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

Частые вопросы

Как проверить сайт после разработчика, если в компании нет программиста?

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

Что обязательно должен передать разработчик сайта?

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

Можно ли подписать акт, если есть замечания?

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

Зачем проверять восстановление из резервной копии при приёмке?

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

Сколько стоит независимая проверка сайта перед приёмкой?

Зависит от размера сайта, наличия личных кабинетов, платежей и интеграций. У Viviar есть пакет «Цифровой Минимум» от 1 700 BYN: проверка по закону 99-З, сканирование уязвимостей и список приоритетов. Глубокий аудит защищённости одного продукта с разбором кода входит в пакет «Запуск безопасной разработки» от 20 300 BYN.

Вывод

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

Источники: OWASP Top 10 (owasp.org); Закон Республики Беларусь от 07.05.2021 № 99-З «О защите персональных данных» (pravo.by); рекомендации НЦЗПД по использованию cookie (cpd.by); Google Search Central — документация по индексации, robots.txt, sitemap и редиректам (developers.google.com); цены — публичные пакеты Viviar, /pricing, действуют с 01.09.2026.