303 see other что это

Удобный справочник кодов состояния соединения.

Код состояния HTTP — это часть первой строки ответа сервера при запросах по протоколу.

Содержание.

100.

Информационные

100 Continue — сервер удовлетворён начальными сведениями о запросе, клиент может продолжать пересылать заголовки.

101 Switching Protocols — сервер предлагает перейти на более подходящий для указанного ресурса протокол. Список предлагаемых протоколов сервер обязательно указывает в поле заголовка Update. Если клиента это заинтересует, то он посылает новый запрос с указанием другого протокола.

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

105 Name Not Resolved — возникла ошибка в связи с неверным или отсутствующем IP-адресом DNS-сервера.

Успешные

200 OK — успешный запрос. Клиенту отправлены запрошенные данные.

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

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

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

204 No Content — сервер успешно обработал запрос, но в ответе были переданы только заголовки без тела сообщения. Клиент не должен обновлять содержимое документа, но может применить к нему полученные метаданные.

Используется для того, чтобы позволить осуществить ввод или какие-либо действия без необходимости обновлять документ (страницу).

205 Reset Content — сервер обязывает клиента сбросить введённые пользователем данные, при этом тело сообщения не передаётся, поэтому страницу обновлять не обязательно.

Используется когда пользователь заполняет форму, а сервер посылает браузеру запрос на очистку формы.

206 Partial Content — сервер удачно выполнил частичный GET-запрос, возвратив только часть сообщения. В заголовке Content-Range сервер указывает байтовые диапазоны содержимого.

207 Multi-Status — сервер передаёт результаты выполнения сразу нескольких независимых операций. Они помещаются в само тело сообщения в виде XML-документа с объектом multistatus.

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

Перенаправление

300 Multiple Choices — по указанному URI существует несколько вариантов предоставления ресурса по типу MIME, по языку или по другим характеристикам. Сервер передаёт с сообщением список вариантов, давая клиенту сделать выбор.

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

301 Moved Permanently — запрошенный документ был перенесен на новый URI адрес которого указанный в поле Location.
Некоторые клиенты некорректно ведут себя при обработке данного кода.

302 Found, 302 Moved Temporarily — запрошенный документ временно доступен по другому URI, указанному в заголовке в поле Location.
Изначально представлял собой основной способ создания временного перенаправления. Тем не менее, сегодня существуют и другие – этичные, и неэтичные – способы его применения.

303 See Other — код указывает пользователю на то, что запрашиваемый ресурс можно найти по URL, который отличается от указанного в запросе. Это не обязательно означает, что что-то было перемещено, этот код лишь предоставляет адрес, по которому следует запрашивать подобный ответ.
Этот метод главным образом существует для того, чтобы позволить выводу данных POST-активированного скрипта перенаправить агента пользователя к выбранному ресурсу.

304 Not Modified — сервер возвращает такой код, если документ не изменился с момента последнего посещения сервера клиентом.
В этом коде сообщается о том, что параметры документа If-Modified-Since или If-Match не менялись с момента создания последнего кэша, и нет необходимости в повторной отправке ресурса.

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

306 — использовался раньше, в настоящий момент зарезервирован.

307 Temporary Redirect — запрашиваемый ресурс, на короткое время, доступен по другому URI указанному в поле Location. Этот код был введён вместе с 303 вместо 302-го для избежания неоднозначности.

Ошибки клиента

400 Bad Request — сервер обнаружил в запросе клиента синтаксическую ошибку.

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

402 Payment Required — предполагается использовать в будущем, сейчас не используется.
Код предусмотрен для платных пользовательских сервисов, а не для хостинговых компаний. Имеется в виду, что эта ошибка не будет выдана хостинговым провайдером в случае просроченной оплаты его услуг.

404 Not Found — самая распространенная ошибка в интернете, основная причина — ошибка в написании адреса Web-страницы.
Сервер понял запрос, но не нашёл соответствующего ресурса по указанному URI.

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

406 Not Acceptable — запрошенный URI не может удовлетворить переданным в заголовке характеристикам. Если метод был не HEAD, то сервер должен вернуть список допустимых характеристик для данного ресурса.

