Как проверить код ответа сервера и почему важно делать такие проверки. Как проверить ответ сервера в браузере

Как проверить код ответа сервера и почему важно делать такие проверки

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

Как происходит процесс общения браузера с сервером

Для начала следует разобраться, как работает вся система и каким образом происходит общение браузера с сервером. Как только вы ввели определенный URL в адресную строку браузера или кликнули по любой ссылке размещенной в сети интернет браузер посылает запросы к интернет-странице на сервер. В ответ сервер отдает необходимый html-файл и http заголовок. Именно этот заголовок состоит из кода ответа сервера  и определенного, пояснительного текста, соответствующего каждому коду ответа сервера. Пояснение необходимо только для человека, оно позволяет понять, в чем заключается ошибка.

Очень важно понимать, что каждая страница сайта должна правильно отвечать поисковым системам, а также как можно быстрее открываться. Если страница работает нормально, то код ответа будет 200, если страница не существует, то отдается код ответа – 404. Иногда сервера могут давать сбой и отдавать поисковому роботу неправильные коды ответов. 

Так рабочие страницы иногда отвечают кодом 404, а те которые действительно не существуют отдают код 200. И вот она причина бед с позициями сайта в поисковой выдаче. В подобной ситуации очень важно пройти процесс корректной настройки статус-кодов в файле .htaccess. И хоть эта ситуация встречается не так часто, очень важно не забывать проверять сайт на работоспособность. Сделайте это, если ваш сайт перебрался на другой хостинг или вы только, что разместили новый сайт.

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

Инструменты для проверки кодов ответа сервера

Существует ряд сервисов и программ, которые позволяют проверить код ответа сервера. Одним из таких сервисов является Яндекс Проверка ответа сервера.

Проверка при помощи сервиса: Яндекса Проверка ответа сервера

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

Для того, чтобы им воспользоваться необходимо зарегистрироваться или авторизоваться в сервисе Яндекс Вебмастер. После этого переходим по ссылке: http://webmaster.yandex.ru/server-response.xml, указываем url-адрес страницы сайта, в специальной строке и производим проверку нажатием на кнопку «Проверить».

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

Правильно работающая страница выдаст код – 200 ОК. В таком случае все работает как надо.

После этого можете ввести url-страницы, которая не существует на вашем сайте и в принципе не может попасть в индекс ПС. Для этого, достаточно в URL адресе ввести любые символы, например как на скриншоте ниже:

Обратите внимание в данном случае код ответа должен быть – 404 Not Found, что значит, данная страница не найдена.

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

Проверка статус кодов при помощи MegaIndex

Иногда необходимо массово проверить страницы сайта на предмет того какие статус коды отдаются всеми его страницами. Это очень удобно делать при помощи сервиса "Комплексный SEO-аудит сайтов" предоставляемого компанией Megaindex.

1. Для этого достаточно зарегистрироваться или войти, если ранее уже проходили регистрацию на MegaIndex.

2. Затем перейти в пункт Сервис >> Аудит сайта.

3. В поле "Аудит сайта:" вводите адрес вашего сайта и жмете "Начать".

4. После всех проверок появится страница, где кликните по вкладке "Еще" и выберите пункт "Коды ответа".

5. В результате будет показана таблица где будут представлены все URL страниц, их уровень вложенности и и код статуса ответа.

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

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

Группы и виды кодов ответа сервера

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

1xx — информирующие коды, они сообщают о процессе передачи данных и загрузке старницы.

2xx — коды-успешности, которые сообщают о правильной работе сайтов и загрузке страниц.

3xx — редирект-коды, обозначают перенаправление посетителей и роботов поисковых систем с одного адреса на другой.

4xx — коды ошибок на стороне клиента, обозначают, что на стороне клиента возникла ошибка и запрошенная страница не может быть показана.

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

Информация по кодам ответа взята из справки Google: https://support.google.com/webmasters/answer/40132?hl=ru

Материал подготовлен проектом: WebMasterMix.ru

Рекомендуем ознакомиться:

Опубликовано: 14 Ноябрь 2013

Обновлено: 30 Ноябрь 2013

Просмотров: 19554

webmastermix.ru

Как проверить код ответа сервера и редиректа, что означает ошибка 301

Содержание статьи

Проверять код ответа нужно для того, чтобы поисковик правильно индексировал страницы. Если страницы, которые нужно включить в индекс, будут отдавать код 404 — никакого продвижения у вас не получится.

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

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

Нестабильная работа сервера может привести к ситуации «шиворот-навыворот»: рабочая страница отвечает 404 ошибкой, а несуществующие страницы помечаются кодом 200. Такие сбои влекут за собой проблемы с индексацией и потерей позиций в поисковой выдаче. Несмотря на невысокую вероятность этой ситуации, в целях оптимизации рекомендуется корректно настроить статус-коды в серверном файле .htaccess. Стоит это сделать при запуске нового сайта или переводе трастового на другой хостинг.

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

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

Яндекс Вебмастер

В Яндекс Вебмастере проверить код ответа сервера можно с помощью инструмента Server Response. Указав url-адрес любой страницы, которая может находится в индексе, нажимаем «Проверить».

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

Осуществлять проверку ответов сервера можно только для сайтов, подтвержденных в панели Яндекс.Вебмастер.

Bertal

В отличии от Server Response, помимо ботов Яндекса на Bertal можно выбрать GoogleBot и BingBot, а также популярные браузеры. Укажем те же страницы, чтобы подтвердить правильную работоспособность сервера. В списке ботов выберем GoogleBot.

Пиксель Тулс

На Пиксель Тулс сервис для проверки ответа сервера поддерживает массовую проверку страниц. Список адресов можно вводить вручную или загружать из файла. Полученные результаты можно сохранить в CSV-файл.

Для использования сервиса необходимо зарегистрироваться. В отличии от Bertal, нельзя выбрать интересующих ботов. Какого-либо списка по выбору адресата нет вообще.

Что такое ошибка 301

Ответ 301 moved permanently означает, что запрашиваемая страница переехала на новый URL. Новый адрес который указывается в отдельной графе сервиса.

Также приведу пример с проверкой страницы, с которой происходит 301 редирект.

Что такое ошибка 503

Ответ 503 Server Unavailable означает, что сервер временно не может обрабатывать запросы из-за технических проблем. Этот код предназначен для уведомления поискового бота о том, что на сайте проводятся технические работы. После ошибки 503 бот при необходимости посетит страницу позже. При продвижении сайта нужно следить за страницами с ответом 503. После осуществления на сайте технических работ нужно проверить их, чтобы они вновь отвечали кодом 200 ОК.

Вот видос, где Гроховский поясняет за коды ответа сервера:

