Код ответа


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

Как пользоваться инструментом?

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

  1. Отслеживания работоспособности продвигаемых SEO-специалистами страниц.
    В том случае если продвигаемая страница отдаёт неверный код ответа сервера (отличный от 200 ОК), это может приводить к исключению страницы из индекса поисковой системы.

  2. Отслеживания работоспособности страниц, на которые ведут объявления рекламной кампании.
    Возможны ситуации, когда с сайта удаляются товары (страницы), на которые ведут объявления рекламной компании. С помощью сервиса можно своевременно обнаружить ошибки, получив коды ответа сервера для целого списка страниц (максимум за одну итерацию — 100 ссылок).

    Работа инструмента проверки кода

    В данном случае страница № 4 отдаёт код 404, что говорит о её недоступности к индексации.


  3. Выявления редиректов в структуре сайта для исключения излишних перенаправлений.

    Код ответа

    Если в исходном коде имеются ссылки на указанные URL-адреса, то рекомендуется заменить их на конечные URL-адреса (столбец «URL-переадресации»).

 

Зачем столбец с размерами страниц?

  1. Избыточный вес страниц может негативно влиять на ранжирование документа.
    Максимальное рекомендованное значение: 120 Кб. В случае превышения данного лимита стоит оптимизировать контент, расположенный на странице (выносить в отдельный файлы JS и CSS-фрагменты).

  2. По весу страницы можно сделать определённые выводы о типе документа, расположенному по введенному URL-адресу, а также находить потенциальные дубли.
    Рассмотрим ряд страниц интернет-магазина измерительной техники:

    Код ответа

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

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


 

Возможность скачать результат в CSV

Чтобы скачать результат проверки в формате CSV, необходимо перед запуском проверки поставить галочку «Скачать результаты в виде CSV-файла».

Код ответа

Какие коды ответа сервера существуют?

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

  • 200 OK — страница доступна, в ответе сервера содержатся запрошенные данные. Надо стремиться к тому, чтобы этот код ответа отдавали все продвигаемые документы сайта и документы, на которые ведут объявления рекламных кампаний.
  • 301 Moved Permanently — запрашиваемая страница была перенесена на новый URL, который указан в инструменте в случае данного кода ответа в столбце «URL-переадресации».
  • 302 Found — запрашиваемая страница была временно перенесена на другой URL, который указан в инструменте в случае данного кода ответа в столбце «URL-переадресации».
  • 404 или Not Found — страница не была найдена по указанному URL.

  • 410 Gone — запрашиваемая страница была удалена с указанного URL и теперь недоступна. Если документ в ближайшее время может быть восстановлен, рекомендуется клиенту отдавать код 404.
  • 503 Server Unavailable — сервер временно не имеет возможности обрабатывать запросы по техническим причинам. В поле Retry-After заголовка сервер может указать время, через которое клиенту рекомендуется повторить запрос. Данный код ответа используется для того, чтобы сообщить поисковому роботу о проведении технических работ на сайте и необходимости посетить ресурс позже. С точки зрения продвижения рекомендуется следить за страницами с кодом ответа 503, чтобы после проведения технических работ на сайте они снова отдавали код ответа 200 OK.

tools.pixelplus.ru

Что собой представляют и что означают коды ответов сервера

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

Класс состояния

В настоящее время выделено пять классов кодов состояния:


  • 1** Informational — коды информации, отвечающие за передачу данных. Это так называемые «информационные коды», которые уведомляют о принятии запроса и его обработке.
  • 2** Success — код успешной обработки запроса сервером.
  • 3** Redirection — запрос перенаправляется на другой адрес.
  • 4** Client Error — запрос имеет плохой синтаксис или не может быть выполнен.
  • 5**  Server Error — ошибка, связанная с самим сервером и не зависящая от действий пользователя. Если сервер не может выполнить действие, он выдает ошибку 5** и указывает ее причину.

Наиболее распространенные ответы сервера

200 ОК

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

301 Moved Permanently

Код ответа‘ width=»>

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


302 Found

Страница временно перемещена на другой адрес, при этом удалять старый адрес из индекса не следует. Ссылочный «вес» остается прежним.

304 Not Modified

Весьма важная ошибка в свете анализа нагрузок на сервер, а также передаваемой им информации. Пользователь получит ошибку 304 в том случае, если в HTTP-заголовке время последнего обновления (Last-Modified) более позднее, нежели в запросе с заголовком If-Modified-Since (иными словами, если страница не подвергалась изменениям после указанной даты). Документ повторно не загружается, так как он не изменился, поисковые роботы получают http-заголовки и обрабатывают страницу далее.

403 Forbidden

Ошибка отказа в доступе пользователю к конкретному типу страницы или документа. Код 403 может появится при попытке входа с запрещенных IP-адресов либо при попытке открытия системного файла *.htaccess. Также могут встретиться ошибки 401 и 407 при проблемах с HTTP-аутентификацией.

404 Not Found

Знакомый каждому пользователю «ненавистный код» ненайденной страницы. Сигнализирует об отсутствии документа или страницы по заданному URL. Код отдается при попытке попадания на несуществующие ссылки и документы. Если вам требуется сообщить об удалении страницы по запрашиваемой  ссылке, применяйте код 410.


Код ответа‘ width=»>

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

