Повний посібник із кодів статусу HTTP. Повний посібник із кодів статусу HTTP HTTP заголовки та їх значення

Здрастуйте, шановні читачі блогу сайт. Сьогодні я хочу розглянути коди стану та HTTP заголовки, що входять як складові у відповідь сервера і дають цінну інформацію про роботу сайту. Ну і розберемо які інструменти дозволяють їх перевірити.

Цей матеріал буде логічним продовженням попередньої статті, де я представив загальну інформацію про , які служать ні більше ні менше як "транспортним засобом" для передачі гіпертексту (), що є змістом будь-якої сторінки веб-ресурсу.

Якщо при запитах на сервер кожна сторінка вашого сайту віддає відповідь з коректним кодом, це буде великим вкладом у його успішне просування. І навпаки, код, що не відповідає стану вебсторінки, може сильно зіпсувати життя вебмайстру і ініціювати просідання позицій. Тому я раджу не нехтувати цим аспектом і приділити йому належну увагу, хоча б загалом ознайомившись із цією статтею.

Відповідь сервера та його складові, які можуть вплинути на SEO

У статті, що пояснює суть передачі даних за допомогою протоколу HTTP (HTTPS), посилання на яку дано на початку публікації, я писав про те, як у принципі відбувається спілкування, яке ґрунтується на схемі "запит клієнта - відповідь сервера".

Нагадаю коротко, як це здійснюється. Браузер, після того, як користувач вводить в адресний рядок URL сторінки, звертається до найближчого ДНС сервера, де зберігаються списки всіх доменів (), а також відповідні їм IP-адреси (кожен пристрій в інтернеті має , включаючи сервери, де "живуть" сайти ).

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

Але, як кажуть, не браузером єдиним ... Аналогічно з сервером може "вести діалог" будь-яка клієнтська програма, яка забезпечена необхідним для цього функціоналом, у тому числі роботи пошукових систем. Принципи механізму подібної взаємодії для різних програм абсолютно тотожні, різниця лише в деталях.

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

Щоб практично здійснити перевірку відповіді сервера на запит робота пошукової системи Яндекс, можна скористатися спеціальним інструментом , де вводите URL досліджуваної сторінки, а також вибираєте потрібного бота зі списку, що випадає (крім основного там присутні роботи по дзеркалах, по картинках, з пошуку відео та інші) :

Трохи нижче я розповім докладніше, що корисного можна отримати з цих даних. Адже якщо ми це зрозуміємо, то можемо дізнатися, яким шляхом рухатися в плані SEO оптимізації сторінок сайту. Ну і звернемо увагу на інші онлайн сервіси, за допомогою яких можна перевірити код відповіді сервера та переглянути зміст HTTP заголовків.

HTTP коди стану - 200, 301, 302, 403, 404, 500 та інші

Код стану, що надходить у відповідь сервера, визначає статус веб-сторінки сайту, щодо якої клієнтська програма надсилає запит на сервер. Наприклад, HTTP 200 OKозначає, що весь вміст сторінки передано і буде доступним для перегляду.

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

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

1. 1XX- Інформаційні, в яких сервер повідомляє про процес обробки запиту.

2. 2XX- HTTP коди, що інформують про успішно передані дані. Про 200 OK я вже згадав, решта його похідних.

3. 3XX— переадресація різних видів з одного URL на інший. Наприклад, якщо 301 означає, що адресу сторінки змінено назавжди, код 302 говорить про тимчасове перенаправлення. На відміну від постійного 302, редирект не є сигналом пошуковим системам для передачі ваги сторінки зі старої адреси, тому на практиці він використовується лише у виняткових ситуаціях, коли є найбільш оптимальним рішенням.

4. 4XX- HTTP коди помилок у запиті з боку клієнта. Наприклад, всім відомий код статусу 404 означає, що документа за такою адресою на хості немає.

5. 5XX— помилка на сервері, внаслідок якої сторінка не може бути надана.

Докладніший список кодів стану, які надаються в HTTP відповіді сервера, можна отримати, якщо відвідаєте відповідну сторінку Вікіпедії .

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

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

Але якщо навіть подібний форс-мажор станеться, своєчасна перевірка коду стану допоможе вчасно виявити цю неприємність та виправити її наслідки з мінімальними витратами часу та сил, які можуть знадобитися для інших важливих справ щодо оптимізації сайту.

Якщо у вас стандартний віртуальний хостинг, то звернення на техпідтримку вашого часто виявляється найкращим рішенням. Якщо ваш ресурс розташований на виділеному сервері, то проблему, швидше за все, доведеться вирішувати самому, але головне, що ви не тільки знаєте про її існування, але і "звідки у неї ноги ростуть".

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

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

