Redirect Chains: що це таке, як знайти і виправити для SEO

Що таке redirect chain

Redirect chain (ланцюжок редиректів) — це послідовність автоматичних переспрямувань, де браузер або пошуковий робот отримує не кінцеву сторінку, а проміжну URL-адресу, яка знову перенаправляє далі. Замість прямого маршруту A → D система проходить A → B → C → D.

У «нормальному» стані редирект виглядає так: запит на сторінку — відповідь 301 із новою адресою — браузер завантажує потрібний ресурс. Один стрибок. Але коли на сервері залишаються старі правила переспрямувань, накладені одне на одне після кількох редизайнів або технічних змін, виникає ланцюжок — і кожна проміжна ланка ускладнює роботу і для користувача, і для Googlebot.

Класичний приклад: інтернет-магазин перейшов із HTTP на HTTPS (перший редирект), потім змінив структуру URL з /category/product на /product (другий), а ще раніше при запуску передав трафік з www на non-www (третій). Жодного разу старі правила не прибирали — і тепер кожен запит до застарілих сторінок проходить три стрибки замість одного.

Типи редиректів і їхній вплив

Не всі редиректи рівнозначні. Різні коди HTTP-статусу по-різному впливають на передачу посилальної ваги та індексацію.

301 — основний інструмент

Постійне переспрямування з кодом 301 — стандарт для зміни URL-адрес. Google офіційно підтверджує, що 301 передає посилальну вагу на кінцеву сторінку. Але навіть 301, пройдений через ланцюжок, поступово «розмиває» цю вагу: кожна проміжна ланка відбирає частину сигналу.

302 і 307 — тимчасові, але небезпечні у неправильному контексті

Тимчасові редиректи не сигналізують Google, що URL змінився остаточно. Якщо сторінка переспрямована через 302 вже рік, Googlebot продовжує індексувати початкову адресу, а не кінцеву. Це означає, що посилання зовні на старий URL не конвертуються в капітал нової сторінки.

JavaScript-редиректи — «чорна діра»

Переспрямування через JavaScript може взагалі не спрацювати для Googlebot на першому проході. Робот сканує HTML, ставить JavaScript у чергу відкладеного виконання — і поки черга дійде до скрипту, Google вже зафіксує стару адресу як кінцеву. Результат: сторінка індексується без урахування редиректу.

Чому ланцюжки шкідливі для SEO

Redirect chains шкодять одразу за кількома напрямами. Зупинимося на кожному детально.

Втрата PageRank і link equity

Кожна ланка у ланцюжку — це точка, де частина посилальної ваги «протікає». Стара оцінка дослідників говорила приблизно про 15% втрати на кожен проміжний перехід. Сучасний алгоритм Google дещо складніший, але принцип залишається: чим коротший шлях від посилання до кінцевої сторінки, тим більше ваги вона отримує. Ланцюжок A→B→C→D замість прямого A→D може позбавити сторінку D значної частини «заробленого» посилального капіталу.

Уповільнення завантаження

Кожен стрибок у ланцюжку — це окремий HTTP-запит, DNS-розв'язка (якщо змінюється домен), з'єднання TCP і час очікування відповіді сервера. Навіть якщо кожна ланка відповідає за 50–100 мс, ланцюжок із трьох стрибків додає 150–300 мс затримки ще до того, як браузер отримає першу корисну відповідь. Для Core Web Vitals, де LCP вимірюється в мілісекундах, це суттєво.

Ліміт кроків Googlebot

Google офіційно описує підтримку до 10 переспрямувань у ланцюжку, але документація Google рекомендує уникати навіть трьох. На практиці SEO-спеціалісти фіксують, що після 5 хопів Googlebot може зупинитися і не дійти до кінцевої сторінки. У такому разі остання URL взагалі не індексується через ланцюжок редиректів — сторінка просто випадає з пошуку.

Мобільні пристрої

