Введите адрес сайта, чтобы узнать первый HTTP-ответ сервера: код, время и основные заголовки. Редиректы не выполняются — их можно проверить отдельно.
Вставьте список адресов, чтобы проверить HTTP-статусы, время ответа и основные заголовки. Каждый URL проверяется отдельно, результаты появляются по мере обработки.
| Проверяемый URL | HTTP-статус | Время, мс | Content-Type | Server | Location |
|---|
Код статуса сообщает, как сервер обработал запрос. Ниже перечислены стандартные коды, которые могут встретиться при проверке.
Проверка ответа сервера помогает понять, что происходит при обращении к конкретному URL: открывается документ, возвращается ошибка или сервер предлагает перейти на другой адрес. Сервис PRLab выполняет запрос к публичной странице и показывает её первый HTTP-статус, время ответа и основные заголовки. Это удобно после переноса сайта, изменения адресов, настройки HTTPS и выбора версии домена.
Код 301 Moved Permanently означает постоянный перенос ресурса. В отчёте можно увидеть сам статус и заголовок Location с адресом назначения. Сопоставьте его с ожидаемой страницей: старый товар не должен случайно перенаправлять посетителя на посторонний раздел.
Проверяйте старые URL после смены структуры сайта и убедитесь, что правило перенаправления срабатывает на нужном адресе. Ответ нового URL проверьте отдельным запросом или через инструмент цепочек.
Ответ 302 Found сообщает о временном перенаправлении. Проверка 302 позволяет заметить, что вместо содержимого сервер возвращает другой адрес: например, страницу обслуживания или входа в аккаунт.
Посмотрите значение Location и назначение правила. Не заменяйте 302 на 301 только потому, что один код кажется «лучше»: постоянный и временный перенос решают разные задачи.
Цепочка возникает, когда исходный URL ведёт через несколько промежуточных адресов. Например, HTTP-версия перенаправляется на HTTPS, затем меняется WWW, а после добавляется слеш. Первый ответ показывает только начальный шаг.
Чтобы увидеть последовательность кодов и конечный URL, откройте проверку цепочки редиректов. Она отслеживает до 10 шагов. Дополнительные пояснения есть в статье как проверить цепочку редиректов сайта.
Циклический редирект возвращает посетителя к уже пройденному адресу: A → B → A. Причиной могут быть конфликтующие правила CMS, веб-сервера и прокси. Один HTTP-ответ с кодом 301 или 302 ещё не доказывает наличие цикла.
Для обнаружения повторного URL используйте проверку циклических редиректов, а для разбора причин — инструкцию как найти циклические редиректы. Сообщение о превышении лимита переходов само по себе не равно подтверждённому циклу.
Введите адрес с явным протоколом http:// и посмотрите, возвращает ли сервер перенаправление на https://. Затем проверьте HTTPS-адрес отдельно. Так можно сопоставить начальный статус, назначение перехода и ответ защищённой версии.
При проверке HTTPS возможна ошибка SSL/TLS или соединения. Успешный ответ не заменяет полный аудит сертификата и настроек безопасности. О связанных задачах рассказывает проверка HTTPS и SSL сайта.
Проверьте один и тот же путь на домене с WWW и без него: https://www.example.com/catalog и https://example.com/catalog. Сравните статусы и заголовки Location, чтобы узнать, какой вариант выбран для перенаправления.
Обратите внимание на сохранение пути и параметров. Если все адреса уходят на главную, посетитель может потерять нужный раздел. Два ответа 200 не являются автоматическим доказательством ошибки: дополнительно учитывайте назначение страниц и правила канонизации.
Trailing slash — завершающий символ / в пути. Для проверки сравните /catalog и /catalog/: сервер может открывать оба адреса либо перенаправлять один на другой. Инструмент показывает ответ каждого указанного варианта.
Проверьте согласованность правил после смены CMS или конфигурации сервера. Не должно возникать ситуации, когда одно правило добавляет слеш, а другое сразу его убирает. Для файлов и разделов сайта правила могут различаться.
HTTP-статус описывает результат запроса: 200 — успешный ответ, 301 и 302 — перенаправление, 404 — документ не найден, 500 — внутренняя ошибка сервера. Встроенный справочник помогает разобраться и в других кодах.
Проверяйте конкретную страницу, а не только главную. При этом HTTP 200 не гарантирует, что содержимое соответствует ожиданиям или страница уже проиндексирована. Подробнее — в статье код ответа сервера сайта.
Помимо статуса, отчёт показывает основные HTTP-заголовки ответа: Location, Server и Content-Type. Первый содержит адрес перенаправления, второй — переданную сервером информацию о программном обеспечении, третий — тип содержимого.
Это не полный дамп всех заголовков. Если поле отмечено как «не передан», сервер не предоставил соответствующее значение. Отсутствие Server само по себе не означает неисправность: сведения могут быть скрыты настройками.
Заголовок Content-Type задаёт MIME-тип ответа. Например, text/html соответствует HTML, application/json — JSON, а application/xml — XML. В значении также может быть указана кодировка, например charset=utf-8.
Сопоставьте тип с назначением URL. Если вместо ожидаемого JSON сервер отдаёт HTML, причиной может быть страница ошибки или авторизации. Для ответа с редиректом Content-Type относится к исходному ответу, а не к документу по адресу Location.
Браузер обычно автоматически следует по адресу из Location. Этот инструмент останавливается на первом ответе, чтобы вы могли изучить само правило перенаправления.
Показатель относится к серверному запросу, а не к загрузке изображений, выполнению JavaScript и отрисовке страницы в браузере.
Ответ может зависеть от момента проверки, защиты от ботов, географии запроса и авторизации. Здесь выполняется серверный запрос без вашей браузерной сессии, поэтому результат иногда отличается от открытого личного кабинета.
Справочные определения: HTTP 301, HTTP 302 и заголовок Content-Type в документации MDN.
Проверка ответа сервера показывает код HTTP, основные заголовки и время ответа для указанного URL. Это базовая диагностика, когда страница не открывается, плохо индексируется, ведёт себя нестабильно или отдаёт неожиданный Content-Type.
Код 200 означает успешную выдачу ресурса, 301 и 302 указывают на перенаправление, а 4xx и 5xx требуют отдельной диагностики. Анализируйте результат вместе с конечным адресом, настройками HTTPS и поведением сервера для разных вариантов домена.
Для комплексной проверки используйте проверку редиректов, проверку защитных заголовков, технический аудит.
Результат «Проверка HTTP-ответа сервера и заголовков страницы» полезнее всего рассматривать не отдельно, а как часть регулярного контроля сайта. Зафиксируйте исходное состояние, приоритетные URL и дату проверки. Затем исправьте одну понятную причину, повторите анализ и сравните данные. Такой подход позволяет не путать случайные колебания с реальным эффектом от доработок, а также сохраняет понятную историю решений для команды, разработчика или заказчика.
Если сервис показывает проблему, сначала определите её масштаб: относится ли она к одному адресу, шаблону раздела или всему домену. Важные страницы стоит проверить с точки зрения доступности, канонического адреса, содержания и внутренней навигации. Не вносите несколько несвязанных изменений одновременно — так проще найти причину улучшения или ухудшения результата и безопасно откатить неудачное решение.
Продолжить работу по теме помогут проверку дублей, диагностику DNS, создание скриншота, проверку индексации.