410 Gone

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

Код ответа‘ width=»>

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

451 Unavailable For Legal Reasons

Часто возникающий код в последнее время. Ошибка 451 свидетельствует о том, что доступ к странице по данному адресу закрыт из-за запрета на государственном уровне. Также могут быть иные причины (нарушения авторских прав, например). Код 451 является уточнением кода 403.

500 Internal Server Error

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


Код ответа‘ width=»>

503 Service Unavailable

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

504 Gateway Timeout

Нет ответа от шлюза. Код появляется при отсутствии ответа от сервера, работающего в качестве прокси.

Как определить коды ответа на сайте

Например, если вы пользуетесь браузером Google Chrome, можно нажать F12 и зайти во вкладку Network. После того, как панель откроется, следует обновить страницу. Для прочих поисковиков можно воспользоваться расширениями (Live HTTP Headers, например), которые предоставят вам информацию по каждой открываемой вами странице.

Существуют также способы массово проверить десятки страниц по списку URL. Для этого стоит воспользоваться Netpeak Spider, Netpeak Checker или Urlitor, которые анализируют до 150 запрашиваемых адресов.

Основные выводы

Коды ответа серверов входят в пять основных групп – классов состояния. Они указывают на различные этапы передачи и обработки информации и определяют «виновного» и причину при отсутствии данных. Абсолютно все страницы, которые должны быть в индексе поисковиков, в обязательном порядке обязаны выдавать код 200 OK.


При смене адреса страниц, уже бывших в выдаче роботами поисковиками, требуется перенастроить редирект (код 301) со старой URL-ссылки на обновленный адрес.

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

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

Столкнулись с кодами ответа сервера из вышеприведенного списка на Вашем сайте? Или хотите их избежать? Закажите у нас seo-аудит и мы поможем Вам со ошибками на сайте.
Получить предложение!

Подпишись и следи за выходом новых статей в нашем монстрограмме.

convertmonster.ru

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


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

1xx — информационные:

  • 100 — сервер принял первую часть запроса, можно подрожать передачу;
  • 101 — нужно изменить протокол работы на более подходящий;
  • 102 — на обработку запроса уйдет много времени, используется чтобы браузер не разрывал соединение раньше времени;

2хх — операция успешна:

  • 200 — запрос выполнен успешно, отправляется для большинства запрашиваемых страниц;
  • 201 — после выполнения запроса был создан ресурс;
  • 202 — запрос принят, но еще не обработан;
  • 203 — запрос выполнен успешно, но информация для ответа взята из прокси;
  • 204 — запрос обработан, но контента для отображения нет;
  • 205 — попросить пользователя ввести необходимые данные;
  • 206 — запрос обработан, но передана только часть контента;

3xx — перенаправления:

  • 300 — есть несколько страниц для этого запроса, например, на нескольких языках;
  • 301 — страница навсегда перемещена по новому адресу;
  • 302 — документ был временно перемещен;
  • 303 — документ необходимо загрузить по указанному адресу с помощью протокола GET;
  • 304 — документ не изменился с последнего запроса;
  • 305 — нужно использовать прокси;
  • 307 — ресурс временно перемещен на новый адрес.

4хх — ошибка в запросе:

  • 400 — неверный запрос;
  • 401 — необходимо аутентифицироваться;
  • 403 — запрос принят, но у вас нет доступа;
  • 404 — страница не найдена на сервере;
  • 405 — используемый метод нельзя применять на сервере;
  • 408 — время ожидания передачи запроса истекло;
  • 410 — ресурс полностью удален;
  • 411 — нужно указать длину запроса;
  • 413 — запрос слишком длинный;
  • 414 — URI запроса слишком длинная.

5хх — ошибка сервера:

  • 500 — внутренняя ошибка сервера;
  • 501 — нужная функция не поддерживается;
  • 502 — прокси не может соединиться со шлюзом;
  • 503 — сервер не может обрабатывать запросы по техническим причинам;
  • 504 — прокси не дождался ответа от сервера;
  • 505 — версия протокола HTTP не поддерживается.

Что такое http заголовки?

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

  • Server — имя и версия веб-сервера;
  • Date — дата осуществления запроса;
  • Content-Type — MIME тип передаваемых данных, например, text/html, тут же задается кодировка;
  • Connection — тип соединения, может быть closed — уже закрыто, или keep-alive — открыто для передачи данных;
  • Vary — указывает при каких заголовках веб-сервер будет возвращать разные старины для одного URI;
  • Set-Cookie — сохранить Cookie информацию для страницы;
  • Expires — можно хранить страницу или ресурс в кэше до определенной даты;
  • Cache-Control — настройка времени кэширования страницы браузером, а также разрешения на кэширования;
  • ETag — содержит контрольную сумму для страницы, применимо для проверки кэша;
  • Last-Modified — дата, когда страница последний раз была изменена;

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

Проверка кода ответа сервера с помощью cURL

Чтобы увидеть только код ответа страницы достаточно выполнить такую команду:

curl -s -o /dev/null -w "%{http_code}" https://losst.ru

Код ответа

Или, если хотите, чтобы ответ выглядел более естественно:

curl -I https://losst.ru 2>/dev/null | head -n 1 | cut -d$' ' -f2

Код ответа

