|
|||
| 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 |
Есть ли простое решение чтобы пройти аутентификацию, для НеСисАдмина, что где поставить в пользователях.. |
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку «Обновить» в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.
Привет, читатель блога 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 возможно сделать перенаправление (правда, не знаю, как это будет восприниматься поисковиками). Об этом я писал в статье про то, как можно скрыть партнерскую ссылку.