Проверка сайта перед запуском: полный чек-лист

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

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

Как пользоваться чек-листом запуска сайта

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

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

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

1. Контент и основные страницы

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

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

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

2. Навигация, устройства и доступность

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

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

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

3. Формы и обращения

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

Тестовые данные и загрузка файлов

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

Оцените сценарии сбоя: потеря соединения, повторное нажатие и недоступность получателя. Сообщение посетителю должно соответствовать фактическому состоянию; при неопределённом результате проверяйте доставку, прежде чем повторять действие, которое может создать дубль.

4. Интернет-магазин и платёжные сценарии

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

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

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

5. Безопасность и доступы

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

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

О типовых классах уязвимостей и мерах защиты — в статье о безопасности CMS. Чек-лист не заменяет профильное тестирование безопасности, если оно требуется проекту.

6. Домен, HTTPS и рабочее окружение

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

Переключение DNS

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

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

7. SEO и обнаружение страниц

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

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

После открытия доступа проверьте важные URL в доступных поисковых кабинетах и наблюдайте за состоянием в дальнейшем. Подробный порядок — в материале о проверке индексации в Google и Яндексе.

8. Скорость и аналитика

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

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

9. План переключения и отката

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

Этап	Пример проверки	Решение
До переключения	Резервная копия и восстановление проверены	Ответственный подтверждает готовность
Сразу после открытия	Главная страница, контакты и тестовая заявка работают	Команда фиксирует результат и ошибки
При критическом сбое	Невозможно получить обращения или открыть ключевые страницы	Ответственный запускает заранее согласованный план восстановления

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

10. Проверка после запуска

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

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