Страницы вернули 200, все в порядке. Но отправляет ли сервер редирект для нужных нам страниц? Если ваш сайт работает на https, то все запросы http должны перекидываться на https, также для любого сайта, все запросы на www домен должны перенаправляться на основной, или наоборот. Запросы на ip сайта тоже в идеале должны отправляться на основной домен. Проверка http ответа:

curl -I http://losst.ru 2>/dev/null | head -n 1 | cut -d$' ' -f2

curl -I https://www.losst.ru 2>/dev/null | head -n 1 | cut -d$' ' -f2

Код ответа

Все работает так, как нужно. Но смотреть код ответа сервера вряд ли понадобиться, намного интереснее проверка http статусов.

Проверка http заголовков с помощью Curl

Для проверки заголовков мы тоже можем использовать утилиту curl. Чтобы вывести заголовки страницы запустите ее с опцией -I:

curl -I https://losst.ru

Код ответа

Здесь отображается код ответа сервера, а также принятые http заголовки. Из них мы можем сделать такие выводы:

  • Страница сгенерирована в nginx 1.10.2;
  • Это обычная html страница (text/html);
  • Размер страницы 102452 байт или 100 кб;
  • Страница последний раз изменялась 18:13:12 (last_modified) это очень важный параметр для поисковых систем;
  • Сервер будет выдавать разные версии страниц при изменении поля Accept-Encoding (Vary);
  • Страница может храниться в любом кэше (public) на протяжении часа (expires);

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

 curl -I https://losst.ru/wp-content/uploads/2016/08/map-2.png

Код ответа

Мы можем видеть, что картинка будет храниться в кэше намного дольше (max-age) чем html страница.

Осталось проверить работают ли такие заголовки, как If-Modified-Since и If-None-Match. Первый позволяет выполнять проверку актуальности кэша по дате модификации, второй — по контрольной сумме поля ETag. Кэш очень важен, чтобы снизить нагрузку на ваш сервер. Если страница не изменилась, то сервер лишь сообщает что она не изменилась, отправляя код ответа 304, вместо передачи полного файла.

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

Проверка If-Modified-Since

Сначала запрашиваем нашу страницу для просмотра заголовков http, а затем копируем поле Last-Modified:

curl -I https://losst.ru

Код ответа

Теперь запрашиваем ее еще раз, но уже с заголовком If-Modified-Since: и ваша дата:

curl -I --header 'If-Modified-Since: Mon, 26 Dec 2016 18:13:12 GMT' https://losst.ru

Код ответа

В ответ вы должны получить не саму страницу, а только заголовок HTTP/1.1 304 Not Modified. Если так, значит проверка кода ответа сервера пройдена и все работает верно.

Проверка If-None-Match

Заголовок If-None-Match работает похожим образом, только здесь используется значение контрольной суммы кэша из поля ETag. Опять запросим нашу страницу и скопируем сумму:

curl -I https://losst.ru

Код ответа

Затем отправим полученную сумму с заголовком:

curl -I --header 'If-None-Match: "58615db8-19034"' https://losst.ru

Код ответа

 

 

И снова мы должны получить ответ 304, страница не изменена.

Проверка сжатия

Сжатие позволяет уменьшить размер передаваемых данных, но в то же время создает дополнительную нагрузку на сервер. Чтобы проверить поддерживает ли сервер сжатие gzip нужно отправить в запросе заголовок Accept-Encoding с параметром gzip:

 curl -I https://losst.ru --header 'Accept-Encoding: gzip'

Код ответа

В ответе мы увидим поле Content-Encoding: gzip. Это будет означать, что сжатие используется.

Выводы

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

losst.ru

Эти коды определены www.w3.org/Protocols/rfc2616/rfc2616-sec10.html:

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

Ответы в диапазоне 100-199 — информационные. Они показывают, что запрос клиента принят и обрабатывается.

100=»Continue»
Начальная часть запроса принята, и клиент может продолжать передачу запроса.
101=»Switching Protocols»
Сервер выполняет требование клиента и переключает протоколы в соответствии с указанием, данным в поле заголовка Upgrade.

Запрос клиента успешен (Successful 2xx)

Ответы в диапазоне 200-299 означают, что запрос клиента обработан успешно.

200=»OK»
Запрос клиента обработан успешно, и ответ сервера содержит затребованные данные.
201=»Created»
Этот код состояния используется в случае создания нового URI. Вместе с этим кодом результата сервер выдает заголовок Location (см. главу 19), который содержит информацию о том, куда были помещены новые данные.
202=»Accepted»
Запрос принят, но обрабатывается не сразу. В теле содержимого ответа сервера может быть дана дополнительная информация о данной транзакции. Гарантии того, что сервер в конечном итоге удовлетворит запрос, нет, даже несмотря на то, что на момент приема запрос выглядел допустимым.
203=»Non-Authoritative Information»
Информация в заголовке содержимого взята из локальной копии или у третьей стороны, а не с исходного сервера.
204=»No Content»
Ответ содержит код состояния и заголовок, но тело содержимого отсутствует. При получении этого ответа броузер не должен обновлять свой документ. Обработчик чувствительных областей изображений может возвращать этот код, когда пользователь щелкает на бесполезных или пустых участках изображения.
205=»Reset Content»

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

