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

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

Короткий контрольный список перед финальной приемкой

• Сверьте состав работ с договором и техническое задание на приемку сайта: что считается "сделано", а что - "хотелки".
• Получите все доступы (CMS/админка, хостинг, домен/DNS, аналитика, почта, репозиторий) и проверьте, что они принадлежат вашей компании.
• Проведите проверка качества сайта перед запуском по критичным сценариям (лиды/оплата/регистрация) и зафиксируйте результаты.
• Проверьте безопасность: HTTPS, роли, резервные копии, отсутствие тестовых входов и "забытых" страниц.
• Проверьте производительность и устойчивость: кэш, логи, мониторинг, лимиты хостинга.
• Закройте блок контента и SEO: индексация, мета‑данные, редиректы, карта сайта, robots.txt.

Подготовка документов, окружения и прав доступа

Раздел подходит, если вы принимаете новый сайт/редизайн/миграцию и хотите формально закрыть работы. Не стоит начинать приемку, если нет зафиксированного объема работ (ТЗ/спецификация), нет тестового контура или подрядчик еще "пилит на проде" без фиксации релизов.

1. Соберите пакет приемки. Должны быть: договор/приложения, актуальное ТЗ, список страниц/функций, макеты/прототипы, регламент поддержки. В идеале - отдельное техническое задание на приемку сайта с критериями "принято/не принято".
2. Разведите окружения. Попросите три адреса/режима: dev/stage/prod. Для stage используйте базовую авторизацию или ограничение по IP и запрет индексации.
3. Зафиксируйте права собственности. Домен зарегистрирован на вашу организацию, доступ к DNS у вас, SSL выпущен на ваш домен, аккаунты аналитики/почты - ваши (не личные подрядчика).
4. Проверьте доступы и роли. Минимум: админ CMS, редактор, доступ к хостингу/панели, доступ к базе (по необходимости), доступ к репозиторию (Git) и к системе задач. У подрядчика - отдельные учетные записи, без "общего admin/admin".
5. Подготовьте фиксацию результатов. Заведите шаблон отчета/таблицу дефектов: шаги воспроизведения, ожидаемое/фактическое, приоритет (P0-P3), ссылка на страницу, скрин/видео.

Функциональные проверки: сценарии и приоритеты

Что понадобится: тестовые учетные записи (клиент/менеджер/админ), доступ в админку CMS, доступ к платежному/CRM (если есть), тестовый номер/почта для уведомлений, список бизнес‑сценариев, а также браузеры Chrome/Firefox/Safari/Edge и мобильный девайс.

1. Определите P0‑сценарии. Обычно это: отправка заявки/покупка/оплата, регистрация/вход, оформление заказа, отправка форм, загрузка файлов, ключевые интеграции (CRM, платежи, доставка).
2. Прогоните сценарии "от входа до результата". Для каждой цепочки фиксируйте: URL, входные данные, ожидаемое сообщение, письма/вебхуки/запись в CRM. Пример: "Форма на /contacts/ → письмо на support@... → лид в CRM с UTM".
3. Проверьте валидации и крайние случаи. Пустые поля, неверный email, длинные значения, спецсимволы, повторная отправка формы, двойной клик по оплате, обновление страницы после отправки.
4. Проверьте админ‑процессы. Создание/редактирование страниц, загрузка изображений, публикация/черновик, права редактора, история изменений (если заявлено), поиск по контенту.
5. Зафиксируйте критерии приемки. Используйте формулировки "считается принятым, если...": например, "после отправки формы пользователь видит страницу thank‑you, письмо приходит в течение разумного времени, в CRM создается сущность с источником".

Сводная таблица‑чек‑лист для приемки (заполните статусами)

Пункт	Критерий приема	Статус	Примечания
Доступы и владение	Домен/DNS/хостинг/CMS/аналитика оформлены на заказчика, у подрядчика отдельные учетки	Не проверено
P0‑сценарии	Все критичные сценарии выполняются без ошибок, результаты фиксируются (письма/CRM/платеж)	Не проверено
Формы и уведомления	Валидации корректны, нет дублей, письма не попадают в спам по очевидным причинам (нет From: noreply@чужой-домен)	Не проверено
HTTPS и сертификат	Открытие по https://, редирект с http://, нет смешанного контента, корректная цепочка сертификатов	Не проверено
Роли и права	Редактор не видит системные настройки, админ защищен, тестовые логины удалены	Не проверено
Резервные копии	Есть регулярные бэкапы файлов и БД, понятна процедура восстановления	Не проверено
SEO‑база	robots.txt и sitemap.xml корректны, каноникалы, мета‑теги, редиректы при смене URL	Не проверено
Кроссбраузерность	Критичные страницы корректны в актуальных браузерах и на мобильных, нет "ломающихся" блоков	Не проверено
Логи и мониторинг	Включены логи ошибок, настроены алерты/метрики, понятны контакты для инцидентов	Не проверено

