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

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

Тестирование сайта перед запуском начинается не с дизайна и не с текстов, а с базовой инфраструктуры. Первым делом проверьте, открывается ли ресурс по основному зеркалу (с www или без, как задумано) и по протоколу HTTPS. Если SSL-сертификат не настроен или работает некорректно, браузер будет пугать посетителей предупреждением о небезопасном соединении, и часть трафика вы потеряете ещё до того, как пользователь увидит контент. Убедитесь, что сертификат выпущен на нужный домен и не истёк, а также что все внутренние ссылки в коде ведут на https-версию. Если сайт уже участвует в поиске, но вы планируете его доработку, важно зафиксировать текущие позиции и метрики, чтобы потом оценить эффект от изменений; в этом случае будет полезно приступить к продвижению с чистой технической базой, а не после возникновения проблем.

Дальше проверяем редиректы и зеркала. Откройте сайт по адресам с www и без, с HTTP и HTTPS, убедитесь, что все варианты ведут на главное зеркало с кодом 301, а не 302. В противном случае поисковики могут склеить дубли или выбрать не то зеркало, что размажет ссылочный вес. Заодно посмотрите robots.txt и sitemap.xml: в robots не должно быть случайных запретов для основных разделов, а в карте сайта должны лежать только реально существующие страницы с кодом 200. Если сайт вообще не открывается, проверьте в первую очередь доступы к хостингу и CMS, возможно, проблема в истёкшем домене или упавшем сервере. Все доступы (к панели хостинга, CMS, доменному регистратору, базе данных) соберите в одном месте, чтобы в критический момент не искать их по почте. Это скучная, но обязательная часть работы, которая избавит от головной боли при запуске.

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

Технический аудит начинается задолго до визуальной проверки. Мы обычно прогоняем сайт через Screaming Frog, параллельно сверяясь с отчётами в Яндекс.Вебмастере и Google Search Console. Краулер за пару минут показывает полную картину структуры: битые ссылки, редиректы, дубли страниц и проблемы с мета-тегами. Особое внимание стоит уделить кодам ответа сервера. 404 и 500 заметны не всегда, особенно если страница отдаёт ошибку только определённым ботам или при определённых параметрах запроса.

В нашей практике был случай, когда интернет-магазин терял до 30% трафика с мобильных устройств. Визуально всё работало, но сервер отдавал 500-ю ошибку на запросы с определённых мобильных браузеров. Нашли только благодаря логам и повторному сканированию с разными user-agent. После тестирования функциональности стоит обратить внимание на поведенческие метрики, так как высокий показатель отказов может указывать на проблемы с юзабилити или контентом, о чём мы подробно писали в статье как снизить показатель отказов на сайте. Список ключевых проверок выглядит так:

• Проверка кодов ответа для всех URL из sitemap.xml через Screaming Frog или аналог.
• Сравнение версий сайта с www и без, http и https, исключение дублей.
• Анализ мета-тегов на длину, дубли и отсутствие title у важных страниц.
• Проверка скорости загрузки через PageSpeed Insights или GTmetrix, особенно для мобильной версии.

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

Файл robots.txt и sitemap.xml тоже часто содержат сюрпризы. Бывает, что в robots.txt случайно закрыт целый раздел каталога, а в sitemap попадают страницы с noindex или служебные URL с параметрами. Проверять нужно не только синтаксис, но и фактическую доступность путей, указанных в директивах. Если в sitemap заявлено 10 тысяч страниц, а краулер находит только 7 тысяч, это повод разобраться, куда делись остальные.

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

Адаптивность вёрстки проверяем не только по контрольным точкам в DevTools. Откройте сайт на реальных устройствах: десктоп, планшет, смартфон. Критичные места — меню, формы, кнопки, читаемость шрифтов. Горизонтальный скролл на мобильных — признак проблемы, которую пользователь не простит. Для быстрой проверки подойдут онлайн-сервисы вроде BrowserStack, но финальное решение принимайте на живом железе. Тепловые карты помогают визуализировать поведение пользователей, что полезно при проверке удобства интерфейса и выявлении проблемных зон перед запуском, поэтому тепловая карта сайта часто входит в наш арсенал на этом этапе.

Интерактивные элементы тестируем на каждом устройстве отдельно: выпадающие меню, табы, слайдеры, формы обратной связи. На планшетах часто срабатывает hover-состояние, которое не переходит в клик. Скорость загрузки на мобильных проверяем через Lighthouse в Chrome DevTools и GTmetrix. Если сайт грузится дольше 3 секунд на 4G, это повод оптимизировать изображения и отложенную загрузку скриптов. В таблице ниже собрали инструменты, которые используем для технической проверки.

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

Формы обратной связи проверяем по единому сценарию: отправка с валидными данными, отправка с пустыми полями, с неверным форматом email и с опечатками в теле сообщения. После каждого теста смотрим, доходит ли письмо до почтового ящика и не падает ли запись в базу данных. Частая история: форма показывает «сообщение отправлено», а письмо так и не приходит, потому что на сервере не настроен SMTP или письмо уходит в спам. Второй типовой сбой, когда данные вообще не сохраняются, например, из-за неверно указанного атрибута name у поля, поэтому всегда проверяем не только визуальный отклик, но и фактическую запись в CRM или админке.

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

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

