Сервер ответил ошибкой проверьте готов ли ваш сервер принимать запросы от маркетплейса

Заголовок
POST /yandexbuy2/order/cancellation/notify HTTP/1.1
Content-Type: application/json;charset=utf-8

ОператорПК

06.09.21 — 13:47

Ёпрст

1 — 06.09.21 — 15:13

ОператорПК

2 — 06.09.21 — 15:17

(1) ага, только в чем ошибка то? Я все предельно на Аглицком написал http://127.0.0.1/UT11HTTP/hs/Marketplace_API_/getyml?НомерКампании=21990000 — что тут не так?

yzimin

3 — 06.09.21 — 16:12

И всё-таки попробуйте использовать веб-сервис из расширения этого модуля. У нас работает с начала года без проблем

Вафель

4 — 06.09.21 — 16:14

некорректно опубликован сервис

ОператорПК

5 — 06.09.21 — 16:29

(3) с этого и начинал… не от хорошей жизни как говориться стал переносить из расширения в основную. вы чем тестировали работу этого HTTP сервиса? не сохранилось рабочего запроса?

ОператорПК

6 — 06.09.21 — 16:30

(4) что там можно не корректно опубликовать?

yzimin

7 — 06.09.21 — 16:31

(5)яндекс умеет посылать тестовые запросы, там есть специальный интерфейс, из его личного кабинета и отлаживали

yzimin

8 — 06.09.21 — 16:33

(7) +там же можно посылать тестовые заказы, самопроверка

Вафель

9 — 06.09.21 — 16:33

(6) >>Ошибка в строке соединения с информационной базой

ОператорПК

10 — 06.09.21 — 16:35

(7) понятно…. хотел сперва «локально» все чтоб работало отладить потом уже выпускать «наружу»… если не секрет сертификат безопасности ставили?

ОператорПК

11 — 06.09.21 — 16:36

(9) это написано прямо в (0)…. вопрос в том и есть: что некорректно в моем запросе http://127.0.0.1/UT11HTTP/hs/Marketplace_API_/getyml?НомерКампании=21990000?

yzimin

12 — 06.09.21 — 16:41

(10) у нас по https работает с доменным именем и купленным сертификатом, SHA1-отпечаток SSL-сертификата мы не указывали, если вы об этом

ОператорПК

13 — 06.09.21 — 16:42

(12) да об этом. спасибо.

yzimin

14 — 06.09.21 — 16:42

(11) а авторизационный токен в запросе передаёте? Точкой остановки вообще попадаете в отладку? А то может у вас сам веб-сервис даёт отлуп

ОператорПК

15 — 06.09.21 — 16:49

(14) «авторизационный токен в запросе передаёте» — нет, а разве это нужно в данном случае? Тут например https://its.1c.ru/db/metod8dev/content/5756/hdoc  про это вроде как нет ничего. Точкой останова в отладку не попадает… не доходит до этого.

ОператорПК

16 — 06.09.21 — 16:50

+(14) вообще представители яндекса сообщили что «технически» можно без сертификатов работать («типа дела ваше»)

unbred

17 — 06.09.21 — 16:52

unbred

18 — 06.09.21 — 16:54

+ (17)  ПолучаемJSON — просто пустой временный файлик

Смотрящий

19 — 06.09.21 — 16:57

yzimin

20 — 06.09.21 — 16:58

ОператорПК

21 — 06.09.21 — 17:03

ОператорПК

22 — 06.09.21 — 17:06

+(21) токен AQAAAABXWjvYAбла бла бла в настройках базы есть конечно.

yzimin

23 — 06.09.21 — 17:12

ОператорПК

24 — 06.09.21 — 17:14

(23)а нельзя договориться о «сервисном времени» когда можно обновлять базу? а если отключили от сервиса то восстановить его сложно?

yzimin

25 — 07.09.21 — 08:54

(24) На время пока ваш сервер не отвечает на запросы, магазин не продаёт. Нам было выгоднее арендовать выделенный сервер, который 24/7 работает, УТ там не обновляем, никакие работы не проводим. Включается магазин, когда начнут проходить ответы от сервера.

dark_stealth

26 — 29.09.21 — 08:30

У меня с этим модулем еще веселее- отдает 404 ошибку, вроде все делал по их инструкции. Но через личный кабинет при проверке 404, все другие базы опубликованы и работают, претензий к веб-серверу нет. Здесь при обращении к корню публикации — чистая страница, при /cart или /stocks ответ Not found. Модуль не работает ?

dark_stealth

27 — 29.09.21 — 11:01

сорри ошибка в url, правильный https://vashserver.ru/опубликованная база/hs/Marketplace_API

На данной странице описаны типичные сложности, с которыми сталкиваются пользователи плагина «Интеграция с Яндекс.Маркет».

Содержание:

1. Ваша система отвечает через API с ошибками
2. В админ-панель не приходят заказы
   2.1. А были ли заказы?
   2.2. Возможные ошибки
   2.3. Вы отказались принимать заказ
3. Не передаются статусы в маркет
4. Проблемы с передачей остатков
   4.1. При входящих обновлениях
   4.2. При исходящих отправках
5. Не скачивается акт-приёма передачи
6. Магазин отключен из-за ошибок в работе API
7. Заказ по FBS, но кнопки от DBS
8. Инструменты диагностики
9. Другие ошибки и вопросы

1. Ваша система отвечает через API с ошибками

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

В этом случае нужно зайти в лог запросов (Настройки — Лог запросов), 

Далее переключиться на «Ошибки» и посмотреть детали конкретных ошибок

Пример 1

Детали ошибки:

В этом конкретном примере мы видим, что на некоторые запросы наш сайт ответил ошибкой с кодом 500 (Internal Server Error) В тексте ответа содержится информация об ошибке с номером 1021. 

Далее уже можно переходить к сайту и изучать его логи на предмет причины неполадок.

В файле error.log есть отсылка на подробности в файле db.log, в котором и нашлась причина возникновения ошибок 1021 — на хостинге закончилось место.

Пример 2

Детали ошибки:

Ошибка, связанная с долгим ответом сервера — 422 Shop response is too slow. SLA breached. Обычно это не постоянная ошибка, а периодически возникающая несколько раз в день. 

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

2. В админ-панель сайта не приходят заказы

Внимание! Синхронизируются только новые заказы, созданные после установки плагина

2.1. А были ли вообще отправлены заказы?

В этом случае нужно зайти в лог запросов (Настройки — Лог запросов), 

Проверить что запросы на передачу заказов вообще отправляются, меняем время на максимальное (23ч), ищем метод /accept

Иногда случаются ошибки в работе Маркета и он не отправляет запросы по API какое-то время. Если запросов нет, значит Маркет ничего не отправлял.

Дополнение: в момент индексации прайс-листа Яндекс.Маркет не создаёт тестовые заказы!

2.2. Возможные ошибки

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

Возможные варианты:

• 403 Forbitten
• Not in GZIP format
• Ошибка 404: проверьте, правильно ли скопирована ссылка из плагина
• Item price is not positive: 0. Данная ошибка говорит о том, что ваш сайт отвечает, что цена товара нулевая. Если на самом деле цена товара не ноль, значит, скорее всего, неверно происходит сопоставление (не находит такой товар по offerID)

Если у вас хостинг Firstvds

Запросы отправляются, ошибки нет, но на сайте нет заказов:

Если у вас установлено приложение «Firewall», оно может блокировать запросы от Я.Маркета

2.3. «Вы отказались принимать заказ»

Плагин может отказаться принимать заказ, если товар не найден, либо он в недостаточном количестве. В этом случае в логе ответа будет: { «order»: { «accepted»: false, «reason»: «OUT_OF_DATE» } }

Как продиагностировать: проверить в логах Яндекс.Маркет, какой товар с каким offerID запрашивает маркет. Смотрим запрос /accept. Вероятные причины ошибки:

• Товара нет в наличии в нужном количестве на выбранном складе.
• Неверно сопоставляются OfferID Подробнее про сопоставление

3. Не передаются статусы в маркет

Данная проблема может возникнуть в следующих случаях:

• В настройках плагина действия магазина сопоставлены неверно. Выполняются действия, не выбранные в настройках плагина, и, соответственно, ничего не отправляется. Как проверить: в логи плагина ничего не записывается, в Маркете нет никаких запросов от сайта в логах. Подробнее про сопоставление статусов. 
• Исходящий авторизационный токен неверен/отозван. Как проверить: в логах плагина будет запись об ошибке (Access Denied / Token Invalid). Токен может быть заблокирован при смене пароля у аккаунта Яндекса или по другим причинам, нужно его обновить. Как это делается написано здесь. 
• Нарушена цепочка последовательности статусов. Вы пытаетесь сменить статус на тот, который недоступен для текущего заказа. Например, для модели FBS предусмотрена четкая последовательность: Принят — Готов к отгрузке — Отгружен. Если попытаться из «Принят» сразу перейти в «Отгружен», из этого ничего не выйдет. Как проверить: в логах плагина, в файле api.error.log будет запись: {«status»:»ERROR»,»errors»:[{«code»:»STATUS_NOT_ALLOWED», «message»: «No permission to set substatus SHIPPED for order XXXXX with status PROCESSING and substatus STARTED»}]}

4. Проблемы с передачей остатков

Кратко: самая частая проблема — неверно выбрано сопоставление «Ваш SKU» (offerID), поэтому остатки отдаются неверно. Подробно про настройку здесь.

Подробный процесс диагностики:

Передача остатков в Яндекс.Маркет в данный момент осуществляется с помощью двух механизмов:

• Яндекс.Маркет сам запрашивает остатки по своему списку товаров, присылая запросы /stocks в любой момент.
• Вы сами отправляете информацию в Маркет об остатках через метод /stocks, через кнопку в интерфейсе, или через автоматический планировщик CRON. Подробнее об этом здесь.

4.1. Диагностика для входящих обновлений остатков

Допустим, вы обнаружили, что наличие остатков в Яндекс.Маркет не соответствует сайту. Как проверить, почему они не обновились:
1. Выберите один или несколько товаров в личном кабинете Яндекс.Маркет, запишите значения из поля «Ваш SKU»:

В данном случае это fbs213, fbs212, fbs214

2. Далее в личном кабинете нужно перейти в раздел «Лог запросов»:

Нас интересуют запросы /stocks На вкладке «К вашему серверу» — те запросы, что посылает сам Маркет, а на вкладке «К серверу Маркета» — те запросы, что ваш сайт посылал самостоятельно. Обратите внимание, чтобы дата и время были выбраны правильно. Подробности запроса доступны по нажатию на «шестерёнку»:

Какие здесь могут быть ошибки:

1) Отсутствуют исходящие запросы /stocks от Маркета — неправильно выставлено время, либо не включено обновление остатков через API.

Проверьте обновление, нажав в личном кабинете в разделе «Настройки API» следующую кнопку: 

2) Запросы /stocks присутствуют, но указано, что есть какие-то ошибки:

• Доступ запрещен — 403 Forbitten
• Ошибка «expected and actual fingerprints aren’t the same»
• Read timed out — маркет не дождался ответа сайта. Если ошибка возникает только «иногда», то причина здесь не в плагине, а в ресурсах сайта. Возможно, в данный момент нагрузка на сайт повышена и он не может быстро отвечать на различные запросы.

3) Запросы /stocks присутствуют, ошибок нет, в теле пусто

Если в реальных запросах наличия ошибок нет, но в ответе «Тело отсутствует», то это нормально. Ответ поддержки Маркета:

Это вполне нормальная ситуация ,когда тело ответа скрывается, открыто оно только в тестовых запросах , сделано это для экономии вычислительных ресурсов, главное ,чтобы статус запроса был 200

Как же узнать, какая информация передаётся об остатках? Переходим в админку нашего сайта и включаем «Дебаг режим»: 

При этом режиме все запросы будут записываться в логи сайта. Перейдите в приложение «Логи». 

В файле plugins/pokupki/apiRequest.debug.log можно увидеть, по каким товарам было запрошены остатки, пример:

Попробуйте найти те SKU, которые записали ранее, присутствуют ли они в запросе Маркета. Для удобства файл лога вы можете скачать и посмотреть в текстовом редакторе на вашем компьютере (рекомендуем Sublime Text). 

Если SKU в запросе отсутствуют, значит Маркет не запрашивает по нему наличие. Это может происходить по различным, не зависящим от нас причинам — может быть товар в архиве? 

Если SKU присутствует, нужно изучить другой файл — ответ сайта. Найдите файл /plugins/pokupki/api.Response.debug.log — в него записывается ответ нашего сайта, та информация, которая отправляется в Яндекс.Маркет.

Теперь попробуйте найти ранее записанные SKU в этом файле. 

Если SKU присутствует, то проверьте, какое по нему отправляется наличие, и какое указано в самом товаре. В случае несовпадения проверьте:

1. Сопоставление OfferID — ID товара/ID артикула/Код артикула. Подробнее про сопоставление.
2. Выбранные склады в этой настройке.
3. Условия по изменению наличия в этой настройке.

Если SKU отсутствует, значит такой товар не найден на вашем сайте. Проверьте следующее:

1. Какие товары выбраны для определения наличия, присутствует ли в нём этот товар. Подробнее про настройку. 
2. Неверно указан принцип сопоставления товаров. Проверьте, как выставлено сопоставление — ID товара/ID артикула/Код артикула. Подробнее про сопоставление.
3. Не учтён формат SKU — например, в Маркете у вас fbs1234 (добавлена приставка к ID). Он заводится здесь.

4.2. Диагностика для исходящих обновлений остатков

В случае использования самостоятельной отправки остатков, вся информация будет записана в файл /plugins/pokupki/api.Request.offers-stock.debug.log В нем вы так же можете найти какой товар с каким наличием отправляется в Маркет, а полученные данные видны в личном кабинете на вкладке «К серверу Маркета», запросы /stocks.

Если при нажатии кнопки отправки остатков, вы видите, что обновляется лог /shop/plugins/pokupki/api.error.log , а внутри следующее сообщение:

{"error":{"code":403,"message":"Access denied"},"errors":[{"code":"FORBIDDEN","message":"Access denied"}],"status":"ERROR"}

значит варианта два:

1. Исходящий токен доступа утратил актуальность, как обновить.
2. Неверно введён номер кампании. 

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

5. Не скачивается акт приёма-передачи

• Акт доступен только в день отгрузки
• Проверьте, что все заказы переведены в статус «Готов к отгрузке».
• Ошибка «Token Invalid» — проверьте исходящий авторизационный токен. Токен может быть заблокирован при смене пароля у аккаунта Яндекса, нужно его обновить. Как это делается написано здесь.

Проверьте, скачивается ли акт в личном кабинете Яндекс.Маркет. 

6. Магазин отключили из-за ошибок в работе API

Если ошибка только при запросе order/status:

Ошибка 500 при запросе order/status

Если ошибка при любом запросе, но иногда:

Яндекс.Маркет может запрашивать актуальное наличие товаров через запрос /stocks хоть каждую минуту. Поэтому, если на сайте возникли какие-либо неполадки, в результате чего он стал временно недоступен, либо стал дольше отвечать на запросы, это может привести к ошибкам в ответе по API, т.к. Яндекс ждёт ответа всего-лишь несколько десятков секунд. Проблем в плагине в этом случае нет.

В любом случае, нужно смотреть описание конкретных ошибок в логах

7. Заказ по модели FBS, но отображаются кнопки от DBS («изменить дату доставки»)

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

В диагностике вам может помочь:

8.1. Лог запросов в личном кабинете Яндекс.Маркет

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

8.2. Включение логирования в плагине

В этом случае в приложении «Логи» будут записи о запросах и ответах, которые принимает или отправляет плагин.

8.3. Отправка тестовых запросов через сервис «Postman»

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

8.4. Отправка тестовых заказов через интерфейс в Яндекс.Маркет

В личном кабинете продавца «Яндекс.Маркет» зайдите в раздел левого меню Настройки — тестовые заказы

Здесь можно отправить тестовый заказ и проверить работу плагина.

9. Другие ошибки и вопросы

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

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

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

Код сервера (его еще называют кодом состояния HTTP) — последовательность из трех чисел с небольшим текстовым пояснением, который запрашивают и проверяют браузеры и поисковые роботы. Вот пример как это выглядит:

Страница с кодом ответа сервера Discord при переходе на несуществующую страницу

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

Читайте также: 11 способов проверки битых ссылок на сайте

Какие бывают коды ответов

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

Класс 1. Выглядит так: 1ХХ. Это временные информационные коды. Они сообщают о том, что запрос принят и находится в обработке.

Класс 2. Выглядит так: 2ХХ. Сообщает об успешной обработке запроса.

Класс 3. Выглядит так: 3ХХ. Сообщает о перенаправлении с одного адреса на другой. Эти коды говорят об изменении URL. Используются при создании зеркал или переносе сайта на новый движок.

Класс 4. Выглядит так: 4ХХ. Говорит об ошибке со стороны посетителя. Обычно после числа идет небольшой текст с объяснением — в чем проблема. Такие коды говорят о запрете просмотра страницы или об ее отсутствии.

Класс 5. Выглядит так: 5ХХ. Сообщает об ошибке со стороны сервера. После этого класса тоже следует текстовое сообщение с объяснением причины поломки. 

Теперь разберем более распространенные виды ответов в каждом классе.

Класс 1

100 Continue. Промежуточный ответ сервера. Говорит о том, что сервер принял запрос и начинает обработку.

101 Switching Protocols. Код ответа указывает протокол, который переключает сервер, используя запрос Upgrade. В ответ сервер отправляет заголовок ответа Upgrade с указанием протокола, на который переключился.

102 Processing. Это значит, что сервер получил запрос и обрабатывает его. Клиент не должен разрывать соединение, чтобы дождаться ответа от сервера. Этот код используется в протоколе WebDAV (измененный HTTP для работы с файлами).

Класс 2

200 Ok. Говорит об успешной обработке запроса. Например, запрошенные страница или данные найдены и готовы к просмотру. Всем страницам, которые участвуют в индексировании, присваивается код 200.