Безопасность: авторизация, сертификаты и уязвимости

Мини‑чек‑лист подготовки перед проверками безопасности

• Работайте в тестовом окружении или в "тихое время", чтобы не мешать реальным пользователям.
• Используйте отдельные тестовые аккаунты с минимальными правами; не делитесь главным админом.
• Зафиксируйте список публичных URL и точек входа: /admin, /login, /api, формы, загрузка файлов.
• Подготовьте доступ к логам (хостинг/приложение) или договоритесь, кто смотрит логи на стороне подрядчика.
• Делайте только безопасные проверки: без агрессивного сканирования, без попыток "положить" сайт.

1. Проверьте принудительный HTTPS и редиректы.
   Откройте http://ваш-домен и убедитесь, что происходит редирект на https://ваш-домен. На ключевых страницах в консоли браузера не должно быть ошибок Mixed Content.
   • Критерий: сайт доступен по HTTPS, HTTP не используется для контента/скриптов/картинок.
   • Критерий: единый "канонический" домен (с www или без) с 301‑редиректом на выбранный вариант.
2. Проверьте закрытие админки и контроль сессий.
   Админ‑панель не должна быть доступна по дефолтным путям без защиты (хотя бы по сильным паролям и ограничению попыток). После выхода сессия должна завершаться, а доступ к закрытым страницам - требовать повторного входа.
   • Критерий: нет логинов вида admin/admin, нет тестовых учеток, нет общих паролей "на всех".
   • Критерий: включены ограничения на брутфорс (лимит попыток/капча/блокировка по IP - как минимум что-то одно).
3. Проверьте права ролей (минимально необходимый доступ).
   Войдите как "редактор" и попытайтесь: изменить пользователей, права, шаблоны, настройки платежей/интеграций. Эти действия должны быть запрещены, если не предусмотрены ролью.
   • Критерий: роли соответствуют матрице доступа из ТЗ/спецификации.
4. Проверьте обработку ошибок и утечки данных.
   На несуществующих URL должна быть аккуратная 404, без трассировок и дампов. Ошибки формы не должны показывать внутренние пути, SQL‑ошибки или ключи.
   • Критерий: в публичном интерфейсе нет stack trace, debug‑панелей, "тестовых" страниц.
5. Проверьте загрузку файлов и ограничения.
   Если есть загрузка (резюме, изображения, документы), убедитесь, что принимаются только допустимые типы и размеры, файлы не исполняются как скрипты, а ссылки на приватные файлы не открываются без авторизации (если это требование).
   • Критерий: типы файлов ограничены, имя файла санитизируется, скачивание приватных файлов контролируется правами.

Если вам нужен независимый взгляд или формальная бумага для руководства, заранее согласуйте формат: внутренний чек‑лист или внешний аудит; запрос "аудит сайта перед запуском цена" корректнее формулировать как "что входит, какой объем страниц/сценариев, какие артефакты на выходе".

Производительность, мониторинг и требования хостинга

• Проверьте кэширование: повторная загрузка страниц должна отдавать статические ресурсы из кэша браузера (смотрите Network в DevTools), а серверные страницы - не "пересобираться" без нужды (если заявлен серверный кэш).
• Проверьте сжатие и размер ресурсов: включены gzip/brotli (если управляется), изображения оптимизированы, нет загрузки "гигантских" баннеров на мобильном.
• Проверьте базовые HTTP‑заголовки: корректный Content-Type, нет лишних редирект‑цепочек, для скачиваемых файлов - адекватный Content-Disposition.
• Проверьте логи и обработку 5xx: есть доступ к error‑логам и понятный процесс реакции (кто смотрит, как быстро).
• Проверьте фоновые задачи (если есть): очереди, крон‑задачи, отправка писем, импорты - выполняются по расписанию и не "зависают" без уведомлений.
• Проверьте резервное копирование и восстановление: не только "бэкап есть", но и кто/как его разворачивает, где хранится, кто имеет доступ.
• Проверьте лимиты хостинга: размер диска, лимиты PHP/Node, размер загрузки файлов, таймауты - соответствуют проекту и не ломают ключевые сценарии.
• Проверьте мониторинг доступности: минимум - внешний пинг главной и критичных URL, плюс алерт на недоступность/5xx (любой инструмент, который реально будет использоваться).

