Контрольный список перед запуском сайта

Быстрые ссылки

• Тест совместимости браузеров и мобильных устройств
• Тест скорости
• Удовлетворить Google (SEO)
• Проверить доступность
• Установить инструмент аналитики

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

Что нужно проверить в первую очередь

Перед релизом разделите работу на пять областей: совместимость, производительность, SEO, доступность и аналитика. Каждая область имеет свои тесты, критерии приёмки и ответственных.

Совместимость браузеров и мобильных устройств

Проблема: вы, вероятно, используете один браузер, а посетители — разные. Браузеры по‑разному обрабатывают CSS и JavaScript. Тестирование должно охватить основные движки и разные разрешения экрана.

Что делать

• Проверить сайт в Chrome, Firefox, Edge и Safari. Сверьте визуально и функционально.
• Идентифицируйте особенности CSS или JS, которые могут ломаться. Например, intrinsic & extrinsic sizing:

width: fit-content

Иногда работает ненадёжно в некоторых версиях Firefox — добавьте fallback‑стили.

• Решите, поддерживаете ли вы Internet Explorer 11. Большинство современных фич могут не работать в IE, и поддержка потребует полифиллов и фолбэков.
• Используйте сервис Can I Use для проверки поддержки свойств и API.
• Адаптивный дизайн: тестируйте не только на телефоне, но и при любых разрешениях экрана. В Chrome это удобно делать через Инструменты разработчика → Responsive.

Практика

• Тестовые параметры: desktop 1366×768, tablet 768×1024, мобильные популярные ширины 360px и 375px. Это отправная точка, но не замена тестов на реальных устройствах.
• Тестируйте реальные устройства и реальные браузеры (iOS Safari на iPhone, Chrome на Android). У устройств разные User‑Agent и поведения.
• Проверьте работу через VPN из другой страны, чтобы выявить региональные проблемы (реклама, CDN‑поведения, редиректы).

Критерии приёмки

• Страницы корректно рендерятся в перечисленных браузерах без критических визуальных сбоев.
• Кнопки и основные формы работают с клавиатуры и мышью.
• Критический путь покупки/регистрации проходит на всех целевых устройствах.

Важно: некритичные визуальные отличия допускаются, если не мешают использованию.

Тест скорости

Почему это важно

Пользователи быстро уходят с медленных страниц. Время загрузки влияет на поведение посетителей и на SEO.

Инструменты и методика

• Используйте Google PageSpeed Insights для анализа настольной и мобильной версий. Он показывает рекомендации и общий профиль производительности.

• Дополнительно прогоняйте тесты в Lighthouse, WebPageTest и в реальных условиях мобильной сети с различной задержкой и скоростью.
• Измеряйте ключевые метрики: First Contentful Paint, Largest Contentful Paint, Total Blocking Time, Cumulative Layout Shift. Эти термины определяют пользовательский опыт загрузки.

Рекомендации по исправлению

• Оптимизируйте изображения: современный формат (WebP/AVIF) и адаптивные srcset. Сжимайте и используйте lazy loading для нефрого контента.
• Минифицируйте и комбинируйте критические CSS и JS, выносите несущественные скрипты в defer/async.
• Используйте HTTP/2 или HTTP/3 и корректную конфигурацию CORS/Cache headers.
• Настройте CDN для статики и длительные заголовки кеширования с версионированием файлов.

Критерии приёмки

• PageSpeed Insights не обязательно должен быть идеальным, но основные показатели должны соответствовать целям проекта (например, LCP под разумное время, CLS минимален).
• Время ответа сервера и время загрузки первой значимой части страницы соответствует ожиданиям для целевой аудитории.

Примечание: не гонитесь за абсолютным числом в PSI — сосредоточьтесь на реальном опыте пользователей.

Удовлетворить Google и другие поисковые системы (SEO)

SEO охватывает множество задач. Ниже — базовый набор, который обеспечивает индексирование и базовую видимость.

Базовые проверки

• Используйте инструменты типа Moz, Ahrefs, Screaming Frog для аудита: они покажут ошибки, метаданные и битые ссылки.