202 Accepted. Запрос принят и будет обрабатываться долго. Пользователь может не дожидаться окончания запроса. Используется, когда запрос обрабатывается другим сервером. Такой код используется сервером, чтобы выполнять несколько запросов одновременно: пока пользователь с кодом 202 ждет окончания операции, 200 уже «видит» страницу.

203 Non-Authoritative Information. Код означает, что обработка запроса прошла успешно. Но информация поступила не от сервера, а от другого источника: облака, резервной копии.

204 No Content. Такой код используется на портал для запуска скриптов. Например, когда пользователь кликает по свободному месту на сайте.

205 Reset Content. Говорит о том, что браузеру нужно очистить форму, в которую вписаны данные. Такой код используется, чтобы очистить поля, заполненные при регистрации. При это обновлять ресурс не нужно.

Класс 3

300 Multiple Choices. Говорит о том, что указанный URL обозначает больше, чем один ресурс. Например, страницу, переведенную на несколько языков. 

301 Moved Permanently. Ответ означает, что запрошенный URL изменен или больше не существует, а пользователю предлагается перейти по новой ссылке. 

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

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

303 See Other. Указывает, что происходит перенаправление на другую страницу. Чтобы новая страница индексировалась, она должна отвечать на код 200. Такой код используется для страниц с подтверждением. Например, когда сайт высылает код подтверждения регистрации. 

304 Not Modified. Это значит, что предыдущая версия страницы не изменена. Благодаря этому робот индексирует ее без загрузки. Из-за этого сервер меньше нагружается и повышается время безотказной работы. А пользователь работает с версией страницы, которая сохранена в памяти браузера. 

У пользователей часто возникает ошибка HTTP 304. Такое бывает, если компьютер заражен вирусами или Windows медленно работает. Чтобы решить проблему, нужно проверить ПК на вирусы и очистить от лишних файлов. Еще можно восстановить записи в реестре системы. Но такую процедуру лучше доверить мастерам сервисного центра: если делать самостоятельно, можно превратить ПК в «кирпич».

305 Use Proxy. Сайт будет доступен только при использовании прокси-сервера. При этом нужно использовать сервер, который указан в разделе Location. Такой код предназначен для защиты сайта. 

308 Permanent Redirect. Полностью повторяет запрос 301. Разница в методе выполняемого запроса.

Класс 4

400 Bad Request. Сервер не может понять запрос, потому что он введен с ошибкой. Под ошибкой обычно понимается синтаксическая: некорректно введен URL. Также код 400 появляется, когда пользователь пытается загрузить на сайт слишком большой файл. Решить проблему помогает смена запроса или очистка cookies. Чтобы очистить куки в браузере, нужно перейти в настройки, в раздел конфиденциальности и безопасности.

401 Unauthorized. У клиента не получается зайти на страницу сайта, потому что у него не хватает прав доступа. Такая ошибка возникает на сайтах, где есть форма для авторизации. Решить ошибку можно двумя способами: войти в систему с использованием логина и пароля или очистить кэш браузера.

403 Forbidden. Этот код говорит о запрете на просмотр страницы. Такое бывает, если для IP-адреса внесен запрет на уровне сервера. Решить проблему можно с помощью VPN или прокси.

Что такое прокси? Как выбрать качественный прокси-сервер? Прокси для SEO, парсинга, арбитража и пр.

404 Not Found. Код означает, что запрашиваемая страница (сайт или документ) не существует или расположена по другому адресу. 

Ошибка 404 влияет на SEO-оптимизацию: если страница не существует / не доступна, поисковые роботы не будут ее индексировать и показывать в поиске. А еще переходы по битым ссылкам ухудшают поведенческие факторы. Но нивелировать негатив поможет грамотное оформление 404-страницы. Можно сделать ее с юмором, перенаправить трафик на другие ресурсы.

405 Method Not Allowed. Соответствующий код появляется, если на этапе обработки запроса сервер получает запрет. Такое случается, если нарушается работа php-скриптов. Ошибку можно решить с помощью перезагрузки страницы. Также помогает проверить все скрипты и удалить дополнения в CMS. 

408 Request Timeout. Это значит, что сервер прервал соединение. Такое бывает, когда сервер не получает запросов от посетителей долгое время. Если пользователь сам прекращает соединение, ошибки не возникает.

409 Conflict.Означает конфликт между пользовательским запросом и сервером. Например, клиент хочет скачать с сайта файл «фото01». Но раньше файл назывался «фото1» и это название сохранилось в кеше. Из-за этого сервер не понимает, что хочет скачать пользователь — возникает конфликт.

410 Gone. Это значит, что документ удален с сервера навсегда. Если поисковый робот получит этот код, он больше не будет просматривать страницу.

413 Request Entity Too Large. Ошибка возникает, если пользователь пытается загрузить слишком большой файл на сайт. Стандартно допустимый размер загружаемого файла — 1 Мб. Если клиент пытается загрузить больше — возникает ошибка. Чтобы решить проблему, нужно увеличить размер максимально загружаемого файла. Для этого нужно вносить изменения в настройки Nginx, php и apache. (Есть видео, как это делать в CMS WordPress.)

414 Request-URL Too Long. Если пользователь пытается сделать запрос с длинным URL, возникает такая ошибка.

423 Locked. Такая ошибка возникает, если IP-адрес блокируется хостером. Блокировку можно получить за сильную активность, интернет-мошенничество или вирусы. 

451 Unavailable For Legal Reasons. Новая ошибка, которая набирает популярность. Она появляется на сайтах, которые заблокированы государством. Ошибка 451 — дополнение к 403.

Класс 5

500 Internal Server Error. Ошибка из-за сбоев на сервере. Возникает при неправильной конфигурации файла .htaccess. Чтобы решить проблему, нужно изменить директиву Options: поставить в начале строки #.

502 Bad Gateway. Возникает, если есть промежуточный сервер. Случается, когда промежуточный сервер получает запрос и запрашивает данные у «главного» сервера, и получает неправильный ответ. В решении ошибки помогает очистка кеша браузера, обновление страницы и очистка DNS-кеша.

