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

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

Что должно получиться

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

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

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

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

Из чего это складывается

Какие инструменты понадобятся

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

Доступ к CMS и журналам сервера поможет уточнить причину, если он у вас есть. Не получайте дополнительные права только ради первого просмотра. Сначала соберите воспроизводимое наблюдение, а затем передайте его тому, кто отвечает за нужный слой сайта.

Как это сделать по шагам

1. Определите границы. Запишите адрес сайта, типы страниц, важные действия и доступные устройства. Укажите, проверяете ли вы весь список или выборку. Для тестирования отправки используйте согласованную площадку и учебные данные.
2. Сохраните исходное состояние. Отметьте дату проверки, браузер, вход в кабинет и условия сети. Перед будущими изменениями убедитесь, что есть пригодная резервная копия. Сам аудит начните с просмотра, не меняющего настройки.
3. Проверьте документы и переходы. Откройте выбранные страницы, посмотрите ответ основного документа и конечный адрес. Проверьте несколько внутренних переходов и неизвестный адрес на своей тестовой площадке. Сравните технический ответ с видимым содержимым.
4. Проверьте загрузку и действия. Посмотрите, доступны ли стили, изображения и нужные скрипты. Повторите важный сценарий с открытой консолью. Отметьте сообщения, которые возникают вместе с поломкой, сохраняя различие между совпадением и установленной причиной.
5. Проверьте форму и небольшой экран. Убедитесь, что ошибки ввода понятны, данные не теряются без причины, а завершение подтверждается. На телефоне проверьте меню, поля и перекрытия. Не подменяйте реальное устройство одной уменьшенной картинкой макета.
6. Сопоставьте технические указания. Для страниц, предназначенных для поиска, проверьте основной адрес, отсутствие случайного запрета и присутствие в карте сайта. Не меняйте эти настройки по одному общему предупреждению без понимания назначения страницы.
7. Составьте порядок исправлений. Сначала выделите то, что мешает получить содержимое или завершить важное действие. Остальные замечания распределите по последствиям и воспроизводимости. Для каждого пункта укажите способ повторной проверки.
8. Проверьте исправления отдельно. После согласованных изменений повторите исходный сценарий в тех же условиях. Затем проверьте соседние страницы с тем же шаблоном. Закрывайте замечание по фактическому результату, а не по сообщению о выполненной работе.

Ответ страницы и её содержимое

В сетевой панели найдите основной документ, а не случайную картинку. Успешный ответ 200 не подтверждает, что открылась нужная статья: вместо неё может быть сообщение об отсутствии или страница входа. Запишите и код, и видимое содержимое, и итоговый адрес после перенаправлений.

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

Загрузка ресурсов и сообщения скриптов

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

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

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

Формы и подтверждение результата

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

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

Частые ошибки

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

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

Объявлять предупреждение причиной. В консоли может быть несколько сообщений, не связанных с замеченной поломкой. Укажите, какое действие и какой момент совпали с сообщением. Причину подтверждают дополнительной проверкой, а не цветом строки.

Смешивать наблюдение с требованием переделать сайт. Фраза «форма не показывает результат после отправки» описывает дефект. Предложение сменить CMS — уже вариант решения, который требует обоснования. Не выдавайте крупную переделку за единственный вывод из небольшого наблюдения.

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

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

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

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

Хорошая строка отчёта может выглядеть так: «На странице услуги в режиме посетителя после корректной тестовой отправки форма остаётся в состоянии загрузки. Запись создаётся, но подтверждение не появляется. Ожидается понятное завершение без повторной отправки». Это учебный пример, а не найденный дефект itsnew.ru.

Технические возможности просмотра загрузки описаны в документации Chrome DevTools, различие браузерной и серверной проверки формы — в материале MDN, обработка HTTP-кодов — в справке Google.

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

Если сбой связан с действием на странице, начните с чтения ошибок JavaScript в консоли. Если проверяете вход по внешнему размещению, отдельно проследите передачу UTM-меток в аналитику.

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

Вопросы и ответы

Можно ли провести технический аудит без платного сервиса?

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

Ответ 200 означает, что страница исправна?

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

Каждое сообщение в консоли нужно срочно исправлять?

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

Почему недостаточно проверить только главную?

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

Нужно ли сразу менять настройки после первого предупреждения?

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

Такой аудит подтверждает безопасность сайта?

Нет. Это проверка обычной работы выбранных страниц и сценариев. Оценка безопасности требует отдельного объёма и методов; отсутствие видимых ошибок не подтверждает отсутствие уязвимостей.