Чек-лист тестирования сайта перед запуском

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

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

Первым делом проверяем, корректно ли сайт открывается по основному домену и по HTTPS. SSL-сертификат должен быть действующим, выпущенным для нужного домена и корректно подключенным ко всем рабочим версиям сайта. Если сертификат отсутствует или настроен неправильно, браузер может показывать предупреждение о небезопасном соединении, что снижает доверие пользователей и способно привести к потере заявок. Также важно убедиться, что внутренние ссылки, canonical, sitemap.xml и другие технические элементы используют HTTPS-адреса и не ссылаются на устаревшую HTTP-версию.

Если запускается новая версия уже существующего сайта, до внесения изменений мы рекомендуем зафиксировать исходные SEO-показатели:

• позиции по приоритетным запросам;
• органический трафик;
• индексируемые страницы;
• количество конверсий;
• наиболее посещаемые посадочные страницы;
• текущие ошибки в Яндекс.Вебмастере и Google Search Console.

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

Следующий этап — проверка зеркал и редиректов.

Нужно открыть сайт в нескольких вариантах:

• http://site.ru;
• https://site.ru;
• http://www.site.ru;
• https://www.site.ru.

Все неосновные варианты должны последовательно приводить к выбранной основной версии сайта. Желательно избегать лишних цепочек перенаправлений.

Например, вместо:

http → https → www → финальный URL

лучше настроить прямой переход на основной адрес.

Одновременно проверяем:

• robots.txt;
• sitemap.xml;
• canonical;
• доступность CMS;
• доступы к хостингу;
• доменному регистратору;
• базе данных;
• аналитике;
• инструментам веб-мастеров.

В sitemap.xml желательно включать только канонические URL, которые действительно должны индексироваться и возвращают корректный ответ сервера.

А в robots.txt не должно оставаться временного запрета вроде:

Disallow: /

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

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

Технический аудит: как найти ошибки, которые не видны глазу

Техническая проверка позволяет обнаружить проблемы, которые невозможно заметить при обычном просмотре сайта. В своей работе мы используем краулеры, данные серверных ответов, Яндекс.Вебмастер, Google Search Console и дополнительные инструменты анализа.
Краулер помогает увидеть структуру сайта так, как ее видит поисковый робот.

Проверяем:

• URL с кодом 404;
• серверные ошибки 5xx;
• внутренние редиректы;
• цепочки перенаправлений;
• циклические редиректы;
• дубли страниц;
• canonical;
• Title и Description;
• H1;
• глубину вложенности;
• закрытые от индексации страницы;
• orphan pages;
• структуру внутренней перелинковки.

Особенно внимательно необходимо анализировать HTTP-коды ответа.
Страница может выглядеть нормально для пользователя, но при этом возвращать неправильный статус. Например, так называемый soft 404 визуально показывает сообщение «страница не найдена», но сервер отвечает кодом 200.

Для поисковой системы это создает путаницу.
Обратная ситуация — рабочая страница периодически возвращает 500 или 503 из-за серверной ошибки. Такие проблемы могут проявляться только под нагрузкой или при определенных сценариях, поэтому автоматический обход желательно дополнять анализом логов.

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

• проверку кодов ответа всех важных URL;
• анализ HTTP/HTTPS и www/non-www версий;
• поиск дублей;
• проверку Title, Description и H1;
• анализ canonical;
• проверку robots.txt;
• проверку sitemap.xml;
• поиск битых внутренних ссылок;
• оценку скорости загрузки;
• проверку мобильной версии;
• контроль индексируемости страниц.

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

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

Robots.txt и sitemap.xml также проверяем не формально, а в связке с реальной структурой сайта.

Типичные проблемы:

• в robots.txt закрыт коммерческий раздел;
• в sitemap находятся 404;
• в sitemap попали URL с noindex;
• карта сайта содержит редиректы;
• присутствуют технические параметры;
• sitemap давно не обновлялся;
• CMS генерирует несколько карт с дублями.

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

Юзабилити и пользовательский опыт: что проверить на каждом устройстве

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

Проверяем:

• меню;
• шапку;
• формы;
• CTA;
• таблицы;
• фильтры;
• слайдеры;
• изображения;
• всплывающие окна;
• размеры текста;
• область нажатия кнопок;
• горизонтальную прокрутку.

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

