Ланцюжок редиректів і SEO: скільки переходів забагато?

Ланцюжок редиректів - це два чи більше редиректів поспіль між URL, який хтось запросив, і сторінкою, що зрештою відповідає 200. Google документує, що Googlebot проходить до 10 переходів, радить спрямовувати одразу на кінцеву ціль і називає довгі ланцюжки гальмом для краулінгу. Він не каже, що вони руйнують ранжування, і каже, що постійні редиректи не спричиняють втрати PageRank. Тож чесний підсумок такий: ланцюжки - це проблема затримки та ефективності краулінгу, яку слід недорого виправити, а не катастрофа для SEO.

Більшість ланцюжків будують не навмисно. Хтось додає правило HTTPS, хтось інший - правило www, маркетинговий інструмент обгортає посилання трекером, і кожен перехід сам по собі виправданий. Нижче: як нашаровуються рівні, скільки коштує кожен перехід, які твердження зі SEO витримують перевірку документацією Google і як простежити й спростити ланцюжок. Для початку про словник кодів статусу - типи редиректів URL є картою. Якщо ланцюжок повертається сам на себе, вам потрібен натомість матеріал як виправити цикл редиректів.

Що таке ланцюжок редиректів

Ланцюжок редиректів виникає, коли URL A переадресовує на B, а B переадресовує на C, замість того щоб A вказував на C безпосередньо. Кожна стрілка - окрема HTTP-відповідь, і клієнт робить новий запит для кожної. Один редирект - це нормально; "ланцюжок" починається з двох.

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

Як утворюються ланцюжки редиректів

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

• Схема. http:// переходить на https://, зазвичай за правилом сервера чи проксі.
• Хост. Апекс переходить на www, або навпаки, за іншим правилом, що спрацьовує після правила схеми.
• Шлях. Нормалізатор кінцевого слеша чи малих літер переписує /Promo/ на /promo.
• Обгортка кампанії чи відстеження. Трекер рекламних кліків, переписувач посилань поштової платформи або коротке посилання стоїть перед усім іншим.
• Застаріла карта. Редирект від минулого редизайну, який ніхто не переспрямував.

Складіть їх разом, і звичайний http://example.com/Promo/ може пройти чотири переходи: на HTTPS, потім на www, потім на нормалізований шлях, потім через старе правило редизайну на живу сторінку. Короткі посилання приєднуються спереду. Один - законний перехід. Шкода починається, коли його ціль не є кінцевим URL. Вставте http://example.com/promo як ціль, і ваше посилання очолить ланцюжок, який побудував сайт цілі, непомітно для вас. Чи шкодять скорочувачі URL SEO охоплює бік ранжування цього запитання; коротка відповідь така: один чистий перехід - нормально, а складений - вам виправляти.

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

Скільки переходів проходить Googlebot?

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

Десять - це стеля, а не рекомендація. Настанова Google щодо переїзду сайту каже переадресовувати безпосередньо на кінцеву ціль, а коли це неможливо, тримати ланцюжок коротким, "в ідеалі не більше 3 і менше 5", бо ланцюжки додають затримку для користувачів, а не всі користувацькі агенти підтримують довгі ланцюжки. Цитуйте це так: мета - один перехід, допуск - кілька, а жорстка зупинка - на десяти.

Браузери мають власні ліміти. Chrome здається на 20 і повертає ERR_TOO_MANY_REDIRECTS, що є симптомом, описаним у посібнику про цикли редиректів. Стандарт HTTP теж не фіксує числа: RFC 9110 лише каже, що клієнти мають виявляти циклічні переадресації та втручатися.

Скільки затримки коштує кожен перехід

Кожен перехід коштує щонайменше один мережевий круговий рейс. Перехід на інше ім'я хоста коштує більше. Клієнт розв'язує нове ім'я, відкриває TCP-з'єднання й завершує рукостискання TLS, перш ніж зможе щось надіслати. Власний аудит Lighthouse провалює сторінку з двома чи більше редиректами й каже, що зайвий рейс може затримати ресурс "на сотні мілісекунд".

Ось арифметика, як ілюстрація, а не еталонний тест. Припустимо круговий рейс 100 мс, що звичайно для мобільного зв'язку із середнім сигналом. Перехід на новий хост із DNS, TCP і рукостисканням TLS 1.3 перед запитом легко коштує три-чотири кругові рейси, тобто 300-400 мс. Перехід, що повторно використовує відкрите з'єднання з тим самим хостом, коштує один, тобто 100 мс. Чотирипереходовий ланцюжок із двома новими з'єднаннями тоді витрачає приблизно 900 мс, перш ніж почнеться справжня сторінка, проти близько 450 мс для одного плоского редиректу.

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

Ланцюжки також втрачають дані. Кожен перехід - це місце, де правило переписування може відкинути рядок запиту, а видалений utm_source - звичний спосіб, яким UTM-параметри зникають з аналітики.

Вага посилань і краул-бюджет: що документує Google

Спершу вага посилань. Документація Google щодо переїзду сайту стверджує, що "301 та інші постійні редиректи не спричиняють втрати PageRank". Gary Illyes із Google сказав те саме про редиректи 30x у 2016 році, але це був допис у соцмережі, а не документація. Тож старе емпіричне правило, що кожен перехід редиректу витікає фіксований відсоток ваги, - фольклор. Жодне джерело Google не називає відсотка, а числа на кшталт 15 відсотків повторюють у дописах зі SEO без цитування. Якщо хтось дає вам таке, попросіть джерело.

Ланцюжки все одно не безкоштовні. Задокументовано два ефекти. По-перше, ефективність краулінгу: настанова Google щодо краул-бюджету для великих сайтів прямо каже уникати довгих ланцюжків редиректів, що негативно впливають на краулінг. По-друге, затримка для користувача, описана вище, що живить сигнали враження від сторінки. Краул-бюджет важливий переважно для дуже великих чи швидкозмінних сайтів; сайт на 200 сторінок навряд чи відчує проблему краул-бюджету від кількох ланцюжків, хоча відвідувачі все одно відчують вартість швидкості.

Є й нюанс індексації. Google використовує постійні редиректи як канонічний сигнал для цілі. Який URL показується, залежить частково від того, чи був кожен редирект тимчасовим чи постійним. Ланцюжок, що змішує переходи 301 і 302, робить цей сигнал менш чітким, а це добра причина один раз визначити коди. Canonical проти редиректу 301 розбирає, як ці сигнали взаємодіють.

Моя позиція: не панікуйте щодо ваги, виправляйте ланцюжки заради швидкості та гігієни краулінгу й не обіцяйте приросту ранжування від спрощення одного. Ніхто не задокументував такого приросту. Швидше завантаження й менше марних запитів - те, що можна виміряти.

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

Почніть із curl, бо він друкує кожен перехід там, де браузер їх ховає. Перша команда показує рядок статусу та Location кожної відповіді:

curl -sIL http://example.com/Promo/ | grep -E '^HTTP|^[Ll]ocation'

Чистий результат - один 3xx, а потім 200. Ланцюжок спершу показує два чи більше рядків 3xx. Щоб отримати кількість і час, витрачений на редиректи, попросіть curl про його власні числа:

curl -sL -o /dev/null \
  -w 'hops: %{num_redirects}\nfinal: %{url_effective}\nredirect time: %{time_redirect}s\ntotal: %{time_total}s\n' \
  http://example.com/Promo/

Два застереження. -I надсилає запит HEAD, а кілька серверів відповідають на HEAD інакше, ніж на GET, тож якщо результат виглядає надто чистим, повторіть без -I і відкиньте тіло через -o /dev/null -D -. І тестуйте найгірший варіант, той, що спрацьовує на кожне правило: http://, без www, шлях з великими літерами, кінцевий слеш. Тестування лише канонічного URL - це те, як ланцюжки виживають. Я краще перетестую потворні варіанти, ніж довірятиму чистому.

У браузері відкрийте devtools, перейдіть на панель Network, поставте позначку "Preserve log", щоб попередні переходи пережили навігацію, і перезавантажте. Кожен редирект показується окремим рядком 301 чи 302. Наш перевіряльник посилань показує той самий ланцюжок без терміналу.

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

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

Спрощення означає, що кожен застарілий URL вказує безпосередньо на кінцевий URL. Кроки по порядку:

1. Оберіть канонічну форму: схему, хост, політику кінцевого слеша та регістр. Запишіть її.
2. Простежте кожен старий URL і запишіть його кінцеву ціль.
3. Перепишіть кожне правило так, щоб воно цілило в цю кінцеву ціль, а не в наступне правило.
4. Оновіть внутрішні посилання, мапи сайту й теги rel="canonical" до кінцевого URL, щоб краулери та користувачі взагалі перестали входити в ланцюжок.
5. Повторіть трасування й переконайтеся, що перехід щонайбільше один.

Прийом на боці сервера - об'єднати схему та хост в одному правилі. В nginx це виглядає так, використовуючи $request_uri, щоб шлях і рядок запиту вціліли:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    # ssl_certificate and key directives go here
    return 301 https://www.example.com$request_uri;
}

Запит http://example.com/page тепер переходить на https://www.example.com/page одним переходом, там, де два правила дали б два. Налаштування редиректу в .htaccess і як переадресувати URL охоплюють еквіваленти для Apache та рівня застосунку.

Спершу тестуйте з 302. Браузери агресивно кешують 301, тож помилка затримується. Коли ланцюжок складається з одного переходу, перемкніться на постійний код. HSTS також допомагає: після того як браузер побачив заголовок Strict-Transport-Security, він внутрішньо оновлює http:// до https://, тож відвідувачі, що повертаються, зовсім пропускають цей перехід. Це нічого не дає краулерам чи першим відвідувачам, тож воно доповнює правило одного переходу, а не замінює його.

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

Як виглядає правильно поводжений редирект короткого посилання

Коротке посилання має бути рівно одним переходом від слага до кінцевої канонічної сторінки, і нічим більше. Запит досягає короткого домену. Відповідь - 3xx із ціллю в Location. Ціль відповідає 200 безпосередньо. Жодного проміжного скорочувача, жодного трекера, що переадресовує знову, жодної цілі, що переходить на www чи HTTPS, бо ви вставили стару форму.

Код залежить від випадку використання.

• 302 (або 307) для відстежуваних, редагованих посилань у кампаніях, дописах у соцмережах, електронній пошті та QR-кодах. Він дає змогу пізніше змінити ціль і тримає кожен клік у досяжності рівня редиректів, тож аналітика лишається повною.
• 301 (або 308), коли переїзд постійний і ви хочете, щоб ціль сприймалася як канонічна, наприклад vanity URL, що назавжди замінює стару адресу.

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

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

Цей допис входить до кластера інженерії. Повну карту кодів статусу читайте в матеріалі типи редиректів URL, а про рівень редиректів за коротким посиланням - як працюють скорочувачі URL.

Пов'язані публікації в блозі

• Цикл редиректів: як знайти й виправити ERR_TOO_MANY_REDIRECTS
• Типи редиректів URL: 301, 302, 307, 308 та інші
• 301 проти 302: який використовувати для коротких посилань
• Чи шкодять скорочувачі URL SEO? Чесна відповідь
• Canonical проти редиректу 301: як обрати правильний сигнал
• Як переадресувати URL: шість способів і коли який правильний