Биті посилання та ланцюжки редиректів: як прибрати 3XX, 4XX і 5XX та не зливати вагу

Биті посилання (коди 4XX/5XX) треба лагодити в самому коді сторінки, а не загортати редиректом. Ланцюжки редиректів (3XX) — скорочувати до прямого кінцевого URL, в ідеалі до нуля хопів. А теги meta refresh — повністю замінювати на серверні 301/302. Це розвантажує краул-бюджет, зберігає посилальну вагу й прибирає red flag, через який AI-краулери просто викидають ваші сторінки зі своєї бази.

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

Що взагалі вважається битим посиланням

Формально — будь-яке посилання, що віддає код відповіді з групи 4XX або 5XX. 404 — сторінку видалено або адресу набрано з помилкою. 410 — видалено навмисно й назавжди. 500 — сервер лається сам: сторінка начебто є, але не може підвантажитися, і користувач її не бачить. Усі три випадки для відвідувача виглядають однаково — глухий кут.

Масштаб недооцінюють. За дослідженням Ahrefs, яке ганяє мільярди сторінок, близько 4,6% усіх внутрішніх посилань на зрілих сайтах (старших за три роки) виявляються битими. Це не «десь у когось» — це середня температура по лікарні, і ваш сайт, найпевніше, не виняток.

Чим це шкодить насправді

Перше й очевидне — сигнал занедбаності. Пошукові алгоритми, включно з Google, читають високу щільність 404 в індексі як «сайт покинули». Ресурс давно не чистять, не оновлюють — і його краулінговий пріоритет падає. Не абстрактний «бюджет», а саме пріоритет: робот рідше й неохочіше заходить.

Друге б'є болючіше, і про нього майже не говорять — за биті сторінки вас карає штучний інтелект. Звичайний Googlebot уміє повернутися й переіндексувати сторінку пізніше. А от AI-краулери так не працюють:

«На відміну від класичного Googlebot, який уміє переіндексувати сторінку пізніше, краулери на кшталт GPTBot чи PerplexityBot при зіткненні з помилкою 404 або 500 виключають цей вузол із семантичного графа. У них не так багато ресурсів — їм ще юзерам відповідати треба, а не тільки свій граф поповнювати».

Логіка проста: ШІ не витрачає контекстне вікно на обробку порожніх сторінок. Свої бази знань він поповнює регулярно — він же не гуглить щоразу наново. І якщо в момент обходу на місці сторінки діра, вузол вилітає з графа. Чи повернеться він туди — велике питання. Для видимості в AI-відповідях і GPT-видачі бите посилання — це чистий red flag.

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

Є живучий міф, що редирект передає 100% ваги. Не передає. Кожен додатковий хоп у ланцюжку (хоп 1 — 301, хоп 2 — 301, хоп 3 — ще 301) забирає від 5 до 10% посилальної ваги. І це за обережною оцінкою:

«Мені здається, на око імпакт навіть більший — я пам'ятаю, як серйозно редиректи впливали на позиції. Але якщо вже 10% мають такий нищівний вплив, то це жах».

Далі — краул-бюджет. У роботів жорсткий ліміт на послідовні переходи. Googlebot тягне ланцюжок приблизно до 10 хопів, після чого кидає сканування й фіксує помилку в Search Console, а сторінка випадає з індексу. Але це стеля терпіння, а не норма: документація Google прямо радить тримати ланцюжок коротким — не більше трьох, і вже точно менше п'яти. На практиці ж наявність навіть першого-другого хопа — уже недобрий знак.

І третє, найнепомітніше — TTFB. Кожен внутрішній редирект змушує браузер чи робота робити повторний HTTP-запит до сервера. Це плюс 150–300 мілісекунд очікування на кожен хоп. Про time to first byte ви напевно чули в контексті швидкості сайту — так от, зайві редиректи її тихо роздувають і псують Core Web Vitals.