206=»Partial Content»

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

233 — because not everyone lives in «your country»

Запрос клиента переадресован (Redirection 3xx)

Код ответа в диапазоне 300-399 означает, что запрос не выполнен и клиенту нужно предпринять некоторые действия для удовлетворения запроса.

300=»Multiple Choices»
Затребованный URI обозначает более одного ресурса. Например, URI может обозначать документ, переведенный на несколько языков. В теле содержимого, возвращенном сервером, может находиться перечень более конкретных данных о том, как выбрать ресурс правильно.
301=»Moved Permanently» — перемещен навсегда
Затребованный URI уже не используется сервером, и указанная в запросе операция не выполнена. Новое местонахождение затребованного документа указывается в заголовке Location. Во всех последующих запросах данного документа следует указывать новый URI.
При запросах не методом HEAD сервер должен передать в теле сообщения гипертекстовое пояснение. При использовании всех методов, кроме GET и POST, предварительно следует уведомить пользователя об изменении ссылки. Не стоить забывать, что некоторые агенты ошибочно меняют метод POST на GET после перехода на другой адрес.
302=»Moved Temporarily» — временно перемещен
Затребованный URI перемешен, но лишь временно. Заголовок Location указывает на новое местонахождение. Сразу же после получения этого кода состояния клиент должен разрешить запрос при помощи нового URI, но во всех последующих запросах необходимо пользоваться старым URI.
При всех методах кроме HEAD сервер должен передать в теле гипертекстовое пояснение. При использовании всех отличных от GET и POST методов предварительно следует уведомить пользователя об изменении URI. При обращении к следующему ресурсу метод POST на GET менять следует как это делают некоторые агенты.
303=»See Other»
Затребованный URI можно найти по другому URI (указанному в заголовке Location). Его следует выбрать методом GET по данному ресурсу.
304=»Not Modified»

Это код ответа на заголовок lf-Modified-Since, если URI не изменялся с указанной даты. Тело содержимого не посылается, и клиент должен использовать свою локальную копию.

305=»Use Proxy»

Доступ к затребованному URI должен осуществляться через proxy-сервер, указанный в заголовке Location.

306=»(Unused)»

307=»Temporary Redirect»

Запрос клиента является неполным (Client Error 4xx)

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

400=»Bad Request»
Означает, что сервер обнаружил в запросе клиента синтаксическую ошибку.
401=»Unauthorized» — требуется авторизация
Этот код результата, передаваемый с заголовком WWW-Authenticate, показывает, что пославший запрос пользователь не имеет необходимых полномочий и что при повторении запроса с указанием данного URI пользователь должен такие полномочия предоставить.
402=»Payment Required»
Этот код в HTTP еще не реализован.
403=»Forbidden»
Запрос отклонен по той причине, что сервер не хочет (или не имеет возможности) ответить клиенту.
404=»Not Found» — не найдено
Документ по указанному URI не существует.
405=»Method Not Allowed» — метод не поддерживается
Этот код выдается с заголовком Allow и показывает, что метод, используемый клиентом, для данного URI не поддерживается.
406=»Not Acceptable»
Ресурс, указанный клиентом по данному URI, существует, но не в том формате, который нужен клиенту. Вместе с этим кодом сервер выдает заголовки Content-Language, Content-Encoding и Content-Type.
407=»Proxy Authentication Required» Прокси-сервер затребовал авторизацию.
Proxy-сервер должен санкционировать запрос перед тем, как пересылать его. Используется с заголовком Proxy-Authenticate.
408=»Request Time-out»
Этот код ответа означает, что клиент не передал полный запрос в течение некоторого установленного промежутка времени (который обычно задается в конфигурации сервера) и сервер разрывает сетевое соединение.
409=»Conflict»
Данный запрос конфликтует с другим запросом или с конфигурацией сервера. Информацию о конфликте следует возвратить в информационной части ответа.
410=»Gone»
Данный код показывает, что затребованный URI больше не существует и навсегда удален с сервера.
411=»Length Required»
Сервер не примет запрос без указанного в нем заголовка Content-Length.
412=»Precondition Failed»
Результат вычисления условия, заданного в запросе одним или несколькими заголовками if. . ., представляет собой «ложь».
413=»Request Entity Too Large»
Сервер не будет обрабатывать запрос, потому что его тело слишком велико.
414=»Request-URI Too Long» — запрос слишком длинный
Сервер не будет обрабатывать запрос, потому что его URI слишком длинный.
415=»Unsupported Media Type»

Сервер не будет обрабатывать запрос, потому что его тело имеет неподдерживаемый формат.

416=»Requested Range Not Satisfiable»

Запрашиваемый диапазон не допустим

417=»Expectation Failed»

Ожидание не удалось

422=»Unprocessable Entity» — сервер успешно принял запрос, может работать с указанным видом данных (например, в теле запроса находится XML-документ, имеющий верный синтаксис), однако имеется какая-то логическая ошибка, из-за которой невозможно произвести операцию над ресурсом.
В некоторых системах используется для передачи требования дополнительных данных: NOT ENOUGH DATA (не хвататет данных) 429=»You exceeded the rate limit»

Превышен лимит запросов

449 — Retry with a proxy in another country.

450=Rating Service Unavailable

451=Unavailable For Legal Reasons

доступ к ресурсу ограничен из-за проблем с законом. 451 — Site is not permitted in your country

452 could be site not permitted by employer,

453 could be site not permitted by ISP

460 Blocked by Repressive Regime

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

Коды ответов в диапазоне 500-599 показывают, что сервер столкнулся с ошибкой и, вероятно, не сможет выполнить запрос клиента.

500=»Internal Server Error»
При обработке запроса на сервере один из его компонентов выдал аварийный отказ или столкнулся с ошибкой конфигурации. Часто бывает связанно с ошибками в файле .htaccess
501=»Not Implemented»
Клиент запросил выполнение действия, которое сервер выполнить не может.
502=»Bad Gateway»
Сервер (или proxy-сервер) получил недопустимые ответы другого сервера (или proxy-сервера).
503=»Service Unavailable»
Данный код означает, что данная служба временно недоступна, но в будущем доступ к ней будет восстановлен. Если сервер знает, когда это произойдет, может быть также выдан заголовок Retry-After.
504=»Gateway Time-out»
Этот ответ похож на 408 (Request Time-out), за исключением того, что шлюз или уполномоченный сервер превысил лимит времени.
505=»HTTP Version not supported»

Сервер не поддерживает версию протокола HTTP, использованную в запросе.

560 — Server is being censored

Ошибки ( Error 7xx)

701 — Your ISP is being a twat.

702 — Your organization is being a twat.

703 — Your government is being a twat

704 — Your ISP is being a twat, and has messed with your DNS request, sending you to a spamvertizement for the domain requested.

705 — Your ISP is throttling / packet shaping the living hell out of your connection.

706 — Variant HTML requested (mobile, Flash-free….lots of flags in here).

707 — The current server time (in ticks since the epoch) & the server’s time zone.

htmlweb.ru

Ответ сервера и его составляющие, которые могут повлиять на SEO

В статье, объясняющей суть передачи данных посредством протокола HTTP (HTTPS), ссылка на которую дана в начале публикации, я писал о том, как в принципе происходит общение между клиентскими приложениями (на примере браузера) и вебсервером, которое основывается на схеме «запрос клиента — ответ сервера».

Напомню вкратце, как это осуществляется. Браузер, после того, как пользователь вводит в адресную строку URL страницы, обращается в ближайший ДНС сервер, где хранятся списки всех доменов (что такое доменное имя?), а также соответствующие им IP-адреса (каждое устройство в интернете имеет свой уникальный айпи, включая серверы, где «живут» сайты).

Получив нужный IP, браузер посылает на соответствующий этому ай-пи сервер запрос GET для получения нужного содержания. Серверное ПО обрабатывает запрос и высылает ответ, включающий содержание вебстраницы в виде HTML-кода, который затем модифицируется веббраузером для отображения контента странички в удобоваримом виде.

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

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

Чтобы практически осуществить проверку ответа сервера на запрос робота поисковой системы Яндекс, можно воспользоваться специальным инструментом, где вводите URL исследуемой страницы, а также выбираете нужного бота из выпадающего списка (кроме основного там присутствуют роботы по зеркалам, по картинкам, по поиску видео и другие):

«>

Чуть ниже я расскажу подробнее, что полезного можно почерпнуть из этих данных. Ведь если мы это поймем, то можем узнать, по какому пути двигаться в плане SEO оптимизации страниц сайта. Ну и обратим внимание на другие онлайн сервисы, посредством которых можно проверить код ответа сервера и просмотреть содержание HTTP заголовков.

HTTP коды состояния — 200, 301, 302, 403, 404, 500 и другие

Код состояния, приходящий в ответе сервера, определяет статус вебстраницы сайта, в отношении которой клиентское приложение отправляет запрос на сервер. Например, HTTP 200 OK означает, что все все содержимое странички передано и будет доступно для просмотра.

Для успешного продвижения главное, чтобы в каждом конкретном случае код состояния был корректным и соответствовал текущему положению вещей. Скажем, если адрес был изменен на постоянной основе по той или иной причине, то в ответе сервера должно быть указано присутствие 301 редиректа (Moved Permanently) в отношении исследуемой страницы (на скриншоте ниже в качестве значения «Location» указан урл страницы, на который осуществлена переадресация):

«>

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

1. 1XX — информационные, в которых сервер сообщает о процессе обработки запроса.

«>

2. 2XX — HTTP коды, информирующие об успешно переданных данных. О 200 OK я уже упомянул, остальные являются его производными.

«>

3. 3XX — переадресация различного вида с одного URL на другой. Например, если 301 означает, что адрес страницы изменен навсегда, то код 302 говорит о временном перенаправлении. В отличие от постоянного 302 редирект не является сигналом поисковым системам для передачи веса страницы со старого адреса, поэтому на практике он используется лишь в исключительных ситуациях, когда является наиболее оптимальным решением.

«>

4. 4XX — HTTP коды ошибок в запросе со стороны клиента. Например, всем известный код статуса 404 означает, что документа по такому адресу на хосте нет.

«>

5. 5XX — ошибка на сервере, в результате которой страница не может быть предоставлена.

«>

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

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

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

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

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