Мобільні з'єднання мають вищу затримку (latency) порівняно з дротовими. На LTE кожен HTTP-запит може коштувати 60–120 мс RTT, на 3G — і більше. Ланцюжок із трьох редиректів на мобільному — це додаткові 180–360 мс до першого байту. Google враховує швидкість завантаження для мобільної індексації, тому redirect chains безпосередньо б'ють по мобільних позиціях.

Краулінговий бюджет

Для великих сайтів — інтернет-магазинів з тисячами SKU, новинних порталів, каталогів — краулінговий бюджет (crawl budget) є обмеженим ресурсом. Googlebot витрачає час і запити на проходження кожної ланки ланцюжка. Сторінки з довгими ланцюжками «забирають» бюджет у нових або важливих URL, які могли б бути проіндексовані натомість.

Як знайти redirect chains

Існує кілька методів виявлення ланцюжків редиректів — від ручної перевірки до автоматичного аудиту всього сайту.

Screaming Frog SEO Spider

Найпоширеніший інструмент для технічного SEO-аудиту. Після сканування перейдіть до вкладки Response Codes → Redirection (3xx), потім відфільтруйте звіт за колонкою Redirect Chain або скористайтеся вбудованим звітом Redirect Chains у меню Reports. Screaming Frog покаже кожну проміжну URL і кількість стрибків у ланцюжку.

Ahrefs Site Audit

У розділі Site Audit → Issues шукайте проблему «Redirect chain». Ahrefs автоматично класифікує сторінки з більш ніж одним переспрямуванням і показує повний ланцюжок від початкової до кінцевої URL. Зручно, що проблеми можна сортувати за кількістю зовнішніх посилань — так легше пріоритизувати виправлення.

Google Search Console

GSC не показує redirect chains прямо, але розділ Coverage → Excluded → Redirect Error сигналізує, коли Googlebot не зміг пройти ланцюжок до кінця. Також перевіряйте звіт Page Indexing на предмет сторінок зі статусом «Crawled — currently not indexed» — частина з них може бути наслідком довгих ланцюжків.

Ручна перевірка через curl

Для окремих URL найшвидший спосіб — команда в терміналі:

curl -sIL -w "%{url_effective}\n" https://example.com/old-page

Прапор -L змушує curl проходити всі редиректи, -I повертає лише заголовки. У виводі ви побачите кожну проміжну відповідь і фінальну URL. Зручно для швидкої перевірки конкретних сторінок без запуску повного аудиту.

Онлайн-інструменти

Для разових перевірок підійдуть безкоштовні сервіси — httpstatus.io, redirect-checker.org або аналогічні. Вони показують весь ланцюжок переспрямувань і HTTP-коди на кожному кроці. Мінус — не замінять систематичного аудиту всього сайту.

Як виправити ланцюжки редиректів

Виправлення redirect chain зводиться до одного принципу: замість ланцюжка A→B→C→D налаштувати прямий редирект A→D. Проміжні ланки після цього або видаляються, або також отримують пряме правило на фінальну URL.

Крок 1. Скласти повну карту поточних редиректів

Перед виправленнями зберіть усі наявні правила в одному місці. Якщо сайт на Apache — це файл .htaccess, на Nginx — блок server { } у конфігурації, на хмарних CDN (Cloudflare, AWS CloudFront) — відповідні правила перенаправлення в панелі керування. CMS-платформи (WordPress, Magento, OpenCart) можуть додавати власні редиректи через плагіни або адмінпанель — перевіряйте і їх.

Крок 2. Виявити кінцеву URL для кожного ланцюжка

Для кожної початкової адреси, яка запускає ланцюжок, визначте, куди в результаті потрапляє користувач. Це і є ваш «D» — кінцева точка. Перевірте, що ця URL:

• повертає статус 200 (не черговий редирект)
• доступна і проіндексована Google
• є «правильною» сторінкою з точки зору контенту

Крок 3. Замінити ланцюжок прямим 301

Налаштуйте пряме правило: будь-який запит до A (і до всіх проміжних B, C) одразу переспрямовується на D. Для Apache у .htaccess:

RedirectPermanent /old-page-a https://example.com/final-page-d
RedirectPermanent /intermediate-page-b https://example.com/final-page-d
RedirectPermanent /intermediate-page-c https://example.com/final-page-d

Крок 4. Перевірити результат

Після внесення змін перевірте кожну початкову URL через curl або httpstatus.io. Очікуваний результат: один стрибок із кодом 301 прямо на фінальну сторінку.

Крок 5. Оновити внутрішні посилання

Виправлення редиректів на сервері — це лише половина роботи. Якщо внутрішні посилання на сайті ведуть на A або B, а не на фінальну D, Googlebot при кожному обходженні все одно буде проходити хоча б один зайвий крок. Масова заміна внутрішніх посилань через пошук по базі даних або CMS-функціонал повністю усуває цю проблему.

Ланцюжки після міграції та редизайну

Найпоширеніша причина появи redirect chains — технічні зміни без ревізії існуючих правил. Розглянемо типові сценарії.

Перехід на HTTPS

Коли сайт переходить із HTTP на HTTPS, правильне налаштування виглядає так:

• http://example.com/page → 301 → https://example.com/page

Але якщо раніше вже був редирект з www на non-www і він записаний в .htaccess першим, виникає ланцюжок:

• http://www.example.com/page → http://example.com/page → https://example.com/page

Рішення: об'єднати обидва правила в одне, яке одразу переспрямовує будь-яку комбінацію (HTTP + www) на HTTPS + non-www.

Зміна структури URL

Редизайн часто супроводжується зміною шаблонів URL: /blog/2023/title стає /blog/title. Якщо при цьому вже існують редиректи зі старішої структури, ланцюжок подовжується ще на одну ланку. Перед впровадженням нової структури потрібно переглянути всі наявні правила і скласти повну карту «старе → нове».

Зміна домену

Міграція з одного домену на інший — найбільш ризикована ситуація. Якщо на старому домені вже є ланцюжки, вони «переїжджають» разом із правилами. Рекомендований підхід: перед міграцією провести повний аудит і виправити всі redirect chains на старому домені, а вже потім налаштовувати редиректи з нього на новий.

Моніторинг і профілактика

Виправити redirect chains один раз — не достатньо. Нові ланцюжки з'являються після кожного оновлення структури, додавання нових редиректів або зміни конфігурації сервера. Систематичний моніторинг запобігає накопиченню проблем.

Регулярний технічний аудит

Для сайтів з активним оновленням контенту або частими технічними змінами рекомендується технічний SEO-аудит щоквартально. Для стабільних сайтів — раз на пів року. Включайте перевірку redirect chains у стандартний чек-лист аудиту.

Автоматичний моніторинг у Ahrefs або Screaming Frog

Ahrefs Site Audit підтримує розклад автоматичного сканування. Налаштуйте щотижневий або щомісячний аудит із сповіщенням про нові redirect chains — це дозволить реагувати на проблеми до того, як вони вплинуть на позиції.

Процедура перед впровадженням змін

Будь-яке технічне оновлення, яке стосується URL або правил переспрямування, повинно проходити через чек-лист:

1. Зберіть усі наявні редиректи в одному файлі
2. Перевірте, чи нові правила не створюють ланцюжки з існуючими
3. Протестуйте зміни на staging-середовищі перед публікацією
4. Після публікації запустіть вибіркову перевірку ключових URL через curl

За нашою практикою, найбільша концентрація redirect chains — на сторінках категорій інтернет-магазинів після сезонних оновлень структури. Часто одна зміна шаблону URL «тягне» за собою десятки ланцюжків одночасно.

Якщо потрібна допомога з виявленням і виправленням ланцюжків у рамках повноцінного SEO-аудиту сайту або комплексного SEO-просування, команда SEO-Factory проводить технічний аналіз і готує детальні рекомендації щодо виправлення. Аудит включає перевірку canonical-тегів, Core Web Vitals і проблем із редиректами в комплексі.

Поширені запитання