Окремий біль — meta refresh

Технічний анахронізм, який досі трапляється. Замість серверного 301/302 хтось ставить тег <meta http-equiv="refresh"> — і перенаправляє користувача на рівні браузера. Проблем від нього одразу кілька. Ламається кнопка «Назад»: людина тисне назад, а скрипт тут же несе її вперед. Google деградує передачу PageRank через такий редирект — спершу треба завантажити сторінку, розпарсити HTML, знайти тег, і лише потім іти далі. А історично meta refresh полюбляли спамери для фішингу й дорвеїв, тому пошуковики ставляться до нього з украй великою підозрою й можуть песимізувати сторінку.

Що з цим робити

Биті посилання виправляйте в джерелі, а не редиректом. Знайшли внутрішнє посилання з кодом 404/410/500 — ідете в HTML-код сторінки й міняєте биту адресу на актуальну. Це ж ваш сайт, ви господар посилання. Якщо цільової сторінки більше немає і аналога в неї немає — просто видаліть посилання:

«Якщо цільову сторінку видалено назавжди й аналогів немає — ви видаляєте відсилання з тексту, зберігши анкорний текст як звичайний неклікабельний елемент».

Кастомізуйте 404-ту. На випадок, якщо відвідувач усе ж потрапив на битий URL. Сторінка має віддавати коректний статус 404 (а не 200!) і при цьому містити пошуковий рядок та посилання на головні розділи — щоб утримати людину, а не виштовхнути її із сайту.

Ведіть внутрішні посилання одразу на кінцевий URL. Якщо сторінка A посилається на B, а та редиректиться на C — не треба думати «і так зійде». Міняєте посилання на A так, щоб воно вело прямо на C.

«Ваше завдання — звести внутрішні хопи до нуля. Не до одиниці, а саме до нуля».

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

Приберіть meta refresh повністю. Замініть усі теги на серверні редиректи — через .htaccess для Apache, nginx.conf для Nginx або на рівні бекенду. І використовуйте правильний код: 301 — коли переносите готову сторінку на новий постійний URL; 302 — тимчасово, наприклад поки сторінка в розробці.

Чек-лист перед закриттям задачі

• Нульовий баланс 4XX/5XX: усередині сайту не лишилося битих сторінок. Закиньте домен у наш аудит сайту — він пройдеться по структурі й покаже всі внутрішні 4XX/5XX.
• Пряма переадресація: усі посилання в меню, футері й тілі статей ведуть на кінцеві сторінки, редиректів усередині майже немає.
• Жодних петель: виключені цикли на кшталт A → B → C → A, через які вилазить помилка «too many redirects».
• У HTML немає жодного meta refresh — усі перенаправлення контролює сервер.
• Зовнішні посилання перевірені на життєздатність: биті посилання на чужі покинуті сайти видалені або замінені на живі авторитетні джерела.

Часті запитання

Бите внутрішнє посилання краще полагодити чи заредиректити?

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

Скільки редиректів поспіль — це вже проблема?

Один хоп Google переживе, але цілитися треба в нуль. Кожен зайвий крок забирає 5–10% ваги й додає 150–300 мс до завантаження. Після п'ятого-десятого хопа робот узагалі кине ланцюжок і викине сторінку з індексу.

Чим 301 відрізняється від 302 на практиці?

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

Підсумок

Биті посилання й редиректи — не косметика, а витік. Витікає краул-бюджет, посилальна вага, довіра пошуковика й місце в базі знань AI. Хороша новина: лагодиться це дисципліною, а не бюджетом. Виправляйте посилання в коді, ведіть їх на кінцевий URL, тримайте живу 404-ту й забудьте про meta refresh — і сайт перестане щодня втрачати потроху.

Хочете, щоб хтось пройшовся вашим сайтом і вичистив усі хопи та биті URL? Обговоримо проєкт — проженемо аудит і покажемо, де саме тече.