Если взгляните на скриншот выше, где дан ответ сервера, то увидите, что чуть ниже строки с кодом статуса присутствует пояснение, включающее информацию о времени ответа сервера, IP-адресе сайта, кодировке и размере страницы:

«>

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

Какой же должна быть величина времени отклика? Гугл, например, определяет максимальную границу в 200 мс (миллисекунд), но, конечно, чем меньше, тем лучше. Как же увеличить скорость ответа сервера? Для начала попробуйте провести некоторые мероприятия по внутренней оптимизации, вполне возможно, что проблему решит установка плагина кеширования.

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

HTTP заголовки и их значение

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

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

«>

Server — название и версия веб-сервера. В данном примере это nginx, который в силу малого использования ресурсов и гибкости конфигурирования решает задачу оптимизации работы основного сервера Apache и используется с ним в связке.

Date — дата и время возврата содержания запрашиваемой страницы.

Content-Lenght — объем передаваемого контента в байтах (определение единицы информации byte читайте в этой статье).

Connection — соединение. Параметр keep-alive означает, что после выдачи документа соединение с сервером не разрывается и можно отправлять дополнительные запросы.

Vary — этот заголовок позволяет выдать правильный документ при наличии нескольких его версий. Он актуален, например, при применении технологии сжатия страниц, когда в кеше хранится и сжатая, и несжатая версия. При ответе Accept-Encoding в кеше будут находиться различные варианты запрошенной страницы для разных клиентских приложений (агентов).

Cache-Control — управление кешированием. В нашем образце этот заголовок отражает вид кеша, в котором располагается документ (public) и время, в течении которого он должен находиться в кеше (max-age). Значение public указывает, что эта операция применяется к файлам, хранящимся в общедоступном кэше. Параметр max-age выдает время в секундах.

X-Hyper-Cache — специальный заголовок, который многие пользователи WordPress, наверное, сразу идентифицировали. Несомненно, он касается работы плагина кэширования Hyper Cache, который я считаю, пожалуй, лучшим в своем классе. Значение «hit — gzip» показывает, что к кешированной странице применено сжатие методом gzip.

Content-Encoding — способ кодирования (в общем смысле) передаваемого в ответе содержания страницы. В нашем примере было применено сжатие gzip. Это сигнал клиентской программе (User Agent) распаковать содержимое для его корректного восприятия.

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

Content-Type — тип контента, который в этом примере представляет из себя HTML-код в кодировке UTF-8. Некорректное указание кодировки может привести к сложностям в восприятии текста пользователями и ботами ПС, а это чревато непопаданием страницы в индекс.

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

Last-Modified — дата последней модификации веб-страницы. Если клиент (в нашем случае робот Яндекса) получил от сервера этот заголовок с датой обновления контента, то при следующем обращении к URL этой же страницы он отправит серверу в составе запроса If-Modified-Since.

Вебсервер выделит промежуток от времени последних изменений до времени, указанного в заголовке If-Modified-Since. Ежели за этот период страница никоим образом не была изменена, то сервер отправит ответ с HTTP кодом 304 Not Modified, причем в этом случае содержание страницы отправлено не будет. Если же редактирование имело место, то робот получит код 200 ОК вместе с измененным контентом.

Этот механизм, если он настроен верно, позволяет выдавать постоянно свежую информацию. Ведь тут важна актуальность данных, что и обеспечивается правильной реализацией проверки времени последнего обновления. Ведь при неправильной настройке (если дата, указанная в Last-Modified не меняется) робот может получить просто код 304 Not Modified (вместо 200 OK с новой версией документа), хотя контент был несколько раз отредактирован.

Как же можно проверить корректность работы Last-Modified для сервера, на котором расположен ваш сайт? Попробуем разобраться на конкретном примере.

На том же сервисе Яндекса, ссылку на который я уже предложил выше, есть специальная опция, которая позволяет добавить запрос If-Modified-Since и указать нужные вам дату и время (в формате GMT, то есть по Гринвичу, относительно часового пояса Москвы это -3 часа) вплоть до минут, которое определит временной интервал проверки на обновление:

«>

Взгляните на 10 скриншот вверх отсюда, где дан результат проверки в отношении урла одной из страниц моего блога (где отмечены все разделы ответа сервера). Там в части заголовков дано определенное значение Last-Modified, то есть дата последнего обновления. Теперь я включаю показатель If-Modified-Since в запрос и проверяю ответ сервера:

«>

Как видите, получен код 304 Not Modified без содержания вебстраницы, что совершенно верно для данной ситуации, поскольку контент действительно не был обновлен за данный период. Далее для тестирования я добавил небольшой фрагмент текста в этой статье.

Затем я вновь послал запрос от робота Яндекса на сервер, который при правильно работающем механизме кэширования (после обновлении страницы в кеше присутствует последняя версия) должен возвратить ответ 200 ОК с новым содержанием, что и произошло:

«>

Для полного успокоения можно еще просмотреть содержимое заголовка Content-Lenght, которое показывает, что объем контента незначительно, но увеличился (18443 против 18437 до редактирования). Это соответствует действительности, поскольку я именно добавил толику текста. Точно так же вы можете проверить правильность настройки заголовков для своего сервера.

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

«>

Новый адрес, на который был проставлен редирект, и будет присутствовать в заголовке Location. Содержимое страницы в ответе отсутствует, что вполне логично, а вот в пояснении, которое следует за кодом ответа 301 Moved Permanently, указан размер страницы, на урл которой осуществляется переадресация.

