Что проверить перед запуском сайта: технический чек-лист
Перед публикацией сайт может выглядеть готовым, но внешняя часть — только один уровень проверки. Ошибка в DNS, форме, перенаправлении или аналитике обнаруживается уже после запуска и влияет не на макет, а на реальные обращения и данные.
Технический чек-лист помогает провести переключение последовательно. Он не заменяет тестирование проекта, но фиксирует критичные точки, которые должны быть проверены перед открытием сайта для посетителей и поисковых систем.
1. Домен, DNS и HTTPS готовы к переключению
Нужно заранее подтвердить владельца домена, доступ к DNS и срок регистрации. Записи должны вести на нужный сервер, а почтовые записи — оставаться корректными после изменений. Если меняется IP-адрес, учитывают время обновления DNS и не отключают старую площадку слишком рано.
Сертификат HTTPS должен быть выпущен для всех используемых имён домена, а переход с HTTP — вести на единственную каноническую версию. Проверяют главную, внутренние страницы, файлы и запросы к API: смешанный контент может оставить часть ресурсов заблокированной браузером.
2. Есть резервная копия и план отката
До переключения создают копию файлов, базы данных и важной конфигурации. Архив проверяют по размеру и составу, сохраняют отдельно от рабочей площадки и записывают понятный порядок восстановления.
Также нужен план отката: кто принимает решение, какие изменения возвращаются и сколько времени допустимо потратить на исправление. Для сайта с активными заказами или заявками отдельно определяют, как не потерять данные, появившиеся между резервной копией и переключением.
3. Формы и интеграции проходят полный сценарий
Каждую форму проходят как посетитель: заполняют обязательные поля, проверяют ошибки, согласия, успешный ответ и защиту от повторной отправки. Затем подтверждают, что заявка действительно дошла до почты, CRM, Telegram или личного кабинета.
Одного сообщения «отправлено» недостаточно. Важно проверить всю цепочку до менеджера, включая вложения, уведомления и источник обращения. Подробная схема такого контроля описана в статье о пути заявки от сайта до менеджера.
4. Мобильная версия проверена на реальных размерах
Сайт проверяют не только в режиме уменьшения окна. Нужны реальные ширины телефонов и планшетов, портретная и альбомная ориентация, увеличение текста и управление пальцем. Особое внимание уделяют меню, формам, всплывающим окнам, таблицам и фиксированным кнопкам.
Заголовки не должны выходить за экран или разрываться посреди слова, интерактивные элементы — перекрывать контент, а поля — вызывать неожиданный масштаб. Проверка с клавиатуры и видимого фокуса помогает обнаружить часть проблем доступности ещё до запуска.
5. Скорость оценивается на рабочих страницах
Скорость измеряют на тех страницах, куда реально придёт трафик: главной, услугах, статьях, форме или каталоге. Отдельно смотрят первый визит без кеша и повторную загрузку, а также поведение на мобильном соединении.
Перед запуском оптимизируют изображения, убирают ненужные скрипты и проверяют, что кеш не скрывает свежую версию. Сервер должен иметь запас ресурсов, а журналы — не заполняться повторяющимися ошибками. При выборе инфраструктуры полезно свериться с руководством по выбору VPS для сайта.
6. SEO, адреса и аналитика настроены до открытия
На публичной версии проверяют заголовки страниц, описания, канонические адреса, robots.txt и Sitemap. Тестовая площадка может быть закрыта от индексации, но этот запрет нельзя случайно перенести на основной домен.
Если меняются адреса, составляют карту постоянных перенаправлений со старых URL на наиболее подходящие новые. Счётчики аналитики и цели проверяют реальным действием, а не только наличием кода. Страницы ошибок, изображения для социальных сетей и фавиконки тоже входят в финальную проверку.
7. Доступы, безопасность и наблюдение переданы ответственным
Перед открытием удаляют временные учётные записи, меняют переданные пароли, ограничивают административные права и проверяют, что секреты не находятся в публичных файлах. Система, плагины и зависимости должны быть на согласованных версиях без лишних компонентов.
После запуска назначают ответственного за домен, сертификат, резервные копии, обновления и реакцию на ошибки. Мониторинг доступности и критичных сценариев включают сразу, а не после первого сбоя. Состав регулярных задач можно сверить со статьёй о поддержке сайта после запуска.
Запуск — это управляемое переключение, а не одна кнопка
У запуска должны быть время, ответственные, список проверок и понятный критерий отмены. Сначала выполняют резервирование и подготовку, затем переключение, короткую проверку критичных функций и расширенный контроль уже на публичном домене.
Результаты фиксируют: что проверено, какие ограничения остались и кто отвечает за следующий шаг. Подготовить запуск сайта вместе со Skycode — опишите проект, и мы составим проверку под его технологии и бизнес-сценарии.
