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

Чтобы проверить страницы сайта при сбоях сервера, соберите адреса с ошибками, повторите проверки в разное время и сопоставьте результаты с журналами сервера. Для каждого сбоя сохраните адрес, время, код ответа и действия пользователя. Разовая успешная загрузка не исключает проблему: страница может открываться сейчас и возвращать ошибку при других условиях.
Владельцу бизнеса не обязательно самостоятельно разбираться в устройстве сервера. Его задача — определить, какие действия посетителей нарушены, собрать проверяемые наблюдения и назначить ответственного за исправление. Причину устанавливают разработчик и специалист, который обслуживает сервер, опираясь на эти данные.
Какие ошибки искать
Когда браузер запрашивает страницу, сервер обычно возвращает содержимое и HTTP-код — служебное обозначение результата запроса. Ошибки группы 5xx показывают, что при обработке запроса возникла проблема на стороне сервера или промежуточного сервиса.
| Код | Что означает | Что стоит проверить специалисту |
|---|---|---|
| 500 | Внутренняя ошибка сервера | Ошибки приложения и соответствующие записи в журналах |
| 502 | Промежуточный сервер получил некорректный ответ от другого сервера | Связь между компонентами и доступность приложения |
| 503 | Сервис временно недоступен | Состояние приложения, обслуживание и доступные ресурсы |
| 504 | Промежуточный сервер не дождался ответа вовремя | Длительные операции и взаимодействие компонентов |
Код помогает выбрать направление проверки, но не устанавливает причину. Например, за ошибкой 500 может стоять сбой обработки конкретного товара, а за 504 — медленный ответ базы данных. Это предположения, которые нужно подтвердить журналами и повторением проблемного действия.
Не каждое сообщение «сайт недоступен» связано с 5xx. Браузер может не получить ответ из-за проблем с соединением, DNS — системой поиска сервера по имени сайта — или защищённым подключением. Такие случаи записывайте отдельно: отсутствие HTTP-ответа и полученная серверная ошибка требуют разной диагностики.
Что подготовить перед проверкой
Понадобятся список страниц, браузер с инструментами разработчика, таблица наблюдений и контакт технического специалиста. Для проверки множества адресов пригодится сканер сайта — программа, которая обходит страницы и записывает ответы. Для поиска периодических сбоев нужен мониторинг: повторные автоматические проверки по расписанию.
Заранее договоритесь, кто сможет посмотреть серверные журналы. Журнал, или лог, — запись запросов и событий. В журнале запросов можно искать адреса и коды ответов, а в журнале приложения — сообщения об ошибках обработки. Состав записей зависит от настроек, поэтому нужных подробностей там может не оказаться.
Укажите единый часовой пояс для наблюдений. Если браузер, мониторинг и сервер показывают время по-разному, специалист может искать событие не в том промежутке. Доступ к журналам владельцу бизнеса необязателен: достаточно передать точное время и попросить сопоставить записи.
Пошаговая проверка страниц
Шаг 1. Соберите адреса и важные сценарии
Начните со страниц, через которые посетители выполняют значимые для бизнеса действия: выбирают товар, отправляют заявку, оформляют заказ или входят в личный кабинет. Добавьте адреса из жалоб, уведомлений мониторинга и ранее обнаруженных ошибок.
Для первоначального списка можно использовать карту сайта, выгрузку из системы управления и отчёт обхода. Карта сайта содержит адреса, предназначенные для обнаружения поисковыми системами, но не обязательно охватывает все варианты страниц. Поиск, фильтры и закрытые разделы часто требуют отдельной проверки.
Собирайте не только адреса, но и сценарии. «Карточка открывается» и «товар добавляется в корзину» — разные проверки. Основная страница может загрузиться, а запрос, который отправляется после нажатия кнопки, — завершиться ошибкой.
Шаг 2. Посмотрите ответ в браузере
Откройте инструменты разработчика и вкладку «Сеть», которая также может называться Network. Затем загрузите проблемную страницу или повторите действие. Во вкладке появятся запросы и их результаты. Найдите основной документ и запросы, связанные с неработающей функцией.
Запишите адрес запроса, код ответа и время ожидания. Если при переходе происходит перенаправление, то есть автоматический переход на другой адрес, сохраните исходный и конечный адреса. Ошибка может возникнуть на одном из этапов перехода.
Проверяйте содержимое вместе с кодом. Страница с текстом «Временная ошибка» иногда возвращает 200 — код успешного ответа. Такой результат нужно отметить как ошибку содержимого. Обратная ситуация тоже возможна: оформление сайта отображается нормально, но внутри не загружается список товаров или форма.
Если передаёте снимок экрана, покажите сообщение и проблемный запрос. Скройте персональные данные, содержимое форм и служебные данные доступа. Для диагностики обычно важнее точный адрес, время и результат, чем полный снимок рабочего окна.
Шаг 3. Проведите обход списка страниц
Загрузите подготовленные адреса в сканер и сохраните отчёт с кодами ответа. Сравните ошибки по типам страниц: карточки товаров, категории, статьи, поиск, личный кабинет. Это поможет увидеть, ограничен ли сбой отдельным разделом или затрагивает разные части сайта.
Начинайте с небольшой скорости обхода, согласованной с техническим специалистом. Массовая проверка создаёт дополнительные запросы. Если сайт уже работает нестабильно, слишком интенсивный обход может усилить проблему и затруднить оценку обычных условий.
Уточните ограничения программы. Некоторые сканеры проверяют только исходный ответ сервера и не выполняют действия внутри страницы. Успешный обход таких адресов не подтверждает работу корзины, фильтра или формы. Эти функции нужно проверять отдельно.
Шаг 4. Повторите проверки в разных условиях
Периодическую ошибку нельзя исключить одним обходом. Повторяйте проверки в периоды, когда поступали жалобы, и в обычное время. Если наблюдения указывают на связь с рекламными переходами, обновлением каталога или резервным копированием, включите соответствующие периоды в план.
Меняйте условия по одному, чтобы понимать, что влияет на результат. Например, сначала сравните открытие страницы без входа и после входа в аккаунт. Затем отдельно проверьте вариант с фильтром. Одновременная смена устройства, сети и состояния входа затруднит выводы.
Полезно сравнить:
- Вход на страницу напрямую и переход из другого раздела.
- Открытие без авторизации и после входа в аккаунт.
- Адрес без параметров и вариант с поиском или фильтром.
- Первую загрузку и повторное открытие.
- Одинаковое действие в обычное время и во время известного сбоя.
Повторная загрузка может получить сохранённую копию страницы из кеша. Кеш — временное хранилище ответов, которое ускоряет открытие сайта. Поэтому успешное обновление страницы не всегда означает, что приложение снова работает исправно. Попросите специалиста учесть кеш при воспроизведении.
Шаг 5. Сопоставьте наблюдения с журналами
Передайте специалисту адреса и время ошибок. Попросите найти соответствующие запросы в журналах и проверить сообщения приложения за тот же период. Если система присваивает запросу идентификатор — уникальную метку для поиска события, — сохраните и его.
Сопоставление помогает определить, на каком этапе возникла проблема. Запрос мог завершиться ошибкой в приложении, при обращении к базе данных или на промежуточном сервере. Одного журнала может быть недостаточно, особенно если сайт состоит из нескольких компонентов.
Отдельно обозначьте факты и предположения. «Ошибка появилась после выбора фильтра» — наблюдение. «Фильтр перегружает базу данных» — гипотеза. В задаче должны остаться оба пункта, но гипотеза не должна подменять техническую проверку.
Как вести таблицу сбоев
Одна строка таблицы должна описывать отдельное событие. Не заменяйте её записью «каталог иногда падает»: такая формулировка не позволяет повторить проверку и найти нужный запрос.
| Поле | Что записать |
|---|---|
| Адрес | Полный путь и значимые параметры запроса |
| Время | Момент сбоя с указанием часового пояса |
| Действие | Что пользователь сделал перед ошибкой |
| Условия | Вход в аккаунт, фильтр, устройство и другие замеченные особенности |
| Результат | Код ответа, сообщение или отсутствие ответа |
| Повторная проверка | Когда выполнена и чем закончилась |
| Подтверждение | Снимок экрана, запись мониторинга или идентификатор запроса |
Не переносите в общую таблицу пароли, данные покупателей и секретные значения из адресов. Если они нужны для воспроизведения, технический специалист должен организовать передачу через подходящий защищённый канал.
Сохраняйте и неудачные, и успешные попытки. Запись «при открытии с фильтром возникла 504, без фильтра страница загрузилась» полезнее отдельного сообщения об ошибке. Она задаёт условия для сравнения, хотя сама по себе ещё не доказывает причину.
Как расставить приоритеты исправления
Оценивайте сбои по последствиям для посетителя, охвату и повторяемости. Ошибка отправки заявки может требовать более срочного исправления, чем недоступность редко используемой страницы. При этом отсутствие жалоб не подтверждает отсутствие проблемы: посетитель может просто уйти.
Сначала выделите ошибки, которые блокируют основное действие: заказ, оплату, обращение или вход. Затем проверьте сбои целых типов страниц и общих компонентов. Если не работает поиск во всех разделах, исправление отдельной карточки не решит основную проблему.
Учитывайте обходной путь. Если пользователь может открыть товар другим способом, последствия отличаются от ситуации, когда оформление заказа полностью остановлено. Опишите это в задаче, чтобы техническая команда понимала срочность и могла выбрать временное решение.
Для SEO важно, чтобы открытые страницы были доступны и пользователям, и поисковым роботам — программам, которые посещают сайт для обработки его содержимого. Повторные серверные ошибки мешают получать страницы. Однако по отдельному сбою нельзя достоверно определить изменение позиций или трафика.
Как передать задачу на исправление
Задача разработчику должна описывать ожидаемое поведение, фактический результат и условия проверки. Добавьте время наблюдений, подтверждения и ответственного. Формулировка «исправить ошибки сервера» слишком широкая: по ней трудно оценить выполнение.
Условный пример задачи:
При выборе фильтра в категории основной документ открывается, но запрос списка товаров возвращает 504. Посетитель не видит результаты. Без фильтра список загружается. В таблице приложены время попыток, параметры запроса и снимок вкладки «Сеть». Нужно установить причину и проверить получение списка в тех же условиях после исправления.
Попросите специалиста описать найденную причину, внесённое изменение и способ проверки. Если потребовалась временная мера, например перезапуск приложения, отметьте её отдельно. Восстановление доступности и устранение причины — разные результаты работы.
Причины могут быть связаны с кодом, ресурсами сервера, базой данных или внешними сервисами. Решение выбирают после диагностики. Увеличение мощности сервера, изменение времени ожидания или отключение функции не следует назначать только по коду ошибки: такая мера может скрыть симптом или не помочь.
Как проверить результат после исправления
Повторите исходный сценарий с теми же параметрами и состоянием входа. Проверьте соседние варианты, которые могли затронуть изменения: другие фильтры, похожие страницы, пустой результат поиска. Убедитесь, что получен корректный ответ и посетитель может закончить действие.
Затем продолжите наблюдение в условиях, где раньше возникала проблема. Если ошибка появлялась во время обновления каталога, проверка вне этого процесса недостаточна. Период наблюдения выбирайте вместе со специалистом с учётом известной частоты и условий сбоя.
Критерий закрытия задачи должен быть проверяемым: проблемное действие выполняется, ожидаемое содержимое отображается, а соответствующие ошибки не обнаружены в согласованных повторных проверках и журналах. Это подтверждение результата проверки, а не гарантия отсутствия любых будущих сбоев.
Как организовать дальнейшее наблюдение
Включите в мониторинг важные страницы и, где возможно, ключевые действия. Проверка только главной страницы не покажет, что перестал работать поиск или отправка формы. Для каждой проверки определите ожидаемый код и признак корректного содержимого.
Настройте уведомления с адресом, временем и результатом запроса. Назначьте человека, который принимает сигнал, и технического специалиста, который разбирает его причину. После исправлений сохраняйте историю: она поможет сопоставить новый сбой с предыдущими событиями.
Автоматическую повторную проверку используйте для уточнения сигнала, сохраняя исходную ошибку. Если система показывает только итоговую успешную попытку, кратковременные сбои могут исчезать из отчёта, хотя посетители уже столкнулись с ними.
Частые вопросы
Почему страница открывается у владельца, но не у покупателя?
Условия запросов могут различаться: состояние входа, параметры адреса, сохранённые данные и время обращения. Запросите точный адрес, действие и время ошибки. Затем сравните эти условия со своей успешной попыткой.
Нужно ли проверять все страницы каждый раз?
Полный обход полезен для поиска новых проблем, но регулярное наблюдение стоит начать с важных страниц и сценариев. При обнаружении ошибки расширяйте проверку на похожие адреса и общие функции, чтобы определить охват.
Можно ли считать перезапуск сервера исправлением?
Перезапуск может восстановить работу, но сам по себе не объясняет причину. Зафиксируйте, что происходило до него, и продолжите наблюдение. Для закрытия задачи нужно понять, почему возник сбой и как проверено устранение причины.
Что делать, если ошибка больше не повторяется?
Сохраните исходное событие и проверьте журналы за соответствующее время. Продолжайте наблюдение при похожих условиях. В отчёте укажите, что повторить ошибку пока не удалось, вместо утверждения, что проблема устранена.