Чек-лист приемки сайта после разработки - как проверить на ошибки и качество

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

Красивый дизайн не гарантирует, что сайт будет быстро загружаться, корректно работать на смартфонах, принимать заявки, индексироваться поисковыми системами и приносить клиентов. Большинство критичных проблем становятся заметны только после запуска, когда исправления занимают больше времени, стоят дороже и часто уже не входят в стоимость разработки.

Чтобы этого избежать, перед приемкой стоит провести полноценную проверку сайта. Для этого не обязательно быть программистом или SEO-специалистом. Достаточно знать, на что обратить внимание и какие вопросы задать разработчикам. Если вы только планируете создание сайта, многие ошибки можно исключить еще на этапе проектирования при написании ТЗ. Как это сделать грамотно, читайте в нашей статье "Как написать ТЗ для создания сайта: пошаговая инструкция с примерами".

В этой статье мы подготовили подробный чек-лист приемки сайта после разработки. Он поможет проверить техническую часть, функциональность, безопасность, SEO, аналитику и убедиться, что сайт действительно готов к работе.

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

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

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

Самые распространенные проблемы становятся заметны только после запуска:

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

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

Если сайт еще только предстоит заказать, заранее оцените реальные расходы на разработку и дальнейшее продвижение.

Реальный пример

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

Через две недели выяснилось сразу несколько проблем:

• форма обратной связи не отправляла заявки;
• на iPhone меню перекрывало часть страницы;
• сайт не индексировался из-за неправильных настроек robots.txt;
• скорость загрузки главной страницы превышала 8 секунд.

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

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

Многие считают, что разработчик должен передать только ссылку на готовый сайт и доступ к административной панели. На практике этого недостаточно.

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

• доступ к панели управления сайтом (CMS);
• доступ к хостингу;
• доступ к регистрации доменного имени;
• FTP или SFTP-доступ к файлам сайта;
• доступ к базе данных (при необходимости);
• данные SSL-сертификата или информацию о его продлении;
• доступ к Яндекс Метрике;
• доступ к Google Analytics 4 (если используется);
• доступ к Яндекс Вебмастеру;
• доступ к Google Search Console;
• исходные материалы дизайна, если это предусмотрено договором;
• инструкцию по работе с сайтом.

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

Почему это важно

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

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

Чек-лист №1. Проверяем техническую часть

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

Начать приемку лучше именно с технической проверки.

Проверьте скорость загрузки страниц

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

Во время проверки обратите внимание на следующие моменты:

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

Дополнительно стоит проверить проект через Google PageSpeed Insights или Lighthouse. Эти сервисы покажут, какие элементы замедляют загрузку.

Убедитесь, что сайт работает по HTTPS

Сегодня наличие SSL-сертификата является обязательным требованием. Защищенное соединение необходимо не только для безопасности пользователей, но и для корректной работы современных браузеров и поисковых систем.

Проверьте следующие пункты:

• адрес сайта начинается с https://;
• браузер не показывает предупреждение о небезопасном соединении;
• при переходе по http происходит автоматическое перенаправление на https;
• на страницах отсутствуют предупреждения Mixed Content.

Если браузер сообщает, что часть ресурсов загружается по HTTP, значит некоторые изображения, стили или скрипты подключены неправильно. Такие ошибки желательно устранить до запуска.

Проверьте наличие технических ошибок

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

Особое внимание уделите следующим моментам:

• нет страниц с ошибкой 404;
• не появляются ошибки сервера 500;
• ссылки открывают нужные страницы;
• отсутствуют бесконечные циклы переадресации;
• изображения отображаются корректно;
• файлы доступны для скачивания, если они предусмотрены.

Мини-кейс

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

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

Проверьте готовность сайта к индексации

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

• файл robots.txt;
• наличие sitemap.xml;
• корректность тегов canonical;
• отсутствие запрета на индексацию важных страниц;
• правильную настройку редиректов.

