Сайт сдали, акт подписали. А потом выяснилось, что заявки никто не получает.

Новый сайт готов. Макеты согласованы, страницы свёрстаны, формы открываются, на смартфоне всё выглядит прилично. Подрядчик присылает акт.

Кажется, осталось проверить пару текстов и закрыть проект.

Но именно после этого иногда начинается самое интересное.

Форма сообщает пользователю «Спасибо», но заявка остаётся внутри административной панели. Яндекс.Метрика установлена, но цели не настроены. Домен зарегистрирован на аккаунт подрядчика. Старые страницы после запуска нового сайта начали отдавать 404. А политика обработки персональных данных вообще досталась проекту из чужого шаблона.

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

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

Форма работает. Но получил ли заявку менеджер?

Один из самых распространённых способов тестирования формы выглядит так:

пользователь заполнил поля → нажал «Отправить» → увидел сообщение «Спасибо».

Формально всё работает.

Но для бизнеса главное начинается только после этого.

Заявка должна попасть туда, где с ней действительно будут работать: в CRM, на корректный email или в другую согласованную систему.

На практике встречаются разные ситуации:

1. обращения уходят бывшему сотруднику;
2. заявки попадают в спам;
3. сохраняются только внутри сайта;
4. в CRM создаётся лид, но без услуги;
5. теряются UTM-метки;
6. не передаётся прикреплённый файл.

Поэтому проверять стоит всю цепочку:

пользователь → форма → сайт → CRM или почта → менеджер.

Если последний человек в этой цепочке заявку не получил, то для бизнеса форма не работает — независимо от того, что увидел разработчик на экране.

«Метрика установлена» ещё не означает, что аналитика настроена

Другой классический сценарий: на сайте есть Яндекс.Метрика, посещения считаются, графики строятся.

А через три месяца руководитель спрашивает:

1. сколько заявок принёс сайт;
2. какая реклама сработала;
3. какие услуги интересуют пользователей;
4. какие страницы приводят обращения.

И ответить на эти вопросы невозможно.

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

Поэтому перед приёмкой полезнее спрашивать не:

У нас есть Метрика?

а:

На какие вопросы о работе сайта мы сможем ответить через три месяца?

«Счётчик стоит» ≠ «аналитика работает».

Новый сайт запустили, а старые страницы исчезли

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

Например, раньше услуга находилась по адресу: site.ru/service-a

После редизайна стала: site.ru/catalog/service-a

Само по себе это нормально.

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

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

Поэтому при миграции сайта нужна карта: старый URL → новый URL → действие.

Это не второстепенная SEO-задача «на потом». Это часть нормальной приёмки нового сайта.

Сайт принадлежит компании. А домен, сервер и лицензии?

Есть ещё один важный вопрос: кому на самом деле принадлежит инфраструктура проекта?

До закрытия работ стоит разобраться, у кого находятся доступы к:

1. домену и DNS;
2. серверу или хостингу;
3. CMS;
4. репозиторию;
5. аналитике;
6. CRM;
7. платным модулям;
8. внешним сервисам;
9. API.

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

Проблема возникает позже — например, когда компания решает сменить разработчика.

Хороший тест: 
Если завтра текущая команда перестанет заниматься сайтом, сможет ли другой специалист продолжить работу без квеста по восстановлению доступов?

Если нет, проект ещё не передан полностью.

Политика обработки данных опубликована. Но соответствует ли она самому сайту?

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

Но при проверке иногда выясняется:

1. указан другой оператор;
2. остался чужой домен;
3. перечислены сервисы, которых на сайте нет;
4. не указаны те сервисы, которые фактически используются;
5. опубликован почти пустой шаблон.

Поэтому проверку персональных данных полезно начинать не с документа, а со схемы:

какие данные собираются → куда передаются → где хранятся → какие системы их получают.

Например:

форма → сервер → CRM → почта → аналитика → сторонний сервис.

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

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

Backup есть. А восстановить сайт из него пробовали?

Фраза «резервное копирование настроено» звучит успокаивающе.

Но файл резервной копии и возможность реально восстановить сайт — не одно и то же.

Перед закрытием проекта полезно спросить:

1. где хранятся копии;
2. как часто они создаются;
3. кто отвечает за восстановление;
4. сколько времени оно займёт;
5. проверял ли кто-нибудь этот процесс.

Мы используем простой принцип: 
backup существует не тогда, когда создаётся файл. Backup существует тогда, когда из него можно восстановить сайт.

Интеграция работает — пока всё идёт по плану

Если сайт связан с 1С, CRM, ERP, медицинской системой или внешним API, обычно демонстрируют успешный сценарий:

система передала данные → сайт их получил.

Но реальная эксплуатация почти всегда сложнее.

Что произойдёт, если:

1. API временно недоступно;
2. цена не пришла;
3. обязательное поле пустое;
4. обмен остановился;
5. запись передалась дважды?

Главный вопрос здесь:
Как мы узнаем, что интеграция перестала работать?

Если ответ — «когда клиент пожалуется», значит мониторинг ещё стоит продумать.

Что на самом деле нужно принимать у подрядчика

Сайт — это не набор страниц.

По итогам проекта бизнес получает цифровую систему, в которую входят:

домен → инфраструктура → код → CMS → аналитика → данные → интеграции → лицензии → документация → резервное копирование.

И приёмка должна охватывать всю эту систему.

Поэтому перед подписанием акта мы бы проверяли как минимум четыре уровня:

1. Пользовательский.Может ли человек выполнить нужное действие?

2. Бизнесовый.Получит ли компания заявку, данные и аналитику?

3. Технический.Корректно ли работают интеграции, сервер, SEO и резервное копирование?

4. Организационный.Есть ли у компании доступы, исходники, лицензии и понимание, как дальше поддерживать проект?

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

Независимый аудит иногда воспринимают как попытку найти ошибки текущей команды.

Мы смотрим на это иначе.

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

Через три месяца исправлять ту же проблему обычно дороже и сложнее.

Поэтому вопрос приёмки стоит формулировать так:

Понимаем ли мы, что именно получили и можем ли этим нормально пользоваться завтра без текущего подрядчика?

Digital-агентство F5 занимается разработкой и развитием сложных сайтов и цифровых платформ, включая проекты для медицины, образования, B2B и государственных организаций.

Полную версию чек-листа с проверкой форм, SEO, аналитики, персональных данных, мобильной версии, интеграций и инфраструктуры мы собрали в материале: «Вам сдали сайт. Что проверить перед подписанием акта: чек-лист F5».