503 Service Unavailable. У сервера не получается обрабатывать запросы по техническим причинам. Например, если на сервере ведутся какие-то работы.

504 Gateway Timeout. Шлюз не дает ответа. Появляется, если ответ от главного сервера не получен.

507 Insufficient Storage. Ошибка высвечивается, если у сервера нет места работы с операцией. Проблему можно решить перезагрузкой. Или просто подождать.

511 Network Authentication Required. Значит, что нужно пройти авторизацию для доступа к интернету. Такой ответ высылает посредник, например, провайдер. Чтобы решить проблему, нужно написать в поддержку провайдера.

О популярных и важных ошибках поговорили. Теперь разберемся, как проверить код сервера. Это можно сделать самостоятельно или с помощью сторонних программ.

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

Начнем с ручного способа. Для этого перейдите на сайт через браузер Chrome и откройте консоль клавишей «F12». (Или «Fn + F12» на ноутбуках. Также инструменты разработчика можно включить сочетанием клавиш «Ctrl + Shift + I».) Теперь перейдите во вкладку «Network» и нажмите «Ctrl + R».

Ручная проверка кодов ответа страниц в консоли

Чтобы узнать код страницы, нужно смотреть столбец «Status».

Коды ответа сервера в столбце Status

Теперь о проверках с помощью сторонних сайтов и плагинов.

Bertal

Bertal — сервис для просмотра http-заголовков, веб-файлов (.html, .php, .asp, .gif, .jpg, .css и др.). Также позволяет просматривать html-код страниц. Работает с протоколами HTTP, HTTPS, FTP.

Возможности:

• Запрос информации методами HEAD, GET, POST. Метод HEAD — если запрашивается заголовок. GET — если запрашивается заголовок и тело. POST — как и GET, но с заполненной строкой POST.
• Поддерживаемые поисковые роботы: YandexBot, GoogleBot, BingBot, Yahoo, Baiduspider.
• Поддерживаемые браузеры: Mozilla Firefox, Google Chrome, Internet Explorer, Opera, Opera mini.
• Работает с Proxy.
• Можно указывать содержимое Cookies.

Отчет по странице от Bertal

Стоимость. Бесплатно.

PR-CY

PR-CY — cервис для SEO-аудита сайта, мониторинга и проверки позиций в поисковой выдачи. Подходит для анализа кодов ответа сервера, метатегов, содержимого страниц. Есть функции мониторинга сайта, проверки индексирования.

Возможности:

• Проверка кодов ответа страниц. Сервис проверяет все элементы: текст, скрипты, видео, фотографии. После PR-CY дает рекомендации: сжать текст, сократить HTML, CSS или JS.
• Работает с видами запросов: GET, POST, HEAD.
• Глубокий анализ: проверка редиректов, поиск всех кодов.
• Работает с поисковыми системами Google и Yandex.
• Проверка контента: пустые заголовки, лишние скрипты, нерабочие внешние ссылки.

Еще у PR-CY есть много чего: проверка скорости загрузки, вирусов, срока действия SSL-сертификата и др.

Результаты анализа сайта в PR-CY

Стоимость. Есть бесплатный тариф для экспресс-анализа сайта. Для полного аудита нужно покупать подписку. Она стартует от 990 ₽ в месяц. Позволяет вести до 5 проектов и проверять 1 000 страниц. Дорогие тарифы отличаются тем, что можно вести больше проектов и проверять больше страниц.

Читайте также: Как оптимизировать изображения для сайта

Checkmy

Checkmy — помогает проверить коды и заголовки ответа сервера. А еще доступность URL адресов, кеширование страниц, сжатие контента, исходный код, тип сервера и корректность переадресаций.

Возможности:

• Работает с доменам на кириллице.
• Работает через мобильную версию.
• Проверяет страницы с несколькими редиректами.
• Показывает размер и скорость загрузки страницы.
• Проверяет контент на сжатие.

Проверка кодов ответа сервера через Chekmy

Стоимость. Бесплатно.

Sitechecker

Sitechecker подходит для мониторинга сайта и полного аудита.  

Возможности:

• Проверка состояния страницы и кодов ответа.
• Подсчет «веса» HTML-кода страницы. Если он больше 2 Мб, сервис подскажет, как его уменьшить.
• Отдельная проверка страницы с кодом 404.
• Проверка индексации поисковыми системами.
• SEO-анализ страницы: проверка title, description, заголовков h1-h6. Проверка изображений и атрибутов Alt, внутренних и внешних ссылок.
• SEO-аудит сайта: оценка битых ссылок и редиректов, метатегов, скорости загрузки.
• Мониторинг ресурса: контроль статуса индексирования, защита от взломов и отслеживание сайтов конкурентов.

Аудит сайта не сервисе Sitecheker

Стоимость. Можно сделать проверку кодов бесплатно. Но функции мониторинга, проверки обратных ссылок и индексации будут недоступны. Платная подписка стартует от 29 $ в месяц. Для подписки доступно 3 тарифа. Они отличаются количеством сайтов, которые можно проверять.

А еще за парсингом метатегов и заголовков, анализом индексации страниц, съемом позиций в поисковиках, сбором семантического ядра можно обратиться в Promopult. Это мощная платформа для комплексного продвижения в интернете: поисковой оптимизации, контекстной и таргетированной рекламы, управления репутацией.

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

Яндекс.Вебмастер поможет узнать, доступны ли страницы для поисковых роботов Яндекса. (Но ответ, полученный через Яндекс.Вебмастер, может отличаться от того, который получит поисковый робот. Дело в том, что инструмент работает через другой IP-адрес. Об этом сказано в Яндекс.Справке.)

Возможности:

• Проверка всех классов ответа сервера.
• Дополнительно можно узнать срок действия SSL-сертификата.
• Проверяет страницы размером до 10 Мб.
• Работает с файлами этих типов: PDF, DOC/DOCX, XLS/XLSX, PPT/PPTX, ODS, ODP, ODT, ODG, RTF, TXT и SWF.

Проверка ответа сервера через Яндекс.Вебмастер

Стоимость. Бесплатно.

Converseo

Converseo подходит для как для проверки одиночного URL, так и для массового отслеживания.

Возможности:

• Работа с методами GET, POST, HEAD.
• Есть дополнительные функции: сравнение списков, загрузка фото из Instagram.
• Готовый отчет можно скачать в формате CSV.

Вот так выглядит отчет по массовой проверке URL на сайте Converseo.

Вот так выглядит отчет по одиночной проверке URL на сайте Converseo.

Стоимость. Бесплатно.

Coolakov

Coolakov — работает также, как и Converseo. Есть и дополнительные функции.

Возможности:

• Массовая проверка URL. Особенность в том, что выдается конечный ответ сервера. Например, если был редирект на рабочую страницу — ответ будет 200. Если на сломанную — в зависимости от ошибки.
• Поддерживаемые браузеры: Mozilla Firefox, Google Chrome, Safari.
• Проверка доступности сайта.
• Измерение скорости загрузки портала.
• Проверка индекса качества сайта.
• Проверка орфографии.

Проверка ответов сервера через Coolakov

Стоимость. Бесплатно.

Headmasterseo

Headmasterseo. Программа для Windows и Mac, которая проверяет массовые URL. Отслеживает коды состояния, редиректы, время ответа и заголовки ответов.

Возможности:

• Проверка URL с помощью метода HEAD.
• Одновременная проверка 500 ссылок.
• Проверка циклов перенаправления. Есть тестер, который оценит, правильно ли настроен редирект.
• Работает с прокси.
• Готовый отчет можно экспортировать в формате CSV.
• Проверка полей заголовков.
• Проверка Sitemap файлов в формате XML.

Пример отчета в Headmasterseo

Стоимость. До 500 URL можно проверять бесплатно. Чтобы проверить больше, нужно платить. За 10 000 URL придется заплатить 50 $. За 100 000 — 100 $. Неограниченное количество ссылок можно проверять за 150 $.

Читайте также: Исчерпывающий гид по поисковым операторам Google и Яндекса

Плагины

Redirect Path Link. Это бесплатный плагин для Google Chrome. Он поможет провести SEO-аудит сайта и проверить HTTP-заголовки. Работает только с 3 классом кодов сервера. 

Robots Exclusion Checker. Помогает оптимизировать сайт, найти проблемы в индексации и сделать SEO-аудит. Плагин бесплатный. Работает со всеми классами кодов и поисковыми роботами Googlebot, Bing, Yahoo.

SEO META in 1 CLICK. Бесплатный плагин для Google Chrome. Помогает проверить коды ответа сервера, проанализировать заголовки H1-H6, проверить изображения и Alt атрибуты к ним и др. 

Website SEO Checker: Free Audit & Analysis. Бесплатный плагин от Sitecheker. В нем есть такие же функции, как и на сайте: аудит, мониторинг, анализ, просмотр кодов ответа и т.д.

Коротко о главном

Код ответа сервера — это трехзначное число с небольшим текстовым сопровождением. Коды делят на 5 классов:

1. 1ХХ — информационные.
2. 2ХХ — успешные.
3. 3ХХ — переадресация
4. 4ХХ — проблемы со стороны пользователя.
5. 5ХХ — проблемы со стороны сервера.

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

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

А чтобы глубже разобраться в SEO, приходите учиться в CyberMarketing. У нас есть статьи, вебинары, базовые и продвинутые курсы по поисковому продвижению. Преподают эксперты Promopult: Руслан Байбеков и Евгений Костин.

Ошибки 5XX означают, что есть проблемы со стороны сервера. Например, 500 ошибка значит, что сервер столкнулся с внутренней ошибкой, из-за которой не смог обработать запрос. К ней могут привести неверные директивы в .htaccess или ошибки в скриптах сайта. А ошибка 503 означает, что сервер не может обработать ваш запрос в данный момент. После номера ошибки часто идёт краткое описание. 503 ошибка сервера часто сопровождается фразой «Service Temporarily Unavailable» (сервис временно недоступен). Если на вашем сайте часто встречается 503 ошибка, значит самое время выяснить её причину.

В этой статье мы рассмотрим возможные причины возникновения 503 ошибки на сайте и способы её устранения.

Ошибка 503 Service Unavailable

Что такое ошибка 503 (Service Temporarily Unavailable)

Эта ошибка означает, что сервер не готов обработать запрос в данный момент. Подразумевается, что это временно и нужно повторить попытку позже. Но это не всегда так. HTTP 503 Service Unavailable — это код состояния, который содержится в ответе веб-сервера и показывает, успешно ли выполнен запрос. Коды 5XX принадлежат классу серверных ошибок. В спецификации RFC 7231 указано, что код 503 сообщает о том, что сервер в настоящее время не может обработать запрос из-за временной перегрузки или планового технического обслуживания

Спецификация RFC 7231

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

Как исправить ошибку 503 со стороны пользователя

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

Ошибка недоступности, если вы владелец сайта

Частые ошибки 503 на вашем сайте могут негативно сказаться на позициях в поисковых системах и привести к снижению трафика. Посетители могут просто не вернуться на ваш сайт. Не игнорируйте проблему и сразу приступайте к её решению. Вот несколько вариантов решения:

• На любом хостинге есть ограничения и лимиты, которые не стоит превышать. Их устанавливает хостинг-провайдер. Превышение лимитов может привести к возникновению проблем на сайте, в том числе и к ошибке 503. Изучить характеристики вашего тарифного плана вы можете на сайте хостинг-провайдера. Для хостинга REG.RU действуют следующие технические ограничения.
• Хостинг может не справляться с большим количеством посетителей на сайте. В этом случае может помочь смена тарифного плана или переезд к новому хостинг-провайдеру.
• Бывает, что неактуальные версии плагинов и других компонентов движка нарушают работу сайта. Попробуйте по очереди отключать установленные плагины вашей CMS и проверять работоспособность сайта после каждого. Если ошибка не возникает после отключения очередного плагина, обновите этот плагин до последней версии. Возможно, что в новой версии разработчик уже внёс исправления. Если обновление не помогло, плагину нужно искать альтернативу.
• Регулярно обновляйте CMS и её компоненты. Зачастую обновления направлены на оптимизацию работы движка, устранение уязвимостей, борьбу с багами, повышение безопасности и быстродействия. Удалите все ненужные компоненты, которыми не пользуетесь. Оставьте только самые необходимые, чтобы уменьшить нагрузку на сервер.
• Проанализируйте скрипты сайта. К HTTP Error 503 может привести неправильная работа скриптов на сайте. Выполните их диагностику и убедитесь, что на сайте не включен режим технических работ.
• Не загружайте крупные файлы при помощи PHP. Очень часто хостинг-провайдер ограничивает время выполнения скрипта, и вы можете не уложиться в этот лимит. Ещё одним минусом передачи файлов через PHP является создание отдельного PHP-процесса, который будет занят загрузкой файла, а не обработкой запросов посетителей. Загружайте файлы по FTP, чтобы уменьшить нагрузку на хостинг.
• Запускайте массовые почтовые рассылки в периоды минимальной активности на вашем сайте. Точно так же стоит поступить и с техническими работами на сайте и сервере.
• Поисковые роботы могут генерировать большое количество обращений к сайту. Проанализируйте статистику по User-Agent и выясните, какие роботы создают нагрузку. При помощи файла robots.txt задайте временной интервал обращений.
• Настройте кэширование средствами CMS или хостинга. В WordPress вы можете настроить кэширование с помощью нашей инструкции: Что такое кэширование и как управлять им в WordPress. В панели управления хостингом тоже часто имеются встроенные инструменты по настройке кэширования.
• Запросы к сторонним ресурсам могут замедлять генерацию и отдачу контента, что в итоге может привести к 503 ошибке. Если удалённый сервер недоступен, ваш сайт потратит больше времени на ожидание ответа. Уменьшите тайм-аут ожидания ответа от стороннего ресурса или вовсе откажитесь от таких запросов. Работоспособность сторонних сервисов невозможно контролировать.

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

Ошибка 503 на хостинге REG.RU

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

Обычные посетители сайта обращают внимание в первую очередь на качественный контент, а поисковые краулеры – на ответы сервера.

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

Немного теории

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

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

Сперва определимся с терминами.

• Клиент – компьютер, смартфон или другое мобильное устройство, которое имеет подключение к интернету.
• Сервер – определенный компьютер, который хранит все данные сайта (включая страницы и системные файлы). Именно на сервере «живет» сайт.

Выделяют пять классов ответов. Идентифицировать класс можно по первой цифре.

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

Логика кодов, таким образом, весьма проста:

Что значат коды состояния HTTP

Причины / решения / пояснения ошибок, я буду давать только для самых часто встречающихся кодов. Для всех остальных – только краткое описание.

Двухсотые – успешные запросы

200 – успешный запрос данных. Код не является ошибкой.

201 – завершена успешная транзакция. Код говорит о том, что сформирован новый ресурс (или документ).

202 – запрос принят, но еще не завершен. Необходимо дождаться окончания обработки.

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

204 – запрос был обработан правильно, но отсутствует содержимое. Есть заголовок ответа, но содержимое для него отсутствует. Обновлять и актуализировать содержимое не нужно.

205 – клиенту необходимо осуществить сброс содержимого. Саму страницу обновлять не требуется.

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

GET-запрос предназначен для получения данных, в то время как POST-запрос нужен для отправки данных.

Код также может быть отправлен с сервера, когда клиент запросил диапазон (например, условно: «Дайте мне первые 2 МБ видеоданных»). Происходит возврат только частичного контента, соответствующего Range-заголовку (данный заголовок дает понять серверу, какую именно часть страницы от него требуют, и какую ему нужно вернуть).

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

207 – выполнено несколько операций. Найти их можно в XML, в строке MultiStatus.

226 – обработан IM-заголовок. Содержимое будет возвращено для получения информации об ответе вместе с ранее обозначенными параметрами.

Трехсотые – запросы на редирект

300 – не удалось идентифицировать точный URL. Такой ответ возникает, когда существует множественный выбор, и краулер не знает, к какой именно странице относится ресурс.

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

302 – документ был временно перемещен на новый URL. Это абсолютно корректный ответ сервера, который актуален для веб-страниц с распродажами или сезонными акциями, распространяющимися на какой-либо товар. Код указывает, что данный URI будет учитываться клиентом в последующих запросах. Другими словами, страница была найдена, но перенесена. Такие документы из индекса не удаляются. Если адрес был изменен навсегда, вместо 302-го, лучше использовать 303-ий или 307-ой ответ.

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

304 – документ не модифицировался. Этот код не является стандартным редиректом. Он помогает краулерам определять страницы, которые не изменились с последнего визита.

Если на вашем сайте немного страниц (до 1 000), использовать код 304 нет смысла. Если вас напрягает этот редирект, то в заголовке нужно поправить параметр Last-Modified (последняя дата изменения) – он не должен быть старше, чем заголовок If-Modified-Since (если изменялся спустя заданное количество времени).

305 – доступ к этому документу возможен исключительно через прокси.

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

Четырехсотые – сбои на стороне клиента

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

401 – отсутствует аутентификация. Код отдается, когда для доступа требуется пароль или регистрация.

403 – отсутствует доступ к документу. Возникает, когда пользователь хочет открыть системные файлы (robots, htaccess). Либо вы сделали опечатку при вводе URL и пытаетесь воспользоваться веб-страницей, которая не предназначена для обычного пользователя, либо вам нужно: пройти авторизацию для доступа к системным файлам.

404 – отсутствует соответствующий ресурс по введенному URL. Разберитесь, по каким причинам была удалена / перемещена страница. Возможно, вы допустили ошибку и удалили ее случайно. Если так – просто восстановите ее.

Задумайтесь над созданием красивой, кастомизированной 404-ой. Например, такой:

405 – некорректный метод (указывается в запросной строке клиента) для выбранного документа. Метод запроса определяет точное действие, которое должно быть выполнено для указанного ресурса.

406 – некорректный / неподдерживаемый краулером формат запроса. Код отдается, когда сервер не способен возвратить ответ, релевантный листу допустимых значений. Самый распространенный случай – поисковый робот не поддерживает кодировку документа или его язык. Убедитесь, что в теле сообщения содержится лист доступных ресурсов. Подробное описание ошибка на сайте веб-разработчиков Mozilla.

