Принимать сайт «на глазок» — открыл, вроде похоже на макет, оплатил — рискованно: часть проблем видна только при внимательной проверке, а после подписания акта предъявлять претензии намного сложнее. Ниже — чек-лист по восьми пунктам, который стоит пройти до оплаты, а не после.
| # | Что проверить | Норма |
|---|---|---|
| 1 | Вёрстка на разных устройствах | Не съезжает на мобильном, планшете и разных браузерах |
| 2 | Кто владеет доменом и хостингом | Регистрация на вас, а не на разработчика |
| 3 | Работа форм и ключевых сценариев | Заявка реально доходит туда, куда должна |
| 4 | Скорость загрузки | Основной контент — в пределах 2,5 секунд |
| 5 | Аналитика и метрики | Яндекс.Метрика / Google Analytics подключены и фиксируют события |
| 6 | SEO-база | Уникальные title/description, sitemap, корректный robots.txt |
| 7 | Валидность кода | Не критично, но полезно для дальнейшей поддержки |
| 8 | Акт приёма-передачи | Прописаны гарантийные правки и право придержать оплату при дефектах |
1. Проверьте вёрстку на разных устройствах
Откройте сайт на телефоне, планшете и компьютере, в нескольких браузерах — Chrome, Safari, если есть возможность, ещё и на Android, и на iPhone отдельно. Обратите внимание, не съезжают ли блоки, не обрезается ли текст, одинаково ли выглядят кнопки и отступы. Разработчик может тестировать только в одном браузере на своём компьютере — а у ваших клиентов устройства разные.
2. Проверьте, кто владеет доменом и хостингом
Это один из самых важных и самых часто упускаемых пунктов. Если домен или хостинг зарегистрированы на аккаунт разработчика, а не на вас, — вы рискуете остаться без доступа к собственному сайту, если возникнет конфликт или разработчик просто станет недоступен. Проверить легко: попросите доступ к личному кабинету регистратора домена и хостинг-панели, убедитесь, что владелец — вы или ваша компания, а не подрядчик.
3. Проверьте работу форм и ключевых сценариев
Не просто «форма открывается», а реально отправьте тестовую заявку и убедитесь, что она доходит туда, куда должна — на почту, в CRM, в Telegram-бот. Если на сайте есть оплата, пройдите весь сценарий покупки до конца тестовым платежом. Разработчики иногда проверяют, что форма технически отправляется, но не проверяют, долетают ли данные до конечной точки.
4. Проверьте скорость загрузки
Прогоните сайт через PageSpeed Insights или аналогичный сервис. Ориентир — основной контент должен появляться быстрее 2,5 секунд, особенно на мобильной версии, которую поисковики оценивают в первую очередь. Медленный сайт хуже ранжируется и теряет посетителей ещё до того, как они увидят контент.
5. Проверьте аналитику и метрики
Убедитесь, что Яндекс.Метрика и, если нужно, Google Analytics подключены и действительно фиксируют посещения и события — не просто вставлен код счётчика, а данные реально идут. Без этого вы не увидите, сколько людей приходит на сайт и что они делают, пока не станет поздно что-то менять.
6. Проверьте SEO-базу
Если сайт делался с расчётом на органический трафик, у каждой страницы должны быть уникальные title и meta description, должен быть подключён sitemap.xml, а robots.txt не должен случайно закрывать от индексации разделы, которые нужно продвигать. Это база, без которой даже хороший сайт не начнёт приносить заявки из поиска.
7. Проверьте валидность кода
Не критичный, но полезный пункт — чистый, валидный HTML упрощает дальнейшую поддержку и доработки, кто бы их ни делал. Проверить можно через W3C Validator: вставляете адрес сайта, получаете список ошибок, если они есть.
8. Проверьте акт приёма-передачи
Это пункт, который чаще всего вообще не проверяют, а зря. Хороший акт приёма-передачи должен включать: список работ, которые считаются выполненными, условия гарантийных правок после подписания, и — что особенно важно — право придержать финальную оплату, если после подписания обнаружится критичный дефект. Без этого пункта вы фактически лишаетесь рычага, если проблема всплывёт через неделю после оплаты.
Что делать, если нашёл дефект после подписания акта?
Смотрите в договор — если там прописаны условия гарантийных правок, требуйте их исполнения по этому пункту. Если договор не предусматривает ничего подобного, ситуация усложняется, поэтому лучше закладывать такие условия ещё на этапе подписания, а не постфактум.
Кто должен владеть доменом — я или разработчик?
Вы. Это должно быть оформлено с самого начала проекта, а не в момент приёмки — если уже не так, стоит договориться о переоформлении до финальной оплаты.
Сколько времени разумно закладывать на проверку перед приёмкой?
Зависит от сложности сайта, но для большинства проектов достаточно нескольких часов вдумчивой проверки по всем пунктам чек-листа — это несопоставимо меньше, чем время на разбор проблем, которые всплывут после оплаты.
Нужен ли независимый аудит, если я не разбираюсь в коде?
Если сайт сложный или бюджет большой — да, разумная предосторожность. Мы в MG Solutions в том числе делаем такие проверки как отдельную консультацию, если нужен взгляд со стороны перед приёмкой.
Если сомневаетесь в качестве своего проекта перед приёмкой — напишите в @MGSolutions_bot, поможем пройтись по чек-листу.
