Чеклист перед запуском сайта: SEO, безопасность, аналитика

Введение. Запуск — событие с необратимыми SEO-эффектами: редиректы, индексация и доверие пользователей нужно проверить до переключения DNS. Материал для product- и engineering-лидеров, которые принимают решения на горизонте 12–24 месяцев, а не гонятся за хайпом в презентации.

Зачем чеклист перед продом

Большинство срывов в теме «чеклист перед запуском сайта» начинается не с кода, а с размытого scope: маркетинг обещает одно, продажи фиксируют другое, а ИТ закрывает техдолг третьим приоритетом. В итоге бюджет уходит в интеграции «на скотч» и ручные сверки в Excel. Мы видим это в проектах, где не описаны границы MVP, нет владельца метрик и не зафиксированы SLA на данные между системами.

По нашему опыту, у большинства запусков без формального go-live чеклиста хотя бы один P0-баг вылезает в первые 48 часов — чаще всего это забытый noindex, битая форма или SSL-сертификат, не выпущенный на поддомен. Каждый такой инцидент в первый день стоит не только органики, но и доверия клиента, который увидел баг раньше вас.

Техника и безопасность

Опорный принцип: сначала поток ценности, потом стек. Нарисуйте journey от первого касания до оплаты и поддержки, отметьте ручные шаги и точки отказа. Только после этого выбирайте техническое SEO и модель данных. Для чеклист перед запуском сайта мы обычно рекомендуем staging sign-off → DNS cutover → post-launch monitoring 72h: она даёт предсказуемый TCO и не блокирует масштабирование команды.

Зафиксируйте ADR по ключевым решениям: хранилище, очереди, авторизация, наблюдаемость. Включите в Definition of Done контрактные тесты API, схему событий и политику миграций. аудит сайта имеет смысл заказывать только когда есть согласованный backlog с приоритетами P0/P1 и измеримые KPI на квартал.

Безопасность на запуске — не только SSL. Просканируйте заголовки (CSP, HSTS, X-Frame-Options), закройте debug-эндпоинты и админку от внешнего доступа, проверьте rate limiting на формах против спам-ботов. Отдельно — smoke-тест восстановления из бэкапа: если в день запуска понадобится откат, вы должны знать, что бэкап реально разворачивается, а не просто лежит в S3.

SEO и аналитика

Кейс A (редизайн). Клиент пришёл с болью: потеряли 40% органики из-за 302. Мы разбили релиз на три волны: стабилизация данных, автоматизация рутины, персонализация. Через 14 недель карта 301 и мониторинг GSC сохранили трафик. Критично было не «переписать всё», а остановить утечку лидов на стыке каналов.

Кейс B (новый бренд). Другая ситуация: формы без CRM. Здесь сработала обратная стратегия — сначала интеграция с CRM и нормализация справочников, затем редизайн витрины. Итог: smoke-тест лидов до go-live поймал сломанный webhook.

Формы и коммуникации

1. Переключать DNS без снижения TTL заранее — пользователи и боты кэшируют старый IP часами.
2. Оставлять noindex или пароль staging-окружения на проде после переноса конфигурации.
3. Не тестировать формы с реального SMTP прод-домена — письма уходят в спам или не уходят вовсе.
4. Запускаться в пятницу вечером без дежурного, способного откатить релиз.
5. Забывать сообщить рекламным кабинетам и партнёрам о смене доменов и UTM-разметки до, а не после запуска.

Контент и юридическое

• [ ] Все тексты вычитаны редактором, даты и цены актуальны
• [ ] Есть оферта, реквизиты и политика конфиденциальности с реальными данными компании
• [ ] Формы содержат чекбокс согласия на обработку персональных данных
• [ ] Изображения и шрифты используются по лицензии, alt-тексты заполнены
• [ ] Страницы 404 и технические уведомления не содержат заглушек вроде «Lorem ipsum»
• [ ] Юрист согласовал пользовательское соглашение и cookie-баннер под вашу юрисдикцию

Go-live и откат

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

Добавьте в чеклист проверку писем с prod-домена: SPF, DKIM, DMARC — иначе заявки уйдут в spam у клиента. Зафиксируйте владельца go/no-go решения письменно в Slack или email — устное «можно запускать» не защитит при инциденте.

• Rollback план и бэкап БД
• Uptime и synthetic checks
• Robots/sitemap на проде

Pre-launch контроль

Перед запуском пройдите технику, контент, legal, analytics. Техника: SSL, редиректы www/https, 404/500, формы (в т.ч. spam), письма, мобильная вёрстка, favicon, Open Graph. Контент: опечатки, контакты, цены, политика конфиденциальности. Analytics: счётчики, цели, e-commerce если нужно, фильтрация internal IP. SEO: title/description, robots, sitemap submit.

Сделайте rollback plan: snapshot DB, tag релиза, кто дежурит 48 часов после go-live. Прогон аудита сайта за неделю до даты снижает риск «забыли noindex на prod». Чек-лист подписывает product owner, не только dev — бизнес принимает запуск.

Проверьте отправку форм с реальных устройств и корпоративных VPN — часто SMTP режет prod. Тестовый заказ или заявка end-to-end в CRM. Cookie banner и согласия на аналитику для EU/РФ по вашей модели. Нагрузочный smoke: 50 одновременных на главную не должны валить origin. Договоритесь о war room на 24–48 ч после переключения DNS.

Проверьте legal: оферта, реквизиты, cookie, согласие на рассылку. Для рекламы — pixel и consent mode до первого клика по кампании.

Сделайте скриншоты ключевых страниц и JSON-LD в архив релиза — при откате проще сверить, что восстановили.