Проверка сайта на ошибки: технический, SEO и конверсионный чек-лист

Проверка сайта на ошибки должна отвечать на четыре вопроса: доступен ли сайт, могут ли поисковые системы правильно его обходить, выполняет ли пользователь целевое действие и фиксирует ли аналитика результат. Список из сотен автоматических предупреждений без приоритета мало полезен. Хороший аудит воспроизводит проблему, указывает конкретный URL, способ воспроизведения и доказательство, объясняет влияние и даёт порядок исправления. Проверяйте production и ключевые шаблоны: главную, услуги, листинг, карточку, статью, форму, оплату или кабинет. Один успешный URL не доказывает здоровье всего сайта.

1. Доступность и HTTP

Проверьте коды 200, редиректы, 404 и 5xx. Редирект должен вести за один понятный шаг, сохранять нужный путь и не создавать цикл. Несуществующий URL возвращает настоящий 404, а не 200 с текстом ошибки. HTTPS работает на основном домене и вариантах, сертификат действителен.

Проверьте сайт с мобильной сети и без авторизации. Важна не только загрузка HTML: иногда сервер возвращает 200 с заглушкой, пустым контентом или ошибкой приложения.

2. Индексация

Robots.txt не должен случайно закрывать рабочие разделы и должен ссылаться на актуальный sitemap. Sitemap содержит только канонические индексируемые URL с 200, без фильтров, поиска, служебных страниц и дублей. Страница не должна одновременно находиться в sitemap и иметь noindex.

Проверьте canonical: обычно он самореферентный и абсолютный. Пагинация, параметры, http/https и www не должны создавать конкурирующие версии. После миграции нужны 301 со старых адресов на релевантные новые.

3. Метаданные и заголовки

У индексируемых страниц уникальны title и description, соответствующие интенту и содержанию. На странице один видимый H1; H2/H3 описывают структуру, а не используются только ради размера шрифта. Title не копируется на десятки URL пагинации или фильтров.

Open Graph влияет на предпросмотр в мессенджерах, но не заменяет поисковые метаданные. Проверяйте абсолютный URL изображения, размер и осмысленный alt. Для JSON-LD используйте фактические данные страницы без скрытых рейтингов и выдуманных цен.

4. Контент и интент

Первые абзацы дают прямой ответ, а не длинное вступление. Страница закрывает один основной интент и ведёт к логичному следующему действию. Несколько материалов не должны конкурировать за один и тот же запрос без различия роли: информационная статья объясняет выбор, коммерческая страница предлагает услугу.

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

5. Скорость и стабильность интерфейса

Измеряйте не только лабораторный балл, но и фактическую загрузку на мобильной сети. Ищите тяжёлые изображения, блокирующие скрипты, шрифты, лишний JavaScript и медленный ответ сервера. Изображения имеют размеры, современные форматы и адаптивные варианты; контент не прыгает после загрузки.

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

6. Мобильная версия и доступность

На ширине 320–480 px нет горизонтального скролла, обрезанных кнопок и перекрытий. Основной текст читаем, поля имеют подписи, focus виден, интерфейс работает клавиатурой. У изображений есть alt по смыслу, декоративные элементы не озвучиваются.

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

7. Формы и конверсия

Пройдите путь заявки как пользователь: понятен ли оффер, что произойдёт после кнопки, какие поля обязательны, работает ли валидация, согласие и сообщение об успехе. Проверьте доставку в реальный канал или безопасный тестовый контур, а не только HTTP 200 на endpoint.

Телефон, email и мессенджеры кликабельны и содержат корректные значения. CTA соответствует странице: аварийная статья ведёт в поддержку, диагностическая — на аудит, коммерческая — к форме услуги.

8. Аналитика

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

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

9. Безопасность

Проверьте обновления, секреты, публичные служебные файлы, права API, rate limit и заголовки. Формы валидируют данные на сервере. Динамический JSON-LD и HTML сериализуются безопасно; пользовательский ввод не попадает в скрипт без экранирования.

Резервная копия считается рабочей после проверки восстановления. Доступы сотрудников разделены, временные ключи отзываются, production не использует debug-режим.

Приоритеты исправления

• P0. Примеры: потеря данных, взлом, недоступная оплата. Действие: ограничить ущерб и исправлять немедленно.
• P1. Примеры: не работает форма, массовые 5xx, закрыта индексация. Действие: исправить до маркетинговых работ.
• P2. Примеры: дубли метаданных, медленная страница, битые ссылки. Действие: запланировать ближайшим циклом.
• P3. Примеры: косметика без влияния на задачу. Действие: делать после подтверждённых разрывов.

Приоритет зависит от трафика и бизнеса. Ошибка на одной служебной странице и ошибка на основной форме не равны, даже если инструмент показывает одинаковый тип.

Что должно быть в отчёте

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

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

Самостоятельная быстрая проверка

1. Откройте ключевые страницы с телефона и desktop.
2. Проверьте title, description, canonical, H1 и код ответа.
3. Пройдите меню, ссылки и форму.
4. Посмотрите консоль и failed-запросы.
5. Откройте robots.txt и sitemap.
6. Проверьте 404 и один старый редирект.
7. Сверьте доставку тестовой заявки и событие аналитики.
8. Запишите проблемы с URL и приоритетом.

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

Когда нужен внешний аудит

Он полезен перед рекламой, миграцией, редизайном, падением заявок и после серии непонятных сбоев. Независимый специалист проверяет не только код, но и связность инфраструктуры, SEO и конверсионного пути. На странице экспресс-аудита зафиксирован текущий формат Za IT: 4 999 ₽, 1–2 рабочих дня, список багов и план действий.

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

Вывод

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