Якою має бути величина часу відгуку? Google, наприклад, визначає максимальну межу в 200 мс (мілісекунд), але, звичайно, чим менше, тим краще. Як збільшити швидкість відповіді сервера? Для початку спробуйте провести деякі заходи, цілком можливо, що проблему вирішить установка плагіна кешування.

Можливо, що вжиті вами дії допоможуть мало, оскільки багато залежить від налаштувань та потужностей програмного забезпечення самого сервера. Тоді є сенс звернутися до серверного адміністратора хостингу. Якщо чіткої відповіді не отримаєте, а час відгуку сервера сильно перевищує ліміт, зазначений вище, варто подумати про принаймні у вигляді зміни провайдера.

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

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

Server- Назва та версія веб-сервера. У цьому прикладі це nginx, що з малого використання ресурсів і гнучкості конфігурування вирішує завдання оптимізації роботи основного сервера Apache і використовується з ним у зв'язці.

Date— дата і час повернення змісту сторінки, що запитується.

Content-Lenght- Об'єм переданого контенту в байтах ().

Connection- З'єднання. Параметр keep-alive означає, що після видачі документа з'єднання з сервером не розривається і можна надсилати додаткові запити.

Vary— цей заголовок дозволяє видати правильний документ за наявності кількох його версій. Він актуальний, наприклад, при застосуванні технології стиснення сторінок, коли в кеші зберігається і стиснена версія, і стиснута. При відповіді Accept-Encoding у кеші будуть різні варіанти запитаної сторінки для різних клієнтських додатків (агентів).

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

X-Hyper-Cache- Спеціальний заголовок, який багато користувачів WordPress, напевно, відразу ідентифікували. Безперечно, він стосується роботи, яку я вважаю, мабуть, найкращим у своєму класі. Значення «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 Відмінно, причому в цьому випадку зміст сторінки не надіслано. Якщо ж редагування мало місце, то робот отримає код 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 і чим він небезпечний для вебмайстрів:

Сторінка 404 покликана повідомляти користувачеві, що заданий url (адреса сторінки) не існує.
Такі неправильні урли ще можна назвати "битими посиланнями".
Багато сайтів роблять свої сторінки 404 для зручності своїх користувачів. Часто це красиві та цікаві сторінки, які викликають у користувача посмішку замість розчарування від того, що адреса сторінки неправильна.
При створенні сторінки 404 є важлива технічна складова, яка сильно впливає на ранжування сайтів у пошукових системах, якщо все правильно не налаштовано.

Якщо ви спантеличувались створенням сторінки 404, то вам потрібно враховувати три моменти:
1) Переадресація з усіх неправильно введених URL на сторінку 404 в.htaccess.
2) Правильна відповідь сервера після переадресації (http-код сторінки має бути 404, а не 200).
3) Закриття сторінки 404 від індексації у robots.txt

Відразу зазначу, що все вищезазначене написано для самописних сайтів, переважно на php. Для wordpress існують плагіни з налаштування того самого. Але в цій статті ми розглянемо, як все виглядає насправді. %)

Переадресація (редирект) неправильних url на сторінку 404

Перше, що ви робите – створюєте саму сторінку 404, щоб було куди людей посилати %).
Перенаправлення URL налаштовується у файлі.htaccess
Просто вписуєте рядок:
ErrorDocument 404 http://mysite.com/404.php
Де «mysite.com» – ваш домен, а http://mysite.com/404.php – шлях до реальної сторінки. Якщо ваш сайт на html, то рядок буде виглядати як:
ErrorDocument 404 http://mysite.com/404.html
Перевірка дуже проста. Після заливки на хостинг файлу.htaccess з вищевказаним рядком, робите перевірку, вводячи урл (бите посилання), що свідомо не існує, наприклад: http://mysite.com/$%$%
Якщо переадресація на створену вами сторінку відбулася, то все працює.
Отже, повністю файл.htaccess, де налаштована ТІЛЬКИ переадресація на 404 виглядатиме так:
____________________________
RewriteEngine on
ErrorDocument 404 http://mysite.com/404.html
____________________________

Правильна відповідь сервера (http-код сторінки)

Дуже важливо, щоб при перенаправленні була правильна відповідь сервера, а саме 404 Not Found.
Тут слід пояснити окремо.

Будь-якому URL при запиті призначається статус (http-сторінки).
Для всіх існуючих сторінок це: HTTP/1.1 200 OK
Для сторінок перенаправлених: HTTP/1.1 302 Found
Якщо сторінки не існує, це має бути HTTP/1.1 404 Not Found