Проверка ответа сервера в онлайн сервисах

Далее для полноты картины нелишним будет отметить online сервисы, которые позволяют проверить HTTP ответ сервера. На просторах интернета мне приглянулся вот этот (Checkmy.ru), который обладает достойным функционалом. Проверим теперь на нем отклик сервера, но уже на запрос робота Google для разнообразия:

«>

После активации процесса чуть ниже вы получите ответ со всеми раскладами:

«>

Сервис Checkmy предлагает пользователям не только выбор приложения (User Agent), с которого будет отправлен запрос, но и использования заголовков If-Modified-Since и Accept-Encoding, о которых велась речь выше.

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

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

«>

В заключение отмечу еще сервис, с помощью инструмента которого удачно осуществите массовую проверку отклика сервера сразу для 200 URL, причем есть возможность загрузки архива ZIP с урлами. А на десерт видеролик о том, что такое код 404 Soft и чем он опасен для вебмастеров:

goldbusinessnet.com

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. Вкратце это будет выглядеть так:

  1. Коды с двухсотыми ответами (чаще всего встречается 200 ОК) — все что запросил браузер (или поисковый бот) на сервере имеется и нет никаких преград, чтобы это было отдано (веб-страница в виде Html кода).
  2. Трехсотые коды ответа сервера — документ по запрошенному адресу временно (302 редирект) или постоянно (301 редирект) перемещен. Сервер сообщает роботу новый адрес веб-страницы, а тот в свою очередь по нему переходит.
  3. Четырехсотые ответы — ошибка в запросе, сделанном поисковым роботом или браузером (по мнению сервера, ибо своей вины он в этом не видит). Например, пытаются получить доступ к закрытой информации без авторизации (401) или к странице, доступ к которой для данного пользователя запрещен (403). Ну и, конечно же, знаменитая ошибка 404 (страница не найдена на сервере), про которую я в свое время даже отдельную стать написал.
  4. Пятисотые ответы — сервер признается (посыпая голову пеплом), что виноват в сложившейся нехорошей ситуации он сам (ошибки на стороне сервера). Он может быть перегружен в данный момент из-за высокого наплыва посетителей или в результате Ддос атаки (мне пришлось для защиты от Ddos подключить сайт к CloudFlare). Также он может зависнуть, либо не иметь возможности осуществить запросы к базе данных, ну и еще несколько наиболее частых причин могут вызвать его недоступность.

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

И что не менее важно, все страницы, на которые по каким-либо причинам были проставлены неправильные Урлы (они могут располагаться ведь не только на вашем сайте), отдавали бы код ошибки 404. Если несуществующие веб-страницы будут отдавать код 200, то это может нанести непоправимый урон сайту и продвигать его средствами СЕО будет затруднительно.

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

Код ответа

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

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

Как тупой сервер может запороть ваше умное SEO

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

  1. На последнем скриншоте показано поле Content-Type:
    Content-Type: text/html;charset=UTF-8

    Оно говорит от том, что имеющийся на сервере документ представляет из себя Html файл в кодировке русского языка UTF-8. Правильное указание кодировки очень важно, ибо может вызвать как проблему с прочтение материалов сайта пользователями, так и сложности в ее восприятии поисковыми роботами.

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

  2. Last-Modified — второй камень преткновения (из сонма http ответов веб-сервера поисковому боту), влияющий на продвижение сайта. В этом поле указывается дата изменения документа (последнего обновления информации на данной веб-странице). Робот обязательно смотри в это поле, ибо у него много работы и отвлекаться на просмотр документа, который не изменился с момента его последнего посещения, было бы глупо.

    Поисковый робот делает серверу запрос на загрузку страницы — была ли та изменена за время, прошедшее с его последнего прихода (отправляется в поле if-modified-since с датой последней загрузки документа этим роботом). Сервер сие обращение обрабатывает, и если страница с тех пор была действительно изменена (считывается Last-Modified и сравнивается с датой полученной от робота), то он отдает ее содержимое боту (и код 200 в ответ, естественно). Поисковый индексатор ее переиндексирует и будут учтены все внесенные изменения, например, добавленный контент или ссылки.

    В противном случае (когда Last-Modified не менялся) сервер отдает боту только лишь код 304. В этом случае робот со спокойной душой пойдет дальше. Проблема может заключаться в том, что страницу вы могли уже за это время десять раз изменить, но в индексе поисковика она не обновится, ибо не обновлялся Last-Modified для этого файла. CMS (движки сайтов) довольно часто этим грешат, нужно обязательно все это проверять и при необходимости настраивать. Как? Это уже другой вопрос.

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

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

301 и 302 редиректы (коды ответа сервера) их использование

Бывает, что по каким-либо причинам вы хотите поменять Урл адрес страницы. Например, как уже упоминал чуть выше, захотите перенести статью из одной рубрики в другую (при определенном алгоритме формирования ЧПУ это может повлечь за собой смену Урла). Причин изменения Урлов может быть масса (хотя бы переход с протокола http на защищенный протокол https).

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

Какой редирект использовать при смене Урл адреса страницы?