znet.ru

Ответы сервера — подробная инструкция — Netpeak Blog

Роботы поисковых систем при проверке страницы вначале смотрят на код ответа сервера, а затем уже приступают к проверке содержимого документа. Например, несуществующие страницы всегда должны отдавать 404 код. Почему? Google утверждает, что страницы с кодом ответа, отличным от 404 и 410, будут сканироваться. Так что, если вы не знаете, какие коды отдают страницы вашего сайта и как это проверить, то ставите под угрозу будущее всего проекта.

О том, что означают коды ответов сервера, — в новом выпуске «Азбуки SEO».

Что такое «код ответа сервера»

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

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

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

Чтобы увидеть код при работе в Google Chrome, воспользуйтесь вкладкой Network на панели инструментов разработчика (чтобы попасть туда, нажмите F12). После открытия панели обновите страницу.

Также можно использовать расширения для браузеров: Live HTTP Headers для Firefox, HTTP Headers для Chrome. С их помощью можно в один клик получить информацию по отдельным страницам. А для массовой проверки по списку URL можно использовать Netpeak Spider, Netpeak Checker или онлайн-инструмент Urlitor (анализ до 150 URL-адресов).

Что такое «классы состояния»

Это группы кодов, объединенных определенными признаками. На класс состояния указывает первая цифра в коде.

Выделяют пять классов:

1. 1xx — информационные коды. Они отвечают за процесс передачи данных. Это временные коды, они информируют о том, что запрос принят и обработка будет продолжаться.
2. 2xx — успешная обработка. Запрос был получен и успешно обработан сервером.
3. 3xx — перенаправление (редирект). Эти ответы сервера гласят, что нужно предпринять дальнейшие действия для выполнения запроса. Например, сделать запрос по другому адресу.
4. 4xx — ошибка пользователя. Это значит, что запрос не может быть выполнен по его вине.
5. 5xx — ошибка сервера. Эти коды возникают из-за ошибок на стороне сервера. В данном случае пользователь всё сделал правильно, но сервер не может выполнить запрос. Для кодов этого класса сервер обязательно показывает сообщение, что не может обработать запрос и по какой причине.

Основные ответы сервера

200 ОК

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

301 Moved Permanently

Этот ответ гласит, что документ или страница были перемещены на другой адрес навсегда. Если у страницы, которая уже была в выдаче поисковых систем, изменился адрес, для сохранения трафика и ссылочного веса рекомендуется настраивать 301 редирект со старого URL-адреса на новый. В конечном итоге поисковик «склеит» эти адреса.

302 Found

Документ временно перенесен на другой адрес. Этот код — сигнал о том, что удалять эту страницу из индекса не надо. По заявлению Gary Illyes из Google, ссылочный вес при этом передается.

304 Not Modified

Важный код с точки зрения нагрузки на сервер и количества передаваемых данных. Сервер возвращает 304 код, если в HTTP-заголовке дата последнего обновления (Last-Modified) старее, чем в запросе с заголовком If-Modified-Since. То есть, если документ не менялся с указанной даты, сервер возвращает код 304 Not Modified. В таком случае роботам поисковиков нет необходимости загружать документ повторно: он не изменился с момента их последнего визита. Фактически они получают только http-заголовки и двигаются дальше.

403 Forbidden

Отказано в доступе. Этот ответ возвращается, если пользователю запрещен доступ к данному документу. В данном случае речь не идет об HTTP-аутентификации (для таких случаев используются 401 и 407 коды). 403 код выводится, например, при входе с запрещенных IP или попытке просмотра системного файла .htaccess.

404 Not Found

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

Страница с сообщением 404 File Not Found не всегда отдает код 404. Многие вебмастера не уделяют этому внимание, что в результате может негативно сказаться на ранжирования всего сайта. Это так называемые страницы «Soft 404». Они возникают, если несуществующая страница отдает код ответа, отличный от 404 и 410. К «Soft 404» могут быть причислены страницы, которые должны отдавать код 200, но на них нет контента (пустая страница). Решение вопроса — найти такие страницы и обязательно настроить для них 404 код.

В искусстве оформления 404 страниц многие преуспели. Отвлекитесь и зацените:

Смотрите также другие интересные примеры дизайна страниц с 404 ошибкой.

410 Gone

Этот ответ говорит, что документ был окончательно удален и более недоступен. Хотя коды 404 и 410 одинаково указывают на то, что страница недоступна, в их обработке есть отличия. Обращаясь к 404 странице, поисковый робот не будет помечать её как удаленную и спустя время снова к ней обратится для уточнения информации. Чего не скажешь про 410 код. В этом случае робот точно отметит, что эта страница или документ навсегда удалены с сервера. Доверясь вебмастеру, бот не будет проверять эту страницу снова.

451 Unavailable For Legal Reasons

В последнее время этот код встречается все чаще. Он означает, что доступ к серверу закрыт из-за его запрета на государственном уровне или по решению суда в случае нарушения авторских прав. Ошибка 451 — уточняющий вариант кода 403.

500 Internal Server Error

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

503 Service Unavailable

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

504 Gateway Timeout

Шлюз не отвечает. Ответ появляется, если сервер работал в качестве прокси и не дождался ответа от вышестоящего сервера для завершения запроса.

Для предотвращения появления страниц в индексе поисковых систем рекомендуется использовать на странице метатег robots с атрибутом noindex: <meta name="robots" content="noindex">.

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

Выводы

1. Существуют пять групп кодов ответа сервера — классы состояния, указывающие на разные этапы процесса передачи данных: от успешной обработки до ошибки сервера.
2. Все страницы, которые мы хотим видеть в индексе поисковых систем, должны отдавать код 200 OK.
3. Если у страницы, которая уже была в выдаче поисковых систем, изменился адрес, рекомендуется настраивать 301 редирект со старого URL-адреса на новый.
4. Если несуществующая страница отдает код ответа, отличный от 404 и 410, возникает ошибка страниц «Soft 404». К ним могут быть причислены страницы, которые должны отдавать код 200, но на них нет контента.

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

Напоследок вопрос на общую эрудицию: почему для ответа сервера Unavailable For Legal Reasons выбрали число 451?

netpeak.net

Проверка ответа сервера, HTTP-заголовки сервера

Список заголовков HTTP

Список кодов состояния HTTP

Код состояния HTTP (англ. HTTP status code) является частью первой строки ответа сервера. Он представляет собой целое число из трех арабских цифр. Первая цифра указывает на класс состояния. За кодом ответа обычно следует отделённая пробелом поясняющая фраза на английском языке, которая разъясняет человеку причину именно такого ответа.

Клиент узнаёт по коду ответа о результатах его запроса и определяет, какие действия ему предпринимать дальше. Набор кодов состояния является стандартом, и они описаны в соответствующих документах RFC. Введение новых кодов должно производиться только после согласования с IETF. Тем не менее, известно о двух используемых кодах, не упомянутых в RFC: 449 Retry With (введён Microsoft) и 509 Bandwidth Limit Exceeded (введён в cPanel).

Клиент может не знать все коды состояния, но он обязан отреагировать в соответствии с классом кода. В настоящее время выделено пять классов кодов состояния.

Веб-сервер Microsoft Internet Information Services в своих файлах журналов кроме стандартных кодов состояния использует подкоды записывая их через точку после основного. При этом в ответах от сервера данный субкод не размещается — он нужен администратору сервера чтобы тот мог более точно определять источники проблем. Со списком подкодов IIS можно ознакомиться в документе "Коды состояния служб IIS" в Базе знаний Microsoft.

1xx: Informational (Информационные)

В этот класс выделены коды, информирующие о процессе передачи. В HTTP/1.0 сообщения с такими кодами должны игнорироваться. В HTTP/1.1 клиент должен быть готов принять этот класс сообщений как обычный ответ, но ничего серверу отправлять не нужно. Сами сообщения от сервера содержат только стартовую строку ответа и, если требуется, несколько специфичных для ответа полей заголовка. Прокси-сервера подобные сообщения должны отправлять дальше от сервера к клиенту.

100 Continue (Продолжать) - Сервер удовлетворён начальными сведениями о запросе, клиент может продолжать пересылать заголовки. Появился в HTTP/1.1.

101 Switching Protocols (Переключение протоколов) - Сервер предлагает выбрать другой протокол, более соответствующий данному ресурсу. Протоколы предлагаемый сервером, указываются в строке заголовка Update, если предложенный сервером протокол, устраивает клиента, он высылает новый запрос с указанием нового протокола. Появился в протоколе версии HTTP/1.1.

102 Processing (Идёт обработка) - Запрос принят, но на его обработку понадобится длительное время. Используется сервером, чтобы клиент не разорвал соединение из-за превышения времени ожидания. Клиент при получении такого ответа должен сбросить таймер и дожидаться следующей команды в обычном режиме. Появился в WebDAV.

105 Name Not Resolved (Не удается преобразовать DNS-адрес сервера) - При разрешении доменного имени возникла ошибка в связи с неверным или отсутствующем IP-адресом DNS-сервера.

2xx: Success (Успешно)

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

200 OK (Хорошо) - Успешный запрос. Если клиентом были запрошены какие-либо данные, то они находятся в заголовке и/или теле сообщения. Появился в HTTP/1.0.

201 Created (Создано) - В результате успешного выполнения запроса был создан новый ресурс. Сервер должен указать его местоположение в заголовке Location. Серверу рекомендуется ещё указывать в заголовке характеристики созданного ресурса (например, в поле Content-Type). Если сервер не уверен, что ресурс действительно будет существовать к моменту получения данного сообщения клиентом, то лучше использовать ответ с кодом 202. Появился в HTTP/1.0.

202 Accepted (Принято) - Запрос был принят на обработку, но она не завершена. Клиенту не обязательно дожидаться окончательной передачи сообщения, так как может быть начат очень долгий процесс. Появился в HTTP/1.0.

203 Non-Authoritative Information (Информация не авторитетна) - Аналогично ответу 200, но в этом случае передаваемая информация была взята не из первичного источника (резервной копии, другого сервера и т. д.) и поэтому может быть неактуальной. Появился в HTTP/1.1.

204 No Content (Нет содержимого) - Сервер успешно обработал запрос, но в ответе были переданы только заголовки без тела сообщения. Клиент не должен обновлять содержимое документа, но может применить к нему полученные метаданные. Появился в HTTP/1.0.

205 Reset Content (Сбросить содержимое) - Сервер обязывает клиента сбросить введённые пользователем данные. Тела сообщения сервер при этом не передаёт и документ обновлять не обязательно. Появился в HTTP/1.1.

206 Partial Content (Частичное содержимое) - Сервер удачно выполнил частичный GET-запрос, возвратив только часть сообщения. В заголовке Content-Range сервер указывает байтовые диапазоны содержимого. Особое внимание при работе с подобными ответами следует уделить кэшированию. Появился в HTTP/1.1.

207 Multi-Status (Многостатусный) - Сервер передаёт результаты выполнения сразу нескольких независимых операций. Они помещаются в само тело сообщения в виде XML-документа с объектом multistatus. Не рекомендуется размещать в этом объекте статусы из серии 1xx из-за бессмысленности и избыточности. Появился в WebDAV.

226 IM Used (Использовано IM) - Заголовок A-IM от клиента был успешно принят и сервер возвращает содержимое с учётом указанных параметров. Введено в RFC 3229 для дополнения протокола HTTP поддержкой дельта-кодирования.

3xx: Redirection (Перенаправление)

Коды класса 3xx сообщают клиенту, что для успешного выполнения операции необходимо сделать другой запрос (как правило по другому URI). Из данного класса пять кодов 301, 302, 303, 305 и 307 относятся непосредственно к перенаправлениям (жарг. редирект). Адрес, по которому клиенту следует произвести запрос, сервер указывает в заголовке Location. При этом допускается использование фрагментов в целевом URI.

По последним стандартам клиент может производить перенаправление автоматически (без запроса пользователя) только если второй ресурс будет запрашиваться методом GET или HEAD. В предыдущих спецификациях говорилось что для избежания круговых переходов пользователя следует спрашивать после 5-го подряд перенаправления. При всех перенаправлениях если метод был не HEAD, то в тело ответа следует включить короткое гипертекстовое сообщение с целевым адресом чтобы в случае чего пользователь смог сам произвести переход.

Разработчики HTTP отмечают что многие клиенты при перенаправлениях с кодами 301 и 302 ошибочно применяют метод GET ко второму ресурсу несмотря на то, что к первому запрос был с иным методом. Чтобы избежать недоразумений в версии HTTP/1.1 были введены коды 303 и 307 вместо 302. Изменять метод нужно только если сервер ответил 303. В остальных случаях следующий запрос производить с исходным методом.

300 Multiple Choices (Несколько вариантов выбора) - По указанному URI существует несколько вариантов предоставления ресурса по типу MIME, по языку или по другим характеристикам. Сервер передаёт с сообщением список альтернатив, давая возможность сделать выбор клиенту автоматически или пользователю. Появился в HTTP/1.0.

301 Moved Permanently (Перемещено навсегда) - Запрошенный документ был окончательно перенесен на новый URI, указанный в поле Location заголовка. Некоторые клиенты некорректно ведут себя при обработке данного кода. Появился в HTTP/1.0.

302 Moved Temporarily / Found (Перемещено временно / Найдено) - Запрошенный документ временно доступен по другому URI, указанному в заголовке в поле Location. Этот код может быть использован, например, при управляемом сервером согласовании содержимого. Некоторые клиенты некорректно ведут себя при обработке данного кода. Введено в HTTP/1.0.

303 See Other (Смотреть другое) - Документ по запрошенному URI нужно запросить по адресу в поле Location заголовка с использованием метода GET несмотря даже на то, что первый запрашивался иным методом. Этот код был введён вместе с 307-ым для избежания неоднозначности, чтобы сервер был уверен, что следующий ресурс будет запрошен методом GET. Например, на веб-странице есть поле ввода текста для быстрого перехода и поиска. После ввода данных браузер делает запрос методом POST, включая в тело сообщения введённый текст. Если обнаружен документ с введённым названием, то сервер отвечает кодом 303, указав в заголовке Location его постоянный адрес. Тогда браузер гарантировано его запросит методом GET для получения содержимого. В противном случае сервер просто вернёт клиенту страницу с результатами поиска. Введено в HTTP/1.1.

304 Not Modified (Не изменялось) - Сервер возвращает такой код, если клиент запросил документ методом GET, использовал заголовок If-Modified-Since или If-None-Match и документ не изменился с указанного момента. При этом сообщение сервера не должно содержать тела. Появился в HTTP/1.0.

305 Use Proxy (Использовать прокси) - Запрос к запрашиваемому ресурсу должен осуществляться через прокси-сервер, URI которого указан в поле Location заголовка. Данный код ответа могут использовать только исходные HTTP-сервера (не прокси). Введено в HTTP/1.1.

306 (Зарезервировано, код использовался только в ранних спецификациях) - Использовавшийся раньше код ответа, в настоящий момент зарезервирован. Упомянут в RFC 2616 (обновление HTTP/1.1).

307 Temporary Redirect (Временное перенаправление) - Запрашиваемый ресурс на короткое время доступен по другому URI, указанный в поле Location заголовка. Этот код был введён вместе с 303 вместо 302-го для избежания неоднозначности. Введено в RFC 2616 (обновление HTTP/1.1).

4xx: Client Error (Ошибка клиента)

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

400 Bad Request (Плохой запрос) - Сервер обнаружил в запросе клиента синтаксическую ошибку. Появился в HTTP/1.0.

401 Unauthorized (Неавторизован) - Для доступа к запрашиваемому ресурсу требуется аутентификация. В заголовке ответ должен содержать поле WWW-Authenticate с перечнем условий аутентификации. Клиент может повторить запрос, включив в заголовок сообщения поле Authorization с требуемыми для аутентификации данными.

402 Payment Required (Необходима оплата) - Предполагается использовать в будущем. В настоящий момент не используется. Этот код предусмотрен для платных пользовательских сервисов, а не для хостинговых компаний. Имеется в виду, что эта ошибка не будет выдана хостинговым провайдером в случае просроченной оплаты его услуг. Зарезервирован, начиная с HTTP/1.1.

403 Forbidden (Запрещено) - Сервер понял запрос, но он отказывается его выполнять из-за ограничений в доступе для клиента к указанному ресурсу. Если для доступа к ресурсу требуется аутентификация средствами HTTP, то сервер вернёт ответ 401 или 407 при использовании прокси. В противном случае ограничения были заданы администратором сервера или разработчиком веб-приложения и могут быть любыми в зависимости от возможностей используемого программного обеспечения. В любом случае клиенту следует сообщить причины отказа в обработке запроса. Наиболее вероятными причинами ограничения может послужить попытка доступа к системным ресурсам веб-сервера (например, файлам .htaccess или .htpasswd) или к файлам, доступ к которым был закрыт с помощью конфигурационных файлов, требование аутентификации не средствами HTTP, например, для доступа к системе управления содержимым или разделу для зарегистрированных пользователей либо сервер не удовлетворён IP-адресом клиента, например, при блокировках. Появился в HTTP/1.0.

404 Not Found (Не найдено) - Самая распространенная ошибка при пользовании Интернетом, основная причина — ошибка в написании адреса Web-страницы. Сервер понял запрос, но не нашёл соответствующего ресурса по указанному URI. Если серверу известно, что по этому адресу был документ, то ему желательно использовать код 410. Ответ 404 может использоваться вместо 403, если требуется тщательно скрыть от посторонних глаз определённые ресурсы. Появился в HTTP/1.0.

405 Method Not Allowed (Метод не поддерживается) - Указанный клиентом метод нельзя применить к текущему ресурсу. В ответе сервер должен указать доступные методы в заголовке Allow, разделив их запятой. Эту ошибку сервер должен возвращать, если метод ему известен, но он не применим именно к указанному в запросе ресурсу, если же указанный метод не применим на всём сервере, то клиенту нужно вернуть код 501 (Not Implemented). Появился в HTTP/1.1.

406 Not Acceptable (Неприемлемо) - Запрошенный URI не может удовлетворить переданным в заголовке характеристикам. Если метод был не HEAD, то сервер должен вернуть список допустимых характеристик для данного ресурса. Появился в HTTP/1.1.

407 Proxy Authentication Required (Необходима прокси авторизация) - Ответ аналогичен коду 401 за исключением того, что аутентификация производится для прокси-сервера. Механизм аналогичен идентификации на исходном сервере. Появился в HTTP/1.1.

408 Request Timeout (Истекло время ожидания) - Время ожидания сервером передачи от клиента истекло. Клиент может повторить аналогичный предыдущему запрос в любое время. Например, такая ситуация может возникнуть при загрузке на сервер объёмного файла методом POST или PUT. В какой-то момент передачи источник данных перестал отвечать, например, из-за повреждения компакт-диска или потери связи с другим компьютером в локальной сети. Пока клиент ничего не передаёт, ожидая от него ответа, соединение с сервером держится. Через некоторое время сервер может закрыть соединение со своей стороны, чтобы дать возможность другим клиентам сделать запрос. Этот ответ не возвращается, когда клиент принудительно остановил передачу по команде пользователя или соединение прервалось по каким-то иным причинам, так как ответ уже послать невозможно. Появился в HTTP/1.1.

409 Conflict (Конфликт) - Запрос не может быть выполнен из-за конфликтного обращения к ресурсу. Такое возможно, например, когда два клиента пытаются изменить ресурс с помощью метода PUT.Появился в HTTP/1.1.