Тобто, який би урл не було введено, йому надається статус, певний код відповіді сервера.
Перевірити відповідь сервера можна на такому ресурсі, як bertal.ru або SEARCH CONCOLE GOOGLE – Сканування/Подивитися як GOOGLE бот.
Коли у вас не було перенаправлення через.htaccess на сторінку 404, то на будь-який неіснуючий урл, введений користувачем, а також на биті посилання була відповідь «HTTP/1.1 404 Not Found»

Після того, як ви налаштували перенаправлення на свою авторську сторінку 404 через.htaccess, як описано вище, то вводячи бите посилання (невірний url, який не існує), типу http://mysite.com/$%$% , відповідь сервера буде:
- спочатку HTTP/1.1 302 Found (перенаправлення),
- а потім HTTP/1.1 200 OK (сторінка існує).

Перевірте через bertal.ru.
Чим це загрожує? Це означатиме, що Google у свою базу даних (індекс) може внести всі биті посилання, як існуючі сторінки зі змістом сторінки 404. По суті - дублі сторінок. А це надзвичайно шкідливо для пошукової оптимізації.

В цьому випадку потрібно зробити дві речі:
1) Налаштувати правильну відповідь сервера на сторінці 404.
2) Закрити від індексування сторінку 404. Це робиться через файл robots.txt

Налаштовуємо відповідь сервера HTTP/1.1 404 Not Found для неіснуючих сторінок

Відповідь сервера налаштовується завдяки функції php на самому початку сторінки:

Пишіть спочатку файл 404.
В результаті ми маємо отримати відповідь на бите посилання:

Закрити сторінку 404 від індексування

Закрити сторінку від індексування можна у файлі rodots.txt. Будьте уважні з цим інструментом, адже через цей файл ваш сайт по суті спілкується з пошуковими роботами!
Повний текст файлу rodots.txt, де ТІЛЬКИ закрито індексацію 404 сторінки, виглядає так:
____________________________
User-agent: *
Disallow:
Disallow: /404.php
____________________________

Примітки щодо коду: "/404.php" означає шлях до сторінки. Якщо на вашому сайті сторінка 404.php (або 404.html відповідно) знаходиться в якійсь папці, то шлях виглядатиме:
/holder/404.php
де "holder" – назва папки.

Ось, власне і все по сторінці 404. Перевірте роботу сторінки, перенаправлення битих посилань та відповіді серверів.
Повторюся: Все викладене для самописних сайтів. Якщо ви використовуєте Wordpress, то можете пошукати пристойний плагін для налаштування помилки 404.

Неможливо знати відповіді сервера.

Приклад:

404 Not found

Подальші дії залежить від того, який код відповіді дав сервер чи сторінка. Зважаючи на те, що набір кодів є стандартним для всіх сайтів/сторінок/серверів, дії при видачі того чи іншого коду теж будуть стандартними.

На сьогоднішній день виділено 5 основних класів коду відповіді:

1xx: Informational (укр. інформаційний) - запит правильно сприйнятий, але його обробка не завершена.

2xx: Success (укр. Успішно) — запит правильно сприйнятий та успішно оброблений.

3xx: Redirection — коди переадресації на інші сторінки.

4xx: Client Error (укр. Помилка клієнта) - помилка з боку клієнта.

5xx: Server Error (помилка сервера) — помилка з боку сервера.

А тепер окремо розберемо деякі коди стану IANA.

Відповідь сервера 1XX

100 Continue Server Code

100 Continue повідомляє, що зв'язок із сервером вже встановлено, сервер прийняв коректний запит і тепер ведеться обмін даними між сервером та клієнтом. Цей код є тимчасовим, тобто. за ним завжди слідує інший. Код 100 є внутрішнім та не відноситься до помилкових. Тобто. «Двері відчинені, читай що потрібно, як закінчиш - закрий». Код 100 може і не генеруватись, якщо користувач вже отримав частину даних від сервера.

101 Switching Protocols

Цей код також не є помилковим. Генерується при перемиканні з одного протоколу на інший. Наприклад, при запиті перемикання зі старої версії HTTP на новішу.

Це один з найпростіших серверних кодів. Він означає, що з боку користувача надійшов запит на перемикання типу протоколу, який використовується на веб-сервері, і сервер погодився на це.

102 Processing

У певному сенсі це аналог коду 100. Генерується у разі, коли обробка запиту може зайняти багато часу. Для цього таймер очікування скидається і очікування подальших команд відбувається у звичайному режимі. Також не є кодом помилки.

Відповідь сервера 200 ОК

По праву займає найперше місце за важливістю та популярністю, т.к. саме його віддає сервер у разі успішної та правильної обробки запиту користувача.

Відповідь сервера 301

Також є одним із найпоширеніших кодів відповіді. Він повідомляє, що запитувана сторінка за цією адресою більше не доступна, а потім відбувається перенаправлення на іншу адресу. 301 редирект може застосовуватися, наприклад, під час «переїзду» сайту з протоколу HTTP на HTTPS (зазвичай це реалізується через файл.htaccess, доступний на серверах Apache).

Відповідь сервера 302

Цей код повідомляє про те, що розташування сторінки, що запитується, тимчасово змінено. Також має бути надана інформація про нове місцезнаходження запитуваного документа. Цей код спочатку використовувався як основний спосіб перенаправлення.

Відповідь сервера 404

Ось вже щось, а помилку відповіді сервера 404 не бачили лише ті, хто ще не народився і ті, хто помер до створення інтернету. Цей код повідомляє про те, що документ, що запитується, з якихось причин на сайті відсутній. Код помилки відповіді сервера 404 повинен віддаватися лише у тому випадку, якщо за вказаною користувачем адресою документа ніколи не було. Якщо документ раніше був доступний за цією адресою, а потім його видалили з сайту, сервер повинен віддавати код 410, а не 404.

Фейкові сторінки 404

Більшість вебмайстрів не звертає на 404 сторінки ніякої уваги, однак це може серйозно нашкодити ранжируванню сайту. Парадокс, але сторінка з повідомленням 404 File Not Found далеко не завжди віддає код 404. Такі сторінки називають «Soft 404». Причини виникнення прості - з якихось причин сторінка віддає код, відмінний від 404 і 410 - наприклад, 200. Це цілком можливо, якщо сторінка вже створена, але контенту на ній поки немає.

Відповідь сервера 500

Усі коди серії 5хх свідчать про те, що сервер не в змозі завершити обробку запиту. Разом з кодом має з'являтися і підказка, що пояснює (з причиною) англійською мовою.

500 Internal Server Error

Код 500 віддається у разі будь-якої внутрішньої помилки сервера, крім інших помилок 5хх класу. Така помилка може бути віддана у тому випадку, коли посилання генерується на сервері у момент запиту. Найпростіший приклад - внутрішній пошук по сайту: фізично ніякого документа по посиланню, що запитується, немає.

Відповідь сервера 502

Код 502 може відображатися в тих випадках, коли сервер відіграє роль шлюзу або проксі, але при цьому не вдалося знайти спільну мову між ним і вищим сервером, тобто, по суті, це просто помилка обміну даних.

Відповідь сервера 550

При виникненні помилки 550 необхідно перевірити наскільки коректно прописані записи MX, щоб усунути дані помилки відповіді сервера.

На виході буде представлено таблицю.

Необхідно переконатися, що в ній прописані необхідні записи для вашої пошти:

ВАЖЛИВО! Змішування MX-записів є неприпустимим, тобто. у таблиці на видачі мають бути лише ті MX-записи, які потрібні саме для вашої пошти. При необхідності потрібно скоригувати записи, виправивши помилки та/або видаливши зайве.

Як отримати коди відповіді сервера (сторінки) через Яндекс

Крок 1. Перевіряємо код відповіді сервера на сторінку сайту, яка має бути у пошуку.

Відкриваємо будь-яку сторінку Вашого сайту, яка знаходиться в пошуковій видачі Яндекса, потім з адресного рядка копіюємо її URL-адресу.

