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

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

1. Сравните результат с согласованным объёмом

Откройте предложение, структуру и последнее согласованное задание. Сверяйте страницы, языки, формы, интеграции и редактируемые материалы. У каждого требования должен быть способ проверки: не «удобная CMS», а «редактор меняет цену и публикует её без разработчика». Дополнительную идею, появившуюся в конце проекта, запишите отдельно. Так исправление невыполненного требования не смешается с расширением заказа, а спор о впечатлениях превратится в конкретный список результатов.

2. Пройдите весь путь заявки

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

Рекомендации W3C по проверке полей помогают сформулировать приёмку: обязательные поля обозначены, ошибка понятна и её можно исправить. Успех и сбой отправки должны давать различимые уведомления. Источники: https://www.w3.org/WAI/tutorials/forms/validation/ и https://www.w3.org/WAI/tutorials/forms/notifications/ .

3. Проверьте мобильный экран и оба языка

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

4. Отделите доступность для поиска от обещания позиций

Попросите показать, какие страницы открыты для индексации, где находится sitemap, как настроены canonical и языковые связи. Важные тексты должны быть доступны поисковику, а старые адреса при переносе — вести на подходящие новые. Одна оценка скорости не заменяет проверку формы и содержимого. Руководство Google описывает технические основы, но выполнение чек-листа не гарантирует индексирование или место в выдаче: https://developers.google.com/search/docs/fundamentals/seo-starter-guide .

5. Заполните таблицу приёмки

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

6. Примите доступы и порядок поддержки

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

Если сайт только планируется, включите эти критерии в задачу на разработку: https://samsa.agency/services/web-development . Для существующего проекта можно отдельно обсудить проверку и сопровождение: https://samsa.agency/services/website-support . Пришлите адрес сайта и список обязательных действий пользователя — по ним можно определить объём проверки.