410 Gone (Удалён) - Такой ответ сервер посылает, если ресурс раньше был по указанному URL, но был удалён и теперь недоступен. Серверу в этом случае неизвестно и местоположение альтернативного документа, например, копии). Если у сервера есть подозрение, что документ в ближайшее время может быть восстановлен, то лучше клиенту передать код 404. Появился в HTTP/1.1.

411 Length Required (Необходима длина) - Для указанного ресурса клиент должен указать Content-Length в заголовке запроса. Без указания этого поля не стоит делать повторную попытку запроса к серверу по данному URI. Такой ответ естественен для запросов типа POST и PUT. Например, если по указанному URI производится загрузка файлов, а на сервере стоит ограничение на их объём. Тогда разумней будет проверить в самом начале заголовок Content-Length и сразу отказать в загрузке, чем провоцировать бессмысленную нагрузку, разрывая соединение, когда клиент действительно пришлёт слишком объёмное сообщение. Появился в HTTP/1.1.

412 Precondition Failed (Условие ложно) - Возвращается, если ни одно из условных полей заголовка запроса не было выполнено. Появился в HTTP/1.1.

413 Request Entity Too Large (Размер запроса слишком велик) - Возвращается в случае, если сервер отказывается обработать запрос по причине слишком большого размера тела запроса. Сервер может закрыть соединение, чтобы прекратить дальнейшую передачу запроса. Если проблема временная, то рекомендуется в ответ сервера включить заголовок Retry-After с указанием времени, по истечении которого можно повторить аналогичный запрос. Появился в HTTP/1.1.

414 Request-URI Too Large (Запрашиваемый URI слишком длинный) - Сервер не может обработать запрос из-за слишком длинного указанного URL. Такую ошибку можно спровоцировать, например, когда клиент пытается передать длинные параметры через метод GET, а не POST. Появился в HTTP/1.1.

415 Unsupported Media Type (Неподдерживаемый тип данных) - По каким-то причинам сервер отказывается работать с указанным типом данных при данном методе. Появился в HTTP/1.1.

416 Requested Range Not Satisfiable (Запрашиваемый диапазон не достижим) - в поле Range заголовка запроса был указан диапазон за пределами ресурса и отсутствует поле If-Range. Если клиент передал байтовый диапазон, то сервер может вернуть реальный размер в поле Content-Range заголовка. Данный ответ не следует использовать при передаче типа multipart/byteranges. Введено в RFC 2616 (обновление HTTP/1.1).

417 Expectation Failed (Ожидаемое неприемлемо) - По каким-то причинам сервер не может удовлетворить значению поля Expect заголовка запроса. Введено в RFC 2616 (обновление HTTP/1.1).

418 I'm a teapot (Я - чайник) - Этот код был введен в 1998 году как одна из традиционных первоапрельских шуток IETF в RFC 2324, Hyper Text Coffee Pot Control Protocol. Не ожидается, что данный код будет поддерживаться реальными серверами.

422 Unprocessable Entity (Необрабатываемый экземпляр) - Сервер успешно принял запрос, может работать с указанным видом данных, в теле запроса XML-документ имеет верный синтаксис, но имеется какая-то логическая ошибка, из-за которой невозможно произвести операцию над ресурсом. Введено в WebDAV.

423 Locked (Заблокировано) - Целевой ресурс из запроса заблокирован от применения к нему указанного метода. Введено в WebDAV.

424 Failed Dependency (Невыполненная зависимость) - Реализация текущего запроса может зависеть от успешности выполнения другой операции. Если она не выполнена и из-за этого нельзя выполнить текущий запрос, то сервер вернёт этот код. Введено в WebDAV.

425 Unordered Collection (Неупорядоченный набор) - используется в расширении WebDAV Advanced Collections Protocol. Посылается, если клиент указал номер элемента в неупорядоченном списке, или запросил несколько элементов в порядке, отличающемся от серверного.

426 Upgrade Required (Необходимо обновление) - Сервер указывает клиенту на необходимость обновить протокол. Заголовок ответа должен содержать правильно сформированные поля Upgrade и Connection. Введено в RFC 2817 для возможности перехода к TLS посредством HTTP.

428 Precondition Required (Необходимо предусловие) - Сервер указывает клиенту на необходимость использования в запросе заголовков условий, наподобие If-Match. Введено в черновике стандарта RFC 6585.

429 Too Many Requests (Слишком много запросов) - Клиент попытался отправить слишком много запросов за короткое время, что может указывать, например, на попытку DoS-атаки. Может сопровождаться заголовком Retry-After, указывающим, через какое время можно повторить запрос. Введено в черновике стандарта RFC 6585.

431 Request Header Fields Too Large (Поля заголовка запроса слишком большие) - Превышена допустимая длина заголовков. Сервер не обязан отвечать этим кодом, вместо этого он может просто сбросить соединение. Введено в черновике стандарта RFC 6585.

434 Requested host unavailable. (Запрашиваемый адрес недоступен) - Запрашиваемый адрес недоступен.

449 Retry With (Повторить с) - Возвращается сервером, если для обработки запроса от клиента поступило недостаточно информации. При этом в заголовок ответа помещается поле Ms-Echo-Request. Введено корпорацией Microsoft для WebDAV. В настоящий момент как минимум используется программой Microsoft Money.

451 Unavailable For Legal Reasons (Недоступно по юридическим причинам) - Доступ к ресурсу закрыт по юридическим причинам, например, по требованию органов государственной власти или по требованию правообладателя в случае нарушения авторских прав. Введено в черновике IETF за авторством Google, при этом код ошибки является отсылкой к роману Рэя Брэдбери "451 градус по Фаренгейту".

456 Unrecoverable Error (Некорректируемая ошибка) - Возвращается сервером, если обработка запроса вызывает некорректируемые сбои в таблицах баз данных. Введено корпорацией Microsoft для WebDAV.

499 () - Используется Nginx, когда клиент закрывает соединение до получения ответа.

5xx: Server Error (Ошибка сервера)

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

500 Internal Server Error (Внутренняя ошибка сервера) - Любая внутренняя ошибка сервера, которая не входит в рамки остальных ошибок класса. Появился в HTTP/1.0.

501 Not Implemented (Не реализовано) - Сервер не поддерживает возможностей, необходимых для обработки запроса. Типичный ответ для случаев, когда сервер не понимает указанный в запросе метод. Если же метод серверу известен, но он не применим к данному ресурсу, то нужно вернуть ответ 405. Появился в HTTP/1.0.

502 Bad Gateway (Плохой, ошибочный шлюз) - Сервер, выступая в роли шлюза или прокси-сервера, получил недействительное ответное сообщение от вышестоящего сервера. Появился в HTTP/1.0.