Тепер переходимо до сервісу Яндекса (http://webmaster.yandex.ru/server-response.xml), за допомогою якого можна подивитися на сайт очима робота та перевірити швидкість відповіді сервера в Яндекс панелі.

Просто вставляємо url-адресу сторінки, що цікавить нас, в текстове поле і натискаємо на кнопку «Перевірити». У цьому випадку ми отримали код 200 ОК, який свідчить про нормальну роботу сторінки.

Крок 2. Перевіряємо відповідь сервера на явно неіснуючу сторінку.

У тому ж сервісі вводимо ім'я_домена/яка_крокозябра

У даному випадку ми отримали відповідь 301 Moved Permanently. Це говорить про те, що адреса сторінки вказана неправильно і відбувається переадресація на правильну адресу.

Як дізнатися коди відповіді сервера (сайту)?

Як альтернатива можна пробити код відповіді за допомогою сервісу http://mainspy.ru. Працює аналогічно сервісу Яндекса: вставляємо URL, що цікавить, і тиснемо «Перевірити». Код відповіді в даному випадку знаходиться в першому рядку:

Bertal, на відміну від Mainspy, дозволяє поглянути на сторінку не лише очима Яндекс-бота, а й очима пошукових роботів Bing та Google, а як бонус – може емулювати популярні браузери. Для зручності поглянемо на ті самі сторінки очима GoogleBot. У цьому випадку код відповіді підсвічений зеленим.

Масова перевірка відповідей сервера (сайту) онлайн

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

Dimax.biz - http://backlinks-checker.dimax.biz/tools/proverka_otveta_servera.php - це один із найкращих чекерів. Єдиний мінус – у безкоштовному режимі можна робити не більше 2 запитів по 50 посилань кожен. Для «серйозніших» обсягів доведеться скористатися платним PRO-тарифом. На виході ми отримуємо список відсортованих за кодом відповіді. У разі у сортуванні немає необхідності, т.к. у списку всього 2 адреси, і обидві віддають код 200.

Urlitor – ще один сервіс, для масової перевірки кодів відповіді. Сервіс хороший тим, що результати перевірки зводяться до таблиці для полегшення сприйняття. До речі, посилання в таблиці клікабельні.

Як перевірити швидкість (час) відповіді сервера сайту?

Скільки таких сервісів уже розлучилося – не перерахувати. Розглянемо деякі з них.

Це англомовний інструмент, що аналізує швидкість за всіма параметрами. З його допомогою можна дізнатися швидкість в секундах, скільки важить сторінка, що тестується, а також отримати оцінку та рекомендації для її поліпшення. Перевага цього сервісу у цьому, що аналізується кожен окремий елемент. Такий аналіз дозволяє з'ясувати, що саме загальмовує завантаження окремо взятої сторінки та/або сайту загалом.

Which Loads Faster

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

Google PageSpeed ​​Insights

Google PageSpeed ​​Insights також є одним із найпотужніших інструментів для вимірювання швидкості роботи мобільної та десктопної версії. Оцінка проводиться за 100-бальною шкалою. 85 балів і більше – це добрий показник. Плюс бонусом він видає рекомендації щодо покращення.

Довга відповідь сервера

Відповідь, тривалість якої складає більше, ніж півсекунди, прийнято називати "довгим". Тому, при тривалому завантаженні на сайті ви можете бачити повідомлення в браузері "перевищено час очікування відповіді від сервера". Причин довгої відповіді може бути сила-силенна:

Складна логіка надання даних

Сервер не встигає своєчасно обробляти запити, що надходять, через їх велику кількість.

Самі запити (або складні, або неоптимізовані, або те й інше)

Запити до великої кількості зовнішніх ресурсів

Велика кількість виконуваних файлів

Сам веб-сервер довго опрацьовує запит.

Найболючіші місця продуктивності сервера:

Веб-сервер (Apache, IIS).

Ряд веб-серверів навіть за видачі статичних файлів можуть створювати затримки, т.к. вони на архітектурному рівні не призначені для обробки великої кількості запитів і через це може бути повідомлення, що перевищено час очікування відповіді від сервера. Тому для нормальної роботи веб-сервера є сенс використовувати nginx (причому у зв'язці з Apache, php-fpm, а також іншими серверами додатків для обробки серверних обчислень).

Використання OpCache.

Скоротіть час відповіді сервера шляхом кешування коду, що виконується (скриптів сайту) - воно дозволяє скористатися вже готовим результатом замість того, щоб щоразу переводити PHP-інструкції в бінарний код. Але це кешування з кешуванням результатів виконання PHP-скриптів немає взагалі нічого спільного.

Запити до бази даних.

Другий крок до швидкодії сервера - налаштування таблиць (індексів) у базі даних та його структурування, щоб полегшити обробку запитів. Сюди можна віднести перерахунок проміжних і кешування найчастіше використовуваних результатів у окремі таблиці. Це зменшить споживання серверних ресурсів у кілька разів і допоможе скоротити час відповіді сервера.

Складна логіка обробки даних.

Третій крок – спрощення серверної логіки. По суті, це просто усунення непотрібних операцій та профілювання часу виконання серверних скриптів.

Звернення до сторонніх сервісів.

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

Чому швидкість відповіді веб-сервера впливає на просування.

По-перше, тому що швидкість завантаження є одним із факторів ранжирування (хоч і не вирішальним). Google відкрито заявляє, що за швидкістю показу сторінок ранжується менше 1% сайтів. АЛЕ…

По-друге, якщо сторінка занадто довго вантажиться – користувач її просто закриє. Таку поведінку користувача прийнято називати "відмовою". До речі, «відмови» прямо впливають на позиції в пошуковій видачі. Чим вища швидкість завантаження - тим нижчий відсоток відмов і, як наслідок, тим вища позиція.

Перевищено час очікування відповіді від сервера.

Спочатку важливо розуміти причину виникнення збою. Тобто. Користувач вводить адресу, а браузер в цей момент відправляє групу запитів, а також включає зворотний секундомір на кожен з них. Якщо після закінчення заданого часу браузер не отримує відповіді на свій запит, то користувач побачить таку неприємну картинку.

Основних причин збою може кілька:

• Неможливо підключитися до сайту через нестабільну роботу його серверів;
• Збиті параметри браузера або його захаращеність;

Проблеми з підключенням до Інтернету з боку користувача;

Ресурс заблоковано.

Що робити для вирішення?

Якщо збій одиничний – перезавантажуємо сторінку за допомогою комбінації Ctrl+F5. Можливо, потрібно перезавантажити сторінку кілька разів. Якщо не допомогло – перевіряємо підключення до інтернету.

Налаштування мережі.

1. Деякі сайти іноді «капризують». Для динамічного IP рішення буде простим – перезавантажити роутер через відключення живлення.

2. Повільне з'єднання іноді провокує помилку ERR_CONNECTION_TIMED_OUT. Швидкість роботи інтернету можна перевірити через Яндекс-інтернетометр. Якщо швидкість надто низька – слід звернутися до інтернет-провайдера.

3. Необхідно перевірити «Властивості мережі» на наявність сторонніх DNS-адрес. Якщо такі адреси є - видалити (попередньо про всяк випадок переписавши їх кудись) і перевірити систему на віруси за допомогою встановленого на ПК антивірусного ПЗ - NOD32, Kaspersky, AdwCleaner, MalwareBytes, Dr.Web і т.д. Найкраще для цього використовувати Live-завантажувачі.

4. Перевірити налаштування самого роутера. Найчастіше збивається параметр MTU. Універсальних рекомендацій щодо настроювання роутера дати неможливо, т.к. це залежить і від моделі роутера, і від інтернет-провайдера. Зазвичай MTU має значення 1500, 1460, 1476.

Який має бути час відповіді сервера?

І одразу ж конкретні цифри:

Найвища конверсія сторінок, які повністю завантажуються за 1,8 і 2,7 секунди для десктопної та мобільної версій відповідно

Найнижчий показник відмов у сторінок, які повністю завантажуються за 1 і 0.7 секунд для десктопної та мобільної версій відповідно

Ці цифри запозичені з дослідження Akamai Technologies.

Отже, Ви перевірили сайт на швидкість завантаження. Але як реагувати на результати?

<1 секунды - идеал

1-2 секунди – майже ідеал

3-5 секунд - непогано, але має сенс допиляти

5-10 секунд - погано, потрібно терміново допилювати

≥10 секунд - дуже погано, потрібно ЕКСТРЕННО допилювати

Проте, не можна забувати одне ультраважливе правило - швидкість завантаження має бути вищою, ніж у конкурентів. Дослідження The New York Times довели, що різниці в 0,25 секунди може бути достатньо для того, щоб відвідувачі віддали перевагу швидшому сайту. І оком моргнути не встигнете (у самому прямому сенсі), як користувач піде від Вас до конкурента.

Скорочення відповіді сервера

Оптимізація графіки.

Раніше ми говорили, що деякі чекери надають ще й рекомендації щодо оптимізації. Серед них можна знайти адреси картинок, які можна оптимізувати шляхом зменшення.

Використовувати кеш браузера.

Браузер завантажуватиме зображення до себе в кеш. Отже, повторне завантаження зображень із сервера вже не потрібно, а це заощадить багато часу на завантаження.

Увімкнути стиск.

Актуально, якщо використовується gzip. У результаті обсяг даних скорочується в 4, а то й у 5. Чим менший обсяг переданих даних - тим менше часу займає їх передача.

Зменшити час відповіді сервера.

З допомогою сервісу Pingdom можна визначити, скільки часу потрібно серверу у тому, щоб дати код відповіді. Ідеальний час – не більше 0,2 секунди.

Ці інструкції допоможуть значно прискорити роботу сайту. Однак є ризик нашкодити функціональності або зовнішньому вигляду. Тому перед кожною дією обов'язково робити бекапи вихідних файлів. Також не завадить проконсультуватись з технічними фахівцями.

452

Коди статусу та помилок HTTP схожі на коротке повідомлення від сервера, яке відображається у верхній частині веб-сторінки. Насправді, це не частина веб-сторінки. Це повідомлення, що повертається при зверненні до сервера, дозволяє дізнатися, як були справи, коли сервером був отриманий запит на перегляд сторінки.

Такі повідомлення повертаються щоразу, коли браузер взаємодіє із сервером, навіть якщо ви не бачите їх. Коди статусу HTTP є безцінним інструментом для діагностики та виправлення помилок, що виникли у конфігурації сайту.

У цій статті представлені найпоширеніші коди статусу та коди помилок.

Звідки вони беруться?

Щоразу, коли ви натискаєте на посилання або вводите URL-адресу і натискаєте « Enter», браузер надсилає запит на сервер. Він отримує і обробляє запит, а потім відправляє ресурси, що запитуються разом з HTTP-заголовком .

Коди статусу доставляються в браузер в заголовку HTTP . Хоча ви їх не бачите. Але коли щось пішло не так, користувачеві відображається код статусу у браузері. Це спосіб сервера сказати: « Щось не так. Ось код, який пояснює, що саме».

Код статусу HTTP Google 404

Щоб побачити коди статусу, які браузер зазвичай не відображає, потрібні спеціальні інструменти. Для популярних браузерів, таких як Chrome та Firefox, доступні відповідні розширення. Також існує багато сервісів для відображення заголовків, наприклад, Web Sniffer .

Щоб побачити код статусу HTTP за допомогою одного з цих інструментів, знайдіть рядок у верхній частині звіту, в якому вказано: “Status: HTTP/1.1 ”. Після неї вказано код статусу, який повертається сервером.

Класи кодів статусу HTTP

Коди статусу HTTP розділені на 5 класів:

• 100: інформаційні коди, що вказують на те, що запит, ініційований браузером, триває.
• 200: коди успішного запиту. Повертаються, коли запит браузера було успішно отримано, розпізнано та оброблено сервером.
• 300: коди перенаправлення повертаються, коли запитаний ресурс замінено на новий.
• 400: http-помилки, що виникають на стороні клієнта та вказують на наявність проблеми із запитом.
• 500: коди помилок сервера, що вказують, що запит було прийнято, але помилка на сервері не дозволила виконати його.

Список кодів статусу HTTP

Існує понад 40 різних кодів статусу сервера. Але тих, з якими ви стикатиметеся регулярно менше дюжини. Нижче наведено список кодів статусу HTTP:

Код статусу 200

200: "Все в порядку". Це код, який повертається, коли веб-сторінка чи ресурс діють точно так, як очікується.

Коди статусу 300

301: « Запитаний ресурс було переміщено назавжди». Цей код повертається, коли веб-сторінка чи ресурс замінюється іншим ресурсом. Він використовується для постійного редиректу URL-адрес .

302: це http-помилка Запитаний ресурс переміщено, але було знайдено». Цей код використовується для вказівки того, що запитаний ресурс був знайдений, але не там, де це очікувалося. Він використовується для тимчасового редиректу URL-адрес .

304: « Запитаний ресурс не змінено з моменту останнього звернення до нього». Повідомляє, що ресурси, які зберігаються в кеші браузера, не змінилися. Він використовується для прискорення доставки веб-сторінок за рахунок повторного використання раніше завантажених ресурсів.

Коди статусу 400

http-помилка 403: « Доступ до цього ресурсу заборонено». Повертається, коли користувач намагається відкрити ресурс, для якого він не має прав доступу. Наприклад, спроба перегляду неавторизованим користувачем контенту, захищеного паролем, може призвести до помилки 403 .

404: « Запитаний ресурс не знайдено». Найбільш поширене повідомлення про помилку. Означає, що запитаний ресурс немає і сервер не знає, чи існував він коли-небудь.

405: « Метод не дозволено». Генерується, коли хостинг-сервер (вихідний сервер) підтримує отриманий метод, але цільовий ресурс відсутній.

406: « Неприйнятна відповідь». Запитаний ресурс здатний генерувати лише контент, неприйнятний відповідно до заголовків Accept, надісланих у запиті.

408: « Час очікування сервером надходження решти запиту з браузера закінчився». Генерується, коли сервер перериває обробку після закінчення часу очікування повного запиту від браузера. Іншими словами, сервер не отримав повного запиту, надісланого браузером. Однією з можливих причин може бути перевантаження мережі, що призводить до втрати пакетів між браузером та сервером.

410: « Запитаний ресурс відсутній і не буде повернутий». Подібний до коду 404 «Не знайдено», за винятком того, що код статусу 410 вказує, що даний статус очікується на постійній основі.

429: це http-помилка Забагато запитів». Генерується сервером, коли користувач надіслав надто багато запитів у заданий проміжок часу ( обмеження за швидкістю). Іноді причиною помилки можуть бути роботи, які намагаються отримати доступ до сайту. У цьому випадку може знадобитися зміна URL-адреси входу до панелі адміністрування WordPress .

429 занадто багато запитів

499: « Клієнт закрив запит». Повертається NGINX , коли клієнт закриває запит, поки NGINX досі обробляє його.

Коди статусу500

500: «Н а сервері виникла помилка, і запит не міг бути завершений». Загальний http-код, який також називають Внутрішня помилка сервера». На сервері щось пішло не так, і запитаний ресурс не був доставлений. Цей код генерується сторонніми плагінами, при збоях коду PHP або підключення до бази даних.

Помилка під час встановлення з'єднання з базою даних

501: "Не реалізовано". Ця помилка вказує на те, що сервер не підтримує функції, необхідні для виконання запиту. Помилка майже завжди пов'язана із самим сервером, і для її вирішення потрібно звернутися до служби підтримки хостинг-провайдера.

Ми випустили нову книгу «Контент-маркетинг у соціальних мережах: Як засісти в голову передплатників та закохати їх у свій бренд».

Код відповіді 200 - один із типів кодів HTTP, інформує користувача про успішну обробку запиту. Виходячи із статусу, сервер може надавати тіло та заголовок повідомлення.

Більше відео на нашому каналі - вивчайте інтернет-маркетинг із SEMANTICA

Наведемо приклад. Ви надіслали посилку до іншого міста. На пошті вам видали трек номер для відстеження. По ньому ви дивіться, що з вашим відправленням - ось воно залишило сортувальний центр вашого міста, ось прибуло до іншого. Ось його вручили адресатові. Щоразу система видає вам статус у відповідь на запит.

Як це працює

Для початку розберемо. Користувач відкриває браузер і робить запит до інтернет-ресурсу. Після цього браузер отримує відповідь хоста, де і вказано код із трьох цифр. За комбінацією цифр можна визначити, яка ситуація зараз спостерігається на хості.

HTTP – це спеціальний протокол для обміну даними між різними (браузер користувача та веб-сервер, де знаходиться сам сайт). Тобто браузер направляє запит до сервера, що його цікавить, це може бути дія або документ, а потім отримує відповідь. Якщо відповідь на звернення позитивна, відображається код відповіді сервера 200 і починається завантаження файлу. Якщо негативний, тобто запитувану сторінку не знайдено або є проблеми в роботі сервісу, виходить повідомлення про помилку.

Що означає код 200 для правильної індексації сайту

Категорія серверних відповідей 2х є категорією «Success». Ця категорія повідомляє користувачів про позитивний результат. Зокрема, код "200 ОК" говорить користувачеві, що його запит успішно виконано. Наприклад, клієнт запросив ті чи інші дані. Відповідь сервера 200 означає, що ці дані відображені у заголовку або повідомленні.

Сьогодні всі пошукові системи індексують ресурси та посилання, що надають на запити код відповіді 200. Пошуковик, розуміє це так: сторінка дійсно існує, значить, її можна включати в індексну базу. Якщо ви хочете, щоб пошукова система проіндексувала ту чи іншу сторінку, подбайте, щоб вона видавала код відповіді 200.

Важливо перевірити, чи не віддають неіснуючі сторінки код 200. Це можливо, навіть коли візуально ви бачите на екрані “404 - сторінка не знайдена”. Причиною цієї проблеми може стати неправильне налаштування роботи сайту. Якщо ви не бажаєте проблем з просуванням вашого ресурсу - перевірте всі типи сторінок на коректну відповідь сервера. Так ви зможете виявити сторінки, які лише прикидаються потрібними.

Як перевірити коди відповідей

Для цього ви можете скористатися однією з багатьох програм, які є в інтернеті. Якісь роблять масові перевірки для всіх сторінок сайту, якісь вимагають введення кожного URL. Вибирайте сервіс, виходячи з ваших завдань.

Насправді кодів відповіді сервера велика кількість, але найчастіше такі:

• Якщо спочатку сторінка відповідала на запит кодом 200, проіндексувалася благополучно, але потім її видалили, при переході на неї буде відображатися код 404 (не знайдений).
• Якщо ви використовуєте тимчасовий редирект (302), то в індекс потраплять обидві адреси.
• Якщо на веб-сторінці використовується постійний редирект, ви отримаєте відповідь з кодом 301. І пошуковик індексуватиме лише кінцеву адресу з потрібним кодом.

Якщо присвоїти сторінці 301 редирект, пізніше вона видаляється з індексної бази, її вага при цьому може бути передана сторінці, на яку направляє редирект. Однак процес переіндексації тривалий, Яндекс в деяких випадках виконує її протягом року. Тому краще відразу правильно відредагувати сторінки, настроїти коректну роботу перед індексацією.