407 – отсутствует регистрация прокси или авторизация файервола.

408 – таймаут запроса. Соединение разорвано, так как полный запрос не был передан. Другими словами, запрос занял слишком много времени, а сервер не готов был ждать. На каждом сайте существует свое время таймаута. Проверьте наличие интернета и просто обновите страницу. Подробное объяснение этой ошибки на сайте веб-разработчиков Mozilla.

409 – несовместимость двух запросов. Запрос невозможно выполнить при текущем состоянии сервера. Самый распространенный случай – операции c PUT-запросом. Например, когда нужно скачать файл, возраст которого превышает возраст уже существующего, расположенного на сервере.

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

411 – сервер сам отклоняет отправляемый запрос, так как не находит значение Content-Length. Этот ответ характерен как для обычных POST-запросов, так и для PUT-запросов (подразумевают замену существующих представлений документа на данные, которые содержатся в самом запросе).

412 –не были до конца выполнены условные поля HTTP-заголовка, например, If-Match. 412-ый код появляется в случаях, когда доступ к целевому документу отклоняется. Нужно проверить соблюдение и корректность HTTP-заголовков выполняемого запроса.

413 – у каждого сервера есть свой собственный максимальный размер запроса, определяемый не самим HTTP-протоколом (у него ограничения по длине запроса просто напросто отсутствуют), а ограничениями со стороны браузеров. Браузеры поддерживают запросы от 2 до 8 килобайт. Вышеуказанный код отдается, когда сервер не понимает запрос из-за слишком большого размера.

414 – возникает, когда отправляется чрезвычайно длинный URL. Запросы, содержащие излишне длинные URL, не могут правильно интерпретироваться сервером. Самые частые случаи появления этого ответа – попытка передать удлиненные параметры (излишне большое количество данных через GET- запрос).

415 – некорректный медиаформат. Текущий тип данных не может быть интерпретирован сервером.

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

417 – указанное значение Expect не может быть удовлетворено (речь о заголовке запроса). Прокси некорректно идентифицировал содержимое поля «Expect: 100-Continue». Устранить эту ошибку самостоятельно не удастся. Если вы используете прокси Squid, обратитесь в поддержку. Вам нужно активировать ignore_expect_100. Другой вариант ­ разрешите BS_PingHost обращаться к интернет-сети без участия прокси.

422 – существует определенная логическая ошибка. Какая именно, данный код не указывает. Копайте в сторону ошибок в семантике документа.

423 – используемый ресурс был заблокирован для выбранного HTTP—метода. Перезагрузите роутер и компьютер. Используйте только статистический IP.

424 – зависимый ресурс был блокирован по соображением безопасности. Данный код отдается, если в запросе присутствуют признаки несанкционированного доступа к файлам CMS.

426 – некорректные значения полей Upgrade и Conection. Этот ответ возникает, когда серверу требуется обновление до SSL-протокола, но клиент не имеет его поддержки.

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

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

Пятисотые – серверные сбои

500 – серверу не удается полностью обработать запрос. Такой код отдается, когда существует непредвиденное условие, мешающее выполнению запроса. Чаще всего внутренняя ошибка сервера может появляться при серверных сбоях. Проверяйте, корректно ли указаны директивы в системных файлах (особенно htaccess), нет ли ошибки прав доступа к файлам. Обратите внимание на ошибки внутри скриптов и их медленную работу.

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

501 – не выполнено. Этот код отдается, когда сам сервер не может идентифицировать метод запроса. Сами вы эту ошибку не исправите. Устранить ее может только сервер.

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

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

504 – отсутствует ответ. Этот код отдается в одной ситуации – если сервер не может получит ответ за необходимый период времени. Отклика нет и возникает таймаут. Как и 501-ый ответ, 504-ый исправить самостоятельно не получится. Здесь дело в прокси, часто – в веб-сервере. Первым делом просто обновите веб-страницу. Если не помогло, нужно почистить DNS-кэш. Для этого используем сочетание горячих клавиш Windows+R и вводим команду cmd (Control+пробел). В открывшемся окне указываем команду ipconfig / flushdns и подтверждаем ее нажатием Enter.

Также полезно посмотреть, как страница ведет себя различных мобильных устройствах и в разных браузерах. Проверьте дебаг. Если сайт на WP, то проверить дебан проще всего. Достаточно добавить этот код в wp-config.php:

Теперь все сбои будут фиксировать в файле debug.log (находится в папке wp-сontents). Если вы используете другую CMS, найдите к ней мануал и посмотрите, как активировать в ней журнал ошибок.

Также 504-ая отдает, когда на сайте существуют проблемы, связанные с задействованием CDN или кастомизированных серверов DNS. Отключите CDN на своем сайте.

Иногда 504-ый код пропадает, если просто подождать несколько часов. Часто 504-ая появляется на сайтах, которые используют CloudFlare.

505 – отсутствует поддержка текущей версии HTTP-протокола.

507 – не хватает места на жестком диске для выполнения запроса.

510 – не найдено расширение, желающее задействовать клиент.

Массово проверяем ответ веб-страницы

Самый простой способ проверить ответ веб-страницы – воспользоваться готовыми сервисами. Наиболее популярны:

• mainspy;
• 2ip;
• cy-pr;
• wwhois;
• 4seo.

Возьмем для примера mainspy. Тут проверить код ответа проще всего:

Таким образом, для проверки кода просто открываем страницу и вводим необходимые URL. Кликаем «Проверить». Будет выведен отчет. Напротив каждого проверяемого URL будет отображаться код ответа сервера:

Кроме перечисленных сервисов есть также замечательный плагин для Google Chrome – HTTP Header Spy. Он позволяет проверять код ответа сервера как одной, так и нескольких страниц сразу:

Послесловие

Коды ответа HTTP – это универсальный язык, который понимают не только краулеры Google / «Яндекса», но и люди. 5 классов кодов позволят с первого взгляда определить, где именно существует ошибка при выполнении HTTP запроса и куда копать для ее устранения.

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