Технический аудит сайта: что владелец может проверить самостоятельно

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

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

Подготовьте выборку и доступы

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

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

Проверьте ответ страницы и переходы

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

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

Разделите обход, индексирование и показ в поиске

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

Инструмент проверки URL в Google Search Console позволяет изучать состояние адреса в индексе и выполнять проверку текущей страницы. Сопоставляйте эти результаты: они относятся к разным моментам обработки.

В таблице укажите назначение страницы: должна участвовать в поиске или относится к служебной части. Затем сравните ожидаемое состояние с наблюдаемым. Корзина и статья решают разные задачи; одинаковое предупреждение инструмента для них может требовать разных решений.

Посмотрите правила доступа к контенту

Файл robots.txt управляет обходом. Google отдельно поясняет, что запрет обхода не равен удалению URL из результатов. Для обработки директивы noindex робот должен получить доступ к странице. Конфиденциальные материалы защищают авторизацией, а не публичным файлом с инструкциями роботам.

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

Проверьте содержимое и основные адреса

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

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

Пройдите мобильный сценарий и отправку

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

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

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

Назначьте приоритет по последствиям

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

• У каждой ошибки есть исходный адрес и дата наблюдения.
• Ожидаемое поведение описано отдельно от фактического.
• Шаги воспроизводятся другим сотрудником.
• Определены затронутые шаблоны и процесс бизнеса.
• После выпуска назначен повторный тест.

Вопросы о техническом аудите

Достаточно одного автоматического отчёта?

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

Можно исправить всё сразу?

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

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