503 Service Unavailable (Сервис недоступен) - Сервер временно не имеет возможности обрабатывать запросы по техническим причинам (обслуживание, перегрузка и прочее). В поле Retry-After заголовка сервер может указать время, через которое клиенту рекомендуется повторить запрос. Хотя во время перегрузки очевидным кажется сразу разрывать соединение, эффективней может оказаться установка большого значения поля Retry-After для уменьшения частоты избыточных запросов. Появился в HTTP/1.0.

504 Gateway Timeout (Шлюз не отвечает) - Сервер в роли шлюза или прокси-сервера не дождался ответа от вышестоящего сервера для завершения текущего запроса. Появился в HTTP/1.1.

505 HTTP Version Not Supported (Версия HTTP не поддерживается) - Сервер не поддерживает или отказывается поддерживать указанную в запросе версию протокола HTTP. Появился в HTTP/1.1.

506 Variant Also Negotiates (Вариант тоже проводит согласование) - В результате ошибочной конфигурации выбранный вариант указывает сам на себя, из-за чего процесс связывания прерывается. Экспериментальное. Введено в RFC 2295 для дополнения протокола HTTP технологией Transparent Content Negotiation.

507 Insufficient Storage (Переполнение хранилища) - Не хватает места для выполнения текущего запроса. Проблема может быть временной. Введено в WebDAV.

508 Loop Detected (Обнаружена петля) -

509 Bandwidth Limit Exceeded (Исчерпана пропускная ширина канала) - Используется при превышении веб-площадкой отведённого ей ограничения на потребление трафика. В данном случае владельцу площадки следует обратиться к своему хостинг-провайдеру. В настоящий момент данный код не описан ни в одном RFC и используется только модулем "bw/limited", входящим в панель управления хостингом cPanel, где и был введён.

510 Not Extended (Нет расширения) - На сервере отсутствует расширение, которое желает использовать клиент. Сервер может дополнительно передать информацию о доступных ему расширениях. Введено в RFC 2774 для дополнения протокола HTTP поддержкой расширений.

511 Network Authentication Required (Требуется сетевая аутентификация) - Этот ответ посылается не сервером, которому был предназначен запрос, а сервером-посредником — например, сервером провайдера — в случае, если клиент должен сначала авторизоваться в сети, например, ввести пароль для платной точки доступа к Интернету. Предполагается, что в теле ответа будет возвращена Web-форма авторизации или перенаправление на неё. Введено в черновике стандарта RFC 6585.

tools.seo-auditor.com.ru

Проверка кода ответа сервера: коды статусов HTTP, сервисы

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

Код ответа сервера (код статуса HTTP) отдается при запросе любого URL’а вашего сайта. Он представляет собой трехзначное число, обозначающее статус страницы. Каждый вебмастер, наверное, слышал о 404 ошибке или 301 редиректе — в этих понятиях как раз и используется данный термин.

Содержание статьи:

Популярные коды статусов HTTP

Найти все возможные коды состояния HTTP для сервера вы можете в Википедии на этой странице.  Я же рассмотрю лишь основные из них, с которыми наиболее часто сталкиваются вебмастера:

• 200 OK — запрос выполнен успешно. Если у вас при проверке отображается код ответа сервера 200, значит с этой страницей все хорошо.
• 301 Moved Permanently — мы уже встречались с этим вариантом в статье про 301 редирект. Он означает, что страница навсегда перемещена на другой адрес (URL). При этом передается почти весь ссылочный вес.
• 302 Moved Temporarily — запрашивая страница временно доступна по другому адресу.
• 404 Not Found — по указанному УРЛу ничего не найдено. Желательно создать на своем сайте эффективную страницу 404 ошибки, где пользователю отображалась бы соответствующая информация и рекомендации.
• 403 Forbidden — ограничение прав доступа к конкретной странице. Администратор сайта может специально закрыть от пользователей системные файлы или директории. Также это может свидетельствовать об ошибке установки прав на папку. Если для доступа к странице нужна аутентификация, то используется код статуса HTTP 401 Unauthorized.
• 408 Request Timeout — истекло время ожидания сервером. Бывает при загрузке пользователем слишком объемного файла на сайт.
• 500 Internal Server Error — код ответа сервера 500 означает любую ошибку, не описанную в других статусах 5xx.
• 502 Bad Gateway — свидетельствует о проблемах в работе сервера DNS, прокси или хостинг провайдера. Обычно траблы возникают с последним — можете смело писать в тех.поддержку и спрашивать почему не работает сайт.
• 503 Service Unavailable — данный код означает, что сервер недоступен по техническим причинам (будь то перегрузка или отключение на тех.обслуживание). С помощью параметра Retry-After можно указать рекомендуемое время повторения запроса. В любом случае поисковые роботы позже еще зайдут на ваш сайт.
• 504 Gateway Timeout — сервер не успел вернуть ответ в определенный лимит времени. Обычно это случается при резких больших нагрузках на сайт, к которым ваш хостинг не готов. Как вариант решения — купить сервер помощнее.

Данные коды состояния HTTP попадаются вебмастерам наиболее часто, остальные, как я уже сказал выше, смотрите в Wikipedia.

Методы проверки ответа сервера

Чтобы проверить код ответа сервера есть разные варианты, все зависит от ситуации — нужно ли вам определить статус страницы своего/чужого сайта, предпочитаете использовать онлайн сервисы или десктопные приложения, это будет массовая проверка кодов ответа сервера или одна страница и т.п. Рассмотрим поочередно все возможности.

Код ответа сервера в Яндекс.Вебмастере

Когда требуется проверить HTTP статус конкретной страницы своего сайта, можно воспользоваться Яндекс.Вебмастером. Переходите в соответствующий раздел панели либо по этой ссылке.

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

Сервисы проверки ответа сервера

Разных веб-проектов, позволяющих проверить ответ сервера достаточно много. Из наших больше всего внушает доверие следующие три варианта:

PR-CY

Среди множества SEO инструментов портала PR-CY нашлась нужная нам функция проверки заголовков сервера. Кроме самого статуса выводится некоторая дополнительная информация.

Checkmy

Онлайн сервис специально создан для определения кода ответа сервера. Поддерживается gzip сжатие, кириллические домены, имеется выбор User Agent’а, а также мобильная версия. Выглядит симпатично.

Mainspy

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

HTTP Status Code Checker

Англоязычных сервисов, где можно проверить ответ сервера еще больше. Один из первых в выдаче — httpstatus.io. Тут все предельно просто: вводите адрес страницы, выбираете (если нужно) дополнительные параметры запроса и кликаете Submit.

Server Headers Checker

Очень часто функцию проверки HTTP кода состояния страниц можно встретить на тематических SEOшных порталах или даже блогах. Инструменты от Seobook — отличный тому пример. Особенностью сервиса есть возможность исследования сразу нескольких страниц.

