замовити дзвінок
+38 057 755-48-00
Starting a new project?
отримати консультацію
SEO - пошукове просування
10
1

Під час внутрішньої оптимізації сайту важливо налаштувати правильні відповіді серверу.

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

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

Приклад:

Редиректы

Рис. 1 - Приклад відповіді сервера (відповідь містить код статусу HTTP та заголовок Expires)

Розберемося, які бувають коди відповідей та як зробити редирект.


1. Коди статусу

Якщо ви переводите сайт на протокол https або на версію сайту без www, чи переїжджаєте на новий домен, то редиректи – перше, що вам потрібно налаштувати.
Розглянемо найважливіші й найбільш затребувані класи стану сторінок та позначимо нюанси роботи.


1.1 Редиректи 3**

  • 300 Multiple Choice.

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

  • 301 Moved Permanently.

Показує, що сайт назавжди змінив адресу та подальші звернення до ресурсу повинні перенаправлятися на новий URL. Вага сторінок зі старого сайту переноситься на новий.

Редиректы

Рис. 2 – Приклад 301 відповіді сервера

  • 302 Moved Temporarily, Found.

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

Недоліки 302 редиректу:

  • 302й редирект не передає вагу сторінки;
  • якщо 302й код використовується довше 7 днів поспіль, сайт може потрапити під фільтр пошукових систем (302у відповідь боти іноді розцінюють як складову “чорного SEO”).

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

  • 303 See Other.

Схожий з 302 кодом, але 303 не вказує на переміщення запитаного URL.
303 редирект показує, що для запитаної сторінки немає відповідного адресу, але є кілька URL, що умовно задовольняють запит.

  • 304 Not Modified.

Показує, що повторно передавати запитану адресу не потрібно, якщо з моменту останньої передачі сторінка не була змінена. Браузер перенаправить користувача на збережену копію сторінки.
А якщо зміни були, то надсилається відповідь “200 ОК”.

  • 305 Use Proxy.

Переадресація через проксі-сервер.
Код 305 використовують для анонімності, або для прискорення завантаження сторінки (тоді кешують вміст сторінки).
Але не всі браузери вірно опрацьовують цей код відповіді (стосується Explorer та Mozilla). Тому він використовується не часто.

  • 306 Switch Proxy.

Раніше застосовувався для позначення використання певного проксі.
Зараз код не використовується, але залишається для резерву.

  • 307 Temporary Redirect.

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

  • 308 Permanent Redirect.

Аналог 301 коду, передає вагу сторінки. Але з обмеженням – не дозволяє змінити метод запиту з Post на Get.
308 редирект використовує Google Drive – показує клієнту, що завантаження даних перервалася.
Вважається, що 301й код відповіді передає більшу частину посилальної ваги. Тому 301 редирект (постійне перенаправлення на нову адресу) застосовують частіше.

Як перевірити вірність перенесення 301 редиректу?

  • вручну (сервіси Header checker tool, bertal.ru);
  • автоматично (Screaming frog seo spider, Netpeak Spider, Serpstat).

Перевірка може затягнутися до 3х тижнів, будьте готові до цього – пошуковики повинні обійти переслані сторінки та привласнити вагу новим.
Що потрібно врахувати при проставленні:

  • якщо на сайті є 302 редиректи, а основний URL поставити неможна, то 302 відповідь замінюємо на 301.

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


1.2 Внутрішні посилання та редиректи

  • всі внутрішні редиректи усуваємо (за можливістю) і замінюємо на цільові URLи з 200 кодом відповіді сервера;
  • обираємо головне дзеркало (з www або без), і з другорядного сайту на головний робимо посторінковий 301 редирект;
  • стежимо за відсутністю циклічних редиректів (коли перенаправлення відбувається за замкнутим циклом);
  • уникаємо ланцюжків перенаправлень;
  • все URLи повинні закінчуватися або слешем, або його відсутністю.

Не повинно бути такого, що частина URL зі слешем, а частина без нього. Стежимо за одноманітністю.
Також обов’язково повинен бути 301й редирект з URLа зі слешем на URL без слешу (або навпаки – в залежності від обраного варіанту).

  • налаштовуємо 301 редирект, якщо всередині URL багато слешів.

Приклад: https://site.com/razdel////tovar повинен перенаправлятися на нормальний URL https://site.com/razdel/tovar

  • URLи з помилковим набором символів перенаправляються на нормальний URL;

Приклад: https://site.com/razdel12 на https://site.com/razdel

  • URLи з великими літерами перенаправляються на нормальний URL.

Приклад: https://site.com/razdel/ToVar на https://site.com/razdel/tovar

Редиректы

Рис. 3 – Приклад перенаправлення URL з великими літерами

У разі, якщо не вдається коректно визначити, куди перенаправити користувача, рекомендуємо налаштувати спрацювання такого правила:

Головна/Блок1/блокn/

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


1.3 Нюанси перенаправлення

  • при перенесенні сайту на https-версію відстежуємо правильний перенос коментарів: щоб коменти з додатку disqus або коректно перенеслися, або були відсутні в коді;
  • стежимо за відсутністю редиректу на редирект;
  • редиректи налаштовуємо тільки на сторінки зі статусом 200 ОК;
  • перевіряємо файл .htaccess на вірність складання та консультуємося з адміном;
  • всі елементи сайту точно переносимо на https-протокол (фахівці часто забувають перевести й URLи зображень).

Рекомендація:

  • при переході з http на https, всю внутрішню перелінковку краще робити відносними посиланнями.

1.4 Коды 404 и 410 (адреса удаленных страниц)

