Битые ссылки и цепочки редиректов: как убрать 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? Обсудим проект — прогоним аудит и покажем, где именно течёт.