407 Proxy Authentication Required — ответ аналогичен коду 401 за исключением того, что аутентификация производится для прокси-сервера. Механизм аналогичен идентификации на исходном сервере.

408 Request Timeout — время ожидания сервером передачи от клиента истекло. Клиент может повторить запрос в любое время. Например, такая ситуация может возникнуть при загрузке на сервер объёмного файла методом POST или PUT.

409 Conflict — запрос не может быть выполнен из-за конфликтного обращения к ресурсу. Такое возможно, например, когда два клиента пытаются изменить ресурс с помощью метода PUT.

410 Gone — сервер посылает такой код если ресурс раньше был по указанному URL, но был удалён и теперь недоступен.
Серверу в этом случае неизвестно и местоположение альтернативного документа, например, копии. Если у сервера есть подозрение, что документ в ближайшее время может быть восстановлен, то лучше клиенту передать код 404.

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

412 Precondition Failed — возвращается, если ни одно из полей запроса не было выполнено.
Иными словами, один или более заголовок запроса был возвращен с атрибутом false.

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

414 Request-URL Too Long — сервер не может обработать запрос из-за слишком длинного указанного URL. Такую ошибку можно спровоцировать, например, когда клиент пытается передать длинные параметры через метод GET, а не POST.

415 Unsupported Media Type — сервер заметил, что часть запроса была сделана в неподдерживаемом формате.
В запросе не указываются какие-либо типы медиа, которые поддерживаются ресурсом или сервером. Например, пользователь запрашивает изображение с расширением файла, которое не поддерживается сервером.

416 Requested Range Not Satisfiable — в поле Range заголовка запроса был указан диапазон за пределами ресурса и отсутствует поле If-Range. Если клиент передал байтовый диапазон, то сервер может вернуть реальный размер в поле Content-Range заголовка.

417 Expectation Failed — по каким-то причинам сервер не может удовлетворить значению поля Expect заголовка запроса

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

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

423 Locked — целевой ресурс заблокирован от применения к нему указанного метода.

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

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 — запрашиваемый адрес недоступен.

444 — возвращается только сервером nginx. Бывают случаи, когда вы можете распознать по неким признакам бота, сканер или хакера. В таких случаях хорошо бы просто закрывать соединение. Вот для таких случаев и создан ответ 444. Собственно NGINX просто посылает в ответ пустой пакет (без заголовков) TCP RST и закрывает соединение.

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, когда клиент закрывает соединение до получения ответа.

Ошибка сервера

500 Internal Server Error — любая внутренняя ошибка сервера, которая не входит в рамки остальных ошибок класса.

501 Not Implemented — сервер не поддерживает возможностей, необходимых для обработки запроса. Типичный ответ для случаев, когда сервер не понимает указанный в запросе метод. Если же метод серверу известен, но он не применим к данному ресурсу, то нужно вернуть ответ 405.

502 Bad Gateway — сервер, выступая в роли шлюза или прокси-сервера, получил недействительное ответное сообщение от вышестоящего сервера.

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

504 Gateway Timeout — сервер в роли шлюза или прокси-сервера не дождался ответа от вышестоящего сервера для завершения текущего запроса.

505 HTTP Version Not Supported — сервер не поддерживает или отказывается поддерживать указанную в запросе версию протокола HTTP.

506 Variant Also Negotiates — в результате ошибочной конфигурации выбранный вариант указывает сам на себя, из-за чего процесс связывания прерывается.

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

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

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

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

Источник

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

Если вы управляете веб-сайтами, понимание переадресации HTTP необходимо для надежной работы сайта. В этой статье мы подробно рассмотрим коды состояния HTTP 3xx, чтобы вы могли понять, как они работают, как лучше всего ими управлять и как они влияют на SEO.

Цель переадресации HTTP

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

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

Давайте подробнее рассмотрим другие причины перенаправления вашей страницы:

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

Подводя итог, Google определяет перенаправление для управления сканированием и индексированием (категория расширенной документации по SEO). Центр поиска Google объясняет переадресацию HTTP как практику выполнения плавного перехода, доступа к странице через несколько URL-адресов, исправления устаревших URL-адресов и отправки пользователей с удаленных страниц на новые, тем самым исключая 404 не найденные ошибки.

Основы веб-протокола

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

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