Netpeak Spider — программа проверки ответа сервера

Когда-то я уже рассказывал о полезном софте от Netpeak. Для решения текущей задачи нам пригодится их программа Netpeak Spider, которая позволяет анализировать внутренние страницы проекта. Помимо поиска битых линков, дубрей, выгрузки МЕТА тегов и работы со ссылками, с ее помощью можно узнать разные параметры страниц сайта (в том числе и код ответа сервера).

В отличии от большинства предыдущих онлайн сервисов программа позволяет оценить сразу множество страниц. Удобно для анализа своего сайта, однако не уверен, что она сможет «обработать» набор разных URL’ов из заданного списка. Скачавайте ее тут. Распространяется бесплатно.

HEADMasterSEO

Недавно на почту написал автор еще одной подходящей программы — HEADMasterSEO. Она хоть является платным продуктом, но имеет возможност проверки до 500 ссылок просто так. Этого, как правило, должно хватить для задач рядового вебмастера.

Софт позволяет получить статусы ответов сервера для большого списка линков, а также считывает ряд других параметров: редиректы, время отклика, ссылки в head, X-Robots-Tag и т.п. Результаты можно сортировать, фильтровать и экспортировать в CSV. Работает программа под Windows и Mac OS X. Честно, не совсем понимаю, что значит ограничее 500 урлов «за одну операцию» — если допускается повторный запуск программы с новыми ссылками, то это безусловно удобнее чем юзать Tor для онлайн чекеров или запускать по 50 линков.

Массовая проверка ответа сервера

Напоследок предлагаю рассмотреть парочку сервисов, которые позволят осуществлять проверку кода ответа сервера для нескольких линков. Я, например, использовал их для поиска неработающих сайтов по купленным в биржах ссылкам (об этом расскажу в следующей статье).

Из наших нашел всего парочку более-менее нормальных сервисов, лучший из них — чекер от Dimax.biz.

Backlinks Checker Dimax.biz

Он предоставляет наиболее точные результаты по кодам ответа сервера. К сожалению, есть ограничение на число проверок — в сутки с одного IP-адреса можно сделать 2 запроса по 50 линков каждый. Для бОльших объемов придется купить PRO-аккаунт.

HTTP status code checker tool

Удобно, что данный проект кроме английского имеет локализацию интерфейса на русском и нескольких других языках. Над формой проверки найдете небольшое пояснение по кодам состояния HTTP и работе самого сайта. Ограничений не заметил, для удобства статус подсвечивается цветом: зеленый — все ок, черный или красный — проблемный URL.

Bulk Server Response Checker w/ Export

В отличии от рунета забугорные сервисы в основной массе отлично справляются со своей задачей. Хотя в результатах могут быть неточности. В данном случае разработчики также просят не использовать более 50-ти ссылок за раз, но по числу проверок лимитов нет. Плюсом можно назвать экспорт в Excel.

Urlitor

По функциональности все англоязычные сервисы также простые и, в принципе, одинаковые. Есть поле для ввода проверяемых ссылок и (в некоторых случаях) выбор User-Agent. В буржуйских проектах мне нравится, что все результаты представлены в виде таблиц для более легкого восприятия. Хотя у Dimax.biz ссылки сразу сортируются в зависимости от кода ответа сервера, что также удобно. Плюсом Urlitor можно назвать наличие активных ссылок в результатах — вы сможете быстро перейти по тем или иным линкам.

Bulk Redirect Checker Tool

Если я правильно понял, то основная задача данного сервиса — определение редиректов в зависимости от используемого User-Agent (браузера). Хотя при этом он показывает и коды HTTP статусов. Минимум дизайна, результаты отображаются достаточно быстро.

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

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

tods-blog.com.ua

Проверка заголовков сервера - Проверка HTTP статусов

Для чего предназначен инструмент "Проверка заголовков сервера"?

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

Что такое заголовки сервера и для чего они нужны?

Различные устройства обмениваются между собой информацией с помощью протокола HTTP (аббревиатура от HyperText Transfer Protocol – "Протокол передачи гипертекста"), и заголовки в этом "общении" играют очень важную роль. В заголовке передается основная информация о соединении, которое устанавливается, и о передаваемых через это соединение данных.

Как работает инструмент "Проверка HTTP статусов" и для чего он нужен?

После того, как вы введете адрес ресурса и нажмете кнопку "Показать", сервер обработает запрос и выдаст результат. В самой верхней строке ответа вы увидите состояние (статус) сервера: например, HTTP/1.1 200 OK.

Что такое статус сервера?

Статусов у сервера – четыре, и они сгруппированы по назначению.

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

Коды 3xx обозначают, что сервер перенаправил запрос и получить информацию о ресурсе можно другим способом.

Коды 4xx – это самая обширная группа статусов сервера, которая обозначают, что в запросе допущена ошибка.

Коды 5xx обозначают, что в работе запрашиваемого сервера произошел какой-то сбой, и получение информации об интересующем ресурсе пока невозможно.

Более подробно о статусах запросов вы можете узнать из таблицы "Перечень кодов HTTP" ниже.

Что такое метод GET и метод POST?

Существует три типа запросов, принимаемых сервером: GET, POST и HEAD, но мы поговорим о наиболее распространенных – первых двух. Третий метод используется достаточно редко, потому как HEAD запрашивает только заголовок ответа, а полноценный обмен данными при этом не происходит. Метод GET используется при запросе к серверу по умолчанию, а POST – только при однозначном указании в запросе формы. Веб-мастера должны учитывать, что при запросе методом GET серверу передаются все данные формы вместе с URL, а при использовании метода POST данные перемещаются не в URL, а в само тело запроса.

Коды 2xx (успешно)

Перечень кодов статуса HTTP, использующихся при успешном запросе (коды 2xx).

Коды 3xx (перенаправление)

Перечень кодов статуса HTTP, использующихся при перенаправлении запроса (коды 3xx).

Коды 4xx (ошибка клиента)

Содержит перечень кодов статуса HTTP, использующихся для обозначения возможных ошибок в клиентском запросе (коды 4xx).

Коды 5xx (ошибка сервера)

Перечень кодов статуса HTTP, использующихся для обозначения возможных ошибок сервера (коды 5xx).

www.cy-pr.com

Http — что это такое, как просмотреть заголовки и проверить код ответов сервера, что означают коды 200, 301, 302, 404 и 500 | KtoNaNovenkogo.ru

Http — что это такое, как просмотреть заголовки и проверить код ответов сервера, что означают коды 200, 301, 302, 404 и 500

Обновлено: 16 июля 2017