Контент, SEO‑проверки и соответствие техзаданию

• Несоответствие структуре: страницы/разделы не совпадают с картой сайта из ТЗ, "потерялись" посадочные.
• Битые ссылки и медиаконтент: ссылки ведут на 404, изображения не грузятся, файлы скачиваются с ошибкой.
• Неправильная индексация: на проде случайно стоит noindex или закрывающий robots.txt; на стейдже наоборот забыли закрыть индексацию.
• Дубли страниц: доступно несколько вариантов URL (со слэшем/без, с параметрами), нет каноникалов, нет редиректов после смены адресов.
• Мета‑данные "по умолчанию": пустые title/description, одинаковые заголовки, неверные Open Graph‑картинки на расшаривание.
• Некорректные H1 и иерархия заголовков: несколько H1 на странице без логики или отсутствует H1 там, где он нужен.
• Неконсистентные контакты/реквизиты: телефон/адрес отличаются в шапке/подвале/контактах, нет кликабельных ссылок tel:/mailto:.
• Неучтенные требования аналитики: нет счетчиков, не настроены цели на ключевые действия, UTM теряются при редиректах.
• Расхождение с "как договорились": важные мелочи не описаны, но подразумевались. Чтобы избежать спора, используйте формулировку принять сайт у подрядчика чек лист как приложение к акту: "пункты ниже - критерии приемки".

Юзабилити, адаптивность и кроссбраузерное поведение

Альтернативы подхода к проверкам - выбирайте по рискам и бюджету (часто разумно комбинировать):

1. Минимальный smoke‑прогон. Уместен для небольших сайтов/лендингов: проверяете только критичные пути (заявка/звонок/форма) и базовую адаптивность. Хорошо сочетается с чек лист приемки сайта перед запуском, когда сроки поджимают.
2. Сценарное тестирование по ролям. Уместно для корпоративных сайтов с личным кабинетом/админ‑процессами: отдельные сценарии для клиента, менеджера, редактора, администратора.
3. Кроссбраузерный прогон на реальных устройствах/облачных стендах. Уместен, если аудитория разнообразна или есть сложная верстка/анимации. Проверяйте хотя бы: iOS Safari, Android Chrome, desktop Chrome/Firefox/Edge.
4. Независимая приемка третьей стороной. Уместна при конфликтной истории с подрядчиком или высоких рисках релиза; заранее согласуйте формат артефактов и критерии, чтобы это не превратилось в бесконечный "поиск несовершенств".

Типичные сомнения при приемке и быстрые решения

Можно ли принимать сайт без полного ТЗ?

Можно, но риски споров выше. Минимум зафиксируйте "техническое задание на приемку сайта": список страниц/функций и критерии "принято/не принято" по ключевым сценариям.

Что считать критичным дефектом перед запуском?

Все, что ломает P0‑сценарии, безопасность, оплату/лиды, доступность или вызывает утечку данных. Остальное оформляйте как пострелизный план с датами.

Подрядчик просит подписать акт, а мелкие баги "потом". Так можно?

Да, если вы подписываете акт с приложением: перечень дефектов и сроков исправления. Без приложения "потом" часто превращается в "никогда".

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

Нужно сделать короткий регрессионный прогон P0‑сценариев именно на том окружении, которое станет продом, после финальной сборки.

Как корректно запросить у исполнителя "аудит сайта перед запуском цена"?

Запрашивайте не только цену, а состав работ: количество шаблонов/страниц, перечень сценариев, список проверок, формат отчета и сроки исправлений.

Какие доступы обязательно должны остаться у заказчика после приемки?

Домен/DNS, хостинг, репозиторий, админка CMS, аналитика, почта/SMTP, аккаунты сторонних интеграций. Доступы должны быть на корпоративных учетках, а не на личных.

Как быстро зафиксировать "принять сайт у подрядчика чек лист" в документе?

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