|
|||
| FFrr1C
10.07.17 — 23:13 |
Подскажите пожалуйста, может кто сталкивался: |
||
| Имитация работы
1 — 10.07.17 — 23:32 |
Открой адрес в браузере. После получения xml внимательно посмотри на адресную строку. Сравни ее с исходной. |
||
| FFrr1C
2 — 10.07.17 — 23:54 |
браузер пишет: |
||
| FFrr1C
3 — 10.07.17 — 23:57 |
Хотя сейчасас в браузере написано следующее: |
||
| FFrr1C
4 — 11.07.17 — 00:11 |
Что-то совсем запутался, в коде Новый WSОпределения(«http://localhost/zerkal/ws/Price.1cws?wsdl»,»admin»,»123″;) что нужно указывать? если WSОпределения(«http://localhost/zerkal/ws/Price.1cws?wsdl»,»admin»,»123″;) тогда код ошибки 301 если WSОпределения(«http://localhost/zerkal/ws/WebPrice.1cws?wsdl»,»admin»,»123″;) тогда код ошибки 404 и в журнале регистрации запись «Сеанс. Ошибка аутентификации» |
||
| Имитация работы
5 — 11.07.17 — 00:38 |
Большую букву Z |
||
| FFrr1C
6 — 11.07.17 — 00:47 |
Я так понимаю все же проблема с аутентификацией, юзер от 1С не подходит.. |
||
| Имитация работы
7 — 11.07.17 — 00:48 |
Ок |
||
| FFrr1C
8 — 11.07.17 — 00:53 |
Не понял какой смысл в имени файла публикации если обращение идет через то имя которое в конфигураторе? это имя фала публикации где-то задействовано? |
||
|
FFrr1C 9 — 11.07.17 — 00:55 |
Есть ли простое решение чтобы пройти аутентификацию, для НеСисАдмина, что где поставить в пользователях.. |
Добрый день.
Пытаюсь разобраться с WEB-сервисами. Разобрал пример из ИНЕТА. Опубликовал локально на WEB-сервере. Но при обращении к нему из обработки, сервер выдает ошибку:
{ВнешняяОбработка.WEB_Service.Форма.Форма.Форма(11)}: Ошибка при вызове конструктора (WSОпределения)
Определение = Новый WSОпределения(«http://localhost/request/ws/request.1cws?wsdl»,»Admin»,»123″);
по причине:
При создании описания сервиса произошла ошибка. URL сервиса: http://localhost/request/ws/request.1cws?wsdl
Код ответа сервера: 301
Публиковал и на IIS и на Apache 2.4
Результата один «Код ответа сервера: 301» (получаемый в ответ от сервера в ситуации, когда запрошенный ресурс был на постоянной основе перемещён в новое место). Совершенно ни о чем мне не говорит.
Сервис прекрасно читается в браузере напрямую — «http://localhost/request/ws/request.1cws?wsdl»
Он даже загружается в «WS-ссылки» конфигуратора.
Но работать не хочет из Обработки, которая к нему обращается.
Пример брал здесь: https://infostart.ru/public/327963/
Подскажите, как с этим бороться.
Нашел неточность. Имя сервиса «Request» (С большой буквы)
Теперь строка в определении выглядит так — «http://localhost/Request/ws/request.1cws?wsdl»
Но теперь ошибка 400 (что-то там с синтаксисом)
Разобрался.
Надо было делать так «http://127.0.0.1/Request/ws/request.1cws?wsdl»
«localhost» не катит
Обновлено 14.10.2020
Добрый день! Уважаемые читатели и гости популярного компьютерного блога pyatilistnik.org. В прошлый раз мы с вами решили ошибку » db query error please try later», и восстановили работу сайта на платформе 1С Битрикс. Сегодня я хочу поделиться небольшой заметкой, как выйти из ситуации, когда не работает кнопка «Заполнить по ИНН» в Справочнике Контрагенты при создании нового. Выдается ошибка «ОбщийМодуль.ОбщегоНазначенияПовтИсп.Модуль(198): Ошибка при вызове конструктора (WSОпределения) WSОпределения = Новый(Тип(«WSОпределения»). Давайте разбираться в чем собственно дело.
Причины ошибок с модулем 198-504
Вся проблема связана с неправильным и устаревшим сертификатом, это бывает если вы давно не обновляли свою версию 1С, а в этот момент как раз истек срок сертификата, который участвует в подключении к внешним сервисам, например, npchk.nalog.ru или api.orgregister.1c.ru.
Вот так вот выглядит более полный текст ошибки:
Не работает кнопка «Заполнить по ИНН» в Справочнике Контрагенты при создании нового.
Выдает ошибку:
{ОбщийМодуль.ОбщегоНазначенияПовтИсп.Модуль(198)}: Ошибка при вызове конструктора (WSОпределения)
WSОпределения = Новый(Тип(«WSОпределения»), Параметры);
по причине:
При вызове веб-сервиса произошла ошибка. При создании описания сервиса произошла ошибка. URL сервиса: https://api.orgregister.1c.ru/orgregister/v7?wsdl
по причине:
Ошибка работы с Интернет: Удаленный узел не прошел проверку
Комментарий: {ОбщийМодуль. ОбщегоНазначения. Модуль (5303)}: Ошибка при вызове конструктора (WSОпределения)
Определения = Новый WSОпределения (ИмяФайлаWSDL, ИмяПользователя, Пароль, ИнтернетПрокси, Таймаут);
по причине:
Ошибка импорта схемы
по причине:
Ошибка при выполнении файловой операции ‘_ttp://npchk.nalog.ru:80/FNSNDSCAWS_2?xsd=1’
по причине:
Ошибка работы с Интернет: произошел таймаут при ожидании ответа шлюзу (504).
10060 — Ошибка соединения с сервером
HOST — npchk.nalog.ru[81.177.31.8]; PORT — 80
Connection timed outTraffic Inspector HTTP/FTP/Proxy server (3.0.2.912)
по причине:
Ошибка работы с Интернет: произошел таймаут при ожидании ответа шлюзу (504)
Как решить проблему
В случае клиент-серверной версии необходимо добавить сертификат Digicert как на сервере, так и на всех клиентах. Добавлять стоит способом, описанным в пункту 1 или 3. Перегружать сервер после обновления cacert.pem не нужно.
- Самым быстрым методом? будет замена сертификата cacert.pem, который располагается в папке с вашим клиентом. Скачать cacert.pem можно о официального сайта по ссылке:
https://its.1c.ru/db/files/1CITS/EXE/cacert/cacert.zip
В итоге у вас будет архив с сертификатом cacert.pem, распакуйте его. Далее, откройте вашего клиента, где вы получаете ошибку при вызове конструктора WSОпределения. И перейдите по пути:
C:Program Files (x86)1cv88.3.11.3034bin это в случае с версией 8.3.11.3034
Если вы теряетесь в своих версиях, то попробуйте произвести поиск по cacert.pem в папке C:Program Files (x86) и посмотрите, где у вас нужно подменить, этот файл. Меняете его на свежий и радуетесь жизни.
- Второй метод, заключается в использовании обработки в 1С. Скачайте файл обработка.epf
https://its.1c.ru/db/files/1CITS/EXE/digicert_epf/digicert_epf.zip
ОБЯЗАТЕЛЬНО запустите его от имени администратора, иначе можете получить ошибку:
Ошибка записи сертификата. Возможно:
— Файл cacert.pem занят. Освободите файл от редактирования и запустите обработку заново.
— Закройте 1С: Предприятие и запустите с правами администратора операционной системы
- Ну и третий метод, это редактирование текущего файла cacert.pem. Откройте его текстовым редактором и в самом конце файла вставьте содержимое файла digicert.pem, который можно скачать тут:
https://its.1c.ru/db/files/1CITS/EXE/digicert/digicert.zip
В этой статье рассмотрим, как можно реализовать веб-сервис в расширении платформы 1С.
В качестве примера возьмем веб-сервис, позволяющий передавать информацию о клиентах из внешней CRM-системы во внутреннюю систему управленческого учета на «1С:Управление нашей фирмой».
Веб-сервис будет создан в расширении, чтобы сохранить конфигурацию на поддержке.
О чем эта статья
Материал статьи раскроет ответы на следующие вопросы:
- Как работать с XDTO-пакетами?
- Как создать веб-сервис и настроить его свойства?
- Как опубликовать веб-сервис на сервере?
Постановка задачи
Компания ведет учет в типовом решении фирмы «1С:Управление нашей фирмой» (УНФ). Для управления взаимоотношениями с клиентами используется облачная CRM-система. В CRM-систему вводят информацию о новых клиентах. Необходимо реализовать перенос сведений о новых клиентах в УНФ сразу же при регистрации данных в CRM-системе.
Рисунок 1. Схема работы
Данные должны передаваться одним параметром (структурой). Спецификация данных, передаваемые из CRM в УНФ приведены в таблице 1.
Таблица 1. Требования к данным для обмена
| Данные | Имя cвойства | Тип | Ограничения |
| Полное наименование | FullName | Строка | Обязательно для заполнения |
| ИНН | INN | Строка(12) | Для ЮрЛица – длина 10 Для ИП – длина 12 Для ФизЛица – не заполняется Допускаются только цифры |
| КПП | KPP | Строка(9) | Для ЮрЛица – длина 9 Для ФизЛица – не заполняется Допускаются только цифры |
| Телефон | Phone | Строка(12) | Обязателен для заполнения формат +7 (NNN) NNN-NN-NN |
После создания контрагента в CRM-систему должен быть передан уникальный идентификатор. Идентификатор будет использоваться в дальнейшем для сопоставлении клиента в CRM и УНФ при обмене заказами. Необходимо реализовать описанный функционал без снятия УНФ с поддержки.
Обоснование выбора варианта решения
- Проанализируем требования. Добавлять клиентов надо «на лету», сразу же при вводе в CRM. Значит периодические обмены по расписанию нам не подходят.
- Выбранная CRM расположена в облаке, поэтому использовать COM-соединение не получится.
- В требованиях к передаваемым данным есть ограничения — на длину строк и на виды контрагентов. Выбирая между технологией обмена через http-сервисы и веб-сервисы, остановимся на веб-сервисах, так как типизация данных и настройка ограничений в них есть «из коробки». Дополнительным плюсом будет то, что веб-сервисы умеют «самодокументироваться», а значит мы экономим время на описании API для разработчиков CRM.
- Последнее требование — не снимать конфигурацию с поддержки.
Таким образом, для решения описанной задачи мы создадим расширение конфигурации. А в этом расширении реализуем веб-сервис для добавления информации о контрагентах.
Добавляем расширение
Начнем реализацию поставленной задачи и создадим новое расширение. Для этого откроем меню Конфигурация -> Расширения конфигурации.
Рисунок 2. Добавляем расширение
В открывшемся окне жмем кнопку Добавить, а затем заполняем окно создания расширения.
Рисунок 3. Заполняем свойства нового расширения
Префикс указывается для обеспечения уникальности расширений. Обычно в качестве префикса используют первые буквы названия компании или инициалы разработчика. Сохраним расширение, нажав ОК, а затем дважды щелкнем по строке расширения, чтобы его открыть.
Импортируем объекты метаданных
Теперь импортируем в расширение объекты для дальнейшей работы. Нам нужны:
- Справочник Контрагенты
- Справочник Виды контактной информации
- Перечисление Типы контактной информации
Начнем со справочника Контрагенты. Выделим его в основной конфигурации и вызовем контекстное меню Добавить в расширение.
Рисунок 4. Импортируем справочник
Затем добавим в расширение реквизиты справочника Контрагенты и табличную часть КонтактнаяИнформация.
В результате ветка Контрагенты в расширении должна выглядеть так:
Рисунок 5. Справочник «Контрагенты» в расширении
После чего добавим в расширение перечисления ВидыКонтрагентов и ТипыКонтактнойИнформации.
Идем дальше. Из справочника ВидыКонтактнойИнформации нам нужно предопределенное значение ТелефонКонтрагента. Выдяем в дереве метаданных справочник ВидыКонтактнойИнформации и переходим по гиперссылке Предопределенные:
Рисунок 6. Предопределенные элементы справочника
В ветке Контрагенты находим предопределенный элемент ТелефонКонтрагента.
Рисунок 7. Выбираем предопределенный элемент ТелефонКонтрагента
Выполняем команду контекстного меню Добавить в расширение. В расширение добавляется справочник ВидыКонтактнойИнформации и его предопределенный элемент ТелефонКонтрагента.
Рисунок 8. Справочник «Виды контактной информации» в расширении
С импортом объектов в расширение мы закончили. Теперь переходим к разработке веб-сервиса.
Как работают веб-сервисы
Веб-сервисы в 1C представляют собой реализацию протокола SOAP (от англ. Simple Object Access Protocol — простой протокол доступа к объектам). Архитектуру приложения на основе протокола SOAP можно представить в виде следующей схемы:
Рисунок 9. Архитектура приложений на основе протокола SOAP
Общий принцип работы веб-сервиса можно описать так: мы создаем некий функционал, чтобы предоставить его сторонним разработчикам. Для того, чтобы этот функционал был им доступен, мы размещаем его на веб-сервере (публикуем). При публикации веб-сервиса происходит размещение его описания в формате WSDL (WSDL – Web Service Definition Language). Это описание стандартизовано и содержит описание методов веб-сервиса и типов данных, которые могут передаваться между сервисом и его клиентом. Клиент сервиса получает описание сервиса в виде WSDL-файла и может начать обмениваться данными в соответствии с этим описанием. Обмен происходит по протоколу HTTP, а сообщения передаются в теле HTTP пакетов в формате XML.
Особенность этой технологии состоит в том, что нам не нужно формировать XML и HTTP-пакеты вручную. Современные среды разработки, в том числе и 1С, позволяют работать с веб-сервисами в объектной технике.
Создаем XDTO-пакет
XDTO-пакеты описывают типы данных, которые будут использоваться при обмене. Потребителями веб-сервисов могут быть программы, написанные на разных языках, поэтому веб-сервис должен представить свои данные в виде примитивных типов (их описание во всех языках равнозначно). XDTO-пакеты позволяют привести типы 1С к типам, которые описаны в общемировом стандарте W3C. Кроме того, мы можем описать набор ограничений, применяемых к данным.
Приступаем к созданию XDTO-пакета для нашего веб-сервиса. В дереве метаданных расширения в ветке Общие -> XDTO-пакеты добавим XDTO-пакет ak_Customers. В URI пространства имен указываем http://kursy-po-1c.ru/ws/wsextension.
Это не ссылка на реальный адрес в интернете, а просто строка-идентификатор пространства имен, который помогает однозначно идентифицировать типы данных с одинаковыми именами. Например, программист Иванов определил тип данных Customer c двумя свойствами Name и FullName, а программист Петров определил свой тип Customer со свойствами Name, INN, KPP.
Чтобы не возникало путаницы и проблем с одинаковыми названиями типов, применяются пространства имен. Пространство имен и имя типа должны однозначно идентифицировать тип данных. При описании типов данных для веб-сервисов принято в качестве пространства имен использовать URI, содержащие доменное имя разработчика. Это позволяет сделать пространство имен уникальным.
Рисунок 10. Свойства XDTO-пакета
Теперь жмем ссылку Открыть пакет и начинаем описывать типы данных.
Сначала опишем простые типы данных по которым нам нужно наложить ограничения. Это ИНН, КПП, Телефон.
ИНН по условиям задачи различается для ИП и для ЮрЛица.
Определим 2 простых типа: INN_IP и INN_UL. Для этого в форме редактирования пакета открываем меню Добавить -> ТипЗначения.
Рисунок 11. Добавляем тип значения в XDTO-пакет
Заполняем свойства как на рисунке ниже:
Рисунок 12. Свойства типа значения INN_IP
Здесь мы указали имя типа INN_IP (ИНН для ИП) и определили для него ограничение — это должна быть строка длиной 12 знаков.
Обратите внимание, что для названий типов веб-сервиса нужно выбирать англоязычные имена. В дальнейшем они будут использоваться на стороне клиента для генерации классов, а с кириллицей где-то могут возникнуть сложности.
Теперь нам нужно задать ограничение: 12 знаков должны быть цифрами. Выделяем свойство INN_IP и вызываем меню Добавить->Образец:
Рисунок 13. Добавляем шаблона заполнения INN_IP
Заполняем свойство образца шаблоном в виде регулярного выражения [0-9]{12}. То есть мы допускаем в значении 12 цифр от 0 до 9.
Рисунок 14. Шаблон заполнения INN_IP
Подобные действия нужно произвести с INN_UL (ИНН юрлица) и KPP (КПП):
Рисунок 15. Добавляем типы значений и устанавливаем шаблоны
И для телефона (шаблон [+][7][ ][(][0-9]{3}[)][ ][0-9]{3}[-][0-9]{2}[-][0-9]{2}):
Рисунок 16. Типа значения Phone и шаблон его заполнения
Теперь перейдем к определению типов для данных о клиентах.
У нас есть три типа клиентов: Юрлицо, ФизЛицо и ИП. Для всех типов клиентов правила заполнения ИНН и КПП отличаются. Можно сделать только один класс Customer и контроль заполнения ИНН и КПП производить программно, но удобнее это делать декларативно — чтобы уменьшить возможность ошибок. Мы создадим три комплексных типа: CustomerIP, CustomerUL и CustomerFL. Значения ИНН и КПП будем выбирать из ранее созданных типов значений.
Для создания клиента ФизЛицо выделим корень пакета и вызовем меню Добавить -> ТипОбъекта. В свойствах укажем следующие значения:
Рисунок 17. Свойства типа объекта CustomerFL
- CustomerFL — это имя типа. Должно быть на английском.
- ComplexType — базовый тип, аналогичный структуре.
Выделим тип объекта CustomerFL и вызовем меню Добавить->Свойство. Заполним в редакторе свойств значения:
Рисунок 18. Добавляем свойство FullName в тип объекта CustomerFL
- FullName — имя свойства. Должно быть на английском.
- Тип string — строковый тип.
- Поле FullName должно быть обязательно заполнено указываем Возможно пустое — Ложь.
Таким же образом добавим свойства Phone и GUID.
Рисунок 19. Добавляем свойство Phone в тип объекта CustomerFL
Рисунок 20 Добавляем свойство GUID в тип объекта CustomerFL
Затем добавим тип объекта CustomerIP с такими же свойствами, как у CustomerFL, добавив новое свойство INN.
Рисунок 21. Добавляем свойство INN в тип объекта CustomerIP
Дальше создадим тип объекта CustomerUL с такими же свойствами, как у CustomerIP. Добавим новое свойство KPP.
Рисунок 22. Добавляем свойство KPP в тип объекта CustomerUL
У свойства INN нужно изменить тип на INN_UL (http://kursy-po-1c.ru/ws/wsextension).
Рисунок 23. Добавляем свойство INN в тип объекта CustomerUL
Мы завершили создание XDTO-пакета.
Рисунок 24. Новый XDTO-пакет
Переходим к разработке веб-сервиса.
Создаем веб-сервис
В ветке метаданных Общие выделяем ветку Web-Сервисы. Вызываем контекстное меню Добавить и заполняем свойства нового веб-сервиса:
Рисунок 25. Заполняем свойства веб-сервиса
- Имя — ak_Customers
- ПакетыXDTO — http://kursy-po-1c.ru/ws/wsextension. Теперь сможем использовать типы данных, которые определены этом пакете.
- URI пространства — http://kursy-po-1c.ru/ws/wsextension. Пространство имен будет использоваться клиентами веб-сервиса.
- Имя файла публикации — Customers.1cws. Имя будет использоваться в URL для получения WSDL.
Теперь добавим метод веб-сервиса, который будет записывать в УНФ нового контрагента-физлицо. Вызываем меню Добавить->Операция и заполняем свойства:
Рисунок 26. Свойства метода AddCustomerFL
- Имя — имя метода веб-сервиса. Будет использоваться при обращении к сервису извне.
- Тип возвращаемого значения — тип данных, который возвращает сервис. В нашем случае это строка-уникальный идентификатор, который в будет возвращен в CRM.
- Имя процедуры — имя процедуры в модуле сервиса, которая будет выполняться при обращении к этому методу.
Далее мы добавим параметры, которые будут передаваться в веб-сервис.
В нашем случае это один параметр — Customer. Для добавления параметра выделяем операцию веб-сервиса и вызываем контекстное меню Добавить->Параметр. В свойствах этого параметра заполняем свойства:
Рисунок 27. Свойства параметра Customer
- Имя — имя параметра метода сервиса. Будет виден на клиенте веб-сервиса.
- Тип значения — тип значения, определенный в нашем пакете.
Добавим еще две операции:
- AddCustomerIP
- AddCustomerUL.
Можно сделать это копированием. Затем нужно поменять имена операций, имена процедур-обработчиков (AddCustomerIP и AddCustomerUL) и типы параметров. Для AddCustomerIP тип параметра установим CustomerIP, а для AddCustomerUL — CustomerUP.
Теперь нужно создать процедуры-обработчики методов сервиса.
//Добавляем ФизЛицо Функция AddCustomerFL(Customer) Возврат ДобавитьКлиента(Customer, Перечисления.ВидыКонтрагентов.ФизическоеЛицо); КонецФункции //Добавляем ЮрЛицо Функция AddCustomerUL(Customer) Возврат ДобавитьКлиента(Customer, Перечисления.ВидыКонтрагентов.ЮридическоеЛицо); КонецФункции //Добавляем ИП Функция AddCustomerIP(Customer) Возврат ДобавитьКлиента(Customer, Перечисления.ВидыКонтрагентов.ИндивидуальныйПредприниматель); КонецФункции //Добавляем контрагента в базу УНФ Функция ДобавитьКлиента(Клиент, ВидКонтрагента) //Создаем нового контрагента и заполняем общие реквищиты НовыйКлиент = Справочники.Контрагенты.СоздатьЭлемент(); НовыйКлиент.ВидКонтрагента = ВидКонтрагента; НовыйКлиент.Наименование = Клиент.FullName; НовыйКлиент.НаименованиеПолное = Клиент.FullName; НовыйКлиент.Покупатель = Истина; //Для ЮрЛица и ИП заполняем ИНН Если ВидКонтрагента <> Перечисления.ВидыКонтрагентов. ФизическоеЛицо Тогда НовыйКлиент.ИНН = Клиент.INN; КонецЕсли; //Для ЮрЛица заполняем КПП Если ВидКонтрагента = Перечисления.ВидыКонтрагентов.ЮридическоеЛицо Тогда НовыйКлиент.КПП = Клиент.KPP; КонецЕсли; //Заполняем контактные данные Телефон = НовыйКлиент.КонтактнаяИнформация.Добавить(); Телефон.Тип = Перечисления.ТипыКонтактнойИнформации.Телефон; Телефон.Вид = Справочники.ВидыКонтактнойИнформации.ТелефонКонтрагента; Телефон.НомерТелефона = Клиент.Phone; Телефон.Представление = Клиент.Phone; //Записываем клиента в базу НовыйКлиент.Записать(); //Возвращаем ссылку в виде уникального идентификатора (GUID) Возврат XMLСтрока(НовыйКлиент.Ссылка); КонецФункции
Код простой и каких-то особых комментариев не требует.
Публикуем веб-сервис на сервере
Для публикации веб-сервиса должны быть установлены:
- Веб-сервер (Apache или IIS)
- Платформа 8.3.7 и выше с установленным расширением веб-сервера
О подготовке рабочего окружения можно прочитать в статье Как настроить обмен 1С с интернет-сервисами.
Для публикации веб-сервиса нужно запустить конфигуратор с правами администратора. Для этого вызываем контекстное меню и выбираем «Запуск от имени администратора»:
Рисунок 28. Запускаем конфигуратор от имени администратора
После открываем меню Администрирование->Публикация на веб-сервере. В открывшемся окне заполняем настройки:
Рисунок 29. Публикация веб-сервиса
- Имя — имя базы для публикации на сервере. Будет являться частью URL.
- Веб-сервер — на нем будет опубликована база. В нашем случае используется Apache 2.4.
- Каталог — место на диске, куда будет помещен default.vrd.
- Публиковать веб-сервисы — отмечаем.
- Публиковать веб-сервисы расширений по умолчанию — отмечаем, чтобы веб-сервисы были доступны из расширений.
Жмем Опубликовать.
Проверим, что веб-сервис опубликовался. Для этого запустим браузер и в адресной строке введем http://localhost/UNF/ws/Customers.1cws?wsdl. В результате в браузере должен отобразиться XML.
Рисунок 30. Проверяем работу веб-сервиса
Если в вашей базе есть пользователи, то при обращении по указанной ссылке будет запрошен логин и пароль. Нужно ввести логин и пароль администратора информационной базы.
Чтобы в дальнейшем не отвлекаться на пароли при изучении статьи (тему безопасности мы сознательно опускаем), откроем в текстовом редакторе файл default.vrd, (он лежит в каталоге, указанном при публикации). В него запишем логин и пароль в строке подключения: ib=”File="D:1CBaseUNF";usr=admin;pwd=12345;”. Логин, пароль и путь должны быть от вашей базы 1С.
Тестируем веб-сервис
Для проверки работоспособности сервера можно создать отдельную базу 1С и добавить в ней обработку ТестВебСервера со следующими реквизитами:
- FullName, строка(100)
- INN, строка(12)
- KPP, строка(9)
- Phone, строка(20)
Реквизиты выводим на форму и добавляем три кнопки:
- Создать ФизЛицо
- Создать ЮрЛицо
- Создать ИП.
Рисунок 31. Обработка для проверки веб-сервиса
В модуле формы напишем такой код:
//1. Обработчики кнопок //Обработчик кнопки СоздатьФизЛицо &НаКлиенте Процедура СоздатьФизЛицо(Команда) СоздатьКлиентаНаСервере("CustomerFL"); КонецПроцедуры //Обработчик кнопки СоздатьИП &НаКлиенте Процедура СоздатьИП(Команда) СоздатьКлиентаНаСервере("CustomerIP"); КонецПроцедуры //Обработчик кнопки СоздатьЮрЛицо &НаКлиенте Процедура СоздатьЮрЛицо(Команда) СоздатьКлиентаНаСервере("CustomerUL"); КонецПроцедуры //Создание клиента &НаСервере Процедура СоздатьКлиентаНаСервере(ТипКлиента) //2. Получаем описание сервиса ВСОпределение = Новый WSОпределения("http://localhost/UNF/ws/Customers.1cws?wsdl"); //3. Создаем прокси для обращения к сервису Прокси = Новый WSПрокси(ВСОпределение, "http://kursy-po-1c.ru">kursy-po-1c.ru/ws/wsextension", "ak_Customers", "ak_CustomersSoap"); //4. Получаем тип клиента по URI пространству имен и имени типа ТипКлиент = Прокси.ФабрикаXDTO.Тип("http://kursy-po-1c.ru">kursy-po-1c.ru/ws/wsextension", ТипКлиента); //5. Создаем XDTOОбъект заданного типа Клиент = Прокси.ФабрикаXDTO.Создать(ТипКлиент) ; //6. Заполняем данные Клиента данными, введенными в форме ЗаполнитьЗначенияСвойств(Клиент, Объект); //7. В зависимости от типа клиента вызываем соответствующий метод веб-сервиса Если ТипКлиента = "CustomerFL" Тогда Объект.GUID = Прокси.AddCustomerFL(Клиент); ИначеЕсли ТипКлиента = "CustomerIP" Тогда Объект.GUID = Прокси.AddCustomerIP(Клиент); ИначеЕсли ТипКлиента = "CustomerUL" Тогда Объект.GUID = Прокси.AddCustomerUL(Клиент); КонецЕсли; КонецПроцедуры
Прокомментируем код:
- В обработчиках кнопок вызываем процедуру СоздатьКлиентаНаСервере() и передаем название типа клиента в виде строки.
- Получаем WSDL-описание веб сервиса, опубликованного по указанному в параметрах URL. На основании него создается объект WSОпределение.
- Создаем объект Прокси для работы с сервисом. Он позволяет обращаться к веб-сервису, вызывая его методы в привычном объектном стиле. В качестве параметров передаем WSОпределение сервиса, созданное на предыдущем шаге, пространство имен веб-сервиса, имя веб-сервиса и точку подключения. Имя точки подключения формируется путем добавления к имени сервиса суффикса Soap (так формирует WSDL 1C).
- Получаем тип клиента по URI пространства имен.
- На основании типа клиента, полученного на предыдущем шаге, создаем XDTOОбъект Клиент. По структуре этот объект будет соответствовать структуре типа, который мы определяли в нашем XDTO-пакете.
- Заполняем значения реквизитов клиента данными, введенными в форме;
- В зависимости от переданного в процедуру типа клиента, мы вызываем разные методы веб-сервиса. «Под капотом» этого вызова произойдет сериализация данных в XML, валидация XML, формирование HTTP пакета и отправка его на сервер.
С этой обработкой можно поэксперементировать. Попробуйте создавать клиентов разных типов, введя корректные данные и некорректные. Если вы попытаетесь ввести в ИНН буквы или заполнить телефон, не соблюдая формат, то появится окно ошибки.
Итак, в данной статье мы познакомились с возможностями платформы по разработке веб-сервисов без снятия конфигурации с поддержки. Создали расширение, импортировали в расширение нужные нам объекты метаданных и описали модель данных для обмена. Создали и опубликовали веб-сервис. Написали обработку на 1С для проверки работоспособности этого сервиса.
На этом пока закончим, но не остановимся
Об авторе
Автор статьи – Алексей Дубровин, г. Челябинск
E-mail: dubrovin1973@gmail.com
Нужно быстро разобраться в работе расширений?
Чтобы быстро и полностью освоить все возможности расширений, рекомендуем пройти наш учебный курс Разработка расширений и технологии доработки конфигураций 1С без снятия с поддержки.
Здравствуйте, уважаемые друзья и гости блога! Сегодня пойдет речь о такой странной вещи на сайте, как ошибка 301 Moved Permanently (переехал навсегда) или по другому редирект 301.
Думаю. что все с таким сталкивались, а некоторые даже использовали данную “ошибку 301” на своих сайтах. Но не все знают для чего эта ошибка 301 или иначе редирект 301 нужна на сайте? Для чего он, 301 редирект, используется?!
Вот сейчас мы с вами и займемся разбором этого вопроса во всех его подробностях и нюансах …
Ошибка 301 или редирект 301 что это?
Как Вы уже наверное догадались по переводу слов “moved permanently” – это дословно, что сайт или отдельная его страница “переехал навсегда” по адресу на который Вас перекинул ваш браузер. Тут надеюсь все понятно и ясно без лишних пояснений!
Но возникает вопрос. Для чего это сделано вебмастером этого сайта? Почему он поставил редирект 301 и у нас с вами выскакивает иногда 301 ошибка? А все просто! Ошибка 301 появляется, когда сервер перебрасывает нас с уже не работающего сайта на страницу сделанную специально для перенаправления пользователя на рабочий сайт, но просто с некоторой задержкой или вообще на этой странице нужно самостоятельно перейти по ссылке. Вот это в двух словах об ошибке 301.
Теперь самый важный момент, зачем же все таки нужен редирект 301 на сайте …
Редирект 301 и для чего он нужен?
Есть несколько причин у вебмастера, чтобы использовать редирект 301. Вот они:
Вот основные причины для использования редирект 301 или ошибка 301 Moved Permanently.
Теперь давайте узнаем, как правильно использовать редирект 301 на своем сайте и как настроить его через файл htaccess …
301 редирект и файл htaccess – как правильно настроить?
Как я вам уже говорил выше – 301 редирект это переадресация посетителя и поискового робота на сайт или отдельно взятую страницу сайта на URL адрес отличный от первоначально запрошенного в браузере.
Для чего это нужно мы с вами также уже разобрали. Но как же это сделать правильно на нашем сайте используя файл htaccess? Сейчас я вам все подробно объясню и приведу примеры внесения изменений в файл htaccess для вашего сайта!
или вот более понятный синтаксис:
Этот материал посвящен выходу 301-ой статьи на моем блоге!
Может вам интересно узнать, что такое ошибка 503 и как ее устранить?
Проверка кода ответа сервера
Проверять код ответа нужно для того, чтобы поисковик правильно индексировал страницы. Если страницы, которые нужно включить в индекс, будут отдавать код 404 — никакого продвижения у вас не получится.
Процесс взаимодействия браузера с сервером основывается на формировании запроса пользователя и его отправке к веб-странице на сервер. Получив запрос, сервер отправляет необходимые http-заголовок и html-файл. Код ответа сервера как раз и состоит из заголовка сайта и определенного сопроводительного текста, который соответствует каждому коду ответа. Пояснительный текст предназначен для человека, который с его помощью может узнать, в чем заключается ошибка.
Как проверить код ответа сервера
Обычно нужно просто ввести урл страницы в один из сервисов, а он уже выдаст вам код ответа. Давайте посмотрим, что за сервисы можно использовать в этих целях.
Яндекс Вебмастер
В Яндекс Вебмастере проверить код ответа сервера можно с помощью инструмента Server Response. Указав url-адрес любой страницы, которая может находится в индексе, нажимаем «Проверить».
Поскольку страница работает нормально, поисковому боту отдается код 200, с пояснением «ОК» — все хорошо.
Для проверки противоположного случая можно ввести адрес страницы, которой на сайте нет и которая никак не может быть просканирована поисковым ботом. Напишем заветное заклинание для тех, кто любит сочинять бред.
Как было написано выше, в ответ на несуществующую страницу, сервер выдает ошибку 404, с пояснением «Not Found» — не найдено.
Bertal
В отличии от Server Response, помимо ботов Яндекса на Bertal можно выбрать GoogleBot и BingBot, а также популярные браузеры. Укажем те же страницы, чтобы подтвердить правильную работоспособность сервера. В списке ботов выберем GoogleBot.
Пиксель Тулс
На Пиксель Тулс сервис для проверки ответа сервера поддерживает массовую проверку страниц. Список адресов можно вводить вручную или загружать из файла. Полученные результаты можно сохранить в CSV-файл.
Что такое ошибка 301
Ответ 301 moved permanently означает, что запрашиваемая страница переехала на новый URL. Новый адрес который указывается в отдельной графе сервиса.
Также приведу пример с проверкой страницы, с которой происходит 301 редирект.
В графе «Location» указана ссылка на которую происходит переадресация. Пояснение «Moved Permanently» означает, что страница переехала навсегда.
Что такое ошибка 503
Ответ 503 Server Unavailable означает, что сервер временно не может обрабатывать запросы из-за технических проблем. Этот код предназначен для уведомления поискового бота о том, что на сайте проводятся технические работы. После ошибки 503 бот при необходимости посетит страницу позже. При продвижении сайта нужно следить за страницами с ответом 503. После осуществления на сайте технических работ нужно проверить их, чтобы они вновь отвечали кодом 200 ОК.
Вот видос, где Гроховский поясняет за коды ответа сервера:
Что такое 301 редирект и как его настроить
При работе с веб-ресурсами возникают ситуации, когда происходит удаление, перенос или изменение url-адреса отдельных страниц или сайта целиком. При этом требуется сохранить индексацию в поисковых системах и перенаправить пользовательский трафик на новый адрес. Для решения этой задачи используется функция под названием 301 Redirect. Это один из инструментов SEO, который позволяет не только избежать ошибок при открытии отдельных страниц, но и добиться корректной работы ресурса. Правильные настройки редиректа дают дополнительную возможность получить синергетический эффект в поисковой оптимизации и увеличить количество органического трафика на релевантные страницы. Рассмотрим более подробно, как происходит настройка редиректа 301.
Что такое переадресация 301
Permanent Redirect 301 применяется с целью организации постоянной переадресации с неактуального доменного адреса или url отдельной страницы на рабочую версию. Редирект может понадобиться в связи с глобальным переносом сайта на другой домен, техническими изменениями в написании адреса, удалением страниц, необходимостью внутренней и внешней перелинковки. Один из вариантов использования перманентной переадресации – редирект с нескольких доменных имен, созданных в разных зонах, на один актуальный адрес. Грамотное использование редиректа позволяет перемещать контент без потерь в поисковой индексации, сохранить и даже увеличить прежний вес и позицию в выдаче.
Настроить код состояния HTTP 301 можно разными способами:
с помощью HTML и PHP;
через панель управления или плагины соответствующей CMS;
при помощи специальных скриптов (программ);
на уровне хостинг-провайдера;
Последний способ является наиболее простым и надежным. О нем чуть позже поговорим подробнее.
Альтернативные методы переадресации
В большинстве случаев постоянная переадресация является более правильным решением, чем временная. На практике это объясняется просто. Предположим, сайт сменил доменную зону, а затем еще и обзавелся защищенным протоколом https. При настройке временной переадресации в индексе Яндекса и Google по одним и тем же запросам появились три версии сайта с пропорциональным проседанием позиций в выдаче. После настройки редиректа 301 на приоритетный url произошло склеивание дублей, робот вернул сайт в топ выдачи.
Не рекомендуется использовать постоянный редирект при временном переносе сайта или наличии серьезных проблем со старым доменным именем. Если адрес забанен или попал под поисковую фильтрацию, смена дислокации с применением переадресации не поможет избавиться от этих ограничений.
В каких случаях используется постоянный редирект 301
Смена доменного имени, перенос сайта. Необходимо произвести тотальную настройку переадресации со старого адреса на новый, чтобы все без исключения запросы к old_site. ru перенаправлялись на new_site. ru.
Изменение написания url определенных страниц в целях SEO-продвижения, смены CMS или по иным причинам. Требуется настроить редирект с site. ru/1hdkr5 на site. ru/page_adress.
Перенос разделов на субдомены. Необходимо сменить адрес www. site. ru/example на example. site. ru.
Для аккумуляции трафика с адресов, купленных в разных доменных зонах, на один приоритетный ресурс.
Исключение дублирующихся страниц из индекса.
Склейка зеркал сайта – вариантов сайта с идентичным контентом, но разным написанием адресов: site. ru, www. site. ru, https://site1.ru и т. д. В этом случае выбирается один приоритетный домен и на него настраивается редирект со всех остальных зеркал.
Удаление ранее существовавшей страницы. В этом случае пользователи обычно видят ошибку 404. Большое количество таких сообщений негативно воспринимается как пользователями, так и поисковиками.
Для быстрого перехода пользователя на мобильную версию ресурса со смартфонов и планшетных устройств.
Создание постоянной переадресации 301 через настройки и плагины CMS
В большинстве популярных конструкторов сайтов и CMS (OpenCart, Joomla!, Битрикс, Wix, Тильда) предусмотрена настройка редиректов с помощью встроенных инструментов. Если сайт создан с помощью WordPress, для настройки переадресации можно воспользоваться следующими плагинами:
Redirection — самый популярный плагин для настройки редиректов. Кроме основной функции обладает следующими возможностями: сбором статистики переадресаций, отслеживанием ошибок 404, поддержкой регулярных выражений.
Safe Redirect Manager — простой плагин, который также поддерживает регулярные выражения, практически не влияет на производительность сайта.
Quick Page/Post Redirect Plugin — еще один удобный инструмент оптимизации. Один из недостатков — отсутствие поддержки регулярных выражений. К ссылкам можно добавлять атрибут «nofollow».
Simple 301 Redirects. Данный модуль обладает одним недостатком – url для переадресации необходимо прописывать вручную.
Для Битрикс кодировка будет выглядеть следующим образом:
В Joomla настройки переадресации производятся через панель администратора в разделе «Компоненты» => «Перенаправление». Здесь можно не только установить правила редиректа, но и отслеживать страницы с битыми ссылками и перенаправлять их на корректные адреса.
Но настроить редирект 301 довольно просто в базовом редакторе.
Найти файл можно через панель управления хостинга либо использовать FTP-клиент. При любом варианте нужно включить отображение скрытых файлов.
Для создания 301 редиректа перейдите в панель управления вашего сайта.
Рекомендуем все условия редирект записывать в блоке IfModule, дабы избежать ошибок при выполнении файла htaccess.
Перед тем как начать прописывать правила перенаправления, необходимо включить механизм преобразований (RewriteEngine) при помощи команды RewriteEngine On.
Хостинги применяют по умолчанию 302 или любой другой 3xx редирект. В связи с этим в правилах используются флаги. Рекомендуем дописывать в своих правилах [R=301,L].
Склейка зеркал сайта (www / без www)
Сайты https://name. site и https://www. name. site для поисковых систем являются разными. А по факту это разные адреса одного сайта.
Если произошла обратная ситуация и необходима переадресация с без «www» на «www», то в файл прописывается:
Редирект с http на https для всего сайта
Если данная конструкция не сработает, попробуйте другой вариант:
Если редирект не работает и в этом случае, попробуйте такой вариант:
В результате пройдет перенаправление на https всех пользователей и поисковых систем.
Постранично
Бывают случаи, когда необходимо создать редирект на https всех страниц, кроме одной. В этом случае используют постраничный редирект:
Для одной страницы
Для редиректа с http на https одной страницы (например page. php), в файл добавьте следующую конструкцию:
Редирект сайта с https на http
Если необходимо сделать 301 редирект всего сайта с https на http, в файл прописывается следующее:
Изменение домена
Редирект на страницу с другим url (без параметров)
Редирект для url (с параметрами)
Если адрес содержит параметр (например, https://name. site/articles. php? section=1, где параметром является «section=1» ), то прописывают следующую конструкцию:
Редирект с index. php на главную страницу
В тех случаях, когда главная страница сайта может быть недоступна по нескольким адресам одновременно, применяют следующую конструкцию:
Редирект со страниц со слешем на без слеша (для всего сайта)
Или более короткий вариант:
Редирект со страниц без слеша на слеш (для всего сайта)
Обратный вариант применяется, когда нужно использовать адреса со слешем.
301 редирект с 404 Not Found
Код 404 Not Found (страница не найдена) присваивается удаленной или несуществующей странице на сайте. Создание постоянного перенаправления с таких страниц актуально для контентных сайтов и крупных интернет-магазинов, где страницы часто удаляются по естественным причинам. Тогда возникает потребность перенаправить посетителей на одну из главных страниц сайта, чтобы они не уходили с ресурса при виде ошибки.
301 редирект для страниц 404 Not Found сделать совсем не сложно. Например, этот код перенаправит со всех 404-страниц на главную:
Однако делать такие редиректы в массовом порядке не рекомендуется, так как это может испортить SEO-статистику всего ресурса.
Пример файла htaccess, после добавления в него редиректов:
точка заменяет произвольный символ
обозначает перечень знаков, совпадающих с буквами a, b, или с
список символов вне указанного диапазона (кроме a, b, с)
указывает на то, что предыдущий знак может повторяться 0 или больше раз
команда найдет идущие подряд символы из заданного набора
приводит к противоположному эффекту
заменяет любой набор символов
ищет все подстроки между кавычками
начало строки (когда используется в начале выражения)
означает конец строки
цифра, буква или подчеркивание _
заменяет любую цифру
может заменить любой знак, кроме цифры
для замены любой цифры
для всех букв от a до z в нижнем регистре
для каждой буквы от A до Z в верхнем регистре
любая буква от a до Z во всех регистрах
Другие способы создания переадресации 301
Через PHP
Данный вариант подойдет тем, кто хорошо разбирается в web-программировании и PHP. Необходимо открыть файл index. php в корне CMS-движка и прописать там:
(в первой строке укажите старый url, а во второй — новый)
ASP-редирект
ASP. NET редирект
Найдите в корне своего сайта файл web. config и вставьте в секцию синтаксис:
ColdFusion редирект
JSP (Java) редирект
Данный способ подойдет для небольшой корректировки простых сайтов. Код можно прописать лишь в одном файле, а сам файл добавить на все нужные страницы, указав:
CGI-скрипт на PERL
Ruby on Rails
Редирект в Nginx
HTML-редирект
Этот способ подойдет для небольших статических сайтов, когда требуется настроить переадресацию для одной страницы. Для этого необходимо добавить специальный мета-тег внутри кода HTML. Пример записи редиректа на другой ресурс после 5-секундной задержки:
Если поставить значение 0 вместо 5, то переадресация на https://livepage. pro произойдет моментально.
Однако для больших сайтов HTML-перенаправление делать сложно и затратно по времени, поэтому лучше отдать предпочтение другому варианту.
Редирект 301 в панелях управления сервера
Большинство панелей управления сервера предоставляют возможность настройки переадресации с кодом 301. Рассмотрим варианты решения этой задачи на примере двух популярных ПУ для VDS.
Cpanel
Нужно перейти в блок «Домены» => «Перенаправления». В появившемся окне выполнить следующее:
В строке «Тип» выбрать «Постоянный 301».
В строке «https://www» из выпадающего списка выбрать домен сайта (например, example. ru).
В строке «Перенаправляет на» указать для домена адрес https://example. ru.
В блоке «Перенаправление www» поставить галочку напротив «Перенаправлять только с www».
Сохранить изменения кликом на «Добавить».
ISPmanager
Автоматическое создание переадресации
При отсутствии знаний и опыта самостоятельной настройки редиректа можно воспользоваться сервисами автоматической генерации:
Проверка корректности настроек 301 редиректа
Самый простой способ проверки переадресации – ручное тестирование. Для этого необходимо вставить в адресную строку браузера url сайта или страницы, с которой настроено перенаправление. Если при открытии будет доступен ресурс, на который настроен редирект, то переадресация выполняется правильно.
Для автоматической проверки можно воспользоваться специальными сервисами:
программой Screaming Frog Seo Spider, способной просканировать весь сайт.
Существует ряд ошибок, которые следует избегать при настройке редирект 301:
использование перенаправлений между страницами сайта без изменения их url в ссылках;
установка временной переадресации вместо постоянной;
неправильный выбор типа редиректа;
перенаправление файла robots. txt;
непонимание разницы между rel=canonical и кодом 301;
редирект на нерелевантный контент;
переадресация, которая не приводит к 200-й странице.
Стоит отметить проблему создания цепочки ссылок, которая может привести к появлению циклического редиректа — ошибки с кодом «ERR_TOO_MANY_REDIRECTS». Наиболее распространенные причины возникновения такого бага – неправильная настройка в процессе создания переадресации, вирусная атака, слишком длинная цепочка редиректов. Не рекомендуется настраивать редирект, содержащий более пяти адресов. Оптимальной является прямая переадресация со старого на новый url.
Заключение
Использование редиректа 301– очень важный способ поисковой и пользовательской оптимизации веб-ресурса. Использовать его следует с осторожностью. Неправильная настройка может привести к сбоям в работе сайта и потере поисковых позиций.
Источники:
https://pribylwm. ru/samoobrazovanie/oshibka-301.html
https://znet. ru/raskrutka/kak-proverit-kod-otveta-servera-i-redirekta-chto-oznachaet-oshibka-301/
https://timeweb. com/ru/community/articles/chto-takoe-301-redirekt-i-kak-ego-nastroit
|
|||
| FFrr1C
10.07.17 — 23:13 |
Подскажите пожалуйста, может кто сталкивался: создал веб сервис «Price», опубликовал вместе с базой, далее в коде Определение = Новый WSОпределения(«http://localhost/zerkal/ws/Price.1cws?wsdl»,»admin»,»123″;) дает ошибку При создании описания сервиса произошла ошибка. URL сервиса: http://localhost/zerkal/ws/Price.1cws?wsdl Код ответа сервера: 301 |
||
| Имитация работы
1 — 10.07.17 — 23:32 |
Открой адрес в браузере. После получения xml внимательно посмотри на адресную строку. Сравни ее с исходной. |
||
| FFrr1C
2 — 10.07.17 — 23:54 |
браузер пишет: 1C:Enterprise 8 application error: HTTP: Not found Ошибка при работе с ресурсом /Zerkal/ws/Price/ |
||
| FFrr1C
3 — 10.07.17 — 23:57 |
Хотя сейчасас в браузере написано следующее: #exception «{http://v8.1c.ru/8.2/virtual-resource-system}Exception»; exception clsid «580392e6-ba49-4280-ac67-fcd6f2180121» reason 404 descr «HTTP: Not foundnОшибка при выполнении запроса GET к ресурсу /ws/WebPrice:» #inner «{http://v8.1c.ru/8.1/data/core}Exception»; inner clsid «a01f465c-ed70-442e-ada5-847668d7a41c» descr «Текущему соединению с информационной базой не назначен сеанс» data «kg0L3QtSDQvdCw0LfQvdCw0YfQrntdC9INGB0LXQsNC90YEifSwzNX0=» |
||
| FFrr1C
4 — 11.07.17 — 00:11 |
Что-то совсем запутался, в конфигураторе Web-Сервис назван WebPrice, имя файла публикации Price.1cws в коде Новый WSОпределения(«http://localhost/zerkal/ws/Price.1cws?wsdl»,»admin»,»123″;) что нужно указывать? если WSОпределения(«http://localhost/zerkal/ws/Price.1cws?wsdl»,»admin»,»123″;) тогда код ошибки 301 если WSОпределения(«http://localhost/zerkal/ws/WebPrice.1cws?wsdl»,»admin»,»123″;) тогда код ошибки 404 и в журнале регистрации запись «Сеанс. Ошибка аутентификации» |
||
| Имитация работы
5 — 11.07.17 — 00:38 |
Большую букву Z |
||
| FFrr1C
6 — 11.07.17 — 00:47 |
Я так понимаю все же проблема с аутентификацией, юзер от 1С не подходит.. |
||
| Имитация работы
7 — 11.07.17 — 00:48 |
Ок |
||
| FFrr1C
8 — 11.07.17 — 00:53 |
Не понял какой смысл в имени файла публикации если обращение идет через то имя которое в конфигураторе? это имя фала публикации где-то задействовано? |
||
|
FFrr1C 9 — 11.07.17 — 00:55 |
Есть ли простое решение чтобы пройти аутентификацию, для НеСисАдмина, что где поставить в пользователях.. |
Код перенаправления 301 Moved Permanently протокола передачи гипертекста (HTTP) показывает, что запрошенный ресурс был окончательно перемещён в URL, указанный в заголовке Location (en-US). Браузер в случае такого ответа перенаправляется на эту страницу, а поисковые системы обновляют свои ссылки на ресурс (говоря языком SEO, вес страницы переносится на новый URL-адрес).
Даже если спецификация требует, чтобы при выполнении перенаправления, метод и тело запроса не изменялись, не все пользовательские приложения обращают на это внимание, и вы все ещё можете столкнуться с программами имеющими этот баг. Именно поэтому код 301 рекомендуется только в качестве ответа на GET или HEAD запрос, а для POST рекомендуется код 308 Permanent Redirect, так как он явно запрещает изменение метода запроса.
Статус
Пример
Запрос клиента
GET /index.php HTTP/1.1 Host: www.example.org
Ответ сервера
HTTP/1.1 301 Moved Permanently Location: http://www.example.org/index.asp
Характеристики
| Спецификация | Название |
|---|---|
| RFC 7231, секция 6.4.2: 301 Redirect Permanently | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |
Совместимость с браузером
BCD tables only load in the browser
Смотрите также
Привет, читатель блога ZametkiNaPolyah.ru! Продолжим знакомиться с протоколом HTTP в рубрике серверы и протоколы и ее разделе HTTP протокол. Данная публикация будет о HTTP кодах состояния перенаправления. К HTTP кодам перенаправления относятся следующие коды: 300, 301, 302, 303, 304, 305, 306, 307. Напомню, что коды перенаправления говорят клиенту о том, что для успешного завершения запроса необходимо выполнить какое-то действие. Обычно браузеры выполняют такие действия без вмешательства пользователя. В данной записи мы рассмотрим сперва все HTTP коды перенаправления, а затем рассмотрим каждый код в отдельности более подробно.
HTTP коды состояния перенаправления: 300, 301, 302, 303, 304, 305, 306, 307
Общая информации о HTTP кодах перенаправления
Содержание статьи:
- Общая информации о HTTP кодах перенаправления
- HTTP код состояния 300: множественный выбор. HTTP код состояния 301: постоянно перенесен. HTTP код состояния 302: временно перемещен.
- HTTP код состояния 303: смотреть другой ресурс. HTTP код состояния 304: ресурс не модифицирован. HTTP код состояния 305: использовать прокси сервер. HTTP код состояния 307: временное перенаправление
Если вы хотите узнать всё про протокол HTTP, обратитесь к навигации по рубрике HTTP протокол. Да, эти коды состояния, как раз и есть тот самый Redirect 301 или склейка доменов, глупое выражение: Redirect 301 – склейка домена. Автор тоже этим грешил, автор каится и обещает исправиться. Все дело в том, что 301 – это всего лишь, код, который означает, что произошло перенаправление, а вот за склейку доменов отвечает HTTP сервер и его конфигурации, поэтому крайне неправильно говорить этот ваш редирект 301.
Мы немного отвлеклись, давайте перейдем к HTTP кодам состояния перенаправления, все HTTP коды перенаправления начинаются с тройки. Общей чертой HTTP кодов перенаправления является то, что все они сообщают браузеру о том, что для продолжения работы ему необходимо выполнить какие-либо дополнительные действия, обычно браузер выполняет эти действия не спрашивая пользователя.
Для удобства давайте сведем все HTTP коды состояния перенаправления в единую таблицу и дадим им краткое описание.
| HTTP ответ | Описание кода состояния перенаправления |
| 300 Multiple Choices | HTTP код перенаправления 300: множественный выбор HTTP код состояния 300 говорит клиенту о том, что запрошенный ресурс имеет несколько представлений и клиент в праве выбрать одно из предлагаемых представлений. Действует ограничение в пять адресов максимум. |
| 301 Moved Permanently | HTTP код перенаправления 301: постоянно перемещен HTTP код состояния 301 говорит клиенту о том, что запрашиваемая страница была перенесена на новый адрес, обычно браузер автоматически переходит по новому адресу. |
| 302 Found | HTTP код перенаправления 302: временно перемещен HTTP код состояния 302 говорит клиенту о том, что запрашиваемый ресурс был временно перемещен на новый адрес. |
| 303 See Other | HTTP код перенаправления 303: смотри другой HTTP код состояния 303 говорит клиенту о том, что ответ на запрос может быть найден по другому URI (про URI в HTTP найдешь информацию здесь), новый запрос следует выполнять методом GET (про HTTP методы смотри здесь). |
| 304 Not Modified | HTTP код перенаправления 304: не модифицирован HTTP код состояния 304 говорит клиенту о том, что сервер выполнил условный GET запрос, но документ никак не изменился. |
| 305 Use Proxy | HTTP код перенаправления 305: используй прокси HTTP код состояния 304 говорит клиенту о том, что запрошенный URL должен быть доступен через прокси, который указан в поле заголовка Location. |
| 306 Unused | HTTP код перенаправления 306: зарезервировано Код состояния 306 использовался в прошлой версии HTTP протокола, на данный момент он не используется, но зарезервирован стандартом HTTP. |
| 307 Temporary Redirect | HTTP код перенаправления 307: временно перемещен HTTP код состояния 307 говорит клиенту о том, что запрашиваемая страница временно переехала на новый адрес |
Давайте более подробно поговорим про каждый из кодов состояний HTTP сервера класса перенаправления.
HTTP код состояния 300: множественный выбор. HTTP код состояния 301: постоянно перенесен. HTTP код состояния 302: временно перемещен.
HTTP код состояния 300 или код множественного выбора говорит о том, что клиент может выбрать несколько доступных представлений ресурса, но не более пяти. Каждое представление ресурса имеет свое уникальное месторасположения на сервере. Формат, в котором клиент будет получать HTTP объект определяется медиа типом данных (читай про типы данных в HTTP по этой ссылке), указанным в поле заголовка Content-Type. Иногда выбор выполняется автоматически браузером без участия пользователя, но стандарт HTTP протокола не дает никаких критериев, по которым должен происходить автоматический выбор, а так же не имеет никаких требований. Ответы HTTP сервера с кодом состояния 300 по умолчанию являются кэшируемыми, если в заголовках не указано иного.
HTTP код состояния 301 или код состояния постоянного переноса. Код состояния 301 сообщает браузеру о том, что для ресурса, к которому он обратился, назначен новый URI, и все обращения к этому ресурсу следует выполнять по новому URI, указанному в ответе HTTP сервера. Ответы сервера с кодом 301 являются кэшируемыми. В тех случаях, когда клиент использовал HTTP запрос с методом отличным от GET или HEAD, браузер спрашивает у пользователя, что делать дальше: переходить по новому URI или не надо.
HTTP код состояния 302 или код временного перемещения ресурса. Код состояния 302 говорит о том, что на данный момент ресурс временно доступен по другому URI и сообщает новый URI ресурса. Кэшируемость ответов сервера с кодом 302 зависит только от значений полей заголовка Cache-Control или Expires. В тех случаях, когда клиент использовал запрос с методом отличным от GET или HEAD, браузер спрашивает у пользователя, что делать дальше: переходить по новому URI или не надо.
HTTP код состояния 303: смотреть другой ресурс. HTTP код состояния 304: ресурс не модифицирован. HTTP код состояния 305: использовать прокси сервер. HTTP код состояния 307: временное перенаправление
HTTP код состояния 303 или код состояния смотреть другой ресурс. Если клиент получает ответ с кодом 303, то это означает, что ответ на его запрос может быть найден по другому URI и его можно запросить при помощи метода GET. Чаще всего ответы с кодом состояния 303 используются, чтобы вывести информацию из формы. Ответы сервера с кодом 303 не кэшируются.
HTTP код состояния 304 или код состояния ресурс не модифицирован. Клиент получает ответ от HTTP сервера с кодом 304 в том случае, когда посылался запрос с условным методом GET, но никаких изменений в документе не произошло. При этом HTTP сообщение от сервера не должно содержать тела. Ответ сервера всегда содержит следующие поля заголовков:
- Date;
- ETag или Content-Location;
- Expires, Cache-Control или
Ответы сервера с кодом 304 всегда завершаются пустой строкой после полей заголовка.
HTTP код состояния 305. Код состояния 305 говорит браузеру о том, что ему нужно обратиться к ресурсу, используя прокси-сервер. Прокси-сервер в сообщениях с кодом состояния 305 указывается в поле Location. При этом HTTP сервер ожидает, что клиент повторит запрос, но уже через прокси сервер и даже при необходимости пройдет аутентификацию на прокси сервере.
HTTP код состояния 306 использовался в старых версиях протокола HTTP, но теперь является просто зарезервированным.
HTTP код состояния 307 аналогичен коду состояния 302.
Настраивая HTTP сервер не забывайте про особенности HTTP соединения и помните, что код состояния — это параметр HTTP. Мы рассмотрели коды перенаправления HTTP, давайте перейдем к кодам ошибок клиента. В HTTP есть еще: информационные коды, успешные коды, коды ошибок клиента и коды ошибок сервера. А если тебе нужна информацию обо всех кодах состояния, обратись к справочнику HTTP кодов состояния, в котором есть полное описание всех кодов.
<?php // Полная загрузка сервисных книжек, создан 2023-01-05 12:44:55
global $wpdb2;
global $failure;
global $file_hist;
///// echo '<H2><b>Старт загрузки</b></H2><br>';
$failure=FALSE;
//подключаемся к базе
$wpdb2 = include_once 'connection.php'; ; // подключаемся к MySQL
// если не удалось подключиться, и нужно оборвать PHP с сообщением об этой ошибке
if (!empty($wpdb2->error))
{
///// echo '<H2><b>Ошибка подключения к БД, завершение.</b></H2><br>';
$failure=TRUE;
wp_die( $wpdb2->error );
}
$m_size_file=0;
$m_mtime_file=0;
$m_comment='';
/////проверка существования файлов выгрузки из 1С
////файл выгрузки сервисных книжек
$file_hist = ABSPATH.'/_1c_alfa_exchange/AA_hist.csv';
if (!file_exists($file_hist))
{
///// echo '<H2><b>Файл обмена с сервисными книжками не существует.</b></H2><br>';
$m_comment='Файл обмена с сервисными книжками не существует';
$failure=TRUE;
}
/////инициируем таблицу лога
/////если не существует файла то возврат и ничего не делаем
if ($failure){
///включает защиту от SQL инъекций и данные можно передавать как есть, например: $_GET['foo']
///// echo '<H2><b>Попытка вставить запись в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>$m_comment));
wp_die();
///// echo '<H2><b>Возврат в начало.</b></H2><br>';
return $failure;
}
/////проверка лога загрузки, что бы не загружать тоже самое
$masiv_data_file=stat($file_hist); ////передаем в массив свойство файла
$m_size_file=$masiv_data_file[7]; ////получаем размер файла
$m_mtime_file=$masiv_data_file[9]; ////получаем дату модификации файла
////создаем запрос на получение последней удачной загрузки
////выбираем по штампу времени создания (редактирования) файла загрузки AA_hist.csv, $m_mtime_file
///// echo '<H2><b>Размер файла: '.$m_size_file.'</b></H2><br>';
///// echo '<H2><b>Штамп времени файла: '.$m_mtime_file.'</b></H2><br>';
///// echo '<H2><b>Формирование запроса на выборку из лога</b></H2><br>';
////препарируем запрос
$text_zaprosa=$wpdb2->prepare("SELECT * FROM `vin_logs` WHERE `last_mtime_upload` = %s", $m_mtime_file);
$results=$wpdb2->get_results($text_zaprosa);
if ($results)
{ foreach ( $results as $r)
{
////если штамп времени и размер файла совпадают, возврат
if (($r->last_mtime_upload==$m_mtime_file) && ($r->last_size_upload==$m_size_file))
{////echo '<H2><b>Возврат в начало, т.к. найдена запись в логе.</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>'Загрузка отменена, новых данных нет, т.к. найдена запись в логе.'));
wp_die();
return $failure;
}
}
}
////если данные новые, пишем в лог запись о начале загрузки
/////echo '<H2><b>Попытка вставить запись о начале загрузки в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>0, 'last_size_upload'=>$m_size_file, 'comment'=>'Начало загрузки'));
////очищаем таблицу
$clear_tbl_zap=$wpdb2->prepare("TRUNCATE TABLE %s", 'vin_history');
$clear_tbl_zap_repl=str_replace("'","`",$clear_tbl_zap);
$results=$wpdb2->query($clear_tbl_zap_repl);
///// echo '<H2><b>Очистка таблицы сервисных книжек</b></H2><br>';
if (empty($results))
{
///// echo '<H2><b>Ошибка очистки таблицы книжек, завершение.</b></H2><br>';
//// если очистка не удалась, возврат
$failure=TRUE;
wp_die();
return $failure;
}
////загружаем данные
$table='vin_history'; // Имя таблицы для импорта
//$file_hist Имя CSV файла, откуда берется информация // (путь от корня web-сервера)
$delim=';'; // Разделитель полей в CSV файле
$enclosed='"'; // Кавычки для содержимого полей
$escaped='
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
25 Comments
-
Веб-сервисы как средство интерграции 1С со сторонними АИС, фактически API двусторонний доступ очень полезная технология. Начинает применяться довольно широко. Поставлю плюс.
Скоро поди ее в 1С прикрутят на некоторые «справочные» обмены с сайтами. Как-то делал обработку для загрузки курсов валют с сайта Сбербанка чтоб проверить данный механизм.
Reply ↓
-
Статья понравилась. Сейчас в 1С Веб-сервисы реально позволяют очень много — начиная от отслеживания курсов , движения посылок , состояний заказов, обменов с интернет-магазином и заканчивая мобильной платформой. Автору плюс.
Reply ↓
-
Хотелось бы поподробнее почитать про «ПРИМЕР ОБРАЩЕНИЯ К WEB-СЕРВИСУ В СИСТЕМЕ «1С:ПРЕДПРИЯТИЕ»» если веб-сервис использует проверку подлинности на основе сертификатов. И может ли вообще 1С работать с веб-сервисами с аутентификацией по сертификаиам.
Reply ↓
-
Автор на мой скромный взляд прогресивно так что просто не слов. Ето все равно что связать не связуемое. Побольше бы таких статей.Ето приводит к размышлению и развитию.Спасибо так держать.
Reply ↓
-
(4) dyak84, верно говорите. Стоит большое внимание на веб-сервисы обратить. Жаль только что обращаешь «усердное» внимание когда уже есть реальная задача 🙂
Reply ↓
-
Веб—сервисы — это уже прошлый век, всем пора переходить на http-сервисы, вот где круто, а веб-сервисы были актуальны лет 5 назад, так что давайте еще одну статью по http сервисам 🙂
Reply ↓
-
Статья понравилась, очень подробно и доходчиво.
Только непонятно, а где мы берем WSDL-файл для его загрузки в Delphi?
Reply ↓
-
Вы какую версию Delphi использовали ?
Reply ↓
-
(8) ira778899, Delphi XE7
Reply ↓
-
Большое спасибо за статью, предоставлена полная информация для «попробовать». Попробовал и почему-то не заработало. Сервис опубликовал на локальном Apache 2.2. При попытке обратиться к нему из 1С доходит до создания WSПрокси, но вылетает в исключение при попытке обратиться к методу. Пробовал добавить ws-ссылку, метод виден, но вызвать его все равно нет возможности. В какую сторону копать?
Reply ↓
-
Спасибо за статью.
Мы начали первые шаги в этом направлении:
1)создали свой веб-сервис как в статье с одной операцией (тестовая) пока простая без параметров
Функция proc_oper_try_4()
Возврат Истина;
КонецФункции
2)успешно выполнили публикацию,
3) разработала тестового простого клиента в Delphi 7, выполнив все как в статье, выполнила импорт WSDL-файла, все отлично создался модуль, далее прописала вызов метода.
Но при проверки работы клиентского приложения при вызове функции сервиса получаю ошибку вида «Received content of invalid Content-Type setting: text/html- SOAP expects «text/xml»
Подскажите пожалуйста, что необходимо подправить для успешного вызова метода? в каком направлении копать?
Reply ↓
-
Ребята, а не опишите ситуацию когда 1с использует внешний веб сервис по HTTPS с сертификатам безопасности. Как такой сертификат использовать?
Т.е. необходима обработка, которую можно было отослать внешнему клиенту бухгалтеру(у которого нет админских прав), и чтоб обработка работала именно по защищенному каналу.
Reply ↓
-
Спасибо! В WSОпределении немного изменил и тогда заработало:
Процедура ПолучитьДанныеНаСервере(Клиент) Определение = Новый WSОпределения(«http://localhost/Ist/ws/DocumentsData?wsdl»,»Admin»,»»); Прокси = Новый WSПрокси(Определение, «http://localhost/request», «DocumentsData», «DocumentsDataSoap»); Прокси.Пользователь = «Admin»; Прокси.Пароль = «»;
И в В default.vrd ничего не надо добавлять если при публикации указать. 1С 8.3.8.1652:
Reply ↓
-
Статья полезная, особенно при начале работы с Web-сервисами. Есть один вопрос — как задать для вызова свойство Web-сервиса с несколькими параметрами, если описывается тип только одного параметра?
Reply ↓
-
(14) rwn_driver, Указываешь при описание несколько параметров и вперед, а лучше указываешь только один параметр, но тип структура и все
Reply ↓
-
А как заполнить список в WS? Например есть документ (заявка) и в нем ТЧ товары.
Reply ↓
-
А можно ли выкладывать не через локальный?
Допустим есть домен и виртуальный сервер от хостера.
Reply ↓
-
Очень полезный материал!
Один вопрос.
Шаг 8. Опубликуем созданный Web-сервис на веб-сервере.
А как опубликовать, если на сервере нет графического интерфейса (linux) ? Сама база опубликована и в команде публикации базы — нет параметра про публикацию сервиса.
С другого компьютера, когда в конфигураторе — не публикует, пишет «Веб-серверы не обнаружены».
Reply ↓
-
А что это может значить?
Если имя совсем неправильное написать — то пишет Сервис не найден.
А так вроде что-то отвечает, но пустая страница. При просмотре — вот такое:
<?xml version=»1.0″ encoding=»UTF-8″?><?xml-stylesheet type=»text/xsl» href=»/redirect.php?url=aHR0cDovLzFjLWxpbnV4L0Jhc2ExL2UxY3N5cy92cnNjb3JlL2V4Y2VwdGlvbi54c2x0P3N5c3Zlcj04LjMuMTAuMjI5OQ==»?><exception xmlns=»http://v8.1c.ru/8.2/virtual-resource-system» xmlns:xs=»http://www.w3.org/2001/XMLSchema» xmlns:xsi=»http://www.w3.org/2001/XMLSchema-instance» xsi:type=»Exception» clsid=»580392e6-ba49-4280-ac67-fcd6f2180121″ reason=»400″><descr xmlns=»http://v8.1c.ru/8.1/data/core»>Не указан заголовок управления сеансами или куки с идентификатором сеанса.</descr></exception>
Reply ↓
-
ошибка возникает в коде
Определение = Новый WSОпределения(«http://localhost/zerkal/ws/***.1cws?wsdl»)
Reply ↓
-
(20)Удалось решить проблему? Я никак не пойму что делать. День потерял и ничего.
Reply ↓
-
(20) Для начала вставьте wsdl-ссылку в браузер и посмотрите, что у Вас выдает
Reply ↓
-
Шаг 1. Положить на клиент, где запускается система 1С файлик webservicecfg.xml со следующим содержимом
Куда именно?
Reply ↓
-
-
Мне показалось, что использование HTTP-сервисов намного проще. Подскажите преимущества WS.
Ещё. Понимаю, что SOAP — это некий универсальный протокол, однако JSON намного проще. В 1С с ним работать тоже проще. Трафик меньше, наглядности в просмотре тоже больше из-за отсутствия «лишнего».
Reply ↓
Leave a Comment
Ваш адрес email не будет опубликован. Обязательные поля помечены *
Сообщение с кодом 301 Redirect сервер возвращает в том случае,
если пользователь либо поисковый робот перенаправляется на URL,
отличающийся от того, на который совершается переход.
О чем свидетельствует код 301
Эта ошибка указывает на то, что старый адрес утратил свою актуальность, и что содержимое,
расположенное по этому адресу, перемещено на другой.
Для поисковых систем это сообщение приводит к автоматической переиндексации,
вследствие чего они начнут перенаправлять пользователей на новый адрес.
Код 301 не является ошибкой, это сервисное сообщение,
которое используется администратором ресурса для настройки переадресации.
Это важно для сохранения рейтинга страницы, адрес которой изменяется, в поисковых системах.
Индексация страницы по новому адресу при использовании редиректа будет происходить точно так же,
как и старой, и раскручивать новый адрес в поиске не понадобится.
Что делать пользователю, когда в браузере появляется код ошибки 301
Поскольку настройка редиректа всегда зависит только от администратора ресурса или хостинг-провайдера,
пользователю не следует ничего предпринимать в том случае,
если сервер перенаправил его на требуемую страницу.
В случае, если перенаправление привело на другую страницу либо возвратило ошибку с любым другим кодом,
например, 404 Page not found, следует сообщить об этом администратору ресурса или
провайдеру услуг хостинга.
Причины возникновения кода 301 redirect
Этот код не сигнализирует об ошибке, он является сервисным сообщением,
которое используют системные администраторы для самых разных задач:
- сохранение «пользовательских сигналов» контента, размещенного на странице;
- сохранение и передача накопленной ссылочной массы на другой адрес;
- перемещение страниц;
- удаление повторяющихся страниц, склейка;
- ребрендинг сайта;
- смена доменного имени;
- управление трафиком – перенаправление на нужный адрес.
Появление сообщения с кодом 301 Redirect сигнализирует о том,
что владелец ресурса настроил переадресацию.
Если все сделано правильно, пользователь будет перенаправлен на искомую страницу.
Здравствуйте, уважаемые читатели блога KtoNaNovenkogo.ru. Чуть ранее мы успели с вами поговорить о зеркалах, дублях страниц и их удалении.
Давайте сегодня продолжим тему и посмотрим каким образом поисковые роботы взаимодействую с нашими сайтами, чтобы понять, на какие вещи нужно обязательно обращать внимание и, в случае обнаружения ошибок, обязательно исправлять.
Казалось бы, что язык Http запросов и ответов сервера (сервер — это ПО на хостинге) настолько далек от SEO, что тратить время на понимание его принципов будет чудовищным расточительством. Однако, это не так.
Многие вещи, не заметные при беглом взгляде через браузер, могут оказывать колоссальное влияние на продвижение вашего сайта (вплоть до его полного выпадания из индекса). Увидеть все эти недочеты можно, только поняв, где и что именно нужно смотреть.
Что такое http и где посмотреть ответ сервера
HTTP (англ. HyperText Transfer Protocol — «протокол передачи гипертекста») — протокол прикладного уровня передачи данных, изначально — в виде гипертекстовых документов в формате HTML, в настоящее время используется для передачи произвольных данных.
Итак, при запросе браузером пользователя какой-либо страницы вашего сайта вместе с Html кодом этой вебстраницы, обозревателю будет передан и так называемый Http заголовок с ответом хоста, в котором помимо прочей информации будет указан код. Он представляет из себя трехзначное число (наиболее часто встречаются варианты 200, 301, 302, 404), которое обозначает ситуацию, сложившуюся на хосте при обработке запроса браузера.
Что такое HTTP? Это протокол, по которому осуществляется обмен данными между вебсервером, на котором расположен интересующий вас сайт, и вашим браузером. Расшифровывается аббревиатура как Hypertext Transfer Protocol. Браузер пользователя обращается к серверу с запросом какого-либо документа и получает соответствующий ответ.
Если ответ на http запрос приходит положительный (200 OK), то браузер начинает загрузку нужного ему файла. Если отрицательный, то информирует об этом пользователя. Имеется еще и шифрованный протокол SHTTP, но сути дела это не меняет.
Например, при успешной загрузке страницы, в браузер будет передан Http заголовок с кодом 200 OK (кроме цифр еще приводится и поясняющая надпись). В случае, если запрошенная страница на сервере найдена не будет, то браузер получит ответ 404 Not Found. Можете сами проверить ответ главной страницы своего сайта, например, на этом сервисе.
К примеру, введя туда заведомо несуществующий адрес страницы своего ресурса (для этого после доменного имени можно написать любую ахинею, например, https://ktonanovenkogo.ru/трали-вали), будет получен примерно такой Http заголовок:
HTTP/1.1 404 Not Found Server: nginx/0.6.32 Date: Wed, 09 Mar 2011 14:52:43 GMT Content-Type: text/html; charset=UTF-8 Transfer-Encoding: chunked Connection: keep-alive X-Powered-By: PHP/5.2.17 X-Pingback: https://ktonanovenkogo.ru/xmlrpc.php Expires: Wed, 11 Jan 1984 05:00:00 GMT Cache-Control: no-cache, must-revalidate, max-age=0 Pragma: no-cache Last-Modified: Wed, 09 Mar 2011 14:52:43 GMT Vary: Accept-Encoding
И это хорошо, ибо поисковые системы правильно обработают данный ответ сервера и не будут добавлять в индекс вашу несуществующую вебстраницу (404 страница для Joomla, 404 Not Found для Вордпресса).
Причем стоит учитывать, что несуществующие документы могут появиться как по вашей вине, так и из-за ошибки какого-либо доброжелателя, разместившего где-нибудь обратную ссылку на ваш сайт с ошибкой. Посмотреть те несуществующие документы (фактически битые ссылки), которые имеются на вашем ресурсе, вы можете в Яндекс Вебмастере или панели Google, как это было описано в статье Проверка битых ссылок.
Гораздо хуже будет, если несуществующий документ не будет выдавать в ответ 404, ибо в этом случае на вашем сайте по разным адресам (URL) несуществующих страниц (а их может быть сколь угодно много) будет выдаваться одна и так же вебстраница ошибки 404. На лицо будет откровенное дублирование контента, которое может повлечь за собой санкции со стороны поисковиков. А оно вам надо — на ровном месте наступать на грабли.
В принципе, еще хуже ситуация может сложиться, если вместо того, чтобы создать отдельную вебстраницу 404 для своего ресурса, вы настроили переброс посетителей на главную, в случае отсутствия запрашиваемого документа на сервере. Поисковые системы, не получив кода 404, вынуждены будут проиндексировать все эти не найденные страницы, а фактически содержимое главной.
Получится совсем неприятная картина — главная будет доступна сразу по неограниченному множеству адресов, ибо при запросе или переходе по битой ссылке будет открываться все время она. Выпадение из индекса главной из-за дублирования контента может нанести очень существенный урон всему продвижению сайта, ибо она, как правило, имеет наибольший статический вес и именно на нее будет приходиться львиная доля всех обратных внешних ссылок.
Обязательно проверьте коды ответа хотя бы у некоторых вебстраниц вашего ресурса, и особенно проверьте правильность цифр, выдаваемых в ответ на запрос несуществующего документа (введите что-то типа http://vash-domen.ru/jhguytrhkfkfijd). Для этой цели можно воспользоваться приведенным выше онлайн сервисом или же рядом других, способных показать все это:
Чтобы быть абсолютно уверенным в том, что поисковики правильно интерпретируют коды ответа вашего хоста, можете воспользоваться инструментом Яндекса Проверка ответа сервера, который, правда, будет вам доступен только после регистрации в Вебмастере, но добавиться туда, так же как и в панель Гугла, нужно будет в любом случае.
Все возможные варианты кодов ответа сервера
Обращу ваше внимание еще и на ответ сервера 301, который появляется в случае использования редиректа (перенаправление навсегда). Дело в том, что поисковые системы рекомендуют использовать 301 редирект в случае изменения адреса (URL) страницы сайта (он будет перебрасывать посетителя со старого Урла на новый) или, например, при склейке зеркал сайта с WWW или без WWW, как это было описано тут.
Если вы использовали 301 редирект, то можете проверить правильность Http ответа при обращении к склеенным Урлам. Например, при запросе www.ktonanovenkogo.ru сервер дает правильный ответ 301 Moved Permanently:
Вспомнил, что по поводу 404 ошибки я слышал довольно интересную историю. Вебмастер или оптимизатор, ведущий раскрутку определенного проекта, получил отставку и был этим сильно раздосадован. Причем, настолько сильно, что решился на то, чтобы подложить бывшему работодателю большую и жирную свинью.
Но сделал он все очень грамотно, ибо поначалу новые оптимизаторы, занимающиеся продвижением этого проекта, никак не могли понять, отчего позиции сайта резко просели. Как это реализовать на практике я не знаю, но тот вебмастер сделал так, что все страницы успешно открывались и отлично работали, но при этом в Http заголовке для всех них сервер давал ответ 404 Not Found.
Пустяк, вроде бы, абсолютно не влияющий на корректную работу ресурса, но напрочь убивающий все усилия по продвижению этого проекта. На этом примере, наверное, еще более наглядно можно увидеть важность проверки кодов ответа.
Правда в случае обнаружения неправильно формируемых кодов вам, скорее всего, придется обращаться за помощью к владельцу хостинга, в случае виртуального хоста, или же придется решать проблему самим, в случае выделенного сервера. Но главное, это вовремя диагностировать и локализовать проблему, воспользовавшись для этого соответствующими сервисами, некоторые из которых я упомянул чуть выше.
Вообще, все коды ответа сервера можно разделить на пять групп:
- 100-199 являются информационными, говорящими о том, что сервер обрабатывает запрос
- 200-299 означают, что запрашиваемые у сервера данные были успешно переданы (например, 200 — запрос был успешно выполнен и требуемые данные переданы)
-
300-399 означают переадресацию и необходимость выполнить дополнительные действия (например,301 — грубо говоря, документ изменил адрес навсегда; 302 — документ изменил адрес временно)
Код Ошибка Описание 300 Множественный выбор Затребованный URL обозначает более одного ресурса, и робот не смог однозначно определить, к какой странице URL относится (получен код
300 Multiple Choices).Исправьте заголовки или укажите ресурс правильно, и тогда робот сможет проиндексировать страницу.
301 Ресурс перемещен навсегда Документ уже не используется сервером, а ссылка перенаправляет на другую страницу (получен код
301 Moved Permanently).Так как пользователи не смогут увидеть подобные документы, показывать их в поиске не имеет смысла, и робот их не индексирует. Однако робот проиндексирует страницу, на которую установлено перенаправление, если она доступна.
302 Ресурс временно перемещен Запрошенный ресурс временно находится под другим адресом (получен код
302 Found).Так как пользователи не смогут увидеть подобные документы, показывать их в поиске не имеет смысла, и робот их не индексирует. Однако робот проиндексирует страницу, на которую установлено перенаправление, если она доступна.
303 Смотрите другой ресурс Запрошенный ресурс находится под другим адресом и его следует запрашивать, используя метод
GET(получен код303 See Other). Если вы хотите, чтобы указанная страница находилась в поиске, она должна отвечать кодом 200.304 Ресурс не изменялся Получен код
304 Not Modified. Если страница не изменилась с момента последнего обращения робота, рекомендуется выдавать этот код. Это ускорит индексирование и уменьшит трафик.305 Следует использовать прокси Доступ к затребованному ресурсу может осуществляться только через прокси-сервер, указанный в заголовке
Location(получен код305 Use Proxy).307 Временное перенаправление Затребованный ресурс был временно переведен на другой адрес, который необходимо прописать в
Location(получен код307 Temporary Redirect). - 400-499 означают, что запрос был сформирован не правильно и выполнен быть не может (например, 404 — документ по указанному адресу не найден на хосте)
Код Ошибка Описание 400 Неверный запрос/Bad Request Запрос не может быть понят сервером из-за некорректного синтаксиса.
401 Неавторизованный запрос/Unauthorized Для доступа к документу необходимо вводить пароль или быть зарегистрированным пользователем.
402 Необходима оплата за запрос/Payment Required Внутренняя ошибка или ошибка конфигурации сервера.
403 Доступ к ресурсу запрещен/Forbidden Доступ к документу запрещен. Если вы хотите, чтобы страница индексировалась, необходимо разрешить доступ к ней.
404 Ресурс не найден/Not Found Документ не существует. Если вы удалили какой-то раздел сайта, можно с помощью robots.txt запретить роботу обращаться к нему. Если такой страницы на сайте никогда не существовало, игнорируйте эту ошибку, возможно, кто-то поставил некорректную ссылку на ваш сайт.
405 Недопустимый метод/Method Not Allowed Метод, определенный в строке запроса (Request-Line), не дозволено применять для указанного ресурса, поэтому робот не смог его проиндексировать.
406 Неприемлемый запрос/Not Acceptable Нужный документ существует, но не в том формате (язык или кодировка не поддерживаются роботом).
407 Требуется идентификация прокси, файервола/Proxy Authentication Required Необходима регистрация на прокси-сервере.
408 Время запроса истекло/Request Timeout Сайт не передал полный запрос в течение установленного времени и робот разорвал соединение.
409 Конфликт/Conflict Запрос конфликтует с другим запросом или с конфигурацией сервера.
410 Ресурс недоступен/Gone Затребованный ресурс был окончательно удален с сайта.
411 Необходимо указать длину/Length Required Сервер отказывается принимать запрос без определенного заголовка Content-Length. Поправьте заголовки на своем сервере;— тогда в следующий раз робот сможет проиндексировать страницу.
412 Сбой при обработке предварительного условия/Precondition Failed При проверке на сервере одного или более полей заголовка запроса обнаружено несоответствие (сбой или ошибка при обработке предварительного условия).
413 Тело запроса превышает допустимый размер/Request Entity Too Large Сервер отказывается обрабатывать запрос потому, что размер запроса больше того, что может обработать сервер.
414 Недопустимая длина URI запроса/Request-URI Too Long Сервер отказывается обслуживать запрос, потому что запрашиваемый роботом URI (Request-URI) длиннее, чем сервер может интерпретировать.
415 Неподдерживаемый MIME тип/Unsupported Media Type Сервер отказывается обрабатывать запрос, потому что тело запроса имеет неподдерживаемый формат.
416 Диапазон не может быть обработан/Requested Range Not Satisfiable Сервер отказывается обрабатывать запрос, потому что значение поля Range в заголовке запроса указывает на недопустимый диапазон байтов.
417 Сбой при ожидании/Expectation Failed Сервер отказывается обрабатывать запрос, потому что значение поля
Expectв заголовке запроса не соответствует ожиданиям.422 Необрабатываемый элемент/Unprocessable Entity Сервер не в состоянии обработать один (или более) элемент запроса.
423 Заблокировано/Locked Сервер отказывается обработать запрос, так как один из требуемых ресурсов заблокирован.
424 Неверная зависимость/Failed Dependency Сервер отказывается обработать запрос, так как один из зависимых ресурсов заблокирован.
426 Требуется обновление/Upgrade Required Сервер запросил апгрейд соединения до SSL, но SSL не поддерживается клиентом.
429 Слишком много запросов/Too Many Requests Отправлено слишком много запросов за короткое время. Это может указывать, например, на попытку DDoS-атаки. Ответ может сопровождаться заголовком Retry-After, который указывает, через какое время можно повторить запрос. Яндекс не учитывает этот заголовок.
- 500-599 означают, что на сервере произошла ошибка и запрос выполнен быть не может. Посмотрите, например, что означает ошибка 502.
Код Ошибка Описание 500 Внутренняя ошибка сервера/Internal Server Error Сервер столкнулся с непредвиденным условием, которое не позволяет ему выполнить запрос.
501 Метод не поддерживается/Not Implemented Сервер не поддерживает функциональные возможности, требуемые для выполнения запроса. Этот ответ соответствует состоянию, когда сервер не распознает метод запроса и не способен обеспечить его для любого ресурса.
502 Ошибка шлюза/Bad Gateway Сервер, действуя в качестве шлюза или прокси-сервера, получил недопустимый ответ от следующего сервера в цепочке запросов, к которому обратился при попытке выполнить запрос.
503 Служба недоступна/Service Unavailable Возникла ошибка из-за временной перегрузки или отключения на техническое обслуживание сервера.
504 Время прохождения через межсетевой шлюз истекло/Gateway Timeout Сервер, при работе в качестве внешнего шлюза или прокси-сервера, своевременно не получил отклик от вышестоящего сервера, к которому он обратился, пытаясь выполнить запрос.
505 Версия НТТР не поддерживается/Version Not Supported Сервер не поддерживает или отказывается поддерживать версию HTTP-протокола, которая используется в сообщении запроса робота.
507 Недостаточно места/Not Extended Сервер не может обработать запрос из-за недостатка места на диске).
510 Отсутствуют расширения/Not Extended Сервер не может обработать запрос из-за того, что запрашиваемое расширение не поддерживается.
Более подробно посмотреть все возможные коды ответа в Http заголовке вы можете, например, в Википедии.
Http запросы — как поисковый робот общается с сервером
Теперь для продолжения разговора на тему, нам нужно будет посмотреть в стороны работы браузеров. Я уже довольно подробно писал, что такое браузер, но если говорить кратко, то это программа для просмотра Html страниц, загруженных из интернета. Но нас сейчас интересует конкретный вопрос: как происходит взаимодействие браузера и сайта?
Браузер (поисковый бот) и сервер общаются по протоколу Http
После того, как вы ввели Урл в адресную строку браузера (или, что то же самое, перешли по ссылке, или открыли закладку), он обращается к упомянутому выше DNS серверу (ближайшему), чтобы тот сообщил браузеру IP адрес, соответствующий введенному доменному имени сайта.
Правда, браузер сначала к файлу Hosts обращается и в свой ДНС кеш заглядывает, но если там ничего по данному домену не находит, то начинает ломиться в ближайший ДНС сервер (обычно он находится у вашего интернет-провайдера).
В DNS серверах хранятся таблицы соответствия доменов и соответствующих им IP адресов серверов (компьютеров, всегда подключенных к интернету), где физически размещаются файлы сайтов. Получив искомый IP адрес, браузер делает HTTP запрос к серверу с этим адресом.
Для передачи данных в таком запросе могут использоваться два метода: Get или Post. В обычных случаях используется Get, и если утрировать, то для нашего примера такой запрос может выглядеть так (указывается относительный URL адрес страницы — относительно корня сервера):
Get /papka/fail.html HTTP/1.1
Этот запрос уходит на IP адрес, полученный ранее от ДНС сервера. На сервере же установлено программное обеспечение (чаще всего Апач), которое, получив такой запрос, находит нужный файл по указанному относительному пути и отправляет его (в виде Html кода) обратно в браузер.
Браузер же, в свою очередь, этот Html код интерпретирует в веб-страницу с учетом CSS стилей, которые могли быть заданы как в самом Html коде, так и во внешнем файле стилей, который тоже будет подгружен.
А как происходит взаимодействие поискового робота с сайтом? По сути, точно так же. Робот отправляет запрос на ДНС сервер и получив IP отправляет Get запрос с указанием относительного пути до нужного ему файлика вебстраниц. Сервер запрос обрабатывает, находит файлик и отправляет ее в Html виде поисковому роботу.
Т.е. отличий фактически нет, ибо поисковый робот — это тот же самый браузер, у которого за ненадобностью отсутствует графический интерфейс (Html страницы он просто загружает, но не открывает). Кроме этого, бот не выполняет Джава-скрипты и не загружает картинки (их индексацией занимается специальных бот). Но это уже детали.
Следовательно, разобравшись в методах общения браузера с сервером, мы поймем, как поисковый робот общается с нашим сайтом и какие проблемы на этом уровне могут возникать, вызывая серьезные препоны успешному продвижению.
Почему так важно проверять HTTP заголовки запросов к вашему сайту
Посмотреть HTTP заголовок можно разными способами. Например, я использую расширение для браузера Хром под названием HTTP Headers, но подобных аналогов море.
Браузер формирует HTTP запрос типа Get, где указывается относительный путь до вебстраницы и версия данного протокола, по которой готов работать браузер (обычно это 1.1):
Get /papka/fail.html HTTP/1.1
Вот такой вот заголовок формируется браузером (он в верхней половине скриншота) при переходе на страницу моего сайта из поисковой выдачи Яндекса:
Из него можно, например, узнать, откуда был совершен переход на запрашиваемую страницу (с помощью содержащийся в поле Referer информации). Также обратите внимание на поле User Agent. Каждый браузер и каждый поисковых имеет свой собственный User Agent, по которому его можно идентифицировать на сервере.
Юзер агенты браузеров довольно-таки длинные (там вначале идут перечисления всякой всячины, а непосредственно название обозревателя идет в самом конце), а вот у ботов они состоят из одного или нескольких слов.
Правильные ответы сервера на Http запросы — залог успешного SEO
В нижней части скриншота показан ответ сервера на HTTP запрос браузера. Именно на основании ответа сервера поисковый робот либо будет любить эту страницу, либо будет ее игнорить. На приведенном скриншоте начальная (самая важная) строка ответа сервера показана вверху под началом запроса браузера и выглядит так:
HTTP/1.1 200 ОК
В этом ответе указывается протокол, который запросил поисковый робот (либо браузер), а дальше идет уже непосредственно код ответа сервера. Если вы помните, то про Http коды ответа я уже писал, но здесь все же повторюсь, чтобы не создавать вам неудобства. Именно этот код ответа сервера определяет дальнейшие действия робота-индексатора с этой страницей вашего сайта.
Кроме кода, в ответе сервера можно найти и еще ряд полезной информации. Например, название программного обеспечения (в поле Server), на котором этот сервер работает (чаще всего встречается Апач, nginx или майкрософт). Тип контента (Content-Type) тоже очень важен для поискового робота, ибо он индексирует не все.
Также очень важным является поле Last-Modified. Плагин HTTP Headers его не показывает, но вы можете ввести Урл страницы в этот сервис и узнать значение Last-Modified для интересующей вас страницы любого сайта (чаще всего нужна информация именно по своему ресурсу).
Ориентируясь на него, поисковый робот может понять, появилось ли на этой странице что-то новое, что имело бы смысл ее переиндексировать, или все осталось по-старому с момента его предыдущего захода.
Заголовок ответа сервера содержит еще ряд полей, после чего следует уже непосредственно Html код вебстраницы, которую и должен будет сохранить робот в случае получения правильного кода ответа (200) или в случае новой даты в поле Last-Modified для ранее проиндексированной страницы.
Http коды ответа сервера и их влияние на SEO продвижение
Основная задача вебмастера (и оптимизатора тоже) заключается в том, чтобы в этом заголовке сервера не было бы чего-то такого, что отвратит от нее поискового бота. Ему не важно, как выглядит страница и что на ней содержится самый важный в мире контент.
Если ответ сервера будет неправильным, то бот развернется и пойдет дальше по своим делам, оставив вашу страницу или весь ресурс не проиндексированным.
А какой ответ считать правильными и какие варианты вообще возможны? Давайте крупными мазками рассмотрим возможные варианты.
Коды ответа делятся по сотням, то есть, допустим, к четырехсотым ошибкам относятся 401, 402, 403. Вкратце это будет выглядеть так:
- Коды с двухсотыми ответами (чаще всего встречается 200 ОК) — все что запросил браузер (или поисковый бот) на сервере имеется и нет никаких преград, чтобы это было отдано (веб-страница в виде Html кода).
- Трехсотые коды ответа сервера — документ по запрошенному адресу временно (302 редирект) или постоянно (301 редирект) перемещен. Сервер сообщает роботу новый адрес веб-страницы, а тот в свою очередь по нему переходит.
- Четырехсотые ответы — ошибка в запросе, сделанном поисковым роботом или браузером (по мнению сервера, ибо своей вины он в этом не видит). Например, пытаются получить доступ к закрытой информации без авторизации (401) или к странице, доступ к которой для данного пользователя запрещен (403). Ну и, конечно же, знаменитая ошибка 404 (страница не найдена на сервере), про которую я в свое время даже отдельную стать написал.
- Пятисотые ответы — сервер признается (посыпая голову пеплом), что виноват в сложившейся нехорошей ситуации он сам (ошибки на стороне сервера). Он может быть перегружен в данный момент из-за высокого наплыва посетителей или в результате Ддос атаки (мне пришлось для защиты от Ddos подключить сайт к CloudFlare). Также он может зависнуть, либо не иметь возможности осуществить запросы к базе данных, ну и еще несколько наиболее частых причин могут вызвать его недоступность.
Наша задача, как вебмастеров и оптимизаторов, состоит в том, чтобы все продвигаемые страницы отдавали бы правильные коды ответа сервера (200 или, на худой конец, 301, если страница поменяла свой Урл по каким-либо причинам).
И что не менее важно, все страницы, на которые по каким-либо причинам были проставлены неправильные Урлы (они могут располагаться ведь не только на вашем сайте), отдавали бы код ошибки 404. Если несуществующие веб-страницы будут отдавать код 200, то это может нанести непоправимый урон сайту и продвигать его средствами СЕО будет затруднительно.
В статье про проверку сайта я упоминал набор общедоступных инструментов из арсенала Яндекс Вебмастера. Есть там и сервис «Проверка ответа сервера«. Вставьте в его форму любой Урл с вашего сайта и намеренно его испортите (добавьте в ту часть адреса, что содержится после доменного имени, какую-нибудь околесицу).
Если в ответ вы увидите код ответа 404, то значит ваш сервер правильно обрабатывает не найденные страницы, а если что-то другое, то нужно искать причину неисправности.
Правда, в случае WordPress может выдаваться код 301 редиректа, если вы галиматью введете в ту часть Урла, которая отвечает за рубрику (это такая особенность работы движка, позволяющая перемещать статьи между рубриками, не переживая о ручной простановке 301 редиректа — все делается автоматически самим движком).
Как тупой сервер может запороть ваше умное SEO
Есть еще целый ряд особенностей в общении между сервером и поисковым ботом, которые могут свести на нет все ваши будущие и текущие усилия по продвижению. Вещи эти кажутся пустяковыми и довольно-таки сложно-непонятными, чтобы большинство вебмастеров и оптимизаторов на них сосредотачивалась. Однако, оно того стоит:
- На последнем скриншоте показано поле Content-Type:
Content-Type: text/html;charset=UTF-8
Оно говорит от том, что имеющийся на сервере документ представляет из себя Html файл в кодировке русского языка UTF-8. Правильное указание кодировки очень важно, ибо может вызвать как проблему с прочтение материалов сайта пользователями, так и сложности в ее восприятии поисковыми роботами.
Бот просто читает содержимое charset, и если оно по каким-либо причинам будет не соответствовать реально используемой в тексте кодировке, то загруженные кракозябры, естественно, ни в индекс, ни в выдачу не попадут. Что печально, ибо в дальнейшем поисковый робот, скорее всего, уже на эту страницу заходить не будет, ибо там ничего ценного нет.
-
Last-Modified — второй камень преткновения (из сонма http ответов веб-сервера поисковому боту), влияющий на продвижение сайта. В этом поле указывается дата изменения документа (последнего обновления информации на данной веб-странице). Робот обязательно смотри в это поле, ибо у него много работы и отвлекаться на просмотр документа, который не изменился с момента его последнего посещения, было бы глупо.
Поисковый робот делает серверу запрос на загрузку страницы — была ли та изменена за время, прошедшее с его последнего прихода (отправляется в поле if-modified-since с датой последней загрузки документа этим роботом). Сервер сие обращение обрабатывает, и если страница с тех пор была действительно изменена (считывается Last-Modified и сравнивается с датой полученной от робота), то он отдает ее содержимое боту (и код 200 в ответ, естественно). Поисковый индексатор ее переиндексирует и будут учтены все внесенные изменения, например, добавленный контент или ссылки.
В противном случае (когда Last-Modified не менялся) сервер отдает боту только лишь код 304. В этом случае робот со спокойной душой пойдет дальше. Проблема может заключаться в том, что страницу вы могли уже за это время десять раз изменить, но в индексе поисковика она не обновится, ибо не обновлялся Last-Modified для этого файла. CMS (движки сайтов) довольно часто этим грешат, нужно обязательно все это проверять и при необходимости настраивать. Как? Это уже другой вопрос.
Главное, чтобы вы поняли где и что смотреть, чтобы вовремя заметить ошибку (смотрите второй из предыдущих скриншотов). Исправлять ее нужно будет уже исходя из ситуации (типа вашей CMS, типа программного обеспечения сервера и т.п.).
Начать же можно с обращения к хостеру с просьбой помочь (бесплатно или за денежку) в решение проблемы. Для них это, как правило, не проблема. Но вы, во-первых, должны сами понять, что у вас эта проблема есть, а во-вторых, должны доходчиво объяснить ее суть администратору сервера.
301 и 302 редиректы (коды ответа сервера) их использование
Бывает, что по каким-либо причинам вы хотите поменять Урл адрес страницы. Например, как уже упоминал чуть выше, захотите перенести статью из одной рубрики в другую (при определенном алгоритме формирования ЧПУ это может повлечь за собой смену Урла). Причин изменения Урлов может быть масса (хотя бы переход с протокола http на защищенный протокол https).
В не зависимости от причины вам важно, чтобы при переходе по старому Урл адресу пользователь попадал бы на нужную ему веб-страницу, а не любовался вашей расчудесной страницей 404 ошибки.
Какой редирект использовать при смене Урл адреса страницы?
Как это сделать? В общем-то не сложно, но важно, чтобы сервер при этом выдавал правильный код ответа (301). Вариантов кода ответа для редиректа (перенаправления) при этом обычно используется два:
- 301 — документ был перемещен по новому адресу навсегда и в дальнейшем искать его нужно будет только там. В этом случае поисковик в выдаче заменит Урл адрес на новый и лишней переадресации потом происходить уже не будет. Кроме этого, по 301 редиректу передается ссылочный вес (в том числе и Пр), накопленный страницей (правда, не сразу и не факт, что полностью).
- 302 — документ был перемещен временно. В этом случае поисковик не будет заменять Урл в выдаче и переносить веса. Какое-то время назад пользоваться 302 редиректом не советовали, но точных причин этого я уже не помню (может быть вы мне напомните).
Если вы не делаете 301 редирект, а просто меняете Урл страницы, то теряете положение (позицию) в выдаче, ибо старый урл, живущий в индексе поисковика, будет отдавать 404 код ответа, а значит со временем будет удален из индекса.
Новый же Урл должен быть сначала проиндексирован, потом еще вам придется набирать заново ссылочную массу, ждать месяцы, и то не факт, что все вернется туда, где и было. Далеко не факт. Поэтому при смене Урла обязательно делайте 301 редирект со старого Урла на новый и будет вам счастье.
Особенно это важно, когда переходите на новый движок сайта (или переносите разделы), т.е. когда меняются Урлы всех страниц сразу, как, например, при cмене доменного имени или переездt сайта на защищенный протокол Https.
В таких случаях обязательно нужно делать постраничный 301 редирект, иначе потеряете весь трафик на очень продолжительный период времени. Причем даже после восстановления он может вернуться не полностью. А при 301 редиректе, скорее всего, все пройдет «чинно и благородно», т.е. практически незаметно в плане снижения трафика из поисковых систем.
Вся имеющаяся внешняя ссылочная масса постепенно перетечет на новые Урлы. 301 редирект устанавливается на постоянной основе несмотря на то, что в индексе поисковика со временем старых Урлов уже не останется.
Сервера бывают разные и редиректы у них настраиваются по разному
Сервер, по сути, тот же компьютер, только в особом (серверном) исполнении. У него есть материнская плата, жесткие диски, процессор и оперативная память. Разве что только нет персонального монитора. Программное обеспечение на него ставится тоже серверное.
Виндовс на веб-серверах используется не часто, ибо эта ОС стоит денег, в то время как большинство аналогов из мира Линукса бесплатны (Debian, CentOS, Ubuntu и другие) — вот они и получили наибольшую популярность.
Но одной операционной системы для работы сервера не достаточно. В ОС устанавливается специальное программное обеспечение, среди которых основной программой является веб-сервер.
Самой популярной из таких программ является Apache (более трех четвертей серверов с сайтами в интернете работают на ней), ибо она бесплатная, постоянно обновляемая, хорошо оттестированная и имеющая большое количество расширений.
Перед Apache иногда ставят еще и Nginx (как и в случае с этим блогом), который является прокси сервером. Это, кстати, отечественная разработка, постепенно завоевывающая весь мир.
Кроме программы веб-сервера устанавливаются еще и интерпретаторы различных языков серверного программирования. Многие CMS написаны на PHP (Joomla, WordPress) и без интерпретатора этого языка работать не будут, но также имеются и другие.
Ну и, конечно же, базы данных тоже требуются для многих движков. Наиболее распространена MySql, но имеются и другие разновидности, как MSSql, Оракл. Еще что-то может быть установлено для решения специфических задач.
С высокой вероятностью ваш сайт будет работать под управлением веб-сервера Apache, а именно он формирует коды ответа сервера, о которых мы говорили чуть выше.
Особенностью работы с подобными средами является то, что:
- У файлов в вебе нет расширений (об этом мы упоминали при разговоре про зеркала). Все, что пытаются изобразить, добавляя через точку к Урлам страниц (типа .html и т.п.), является просто следованием традициям, а точнее привычкам «чайников», коих в интернете около девяносто процентов (включая меня).
- Второй особенностью серверных программ является способ их управления, который кардинально отличается от того, к чему мы привыкли в Виндовс. Это не какие-то графические меню, а конфигурационные файлы, в которых прописаны определенные параметры и инструкции для исполнения.
htaccess — файл облегчающий управление сервером Apache
У веб-сервера Apache основной конфигурационный файл называется httpd.conf. Однако, если в нем прописана разрешающая директива, то для каждого каталога сайта на вашем сервере можно будет использовать дополнительный файл конфигурации .htaccess.
Возможности у него такие же, как и у httpd.conf, но все прописанные в нем директивы будут применяться только к той папке, в которой он находится.
Однако, если разместите файл .htaccess в корне, то его действие распространится на весь ваш сайт. Этот способ конфигурирования Apache удобен тем, что доступ к .htaccess, лежащему в корне сайта, можно получить по обычному ФТП соединению с помощью любого ФТП клиента. Редактировать же его можно в любом текстовом или Html редакторе (в том числе и в онлайн редакторе).
Если у вас в корневой директории .htaccess нет, то просто создайте у себя на компьютере пустой текстовый файл и сохраните его без расширения и с точкой перед названием htaccess. После этого подключитесь к сайту по ФТП и скопируйте данный пустой файлик в корневую папку. Потом по мере необходимости открывайте его и вносите нужные вам инструкции, которые с превеликим удовольствие выполнит веб-сервер Apache.
Однако, настоятельно рекомендую перед каждой правкой .htaccess сохранять его к себе на компьютер, ибо из-за ошибки во вносимой инструкции может стать недоступным весь сайт. Имея бекап, вы сможете восстановить все как было в считанные секунды. Ну и также советую правку вносить не в обычном блокноте Виндовс, а в редакторе на вроде Notepad++, где есть возможность откатиться назад.
Что же именно можно прописывать в .htaccess? Очень много всего, и для полного и самостоятельного понимания сути вам придется окунуться в мир администрирования серверов и программирования (см. статью про волшебный файл .htaccess). Очень часто в таких записях встречаются так называемые «регулярные выражения», которые позволяют точечно применять прописанные директивы.
Все это нужно знать, чтобы полностью самостоятельно управлять своим веб-сервером для реализации требуемых на сайте функций. Однако, никто вам не мешает пользоваться чужими наработками в огромных количествах наличествующих в сети.
Хорошим примером может служить склейка зеркал через 301 редирект, описанная в статье по приведенной ссылке или же в первой части данной публикации. Также с помощью записей в .htaccess мы:
- Включали Gzip сжатие для ускорения загрузки сайта
- Запрещали хотлинкинг (hotlink) в Apache
- Настраивали корректную работу вашей RSS ленты при трансляции ее через Фидбернер
Настраиваем 301 редирект через файл .htaccess
Напомню, что сегодня мы говорим про ответы сервера и 301 редирект, который является абсолютно необходимой вещью при смены Урла одной страницы или переносе всего сайта на новый домен, переезде на Https или при склейке зеркал. Этот самый редирект чаще всего реализуются именно с помощью файла .htaccess (если сайт работает на сервере Apache. Давайте посмотрим примеры его реализации.
Для перенаправления с одного Урла на другой будет достаточно добавления в .htaccess такой вот строчки:
Redirect 301 /old-page.html http://new-domain.ru/new-page.html
В директиве Redirect обозначения старой страницы (с которой идет переадресация) используется относительный адрес (ибо редирект по-любому будет выполняться на этом сайте), а для нового Урла — абсолютный (ибо можно сделать редирект и на страницу другого сайта). Кстати, вместо директивы Redirect 301 можно использовать RedirectPermanent или Redirect permanent.
Если идет переадресация в пределах одного домена, то можно использовать в обоих случаях относительные адреса. Вот реальный пример из .htaccess, живущего в корневой папке моего блога (между двумя адресами ставится пробел):
Redirect 301 /joomla/joomla-3-professionalnyj-sajt-za-odin-den.html /videokursy
Однако, если вам нужно сделать постраничный редирект (например, для смены расширения страниц сайта с .html на .php или еще что-то, что позволяет не прописывать отдельные строки 310 редиректа для каждой страницы), то гораздо удобнее использовать регулярные выражения. Такой способ называют пакетным редиректом.
Для этого используется уже директива RedirectMatch, в которой допускается использование регулярных выражений. Например, для смены окончаний страниц .html на .php можно использовать такой вот код:
RedirectMatch 301 (.*).html$ http://www.yourdomain.ru$1.php
Чпу (человекопонятные ссылки) на сайтах многих CMS тоже реализуются с помощью подобных редиректов. Ну и, конечно же, та самая склейка зеркал, возникающая из-за WWW, тоже происходит за счет 301 редиректа (с использованием возможностей модуля mod_rewrite веб-сервера Apache):
Редирект на WWW:
Options +FollowSymLinks
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.domain.ru$ [NC]
RewriteRule ^(.*)$ http://domain.ru/$1 [R=301,L]
Редирект с WWW:
Options +FollowSymLinks
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.domain.ru$ [NC]
RewriteRule ^(.*)$ http://domain.ru/$1 [R=301,L]
Кроме возможностей дополнительного файла конфигурирования Apache (.htaccess) для создания редиректов используют и другие методы, реализованные на возможностях различных языков программирования (PHP, Javascript и других). Даже средствами Html возможно сделать перенаправление (правда, не знаю, как это будет восприниматься поисковиками). Об этом я писал в статье про то, как можно скрыть партнерскую ссылку.
Сообщение с кодом 301 Redirect сервер возвращает в том случае,
если пользователь либо поисковый робот перенаправляется на URL,
отличающийся от того, на который совершается переход.
О чем свидетельствует код 301
Эта ошибка указывает на то, что старый адрес утратил свою актуальность, и что содержимое,
расположенное по этому адресу, перемещено на другой.
Для поисковых систем это сообщение приводит к автоматической переиндексации,
вследствие чего они начнут перенаправлять пользователей на новый адрес.
Код 301 не является ошибкой, это сервисное сообщение,
которое используется администратором ресурса для настройки переадресации.
Это важно для сохранения рейтинга страницы, адрес которой изменяется, в поисковых системах.
Индексация страницы по новому адресу при использовании редиректа будет происходить точно так же,
как и старой, и раскручивать новый адрес в поиске не понадобится.
Что делать пользователю, когда в браузере появляется код ошибки 301
Поскольку настройка редиректа всегда зависит только от администратора ресурса или хостинг-провайдера,
пользователю не следует ничего предпринимать в том случае,
если сервер перенаправил его на требуемую страницу.
В случае, если перенаправление привело на другую страницу либо возвратило ошибку с любым другим кодом,
например, 404 Page not found, следует сообщить об этом администратору ресурса или
провайдеру услуг хостинга.
Причины возникновения кода 301 redirect
Этот код не сигнализирует об ошибке, он является сервисным сообщением,
которое используют системные администраторы для самых разных задач:
- сохранение «пользовательских сигналов» контента, размещенного на странице;
- сохранение и передача накопленной ссылочной массы на другой адрес;
- перемещение страниц;
- удаление повторяющихся страниц, склейка;
- ребрендинг сайта;
- смена доменного имени;
- управление трафиком – перенаправление на нужный адрес.
Появление сообщения с кодом 301 Redirect сигнализирует о том,
что владелец ресурса настроил переадресацию.
Если все сделано правильно, пользователь будет перенаправлен на искомую страницу.
Добрый день.
Пытаюсь разобраться с WEB-сервисами. Разобрал пример из ИНЕТА. Опубликовал локально на WEB-сервере. Но при обращении к нему из обработки, сервер выдает ошибку:
{ВнешняяОбработка.WEB_Service.Форма.Форма.Форма(11)}: Ошибка при вызове конструктора (WSОпределения)
Определение = Новый WSОпределения(«http://localhost/request/ws/request.1cws?wsdl»,»Admin»,»123″);
по причине:
При создании описания сервиса произошла ошибка. URL сервиса: http://localhost/request/ws/request.1cws?wsdl
Код ответа сервера: 301
Публиковал и на IIS и на Apache 2.4
Результата один «Код ответа сервера: 301» (получаемый в ответ от сервера в ситуации, когда запрошенный ресурс был на постоянной основе перемещён в новое место). Совершенно ни о чем мне не говорит.
Сервис прекрасно читается в браузере напрямую — «http://localhost/request/ws/request.1cws?wsdl»
Он даже загружается в «WS-ссылки» конфигуратора.
Но работать не хочет из Обработки, которая к нему обращается.
Пример брал здесь: https://infostart.ru/public/327963/
Подскажите, как с этим бороться.
Нашел неточность. Имя сервиса «Request» (С большой буквы)
Теперь строка в определении выглядит так — «http://localhost/Request/ws/request.1cws?wsdl»
Но теперь ошибка 400 (что-то там с синтаксисом)
Разобрался.
Надо было делать так «http://127.0.0.1/Request/ws/request.1cws?wsdl»
«localhost» не катит
Error: Ошибка 301 — Если веб-сервер настроен правильно, он автоматически перенаправит читателя в новое расположение файла.
В этой статье представлен номер ошибки Ошибка 301, широко известный как Перемещено навсегда, описанный как Если веб-сервер настроен правильно, он автоматически перенаправит читателя в новое расположение файла.
О кодах состояния
Когда вы получаете коды веб-ошибок, у вас могут быть проблемы либо с клиентом, либо с сервером. Проблема может быть связана с браузером или настройками, которые блокируют ваше соединение, или это могут быть любые другие проблемы, связанные с сервером, к которому вы пытаетесь получить доступ.
Чтобы объяснить проблему подробнее, вот несколько полезных сведений о кодах веб-ошибок, их симптомах, причинах и методах устранения.
Определения (Бета)
Здесь мы приводим некоторые определения слов, содержащихся в вашей ошибке, в попытке помочь вам понять вашу проблему. Эта работа продолжается, поэтому иногда мы можем неправильно определить слово, так что не стесняйтесь пропустить этот раздел!
- Файл — блок произвольной информации или ресурс для хранения информации, доступный по строковому имени или пути.
- Местоположение — Местоположение — это конкретное положение в физическом пространстве, например точка на поверхности Земли, описанная с использованием координат широты и долготы.
- Reader — Reader указывает программное обеспечение, которое может читать файлы определенного формата или аппаратного устройства, которое может считывать данные с карты памяти или аналогичного устройства.
- Перенаправление — ответ веб-сервера, который просит пользовательский агент не отображать ответ body, но вместо этого запрашивает другой ресурс.
- Сервер . Сервер — это запущенный экземпляр программного приложения, способного принимать запросы от клиента и соответственно давать ответы.
- Интернет — используйте этот тег для ответов на общие вопросы, связанные со всеми аспектами всемирной паутины.
- Настройка . Процесс установки — это развертывание приложения на устройстве для будущего выполнения n и используйте.
Симптомы Ошибка 301 — Перемещено навсегда
Коды веб-ошибок также известны как коды состояния http. Существует пять различных классов кодов состояния http, и они всегда начинаются со следующих цифр, в зависимости от того, с какой ошибкой столкнулся пользователь. Это также симптомы ошибки, с которой столкнулся пользователь. Для дальнейшего объяснения ниже приведены коды состояния.
3xx: Перенаправление
Этот код состояния отправляется обратно клиенту, если пользователю необходимо предпринять дополнительные действия для завершения запроса. Пользователь либо получает уведомление о том, что содержимое временно или постоянно недоступно, либо получает кликабельный URI на сайт, куда перемещено запрашиваемое содержимое. Действия, которые необходимо предпринять пользователю, выделены жирным шрифтом, например, следующим образом:
300 — Множественные варианты
301 — Перемещено навсегда
302 — Найдено
303 — Посмотреть другие
304 — Не изменено
305 — Использовать прокси
307 — Временное перенаправление
(Только для примера)
Причины Перемещено навсегда — Ошибка 301
Коды 3XX возникают из-за определенных изменений, внесенных в исходный URI, и необходимости перенаправить пользователя на другой URI или некоторых других действий, описанных на странице ошибки.
Методы устранения
Для определенных кодов веб-ошибок существуют конкретные шаги по устранению неполадок. Однако существуют и обобщенные методы устранения, которые пользователи могут применять при возникновении подобных ошибок.
Если метод ремонта вам подошел, пожалуйста, нажмите кнопку upvote слева от ответа, это позволит другим пользователям узнать, какой метод ремонта на данный момент работает лучше всего.
Обратите внимание: ни ErrorVault.com, ни его авторы не несут ответственности за результаты действий, предпринятых при использовании любого из методов ремонта, перечисленных на этой странице — вы выполняете эти шаги на свой страх и риск.
Метод 1 — Очистить кеш браузера
При доступе к сайту данные сохраняются в кеше браузера. Иногда вы пытаетесь исправить веб-ошибку, но в вашем браузере появляется такое же сообщение. В таких случаях вам необходимо очистить кеш браузера, чтобы избавиться от надоедливого сообщения. Вот способы сделать это в разных браузерах:
- В Google Chrome
- Откройте Chrome и нажмите три точки в правом верхнем углу браузера.
- Нажмите Дополнительные инструменты , а затем нажмите Очистить данные просмотра .
- Вы можете удалить все или только определенный период просмотра.
- Установите флажки рядом с файлами cookie и другими данными сайта и кэшированными изображениями и файлами .
- Наконец, нажмите Очистить данные .
- На краю
- Нажмите … это крайняя правая кнопка под кнопкой закрытия.
- Прокрутите вниз и нажмите «Настройки».
- Найдите пункт «Очистить данные просмотра» и нажмите кнопку «Выбрать, что очистить».
- Это даст вам возможность выбрать, какой тип данных вы хотите очистить, просто поставьте галочку на тех элементах, которые хотите включить, затем нажмите «Очистить».
- В Mozilla
- Перейдите в меню «История» и выберите «Очистить недавнюю историю».
- Вы можете нажать кнопку Alt, если строка меню скрыта.
- Вы увидите раскрывающееся меню, в котором вы можете выбрать период или диапазон, который хотите удалить, и щелкните свой выбор.
- Вы можете нажать «Подробности», чтобы выбрать, что нужно очистить, будь то весь кеш или другие элементы.
- После выбора нажмите «Очистить сейчас» и перезагрузите браузер, чтобы изменения вступили в силу.
Метод 2 — Проверить журналы
- Если вы хотите проверить файлы журналов, вы можете сделать это, сначала убедившись, что вы вошли на компьютер веб-сервера как администратор.
- Нажмите «Пуск», затем «Настройка», затем нажмите «Панель управления».
- Откройте Инструменты администратора и дважды щелкните Диспетчер служб Интернета.
- Выберите веб-сайт из списка различных обслуживаемых сайтов.
- Щелкните веб-сайт правой кнопкой мыши и затем наведите указатель мыши на «Свойства».
- Выберите вкладку «Веб-сайт» и нажмите «Свойства». На нем вы увидите вкладку Общие свойства. Внизу окна вы можете увидеть расположение сгенерированных файлов журнала.
- Открывайте файлы журналов с помощью WordPad, любого средства просмотра текстовых файлов или Microsoft Word.
- Здесь вы сможете проанализировать, где возникли ошибки при доступе к серверу.
Метод 3 — Проверить запрошенный URL
- Бывают случаи, когда вы вручную вводите URL-адрес сайта, который хотите изучить. Если после этого вы получаете ошибки, проверьте URL-адрес, который вы только что ввели в адресной строке, если вы действительно получаете доступ к правильному адресу. Если нет, исправьте элементы, которые вы ввели неправильно.
Метод 4 — Удалить последние обновления
Для Windows 7
- Найдите обновления Windows в строке поиска.
- Нажмите «Ввод», когда он появится в результатах поиска.
- Проверьте последние обновления и нажмите Удалить обновления в те дни, когда возникла ошибка.
Для Windows 8 и Windows 10
- Нажмите одновременно кнопку окна и букву X, чтобы открыть настройки.
- Когда вы перейдете к настройкам Windows, нажмите «Обновление и безопасность».
- Нажмите «Просмотреть историю установленных обновлений», а затем «Удалить обновления».
Метод 5 — Удалить расширения
- Иногда дополнительные расширения могут выдавать коды веб-ошибок.
- Удалите недавно установленные расширения, зайдя в настройки браузера и нажав «Дополнительные инструменты».
- Вы увидите расширения, которые не были установлены в вашем браузере, выберите последнее дополнение, которое, как вы подозреваете, вызвало возникшую у вас проблему.
Метод 6 — Проверить конфигурацию сервера
- Устранением неполадок обычно занимается администратор сайта. Если это вы, то вам необходимо иметь представление о конфигурации веб-сервера.
- Вы можете проверить, на каком веб-сервере работает ваш сайт, с помощью средств проверки URL или домена. Вам просто нужно ввести адрес сайта и проанализировать результаты, которые вы получите.
- Вы также можете проверить неработающие ссылки, щелкнув веб-страницу правой кнопкой мыши и выбрав «Проверить». Это должно дать вам код сайта справа. Вы можете проверить каждый якорный текст и убедиться, что связанные с ними ссылки все еще активны.
Метод 7 — Другие техники
- Вы также можете проверить наличие нежелательных символов в кодах и сценариях с помощью отладки кодов приложений и сценариев. Если вы не знаете, как это сделать, вы можете проверить этот ресурс для этого.
- Вы также можете попробовать Обновить веб-сайт. Иногда вы получаете старую ошибку, которая никуда не делась, и простое обновление, нажав F5, может сработать.
Другие языки:
How to fix Error 301 (Moved Permanently) — If the web server is setup properly, it will automatically redirect the reader to the new location of the file.
Wie beheben Fehler 301 (Ständig umgezogen) — Wenn der Webserver richtig eingerichtet ist, leitet er den Reader automatisch an den neuen Speicherort der Datei um.
Come fissare Errore 301 (Spostato Permanentemente) — Se il server web è configurato correttamente, reindirizzerà automaticamente il lettore alla nuova posizione del file.
Hoe maak je Fout 301 (Verplaatst Permanent) — Als de webserver correct is ingesteld, wordt de lezer automatisch omgeleid naar de nieuwe locatie van het bestand.
Comment réparer Erreur 301 (Déménagé de manière permanente) — Si le serveur Web est correctement configuré, il redirigera automatiquement le lecteur vers le nouvel emplacement du fichier.
어떻게 고치는 지 오류 301 (영구적으로 이동됨) — 웹 서버가 제대로 설정되면 리더를 파일의 새 위치로 자동 리디렉션합니다.
Como corrigir o Erro 301 (Movido Permanentemente) — Se o servidor da web estiver configurado corretamente, ele redirecionará automaticamente o leitor para o novo local do arquivo.
Hur man åtgärdar Fel 301 (Flyttade permanent) — Om webbservern är korrekt konfigurerad kommer den automatiskt att omdirigera läsaren till den nya platsen för filen.
Jak naprawić Błąd 301 (Przeniesiony na stałe) — Jeśli serwer WWW jest poprawnie skonfigurowany, automatycznie przekieruje czytnik do nowej lokalizacji pliku.
Cómo arreglar Error 301 (Movido permanentemente) — Si el servidor web está configurado correctamente, redirigirá automáticamente al lector a la nueva ubicación del archivo.
Об авторе: Фил Харт является участником сообщества Microsoft с 2010 года. С текущим количеством баллов более 100 000 он внес более 3000 ответов на форумах Microsoft Support и создал почти 200 новых справочных статей в Technet Wiki.
Следуйте за нами: 
Последнее обновление:
12/03/23 10:23 : Пользователь Mac OS X проголосовал за то, что метод восстановления 1 работает для него.
Рекомендуемый инструмент для ремонта:
Этот инструмент восстановления может устранить такие распространенные проблемы компьютера, как синие экраны, сбои и замораживание, отсутствующие DLL-файлы, а также устранить повреждения от вредоносных программ/вирусов и многое другое путем замены поврежденных и отсутствующих системных файлов.
ШАГ 1:
Нажмите здесь, чтобы скачать и установите средство восстановления Windows.
ШАГ 2:
Нажмите на Start Scan и позвольте ему проанализировать ваше устройство.
ШАГ 3:
Нажмите на Repair All, чтобы устранить все обнаруженные проблемы.
СКАЧАТЬ СЕЙЧАС
Совместимость
Требования
1 Ghz CPU, 512 MB RAM, 40 GB HDD
Эта загрузка предлагает неограниченное бесплатное сканирование ПК с Windows. Полное восстановление системы начинается от $19,95.
ID статьи: ACX01618RU
Применяется к: Windows 10, Windows 8.1, Windows 7, Windows Vista, Windows XP, Windows 2000
Ошибки в алфавитном порядке: A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Логотипы Microsoft и Windows® являются зарегистрированными торговыми марками Microsoft. Отказ от ответственности: ErrorVault.com не связан с Microsoft и не заявляет о такой связи. Эта страница может содержать определения из https://stackoverflow.com/tags по лицензии CC-BY-SA. Информация на этой странице представлена исключительно в информационных целях. © Copyright 2018
Обычные посетители сайта обращают внимание в первую очередь на качественный контент, а поисковые краулеры – на ответы сервера.
Сегодня научимся проверять код как одной страницы, так и всех сразу, а также разберем все коды ответа и узнаем, что именно они означают.
Немного теории
Определить доступность веб-страницы поможет анализ кода состояния HTTP. Технически он представляет из себя стандартный запрос. Он отправляется, когда мы переходим по определенной ссылке на сайте или просто вводим ее в поисковой строке браузера. При обработке запроса сервер самостоятельно формирует и отдает трехзначный цифровой код.
Благодаря коду ответа понять реакцию сайта на запрос может не только поисковый краулер, но и обычный пользователь. Здесь нет ничего сложного даже для начинающих вебмастеров.
Сперва определимся с терминами.
- Клиент – компьютер, смартфон или другое мобильное устройство, которое имеет подключение к интернету.
- Сервер – определенный компьютер, который хранит все данные сайта (включая страницы и системные файлы). Именно на сервере «живет» сайт.
Выделяют пять классов ответов. Идентифицировать класс можно по первой цифре.
- 5** – техническая ошибка на стороне сервера. Точная причина указывается сразу после кода. Иногда пятисотая говорит о внутренних сбоях, реже – о превышении статической нагрузки на сервер.
- 4** – сбой на стороне юзера.
- 3** – обнаружен редирект на другой адрес (не ошибка).
- 2** – запрос обработан успешно (не ошибка).
- 1** – служебный класс кодов, который чаще всего относится к информационным сообщениям (не ошибка).
Логика кодов, таким образом, весьма проста:
Продвинем ваш бизнес
В Google и «Яндексе», соцсетях, рассылках, на видеоплатформах, у блогеров
Подробнее
Что значат коды состояния 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 запроса и куда копать для ее устранения.
Если ваш код ответа не указан в этом мануале, значит речь идет о кастомизированном сервере. Чтобы правильно истолковать ответ такого сервера и перевести его на человеческий язык, придется обратится к его разработчику.
Каждый раз, когда мы кликаем на какую-то ссылку или на наш сайт заходят поисковые роботы, происходит один из диалогов примерно такого содержания:
— Привет, сервер! Я поисковый робот. Могу я просканировать эту страницу?
— Привет! Конечно, заходи.
— А если вот эту страницу?
— А вот здесь пока ведутся ремонтные работы, приходи позже.
Язык ответов HTTP понимают и браузеры, и поисковые роботы, и SEO-специалисты, которым он нужен при работе с сайтом.
Если вы до сих пор путаете 301 с 302, и не знаете, зачем нужен 410 ответ — вам просто необходимо разобраться в кодах ответов HTTP, которые встречаются чаще всего. О них я и расскажу в этой статье. А еще мы узнаем, какую роль они отыграют в SEO и как не допустить ошибок в их использовании.
Какие ответы серверов существуют?
Начнем с того, что все коды ответов (состояния) серверов делятся на 5 классов, каждый из которых несет определенный смысл:
- 1XX. Эти информационные коды говорят о том, что запрос был понят, принят сервером и уже обрабатывается. Такие временные ответы обычно не отображаются на экране пользователей, но служат внутренними кодами для браузеров.
- 2XX. Обозначают успешную обработку полученного запроса. Они используются браузерами для подтверждения того, что запрос был принят, обработан и отражают его текущий статус.
- 3XX. Это коды перенаправления. Говорят о том, что серверу нужно выполнить дополнительные действия — например, перейти по редиректу на новый адрес.
- 4XX. Говорят об ошибке на стороне пользователя. Чаще всего появляются, если время ожидания браузера истекло или запрос был введен неправильно.
- 5XX. Говорят об ошибке сервера. Это значит, что вы запрашиваете специфический ресурс и он найден, но сервер не может дать вам к нему доступ. В конечном счете, запрос не может быть обработан.
Не все ответы сервера можно увидеть прямо на экране, большинство так и остаются внутренними кодами для браузеров и поисковых роботов. Чтобы быстро узнать статус любой страницы, откройте инструменты разработчика в браузере Chrome (нажмите F12). Перейдите на вкладку Network, обновите страницу и получите список статусов каждого элемента, включая саму страницу:
Именно в этих трех цифрах в колонке Status зашифрованы данные о состоянии страницы: можно ли ее сканировать, находится ли она по этому адресу, загружается ли все ее содержимое и т. д.
Какие же коды ответов сервера встречаются чаще всего? И что они значат для оптимизации сайта? Давайте внимательно рассмотрим самые полезные для SEO ответы и способы их обработки.
Ответы серверов, которые встречаются чаще всего
На самом деле существует более 70 различных кодов состояния сервера, но, скорее всего, вы никогда не столкнетесь с большей половиной из них. Однако знать самые распространенные коды состояния HTTP очень важно, потому что ответы сервера напрямую влияют на индексацию вашего сайта, краулинговый бюджет и продвижение ресурса в поисковых системах.
301 Moved Permanently
Говорит о том, что URL был навсегда перенесен на новое место. Браузеры самостоятельно переходят по 301 переадресации — никакого действия от пользователя не требуется.
301 код ответа обычно используют при переводе сайта с HTTP на HTTPS, склейке зеркал (страниц с www и без www), настройке слеша в конце URL, а также при переносе части сайта или всех страниц на новый домен. Этот редирект идеально подходит, если вы хотите передать ссылочный вес старой страницы на новую и сохранить результаты SEO-продвижения.
Совет: Старайтесь не перенаправлять пользователей с удаленного URL на главную страницу сайта. Например, в вашем интернет-магазине есть карточка с неактуальным товаром, но с неплохой ссылочной массой. Вы хотите сохранить этот вес и ставите 301 редирект на главную. Здесь и кроется ошибка! Такой редирект воспринимается Google как 404 Soft, а это означает, что поисковик не будет передавать сигналы со старого URL на новый. В такой ситуации всегда перенаправляйте страницу на максимально похожую (или 404, если аналогичная страница отсутствует).
Кроме того, избегайте цепочек редиректов с двумя и больше переадресациями, так как они создают дополнительную нагрузку на сервер и даже могут помешать пользователям перейти на ваш сайт как небезопасный. Google не индексирует дальше 4-го редиректа, и после каждого теряется вес, поэтому лучше ставьте прямые редиректы (вместо 1 -> 2 -> 3, сразу 1 -> 3).
Через несколько лет можете смело удалять 301, чтобы уменьшить нагрузку на сервер.
302 Found / Moved Temporarily
В отличие от постоянного 301 редиректа, этот — временный. Он говорит о том, что страница найдена, но пока размещена по другому адресу.
Обычно его путали с 301, а после того, как Google объявил, что все 3хx редиректы передают ссылочный вес, — ситуация усугубилась. По факту, его нужно ставить, если вы точно уверены, что будете использовать старый URL снова. Как раз об этом вы и сообщаете поисковику с помощью 302 сигнала, а он в ответ оставляет весь ссылочный вес за старой страницей.
Если вы будете использовать 302 редирект на постоянной основе, Google в конечном итоге воспримет его как 301 со всеми вытекающими последствиями. Также проверьте, нет ли на вашем сайте 302 редиректов, которые на самом деле должны быть 301 — такая ошибка встречается очень часто.
304 Not Modified
Сервер отдает 304 Not Modified ответ, когда страница остается неизменной со времени последнего посещения.
Все браузеры хранят в своем кэше данные заголовка Last-Modified. В свою очередь, это позволяет им точно знать, когда страница была в последний раз изменена. И когда поисковые роботы заходят на страницу и видят, что значение заголовка совпадает с уже сохраненным в кэше, сервер возвращает 304 ответ.
Этот код можно использовать для ускорения индексации сайта. Ведь получив такой ответ, поисковый робот не будет загружать страницу, а значит, успеет проиндексировать больше других страниц.
Лучший ответ сервера для оптимизатора ― 200 ОК. Он означает, что запрос успешно обработан. Но 304 несет ту же нагрузку. Как правило, на новые страницы и первое посещение должен выдаваться ответ 200, на все последующие, если не произошло изменений — 304.
403 Forbidden
Этот код ответа говорит о том, что пользователю запрещен доступ к странице.
403 ошибка может появиться, если пользователь вошел на сайт, но у него нет разрешения для доступа к закрытой внутренней сети. Например, если я попытаюсь зайти в кабинет админа SE Ranking по прямому URL, используя пароль и логин личного аккаунта, на экране будет 403 ошибка «Нет доступа». Также 403 ошибка возникает, если индексный файл для главной указан неправильно. Он обязательно должен иметь название index и расширение: *.shtml, *.html, *.htm, *.phtml или *.php.
Кроме того, когда вы переносите сайт на HTTPS, то 403 ответ появится, когда DNS-кэш ещё не успел обновиться, а вы уже что-то от него хотите. Лучше подождите, или, если это вопрос жизни и смерти, обновите кэш принудительно.
Совет: страницы с 403 кодом ответа в конечном итоге будут удалены из индекса, поэтому Google рекомендует использовать 404 ответ вместо 403.
404 Not Found
Самая «любимая» ошибка в SEO. Говорит о том, что сервер ничего не нашел по указанному адресу, хотя соединение между сервером и клиентом прошло успешно.
Не стоит переживать, если вы увидите много 404 страниц в своей Google Search Console. Поисковик просто сообщает вам, какие страницы удалены, а вам уже решать, нужно ли их проверять. Но что стоит точно сделать — убрать все ссылки на удаленные страницы, чтобы не путать посетителей при навигации по вашему сайту.
Обычно мы видим этот код ошибки, когда вводим неправильный URL в браузер и, как следствие, пытаемся получить доступ к несуществующей странице. Или, например, владелец сайта удалил страницу без редиректа URL по новому адресу. Как результат — 404 ошибка. Чтобы решить проблему, посетителю нужно перепроверить написание URL или попробовать найти информацию на сайте самостоятельно через поиск, а владельцу ресурса ― исправить «битые» ссылки на рабочие.
404 страница не индексируется и не передает вес. Поэтому некоторые оптимизаторы грешат «мягкой 404», выдавая стандартную страницу с ответом 200 вместо 404. Но это считается плохой практикой, потому что 200 код говорит Google, что по этому URL есть реальная страница. В конечном счете, страница оказывается в индексе, и поисковик продолжает свои попытки сканировать несуществующие URL-адреса вместо сканирования ваших реальных страниц.
Как настроить 404 страницу для своего сайта
Если раньше после перехода на несуществующую страницу пользователь видел перед собой только цифру 404, то сейчас — просто море креатива. Но не стоит забывать, что он пришел с конкретным запросом и ваша задача — дать решение, а не развлечь его. Поэтому не забудьте оптимизировать 404 страницу — добавьте навигацию своего сайта или контактную форму, особенно если на 404 страницы идет трафик.
Если ваша CMS (система управления контентом) не создала 404 страницу, вы можете создать ее самостоятельно.
С помощью htaccess
Самый простой способ настроить страницу с 404 ошибкой — добавить сообщение об ошибке, например ErrorDocument 404 “<H1> Not Found </ H1>” в сам файл .htaccess.
В результате у вас должно получиться что-то вроде этого:
Через PHP
Вы можете использовать функцию заголовка и менять контент 404 страницы в зависимости от разных сценариев (например, юзер сделал ошибку в URL самостоятельно или уже перешел по «битой» ссылке с какого-то ресурса).
Детальнее — в этой инструкции.
Через WordPress
У вас есть несколько вариантов:
- Отредактируйте существующую страницу 404, которая уже есть в вашей теме.
- Добавьте свою 404 страницу, если ваша тема ее не предлагает по умолчанию.
- Используйте плагин для 404 страницы.
Подробности можно узнать здесь.
410 Gone
Этот ответ говорит о том, что страница или документ не доступны по указанному адресу и новый адрес неизвестен.
Более того, инструмент проверки URL в Google Search Console обозначает 410 ответы как 404, что приводит к еще большему количеству 404 ошибок, обнаруженных в консоли.
410 ответ чаще всего встречается на страницах с низким трастом, без ссылок или тех, что удалены безвозвратно. Например, с товаром, которого больше не будет в продаже.
Поскольку Google все-таки относится к 404 и 410 ошибкам по-разному, нужно использовать 410 код только тогда, когда вы точно знаете, что страница удалена и больше не вернется. Такой ответ по умолчанию кэшируется, поисковый робот больше не заходит на страницу, а она в свою очередь удаляется из индекса.
Совет: подумайте дважды, прежде чем удалять страницу навсегда. Если вы сомневаетесь, лучше поставить редирект на похожую страницу и получить хотя бы часть текущего трафика. Если же удаления страницы не избежать, обязательно проверьте ссылки, которые на нее ведут — как только страница будет удалена, магия ссылок закончится тоже.
503 Service Unavailable
Этот статус говорит поисковым роботам и пользователям, что в данный момент страница недоступна и, следовательно, сервер не может обработать входящий запрос.
В большинстве случаев 503 появляется, если сервер перегружен, например, превышено ограничение на число входящих запросов или сервер проходит техническое обслуживание.
Могут быть ещё такие причины:
- DDOS-атака на сайт.
- Использование большого количества скриптов и других элементов с внешних ресурсов: виджеты, картинки.
- Запросы к базе данных и извлечение оттуда информации занимают слишком много времени.
- Чрезмерное количество обращений к сайту от поисковиков, пользователей или сервисов по парсингу сайта.
Совет: в идеале в сообщении с 503 ошибкой обязательно нужно указать, что пользователю нужно вернуться на сайт через Х времени. К сожалению, так очень редко делают — обычно просят попытать удачу позже.
И последнее, но не менее важное: код состояния 503 не позволяет поисковым системам индексировать сайт. Кроме того, он сообщает, что сайт плохо обслуживается, потому что пользователи не могут попасть, куда хотели. Поэтому важно, чтобы неполадки были устранены как можно быстрее — иначе это скажется на позициях сайта.
Как настроить 503 страницу для своего сайта через PHP
Вот как выглядит код состояния 503 в PHP:
<?php
header("HTTP/1.1 503 Service Temporarily Unavailable");
header("Status: 503 Service Temporarily Unavailable");
header("Retry-After: 3600");
?>
Больше подробностей можно почитать в этой инструкции.
Как проверить коды состояния всех страниц на сайте
Чтобы быть в курсе всего, что происходит на вашем сайте, нужно мониторить коды состояния всех ваших страниц. Конечно, для этого можно использовать расширение Live HTTP Headers для Chrome или отчет «Покрытие» в Google Search Console, но лучше, если вы проанализируете ответы до того, как до них доберутся поисковые роботы.
Если вы хотите быстро проверить коды состояния всех страниц вашего сайта одним кликом, обязательно попробуйте наш инструмент «Аудит сайта».
Инструмент не просто проверит все страницы на вашем сайте и проанализирует ключевые параметры оптимизации, но и выполнит SEO-аудит всего ресурса по важным техническим параметрам, найдет ошибки и даже подскажет методы их решения.
Все статусы страниц вы увидите в основном отчете, в котором проанализированы технические параметры, страницы, мета-теги, ссылки и контент.
Кстати, вы можете воспользоваться бесплатной пробной версией, чтобы протестировать все основные функции аудита.
Если же вас интересуют только коды состояния всех страниц, просто перейдите на вкладку «Сканированные страницы». Все данные можно экспортировать в формате XLS для подробного изучения:
Безусловно, найти ошибки в кодах ответов это только полдела. Решать проблемы, связанные с ошибками сервера, вам все равно придется самостоятельно, но сам поиск ошибок у вас теперь будет занимать считанные минуты. Оптимизировав коды состояния своих страниц, не забудьте отправить их на повторную индексацию.
Чтобы сдать этот экзамен на отлично, мы подготовили для вас шпаргалку по правилам HTTP-знаков с лучшими SEO-советами. Теперь какой бы знак не встретился у вас на пути, вы будете знать, что делать.
Юлия — контент-маркетолог c 10-летним опытом работы в журналистике, копирайтинге, рекламе и PR.
Своим опытом и знаниями она делится, создавая полезные статьи про SEO и диджитал-маркетинг для блога SE Ranking и популярных медиа.
Когда Юлия не пишет статьи, она осваивает новые асаны, путешествует и помогает волонтерской организации YWCA.