Битые ссылки и редиректы после переезда сайта: что чинить в первую очередь

Битая ссылка — переход на страницу, которая отвечает ошибкой 404 или 5xx, а цепочка редиректов — путь из нескольких переадресаций подряд между старым и текущим адресом. Порядок починки простой: сначала убирают редирект-петли и 404 на страницах с трафиком или продажами, затем схлопывают длинные цепочки в один переход, и только потом донастраивают внутренние ссылки на старые адреса.

почему возникают битые ссылки и цепочки редиректов

Интернет-магазин автозапчастей переезжает на новую версию сайта в разгар сезона. Разработчик меняет структуру url для карточек товаров: вместо /catalog/detail123/ теперь /zapchasti/dvigatel/123/. Старые адреса никуда не делись из индекса — на них по-прежнему ведут ссылки из рассылки, из уже запущенной рекламной кампании в Директе и из закладок постоянных клиентов. Но 301 редирект со старых url на новые никто не настроил: разработчик собирал новую версию каталога под дедлайн и оставил перенос ссылок «на потом». Поэтому каждый переход по ссылке из письма или объявления заканчивается страницей 404. За две недели число ошибок в отчёте Google Search Console вырастает с десятка до нескольких сотен, а служба поддержки получает одни и те же обращения: «не могу найти запчасть, которую заказывал в прошлый раз», «ссылка из вашего письма не работает».

История с переездом — самый частый, но не единственный сценарий. У битых ссылок и цепочек редиректов обычно один из пяти источников.

• ✓смена CMS, дизайна или структуры url без заранее подготовленной карты соответствий старых и новых адресов
• ✓удаление карточки товара, услуги или целого раздела каталога без переноса на замену или редиректа на категорию
• ✓склейка дублей через несколько редиректов подряд, когда новое правило ставят поверх уже существующего, а не вместо него
• ✓ошибка в правиле сервера — в .htaccess или конфиге nginx, из-за которой страница А ведёт на Б, а Б через пару правил обратно на А
• ✓смена домена или протокола — http на https, адрес с www на без www — без сквозного правила для всех старых адресов сразу

Пока цепочка редиректов и битые ссылки остаются на сайте, теряется не только позиция в выдаче. Поисковый робот тратит краулинговый бюджет на переходы по неработающим адресам вместо новых страниц — а у сайта с большим каталогом этот бюджет и так ограничен. Вес ссылки размывается на каждом лишнем прыжке в цепочке, поэтому старая страница с внешними ссылками, которая раньше хорошо ранжировалась, после переезда теряет часть позиций даже при формально настроенном редиректе. Пользователь, попавший на 404 с рекламного объявления, разворачивается — рекламный бюджет на этот клик уже списан, а заявка не оформлена. Для интернет-магазина с активной контекстной рекламой это прямые потери в каждом еженедельном отчёте по расходу бюджета, а в сезон — упущенные заявки, которые конкуренты закрывают вместо него.

как найти все битые ссылки и редиректы на сайте

сканер сайта

Полный список проблемных адресов даёт сканирование сайта краулером: программа обходит все страницы по ссылкам, как поисковый робот, и фиксирует код ответа каждой — 200, 301, 302, 404, 500. В отчёте сразу видно, где редирект ведёт не туда, где цепочка из нескольких переходов подряд, а где ссылка бьётся в пустоту. Важная деталь, которую часто упускают: сканер показывает не только конечный код ответа, но и длину цепочки — сколько промежуточных адресов между исходным url и финальной страницей. Для сайта на несколько тысяч страниц такой обход занимает от получаса до нескольких часов; вручную проверить каждую ссылку в разумные сроки нереально, а выборочная проверка «на глаз» почти всегда пропускает ошибки в глубоких разделах каталога.

отчёты поисковых систем

Второй источник — сами поисковики. В Яндекс.Вебмастере это раздел «Диагностика» и отчёт по некорректным ответам сервера, в Google Search Console — раздел «Страницы» с ошибками индексирования и отдельно вкладка по переадресациям. Оба сервиса показывают адреса, которые робот уже обошёл и на которых получил ошибку, включая случаи, когда на битую страницу продолжают ссылаться внешние сайты — такие ссылки сканер собственного сайта не увидит, потому что находятся не на нём. Свести данные сканера и поисковых отчётов в один список, отсеять дубли и расставить приоритеты — часть технического аудита сайта по девяти направлениям: там же проверяют скорость загрузки, индексацию и ещё семь параметров, которые влияют на позиции.

как исправить битые ссылки и цепочки редиректов: порядок действий

Список из нескольких сотен адресов не чинят подряд сверху вниз — иначе неделя уйдёт на правку ссылки в старой статье блога, пока карточка товара с рекламным трафиком продолжает отвечать 404. Порядок такой: сначала редирект-петли и 404 на страницах, которые приносят трафик или продажи, затем длинные цепочки редиректов, и только потом — внутренние и внешние ссылки на старые адреса.

чем 301 отличается от 302 в цепочке

