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

Четверг, 18:20. Отдел маркетинга готовится опубликовать страницу заявок для дилеров, над которой работал три недели: обложка на месте, форма отправляется, список услуг верный. Нажата кнопка публикации, страница уходит в прод, все расходятся по домам. На следующее утро в 9:10 звонит региональный руководитель. В английской версии два блока остались на исходном языке, во вкладке браузера вместо заголовка написано «Новая страница», а ни одна из ночных заявок не дошла до CRM — форма отправляется, сообщение с благодарностью показывается, запись не появляется нигде. Все три ошибки можно было поймать за пятнадцать минут до публикации.

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

Что на самом деле ловит автоматическая предпусковая проверка?

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

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

Чем блокирующая находка отличается от предупреждения?

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

Находка	Пример	Блокирует?	Что делать
Пустой заголовок страницы	Во вкладке «Новая страница»	Да	Заполнить до публикации
Незаконченный текст на одном языке	Два блока без перевода	Да	Дописать или отключить язык
Сопоставление формы не проверено	Тестовая отправка не делалась	Да	Прогнать пробную заявку
Домен не подтверждён	DNS TXT-запись не добавлена	Да	Добавить запись, дождаться проверки
Пустое описание страницы	В выдаче не будет сниппета	Нет, предупреждение	Написать в первую неделю
Нет alt-текста у изображения	Обложка без описания	Нет, предупреждение	Закрыть в следующей версии

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

Чтение вручную: содержимое действительно готово?

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

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

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

Формы правда пишут туда, куда вы думаете?

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

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

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

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

Готовы ли домен, переадресация и ссылки?

Страница может работать на служебном адресе, но если кампанию объявляют на вашем домене, день публикации — худшее время ждать DNS. В сценарии Собственный домен и подтверждение система выдаёт одноразовую DNS TXT-запись, вы добавляете её в настройки домена, и подтверждение доказывает владение; после этого отдельно проверяется запись маршрутизации. Закройте этот шаг минимум за сутки: распространение DNS не подстраивается под ваш график.

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

Прочитает ли поисковик страницу правильно в первый же день?

Когда публичные страницы рендерятся на сервере, заголовок, описание, канонический адрес, языковые альтернативы и структурированные данные приходят прямо в HTML и читаются до выполнения JavaScript, а у каждого опубликованного сайта есть свои sitemap.xml и robots.txt. В проверке вы смотрите не на наличие этой основы, а на значения, которые заполнили вы: у каждой ли страницы свой заголовок и описание, не делят ли две страницы один заголовок, не осталась ли открытой для индексации страница благодарности.

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

Кто согласует и кто нажимает кнопку публикации?

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

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

По какому принципу выбирают час публикации?

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

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

На что смотреть в первые 48 часов после публикации?

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

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

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

Каков ваш план отката, если что-то пойдёт не так?

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

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

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

Если хотите, чтобы ваш собственный список проверок работал, а публикации проходили через согласование и версии, откройте бесплатный аккаунт Rocketly и прогоните первую страницу через предпусковую проверку.

Частые вопросы

Любая находка блокирует публикацию?

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

Можно ли показать страницу человеку вне команды до публикации?

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

Я опубликовал не ту версию — сколько займёт возврат?

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

Нужно ли писать список проверок заново перед каждым запуском?

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