• Создайте XML sitemap. Он помогает поисковым системам находить страницы. Генерируйте автоматически или через плагин, если сайт на CMS.

  Пример директивы для robots.txt:

Sitemap: https://example.com/sitemap.xml

• Проверьте robots.txt, чтобы случайно не закрыть сайт от индексации. Исключите только служебные пути, такие как /wp-admin.
• Настройте Open Graph и Twitter Card метаданные для корректного предпросмотра и встраивания страниц.
• Рассмотрите внедрение структурированных данных (JSON‑LD) для статей, продуктов, событий. Это увеличивает шанс получения расширенных сниппетов.
• Если используете AMP, проверьте валидность AMP через инструменты Google. AMP ограничивает JavaScript (разрешён только amp-script с ограничениями).
• Валидируйте HTML на предмет серьёзных ошибок. Полная W3C‑валидация не обязательна, но критические ошибки следует исправить.

Критерии приёмки

• Сайт индексируется поисковыми системами по ключевым страницам.
• Наличие sitemap и корректных robots.txt правил.
• Корректные метаданные для социальных сетей.

Альтернативный подход

• Если ваш трафик почти весь платный, акцентируйте усилия на целевых посадочных страницах и трекинге конверсий, а не на полном SEO‑аудите.

Доступность сайта

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

Основные шаги

• Добавляйте alt‑тексты ко всем изображением и иллюстрациям. Они описывают содержимое для скрин‑ридеров.

• Отмечайте основные landmarks (header, nav, main, footer) и используйте семантические теги.
• Проверьте последовательность заголовков (h1 → h2 и т. д.) и их логическую иерархию.
• Убедитесь, что все интерактивные элементы доступны с клавиатуры и получают фокус.
• Проверьте контраст текста и фонов (инструменты показывают значение контраста). Тоже важно для людей с нарушением зрения.
• Лейблы форм и aria‑атрибуты: убедитесь, что формы имеют понятные подписи и error‑сообщения, которые доступны для скрин‑ридеров.
• Применяйте инструменты для локального тестирования: tota11y от Khan Academy даёт быстрый визуальный отчёт о проблемах доступа.

Критерии приёмки

• Ключевые страницы проходят базовый аудит доступности без критических нарушений.
• Формы работают с клавиатуры и корректно озаглавлены.

Когда автоматические инструменты не помогают

• Автоматические сканеры находят большинство очевидных проблем, но не способны оценить смысл текста в alt или корректность пользовательских сценариев. Проведите ручное тестирование со скрин‑ридером.

Установка инструмента аналитики

Зачем это делать заранее

Аналитика должна собирать данные с первого дня. Без исторических данных вы не сможете понять тренды и эффекты изменений.

Рекомендации

• Установите Google Analytics, Matomo или другой инструмент до релиза. Настройте цель/конверсии и основные события (submit формы, клики по CTA, просмотры страниц).

• Настройте отчёты и дашборды для ответственных лиц (маркетинг, продукт, аналитика).
• Планируйте A/B‑тестирование на посадочных страницах и основных путях конверсии.

Критерии приёмки

• Трекинг установлен и обеспечивает запись основных событий.
• Данные доступны в отчетах и проходят базовую проверку на корректность.

Чек‑лист перед нажатием кнопки «Опубликовать»

Общий чек‑лист (кратко)

• Бэкапы и rollback‑план готовы.
• DNS и SSL корректно настроены.
• Роботс.txt и sitemap валидны и доступны.
• Критические пути протестированы на всех целевых устройствах.
• Основные метрики скорости в целевых пределах.
• Структурированные данные и соцметаданные настроены.
• Скрипты аналитики и трекинг событий работают.
• Доступность основных страниц на уровне без критических ошибок.

Ролевые чек‑листы

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

• Разработчик

  • Проверил сборку и минификацию.
  • Убедился в наличии полифиллов для целевых браузеров.
  • Прогнал unit/integration тесты.

• Дизайнер

  • Проверил визуальную целостность на основных разрешениях.
  • Подготовил и дал alt‑тексты для изображений.