Во время разработки сайты часто закрывают от поисковых роботов, чтобы тестовые версии не попали в индекс. Иногда после запуска эти ограничения забывают снять. Если во время проверки обнаружились технические ошибки, лучше устранить их до запуска сайта, поэтому рекомендуем заказать услугу техническая SEO-оптимизация сайта

Реальный пример

После публикации нового корпоративного сайта прошло почти три месяца, но посетителей из поиска не было совсем.

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

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

Чек-лист №2. Проверяем адаптивность

Сегодня более половины пользователей заходят на сайты со смартфонов. Для некоторых сфер бизнеса этот показатель превышает 70%. Если сайт неудобно использовать с мобильного устройства, потенциальный клиент, скорее всего, просто закроет страницу и перейдет к конкурентам.

При этом адаптивная верстка — это не только уменьшение изображения под размер экрана. Все элементы интерфейса должны оставаться удобными независимо от устройства.

Какие устройства стоит проверить

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

Минимальный набор для проверки выглядит так:

• компьютер или ноутбук;
• планшет;
• смартфон на Android;
• iPhone;
• широкоформатный монитор (если есть возможность).

Если протестировать сайт на реальных устройствах невозможно, можно воспользоваться инструментами разработчика в браузере Google Chrome или Microsoft Edge, которые позволяют эмулировать различные размеры экранов.

Что проверить на мобильной версии

Во время тестирования обратите внимание не только на внешний вид страниц, но и на удобство взаимодействия с ними. Обязательно проверьте:

• открывается ли мобильное меню;
• удобно ли нажимать на кнопки;
• не выходят ли изображения за пределы экрана;
• не появляется ли горизонтальная прокрутка;
• читабелен ли текст без увеличения масштаба;
• не перекрывают ли элементы друг друга;
• удобно ли заполнять формы.

Отдельное внимание уделите всплывающим окнам. Иногда они выглядят корректно на компьютере, но полностью перекрывают экран смартфона, не позволяя пользователю закрыть окно или отправить заявку.

Реальный пример

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

Во время проверки выяснилось, что на большинстве моделей iPhone кнопка «Отправить заявку» располагалась ниже экрана и перекрывалась фиксированным футером. Пользователь просто не мог завершить заполнение формы.

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

Чек-лист №3. Проверяем формы обратной связи

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

Недостаточно просто увидеть сообщение «Спасибо за обращение». Необходимо убедиться, что заявка действительно дошла до компании.

Проверьте каждую форму отдельно

Во время приемки отправьте тестовую заявку через каждую форму, которая есть на сайте. Например:

• обратный звонок;
• форма «Оставить заявку»;
• форма консультации;
• форма заказа услуги;
• форма подписки на рассылку;
• форма обратной связи в разделе «Контакты».

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

После отправки заявки обязательно проверьте

Сам факт отправки — это только начало проверки. Убедитесь, что:

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

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

Мини-кейс

После запуска сайта менеджеры были уверены, что заявок просто мало. Однако спустя несколько недель выяснилось, что форма показывала сообщение «Спасибо, ваша заявка отправлена», хотя почтовый сервер был настроен неправильно.

Все обращения пользователей просто исчезали, а отдел продаж даже не подозревал об их существовании.

Чек-лист №4. Проверяем SEO-подготовку

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

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

Проверьте основные SEO-настройки

Минимальный набор технических параметров включает:

• у каждой страницы есть уникальный Title;
• заполнены метаописания Description;
• используется один заголовок H1;
• изображения содержат атрибуты alt;
• адреса страниц понятные и человекочитаемые;
• настроены хлебные крошки;
• прописаны canonical-теги;
• созданы robots.txt и sitemap.xml.

Даже если продвижение сайта планируется позже, эти элементы должны быть предусмотрены еще на этапе разработки. Их отсутствие усложнит дальнейшую SEO-оптимизацию.

Проверьте микроразметку

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

• Organization;
• WebSite;
• BreadcrumbList;
• Product;
• Service;
• Article;
• FAQPage.

Если микроразметка реализована неправильно, поисковые системы могут игнорировать расширенные сниппеты или отображать информацию некорректно. Структурированные данные помогают поисковым системам лучше понимать содержимое страниц и могут улучшить отображение сайта в поиске. Подробнее об этом мы рассказывали в отдельной статье "Микроразметка страниц сайта Schema.org: зачем нужна, как настроить и проверить".

Проверьте Open Graph

Open Graph отвечает за отображение страниц при публикации ссылок в социальных сетях и мессенджерах. Убедитесь, что для страниц настроены:

• заголовок;
• описание;
• изображение;
• канонический адрес страницы.

Если Open Graph отсутствует, при публикации ссылки может отображаться случайная картинка или вообще не появится изображение.

Реальный пример

После переноса сайта на основной домен оказалось, что все страницы получили одинаковый Title — «Главная». Для пользователя это было практически незаметно, а вот поисковые системы восприняли такой сайт как плохо оптимизированный.

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

Чек-лист №5. Проверяем удобство управления сайтом

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

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

Что стоит проверить в административной панели

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

• добавить новую страницу;
• изменить текст;
• заменить изображение;
• опубликовать новость;
• изменить контактную информацию;
• добавить нового сотрудника;
• обновить стоимость услуг.

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

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

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

Чек-лист №6. Проверяем безопасность

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

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

Что обязательно проверить

Минимальный набор требований к безопасности включает:

• настроено автоматическое резервное копирование сайта;
• создаются резервные копии базы данных;
• используются сложные пароли для административной панели;
• у разных сотрудников разные учетные записи;
• CMS и установленные расширения обновлены до актуальных версий;
• формы защищены от спама с помощью CAPTCHA или аналогичных решений;
• закрыт доступ к служебным каталогам и файлам.

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

Мини-кейс

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

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

Чек-лист №7. Проверяем аналитику

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

Настройка аналитики должна быть выполнена еще до запуска проекта.

Какие системы должны быть подключены

В зависимости от задач бизнеса используются разные инструменты, но чаще всего достаточно следующего набора:

• Яндекс Метрика;
• Google Analytics 4;
• Яндекс Вебмастер;
• Google Search Console;
• пиксели рекламных систем, если планируется запуск рекламы.

Что обязательно протестировать

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

• фиксируются посещения страниц;
• работают цели и события;
• отслеживается отправка форм;
• данные корректно передаются в CRM при наличии интеграции;
• электронная коммерция настроена правильно, если это интернет-магазин.

Реальный пример

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

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

Скачать итоговый чек-лист перед подписанием акта

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

Ошибки, которые заказчики замечают слишком поздно

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

• формы обратной связи не отправляют заявки;
• сайт закрыт от индексации поисковых систем;
• отсутствуют счетчики аналитики;
• не настроены цели в Метрике;
• нет доступа к хостингу и доменному имени;
• не работают отдельные страницы или ссылки;
• сайт некорректно отображается на мобильных устройствах;
• не выполняется резервное копирование;
• невозможно самостоятельно изменить контент.

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

Бесплатные SEO инструменты

Сравнение контента с конкурентом

Планировщик структуры сайта

Технический SEO анализ сайта

Когда стоит заказать независимый аудит

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

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

• качество программного кода;
• производительность сайта;
• безопасность проекта;
• корректность SEO-настроек;
• работу аналитики;
• качество адаптивной верстки;
• соответствие современным требованиям поисковых систем.

Стоимость независимого аудита обычно значительно ниже расходов на исправление ошибок уже после запуска проекта. Особенно если сайт создавался как основной инструмент продаж. Если хотите убедиться, что сайт полностью готов к работе, продвижению и приему заявок, имеет смысл заказать комплексный аудит.

Приемка сайта — это инвестиция в его дальнейшую работу

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

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

Если поисковый трафик уже не ограничивается только Яндексом и Google, стоит учитывать и новые источники переходов. Читайте в нашей статье "GEO вместо SEO - как продвигать сайт в ChatGPT и AI-поиске".

Используйте этот чек-лист при запуске любого нового проекта. Он поможет избежать большинства распространенных ошибок и принять сайт не только красивым, но и действительно качественным.