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

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

Скачать чек-лист запуска в Markdown. В файле есть место для адреса, ответственного, результата и повторной проверки. Копируйте его для конкретного релиза и сохраняйте рядом с резервной копией.

Проверка сайта перед запуском: содержание и связи

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

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

Проведите сценарий с телефона

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

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

Отправьте обращение до получателя

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

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

Проверка сайта перед запуском: условия публикации

Участок	Что подтвердить
Домен и HTTPS	Правильный адрес, действующий сертификат, выбранная основная версия.
Перенос старого сайта	Сохранённые адреса или карта перенаправлений, резервная копия.
Индексация	Нет случайного запрета публичных страниц; карта сайта доступна.
Доступы	Владельцу переданы необходимые роли и способ восстановления.
Откат	Понятно, где копия, кто восстанавливает и как проверить результат.

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

Что записать в акт проверки

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

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