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

Как отделить проблему от мнения

Каждое наблюдение записывайте в пяти полях: место, факт, влияние, рекомендация и проверка. «Сделать современнее» — мнение. «На ширине 360 пикселей кнопка выходит за экран и недоступна без горизонтальной прокрутки» — проверяемая проблема.

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

1–5. Предложение и доверие

1. Совпадает ли страница с намерением

Сравните запрос или рекламное обещание с заголовком и первым экраном. Человек должен увидеть продолжение своей задачи, а не универсальное приветствие компании.

2. Понятны ли аудитория и результат

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

3. Видны ли границы

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

4. Есть ли доказательства нужного типа

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

5. Понятен ли следующий шаг

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

6–10. UX, мобильный сценарий и форма

6. Читается ли иерархия

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

7. Работает ли навигация

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

8. Нет ли мобильных потерь

Проверьте 320–390 пикселей, увеличение текста, длинные слова, таблицы, фиксированные элементы и экранную клавиатуру. Горизонтальный скролл часто выдаёт реальную недоступность действия.

9. Понятна ли форма

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

10. Доступен ли основной путь

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

11–15. Техническое качество

11. Загружается ли главное без лишней задержки

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

12. Стабилен ли макет

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

13. Нет ли ошибок в консоли и сети

Ищите 404 ресурсов, смешанный контент, исключения JavaScript и запросы, которые не завершаются. Проверьте не только главную.

14. Защищён ли публичный контур

HTTPS, базовые заголовки безопасности, отсутствие секретов в клиентском коде, ограничения формы и безопасные cookies — минимальный набор, который уточняется по архитектуре.

15. Есть ли безопасный релиз

Проверьте резервную копию, воспроизводимый скрипт, конфигурацию до перезагрузки, публичный smoke и понятный откат. Успешная загрузка файлов ещё не означает готовый релиз.

16–20. Техническое SEO и содержание

16. Доступна ли индексация

Проверьте код ответа 200, robots meta, robots.txt и отсутствие случайной защиты. Канонический адрес должен указывать на выбранную индексируемую версию.

17. Уникальны ли title, description и H1

Они описывают отдельное поисковое намерение страницы. Массовые страницы с одинаковым смыслом создают каннибализацию, а не охват.

18. Есть ли полезный HTML-контент

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

19. Связаны ли страницы

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

20. Корректны ли данные представления

Open Graph улучшает карточку ссылки. Schema.org должна соответствовать видимому содержанию и реальному типу сущности, а не добавляться ради обещания расширенного сниппета.

21–25. Заявка и измерение

21. Доходит ли лид на сервер

Отправьте реальную тестовую заявку по публичному адресу и проверьте запись. Клиентское сообщение об успехе не является доказательством доставки.

22. Сохраняется ли источник

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

23. Есть ли ответственный и срок

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

24. Фиксируется ли причина результата

Закрытие «неуспешно» без причины не помогает продукту. Используйте небольшой, устойчивый справочник и возможность добавить контекст.

25. Возвращается ли результат в аналитику

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

Как расставить приоритеты

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

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

1) безопасность и потеря данных; 2) недоступное действие; 3) индексация и код ответа; 4) ясность предложения; 5) скорость и доступность; 6) гипотезы роста; 7) декоративная полировка.

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