Запуск и качество
Чек-лист запуска сайта: что проверить перед публикацией
Запуск считается завершённым не после загрузки файлов на сервер, а после проверки пользовательского пути, измерения заявок и готовности команды быстро восстановить работу.
Коротко
Перед публикацией сайта проверьте production-домен и HTTPS, формы и уведомления, мобильные сценарии, аналитику и цели, robots.txt, sitemap, canonical, метаданные, редиректы, скорость, доступность, безопасность, юридические документы и резервное копирование. После запуска повторите критичный путь на реальном домене и проверьте, что поисковые системы видят нужные URL.
Начните с главного пользовательского сценария
Перед техническими деталями пройдите путь, ради которого создан сайт. Найдите услугу или товар, откройте карточку, заполните форму, оплатите тестовый заказ или скачайте документ. Проверяйте не только идеальный вариант, но и ошибку, повтор, возврат и мобильное устройство.
Тест должен заканчиваться в рабочей системе. Если форма показывает «спасибо», но письмо не приходит, заявка не создаётся в CRM или менеджер не понимает источник, конверсия потеряна. Для каждой точки нужен владелец и способ проверить результат.
- Основная задача выполняется без подсказок.
- Навигация и поиск ведут к ожидаемому результату.
- Кнопки и ссылки работают с клавиатуры и касания.
- Форма показывает обязательные поля и понятные ошибки.
- Успешное действие подтверждается и не создаёт дубль.
- Письмо, CRM, Telegram или другая система получают событие.
- Телефон, email, адрес и мессенджеры открываются корректно.
- Страница ошибки 404 помогает вернуться к полезному разделу.
Проверьте домен, HTTPS и production-конфигурацию
Сайт нужно тестировать на том же артефакте и максимально близкой конфигурации, которая пойдёт в production. Разница между тестовой и боевой сборкой часто проявляется в переменных окружения, API, путях к файлам, CORS и внешних callback URL.
Определите единственную основную версию адреса: с www или без, с HTTPS и единым завершающим слешем по принятому правилу. Остальные варианты перенаправляют постоянным редиректом без цепочек.
Перед релизом создают резервную копию текущей версии, фиксируют инструкцию отката и проверяют, кто имеет доступ к домену, DNS, серверу, репозиторию и аналитике.
- DNS указывает на нужный сервер, а старые записи удалены по плану.
- SSL-сертификат действителен и обновляется автоматически.
- HTTP и альтернативный host перенаправляют на основной HTTPS-адрес.
- Production API, webhook и callback используют правильные URL.
- Отладка, тестовые аккаунты и временные баннеры отключены.
- Секреты не находятся в клиентском коде и репозитории.
- Настроены резервная копия, мониторинг и понятный откат.
- Владелец получил доступы, а лишние временные доступы закрыты.
Формы, цели и источники заявки проверяют вместе
Счётчик на странице ещё не означает, что аналитика настроена. Нужно проверить просмотр, отправку формы, клик по телефону, оформление заказа и другие события, по которым команда принимает решения.
UTM-метки и реферер передают вместе с заявкой или сохраняют в CRM. Иначе реклама и SEO показывают трафик, но менеджер не может связать обращение с источником и выручкой.
Cookie-баннер должен соответствовать фактическому поведению сайта: необязательная аналитика запускается только после выбранного согласия, если это требуется принятой политикой и юрисдикцией.
| Проверка | Как подтвердить | Кто получает результат |
|---|---|---|
| Отправка формы | Тестовая заявка с меткой | Почта, CRM или бот |
| Цель аналитики | Событие видно в отладке | Маркетолог или аналитик |
| Источник | UTM сохранена в карточке | Продажи и маркетинг |
| Ошибка отправки | Пользователь видит действие | Поддержка получает сигнал |
| Заказ и оплата | Статусы совпали во всех системах | Продажи и финансы |
Минимальная SEO-проверка перед открытием индексации
Сначала убедитесь, что production не наследовал noindex, пароль или запрет из тестовой среды. Затем проверьте canonical, robots.txt и sitemap. В карту добавляют только индексируемые канонические URL с успешным ответом.
У каждой важной страницы должны быть уникальные title, description, H1 и понятный текст, соответствующий поисковому намерению. Open Graph не влияет напрямую на ранжирование, но определяет, как ссылка выглядит в социальных сетях и мессенджерах.
При редизайне или смене структуры заранее готовят карту старых и новых URL. Каждый значимый старый адрес ведёт 301-редиректом на максимально близкий новый материал, а не на главную страницу.
- Важные страницы отвечают 200 и не закрыты от индексации.
- Canonical указывает на правильный основной URL.
- robots.txt не блокирует CSS, JavaScript и нужные разделы.
- sitemap содержит только канонические индексируемые страницы.
- Title, description и H1 уникальны и соответствуют содержанию.
- Изображения имеют осмысленные alt там, где передают информацию.
- Внутренние ссылки используют обычные доступные href.
- Старые URL перенаправлены без цепочек и массовых ошибок.
- Сайт подтверждён в Яндекс Вебмастере и Google Search Console.
- Для новых URL настроен контроль индексации, а не только отправка sitemap.
Скорость, мобильная версия и доступность
Проверяйте реальное устройство и медленное соединение, а не только широкий монитор разработчика. Первый экран должен быстро показать содержание, элементы не должны прыгать при загрузке, а основное действие — отвечать без заметной задержки.
Автоматический тест не заменяет ручную проверку. Пройдите сайт клавиатурой, убедитесь в видимом фокусе, корректных подписях форм, достаточном контрасте и понятном порядке заголовков.
Изображения отдают в подходящем размере и формате, шрифты не блокируют первый экран, а сторонние скрипты подключают только при необходимости. Для тяжёлого интерактива нужен запасной способ получить основную информацию.
- Макет не ломается на 320–375 px и в landscape.
- Текст не обрезается при увеличении масштаба.
- Кнопки и поля имеют стабильный размер и подпись.
- Фокус виден, меню и модальные окна работают с клавиатуры.
- Изображения не создают сдвиг макета и имеют размеры.
- Видео не блокирует контент и имеет управляемое воспроизведение.
- Основные страницы проверены через Lighthouse и реальные устройства.
- Критичные действия остаются доступными при ошибке необязательного скрипта.
Что проверить в первые часы и дни после запуска
Сразу после deployment повторно пройдите форму, заказ, вход и другие критичные сценарии на production. Проверьте логи сервера, ошибки JavaScript, доставку писем, webhook и события аналитики.
В первые дни контролируют ответы сервера, ошибки 404, индексацию, скорость, заявки и их источники. Резкое изменение трафика или конверсии рассматривают вместе с релизом, рекламой и сезонностью.
Google рекомендует подтвердить сайт, передать sitemap и отслеживать индексирование после запуска. Для интернет-магазина дополнительно проверяют доступность товаров, разметку и данные Merchant Center, если он используется.
План развития после публикации разобран в статье что делать с сайтом после запуска. Если меняется домен или структура, используйте отдельный план SEO-миграции.
- СразуSmoke-test production, формы, оплаты, входа и уведомлений.
- В первый деньЛоги, цели, 404, скорость и доступность сервера.
- В первую неделюИндексация, поисковые ошибки, заявки и источники.
- Через 2–4 неделиПоведение пользователей, конверсия и план улучшений.
FAQ
Частые вопросы
01Когда открывать сайт для индексации?
После проверки production-URL, контента, canonical, robots.txt, sitemap, редиректов и критичных пользовательских сценариев. Не открывайте тестовую версию с временными текстами.
02Нужно ли отправлять каждую страницу в поиск вручную?
Для небольшого числа приоритетных URL можно использовать инструменты проверки URL. Для массового обнаружения нужен корректный sitemap и доступные внутренние ссылки. Отправка не гарантирует индексацию.
03Кто должен проверять формы после запуска?
Ответственность лучше закрепить за конкретным человеком. Тест должен подтвердить интерфейс, серверную обработку, доставку уведомления, запись в CRM и событие аналитики.
04Можно ли запустить сайт без аналитики?
Технически можно, но вы потеряете базовую линию и не сможете оценить источники и конверсию. Минимальные цели и проверку заявок лучше настроить до рекламного трафика.
05Что делать, если после запуска нашли критичную ошибку?
Ограничить проблемную функцию, откатить релиз или включить безопасный режим по заранее подготовленному плану. Затем сохранить данные для разбора, исправить причину и повторить критичные тесты.
Источники и документация
Материал подготовлен редакцией ХЭМС на основе проектной практики. Цены и технические условия актуальны на дату публикации и уточняются после разбора задачи.
Обсудить проект
Запустите сайт без слепых зон
Проверим пользовательский путь, формы, аналитику, SEO, скорость и production-контур. Вернём список рисков и приоритет исправлений.