В цепочках редиректов часто находят 302 там, где нужен 301. Временный редирект 302 поисковик воспринимает буквально: страница ещё вернётся, поэтому индексирует и исходный, и целевой адрес, а вес ссылки передаёт не полностью. Если переезд окончательный — со старой версии каталога на новую, с http на https, — везде должен стоять постоянный 301. 302 оставляют только для действительно временных случаев: технических работ, сезонного отключения раздела, A/B-теста страницы.

Ручная расстановка приоритетов по такому списку занимает дни, особенно если сайт объединяет каталог из тысяч товаров и услуг. В аудите сайта эта работа — часть отчёта: список ошибок сразу приходит с пометкой, что чинить в первую очередь, а что можно отложить на следующий спринт.

что делать, если ошибка повторяется после исправления

Редирект иногда возвращается через день-два после того, как его вроде бы поправили. Частые причины: старый sitemap.xml всё ещё ссылается на снесённые адреса, и поисковик продолжает их обходить; кэш CDN или самого движка отдаёт прежнюю версию страницы, пока не истечёт срок жизни кэша; шаблон каталога — например, блок «похожие товары» или хлебные крошки — генерирует ссылки на старый url автоматически, потому что правило подстановки в шаблоне не обновили; правило редиректа прописано только в настройках CMS, а не на уровне сервера, и его перезаписывает очередное обновление модуля.

• ✓обновить sitemap.xml и отправить его на переобход в Вебмастере и Search Console
• ✓сбросить кэш CDN и самого движка после каждой правки редиректа, а не ждать, пока он истечёт сам
• ✓проверить шаблоны, которые генерируют ссылки автоматически — похожие товары, хлебные крошки, фильтры каталога
• ✓закрепить правило редиректа на уровне сервера или веб-сервера, а не только в admin-панели CMS

Если правки в конфиге каждый раз откатываются, а сайт держится на хостинге, который не тянет корректную обработку правил редиректа и периодически отдаёт таймауты вместо ответа, проблема уже не в SEO-настройках, а в самом сервере. Настройка и сопровождение сервера в таких случаях считаются отдельно от аудита — состав работ и стоимость указаны на странице тарифов.

как предотвратить появление новых битых ссылок и редиректов

что проверять при каждом релизе

Большинство битых ссылок появляются не сами по себе, а после конкретного действия — релиза новой версии сайта, переноса раздела, смены хостинга. Проверку стоит встроить в сам процесс релиза, а не вспоминать о ней постфактум.

• ✓перед переносом раздела или сменой CMS готовить карту редиректов заранее, а не после того, как старые страницы уже недоступны
• ✓не удалять страницы бесследно — переводить в архив или ставить 301 на ближайшую по смыслу замену
• ✓раз в квартал прогонять сайт сканером и сверять результат с отчётами Вебмастера и Search Console
• ✓следить, чтобы новый редирект вёл сразу на финальный адрес, а не добавлялся поверх старого правила
• ✓закреплять правило редиректа на уровне сервера, чтобы обновление CMS или отдельного модуля его не сбрасывало

Регулярная проверка занимает часы, а разбор жалоб от клиентов, которые не могут найти нужную страницу, — дни и упущенные заявки. Технический аудит сайта закрывает проверку битых ссылок и цепочек редиректов вместе с восемью другими направлениями и приходит одним отчётом с готовым порядком починки — от критичных петель до второстепенных ссылок в старых статьях.

❓ Частые вопросы

Сколько времени занимает поиск всех битых ссылок на сайте с несколькими тысячами страниц?

Зависит от размера сайта, но полное сканирование краулером обычно занимает от получаса до нескольких часов, а разбор отчёта и расстановка приоритетов по правкам — ещё день-два работы. Ручной поиск без сканера растягивается на недели и почти всегда пропускает часть ошибок в глубоких разделах каталога, которые редко открывают вручную.

Может ли 301 редирект навредить позициям сайта?

Сам по себе аккуратный 301 со старого адреса на прямую замену вреда не наносит. Проблема начинается, когда редиректов несколько подряд или страница ведёт на нерелевантный раздел — тогда поисковик хуже передаёт вес ссылки и не понимает, какую страницу считать актуальной.

Нужно ли чинить 404 на страницах, у которых почти нет трафика?

В первую очередь нет. Такие страницы можно оставить в очереди на потом и сосредоточиться на карточках и посадочных, куда идёт реклама или органический трафик. Проверить их стоит, но критичный приоритет — у страниц, которые реально приносят заявки и продажи.

Почему редирект снова ломается после переноса сайта на новый хостинг?

Чаще всего правила редиректа были прописаны в конфиге старого сервера или в модуле CMS, который не перенесли при переезде. Если новый сервер слабый, дополнительно могут появляться таймауты, которые поисковик тоже фиксирует как ошибку доступности страницы.

Как понять, что на сайте есть цепочка редиректов, а не просто один переход?

В отчёте сканера или в Google Search Console видно количество промежуточных адресов между исходным url и финальной страницей. Если между ними больше одного перехода — это уже цепочка, и её стоит схлопнуть в один прямой редирект, чтобы не терять вес ссылки.