Вам сдали сайт. Что проверить перед подписанием акта: чек-лист F5
Сайт выглядит готовым: дизайн соответствует макетам, кнопки нажимаются, тексты загружены — кажется, можно подписывать акт и запускаться.
Но именно на этом этапе часто обнаруживаются вещи, которые не видны на красивом первом экране. Форма отправляет письма на старый адрес, цели в Метрике не настроены, политика обработки персональных данных не соответствует реальной схеме, старые страницы исчезли без редиректов, а резервную копию никто не пробовал восстанавливать.
1. Сначала проверьте не сайт, а то, что вам передают вместе с ним
Проблемы часто начинаются не в день запуска, а через несколько месяцев — когда компания решает сменить подрядчика. Тогда выясняется, что домен оформлен на разработчика, хостинг находится в чужом кабинете, репозитория у заказчика нет, лицензия CMS привязана к чужой почте, а счётчик аналитики принадлежит агентству.
Что проверить
Доступы:
- домен и DNS;
- хостинг или сервер;
- административная панель сайта;
- CMS и лицензии;
- аналитика, CRM, рассылки и корпоративная почта;
- репозиторий исходного кода;
- сторонние сервисы и API.
Отдельно запросите:
- актуальные дизайн-макеты и исходники уникальной графики;
- перечень лицензий;
- документацию по нестандартным интеграциям;
- инструкцию администратора;
- схему резервного копирования;
- список сторонних сервисов, подключённых к сайту.
ВОПРОС ПОДРЯДЧИКУ
Если завтра текущий разработчик перестанет отвечать, сможете ли вы передать сайт другой команде и продолжить работу?
2. Проверьте контент, который вы не согласовывали
Заказчик обычно внимательно смотрит ключевые страницы. Ошибки остаются в системных сообщениях CMS, формах, поиске, фильтрах, пагинации и сторонних компонентах: Read more, Submit, Previous / Next, Search, Your message has been successfully sent.
Что проверить
- нет ли английских системных терминов и Lorem ipsum;
- одинаково ли называются услуги и разделы;
- не осталось ли старого названия компании;
- актуальны ли телефоны, e-mail, адреса и реквизиты;
- работают ли ссылки на документы;
- нет ли текстов от шаблона, демоверсии или явных ИИ-артефактов;
- понятны ли подписи кнопок;
- есть ли на каждой странице понятное следующее действие.
Посмотрите на сайт глазами человека, который видит его впервые
Для команды проекта кнопка «Решения» может быть совершенно понятной. Для нового посетителя — нет. Пройдите ключевые страницы без знания внутренней логики проекта и проверьте, понятно ли, где вы находитесь и что делать дальше.
Полезно знать
3. Формы: проверить нужно не кнопку «Отправить», а весь путь заявки
Форма считается рабочей не тогда, когда появилась надпись «Спасибо», а когда заявка прошла весь маршрут и дошла до нужного сотрудника.
Из практики F5
На сайте всё работало, кроме одного: заявки отправлялись на почту сотрудника, который уже не работал в компании. Технически форма была исправна. Для бизнеса — нет.
- Форма открывается и заполняется.
- Обязательные поля действительно обязательны.
- Телефон и e-mail корректно валидируются.
- Ошибки объясняются человеческим языком.
- После отправки пользователь понимает, что произошло.
- Менеджер получает заявку на актуальный e-mail.
- Если подключена CRM — лид или сделка создаются там.
- Передаются страница, услуга, UTM и источник обращения.
- Не создаются дубли.
- Прикреплённые файлы доходят.
- Форма работает с телефона.
- Проверена защита от очевидного спама.
- Проверен сценарий ошибки отправки.
ВОПРОС ПОДРЯДЧИКУ
Куда именно попадает заявка после отправки формы и как мы узнаем, если этот маршрут перестанет работать?
4. Персональные данные, согласия и cookies: наличие документов ещё не означает, что всё сделано правильно
Политика и чекбокс не подтверждают соответствие сами по себе. Документы должны описывать реальную схему работы сайта, а не абстрактный шаблон.
Посмотрите, где сайт собирает информацию о пользователях
- формы обратной связи, записи и обратного звонка;
- регистрация и личный кабинет;
- подписка и рассылки;
- загрузка файлов;
- чат, CRM и уведомления;
- аналитика и сторонние виджеты.
Проверьте документы и согласия
В документах должны быть указаны корректный оператор, цели, состав данных, сроки, порядок обработки и фактически используемые сервисы. Согласия не должны быть спрятаны внутри другого документа или подменяться общей фразой у кнопки.
Проверьте не только сайт, но и путь данных
Правильный вопрос: «Где оказываются данные пользователя после того, как он заполнил форму?» Реальная цепочка может выглядеть так:
сайт → почта → CRM → Telegram-уведомление → сторонний сервис.
А что с cookies?
Проверяйте не наличие красивой плашки, а механику: какие технологии запускаются, какие данные обрабатываются, для каких целей, какие внешние сервисы подключаются и соответствует ли уведомление фактической работе сайта.
Важно
Требования зависят от состава сервисов, целей и конкретной схемы обработки. Это технический чек-лист, а не юридическое заключение. Для медицины, государственных организаций и проектов с чувствительными данными модель обработки лучше проверять отдельно.
Полезно знать
5. SEO: новый сайт может выглядеть лучше старого и потерять накопленный трафик
При редизайне особенно важно сохранить историю существующих страниц. Если адрес site.ru/services/service-name заменили на site.ru/catalog/new-service-name, поисковой системе нужно явно объяснить переезд.
Если сайт заменяет старый
До запуска должна появиться таблица: старый URL → новый URL → что с ним происходит. Отсутствующие страницы нельзя просто выключить и заменить сотнями 404.
Перед запуском проверьте
- Title, Description и H1;
- логичную структуру H2–H3;
- URL и canonical;
- robots.txt и sitemap.xml;
- страницу 404;
- индексацию технических разделов и отсутствие дублей;
- метаданные для социальных сетей;
- alt у содержательных изображений;
- фильтры, пагинацию и микроразметку там, где она нужна;
- 301‑редиректы со старой версии;
- снятие запрета индексации после переноса с тестового домена.
🚩 Красный флаг
Сайт перенесли на основной домен вместе с Disallow: / или метатегом noindex, установленным на этапе разработки.
6. Аналитика: установленная Метрика ещё не означает настроенную аналитику
Посещения могут считаться, но без целей бизнес не узнает, стал ли новый сайт приносить больше обращений.
«Метрика стоит» ≠ «аналитика настроена»
Хорошая проверка начинается не с вопроса «Установлен ли счётчик?», а с вопроса: «На какие вопросы о работе сайта бизнес должен уметь ответить через три месяца?»
- счётчик принадлежит заказчику;
- данные поступают без дублей;
- настроены отправки форм;
- считаются клики по телефону, e-mail и мессенджерам;
- отслеживаются скачивания и другие значимые действия;
- передаются рекламные параметры;
- аналитика корректно работает вместе с consent-механикой.
Полезно знать
7. «Адаптивный сайт» тоже нужно проверять руками
Откройте сайт на небольшом и большом смартфоне, ноутбуке и широком мониторе. Затем пройдите реальный сценарий:
открыть меню → найти услугу → заполнить форму → допустить ошибку → исправить → отправить → вернуться назад.
Так обнаруживаются перекрытые клавиатурой кнопки, незакрывающиеся попапы, горизонтальный скролл, таблицы шире экрана, конфликт sticky-кнопок и cookie-баннер, закрывающий основной CTA.
8. Скорость: не гонитесь за красивыми баллами ради баллов
Не требуйте 100 баллов PageSpeed как самоцель. Гораздо полезнее проверить:
- как быстро появляется основной контент;
- не прыгают ли элементы во время загрузки;
- не загружаются ли чрезмерно тяжёлые изображения;
- корректно ли работают кеширование и шрифты;
- нет ли ошибок JavaScript и отсутствующих ресурсов;
- как сайт ведёт себя на реальных мобильных устройствах;
- корректны ли HTTPS и технические редиректы.
Лабораторный тест — ориентир, а не исчерпывающая оценка пользовательского опыта.
9. Не прокликивайте страницы — проходите пользовательские сценарии
Пользователь № 1: хочу заказать услугу.
Можно ли понять, куда идти?
Пользователь № 2: хочу задать вопрос.
Легко ли найти контакт?
Пользователь № 3: ищу конкретный продукт.
Работают ли поиск и фильтры?
Пользователь № 4: хочу скачать документ.
Открывается ли он?
Пользователь № 5: пришёл из поиска сразу на внутреннюю страницу.
Понятно ли мне, где я нахожусь и что делать дальше?
В рамках этих сценариев проверьте
- ссылки, кнопки, меню и хлебные крошки;
- поиск, фильтры и пагинацию;
- документы и якоря;
- телефон, e-mail, мессенджеры и внешние переходы;
- ссылки на тестовый домен, старую версию сайта и временные хранилища.
10. Интеграцию нельзя принимать только по одному успешному сценарию
Для 1С, Битрикс24, CRM, ERP, МИС, телефонии, платёжных систем и API нужно проверять не только happy path.
- что произойдёт после изменения цены;
- что будет при удалении товара или нулевом остатке;
- что произойдёт при прерывании обмена;
- как система поведёт себя без обязательного значения;
- что увидит пользователь при недоступности API;
- создастся ли дубль при повторном действии;
- как администратор узнает об ошибке.
ОДИН ИЗ ЛУЧШИХ ВОПРОСОВ ПРИ ПРИЁМКЕ ИНТЕГРАЦИИ
Как мы узнаем, что обмен перестал работать?
Если ответ: «Когда кто-нибудь заметит», стоит отдельно обсудить мониторинг и уведомления.
11. Безопасность и восстановление
Полноценный аудит информационной безопасности — отдельная задача. Но базовый уровень нужен практически каждому проекту:
- сайт работает по HTTPS;
- тестовые и служебные среды не оставлены публичными;
- нет очевидных тестовых учётных записей;
- права пользователей разграничены;
- бывшим участникам отключены ненужные доступы;
- секретные ключи не находятся в открытом коде;
- понятно, кто отвечает за обновления;
- резервные копии создаются и хранятся независимо.
ВОПРОС ПОДРЯДЧИКУ
Если завтра сайт полностью перестанет работать, кто, откуда и за какое время сможет его восстановить?
А кто проверял, что резервная копия действительно восстанавливается?
Backup существует не тогда, когда создаётся файл
Backup существует тогда, когда из него можно восстановить сайт.
12. Дайте сайт будущему администратору
Попросите человека, который будет реально работать с сайтом, самостоятельно:
- добавить новость;
- поменять телефон;
- заменить изображение;
- изменить страницу;
- добавить сотрудника;
- поменять SEO-поля.
Если каждое обычное действие заканчивается сообщением разработчику, нужно понять: это сознательно выбранная модель сопровождения или неудобно спроектированная административная часть.
Что в итоге должен получить заказчик
К моменту закрытия проекта у компании должна быть не просто ссылка на работающий сайт, а управляемая система:
Сайт → доступы и владельцы → домены и инфраструктура → исходники и лицензии → аналитика → персональные данные и внешние сервисы → интеграции → резервное копирование → правила дальнейшей поддержки.
Принимать нужно всю систему целиком.
🚩 13 красных флагов перед подписанием акта 🚩
Мы бы не торопились считать проект завершённым, если:
- непонятно, на кого зарегистрирован домен;
- у заказчика нет доступа к хостингу или серверу;
- никто не может перечислить сторонние сервисы проекта;
- формы не проверялись реальными отправками;
- неизвестно, куда попадают данные после отправки формы;
- документы по ПДн не соответствуют реальной работе сайта;
- аналитика установлена, но ключевые действия не считаются;
- при замене старого сайта нет карты старых и новых URL;
- тестовая версия доступна поисковикам или пользователям без необходимости;
- резервное копирование никто не проверял восстановлением;
- интеграции протестированы только на одном положительном сценарии;
- часть системы работает только под аккаунтом разработчика;
- у заказчика нет исходников, документации или понимания устройства нестандартной разработки.
Один пункт ещё не означает, что подрядчик сделал плохой сайт. Но каждый — повод разобраться до подписания акта, а не после возникновения проблемы.
Приёмка сайта — это не поиск виноватых
Даже хороший проект состоит из сотен элементов, сценариев и нескольких информационных систем. Ошибки появляются при переносе, после изменения требований и на стыке сервисов. Поэтому техническая приёмка — такой же этап разработки, как проектирование, дизайн или программирование.
А если сайт уже работает?
Эти проверки полезны не только перед актом. Их можно использовать при смене подрядчика, перед развитием проекта, после редизайна или если сайт перестал давать понятный бизнес-результат.
Для государственных, медицинских, научных и образовательных организаций дополнительно учитывайте отраслевые требования и ограничения по персональным данным.