Здравствуйте, уважаемые читатели блога KtoNaNovenkogo.ru. Сегодня я хочу поговорить в первую очередь о таком важном понятии для правильной работы любого сайта, как правильный ответ сервера. Что это такое? Сначала мы рассмотрим чуток теории о том, какие коды ответа бывают, на какие стоит обратить особое внимание, ну и как их проверить для всех страниц своего проекта.

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

Что такое http и онлайн сервисы для просмотра ответа сервера

Итак, при запросе браузером пользователя какой-либо страницы вашего сайта вместе с Html кодом этой вебстраницы, обозревателю будет передан и так называемый Http заголовок с ответом хоста, в котором помимо прочей информации будет указан код. Он представляет из себя трехзначное число (наиболее часто встречаются варианты 200, 301, 302, 404), которое обозначает ситуацию, сложившуюся на хосте при обработке запроса браузера.

Что такое HTTP? Это протокол, по которому осуществляется обмен данными между вебсервером, на котором расположен интересующий вас сайт, и вашим браузером. Расшифровывается аббревиатура как Hypertext Transfer Protocol. Браузер пользователя обращается к серверу с запросом какого-либо документа и получает соответствующий ответ.

Если ответ на http запрос приходит положительный (200 OK), то браузер начинает загрузку нужного ему файла. Если отрицательный, то информирует об этом пользователя. Имеется еще и шифрованный протокол SHTTP, но сути дела это не меняет.

Например, при успешной загрузке страницы, в браузер будет передан Http заголовок с кодом 200 OK (кроме цифр еще приводится и поясняющая надпись). В случае, если запрошенная страница на сервере найдена не будет, то браузер получит ответ 404 Not Found. Можете сами проверить ответ главной страницы своего сайта, например, на этом сервисе.

К примеру, введя туда заведомо несуществующий адрес страницы своего ресурса (для этого после доменного имени можно написать любую ахинею, например, http://ktonanovenkogo.ru/трали-вали), будет получен примерно такой Http заголовок:

И это хорошо, ибо поисковые системы правильно обработают данный ответ сервера и не будут добавлять в индекс вашу несуществующую вебстраницу (404 страница для Joomla, 404 Not Found для Вордпресса).

Причем стоит учитывать, что несуществующие документы могут появиться как по вашей вине, так и из-за ошибки какого-либо доброжелателя, разместившего где-нибудь обратную ссылку на ваш сайт с ошибкой. Посмотреть те несуществующие документы (фактически битые ссылки), которые имеются на вашем ресурсе, вы можете в Яндекс Вебмастере или панели Google, как это было описано в статье Проверка битых ссылок.

Гораздо хуже будет, если несуществующий документ не будет выдавать в ответ 404, ибо в этом случае на вашем сайте по разным адресам (URL) несуществующих страниц (а их может быть сколь угодно много) будет выдаваться одна и так же вебстраница ошибки 404. На лицо будет откровенное дублирование контента, которое может повлечь за собой санкции со стороны поисковиков. А оно вам надо — на ровном месте наступать на грабли.

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

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

Обязательно проверьте коды ответа хотя бы у некоторых вебстраниц вашего ресурса, и особенно проверьте правильность цифр, выдаваемых в ответ на запрос несуществующего документа (введите что-то типа http://vash-domen.ru/jhguytrhkfkfijd). Для этой цели можно воспользоваться приведенным выше онлайн сервисом или же рядом других, способных показать все это:

1. Чтобы быть абсолютно уверенным в том, что поисковики правильно интерпретируют коды ответа вашего хоста, можете воспользоваться инструментом Яндекса Проверка ответа сервера, который, правда, будет вам доступен только после регистрации в Вебмастере, но добавиться туда, так же как и в панель Гугла, нужно будет в любом случае.
2. Есть еще любопытный онлайн сервис, который позволит узнать коды ответов сразу для 200 введенных вами Урлов. Довольно удобная вещь, ибо можно будет загрузить список Урлов и быстро получить разблюдовку.

Все возможные варианты кодов ответа сервера

Обращу ваше внимание еще и на ответ сервера 301, который появляется в случае использования редиректа (перенаправление навсегда). Дело в том, что поисковые системы рекомендуют использовать 301 редирект в случае изменения адреса (URL) страницы сайта (он будет перебрасывать посетителя со старого Урла на новый) или, например, при склейке зеркал сайта с WWW или без WWW, как это было описано тут.

Если вы использовали 301 редирект, то можете проверить правильность Http ответа при обращении к склеенным Урлам. Например, при запросе www.ktonanovenkogo.ru сервер дает правильный ответ 301 Moved Permanently:

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

Но сделал он все очень грамотно, ибо поначалу новые оптимизаторы, занимающиеся продвижением этого проекта, никак не могли понять, отчего позиции сайта резко просели. Как это реализовать на практике я не знаю, но тот вебмастер сделал так, что все страницы успешно открывались и отлично работали, но при этом в Http заголовке для всех них сервер давал ответ 404 Not Found.

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

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

Вообще, все коды ответа сервера можно разделить на пять групп:

1. 100-199 являются информационными, говорящими о том, что сервер обрабатывает запрос
2. 200-299 означают, что запрашиваемые у сервера данные были успешно переданы (например, 200 — запрос был успешно выполнен и требуемые данные переданы)
3. 300-399 означают переадресацию и необходимость выполнить дополнительные действия (например,301 — грубо говоря, документ изменил адрес навсегда; 302 — документ изменил адрес временно)
4. 400-499 означают, что запрос был сформирован не правильно и выполнен быть не может (например, 404 — документ по указанному адресу не найден на хосте)
5. 500-599 означают, что на сервере произошла ошибка и запрос выполнен быть не может

Более подробно посмотреть все возможные коды ответа в Http заголовке вы можете, например, в Википедии.

Удачи вам! До скорых встреч на страницах блога KtoNaNovenkogo.ru

Твитнуть

Поделиться

Плюсануть

Поделиться

Отправить

Класснуть

Линкануть

Запинить

Подборки по теме:

ktonanovenkogo.ru

Смотрите также

• 
  Как в браузере поменять размер шрифта
• 
  В яндекс браузере не работает vksaver
• 
  Как в мозиле открыть историю браузера
• 
  В каком браузере смотреть мегафон тв
• 
  Как восстановить текст в браузере яндекс
• 
  Пропала панель инструментов в яндекс браузере
• 
  Какой браузер на андроид поддерживает icloud
• 
  Как скрыть полосу прокрутки в браузере
• 
  Как очистить кэш браузера виндовс 8
• 
  Игры в браузере онлайн для мальчиков
• 
  В каком браузере работает втб 24