Как это сделать? В общем-то не сложно, но важно, чтобы сервер при этом выдавал правильный код ответа (301). Вариантов кода ответа для редиректа (перенаправления) при этом обычно используется два:

  1. 301 — документ был перемещен по новому адресу навсегда и в дальнейшем искать его нужно будет только там. В этом случае поисковик в выдаче заменит Урл адрес на новый и лишней переадресации потом происходить уже не будет. Кроме этого, по 301 редиректу передается ссылочный вес (в том числе и Пр), накопленный страницей (правда, не сразу и не факт, что полностью).
  2. 302 — документ был перемещен временно. В этом случае поисковик не будет заменять Урл в выдаче и переносить веса. Какое-то время назад пользоваться 302 редиректом не советовали, но точных причин этого я уже не помню (может быть вы мне напомните).

Если вы не делаете 301 редирект, а просто меняете Урл страницы, то теряете положение (позицию) в выдаче, ибо старый урл, живущий в индексе поисковика, будет отдавать 404 код ответа, а значит со временем будет удален из индекса.

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

Особенно это важно, когда переходите на новый движок сайта (или переносите разделы), т.е. когда меняются Урлы всех страниц сразу, как, например, при cмене доменного имени или переездt сайта на защищенный протокол Https.

В таких случаях обязательно нужно делать постраничный 301 редирект, иначе потеряете весь трафик на очень продолжительный период времени. Причем даже после восстановления он может вернуться не полностью. А при 301 редиректе, скорее всего, все пройдет «чинно и благородно», т.е. практически незаметно в плане снижения трафика из поисковых систем.

Вся имеющаяся внешняя ссылочная масса постепенно перетечет на новые Урлы. 301 редирект устанавливается на постоянной основе несмотря на то, что в индексе поисковика со временем старых Урлов уже не останется.

Сервера бывают разные и редиректы у них настраиваются по разному

Сервер, по сути, тот же компьютер, только в особом (серверном) исполнении. У него есть материнская плата, жесткие диски, процессор и оперативная память. Разве что только нет персонального монитора. Программное обеспечение на него ставится тоже серверное.

Виндовс на веб-серверах используется не часто, ибо эта ОС стоит денег, в то время как большинство аналогов из мира Линукса бесплатны (Debian, CentOS, Ubuntu и другие) — вот они и получили наибольшую популярность.

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

Самой популярной из таких программ является Apache (более трех четвертей серверов с сайтами в интернете работают на ней), ибо она бесплатная, постоянно обновляемая, хорошо оттестированная и имеющая большое количество расширений.

Перед Apache иногда ставят еще и Nginx (как и в случае с этим блогом), который является прокси сервером. Это, кстати, отечественная разработка, постепенно завоевывающая весь мир.

Кроме программы веб-сервера устанавливаются еще и интерпретаторы различных языков серверного программирования. Многие CMS написаны на PHP (Joomla, WordPress) и без интерпретатора этого языка работать не будут, но также имеются и другие.

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

С высокой вероятностью ваш сайт будет работать под управлением веб-сервера Apache, а именно он формирует коды ответа сервера, о которых мы говорили чуть выше.

Особенностью работы с подобными средами является то, что:

  1. У файлов в вебе нет расширений (об этом мы упоминали при разговоре про зеркала). Все, что пытаются изобразить, добавляя через точку к Урлам страниц (типа .html и т.п.), является просто следованием традициям, а точнее привычкам «чайников», коих в интернете около девяносто процентов (включая меня).
  2. Второй особенностью серверных программ является способ их управления, который кардинально отличается от того, к чему мы привыкли в Виндовс. Это не какие-то графические меню, а конфигурационные файлы, в которых прописаны определенные параметры и инструкции для исполнения.

htaccess — файл облегчающий управление сервером Apache

У веб-сервера Apache основной конфигурационный файл называется httpd.conf. Однако, если в нем прописана разрешающая директива, то для каждого каталога сайта на вашем сервере можно будет использовать дополнительный файл конфигурации .htaccess.

Возможности у него такие же, как и у httpd.conf, но все прописанные в нем директивы будут применяться только к той папке, в которой он находится.

Однако, если разместите файл .htaccess в корне, то его действие распространится на весь ваш сайт. Этот способ конфигурирования Apache удобен тем, что доступ к .htaccess, лежащему в корне сайта, можно получить по обычному ФТП соединению с помощью любого ФТП клиента. Редактировать же его можно в любом текстовом или Html редакторе (в том числе и в онлайн редакторе).

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

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

Что же именно можно прописывать в .htaccess? Очень много всего, и для полного и самостоятельного понимания сути вам придется окунуться в мир администрирования серверов и программирования (см. статью про волшебный файл .htaccess). Очень часто в таких записях встречаются так называемые «регулярные выражения», которые позволяют точечно применять прописанные директивы.

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

Хорошим примером может служить склейка зеркал через 301 редирект, описанная в статье по приведенной ссылке или же в первой части данной публикации. Также с помощью записей в .htaccess мы:

  1. Включали Gzip сжатие для ускорения загрузки сайта
  2. Запрещали хотлинкинг (hotlink) в Apache
  3. Настраивали корректную работу вашей RSS ленты при трансляции ее через Фидбернер

ktonanovenkogo.ru


You May Also Like

About the Author: admind

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.