• QA

  • Прогнал сценарии ключевых пользовательских путешествий.
  • Задокументировал найденные баги и убедился в исправлениях.

• Маркетинг

  • Настроил метаданные и метки UTM для кампаний.
  • Подготовил материалы для соцсетей и пресс‑релиз.

• DevOps

  • Подготовил rollback‑план и мониторинг.
  • Проверил конфигурацию CDN и кеширования.

Методика приёмочного тестирования и критерии приёмки

Мини‑методология

1. Определите критические пользовательские пути. Примеры: регистрация, поиск, оплата.
2. Для каждого пути подготовьте тест‑кейсы: предусмотрите нормальные, граничные и негативные сценарии.
3. Выполните тесты в трёх средах: локально (стейдж), предрелизный стенд и прод на момент «мягкого» запуска.
4. Соберите результаты и назначьте приоритеты на исправление.
5. После исправлений повторите регресс‑тест.

Примеры тест‑кейсов

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

Критерии приёмки

• Ключевые пути проходят ручное тестирование без критических ошибок.
• Все блокирующие баги исправлены.
• Для оставшихся недочётов есть планы и оценка риска.

План на случай инцидента и отката изменений

Простой runbook для отката

1. Если продакшн не работоспособен — активируйте план отката.
2. Переключите трафик на старую версию (blue/green или rollback через CI/CD).
3. Отмените последние миграции базы данных, если они несовместимы.
4. Уведомите команду и стейкхолдеров о причинах и ожидаемом времени восстановления.
5. После восстановления запустите root cause analysis.

Важно: держите автоматизированные бэкапы и проверяйте процедуры восстановления заранее.

Ментальные модели и рекомендации

• «Критический путь» — сосредоточьтесь на сценариях, которые приносят доход или самые частые действия пользователей.
• «Fail fast, rollback safely» — в релизе допустимы небольшие фичи, но не допустимы ошибки, разрушающие ядро продукта.
• Приоритизация: исправления классифицируйте как блокирующие, критические, незначительные.

Decision tree для решения, запускать или откладывать релиз

flowchart TD
  A[Готов ли минимальный набор функций?] -->|Нет| B[Откладываем: фиксируем блокирующие баги]
  A -->|Да| C[Проверены критические пути?]
  C -->|Нет| B
  C -->|Да| D[Проведены скоростные тесты?]
  D -->|Нет| E[Оптимизируем и ретестируем]
  D -->|Да| F[SEO и доступность на базовом уровне?]
  F -->|Нет| E
  F -->|Да| G[Аналитика настроена?]
  G -->|Нет| E
  G -->|Да| H[Релиз с мониторингом и планом отката]

Частые ошибки и когда предложенные шаги не работают

• Проблема: «всё локально ок, но прод ломается». Причина: различия конфигурации или данных. Решение: выровнять окружения и прогнать smoke‑тесты на прод‑стенде.
• Проблема: высокие показатели скорости в синтетическом тесте, но плохой UX у реальных пользователей. Решение: проводить полевые замеры и RUM (Real User Monitoring).
• Проблема: автоматические сканеры объявляют сайт доступным, но пользователи жалуются. Решение: ручное тестирование со скрин‑ридерами и тестирование с пользователями.

Контрольный список для 48 часов после запуска

• Мониторинг ошибок на проде (логирование, Sentry, система оповещений).
• Проверка реальных сессий через инструменты RUM и аналитики.
• Соберите обратную связь от команды поддержки и от пользователей.
• Быстрая итерация по критическим замечаниям.

Короткое резюме

• Проверьте совместимость по браузерам и устройствам.
• Уделите внимание скорости и реальному опыту пользователей.
• Настройте SEO‑базу и структурированные данные.
• Сделайте сайт доступным для людей с ограниченными возможностями.
• Включите аналитику и настройте A/B‑тесты для улучшения метрик.
• Подготовьте план отката и держите бэкапы под рукой.

Важно: запуск — не финал, а начало цикла улучшений. Собирайте данные, приоритизируйте проблемы и итеративно улучшайте продукт.