Запуск сайта: чек-лист проверки перед публикацией

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

Что решает проверка перед запуском и где её границы

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

Что входит в проверку

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

Порядок проверки и два прохода

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

Что остаётся за рамками

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

Контент и тексты: критерии готовности страниц

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

Страницы, заголовки и описания

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

Изображения и внутренние ссылки

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

Функции и сценарии посетителя

Функции проверяет тот, кто ставил задачи на разработку, вместе с разработчиком. Здесь важно не «посмотреть на форму», а пройти сценарий до конца и убедиться, что результат доходит до адресата.

Формы и уведомления

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

Поиск, корзина, личный кабинет

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

Техническая готовность: HTTPS, почта, фоновые задачи

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

Защищённое соединение и почта

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

Фоновые задачи и административный раздел

Проверьте, что фоновые задачи выполняются по расписанию, а административный раздел доступен. В Битрикс административная часть открывается по отдельному адресу, и это стоит проверить заранее, чтобы не искать вход в день запуска. Если сайт работает на виртуальной машине, часть настроек — HTTPS, почта, задачи по расписанию, резервное копирование — управляется из её интерфейса, и это отдельная зона ответственности администратора. Конкретный перечень доступных настроек зависит от конфигурации проекта, поэтому его уточняют у администратора, а не переносят из общей инструкции.

Доступы, роли и защита административной части

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

Роли и права

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

Двухэтапная авторизация

Для администраторов стоит включить двухэтапную авторизацию: после логина и пароля сайт запрашивает дополнительное подтверждение — код из приложения-аутентификатора или другой способ, настроенный на проекте. Одноразовый код не подходит для следующего входа, поэтому даже при утечке пароля постороннему понадобится второе подтверждение. Это особенно важно для учётных записей с правом менять материалы сайта. Если подтвердить вход не получается, вопрос решает администратор сайта; резервные коды, если они разрешены на проекте, выдаются заранее. Способ подтверждения зависит от настроек конкретного сайта, поэтому его проверяют на месте.

Аналитика, резервные копии и план возврата

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

Счётчики и цели

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

Резервные копии и восстановление

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

План возврата

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

Ответственные и условия остановки запуска

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

Кто отвечает за что

• Заказчик — смысл, тексты, контакты, юридические блоки.
• Руководитель проекта — полнота проверки и решение о запуске.
• Разработчик — функции, формы, техническая часть.
• Администратор — доступы, роли, резервные копии, почта, фоновые задачи.
• Аналитик — счётчики и цели.

Условия остановки запуска

Запуск останавливают, если не работает оформление заказа или ключевая форма, нет свежей проверенной резервной копии, не настроен HTTPS, администратор входит без второго фактора, отсутствуют обязательные юридические тексты. Это не «мелкие недочёты» — это причины, по которым сайт лучше не публиковать. Решение об остановке принимает руководитель проекта, а не тот, кто нашёл проблему: иначе спор о важности пункта затягивается, а запуск идёт по инерции.

Таблица решений: что проверять и по какому критерию

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

Чек-лист готовности сайта к запуску

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

• Все страницы из структуры созданы и заполнены, заглушек нет.
• У каждой страницы заполнены заголовок и описание.
• Контакты, реквизиты и юридические тексты на месте.
• Изображения сжаты и снабжены описаниями.
• Внутренние ссылки ведут на существующие страницы.
• Каждая форма отправляется и доходит до нужного адреса.
• Уведомления о заявках приходят ответственному.
• Поиск по сайту возвращает результаты по всем разделам.
• Корзина и оформление заказа работают (для магазина).
• Регистрация, вход и восстановление пароля проверены.
• Страница 404 настроена и понятна посетителю.
• HTTPS настроен, сертификат действителен.
• Резервная копия создана и проверена на восстановление.
• Почтовые уведомления уходят, фоновые задачи выполняются.
• Административный раздел доступен, роли назначены.
• Для администраторов включена двухэтапная авторизация.
• Счётчики и цели аналитики настроены и фиксируют данные.
• Определён ответственный за сопровождение после запуска.
• Есть план возврата, если после публикации обнаружится проблема.

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

Ниже — учебный пример. Данные о компании и количестве объектов условные, это не реальный кейс и не статистика.

Входные условия

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

Ход проверки

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

Затем разработчик проверяет остальные формы и поиск. Поиск находит товары, но по одному разделу выдаёт пустой результат — не хватает привязки. Администратор в это время проверяет техническую часть: HTTPS настроен, сертификат действителен, фоновые задачи выполняются. Резервная копия создана, но восстановление ещё не проверяли — этот пункт оставляют открытым.

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

Результат и проверка

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

Как принять работу и что наблюдать после запуска

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

Что фиксировать письменно

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

Наблюдение после запуска

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

Типичные ошибки, ограничения и исходные данные

Частые ошибки

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

Ограничения

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

Какие исходные данные подготовить для оценки

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