Якими сервісами шукати “биті” посилання?

  1. вручну (якщо сайт невеликий, можна весь його пройти та проклікати всі посилання на сайті, або задати пошуковику команду з оператором “site: вашсайт.com”);
  2. автоматично:
  • Google Search Console (вкладка “Сканування – Помилки сканування”);
  • Google Tag Manager (через створення окремої змінної);
  • Яндекс.Вебмайстер (розділ “Внутрішні посилання – Непрацюючі внутрішні посилання на сайті”);
  • Online broken link checker (безкоштовна перевірка до 3000 сторінок – тільки HTML-документи);
  • Xenu’s link sleuth;
  • Screaming frog (безкоштовна перевірка до 500 сторінок);
  • Broken link checker (плагін для WordPress);
  • Check my links (розширення для Google Chrome).

Непрацюючі посилання знайшли, що далі?

Редиректы

Рис. 4 – Приклад 404 відповіді сервера

1. створюємо спеціальну постійну сторінку 404, наприклад https://site.com/404;
2. перевіряємо, чи точно вона віддає 404й код відповіді (часто помилково налаштовують 200 відповідь);
3. на неї перенаправляємо всі 404 сторінки, наприклад – https://site.com/folfdsfods
4. сторінка https://site.com/404 містить:

  • попередження, що такої сторінки не існує;
  • пропозиція перейти до інших розділів сайту, або скористатися пошуком.

Тобто повинні бути налаштовані посилання на популярні розділи або головне меню.

5. за допомогою краулерів виявляємо та усуваємо причини виникнення 404х т. з. “битих” посилань;
6. для того, щоб дані щодо відсутніх або сторінок з помилками відбивалися у звітах Google Analytics:

  • на сторінку з кодом 404 додаємо код відстеження Google Analytics;
  • + рядок перед кодом GTM:

<Script type = “text / javascript”>
 id404 = «true»;
 </ Script>

Тепер зібрані дані можна переглянути в розділі Content (Top pages, Top landing pages, Top exit pages) звіту Google Analytics.
Інформація з «поганих» 404 сторінок покаже обсяг битих посилань. Так ми зможемо сміливо видалити або змінити їх. Причому видалити їх доведеться й з індексу. Робимо це через панелі Google та Яндекс. Щоб видалити биту сторінку, присвоюємо їй помилку 404. При наступному обході робот виконає запити на видалення та вони зникнуть з Пошуку.

  • Soft 404 помилка

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

Де можна знайти всі помилки обробки відповідей серверів? В логах файлів.
Це додатковий інструмент виправлення проблем при внутрішній оптимізації сайту.

  • 410 Gone

Аналог 404 помилки. Код відповіді сповіщає про те, що сторінка видалена та більш недоступна. При подальшій перевірці бот не обходитиме її та не вноситиме змін до індексу.

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


1.5 Access Log и отчет в Search Console

Текстовий файл access.log збирає статистику сайту – всі звернення до сервера пошукових роботів.

Що дає цей список URL:

  • пошук низькоякісних сторінок, які не бачить парсер, але про яких знає робот.

Крім того, це може бути “чорне SEO” від конкурентів (нагенеровані дублі для погіршення просування).

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

2. Заголовки відповіді сервера

Заголовки – команди обміну між сервером та пошуковим роботом.
Заголовки містять інформацію стосовно протоколу, кодування, мови та ін.. Складових роботи ресурсу.


2.1 Last-Modified

Зберігає відомості щодо дати останнього редагування сторінки.

Механізм дії:

  1. якщо при обході отриманий заголовок Last-Modified, то наступного разу при зверненні до цього URL (і при наявності цієї сторінки в кеші браузера), робот запросить If-Modified-Since (чи були якісь зміни на сторінці після дати в Last- Modified);
  2. далі сервер звіряє отриманий час з часом останньої зміни сторінки;
  3. якщо дата не змінювалася, він відповідає “304 Not Modified”.

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


2.2 If-Modified-Since

Показує, чи вносилися на сторінку зміни після дати, яка отримана в Last-Modified.

Механізм:

  • клієнт отримує запит If-Modified-Since;
  • звіряє дату з часом останньої зміни сторінки;
  • якщо вони збігаються, сервер відповідає 304 Not Modified та сторінка завантажується з кешу;
  • якщо ж часи останніх зміни відрізняються, сервер відповідає буде 200 ОК.

2.3 Expires

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

  • дата створення сторінки = реальному часі останньої зміни сторінки.

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

  • Expire date всіх страніцравна поточного моменту часу + 3600 секунд для того, щоб закешовану статичні елементи на 1 годину.

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


3. Що ж стосовно SEO?

Сторінки, що просуваються, повинні давати код відповіді 200.
Ті, що переміщені – 301.
Та 404 – всі сторінки з помилками.
Кожен код повинен відповідати призначеній задачі. Так пошукові роботи працюють більш ефективно зі сторінками сайту.

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


Что такое SEO

Що таке SEO та навіщо потрібна пошукова оптимізація

Скорость загрузки сайтов

Швидкість завантаження сайтів. Що потрібно знати

Core Web Vitals

Core web vitals: фактор ранжування Google

Підпишіться на наші оновлення
Більше корисних статей та мануалів ще попереду. Будьте в курсі

Ви вже підписані на нашу розсилку!

Підтвердіть свій email для завершення підписки.

Замовити
просування
Більше корисних статей та мануалів ще попереду. Будьте в курсі

Дякуємо! Скоро з вами зв'яжеться наш менеджер.