Технический аудит полезен, когда его результат можно превратить в очередь работ: какая ошибка подтверждена, какие страницы или действия она затрагивает, кто её исправляет и как принять результат. Отчёт с сотнями предупреждений без этих ответов оставляет владельцу ту же неопределённость, что была до проверки.
Чтобы провести технический аудит сайта, сначала определите границы проверки, затем пройдите ключевые сценарии и типы страниц. Для каждого найденного отклонения сохраните доказательство и условие повторной проверки. Ниже — рабочий чек-лист для такой диагностики; он не заменяет отдельное исследование безопасности или полноценный аудит поискового продвижения.
Подготовьте выборку и правила проверки
Составьте перечень типов страниц: главная, услуги, категории, карточки, статьи, контакты — только те, которые есть на вашем сайте. Включите страницы, через которые приходят обращения и заказы, недавно изменённые разделы и известные проблемные адреса. У каталога проверьте также пагинацию, фильтры, пустой результат и снятый с продажи товар. Одна исправная главная не подтверждает исправность остальных шаблонов.
Для каждого типа возьмите обычную страницу и подходящий граничный случай: длинное название, отсутствие изображения, пустой раздел. Если ошибка повторяется на одном шаблоне, расширьте проверку именно этого шаблона. В отчёте укажите размер и состав выборки: выборочная проверка не доказывает отсутствие ошибок на всех адресах.
Перед началом зафиксируйте:
- Контур: рабочий сайт или тестовая копия, дата, проверяемая версия и последние изменения.
- Сценарии: что должно происходить после заявки, заказа, поиска или входа в кабинет; кто подтверждает результат со стороны бизнеса.
- Условия: устройства, браузеры, ширина экрана, режим входа, сеть и наличие кэша, если измеряется скорость.
- Доступ: какие кабинеты, журналы ошибок и отчёты доступны; кто может предоставить недостающие сведения.
Используйте тестовые данные и согласованный способ проверки заявок и заказов. Проверки с реальной оплатой, массовый обход, нагрузочные испытания и восстановление поверх рабочего сайта заранее согласуйте с ответственным. Для обычного чек-листа они не нужны.
У каждого пункта должен быть один из четырёх результатов: условие выполнено, ошибка подтверждена, не проверено или не применимо. Последние два требуют причины. Например, без доступа к почте нельзя подтвердить доставку заявки, даже если форма показывает сообщение об успехе.
Назначайте приоритет по последствиям
Используйте простую шкалу очереди исправлений. Это правило работы команды, а не универсальная оценка любого предупреждения сканера.
| Приоритет | Когда назначать | Пример |
|---|---|---|
| P0 — немедленное вмешательство | Основной сценарий недоступен либо подтверждён доступ к чужим данным | Все заявки теряются; пользователь видит чужой заказ |
| P1 — ближайшие работы | Важный раздел или заметная часть целевого сценария работает неправильно | Страницы услуг закрыты от индексации; мобильная форма не отправляется |
| P2 — плановое исправление | Ошибка локальна и не блокирует критический путь | Ссылка в отдельной старой статье ведёт на удалённый материал |
Приоритет зависит от масштаба и контекста. Битая ссылка на основной кнопке заказа и такая же ссылка в архивной заметке требуют разной очередности. Не приписывайте ошибке потерянную выручку без данных: достаточно описать подтверждённое препятствие и затронутый сценарий.
Чек-лист: условие, ошибка и приёмка
1. Важные страницы доступны, ответы сервера соответствуют содержимому
Проверяемое условие. Нужная страница открывается по прямому адресу и через меню, показывает ожидаемый материал, возвращает успешный ответ. Несуществующий адрес показывает понятную страницу отсутствия и код 404, а не пустую страницу с кодом 200. Коды ответов можно посмотреть во вкладке Network инструментов разработчика браузера; при сомнениях попросите разработчика сохранить результат запроса.
Пример ошибки и влияние. Главная работает, но карточки услуги возвращают 500. Посетитель не получает предложение, а длительные серверные ошибки могут мешать обходу сайта поисковыми роботами. Другой случай — ответ 200 с текстом «страница не найдена»: Google может считать его soft 404. Сам по себе код 200 не гарантирует индексацию.
Ответственный и приоритет. Разработчик; при сбое инфраструктуры — также администратор хостинга. P0 для недоступного основного сценария, P1 для важного раздела. Настоящий 404 удалённой страницы сам по себе не является дефектом.
Повторная проверка. Открыть исходные проблемные адреса и другие страницы того же шаблона. Проверить содержимое, код ответа и переход из меню; отдельно повторить запрос к несуществующей странице. Приложить время проверки и результат после исправления.
2. Правила обхода и индексации согласованы с назначением страниц
Проверяемое условие. Для важных публичных страниц не осталось случайного запрета обхода в robots.txt или директивы noindex после разработки. В sitemap перечислены предназначенные для поиска канонические адреса. Отдельно сверены статус индексации и диагностика выбранных страниц в Яндекс Вебмастере и Google Search Console.
Пример ошибки и влияние. Вместе с тестовой версией на рабочий сайт перенесли noindex для всего раздела услуг. Поисковая система получает запрет на включение этих страниц в индекс. Обратная ошибка — считать, что Disallow надёжно скрывает страницу: robots.txt управляет обходом, а запрещённый адрес может появиться в поиске по ссылкам. Чтобы робот увидел noindex, ему нужен доступ к странице.
Ответственный и приоритет. SEO-специалист определяет нужные правила, разработчик реализует и проверяет их. P1 для ошибочно закрытого коммерческого раздела. Служебные и личные данные защищают правами доступа, а не файлом robots.txt.
Повторная проверка. Проверить фактический ответ страницы, директивы и карту на рабочем сайте. После повторного обхода сверить сведения поискового кабинета. Техническое исправление и обновление индекса — разные события; наличие sitemap не гарантирует индексацию. Подробности разобраны в статье о задачах robots.txt и sitemap.xml.
3. Адреса, перенаправления и внутренние ссылки не противоречат друг другу
Проверяемое условие. У страницы есть выбранный основной адрес. Внутренние ссылки и sitemap ведут на него, а canonical не указывает на другую по смыслу, закрытую или отсутствующую страницу. Если адрес действительно заменён, старый ведёт к соответствующему новому материалу без цикла и лишних промежуточных переходов.
Пример ошибки и влияние. В шаблоне всех услуг canonical указывает на главную. Это подаёт поисковой системе неверный сигнал о предпочтительном адресе. Ещё пример — меню ведёт на старый путь, который перенаправляет через несколько промежуточных адресов. Посетителю и роботу приходится проходить лишние переходы. Canonical является сигналом предпочтения, а не безусловной командой поисковику.
Ответственный и приоритет. Разработчик вместе с SEO-специалистом. P1 для ошибки всего шаблона или навигации ключевого раздела, P2 для локальной устаревшей ссылки. Не перенаправляйте все удалённые страницы на главную автоматически: сначала определите, есть ли содержательно подходящая замена.
Повторная проверка. Пройти полный маршрут со старого адреса, проверить конечную страницу, её ответ и canonical. Повторить переход по внутренней ссылке после её обновления. Дубли одной причины объединить в одну задачу со списком затронутых адресов.
4. Шаблоны выводят нужное содержимое, а ресурсы загружаются
Проверяемое условие. На каждом выбранном шаблоне присутствуют основное содержание, понятный заголовок и относящийся к странице title. Важные тексты и переходы не пропадают после выполнения JavaScript. Изображения, стили и скрипты загружаются; в Network и Console нет ошибок, нарушающих проверяемый сценарий. Для важных публичных страниц полезно сравнить отображение в браузере с результатом проверки страницы поисковым инструментом.
Пример ошибки и влияние. У карточки есть адрес и title, но описание и кнопка обращения остаются пустыми из-за ошибки скрипта. Формально страница доступна, однако посетитель не может получить предложение. Либо защищённая страница пытается загрузить скрипт по незащищённому соединению: браузер блокирует такой смешанный контент, и часть функций перестаёт работать.
Ответственный и приоритет. Разработчик; за отсутствующий исходный текст отвечает редактор или владелец контента. P1 для сломанного основного содержимого, P2 для локального некритичного дефекта. Предупреждение консоли само по себе ещё не определяет приоритет — нужен воспроизводимый эффект.
Повторная проверка. Открыть страницу без сохранённого кэша и пройти затронутое действие. Проверить соседние страницы шаблона и состояние без изображения или с длинным текстом. Сверить загрузку ресурсов и относящиеся к ошибке сообщения.
5. Заявка или заказ проходит до согласованного получателя
Проверяемое условие. Форма принимает корректные данные, объясняет ошибку заполнения и позволяет её исправить. После отправки тестовое обращение находится там, где его должен обработать сотрудник: в почте, CRM или другом согласованном месте. Для магазина отдельно подтверждается правильное состояние тестового заказа по предусмотренному сценарию.
Пример ошибки и влияние. Пользователь видит «Спасибо», но обращение не дошло до получателя. Либо ошибка внешнего сервиса отображается как успешная отправка. Бизнес может не получить контакт; проверка только кнопки и сообщения не выявит этот сбой.
Ответственный и приоритет. Разработчик отвечает за передачу и обработку ошибки; сотрудник бизнеса подтверждает приём. P0, если основной канал заявок полностью не работает, P1 для определённой формы или устройства.
Повторная проверка. Повторить успешный и ошибочный сценарии с тестовыми данными, сверить полученную запись и понятность сообщения. Проверить повторное нажатие и возврат к форме: результат должен соответствовать согласованному поведению. Сбой интеграции безопасно воспроизводить на тестовой копии, не отключая рабочую CRM или почту.
6. На телефоне и с клавиатуры можно закончить действие
Проверяемое условие. Меню, кнопки и форма остаются доступны на выбранных мобильных устройствах. Экранная клавиатура и сообщения об ошибках не мешают завершению сценария. При работе обычной клавиатурой можно перейти к полям и кнопке, понять текущий фокус и исправить неверное значение. Поля имеют понятные подписи; ошибка не передаётся одним цветом.
Пример ошибки и влияние. Плавающая панель закрывает кнопку отправки на телефоне. Или форма отмечает поле красной рамкой, но не объясняет проблему. Человек не может закончить обращение, хотя на большом экране ошибка незаметна.
Ответственный и приоритет. Разработчик интерфейса; при необходимости дизайнер уточняет поведение. P1, если целевой сценарий недоступен, P2 для локального неудобства без блокировки.
Повторная проверка. Пройти весь сценарий на устройстве, где возник дефект, и на другом затронутом размере экрана. Проверить длинный текст, увеличение масштаба и ошибку заполнения. Проверка мышью не заменяет отдельного прохождения клавиатурой.
7. Скорость измерена в сопоставимых условиях
Проверяемое условие. Измерения выполнены для ключевых шаблонов, отдельно для мобильного и настольного сценариев. Указаны инструмент, условия, дата и адрес. Лабораторный тест помогает искать причины; данные реальных посещений показывают опыт пользователей. Если реальных данных недостаточно, так и запишите — это не подтверждение хорошей скорости.
Пример ошибки и влияние. Быстро открылась главная с сохранённым кэшем, и результат распространили на весь сайт. Между тем карточка долго показывает главный контент, а при появлении изображения сдвигает кнопку. Это повод проверить соответствующий шаблон и действие, а не просто добиваться высокого общего балла.
Для Core Web Vitals текущие ориентиры хорошего результата — LCP до 2,5 секунды включительно, INP до 200 миллисекунд включительно и CLS до 0,1 включительно. Их оценивают по 75-му перцентилю реальных посещений: отдельно для мобильных и настольных устройств. Это не норматив времени загрузки каждой отдельной страницы. Обычный тест загрузки Lighthouse не измеряет INP без взаимодействий; лабораторный TBT помогает диагностике, но не заменяет полевой INP.
Ответственный и приоритет. Разработчик; при подтверждённой серверной причине — администратор инфраструктуры. P1 для серьёзной задержки или сдвига, мешающего целевому действию; локальная тяжёлая иллюстрация может попасть в P2.
Повторная проверка. Повторить измерения тех же страниц при сопоставимых настройках устройства, сети и кэша. Зафиксировать изменение конкретной метрики и проверить действие пользователя. Полевые данные обновляются с задержкой; один быстрый прогон не подтверждает улучшение для всех. Причины подробнее разобраны в статье о медленной загрузке сайта.
8. Доступы и восстановление имеют проверяемое подтверждение
Проверяемое условие. У ответственных есть перечень административных учётных записей и их ролей; права соответствуют задачам, лишние доступы отозваны. Для проверки разграничения используют согласованные тестовые учётные записи и тестовые данные. У резервной копии известны дата, состав и результат пробного восстановления в изолированной среде.
Пример ошибки и влияние. Кнопку чужого заказа скрыли, но сервер отдаёт данные при прямом обращении. Или резервирование включено, однако из копии не удаётся восстановить файлы загрузок. В первом случае подтверждён риск доступа к чужим данным, во втором — не подтверждена готовность восстановить сайт.
Ответственный и приоритет. За права отвечает разработчик и администратор системы, за резервирование — назначенный ответственный за инфраструктуру. Подтверждённое раскрытие чужих данных требует P0. Непроверенное восстановление фиксируется как отдельный риск; его срочность определяют по критичности сайта и доступным копиям.
Повторная проверка. Проверить разрешённое и запрещённое действие тестовыми ролями на сервере, а не только видимость кнопки. После пробного восстановления пройти ключевой сценарий в изолированной копии. Не помещать пароли, токены и персональные данные в отчёт. Этот пункт не даёт основания объявить сайт полностью безопасным: более глубокая проверка требует отдельного объёма работ.
Превратите находку в задачу: учебный пример
Предположим, у условного сайта услуг на телефоне форма сообщает об успехе, но обращение не появляется в согласованной почте. Это учебный пример, а не случай из практики клиента.
Карточку задачи можно заполнить так:
| Поле | Что записать |
|---|---|
| Наблюдаемое поведение | После отправки корректных тестовых данных показано сообщение об успехе; получатель обращение не видит |
| Где и как повторить | Тестовая страница услуги, согласованное устройство и браузер, точные шаги, время отправки, идентификатор теста |
| Доказательство | Снимок сообщения, результат проверки у получателя и обезличенный фрагмент журнала передачи |
| Влияние и масштаб | Обращение по этой форме не попадает сотруднику; другие формы пока не проверены |
| Приоритет | P1; повысить до P0, если подтверждён отказ единственного основного канала обращений |
| Ответственный | Разработчик проверяет передачу; назначенный сотрудник подтверждает приём |
| Критерий приёмки | Корректный тест принят получателем; ошибка передачи на тестовой копии не выдаётся за успех; связанные формы проверены |
Причину не записывайте как факт до подтверждения. «Не дошла заявка» — наблюдение, «виноват почтовый сервер» — гипотеза, пока нет диагностики. Назначьте одного владельца задачи: именно он собирает ответы разработчика, инфраструктуры и сотрудника бизнеса.
Не создавайте отдельную задачу на каждый адрес с одной ошибкой шаблона. Сохраните перечень адресов, объедините общую причину и задайте проверку всей затронутой группы. Исправление шаблона может закрыть много симптомов; исправление одного экземпляра — оставить остальные.
Когда считать аудит завершённым
По итогам должны остаться согласованная область проверки, подтверждённые проблемы с приоритетами и владельцами, а также перечень того, что не удалось проверить. Отдельно нужны результаты повторной проверки исправленных задач. Сообщение «разработчик поправил» не является приёмкой.
После размещения исправлений на рабочем сайте повторите исходные шаги и связанный сценарий. Например, изменение правила индексации проверяйте вместе с доступностью страницы; исправление формы — вместе с её доставкой и сообщениями об ошибках. Сохраните результат «до» и «после». Для каждого незакрытого пункта укажите причину и следующий шаг, а не оставляйте его без статуса.
Аудит описывает состояние сайта на момент проверки. Он не гарантирует отсутствие будущих сбоев или рост поисковых позиций. Для нового сайта удобнее заложить часть условий заранее — в статье о требованиях SEO при разработке есть соответствующий контекст.
Если нужна диагностика перед доработкой, следующий шаг — технический аудит сайта с согласованными границами и результатом проверки. Когда проблемы уже подтверждены и относятся к обходу, дублям и адресам страниц, смотрите техническую SEO-оптимизацию сайта: список находок позволяет обсудить конкретные исправления и их приёмку.
