HTML redirect — це процес перенаправлення користувача з запитаний URL-адреси на інший. Він використовується, коли документ був тимчасово або постійно переміщений на інший URL-адресу. Редирект може бути ефективним інструментом поліпшення юзабіліті і SEO.
У цьому посібнику ми розглянемо, які види редиректів існують, як вони реалізуються і як їх використовувати.
З технічної точки зору: що таке редирект
Редірект — це автоматичний перехід з запитаний URL-адресою до URL-адреси призначення. Редирект завершується, коли клієнт перенаправляється на URL-адресу призначення.
Редирект може бути ініційований, як на стороні сервера, так і на стороні клієнта:
Редиректи на стороні сервера:
- HTTP-коди статусів 30x.
Редиректи на стороні клієнта:
- мета-оновлення;
- Javascript-перенаправлення.
Редиректи на стороні сервера
HTML redirect на іншу сторінку на стороні сервера відбувається, коли на HTTP-запит приходить відповідь з кодом статусу сервера, який вказує, що запитуваний документ переміщено на інший URL-адресу. Після цього клієнт запитує URL призначення, і користувач перенаправляється на нього.
Є кілька видів HTTP кодів статусу (RFC 7231), які вказують на редирект певного типу. Не існує хороших або поганих кодів статусу. Кожен вид редіректу має своє призначення і може бути застосований для оптимізації певного аспекту.
Якщо пошукова система виявляє редирект, вона повинна вирішити, як його обробляти. З точки зору SEO існує один основне питання: чи потрібно передавати за посиланням, на яку веде редирект, вага або сигнали ранжирування?
Щоб ухвалити це рішення, пошукові системи розглядають код статусу, використовуваний для редиректа, і його технічні характеристики.
У наступній таблиці наведені коди статусу 30x та їх технічні характеристики:
* cache-default для кодів стану 301, 302, 307 і 308 може бути перепризначений кешуванням методу запиту або за допомогою явних елементів керування кешем. Більш детальну інформацію з цієї теми ви можете знайти в RFC 7234, розділ 4.2.2.
Пошукові системи можуть по-різному реагувати, виходячи з відповідей на наступні питання:
- Є HTML redirect тимчасовим або постійним?
- Може початковий URL-адресу редіректу відображатися в результатах пошуку?
- Є інформація про те, як довго буде активний редирект?
Код статусу редіректу може допомогти відповісти на ці питання.
Редирект 301 «Переміщено назавжди»
Важливим перенаправленням з точки зору SEO є редирект 301 «Переміщено назавжди«. Google підтвердив, що редирект 301 зазвичай передає вагу посилання з невеликою втратою і є основним способом для вирішення завдань SEO при зміні структури сайту. Інші пошукові системи можуть сповідувати ту «філософію».
Редирект 301 кластера за умовчанням, якщо не зазначено інше. cache-default може бути перевизначено кешуванням методу запиту або за допомогою явних елементів керування кешем.
Метод запиту може змінюватися при повторному запиті. Сучасні браузери зазвичай використовують метод GET для передачі запиту до URL-адреси призначення навіть якщо початковий запит був відправлений з допомогою методу POST.
Коли використовувати редирект 301
Redirect 301 HTML є правильним рішенням для запобігання тупикових переходів і об’єднання вхідних посилань. Посилальну вагу і трафік можуть бути збережені. Зазвичай редирект 301 використовується, якщо потрібно, щоб пошукові системи перенесли весь SEO-вага на URL-адресу призначення після переміщення на нього документа назавжди.
Випадки використання 301 редіректу
- Переміщення домена на постійній основі;
- Переміщення документа на постійній основі;
- Зміна протоколу сайту на постійній основі;
- Зміна структури сайту на постійній основі.
Коли не потрібно використовувати редирект 301
Редирект 301 є неправильним рішенням для випадків, в яких кешування може привести до несподіваного негативному поведінці.
Приклади:
- Геотаргетинг;
- Таргетинг пристроїв;
- А / В тестування;
- Відстеження (включаючи кампанії з платою за клік і реферальні кампанії).
Redirect 301 HTML також не слід використовувати, якщо ви хочете застосувати тимчасове перенаправлення.
Приклади:
- Сезонні товари на сайтах електронної комерції;
- Тимчасові спеціальні пропозиції на цільових сторінках сайтів електронної комерції.
Редирект 302 — «Знайдений» / «Тимчасово переміщений»
Код стану 302 вказує, що запитуваний документ тимчасово перенесено на інший URL-адресу.
Редирект 302 не кластера за умовчанням. cache-default може бути перевизначено кешуванням методу запиту або за допомогою явних елементів керування кешем.
Редирект 302 вперше був визначений у HTTP / 1.0 (RFC 1945) і описується фразою «Тимчасово переміщено«. Хоча було вказано, що первинний метод запиту повинен використовуватися і для URL-адреси призначення, браузери часто обробляють редирект 302 всупереч стандарту з використанням для URL-адреси призначення методу GET.
В HTTP / 1.1 (RFC 2616) редирект 302 був перейменований в «Знайдено» і були додані коди статусу 303 і 307, щоб надати можливість використовувати різні часові редиректи, дозволяють і не дозволяють змінювати метод запиту до URL-адреси призначення.
Код статусу 302 на сьогоднішній день як і раніше є найбільш часто використовуваним статусом тимчасового HTML meta redirect і забезпечує сумісність для клієнтів, які не підтримують HTTP / 1.1.
Із-за тимчасового характеру редіректу 302 його поведінка завжди можна змінити. Саме тому пошукові системи, як правило, не зраджують через нього PageRank або SEO-вага URL-адреси призначення. Це також є причиною того, що редирект 302 часто розглядається як «поганий» редирект для оптимізаторів, що є помилкою. Є випадки, в яких специфічні характеристики редіректу 302 можуть бути використані з позитивним ефектом для SEO.
Коли використовувати редирект 302
Це правильне рішення, якщо ви хочете застосувати тимчасовий редирект, який не впливає на присутність сайту в результатах пошуку. Тимчасовий редирект повинен бути обмежений у часі. Він також може бути використаний, якщо потрібно застосувати редирект, який не є кэшируемым.
Випадки використання редіректу 302:
- Геотаргетинг;
- Таргетинг пристроїв;
- А / В тестування;
- Відстеження;
- Періодичне тимчасове вміст;
- Перенаправлення при відсутності сторінки в результатах пошуку.
Приклади:
- Сезонні товари на сайтах електронної комерції;
- Тимчасові спеціальні пропозиції на цільових сторінках сайтів електронної комерції.
Коли не слід використовувати редирект 302
Код статусу 302 не слід використовувати, якщо потрібно передавати SEO-вага URL-адреси призначення.
Приклади:
- Переміщення домена на постійній основі;
- Переміщення документа на постійній основі;
- Зміна протоколу сайту на постійній основі;
- Зміна структури сайту на постійній основі.
HTML redirect 302 також не слід застосовувати, якщо метод вихідного запиту необхідно використовувати для запиту до URL-адреси призначення.
Приклади:
- Тимчасове переміщення URL-адресаа обробника форми, яка використовує метод POST.
303 — «Дивитися інші»
Код статусу 303 був визначений в HTTP / 1.1 і вказує на тимчасовий редирект. Метод запиту для URL-адреси призначення завжди GET.
Редирект 303 ніколи не потрапляв. Більшість клієнтів обробляють код статусу 303 так само, як і статус 302.
Коли слід використовувати редирект 303
Редирект 303 може використовуватися, як і редирект 302. Завдяки тому, що він не потрапляв ні за яких обставин, ми рекомендуємо використовувати 303 замість 302, коли тимчасовий редирект задається на невизначений період часу або URL-адресу призначення може бути змінена. Тим не менш, запит до URL-адреси призначення завжди буде виконуватися з використанням методу GET.
Випадки використання редіректу 303
- Всі випадки використання редіректу 302, які обробляються за допомогою методу GET для повторних запитів:
- Геотаргетинг;
- Таргетинг пристроїв;
- А / В тестування;
- Відстеження;
- Періодичне тимчасове вміст;
- Перенаправлення при відсутності сторінки в результатах пошуку;
- PRG-шаблон (POST / редирект / GET).
Коли не слід використовувати редирект 303
HTML redirect на іншу сторінку 303 не може використовуватися, якщо для повторного запиту повинен бути використаний метод POST. Також не рекомендується використовувати редирект 303 для клієнтів, які не підтримують HTTP / 1.1.
Як і редирект 302, редирект 303 не може бути використаний для сценаріїв, які мають постійний характер.
Приклади:
- Після первинного запиту потрібно використовувати метод POST. Наприклад, при переміщенні URL-адресу обробника форми, для якого потрібно метод POST;
- Перенаправлення є постійним;
- Значення SEO повинно передаватися URL-адреси призначення.
Редирект 307 — «Тимчасово переміщено»
Код статусу 307 був визначений в HTTP / 1.1, щоб замінити код 302 для випадків, коли метод запиту не повинен змінюватися для URL-адреси призначення.
Редирект 307 не кластера за умовчанням. cache-default може бути перевизначено кешуванням методу запиту або за допомогою явних елементів керування кешем.
Коли слід використовувати редирект 307
Редирект 307 може бути використаний, якщо потрібен тимчасовий редирект, який вказує клієнту не змінювати метод початкового запиту при запиті URL-адреси призначення.
Випадки використання редіректу 307:
- Для повторного запиту потрібно метод POST. Наприклад, переміщення URL-адресу обробника форми, для якої потрібно метод POST.
Коли не слід використовувати редирект 307
Редирект 307 не повинен використовуватися для PRG-шаблону. Код статусу 307 також не слід використовувати, якщо редирект має постійний характер.
Редирект 308 «Переміщено назавжди»
Код статусу 308 визначений у RFC 7538. Це постійний аналог коду статусу 307. В протилежність 301 редіректу він вказує, що метод повторного запиту URL-адреси призначення повинен бути таким же, як і метод початкового запиту.
HTML redirect 308 кластера за умовчанням, якщо не зазначено інше. cache-default може бути перевизначено кешуванням методу запиту або за допомогою явних елементів керування кешем.
RFC 7538 обмежує використання коду статусу 308 тими випадками, «коли сервер повністю впевнений, що клієнт розпізнає новий код, або коли резервний варіант семантики коду статусу 300 не є проблемою«.
Коли слід використовувати редирект 308
Редирект 308 може бути застосований, якщо потрібно використовувати метод початкового запиту для повторного. Наприклад, редирект на URL-адресу обробника форми з використанням методу POST.
Випадки використання редіректу 308:
- Переміщення на складному сайті з великою кількістю форм, використовують метод POST;
- Якщо для повторного запиту потрібно метод POST. Наприклад, переміщення URL-адресу обробника форми, для якої потрібно метод POST;
- Всі випадки використання редіректу 301:
- Переміщення домена на постійній основі;
- Переміщення документа на постійній основі;
- Зміна протоколу сайту на постійній основі;
- Зміна структури сайту на постійній основі.
Коли не слід використовувати редирект 308
Редирект 308 — це невірне рішення для всіх випадків, в яких кешування може привести до несподіваного негативному поведінці.
Висновок за редиректам на стороні сервера
Існує багато різних сценаріїв, для яких потрібні різні технічні характеристики використовуваних redirect HTML index. Різні коди статусу забезпечують ідеальне відповідність редіректу кожній конкретній ситуації.
Редиректи на стороні клієнта
Редірект на стороні клієнта — це прямий перехід до URL-адреси призначення. Він ініціюється безпосередньо клієнтом, наприклад, браузером.
У той час як редиректи на стороні сервера є кращим способом реалізувати редирект, розробники не завжди мають можливість контролювати редирект на стороні сервера. В цьому випадку для перенаправлення користувача або поновлення документа можна застосувати редирект на стороні клієнта.
«Застосування JavaScript для перенаправлення користувачів може бути правильною практикою. Наприклад, якщо ви перенаправляти користувачів на внутрішню сторінку, після того, як вони авторизувались. При прийнятті рішення про використання JavaScript або інших методів перенаправлення, щоб забезпечити відповідність практик, які використовуються на сайті, нашим рекомендаціям, розгляньте аспект, пов’язаний з тим, для чого це робиться. Майте на увазі, що редиректи 301 краще всього використовувати при перенесенні сайту, але можна використовувати для цієї мети JavaScript-редиректи, якщо у вас немає доступу до сервера.» — Довідка Google Search Console — Керівництво по підвищенню якості.
Оновлення за допомогою метаконтента
В HTML можна запустити редирект, використовуючи наступний синтаксис в розділі :
Мета-тег HTML пропонує атрибут «http-equiv«, який можна використовувати зі значенням «refresh«, щоб задати автоматичний запит цільового URL-адреси через заданий час. URL-адреса і час повинні бути вказані в атрибуті «content«. Значення атрибута content повинно містити кількість секунд, через яке запускається редирект, після якого через крапку з комою вказується URL-адресу. URL-адреса не є обов’язковим. Метаэлементы повинні розташовуватися в межах розділу .
Наведений у прикладі код вказує виконати HTTP-запит за допомогою методу GET до URL-адресою http://www.example.com/~~HEAD=pobj~~V через 5 секунд. Щоб виконати HTML redirect негайно, вкажіть 0 секунд. У даному процесі не задіяні коди статусу редіректу.
Цей метод широко використовувався на зорі розвитку SEO для створення прихованої переадресації для дорвеїв. Саме тому пошукові системи можуть невірно витлумачити наміри сайтів, які використовують метаобновления. Крім цього метаобновления з затримкою більше ніж 0 секунд, суперечать Керівництву щодо забезпечення доступності веб-контенту.
Ми не рекомендуємо використовувати метаобновления, так як це може привести до проблем з юзабіліті і ранжирування сайту в пошукових системах. Існують більш бажані варіанти забезпечення перенаправлення з використанням редіректу на стороні сервера.
JavaScript-перенаправлення
Javascript-редиректи є альтернативним метаобновлению перенаправленням на стороні клієнта. Для цього необхідно, щоб клієнт був в змозі інтерпретувати JavaScript.
Випадки використання:
- Редірект на основі взаємодії з користувачем;
- Перенаправлення для різних браузерів;
- Таргетинг пристроїв.
В більшості випадків краще використовувати редирект на стороні сервера, а не JavaScript-редирект. Навіть якщо пошукові системи будуть в змозі правильно зрозуміти наміри, з якими застосовується JavaScript-редирект і правильно їх інтерпретувати, редирект на стороні сервера в будь-якому випадку повинен розглядатися, як первинне рішення, так як він характеризується більш низькими вимогами до клієнта. Якщо клієнт не інтерпретує JavaScript, редирект не буде працювати. Редірект на стороні сервера буде працювати в будь-якому випадку.
Порівняно з метаобновлением, JavaScript-редирект дозволяє перенаправити клієнта, керуючись логікою. Він дозволяє перенаправляти до різних URL-адресами призначення при різних обставинах. Це робить його привабливим вибором, наприклад, при відстеженні певного клієнта або пристрої для перенаправлення по конкретному клієнту або влаштування на певний URL-адресу.
З-за того, що в Javascript доступно більше інформації про конкретних клієнтів, ніж в заголовку HTTP-запиту, в деяких ситуаціях Javascript-редирект може бути кращим рішенням, ніж HTML redirect на стороні сервера.
Приклади JavaScript-редиректів
Існує широкий спектр способів реалізації JavaScript-редіректу. Він може мати різну поведінку в плані історії браузера, інформації про первісної сторінці запиту і може вести себе по-різному в залежності від браузера, який використовується.
Ось кілька прикладів для різних методів реалізації JavaScript-редіректу:
location.href = «http://www.example.com/»;
location.assign(«http://www.example.com/»);
location.replace(«http://www.example.com»);
Висновок за редиректам на стороні клієнта
З точки зору SEO, редіректу на стороні сервера завжди повинна віддаватися перевага перед перенаправленням на стороні клієнта. Основним недоліком редіректу на стороні клієнта є відсутність інформації про причини перенаправлення користувача, що робить його менш прозорим для пошукових систем, і по ньому важче прийняти рішення про те, як слід обробляти редирект.
Якщо перенаправлення на стороні сервера застосувати неможливо, можуть бути використані JavaScript-перенаправлення при відстеженні конкретного браузера/клієнта або геотаргетинге.
Загальні випадки використання редиректів для цілей SEO
Редиректи при зміні структури сайту
Якщо структура сайту змінюється, а редирект при цьому не використовується, користувачі в кінцевому підсумку будуть потрапляти на сторінку 404, і SEO-вага, як і трафік можуть бути втрачені. Це часто відбувається, коли сайти відновлений.
HTML redirect на іншу сторінку, використовуваний для запобігання подібних проблем, повинен бути:
- Постійним;
- Кэшируемым.
Для запобігання тупиків і збереження шляхи користувача, а також SEO-ваги, ми пропонуємо використовувати код статусу 301 або 308 для перенаправлення користувачів зі старих URL-адрес на нові.
Примітка: 308 редирект є більш відповідним специфікації рішенням, але клієнти можуть не підтримувати його.
Редирект для місцеположення
Якщо користувачі повинні направлятися на певний URL-адресу, виходячи з їх місця розташування, існують про вимоги, які необхідно враховувати при виборі коду статусу:
- Переадресація повинна носити тимчасовий характер;
- Редирект повинен бути некэшируемым;
- Пошуковим системам повинні надаватися різні заголовки в залежності від обставин.
Якщо користувач змінює своє географічне розташування або мовні настройки браузера, використання кешувального коду стану може призвести до проблем. Користувач може дивитися контент, що відображається, виходячи з його попереднього розташування. В результаті чого може бути спотворений або погіршений досвід взаємодії.
Без можливості отримати варіативні заголовки пошукові системи не будуть мати ніякої інформації про зміненому поведінці редіректу при різних обставинах. Використання варіативного заголовка зазвичай призводить до адресного відображення багатомовних сайтів в результатах пошуку.
Виходячи з перелічених вище вимог, ми пропонуємо використовувати для місцеположення редиректи 303, 302 чи 307. Вебмастера можуть допомогти пошуковим системам краще зрозуміти міжнародні сайти, якщо атрибут посилання hreflang використовується належним чином.
Перенаправлення для Pay Per Click / реферального маркетингу
При використанні редіректу для Pay Per Click або реферального маркетингу для запобігання певних проблем потрібно тимчасовий редирект. Адреси призначення HTML meta redirect можуть змінюватися в залежності від тестування різних посадкових сторінок або внаслідок змін в інфраструктурі відстеження. Щоб уникнути проблем, поведінка кешування клієнта повинно контролюватися.
Pay Per Click / реферальні кампанії породжують багато зовнішніх посилань на сайти рекламодавців. Сайти часто купують посилання, де використовується постійний редирект, і, отже, має місце передача SEO-ваги. У той же час пошукові системи в цілях боротьби з SEO-посиланнями застосовують різні санкції до таких сайтів. У гіршому випадку це може привести до потрапляння під фільтр, наприклад, Google Penguin. Сайт-продавець також може піддатися санкціям.
У більшості випадків цим цілям відповідає uncacheable редирект. Але, ми говоримо про сплачене трафік, тому бажано оптимізувати швидкість завантаження за рахунок зниження затримки при редірект. Було б корисно використовувати тимчасові редиректи і робити їх кешованими. Це можна зробити з допомогою заголовків Cache-Control або Expire з малим часом тривалості, наприклад, 1 день. Крім цього при правильно заданому даних на стороні клієнта при відстеженні буде враховуватися тільки перший доступ, тому що URL-адресу призначення редіректу кешується і викликається безпосередньо при повторному виклику вихідного URL-адреси.
Вимоги до редиректу для Pay Per Click / реферальних кампаній:
- Тимчасовий;
- Uncacheable / кешуючий, залежно від завдань.
В наступній таблиці показано, які коди стану підходять для різних випадків:
Редирект для націлювання пристроїв
Якщо користувачі повинні спрямовуватися на конкретний URL-адресу в залежності від використовуваного пристрою, існують певні вимоги, які необхідно враховувати при виборі коду стану:
- HTML redirect повинен бути тимчасовим;
- Редирект повинен бути не кэшируемым;
- Пошуковим системам повинні надаватися варіативні заголовки.
Бувають випадки, коли користувачі не хочуть використовувати версію сайту, відповідну їх пристрою, тому що воліють використовувати тільки стаціонарну або мобільну версію. У цьому випадку кешуючий редирект може привести до проблем. Користувач може бути не в змозі вибрати потрібний варіант після того, як редирект був кэширован.
Якщо не надаються варіативні заголовки, пошукові системи не будуть мати ніякої інформації про те, що поведінка редіректу змінюється в залежності від різних обставин. Використання варіативного заголовка зазвичай призводить до адресного відображення версій сайтів під конкретні пристрої в результатах пошуку.
Виходячи з перелічених вище вимог, ми пропонуємо використовувати для відстеження пристроїв редирект 303 чи 307 залежно від необхідного методу запиту URL-адреси призначення.
Google підтримує як HTTP-редиректи, так і Javascript-перенаправлення при відстеженні пристроїв, але пропонує використовувати редирект 302 разом з визначенням rel=alternate.
Ми пропонуємо використовувати при відстеженні пристроїв redirect HTML code 303, 302 чи 307.
Використовуючи rel=alternate належним чином, веб-майстри можуть допомогти пошуковим системам краще зрозуміти міжнародні сайти.
Редиректи при зміні хоста або протоколу та інших корекціях URL-адреси
Багато сайтів використовують htaccess для виконання корекції URL-адреси при зміні хоста, протоколу і в інших випадках.
Це, як правило, включає (але не обмежується цим):
- Переклад не-www версію з www версії;
- Переклад протокол HTTPS з HTTP;
- Додавання слеша в кінці.
Редирект для URL-корекції повинен бути постійним, кэшируемым і передавати SEO-вага для об’єднання потоку користувачів і ваги на цільовому URL-адресі.
Вимоги, що пред’являються до редиректу для URL-корекції:
- Постійний;
- Кешуючий.
Ми пропонуємо використовувати для URL-корекцій редирект 301 або 308.
Редиректи і Canonical в SEO
Технічно, HTML redirect і rel=canonical навряд чи можна порівнювати. Однак з точки зору SEO вони допомагають:
- Уникнути проблем з дубльованим контентом;
- Об’єднати властивості URL, наприклад, популярність посилань.
В протилежність редіректу, «canonical» — це HTML мета-елемент посилання, який визначає бажану версію документа, доступного за більш ніж одному URL-адресою. Це може допомогти передати SEO-вага від вихідного URL адресою призначення, в той час як користувач може отримати доступ безпосередньо до документа-дублікату. Тим не менш, «Специфікація зв’язків канонічних посилань» (RFC 6596) говорить, що, якщо автор використовує canonical, йому слід очікувати, що пошукові системи, об’єднають властивості URL-адрес в канонічному URL-адресі.
Однак програми не обов’язково повинні слідувати специфікації при використанні інформації canonical для об’єднання властивості URL-адрес. Тому поведінка пошукових систем щодо передачі SEO-ваги може в окремих випадках відрізнятися від очікуваного.
І на відміну від невизначеного характеру canonical, редирект є конкретним рішенням з чітко визначеним поведінкою додатків. Виходячи з цього, редирект слід розглядати як більш переважний рішення, ніж canonical, коли мова йде про об’єднання властивостей URL-адреси і запобігання проблем, пов’язаних з дубльованим контентом.
Типові помилки SEO, пов’язані з перенаправленням
Ланцюжки редиректів
З часом на сайт можуть додаватися нові редиректи, і це може призвести до виникнення ланцюжка. Ланцюжок редиректів — це ряд редиректів, наступних друг за іншому.
Поява ланцюжка HTML redirect веде до:
- Висновку попередження клієнта «занадто багато редиректів«.
- Більш тривалому часу затримки.
- Проблем з бюджетом сканування.
- Втрати SEO-ваги.
URL-адреси призначення редіректу повинні регулярно перевірятися, щоб запобігти виникненню ланцюжка.
Редиректи як джерело виникнення затримки
Кожен редирект генерує запит на сервер, який повинен бути оброблений і на який повинен бути отриманий відповідь. Це призводить до збільшення затримки і може стати причиною зменшення активності користувачів на сайті.
Приклад:
Різні клієнти видають повідомлення «Занадто багато редиректів» при різній кількості редиректів.
Ланцюжок редиректів може виникнути швидко, наприклад, якщо має місце ланцюжок URL-корекцій.
В наступній таблиці показано приклад ланцюжка редиректів, яка виникає за певної кількості URL-корекцій, оброблюваних на кожному окремому етапі.
З точки зору SEO, кількість і довжина ланцюжків редиректів повинні бути зведені до мінімуму, коли це тільки можливо. Це дозволить оптимізувати час очікування і поліпшити досвід взаємодії користувачів. Занадто велика кількість редиректів може призвести до втрати SEO-ваги. Редиректи при корекції URL-адреси повинні бути реалізовані таким чином, щоб усі корекції відбувалися одночасно з допомогою одного редіректу.
Перенаправлення як причина проблем з бюджетом сканування
Пошукові системи сканують тільки невеликий фрагмент Мережі. Одним з основних завдань цього процесу є пошук максимально можливої кількості релевантних документів з використанням обмежених ресурсів. Щоб досягти цього, кожному сайту призначається бюджет сканування вмісту пошуковими системами, який визначає максимальну кількість запитів пошукової системи протягом певного періоду часу.
Кожен HTML redirect на іншу сторінку примушує пошукову систему виконувати новий запит, щоб знайти необхідний документ. Таким чином, якщо редиректи підсумовуються, це вплине на використання бюджету сканування. Коли бюджет сканування витрачається в основному на редиректи, більш релевантні розділи сайту можуть відвідуватися пошуковим роботом рідше або зовсім не відвідуватися. Це також може призвести до збільшення часу повного обходу сайту, що погіршує оновлюваність індексу.
Збій відображення URL-адрес з-за редіректу
Збій відображення URL-адреси відбувається, коли пошукач несподівано відображає результати початковий URL-адресу тимчасового редіректу замість URL-адреси призначення.
Якщо використовуються тимчасові редиректи, пошукові системи не можуть правильно відповісти на запитання, чи має вихідний URL-адресу відображатися в результатах пошуку, або кращим варіантом буде URL-адреса призначення. Це може призвести до непередбачуваного поведінки пошукової системи.
Пошукова система може:
- використовувати для відображення в результатах пошуку початковий URL-адресу;
- використовувати для відображення в результатах пошуку URL-призначення redirect HTML index.
Фактори, які можуть бути прийняті до уваги пошуковими системами:
- Період, протягом якого активний тимчасовий редирект;
- Вхідні посилання на кожен URL-адресу;
- Трастовий хоста;
- Довжина первинного URL-адреси і URL-адреси призначення;
- Сигнали користувачів в результатах пошуку;
- Внутрішній або зовнішній це редирект.
Якщо ви хочете перемістити контент з одного URL-адреси на інший, намагайтеся використовувати постійний редирект, щоб уникнути збою відображення.
Якщо відбулося зміщення вашого рейтингу в пошукових системах на користь третьої сторони, обов’язково повідомте пошукову систему про це. Всі основні сервіси надають форми, через які веб-майстри можуть надати таку інформацію.
Петля редиректів через кешування редиректів
Якщо такі редиректи тимчасово використовуються для переадресації вперед і назад між двома URL-адресами, це може призвести до виникнення петлі редиректів.
Приклад:
Якщо користувач відвідує сайт в той час, коли активний перший HTML redirect, браузер кешує його. Коли користувач повертається на сайті, клієнт бачить новий редирект, зворотний первісним, і кешує його. В результаті клієнт може потрапити в петлю між цими двома URL-адресами.
Більшість клієнтів оминають цю проблему. Клієнти, як правило, розривають петлю редиректів, ігноруючи внутрішній кеш і перевіряючи інформацію кешу більш свіжому запитом. Однак такої поведінки не слід очікувати від всіх клієнтів.
Неправильний редирект при пагинации
Глибина пагинации може змінюватися, особливо на сайтах з часто змінним кількістю контенту.
Приклад:
Пагинация може містити певну кількість елементів в один момент часу і меншу кількість елементів в інший. Це призводить до зміни кількості сторінок пагинации. Користувач може побачити одну сторінку пагинации в певний момент, а через якийсь час, коли він намагається відвідати її, вона стає неактивною.
Якщо ви в подібній ситуації використовуєте постійний код статусу, він може кешуватися браузером. Коли число елементів знову змінюється і сторінка пагинации знову може стати активною, користувач може знову спробувати отримати доступ до неї, і тоді він спрямовується на раніше збережений URL-адреса призначення редіректу.
Ми рекомендуємо використовувати некешіруемие тимчасові редиректи для URL-корекції пагинации.
Переклад статті «Redirects & SEO — The Complete Guide» був підготовлений дружною командою проекту Сайтостроение від А до Я.