Контент и метаданные часто становятся источником незаметных, но болезненных потерь в выдаче. Дубли страниц, сгенерированные CMS фильтры или забытые мета-теги на новых посадочных могут «склеить» позиции или отправить страницу в поиск без сниппета. Мы обычно прогоняем тексты через «Яндекс.Вебмастер» и Search Console, проверяя, какие страницы попали в раздел «Исключено», и параллельно смотрим на уникальность методом шинглов вручную. Если видим, что на сайте появляются служебные страницы с одинаковым описанием, это повод добавить их в robots.txt или закрыть через мета-тег noindex, иначе поисковик начнёт ранжировать их вместо основных.

Заголовки H1-H3 должны чётко отражать структуру раздела, а не быть «рыбой» из визуального редактора. Проверьте, что на каждой странице один H1, а остальные уровни логично вложены. Alt-атрибуты у изображений не только помогают индексации, но и закрывают потребность в текстовом описании для слабовидящих. ЧПУ и хлебные крошки тоже влияют на восприятие: URL вида /catalog/item/12345 без ключевого слова в адресе работает хуже, чем транслитерированный вариант. На практике мы часто видим, как правильно настроенные крошки снижают глубину входа и уменьшают процент отказов, а это прямой сигнал для ранжирования.

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

Безопасность часто воспринимают как то, что «потом как-нибудь». На практике это самый недооценённый пункт чек-листа тестирования сайта перед запуском. Слабый пароль от админки, необновлённый плагин или незакрытая SQL-инъекция превращают сайт в лёгкую добычу для автоматических сканеров. Проверить хотя бы базовые вещи несложно: в Яндекс.Вебмастере и Search Console есть разделы с уведомлениями о вредоносном коде, а для первичного сканирования подойдут онлайн-сервисы вроде VirusTotal или Quttera. Если сайт на CMS, достаточно заглянуть в логи и убедиться, что нет подозрительных POST-запросов к формам.

Отдельно настройте бэкапы до того, как они понадобятся. Мы обычно рекомендуем схему «ежедневная копия базы + еженедельная полная копия файлов» с хранением на внешнем хранилище, чтобы взлом сервера не уничтожил и резервные копии. Обновление ядра и модулей не менее важно: устаревший плагин это открытая дверь для XSS-атак. Включите автообновления для мелких патчей, но крупные релизы лучше проверять на тестовой копии, чтобы не сломать вёрстку. Эти меры не гарантируют абсолютную защиту, но закрывают 90% типовых сценариев взлома, с которыми сталкиваются владельцы сайтов.

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

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

• Составьте полный список URL из Яндекс.Вебмастера и Search Console, сверьте его с картой сайта, добавьте страницы с UTM-метками.
• Заведите тестовые аккаунты с разными ролями и проверьте, что пользователь без прав не получает доступ к админке.
• Проверьте редиректы со старых адресов на новые через Screaming Frog, обратите внимание на цепочки из трёх и более переходов.
• Протестируйте все формы, включая подписку на рассылку, и убедитесь, что письма реально уходят на тестовый ящик.
• Проверьте скорость загрузки на мобильных устройствах через PageSpeed Insights, а не только на десктопе.
• Сделайте финальный проход по чек-листу с включённой консолью браузера, чтобы отследить ошибки JavaScript.

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

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

Самая частая ошибка при тестировании перед запуском, которую мы видим у клиентов, это проверка только на одном устройстве. Разработчик открыл сайт на своём MacBook, всё выглядит идеально, и он передаёт проект. Через неделю владелец бизнеса открывает его на Android-смартфоне и обнаруживает, что кнопки съехали, а форма не отправляется. На практике это выливается в потерю заявок с мобильного трафика, который часто составляет больше половины. То же касается скорости: если вы проверяете сайт на локальном сервере, вы не увидите реальные 3–5 секунд загрузки, которые увидит пользователь. Всегда прогоняйте финальную версию через PageSpeed Insights и смотрите на реальные данные, а не на ощущения.

Вторая системная ошибка, отсутствие тестовых сценариев, приводит к тому, что вы проверяете только «счастливый путь»: заполнил форму, отправил, увидел сообщение. А что если пользователь введёт некорректный email? Что если поле оставить пустым? Что если нажать кнопку дважды или отправить форму с пустой корзиной? Мы обычно составляем список из 20–30 критичных сценариев, включая обработку ошибок, и прогоняем их на всех ключевых страницах. Наконец, игнорирование аналитики до запуска это время, потраченное впустую. Если счётчики и цели не настроены, после старта вы не увидите, где посетители уходят, и будете гадать, что сломано. Проверьте, что события отправляются, цели фиксируются, а данные в Вебмастере и Search Console приходят. Если этот этап вызывает сложности, агентство Cinar решает такие задачи в рамках комплексного аудита, но базовую проверку по этому списку вы можете выполнить и самостоятельно за пару часов.

Часто задаваемые вопросы

Константин Крючков

Senior SEO-специалист

Подписаться на ТГ