Интерактивные элементы проверяем отдельно:

• выпадающие меню;
• аккордеоны;
• табы;
• фильтры;
• модальные окна;
• калькуляторы;
• формы;
• слайдеры.

То, что работает мышью на десктопе, может вести себя иначе при касании пальцем.
Отдельный блок проверки — производительность.

Оцениваем:

• скорость первого отображения;
• загрузку основного контента;
• визуальные смещения;
• реакцию интерфейса;
• вес изображений;
• количество сторонних скриптов.

Ориентироваться только на условное правило «сайт должен открываться за три секунды» не стоит. Корректнее анализировать показатели Core Web Vitals и реальные данные пользователей, если они уже накоплены.

Для тестирования можно использовать следующие инструменты:

Функциональное тестирование: как проверить все формы и сценарии

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

Корректные данные

Пользователь заполняет все поля правильно и отправляет форму.

Проверяем:

• появилось ли сообщение об успешной отправке;
• пришли ли данные на email;
• попала ли заявка в CRM;
• зафиксировалась ли цель в аналитике;
• не произошло ли повторной отправки.

Пустые поля

Система должна понятно показать, какие данные необходимо заполнить.

Некорректный формат

Проверяем:

• email;
• телефон;
• обязательные чекбоксы;
• ограничения длины.

Повторное нажатие

Двойной клик по кнопке не должен создавать несколько одинаковых лидов.

Ошибка сервера

Пользователь должен получить понятное сообщение, а не бесконечный loader.
Важно проверить не только визуальное сообщение «Заявка отправлена», но и фактическое поступление данных.
Нередко форма успешно отображает финальный экран, но информация не приходит в CRM из-за ошибки API, SMTP или webhook.

Для интернет-магазина сценариев еще больше.

Тестируем полный цикл: добавление товара → корзина → изменение количества → промокод → доставка → оформление → оплата → подтверждение заказа.

Отдельно проверяем:

• товар закончился во время оформления;
• пользователь вернулся с платежной страницы;
• платеж отклонен;
• промокод просрочен;
• промокод применен повторно;
• заказ оформляется гостем;
• заказ оформляется авторизованным пользователем;
• изменяется адрес доставки.

В личном кабинете тестируем:

• регистрацию;
• авторизацию;
• восстановление пароля;
• изменение данных;
• историю заказов;
• права доступа.

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

Контент и метаданные: как не потерять позиции из-за мелочей

Контентная и SEO-проверка перед запуском особенно важна при переносе уже существующего сайта.
Даже небольшие ошибки могут привести к тому, что поисковая система начнет индексировать не те URL, потеряет старые страницы или выберет неверную каноническую версию.

Для каждой важной страницы проверяем:

• Title;
• Description;
• H1;
• структуру H2-H3;
• текст;
• изображения;
• alt;
• canonical;
• URL;
• хлебные крошки;
• внутренние ссылки.

Title и Description не должны массово дублироваться.
При этом не стоит оценивать их только по количеству символов. Важнее, чтобы метаданные соответствовали странице, были информативными и помогали пользователю понять содержание результата в поиске.

H1 должен описывать основную тему страницы.
Жесткое правило «на странице всегда обязан быть только один H1» не стоит превращать в техническую догму, однако для коммерческих и SEO-посадочных страниц мы рекомендуем использовать понятную и предсказуемую структуру с одним основным заголовком.
H2 и H3 должны формировать логическую иерархию контента, а не использоваться исключительно ради размера шрифта.

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

Отдельно проверяем ЧПУ. При этом наличие ключевого слова непосредственно в URL не является обязательным условием хорошего ранжирования.

Главные требования к адресу:

• стабильность;
• краткость;
• читаемость;
• отсутствие лишних параметров;
• понятная структура.

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

Хлебные крошки помогают пользователю понять свое место в структуре сайта и упрощают навигацию. Они также могут использоваться поисковыми системами для понимания иерархии страниц.

При переносе существующего проекта отдельно готовим таблицу: старый URL → новый URL → тип редиректа. Это один из наиболее важных SEO-документов при редизайне.

Безопасность и защита данных: что должен знать каждый владелец

Безопасность необходимо проверять до запуска, а не после первого инцидента. Особенно внимательно стоит относиться к сайтам на популярных CMS и проектам с большим количеством сторонних расширений.

Проверяем:

• актуальность CMS;
• версии плагинов и модулей;
• административные аккаунты;
• пароли;
• двухфакторную аутентификацию;
• права доступа;
• резервные копии;
• HTTPS;
• формы;
• загрузку пользовательских файлов;
• серверные логи.

Неиспользуемые плагины лучше удалить, а не просто отключить.

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

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

Особого внимания требуют:

• формы загрузки файлов;
• личный кабинет;
• платежные данные;
• API;
• административные панели.

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

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

Поэтому стратегия backup должна учитывать:

• интенсивность обновления данных;
• размер проекта;
• допустимую потерю информации;
• возможности восстановления.

Копии желательно хранить отдельно от основного сервера.

Важно проверять не только создание резервной копии, но и возможность реально восстановить из нее сайт.

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

Перед финальным релизом мы объединяем результаты всех предыдущих проверок в единый чек-лист.

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

Вручную в первую очередь тестируем:

• основные шаблоны страниц;
• ключевые коммерческие URL;
• формы;
• пользовательские сценарии;
• оплату;
• личный кабинет;
• мобильную версию.

Практический порядок проверки:

• Соберите список основных типов страниц и критичных URL.
• Сравните старую и новую структуру, если проводится перенос сайта.
• Проверьте редиректы со старых адресов на новые.
• Создайте тестовые аккаунты с разными уровнями прав.
• Проверьте ограничения доступа.
• Протестируйте все формы.
• Убедитесь, что заявки доходят до CRM и почты.
• Проверьте мобильную версию.
• Оцените скорость и Core Web Vitals.
• Проверьте robots.txt, sitemap.xml и canonical.
• Убедитесь, что production-сайт открыт для индексации.
• Проверьте консоль браузера на критичные JavaScript-ошибки.
• Настройте системы аналитики.
• Проверьте достижение целей.
• Выполните финальный контроль после переноса на рабочий домен.

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

После исправления ошибок необходимо проводить повторное тестирование затронутых сценариев. Если изменение касалось общего шаблона, например шапки или карточки товара, проверять нужно не одну страницу, а несколько URL этого типа.
После публикации работа также не заканчивается.

В первые дни желательно контролировать:

• ошибки сервера;
• работу форм;
• статистику аналитики;
• индексацию;
• новые 404;
• редиректы;
• конверсии;
• поисковый трафик.

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

Частые ошибки при тестировании и как их избежать

Одна из самых распространенных ошибок — проверка сайта только на устройстве разработчика.

То, что корректно выглядит на большом мониторе в Chrome, может работать иначе:

• на небольшом смартфоне;
• в Safari;
• на Android;
• при медленном соединении;
• при использовании сенсорного управления.

Поэтому тестировать нужно не один экран, а несколько реальных пользовательских сценариев и устройств.

Вторая ошибка — проверять только успешный сценарий.

Например: пользователь ввел правильные данные → нажал кнопку → получил сообщение.

Но реальный посетитель может:

• оставить поле пустым;
• ошибиться в email;
• дважды нажать кнопку;
• потерять интернет;
• вернуться назад;
• обновить страницу;
• закрыть окно оплаты;
• попытаться оформить отсутствующий товар.

Система должна корректно обрабатывать и такие ситуации.

Третья распространенная ошибка — откладывать настройку аналитики на период после запуска.

В этом случае первые посетители уже приходят на сайт, а команда не может понять:

• откуда они пришли;
• какие страницы посещают;
• отправляют ли заявки;
• где возникают ошибки;
• какие каналы работают.

Поэтому до релиза необходимо проверить:

• счетчики;
• цели;
• ecommerce-события, если они используются;
• UTM-разметку;
• передачу заявок;
• интеграцию с CRM.

Четвертая ошибка — запуск без SEO-проверки.

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

• изменившихся URL;
• отсутствующих редиректов;
• закрытого robots.txt;
• неправильного canonical;
• удаленных SEO-страниц;
• потерянной перелинковки;
• массового изменения метаданных.

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

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