Приёмка и запуск сайта: что проверить до и после публикации

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

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

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

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

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

• Страницы и содержание. Услуги, цены, контакты, реквизиты и изображения актуальны; тестовые тексты и чужие данные удалены.
• Функции. Поиск, фильтры, корзина, личный кабинет и интеграции проверены, если они входят в ваш проект. Для обычного сайта услуг лишние проверки не нужны.
• Замечания. Записывайте адрес страницы, действие, ожидаемый и фактический результат. Снимок экрана помогает воспроизвести ошибку.

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

2. Пройдите путь посетителя на телефоне и компьютере

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

• Читаемость. Текст, подписи к рисункам и кнопки различимы на телефоне; страница не уезжает вбок, важное не закрыто баннером.
• Навигация. Меню, внутренние ссылки, телефон и почта ведут куда нужно. Проверьте также пустой поиск и несуществующую страницу.
• Формы. Пустые и неверные данные дают понятное сообщение; после успешной отправки есть подтверждение. Повторное нажатие не должно незаметно создавать несколько одинаковых обращений.
• Разные условия. Откройте важные сценарии в согласованных браузерах и на реальном телефоне. Проверьте загрузку через мобильную сеть, а не только офисный Wi-Fi.

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

3. Убедитесь, что компания получила тестовую заявку

«Форма отправлена» и «менеджер получил обращение» — две разные проверки. Отправьте тест с заметной пометкой и проследите весь путь до рабочего почтового ящика или CRM.

1. Отправьте каждую важную форму: с главной, услуги, карточки товара, из всплывающего окна.
2. Проверьте у получателя время, контакты и содержание обращения. При интеграции с CRM — создание записи и назначение ответственного.
3. Убедитесь, что аналитика фиксирует именно нужное действие. Клик по телефону не доказывает состоявшийся звонок, а цель формы может требовать дополнительной настройки.
4. Повторите проверку после переноса сайта. Домен, почтовые настройки и параметры интеграции могли измениться.

Например, документация Яндекс Метрики о валидации формы предупреждает: стандартная цель может засчитаться и при неуспешной попытке отправки. Поэтому сверяйте событие аналитики с фактическим получением заявки.

4. Проверьте основной домен, HTTPS и доступность для поиска

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

HTTPS шифрует обмен между браузером и сервером; это одна часть технической подготовки. Доступность и технические требования поиска описаны в документации Google. Выполнение проверок не гарантирует попадание каждой страницы в индекс.

5. Получите доступы, материалы и проверяемую резервную копию

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

• Учётные записи. Домен и DNS, хостинг, CMS, почта, аналитика, кабинеты вебмастеров и подключённые сервисы. Проверьте вход под владельцем и способы восстановления.
• Материалы. Согласованные исходники, тексты, изображения, сведения о лицензиях, настройках и продлении платных сервисов — в объёме договора.
• Резервная копия. Файлы, база данных и нужные настройки. Укажите дату, место хранения и ответственного; попросите показать восстановление на отдельной площадке.
• Рабочие роли. Выдайте сотрудникам необходимые права. Согласуйте, какие доступы сохраняет подрядчик для поддержки и когда они прекращаются.

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

6. Зафиксируйте готовность и повторите проверки после запуска

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

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

Можно ли подписать приёмку с замечаниями? Условия определяются договором; практический ориентир — зафиксировать список и влияние каждой проблемы. При неработающей оплате или потере заявок сначала восстановите основной сценарий.

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

Если нужен сайт с понятным порядком сдачи, посмотрите состав разработки в Group-S или пришлите задачу и текущий чек-лист.