Этот протокол запрос-ответ работает через TCP-соединения, которые используются для связи с сервером. Протокол управления передачей позволяет интернет-поисковикам взаимодействовать с любыми доступными идентифицированными ресурсами, представленными во всемирной паутине. Связь пользователя с веб-серверами, серверами видео и сообщений осуществляется через HTTP. Таким образом клиенты могут получить доступ к веб-страницам.

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

Есть режимы работы HTTP прокси. HTTP-клиент используется для защиты браузера пользователя. Он отправляет сообщения запроса на сервер. HTTP-сервер отвечает за HTTP-ответные соединения. Принцип работы HTTP-прокси можно представить следующим образом:

Основные преимущества протоколов HTTP:

Согласно Hitech Whiz, есть и другие преимущества протокола передачи гипертекста, которые следует учитывать:

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

Что такое коды состояния ответа HTTP?

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

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

Стоит отметить, что некоторые коды состояния и ошибки напрямую влияют на SEO. В то время как классы 1xx и 2xx не сильно влияют на поисковую оптимизацию (хотя лучше всего использовать ответ 200), классы 300, 400 и 500 могут негативно повлиять на сканирование и индексирование ваших веб-страниц. Вы всегда должны следить за кодами состояния и ошибками 4xx и 5xx, так как это может быть очень вредным для рейтинга вашего сайта в целом.

Коды HTTP 300, возможно, играют центральную роль для SEO. Этот класс кодов статуса отвечает за передачу всего SEO-значения от ваших старых URL-адресов к новым. Таким образом, необходимо вникнуть в значение каждого 300-уровневого кода (временные или постоянные перенаправления, прокси, множественный выбор и т. Д.).

Полный список кодов состояния HTTP 3xx

Коды состояния HTTP предназначены для перенаправления URL-адресов. Коды уровня 300 обозначают различные типы перенаправлений HTTP. Маркетологи обычно используют коды состояния 3xx для отслеживания и анализа пользовательского опыта, поведения пользователей веб-сайта и эффективности SEO. В DataTracker ресурсы определяют четыре типа переадресаций распределенных по кодам состояния HTTP 300 уровня:

Коды состояния 300 уровня появляются, когда необходимо указать ответ перенаправления от сервера. Другой пример действия класса кода состояния HTTP 3xx — это когда удаленная страница сохраняет свой рейтинг. Кроме того, редиректы пригодятся, когда необходимо исправить неработающий URL.

Например, перенаправление 301 было использовано через PHP для перемещения всего трафика на новую страницу https://eurovps.com:

Таким образом, он сохраняет рейтинг прежнего URL-адреса. Тот же алгоритм можно использовать для исправления неработающих URL-адресов с помощью постоянного редиректа.

Перенаправления не ожидают появления ошибок, связанных с другими кодами ответа. Например, перенаправления не решают проблемы с информационными ответами или ошибками сервера / клиента ( Не реализовано = 501; Плохой шлюз = 502; Непроцессированная сущность = 420).

Давайте подробнее рассмотрим каждый 300-уровневый код, чтобы понять их влияние на SEO и рейтинг веб-сайта. Вам необходимо просмотреть девять кодов состояния 3xx, а также их особенности, функции, преимущества и различия.

300 Multiple Choices

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

Еще одна причина для использования 300 редиректов — это соответствие требованиям агентских переговоров. Сервер информирует пользовательский агент о доступных типах представлений на выбор. Присмотритесь к примеру, чтобы увидеть 300-редирект в действии:

Вы можете увидеть /fooи /barв кодировке. Местоположение указывается, когда доступны для выбора оба варианта.

301 Moved Permanently

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

Давайте объясним концепцию постоянных перенаправлений HTTP на примере реального случая:

Вы можете увидеть /fooи /barв кодировке. Местоположение указывается, когда доступны для выбора оба варианта.

301 перемещен навсегда

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

Давайте объясним концепцию постоянных перенаправлений HTTP на примере реального случая:

Страница часто задаваемых вопросов размещена на субдомене ( https://faq.website.com).

Рассмотрим еще один пример постоянного перенаправления (301 редирект). Здесь мы видим код состояния 301 HTTP, используемый для перенаправления пользователей и поисковых систем в новое место. Выделенные изменения выделены жирным желтым цветом.

Программисты часто используют.htaccessфайл для реализации различных типов перенаправления, включая перенаправление 301. Следует учитывать два метода переадресации 301:

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

Обратите внимание, что JavaScript далеко не оптимален для SEO. Иногда Google неправильно интерпретирует 301 редирект в JavaScript. Если вас интересует постоянное перенаправление, оптимизированное для SEO, лучше выбрать один из перечисленных выше методов.

302 Found

В REST API есть еще один часто используемый код состояния. По сравнению с постоянными перенаправлениями 301, используются 302-уровневые, когда требуются некоторые временные перенаправления. Например, вы знаете об изменениях в этом URL-адресе, который вы скоро перенаправите, или прежняя страница будет восстановлена ​​в какой-то момент. Еще один случай, когда вы должны удалить старую страницу, но вам нужно перенаправить весь трафик и сохранить оценки рейтинга на временном URL-адресе. Среди других причин использования кода состояния 302:

Стоит отметить, что реализация 302 редиректа может осуществляться так же, как и для 301-го уровня. Здесь также применима рекомендация избегать кодирования JavaScript в целях оптимизации SEO.

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

303 See Other

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

Код статуса 303 не имеет значения для SEO. Тем не менее, это может помочь повысить удобство использования и реализовать маркетинговые цели, когда можно предложить другой URL-адрес вместо уже посещенного.

303 See Other

Этот код обычно используется в REST API, как и другие перечисленные выше 3xx. Если повторная передача не требуется, можно использовать неизмененный код состояния. Если страница еще не была изменена, можно сделать переадресацию без кеша.

Давайте подробнее рассмотрим кодирование на примере перенаправления 304. Код состояния указывается в запрошенном методе и URL-адресе.

305 Use Proxy

Этот код состояния HTTP пока не рекомендуется. Некоторые браузеры не позволяют использовать этот тип перенаправления. Например, Mozilla Firefox и Internet Explorer запрещают пользователям выполнять переадресацию 305 по соображениям безопасности. Основное объяснение этой ситуации — единственный прокси-сервер, используемый для обработки запроса и предоставления доступа к веб-ресурсу. Этот подход опасен для некоторых браузеров.

306 Switch Proxy (Unused)

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

307 Temporary Redirect

Этот код состояния HTTP очень похож на код состояния 302. Вот почему метод реализации, необходимый для перенаправления, такой же, как для 301 и 302. Давайте углубимся в разницу между 207 и 302, поскольку оба они относятся к временным перенаправлениям HTTP. Специалисты до сих пор дискутируют на эту тему. Для наших целей есть два мнения о 307 редиректах:

Это означает, что любые изменения метода запроса GET в 302 редиректах приводят к непредсказуемым результатам в сети. Этого не происходит с 307 редиректами. На рисунке ниже показан пример использования временного перенаправления на уровне 307.

308 Permanent Redirect

Этот код состояния считается экспериментальным, но имеет ту же семантику, что и постоянное перенаправление 301. Единственная разница между перенаправлениями 308 и 301 — это доступность изменений метода HTTP. В то время как перенаправления 301 позволяют пользовательским агентам изменять используемые методы HTTP, код состояния 308 подразумевает неизменяемые методы HTTP-запроса для перенаправления.

Код состояния 308 HTTP довольно новый, так как он был введен только в 2015 году. Некоторые браузеры до сих пор не могут распознавать 308 редиректы и показывать пользователям пустые страницы вместо перенаправленных (например, Internet Explorer 11). Вот почему 301 постоянная переадресация будет предпочтительнее из-за лучшей поддержки и удобства для SEO. Код состояния HTTP уровня 308 по-прежнему плохо поддерживается, и поисковые роботы не всегда его распознают.

Значение кода состояния HTTP 3xx для SEO

300-уровневая переадресация важна для сохранения ценности SEO. Если вам нужно перейти с одной старой страницы на другую и вы не хотите терять ее рейтинг, рекомендуется временное или постоянное перенаправление. Чтобы сохранить ссылочный вес и не навредить SEO вашего сайта, когда дело доходит до редизайна или других изменений, вы можете использовать несколько кодов HTTP 300:

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

Когда использовать 301 или 302 редирект для SEO

Когда дело доходит до временных и постоянных перенаправлений, коды состояния HTTP 301 и 302 всегда имеют приоритет. Но есть разница между этими кодами HTTP 300. Вот первый сценарий. Вы решили навсегда удалить свой старый сайт. Но этот URL-адрес часто посещался и был высоко оценен поисковыми системами. Есть рекомендация использовать постоянное перенаправление 301, чтобы поддерживать ссылочный вес и рейтинг Google.

Второй сценарий — это когда вы реструктурируете свой веб-сайт и сохраняете результаты поиска в течение некоторого краткосрочного периода. Сайт потеряет SEO-ценность. Поисковые системы сохранят ваш старый URL, но начнут индексировать вашу новую страницу после перенаправления. Если вы уверены, что все обновления и редизайны подойдут к концу и вы вернетесь к старому URL-адресу, лучше использовать 302 редиректа (временный).

Если вы неправильно используете коды HTTP 300, эти ошибки могут повлиять на вашу поисковую оптимизацию. Вот краткий список случаев, когда стратегии SEO терпят неудачу из-за неправильных перенаправлений:

Обратите внимание, что код состояния 301 подходит для тематических кластеров. Если вам действительно нужны постоянные перенаправления, не используйте 302. Предотвратите риск потери рейтинга и трафика. Перенаправления 302 заставляют поисковые системы продолжать индексировать ваши старые страницы и не позволяют им передавать ссылочный вес вашим новым. Убедитесь, что вы всегда проверяете точность кода состояния HTTP на своем веб-сайте с помощью специального программного обеспечения, такого как WTOOLS и Redirect Checker.

301 и 302

Постоянные перенаправления

301 имеет более сильную канонизацию для Google. В то же время представитель команды Google Джон Мюллер заявил, что коды состояния HTTP 308 и 301 обеспечивают одинаковые свойства перенаправления и SEO.

Временные перенаправления

Код статуса 307 предпочтительнее для специалистов по SEO. Из-за изменения синтаксиса 302 перенаправлений это может вызвать любое неожиданное поведение. Кроме того, в этом руководстве Rest API указано, что 307 редиректов пригодятся при переносе клиентских запросов на другой хост.

MOZ предлагает 302 редиректа, если по существу невозможно определить, идентифицировали ли поисковые системы страницу как совместимую. Таким образом, любой контент, который временно перемещается на другую страницу, должен быть перенаправлен с помощью кода состояния 302 HTTP. Сканеры отметят изменения, и URL-адрес будет правильно проиндексирован.

Проверка кодов состояния HTTP в рейтинге SE

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

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

Инфографика будет содержать доминирующий класс кода состояния HTTP (1xx, 2xx, 3xx, 4xx, 5xx). Дополнительно в отчете (под основной инфографикой) будет указано количество перенаправлений и отсоединенных страниц.

Во время полного аудита веб-сайта SE Ranking обнаруживает слабые места и ошибки, связанные с кодами состояния HTTP, предоставляет описания проблем и предлагает способы их устранения для повышения производительности вашего веб-сайта в Интернете.

Какие коды 3xx вам действительно нужно знать

Все коды HTTP 300 заслуживают внимания современных представителей бизнеса, которые заинтересованы в хорошей видимости в Интернете. Например, 300 (множественный выбор) будет полезен для выполнения некоторых маркетинговых стратегий, когда пользователь должен выбирать между несколькими объектами одновременно. Код состояния 303 (см. Прочее) пригодится, когда другой URL-адрес должен использоваться для перенаправления на интересующий ресурс.

Но основные коды HTTP 300 — это 301, 302 и 307, потому что они используются для временных и постоянных перенаправлений. Эти коды состояния рекомендуются для обеспечения миграции веб-сайтов с оптимизацией поисковых систем, изменения URL-адресов, реструктуризации и обновлений сайта, смены доменов или коротких повторных публикаций для страниц веб-сайтов.

Стоит отметить, что к процессу перенаправления предъявляются некоторые требования, чтобы соответствовать стандартам рейтинга Google и не терять ссылочный вес. Следует помнить пять основных советов:

Источник