| 100 Continue | Сервер удовлетворён начальными сведениями о запросе. Можно продолжать пересылать заголовки. |
| 101 Switching Protocols | Сервер предлагает перейти на более подходящий для указанного ресурса протокол. Список предлагаемых протоколов сервер обязательно указывает в поле заголовка Update. |
| 102 Processing | Запрос принят, но на его обработку понадобится длительное время. Используется сервером, чтобы клиент не разорвал соединение из-за превышения времени ожидания. |
| 200 OK | Успешный запрос ресурса. |
| 201 Created | В результате успешного выполнения запроса был создан новый ресурс. Сервер должен указать его местоположение в заголовке Location. |
| 202 Accepted | Запрос был принят на обработку, но обработка не завершена. |
| 203 Non-authoritative Information | Успешный запрос ресурса, но в этом случае передаваемая информация была взята не из первичного источника (резервной копии, другого сервера и т. д.) и поэтому может быть неактуальной. |
| 204 No Content | Сервер успешно обработал запрос, но в ответе были переданы только заголовки без тела сообщения. |
| 205 Reset Content | Сервер обязывает сбросить введённые пользователем данные. |
| 206 Partial Content | Сервер удачно выполнил частичный GET возвратив только часть. В заголовке Content-Range сервер указывает байтовые диапазоны содержимого. |
| 207 Multi-Status | Сервер передаёт результаты выполнения сразу нескольких независимых операций. Они помещаются в само тело сообщения в виде XML-документа с объектом multistatus. |
| 208 Already Reported | Члены привязки DAV уже были перечислены в предыдущей части (multistatus) ответа и не включаются снова. |
| 226 IM Used | Заголовок A-IM от клиента был успешно принят и сервер возвращает содержимое с учётом указанных параметров. |
| 300 Multiple Choices | По указанному URI существует несколько вариантов предоставления ресурса по типу MIME, по языку или по другим характеристикам. |
| 301 Moved Permanently | Запрошенный документ был окончательно перенесен на новый URI, указанный в поле Location заголовка. |
| 302 Found | Запрошенный документ временно доступен по другому URI, указанному в заголовке в поле Location. |
| 303 See Other | Документ по запрошенному URI нужно запросить по адресу в поле Location заголовка с использованием метода GET несмотря даже на то, что первый запрашивался иным методом. |
| 304 Not Modified | Клиент запросил документ методом GET, использовал заголовок If-Modified-Since или If-None-Match и документ не изменился с указанного момента. |
| 305 Use Proxy | Запрос к запрашиваемому ресурсу должен осуществляться через прокси-сервер, URI которого указан в поле Location заголовка. |
| 307 Temporary Redirect | Запрашиваемый ресурс короткое время доступен по другому URI (указывается в поле Location заголовка). |
| 308 Permanent Redirect | Запрашиваемый ресурс теперь постоянно находится в другом URI (указывается в поле Location заголовка). Данный код ответа имеет ту же семантику, что и код ответа 301 Moved Permanently, за исключением того, что агент пользователя не должен изменять используемый метод HTTP: если POST использовался в первом запросе, POST должен использоваться и во втором запросе. |
| 400 Bad Request | Запрос не понят сервером из-за наличия синтаксической ошибки. |
| 401 Unauthorized | Запрос требует идентификации пользователя. |
| 402 Payment Required | В настоящий момент этот код не используется |
| 403 Forbidden | Сервер понял запрос, но он отказывается его выполнять из-за ограничений в доступе со стороны клиента к указанному ресурсу. |
| 404 Not Found | Сервер понял запрос, но не нашёл соответствующего ресурса по указанному URI. |
| 405 Method Not Allowed | Указанный клиентом метод нельзя применить к ресурсу. Сервер также должен передать в заголовке ответа поле Allow со списком доступных методов. |
| 406 Not Acceptable | Запрошенный URI не может удовлетворить переданным в заголовке характеристикам. |
| 407 Proxy Authentication Required | Запрос требует идентификации прокси-сервера. |
| 408 Request Timeout | Время ожидания сервером передачи от клиента истекло. |
| 409 Conflict | Запрос не может быть выполнен из-за конфликтного обращения к ресурсу. |
| 410 Gone | Такой ответ сервер посылает, когда ресурс раньше был по указанному URI, но был удалён и теперь недоступен |
| 411 Length Required | Для указанного ресурса клиент должен указать Content-Length в заголовке запроса. |
| 412 Precondition Failed | Ни одно из условных полей заголовка запроса не было выполнено. |
| 413 Payload Too Large | Сервер по каким-то причинам не может передать запрашиваемый объём информации. |
| 414 Request-URI Too Long | Сервер не может обработать запрос из-за слишком длинного указанного URI. |
| 415 Unsupported Media Type | По каким-то причинам сервер отказывается работать с указанным типом данных при данном методе. |
| 416 Requested Range Not Satisfiable | В поле Range заголовка запроса был указан диапазон за пределами ресурса и отсутствует поле If-Range. |
| 417 Expectation Failed | По каким-то причинам сервер не может удовлетворить значению поля Expect заголовка запроса. |
| 418 I’m a teapot | Этот код был введен в 1998 году как одна из традиционных первоапрельских шуток IETF в RFC 2324. |
| 421 Misdirected Request | Запрос был перенаправлен на сервер, не способный дать ответ. |
| 422 Unprocessable Entity | Сервер успешно принял запрос, может работать с указанным видом данных, в теле запроса XML-документ имеет верный синтаксис, но имеется какая-то логическая ошибка из-за которой невозможно произвести операцию над ресурсом. |
| 423 Locked | Целевой ресурс из запроса заблокирован от применения к нему указанного метода. |
| 424 Failed Dependency | Реализация текущего запроса может зависеть от успешности выполнения другой операции. |
| 426 Upgrade Required | Сервер указывает на необходимость обновить протокол. Заголовок ответа должен содержать правильно сформированные поля Upgrade и Connection. |
| 428 Precondition Required | Сервер указывает клиенту на необходимость использования в запросе заголовков условий, наподобие If-Match. |
| 429 Too Many Requests | Клиент попытался отправить слишком много запросов за короткое время, что может указывать, например, на попытку DDoS-атаки. Может сопровождаться заголовком Retry-After, указывающим, через какое время можно повторить запрос. |
| 431 Request Header Fields Too Large | Превышена допустимая длина заголовков. Сервер не обязан отвечать этим кодом, вместо этого он может просто сбросить соединение. |
| 444 Connection Closed Without Response | Сервер не вернул информацию пользователю и закрыл соединение. |
| 449 Retry With | Возвращается сервером если для обработки запроса от клиента поступило не достаточно информации. При этом в заголовок ответа помещается поле Ms-Echo-Request. |
| 451 Unavailable For Legal Reasons | Доступ к ресурсу закрыт по юридическим причинам, например, по требованию органов государственной власти или по требованию правообладателя в случае нарушения авторских прав. |
| 499 Client Closed Request | Клиент закрыл соединение, прежде чем сервер ответит на запрос. |
| 500 Internal Server Error | Внутренняя ошибка сервера, которая не входит в рамки остальных ошибок класса 5xx. |
| 501 Not Implemented | Сервер не поддерживает возможностей, необходимых для обработки запроса. Типичный ответ для случаев, когда сервер не понимает указанный в запросе метод. |
| 502 Bad Gateway | Сервер в роли шлюза или прокси получил сообщение о неудачном выполнении промежуточной операции. |
| 503 Service Unavailable | Сервер временно не имеет возможности обрабатывать запросы по техническим причинам (обслуживание, перегрузка и прочее). В поле Retry-After заголовка сервер может указать время, через которое клиенту рекомендуется повторить запрос. |
| 504 Gateway Timeout | Сервер в роли шлюза или прокси не дождался ответа от вышестоящего сервера для завершения текущего запроса. |
| 505 HTTP Version Not Supported | Сервер не поддерживает или отказывается поддерживать указанную в запросе версию протокола HTTP. |
| 506 Variant Also Negotiates | В результате ошибочной конфигурации выбранный вариант указывает сам на себя из-за чего процесс связывания прерывается. |
| 507 Insufficient Storage | Не хватает места для выполнения текущего запроса. Проблема может быть временной. |
| 508 Loop Detected | Обнаружено бесконечное перенаправление |
| 509 Bandwidth Limit Exceeded | Используется при превышении веб-площадкой отведённого ей ограничения на потребление трафика. |
| 510 Not Extended | На сервере отсутствует расширение, которое планирует использовать клиент. |
| 511 Network Authentication Required | Этот ответ посылается не сервером, которому был предназначен запрос, а сервером-посредником — например, сервером провайдера — в случае, если клиент должен сначала авторизоваться в сети, например, ввести пароль для платной точки доступа к Интернету. Предполагается, что в теле ответа будет возвращена Web-форма авторизации или перенаправление на неё. |
| 520 Unknown Error | Возникает когда сервер CDN не смог обработать ошибку веб-сервера. |
| 521 Web Server Is Down | Возникает когда подключения CDN отклоняются веб-сервером. |
| 522 Connection Timed Out | Возникает когда CDN не удалось подключиться к веб-серверу. |
| 523 Origin Is Unreachable | Возникает когда веб-сервер недостижим. |
| 524 A Timeout Occurred | Возникает при истечении таймаута подключения между сервером CDN и веб-сервером. |
| 525 SSL Handshake Failed | Возникает при ошибке рукопожатия SSL между сервером CDN и веб-сервером. |
| 526 Invalid SSL Certificate | Возникает когда не удаётся подтвердить сертификат шифрования веб-сервера. |
| 599 Network Connect Timeout Error | Ошибка таймаута — сетевые подключения. |
Проверка ответа сервера
С помощью этого инструмента можно проверить код и скорость ответа сервера, наличие gzip сжатия, посмотреть все заголовки ответа, проверить отдачу сервером 304 Not Modified.
Просто введите адрес интересующей вас страницы в соответствующем поле и нажмите «проверить». Тестер поддерживает переадресацию, но не более 10 редиректов в цепочке. Если редиректов больше, то, вероятно, это циклическая бесконечная переадресация, вызванная ошибкой в программе.
При необходимости вы можете добавить заголовки к запросу. Например, If-Modified-Since, User-Agent или любые другие.
От чего зависит время ответа сервера
Скорость ответа сайта зависит от того, насколько быстро сервер обработает запрос и вернет результат. Основная причина слишком медленной реакции сайта — это перегрузка. Сервер не справляется с тем количеством запросов, которое к нему поступает. Чтобы уменьшить время ответа, нужно либо улучшить конфигурацию сервера, либо оптимизировать скрипты и запросы к базе данных. После такой оптимизации сервер будет тратить меньше времени на один запрос и успеет обрабатывать больше количество запросов за единицу времени.
Не существует универсального способа сократить время ответа сервера. В каждом случае должен быть индивидуальный подход к оптимизации нагрузки.
Нормальное время ответа — это сколько?
Чем меньше, тем лучше.
- До 300 миллисекунд — очень хороший результат, можно спать спокойно.
- От 300 до 700 миллисекунд — тоже неплохо, волноваться повода нет.
- Если время ответа вашего сайта приближается к секунде, или ещё выше — повод принимать меры.
Если вы этого ещё не сделали, то рекомендую прямо сейчас проверить скорость ответа вашего сайта. Результат может быть неожиданным для вас. Более того, рекомендую делать это регулярно. Для этого в нашем тестере предусмотрена возможность сохранять проверки. Достаточно один раз сохранить все страницы, которые вы желаете проверять, и далее проверять их мгновенно за 1 клик.
Помните, что скорость ответа влияет не только на восприятие сайта людьми (согласитесь, неприятно, когда при серфинге по сайту наблюдаются задержки при открытии страниц), но и на восприятие сайта поисковыми системами. Давно не секрет, что данный фактор оказывает влияние на ранжирование.
Коды ответов HTTP
Код состояния HTTP — это число, состоящее из трех цифр. Первая цифра означает группу, к которой принадлежит код.
Существуют следующие группы:
- 1xx — Информационные коды
- 2xx — Успешные коды
- 3xx — Коды перенаправлений
- 4xx — Коды ошибок клиента
- 5xx — Коды ошибок сервера
Проверка 304 Not Modified
Правильно настроенный сервер должен обрабатывать заголовок If-Modified-Since. Этот заголовок содержит дату и спрашивает, была ли изменена страница после этой даты. Если страница не была изменена, сервер должен вернуть ответ 304 Not Modified. При этом ответ содержит только заголовки и не содержит тело страницы. Это значительно экономит время и трафик при обходе вашего сайта поисковыми роботами.
Помимо этого, для корректной работы этой схемы сайт должен на каждый GET запрос возвращать заголовок Last-Modified, содержащий дату последнего изменения страницы. Браузеры и поисковые роботы сохраняют эту дату и при следующем запросе используют именно её для заголовка If-Modified-Since как бы спрашивая, изменилась ли страница с тех пор, нужно ли её скачивать заново.
Проверка ответа сайта и загрузки страницы
Тип запроса к серверу
GETPOSTHEAD
Максимальное время загрузки данных*
Параметры для POST-запроса
Сервера для проверки Вашего сайта:
сервер Россия (Москва)
сервер Россия (Санкт-Петербург)
сервер Россия (Новосибирск)
Выбранная страница сайта скачивается на сервера мониторингов по HTTP/HTTPS.
Проверяется скорость загрузки кода страницы или заголовка ответа.
На сервер не скачиваются картинки и дополнительные скрипты, а только код выбранной страницы.
Другие проверки Выберите чтобы перейти к проверке————————————————————Комплексная проверка сайта————————————————————Проверка доступности сайта PINGПроверка загрузки страницы HTTP/HTTPSПроверка ответа от DNSПроверка доменаПроверка сертификатаПроверка сайта на вирусыПроверка доступности FTPПроверка произвольного порта
Эти данные будут собраны онлайн со всех серверов, которые Вы отметили для проверки.
Для того, чтобы статистика о Вашем ресурсе собиралась постоянно — запустите постоянный мониторинг
ЗАПУСТИТЬ ПОСТОЯННЫЙ МОНИТОРИНГ БЕСПЛАТНО!
Для новых пользователей бесплатный мониторинг одного сайта — 15 дней!
Анализ сайта
Для анализа работы сайта недостаточно только одной проверки PING до сервера (проверить доступность сайта), т.к. там передаются только небольшие пакеты.
Для более тщательного анализа, необходимо производить периодическую загрузку страницы на сервера проверок и проверять время загрузки.
Причины медленной загрузки сайта
Скорость загрузки может зависеть от загрузки проверяемого веб-сервера, от скорости и качества его интернет-соединения, от работы промежуточных узлов сети.
Но также все те же проблемы могут быть на проверяющем сервере. Так что для уверенности в мониторинге необходимо проверять ресурс с нескольких серверов одновременно. Для таких целей лучше использовать сервера, которые располагаются на территории потенциальных пользователей сайта, но на удаленности друг от друга. Это уменьшит погрешность результатов мониторинга.
Настройка параметров мониторинга
Вам необходимо выбрать тип запроса к серверу:
GET
скачивание указанной страницы, с переданными параметрами в строке запроса
POST
отправка параметров к странице, и скачивание результирующей страницы (это имитация заполнения формы на сайте, удобно использовать для проверки работоспособности разнообразных сервисов (авторизация пользователя, обратная связь, оставление заявок))
HEAD
принимаются только заголовки ответа сервера на запрос страницы. Вся страница не скачивается. Такая проверка нужна только для проверки доступности сайта и анализа кодов ответа сервера
При проверке необходимо определить максимальное время загрузки данных. Превышение этого времени будет считаться ошибкой.
Также эта проверка сайта позволяет проверять слова на странице, их можно указать через провел или запятую. Если любое из указанных слов перестало быть в ответе страницы — сервис выдаст ошибку.
При необходимости, возможно отметить галочку для перехода по редиректу, если страница может временно перенаправляться на другую.
Но лучше указывать конечную правильную страницу, с правильным протоколом (http или https).
Основные причины необходимости проверок HTTP/HTTPS:
Проверка ответа сервера
Сервер может отвечать на запросы пользователей, но с ошибками. Необходимо постоянно отслеживать ответ сервера.
Работоспособность сайта
Необходимо проверять время ответа сервера и контент, который отдается сервером. Также важно проверять несколько ключевых слов со страницы, чтобы определять возможные ошибки веб-сервера.
Проверка загрузки страницы и ответа сервера — основной метод мониторинга работоспособности сайтов
Если необходимо проверить нестандартный порт сервера — проверить порт
Перед запуском ежеминутного мониторинга попробуйте проверить сайт онлайн
Как контролировать время отклика или как быстро грузится Ваш сайт?
Хорошо известно, что время отклика сервера оказывает непосредственное влияние на индексацию веб-сайта поисковой системой. Чем дольше грузится сайт, тем ниже он ранжируется, а низкие позиции поисковой выдачи имеют ряд негативных следствий: меньшее количество посетителей из поискового трафика, уменьшение показателей конверсии, увеличение количества отказов и тому подобное. Под временем отклика понимается время получения ответа сервера на запросы клиента, которым чаще всего выступает веб-браузер. Время отклика напрямую влияет на скорость загрузки веб-страниц, поэтому эти две характеристики часто путают. ХостТрекер предлагает функцию для измерения этого времени с разных стран и континентов.Связь СЕО и времени отклика
Интернет вмещает в себе кучу самой разнообразной статистики различной степени полезности. Например, можно найти исследования зависимости положения сайта в поисковой выдаче от его времени отклика. Поисковые роботы тоже любят сайты, которые быстро грузятся — веб-сайты с хорошим временем отклика, при прочих равных условиях, чаще всего располагаются на верхних позициях поисковой выдачи. Что же это за хорошее время? Конечно, это зависит от категории сайта, так как разные типы сайтов по умолчанию содержат разное количество контента и разных плюшек. Но для большинства сайтов считается хорошим время загрузки 0.35-0.38 с. Именно такое время, как правило, демонстрируют сайты с ТОП выдачи поисковиков по популярным запросам. До одной секунды также считается хорошим результатом, но на итоговую позицию может влиять разница всего в 0.1 или 0.2 с. Конечно, контент и релевантность по-прежнему остаются на первом месте по влиянию на положение в поисковой выдаче, но при текущем уровне конкуренции хорошие веб-мастера учитывают все больше и больше факторов.
Логично, что при измерении времени отклика следует учитывать географическое расположение сервера с сайтом. Если пользователь из Исландии вдруг решит полазить по австралийским сайтам — то некоторый дискомфорт он, безусловно, испытает. Ведь чем дальше от сервера расположен пользователь, желающий открыть страницы на нем расположенные, тем через большее количество хостов будет идти к нему ответ, а обработка на каждом из них занимает какое-то время (это мы еще о конечности скорости света умолчим). Поэтому крайне желательно размещать свой сайт как можно ближе к своей целевой аудитории. Для глобальных сайтов проблема решается использованием CDN (Content Delivery Network).
Мониторинг времени отклика
Host-Tracker предоставляет несколько возможностей отслеживания времени отклика сервера. Во-первых, время отклика с разных точек мира фиксируется при мгновенной проверке, доступной бесплатно даже для незарегистрированных пользователей. Если же Вам интересна статистика, мониторинг из определенного региона или же оповещения о превышении времени — тогда можно использовать функцию «Проверка времени отклика»; также, эта функция доступна при настройке задания «Проверка сайта (http)» — время отклика настраивается в расширенных настройках http-задания.
В настройках можно указать максимально допустимое время отклика для Вашего сайта. Если сервер не ответил за время, выставленное в поле «Таймаут», тогда Host-Tracker пришлет сообщение, что сайт начал «тормозить». Кстати, это может быть полезным, даже если Вы не боритесь за доли секунды — внезапный или постепенный рост времени отклика может свидетельствовать о различных технических работах, проводимых на сервере, или о перегрузке веб-сервера хостинговой компанией.
Важно также уделить внимание региону, откуда следует вести проверку, так как время отклика сильно зависит от географии расположения сайта. Данная опция настраивается в перечне расширенных настроек задания.
Заключение
Как видим, ХостТрекер может помочь. Наиболее приемлемым значением отклика исследователи называют 0.5 с, что очень важно для индексации сайта и для его ранжирования. С учетом географии, это значение можно ожидать около 1-3 секунд. Если значение отклика стабильно оказывается больше указанного значения, тогда нужно задуматься о смене хостинга или оптимизации сайта.
Инструменты для проверки сайта
см. также:
Инструменты для оптимизации сайта
Экспресс анализ сайта
SEO анализ веб страницы
Цена SEO аудита сайта
Проверка html (html валидатор)
Проверяет html код, как заданный с помощью ссылки на страницу, так и просто в виде загруженного файла или скопированного текста. Дает список замечаний с рекомендациями по их исправлению.
http://validator.w3.org/
Проверка css (css валидатор)
Проверяет стили документа или таблицу стилей, расположенную в отдельном файле.
http://jigsaw.w3.org/css-validator/
Проверка лент (feed) RSS и Atom
Проверяет правильность работы фидов RSS и Atom.
http://validator.w3.org/feed/
Проверка орфографии на веб странице
Подсвечивает ошибки на заданной URL странице.
http://webmaster.yandex.ru/spellcheck.xml
Показывает ошибки в тексте, скопированном в проверочное окно.
http://api.yandex.ru/speller/
Проверка структуры веб страницы
Показывает структуру веб страницы. Актуален для проверки html5 документов.
Неправильно отображает кириллицу (:.
http://gsnedders.html5.org/outliner/
Проверка контента на уникальность
В бесплатной версии показывает до 10 страниц в инете с частичным совпадением текста с вашей страницей.
http://www.copyscape.com
Проверяет уникальность текста введенного в форму. В бесплатной версии возможно ожидание результатов.
http://www.miratools.ru/Promo.aspx
Проверяет уникальность как введенного текста, так и текста по заданному URL, показывает уровень уникальности в процентах.
Имеет собственный алгоритм проверки.
http://content-watch.ru
Десктопные программы для проверки уникальности контента от бирж копирайтеров. Работают долго, но качественно. Etxt имеет версии для трех операционных систем: Mac, Linux и Windows.
http://advego.ru/plagiatus/
http://www.etxt.ru/antiplagiat/
Поиск похожих сайтов
Показывает сайты с похожим содержанием и схожей внутренней структурой.
http://similarsites.com
Проверка cms сайта
Проверяет наличие признаков наиболее известных cms.
http://2ip.ru/cms/
Проверка доступности с мобильных устройств
Оценивает возможность просмотра страницы с мобильных устройств и выдает список замечаний и ошибок.
http://validator.w3.org/mobile/
Проверка удобства сайта для телефонов от Гугл.
https://www.google.com/webmasters/tools/mobile-friendly/
Показывает скорость загрузки сайта на мобильных устройствах.
https://testmysite.withgoogle.com/intl/ru-ru
Сайт эмулятор выхода с мобильного телефона. Показывает сайт глазами выбранной модели.
http://www.mobilephoneemulator.com/
Проверка доступности для людей с ограниченными возможностями
Сервис проверки страницы для слабовидящих. Доступен on-linе и в виде плагина для Firefox.
http://wave.webaim.org/
Просмотр содержания сайта глазами поискового робота
Показывает текст сайта, приближенный к тому, что видит поисковый индексатор.
http://www.seo-browser.com/
Дистрибутив текстового браузер lynx для win32 систем. Перед использованием нужно отредактировать lynx.bat, указав в нем путь к директории с lynx.
http://www.fdisk.com/doslynx/lynxport.htm
Убирает все разметку и показывает текст страницы, мета теги и теги заголовков, число внешних и внутренних ссылок. Показывает превью страницы в google.
http://www.browseo.net
Проверка битых ссылок
Показывает список исходящих ссылок для URL и проверяет их отклик. Может проверять рекурсирвно, то есть переходить от одного документа к другому самостоятельно.
http://validator.w3.org/checklink
Freeware инструмент для проверки битых ссылок. Для работы нужно установить его на свой компьютер. Рекурсивно сканирует сайт, делает отчеты, может быть полезен для составления карты сайта.
http://home.snafu.de/tilman/xenulink.html
Проверка перелинковки и заголовков страниц
Проверяет и показывает внутренние ссылки, заголовки страниц, наличие дублированного контента на сайте. Бесплатно позволяет сканировать сайт 1 раз в 30 дней.
http://www.siteliner.com/
Сканирует до 500 страниц сайта в бесплатной версии. Проверяет число внешних и внутренних ссылок. Выводит информацию о просканированных страницах: вложенность, коды ответа, названия, мета информацию и заголовки.
http://www.screamingfrog.co.uk/seo-spider/
Проверка ссылочной структуры и веса внутренних страниц
Программа сканирует сайт, строит матрицу внутренних ссылок,
добавляет внешние (входящие) ссылки с заданных URL и, на основании этих данных, рассчитывает
внутренние веса страниц сайта. Программа может быть использована для нахождения внешних (исходящих) ссылок для списка URL страниц сайта.
http://www.design-sites.ru/utility/link-analyzer.php
Проверка HTTP заголовков и ответа сервера, видимости страниц для роботов
Проверяет коды ответа сервера, прогнозирует скорость загрузки страницы в зависимости от объема в байтах ее данных,
показывает содержимое html тега head, внутренние и внешние ссылки для страницы, содержимое страницы глазами поискового робота.
http://urivalet.com/
Проверяет коды ответа сервера. Дает возможность проверить редиректы (коды ответа 301, 302), заголовок Last-Modified и др.
http://www.rexswain.com/httpview.html
Показывает объемы и содержимое данных, передаваемых при загрузки страницы.
http://www.websiteoptimization.com/services/analyze/
Проверяет редиректы, использование атрибута canonical, мета теги, некоторые аспекты безопасности сайта. Дает рекомендации по улучшению загрузки страниц.
http://www.seositecheckup.com
Проверка информации о домене и об IP адресе
WHOIS-сервис центра регистрации доменов RU center. Дает информацию по IP адресам и доменам по всему миру. Иногда зависает.
https://www.nic.ru/whois/?wi=1
Служба Whois от РосНИИРОС (RIPN). Дает информацию для доменов в зоне RU и IP адресам из базы RIPE (Европа).
http://www.ripn.net:8080/nic/whois/
Определяет, где у домена хостинг и также показывает IP адрес сайта.
http://www.whoishostingthis.com
Проверка не включен ли IP адрес в черный список для рассылки email.
http://whatismyipaddress.com/blacklist-check
http://ru.smart-ip.net/spam-check/
Проверка MX записей для домена. Проверка SMTP сервера для домена. Проверка IP в черных списках для рассылки.
https://mxtoolbox.com/
Поиск по базе зарегистрированных торговых марок в США.
http://tmsearch.uspto.gov/
Проверка файлов robots.txt
Проверяет доступность для индексации страниц сайта роботом Yandex.
http://webmaster.yandex.ru/robots.xml
Проверяет корректность файла robots.txt.
https://www.websiteplanet.com/webtools/robots-txt
Техосмотр сайта
Мониторинг доступности сайта. Дает возможость подключить один сайт бесплатно с минимальными опциями проверки.
http://www.siteuptime.com
Проверка скорости загрузки сайта. Посылает отчет на email. Имеет платные сервисы мониторинга доступности сайта.
http://webo.in
Проверка скорости загрузки страниц сайта.
http://www.iwebtool.com/speed_test
Видимость сайта в поисковиках
Сервис, показывающий ключевые слова для сайта, по которым он находится в ТОП 20 (первой двадцатке) выдачи Google во времени. Данные о поисковом и рекламном трафике.
http://www.semrush.com/
Положение в ТОП50 yandex и Google. Тиц сайта и PR главной страницы, наличие в важных каталогах, видимость в топе по ВЧ запросам.
http://pr-cy.ru/
Проверка банов и уровня доверия к сайту
Проверка трастовости сайта. Сервис, утверждающий, что он измеряет траст для Яндекса (проверить все равно никто не может :).
http://xtool.ru/
Проверка наложения фильтров Панда и Пингвин от Гугл. Сервис позволяет визуально определить падал ли сайт в даты апдейтов Панда и Пингвин.
http://feinternational.com/website-penalty-indicator/
Проверка Page Rank страниц сайта (при копировании URL в инструмент нужно стереть последнюю букву а потом написать заново).
http://www.prchecker.net/
Проверка истории развития сайта
Показывает историю развития сайта и дает возможность посмотреть скриншоты старых страниц.
http://www.archive.org/web/web.php
История позиций сайта в ТОП Google (ключевые фразы, страницы, заголовки), показателей PR, ТИЦ, Alexa Rank, числа обратных ссылок для популярных сайтов.
http://SavedHistory.com
SEO плагины для проверки сайтов
SEO Doctor — дополнение к Firefox. Показывает ссылки на странице и дает удобный интерфейс к различным SEO сервисам.
http://www.prelovac.com/vladimir/browser-addons/seo-doctor/
SeoQuake — дополнение к Firefox. Показывает важнейшие характериситки сайта: ТИЦ, PR, обратные ссылки, Alexa Rank.
Работает как с выдачей Google, так и с выдачей Yandex. Дает возможность быстрого анализа конкурентов.
http://www.seoquake.com/
IEContextHTML — дополнение к Internet Explorer. Проверяет индексацию ссылок в Yandex и Google, показывает список внешних и внутренних ссылок, позволяет импортировать данные c веб страниц.
http://www.design-sites.ru/utility/ie-context-html.php
Видимость сайта в посковиках в зависимосит от места расположения
Обновляемый список бесплатных прокси серверов, в том числе и Российских.
http://www.checker.freeproxy.ru/checker/last_checked_proxies.php
http://spys.ru/proxys/ru/
Анонимный бесплатный прокси с возможностью представиться из трех стран. Работает с поиском Google.
https://hide.me/en/proxy
Эммуляторы поиска Google в разных странах, путем задания параметров поиска.
http://searchlatte.com/
http://isearchfrom.com/
Проверка позиций в Yandex и Google
Сервис дает возможность глубокой проверки (до 500) позиции сайта по регионам в Yandex.
http://www.design-sites.ru/utility/search-xml.php
Анализ обратных ссылок
Осуществляет анализ ссылочной массы сайта, формирует срезы по различным критериям: тип ссылки, анкоры, страницы. Показывает вес обратных ссылок.
Сервис доступен только для зарегистрированных пользователей.
http://ahrefs.com
Проверка наличая обратных ссылок на сайт
Проверяет наличие бэклинков на сайт в предложенном списке URL (до 100 страниц).
http://webmasters.ru/tools/tracker
см. также:
Инструменты для социально-направленного поиска
PlusOneChecker
Показывает число лайков (plusone) в Google+. Можно вводить сразу список проверяемых URl.
http://www.plusonechecker.net/
Facebook Graph API Explorer
При вводе в поле GET URL адреса страницы сайта (например: http://www.design-sites.ru/utility/express-analys.php) показывает число «Поделиться» и комментариев для этой страницы.
Для работы нужно быть «залогининым» в Facebook.
https://developers.facebook.com/tools/explorer
Показывает популярность в Твиттере, Google+, Facebook, LinkedIn, Pinterest, Delicious, StumbleUpon, Diggs.
http://sharedcount.com
Cool Social
Показывает популярность первой страницы сайта в Твиттере, Google+, Facebook, Delicious, StumbleUpon.
Для российских сайтов данные иногда неверные.
http://www.coolsocial.net
Social-Popularity
Показывает метрику «Поделиться» (Shares) для российских сетей: «В Контакте», «Одноклассники», «Mail.ru», «Ya.ru».
http://www.design-sites.ru/utility/social-popularity.php
Social Crawlytics
Сканирует сайт и формирует отчеты «Shares» основных зарубежных социальных сетей для этих страниц. Регистрирует пользователей через акаунт в твиттере. Отчеты можно видеть уже на следующий день.
https://socialcrawlytics.com
Проверка сайта на вирусы
Dr.Web
Проверяет заданный URL на подозрительный код, показывает подгружаемые скрипты и результаты их проверки.
http://vms.drweb.com/online/
Virus Total
Проверяет URL на вирусы 30 сканерами.
https://www.virustotal.com/#url
Alarmer
Система защиты сайта от вирусов. Ежедневно сканирует файлы сайта и присылает отчет об их изменениях по email.
http://www.design-sites.ru/alarmer.php
Проверка ответа сервера, HTTP-заголовки сервера
Список заголовков HTTP
Список кодов состояния HTTP
Код состояния HTTP (англ. HTTP status code) является частью первой строки ответа сервера. Он представляет собой целое число из трех арабских цифр. Первая цифра указывает на класс состояния. За кодом ответа обычно следует отделённая пробелом поясняющая фраза на английском языке, которая разъясняет человеку причину именно такого ответа.
Клиент узнаёт по коду ответа о результатах его запроса и определяет, какие действия ему предпринимать дальше. Набор кодов состояния является стандартом, и они описаны в соответствующих документах RFC. Введение новых кодов должно производиться только после согласования с IETF. Тем не менее, известно о двух используемых кодах, не упомянутых в RFC: 449 Retry With (введён Microsoft) и 509 Bandwidth Limit Exceeded (введён в cPanel).
Клиент может не знать все коды состояния, но он обязан отреагировать в соответствии с классом кода. В настоящее время выделено пять классов кодов состояния.
Веб-сервер Microsoft Internet Information Services в своих файлах журналов кроме стандартных кодов состояния использует подкоды записывая их через точку после основного. При этом в ответах от сервера данный субкод не размещается — он нужен администратору сервера чтобы тот мог более точно определять источники проблем. Со списком подкодов IIS можно ознакомиться в документе «Коды состояния служб IIS» в Базе знаний Microsoft.
1xx: Informational (Информационные)
В этот класс выделены коды, информирующие о процессе передачи. В HTTP/1.0 сообщения с такими кодами должны игнорироваться. В HTTP/1.1 клиент должен быть готов принять этот класс сообщений как обычный ответ, но ничего серверу отправлять не нужно. Сами сообщения от сервера содержат только стартовую строку ответа и, если требуется, несколько специфичных для ответа полей заголовка. Прокси-сервера подобные сообщения должны отправлять дальше от сервера к клиенту.
100 Continue (Продолжать) — Сервер удовлетворён начальными сведениями о запросе, клиент может продолжать пересылать заголовки. Появился в HTTP/1.1.
101 Switching Protocols (Переключение протоколов) — Сервер предлагает выбрать другой протокол, более соответствующий данному ресурсу. Протоколы предлагаемый сервером, указываются в строке заголовка Update, если предложенный сервером протокол, устраивает клиента, он высылает новый запрос с указанием нового протокола. Появился в протоколе версии HTTP/1.1.
102 Processing (Идёт обработка) — Запрос принят, но на его обработку понадобится длительное время. Используется сервером, чтобы клиент не разорвал соединение из-за превышения времени ожидания. Клиент при получении такого ответа должен сбросить таймер и дожидаться следующей команды в обычном режиме. Появился в WebDAV.
105 Name Not Resolved (Не удается преобразовать DNS-адрес сервера) — При разрешении доменного имени возникла ошибка в связи с неверным или отсутствующем IP-адресом DNS-сервера.
2xx: Success (Успешно)
Сообщения данного класса информируют о случаях успешного принятия и обработки запроса клиента. В зависимости от статуса сервер может ещё передать заголовки и тело сообщения.
200 OK (Хорошо) — Успешный запрос. Если клиентом были запрошены какие-либо данные, то они находятся в заголовке и/или теле сообщения. Появился в HTTP/1.0.
201 Created (Создано) — В результате успешного выполнения запроса был создан новый ресурс. Сервер должен указать его местоположение в заголовке Location. Серверу рекомендуется ещё указывать в заголовке характеристики созданного ресурса (например, в поле Content-Type). Если сервер не уверен, что ресурс действительно будет существовать к моменту получения данного сообщения клиентом, то лучше использовать ответ с кодом 202. Появился в HTTP/1.0.
202 Accepted (Принято) — Запрос был принят на обработку, но она не завершена. Клиенту не обязательно дожидаться окончательной передачи сообщения, так как может быть начат очень долгий процесс. Появился в HTTP/1.0.
203 Non-Authoritative Information (Информация не авторитетна) — Аналогично ответу 200, но в этом случае передаваемая информация была взята не из первичного источника (резервной копии, другого сервера и т. д.) и поэтому может быть неактуальной. Появился в HTTP/1.1.
204 No Content (Нет содержимого) — Сервер успешно обработал запрос, но в ответе были переданы только заголовки без тела сообщения. Клиент не должен обновлять содержимое документа, но может применить к нему полученные метаданные. Появился в HTTP/1.0.
205 Reset Content (Сбросить содержимое) — Сервер обязывает клиента сбросить введённые пользователем данные. Тела сообщения сервер при этом не передаёт и документ обновлять не обязательно. Появился в HTTP/1.1.
206 Partial Content (Частичное содержимое) — Сервер удачно выполнил частичный GET-запрос, возвратив только часть сообщения. В заголовке Content-Range сервер указывает байтовые диапазоны содержимого. Особое внимание при работе с подобными ответами следует уделить кэшированию. Появился в HTTP/1.1.
207 Multi-Status (Многостатусный) — Сервер передаёт результаты выполнения сразу нескольких независимых операций. Они помещаются в само тело сообщения в виде XML-документа с объектом multistatus. Не рекомендуется размещать в этом объекте статусы из серии 1xx из-за бессмысленности и избыточности. Появился в WebDAV.
226 IM Used (Использовано IM) — Заголовок A-IM от клиента был успешно принят и сервер возвращает содержимое с учётом указанных параметров. Введено в RFC 3229 для дополнения протокола HTTP поддержкой дельта-кодирования.
3xx: Redirection (Перенаправление)
Коды класса 3xx сообщают клиенту, что для успешного выполнения операции необходимо сделать другой запрос (как правило по другому URI). Из данного класса пять кодов 301, 302, 303, 305 и 307 относятся непосредственно к перенаправлениям (жарг. редирект). Адрес, по которому клиенту следует произвести запрос, сервер указывает в заголовке Location. При этом допускается использование фрагментов в целевом URI.
По последним стандартам клиент может производить перенаправление автоматически (без запроса пользователя) только если второй ресурс будет запрашиваться методом GET или HEAD. В предыдущих спецификациях говорилось что для избежания круговых переходов пользователя следует спрашивать после 5-го подряд перенаправления. При всех перенаправлениях если метод был не HEAD, то в тело ответа следует включить короткое гипертекстовое сообщение с целевым адресом чтобы в случае чего пользователь смог сам произвести переход.
Разработчики HTTP отмечают что многие клиенты при перенаправлениях с кодами 301 и 302 ошибочно применяют метод GET ко второму ресурсу несмотря на то, что к первому запрос был с иным методом. Чтобы избежать недоразумений в версии HTTP/1.1 были введены коды 303 и 307 вместо 302. Изменять метод нужно только если сервер ответил 303. В остальных случаях следующий запрос производить с исходным методом.
300 Multiple Choices (Несколько вариантов выбора) — По указанному URI существует несколько вариантов предоставления ресурса по типу MIME, по языку или по другим характеристикам. Сервер передаёт с сообщением список альтернатив, давая возможность сделать выбор клиенту автоматически или пользователю. Появился в HTTP/1.0.
301 Moved Permanently (Перемещено навсегда) — Запрошенный документ был окончательно перенесен на новый URI, указанный в поле Location заголовка. Некоторые клиенты некорректно ведут себя при обработке данного кода. Появился в HTTP/1.0.
302 Moved Temporarily / Found (Перемещено временно / Найдено) — Запрошенный документ временно доступен по другому URI, указанному в заголовке в поле Location. Этот код может быть использован, например, при управляемом сервером согласовании содержимого. Некоторые клиенты некорректно ведут себя при обработке данного кода. Введено в HTTP/1.0.
303 See Other (Смотреть другое) — Документ по запрошенному URI нужно запросить по адресу в поле Location заголовка с использованием метода GET несмотря даже на то, что первый запрашивался иным методом. Этот код был введён вместе с 307-ым для избежания неоднозначности, чтобы сервер был уверен, что следующий ресурс будет запрошен методом GET. Например, на веб-странице есть поле ввода текста для быстрого перехода и поиска. После ввода данных браузер делает запрос методом POST, включая в тело сообщения введённый текст. Если обнаружен документ с введённым названием, то сервер отвечает кодом 303, указав в заголовке Location его постоянный адрес. Тогда браузер гарантировано его запросит методом GET для получения содержимого. В противном случае сервер просто вернёт клиенту страницу с результатами поиска. Введено в HTTP/1.1.
304 Not Modified (Не изменялось) — Сервер возвращает такой код, если клиент запросил документ методом GET, использовал заголовок If-Modified-Since или If-None-Match и документ не изменился с указанного момента. При этом сообщение сервера не должно содержать тела. Появился в HTTP/1.0.
305 Use Proxy (Использовать прокси) — Запрос к запрашиваемому ресурсу должен осуществляться через прокси-сервер, URI которого указан в поле Location заголовка. Данный код ответа могут использовать только исходные HTTP-сервера (не прокси). Введено в HTTP/1.1.
306 (Зарезервировано, код использовался только в ранних спецификациях) — Использовавшийся раньше код ответа, в настоящий момент зарезервирован. Упомянут в RFC 2616 (обновление HTTP/1.1).
307 Temporary Redirect (Временное перенаправление) — Запрашиваемый ресурс на короткое время доступен по другому URI, указанный в поле Location заголовка. Этот код был введён вместе с 303 вместо 302-го для избежания неоднозначности. Введено в RFC 2616 (обновление HTTP/1.1).
4xx: Client Error (Ошибка клиента)
Класс кодов 4xx предназначен для указания ошибок со стороны клиента. При использовании всех методов, кроме HEAD, сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя.
400 Bad Request (Плохой запрос) — Сервер обнаружил в запросе клиента синтаксическую ошибку. Появился в HTTP/1.0.
401 Unauthorized (Неавторизован) — Для доступа к запрашиваемому ресурсу требуется аутентификация. В заголовке ответ должен содержать поле WWW-Authenticate с перечнем условий аутентификации. Клиент может повторить запрос, включив в заголовок сообщения поле Authorization с требуемыми для аутентификации данными.
402 Payment Required (Необходима оплата) — Предполагается использовать в будущем. В настоящий момент не используется. Этот код предусмотрен для платных пользовательских сервисов, а не для хостинговых компаний. Имеется в виду, что эта ошибка не будет выдана хостинговым провайдером в случае просроченной оплаты его услуг. Зарезервирован, начиная с HTTP/1.1.
403 Forbidden (Запрещено) — Сервер понял запрос, но он отказывается его выполнять из-за ограничений в доступе для клиента к указанному ресурсу. Если для доступа к ресурсу требуется аутентификация средствами HTTP, то сервер вернёт ответ 401 или 407 при использовании прокси. В противном случае ограничения были заданы администратором сервера или разработчиком веб-приложения и могут быть любыми в зависимости от возможностей используемого программного обеспечения. В любом случае клиенту следует сообщить причины отказа в обработке запроса. Наиболее вероятными причинами ограничения может послужить попытка доступа к системным ресурсам веб-сервера (например, файлам .htaccess или .htpasswd) или к файлам, доступ к которым был закрыт с помощью конфигурационных файлов, требование аутентификации не средствами HTTP, например, для доступа к системе управления содержимым или разделу для зарегистрированных пользователей либо сервер не удовлетворён IP-адресом клиента, например, при блокировках. Появился в HTTP/1.0.
404 Not Found (Не найдено) — Самая распространенная ошибка при пользовании Интернетом, основная причина — ошибка в написании адреса Web-страницы. Сервер понял запрос, но не нашёл соответствующего ресурса по указанному URI. Если серверу известно, что по этому адресу был документ, то ему желательно использовать код 410. Ответ 404 может использоваться вместо 403, если требуется тщательно скрыть от посторонних глаз определённые ресурсы. Появился в HTTP/1.0.
405 Method Not Allowed (Метод не поддерживается) — Указанный клиентом метод нельзя применить к текущему ресурсу. В ответе сервер должен указать доступные методы в заголовке Allow, разделив их запятой. Эту ошибку сервер должен возвращать, если метод ему известен, но он не применим именно к указанному в запросе ресурсу, если же указанный метод не применим на всём сервере, то клиенту нужно вернуть код 501 (Not Implemented). Появился в HTTP/1.1.
406 Not Acceptable (Неприемлемо) — Запрошенный URI не может удовлетворить переданным в заголовке характеристикам. Если метод был не HEAD, то сервер должен вернуть список допустимых характеристик для данного ресурса. Появился в HTTP/1.1.
407 Proxy Authentication Required (Необходима прокси авторизация) — Ответ аналогичен коду 401 за исключением того, что аутентификация производится для прокси-сервера. Механизм аналогичен идентификации на исходном сервере. Появился в HTTP/1.1.
408 Request Timeout (Истекло время ожидания) — Время ожидания сервером передачи от клиента истекло. Клиент может повторить аналогичный предыдущему запрос в любое время. Например, такая ситуация может возникнуть при загрузке на сервер объёмного файла методом POST или PUT. В какой-то момент передачи источник данных перестал отвечать, например, из-за повреждения компакт-диска или потери связи с другим компьютером в локальной сети. Пока клиент ничего не передаёт, ожидая от него ответа, соединение с сервером держится. Через некоторое время сервер может закрыть соединение со своей стороны, чтобы дать возможность другим клиентам сделать запрос. Этот ответ не возвращается, когда клиент принудительно остановил передачу по команде пользователя или соединение прервалось по каким-то иным причинам, так как ответ уже послать невозможно. Появился в HTTP/1.1.
409 Conflict (Конфликт) — Запрос не может быть выполнен из-за конфликтного обращения к ресурсу. Такое возможно, например, когда два клиента пытаются изменить ресурс с помощью метода PUT.Появился в HTTP/1.1.
410 Gone (Удалён) — Такой ответ сервер посылает, если ресурс раньше был по указанному URL, но был удалён и теперь недоступен. Серверу в этом случае неизвестно и местоположение альтернативного документа, например, копии). Если у сервера есть подозрение, что документ в ближайшее время может быть восстановлен, то лучше клиенту передать код 404. Появился в HTTP/1.1.
411 Length Required (Необходима длина) — Для указанного ресурса клиент должен указать Content-Length в заголовке запроса. Без указания этого поля не стоит делать повторную попытку запроса к серверу по данному URI. Такой ответ естественен для запросов типа POST и PUT. Например, если по указанному URI производится загрузка файлов, а на сервере стоит ограничение на их объём. Тогда разумней будет проверить в самом начале заголовок Content-Length и сразу отказать в загрузке, чем провоцировать бессмысленную нагрузку, разрывая соединение, когда клиент действительно пришлёт слишком объёмное сообщение. Появился в HTTP/1.1.
412 Precondition Failed (Условие ложно) — Возвращается, если ни одно из условных полей заголовка запроса не было выполнено. Появился в HTTP/1.1.
413 Request Entity Too Large (Размер запроса слишком велик) — Возвращается в случае, если сервер отказывается обработать запрос по причине слишком большого размера тела запроса. Сервер может закрыть соединение, чтобы прекратить дальнейшую передачу запроса. Если проблема временная, то рекомендуется в ответ сервера включить заголовок Retry-After с указанием времени, по истечении которого можно повторить аналогичный запрос. Появился в HTTP/1.1.
414 Request-URI Too Large (Запрашиваемый URI слишком длинный) — Сервер не может обработать запрос из-за слишком длинного указанного URL. Такую ошибку можно спровоцировать, например, когда клиент пытается передать длинные параметры через метод GET, а не POST. Появился в HTTP/1.1.
415 Unsupported Media Type (Неподдерживаемый тип данных) — По каким-то причинам сервер отказывается работать с указанным типом данных при данном методе. Появился в HTTP/1.1.
416 Requested Range Not Satisfiable (Запрашиваемый диапазон не достижим) — в поле Range заголовка запроса был указан диапазон за пределами ресурса и отсутствует поле If-Range. Если клиент передал байтовый диапазон, то сервер может вернуть реальный размер в поле Content-Range заголовка. Данный ответ не следует использовать при передаче типа multipart/byteranges. Введено в RFC 2616 (обновление HTTP/1.1).
417 Expectation Failed (Ожидаемое неприемлемо) — По каким-то причинам сервер не может удовлетворить значению поля Expect заголовка запроса. Введено в RFC 2616 (обновление HTTP/1.1).
418 I’m a teapot (Я — чайник) — Этот код был введен в 1998 году как одна из традиционных первоапрельских шуток IETF в RFC 2324, Hyper Text Coffee Pot Control Protocol. Не ожидается, что данный код будет поддерживаться реальными серверами.
422 Unprocessable Entity (Необрабатываемый экземпляр) — Сервер успешно принял запрос, может работать с указанным видом данных, в теле запроса XML-документ имеет верный синтаксис, но имеется какая-то логическая ошибка, из-за которой невозможно произвести операцию над ресурсом. Введено в WebDAV.
423 Locked (Заблокировано) — Целевой ресурс из запроса заблокирован от применения к нему указанного метода. Введено в WebDAV.
424 Failed Dependency (Невыполненная зависимость) — Реализация текущего запроса может зависеть от успешности выполнения другой операции. Если она не выполнена и из-за этого нельзя выполнить текущий запрос, то сервер вернёт этот код. Введено в WebDAV.
425 Unordered Collection (Неупорядоченный набор) — используется в расширении WebDAV Advanced Collections Protocol. Посылается, если клиент указал номер элемента в неупорядоченном списке, или запросил несколько элементов в порядке, отличающемся от серверного.
426 Upgrade Required (Необходимо обновление) — Сервер указывает клиенту на необходимость обновить протокол. Заголовок ответа должен содержать правильно сформированные поля Upgrade и Connection. Введено в RFC 2817 для возможности перехода к TLS посредством HTTP.
428 Precondition Required (Необходимо предусловие) — Сервер указывает клиенту на необходимость использования в запросе заголовков условий, наподобие If-Match. Введено в черновике стандарта RFC 6585.
429 Too Many Requests (Слишком много запросов) — Клиент попытался отправить слишком много запросов за короткое время, что может указывать, например, на попытку DoS-атаки. Может сопровождаться заголовком Retry-After, указывающим, через какое время можно повторить запрос. Введено в черновике стандарта RFC 6585.
431 Request Header Fields Too Large (Поля заголовка запроса слишком большие) — Превышена допустимая длина заголовков. Сервер не обязан отвечать этим кодом, вместо этого он может просто сбросить соединение. Введено в черновике стандарта RFC 6585.
434 Requested host unavailable. (Запрашиваемый адрес недоступен) — Запрашиваемый адрес недоступен.
449 Retry With (Повторить с) — Возвращается сервером, если для обработки запроса от клиента поступило недостаточно информации. При этом в заголовок ответа помещается поле Ms-Echo-Request. Введено корпорацией Microsoft для WebDAV. В настоящий момент как минимум используется программой Microsoft Money.
451 Unavailable For Legal Reasons (Недоступно по юридическим причинам) — Доступ к ресурсу закрыт по юридическим причинам, например, по требованию органов государственной власти или по требованию правообладателя в случае нарушения авторских прав. Введено в черновике IETF за авторством Google, при этом код ошибки является отсылкой к роману Рэя Брэдбери «451 градус по Фаренгейту».
456 Unrecoverable Error (Некорректируемая ошибка) — Возвращается сервером, если обработка запроса вызывает некорректируемые сбои в таблицах баз данных. Введено корпорацией Microsoft для WebDAV.
499 () — Используется Nginx, когда клиент закрывает соединение до получения ответа.
5xx: Server Error (Ошибка сервера)
Коды 5xx выделены под случаи неудачного выполнения операции по вине сервера. Для всех ситуаций, кроме использования метода HEAD, сервер должен включать в тело сообщения объяснение, которое клиент отобразит пользователю.
500 Internal Server Error (Внутренняя ошибка сервера) — Любая внутренняя ошибка сервера, которая не входит в рамки остальных ошибок класса. Появился в HTTP/1.0.
501 Not Implemented (Не реализовано) — Сервер не поддерживает возможностей, необходимых для обработки запроса. Типичный ответ для случаев, когда сервер не понимает указанный в запросе метод. Если же метод серверу известен, но он не применим к данному ресурсу, то нужно вернуть ответ 405. Появился в HTTP/1.0.
502 Bad Gateway (Плохой, ошибочный шлюз) — Сервер, выступая в роли шлюза или прокси-сервера, получил недействительное ответное сообщение от вышестоящего сервера. Появился в HTTP/1.0.
503 Service Unavailable (Сервис недоступен) — Сервер временно не имеет возможности обрабатывать запросы по техническим причинам (обслуживание, перегрузка и прочее). В поле Retry-After заголовка сервер может указать время, через которое клиенту рекомендуется повторить запрос. Хотя во время перегрузки очевидным кажется сразу разрывать соединение, эффективней может оказаться установка большого значения поля Retry-After для уменьшения частоты избыточных запросов. Появился в HTTP/1.0.
504 Gateway Timeout (Шлюз не отвечает) — Сервер в роли шлюза или прокси-сервера не дождался ответа от вышестоящего сервера для завершения текущего запроса. Появился в HTTP/1.1.
505 HTTP Version Not Supported (Версия HTTP не поддерживается) — Сервер не поддерживает или отказывается поддерживать указанную в запросе версию протокола HTTP. Появился в HTTP/1.1.
506 Variant Also Negotiates (Вариант тоже проводит согласование) — В результате ошибочной конфигурации выбранный вариант указывает сам на себя, из-за чего процесс связывания прерывается. Экспериментальное. Введено в RFC 2295 для дополнения протокола HTTP технологией Transparent Content Negotiation.
507 Insufficient Storage (Переполнение хранилища) — Не хватает места для выполнения текущего запроса. Проблема может быть временной. Введено в WebDAV.
508 Loop Detected (Обнаружена петля) —
509 Bandwidth Limit Exceeded (Исчерпана пропускная ширина канала) — Используется при превышении веб-площадкой отведённого ей ограничения на потребление трафика. В данном случае владельцу площадки следует обратиться к своему хостинг-провайдеру. В настоящий момент данный код не описан ни в одном RFC и используется только модулем «bw/limited», входящим в панель управления хостингом cPanel, где и был введён.
510 Not Extended (Нет расширения) — На сервере отсутствует расширение, которое желает использовать клиент. Сервер может дополнительно передать информацию о доступных ему расширениях. Введено в RFC 2774 для дополнения протокола HTTP поддержкой расширений.
511 Network Authentication Required (Требуется сетевая аутентификация) — Этот ответ посылается не сервером, которому был предназначен запрос, а сервером-посредником — например, сервером провайдера — в случае, если клиент должен сначала авторизоваться в сети, например, ввести пароль для платной точки доступа к Интернету. Предполагается, что в теле ответа будет возвращена Web-форма авторизации или перенаправление на неё. Введено в черновике стандарта RFC 6585.
Время ответа сервера: как проверить, как сократить, что делать при появлении ошибки Долгий ответ сервера в Яндекс.Вебмастер?
Время ответа сервера – это время, которое проходит между отправкой запроса серверу и получением первой информации от него. Например, при запросе страницы с сайта сервер в ответ присылает информацию о содержании страницы.
Скорость ответа сервера – один из важнейших показателей для продвижения, поскольку связан со скоростью работы сайта в целом. Чем быстрее пользователь начнет получать информацию, тем быстрее загрузится страница в браузере. Из-за медленной загрузки страниц пользователи могут покидать сайт, а поисковые системы – понижать его позиции в поиске.
Какое должно быть время ответа сервера?
Рекомендуемые показатели следующие:
- Максимальный приемлемый показатель – до 200 мс.
- Оптимальный показатель – до 50 мс.
Практика показывает, что даже на виртуальном хостинге при выполнении рекомендаций по оптимизации времени отклика получается добиться показателей 20-30 мс.
Как проверить скорость ответа сервера?
Воспользуйтесь инструментом «Проверка ответа сервера» в Яндексе. В форме необходимо ввести адрес страницы (это может быть главная страница сайта или внутренняя), которую вы хотите проверить, и нажать на кнопку «Проверить».
Внизу формы появятся результаты проверки:
Здесь можно посмотреть код ответа сервера (должен быть 200 для существующих страниц), IP сайта, кодировку, размер страницы, а также – время ответа в мс. В нашем случае – это 23 мс.
Если время ответа сервера превышает 50 мс, лучше провести работы по оптимизации показателя. Если время превышает 200 мс, данные работы необходимо провести обязательно.
Критичная ошибка «Долгий ответ сервера» в Яндекс.Вебмастер. Что делать?
Если сервер отвечает очень долго, Яндекс посчитает это критичной ошибкой и выведет соответствующее уведомление в Яндекс.Вебмастере на вкладке «Диагностика сайта»:
Согласно информации в помощи Яндекс.Вебмастера, критичные ошибки могут привести к ухудшению ранжирования или полному исключению сайта из поиска.
Если вы получили уведомление об ошибке «Долгий ответ сервера», сразу принимайте меры:
- Проверьте время ответа сервера у страниц вашего сайта. При появлении ошибки в Яндекс.Вебмастере можно посмотреть список страниц, при загрузке которых возникли проблемы.
- Если время ответа сервера превышает 200 мс, следуйте рекомендациям по улучшению данного показателя. Они будут написаны ниже. После улучшения показателя нажмите на кнопку «Проверить» справа от ошибки (на скриншоте выше кнопка уже нажата).
- Если время ответа сервера не превышает 200 мс, напишите в поддержку Яндекс.Вебмастер. Возможно, уведомление получено по ошибке или в момент визита роботов наблюдались временные сбои. В любом случае, лучше разобраться в ситуации.
Как сократить время ответа сервера?
Данный показатель зависит от настроек сервера, количества запросов к базе данных при загрузке сайта, настроек самого сайта.
Чтобы уменьшить время ответа сервера:
- Сократите количество запросов к базе данных. Например, в шаблонах WordPress прописано несколько обращений к базе, в которых берется название сайта, адрес файла с CSS и другие параметры, статичные для конкретного проекта. Вместо запросов в шаблоне можно прописать данные вашего сайта, и количество запросов к базе сократится. Если вы не являетесь специалистом, то можете заказать услуги по ускорению сайта в компании 1PS.ru или у программистов-фрилансеров.
- Включите кеширование сайта. Это позволит значительно уменьшить время ответа сервера на WordPress и других системах управления. Например, в случае блога http://adblogger.ru/ пришло уведомление из Яндекса о долгом ответе сервера. Проверка показала, что сервер отвечает за 500-550 мс. Проблема оказалась в плагине кеширования, который не работал. После исправления ошибки время ответа сервера сократилось до 20-25 мс.
- Обратитесь к специалистам, которые помогут оптимально настроить ваш хостинг.
- В ряде случаев сервер отвечает долго из-за нехватки ресурсов. В этом случае поможет приобретение новых ресурсов или переезд на более мощное оборудование.
Выводы
Время ответа сервера – это важный показатель, который стоит отслеживать. При превышении рекомендуемых значений необходимо провести работы по оптимизации скриптов сайта и настроек хостинга. Чем быстрее грузится ваш проект, тем меньше пользователей будут уходить с него и тем выше могут быть позиции вашего ресурса в поиске.
Читайте также: