Битые ссылки на сайте - самая частая техническая проблема, которую я вижу на аудитах: переезд на новый домен, смена CMS, ручная правка меню в шапке - и через месяц сотни страниц молча отдают 404, а поисковый робот на каждом обходе теряет часть краулингового бюджета на пустые адреса. Разбираю, как их искать, чем закрывать и в каких случаях 404 лучше вообще не трогать.
Почему на сайте появляются битые ссылки
Причины почти всегда одни и те же, я вижу их из проекта в проект:
- Удаление товаров или категорий без 301-редиректа - классика для WooCommerce после чистки каталога перед сезонной распродажей.
- Смена ЧПУ при переезде с Tilda на WordPress: старые адреса вида /page123 меняются на человекочитаемые, а внешние сайты продолжают ссылаться на прежний URL.
- Ручная правка меню - кто-то поменял пункт в шапке, а саму страницу переименовал или удалил, забыв обновить внутренние ссылки на неё.
- Смена платёжного модуля: после перехода на T‑Bank вместо старого эквайринга ссылки на страницы оплаты и чеков из писем и админки годами продолжают вести на несуществующие адреса.
- Смена виджета доставки СДЭК - при обновлении API старые ссылки на трек-номера в письмах клиентам превращаются в 404.
- Удалённые файлы - PDF-прайсы, инструкции, изображения, которые почистили в медиабиблиотеке, а ссылки на них остались в статьях.
- Опечатки в ручных ссылках внутри текста блога.
Как найти неработающие ссылки: инструменты и ручные методы
Вручную по всему сайту искать смысла нет - за это отвечают краулеры и отчёты поисковых систем.
Screaming Frog и Netpeak Spider
На проекте на 3200 страниц Screaming Frog находит все битые ссылки за 15-20 минут в обычном режиме краулинга - просто сортирую отчёт по колонке Status Code и смотрю всё, что начинается с 4. Бесплатная версия ограничена 500 URL за сессию - этого хватает на сайт-визитку или лендинг, а для магазина на тысячи товаров нужна платная лицензия или Netpeak Spider с похожим лимитом.
Google Search Console и Яндекс.Вебмастер
В Search Console раздел «Страницы» → «Не проиндексировано» → «Ошибка 404» показывает адреса, которые находил робот при последнем обходе, обычно с задержкой 3-7 дней от момента появления ссылки. В Яндекс.Вебмастере тот же список лежит в «Индексировании» → «Страницы в поиске» с фильтром по статусу - там же видно, есть ли у страницы внешние ссылки, что важно для следующего шага.
Скрипт для точечной проверки
Когда нужно быстро перепроверить конкретный раздел после правок, а не гонять полный краулинг, использую простой скрипт на Python по списку URL из sitemap.xml:
import requests
urls = open("urls.txt").read().splitlines()
for url in urls:
try:
r = requests.head(url, allow_redirects=True, timeout=5)
if r.status_code >= 400:
print(url, r.status_code)
except requests.RequestException as e:
print(url, "ошибка соединения", e)
Проходит по сотне-другой адресов за секунды и сразу показывает, что реально отдаёт 404, а что просто редиректит через несколько хопов.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
404 ошибка: когда её оставить, а когда закрывать редиректом
Не каждый найденный 404 нужно тут же редиректить. Страница без обратных ссылок и без органического трафика может спокойно отдавать честный 404 - Google выкинет её из индекса за несколько недель, и ничего страшного не произойдёт. А вот страница, на которую ведут внешние ссылки или которая раньше собирала трафик, требует 301 на ближайший смысловой аналог.
На одном интернет-магазине на WooCommerce после смены структуры категорий нашёл 140 битых ссылок. У 12 из них были внешние ссылки с других сайтов и остаточный органический трафик - их отредиректил на новые категории. Остальные 128 просто убрал из sitemap и оставил отдавать честный 404, не тратя время на редиректы в никуда - проверять обратные ссылки перед решением помогает отчёт по бэклинкам в Search Console или в любом стороннем сервисе анализа ссылок.
Редирект 301 или 410 - что выбрать для закрытия битых ссылок
Разница между кодами не формальность - от неё зависит, как быстро и как аккуратно поисковик уберёт мёртвый URL и передаст вес живому.
| Код | Когда использовать | Что происходит с индексом |
|---|---|---|
| 301 | Страница переехала, есть прямой аналог с похожим содержанием | Вес ссылок передаётся новому адресу, переиндексация обычно за 1-2 недели |
| 410 | Страница удалена навсегда, замены нет и не планируется | Выпадает из индекса быстрее, чем при обычном 404, часто за 1-3 недели |
| 404 | Страницу убрали, но однозначной замены нет и трафика на ней не было | Google может держать адрес в очереди на переобход месяцами, особенно если на него ведут внешние ссылки |
Отдельно проговорю частую ошибку - массовый редирект всех битых ссылок на главную. Google в таких случаях нередко трактует это как мягкий 404 (soft 404) и всё равно выкидывает страницу из индекса, только с задержкой и потерей веса ссылок по пути. Редиректить стоит на страницу, которая реально закрывает тот же запрос, а не куда попало.
Мониторинг битых ссылок в фоне: WooCommerce, Tilda и автоматизация
Разовая чистка снимает симптом, но через пару месяцев правок каталога или контента список 404 снова растёт.
WooCommerce после смены каталога или эквайринга
После смены категорий, плагина оплаты или структуры атрибутов в WooCommerce я всегда прогоняю краулер по всему каталогу - там чаще всего страдают карточки товаров со скрытыми вариациями и старые ссылки из писем с подтверждением заказа, которые никто не обновляет годами.
n8n и регулярная проверка sitemap
Для сайтов с ежедневными правками контента ставлю сценарий в n8n: по расписанию раз в неделю нода забирает sitemap.xml, проходит по всем URL и при обнаружении 4xx отправляет уведомление в Telegram через бот. Такие сценарии я собираю на n8n или пишу отдельным скриптом на Python с расписанием - в библиотеке готовых скриптов есть похожий пример мониторинга, который можно адаптировать под свой sitemap без разработки с нуля.
Ручная проверка занимает 20-30 минут, но если контент меняется каждую неделю, дешевле настроить это один раз, чем гонять краулер руками. Такая настройка на n8n у меня стоит от 25 000 ₽, отдельный скрипт на Python с уведомлениями в Telegram - от 20 000 ₽.
Чтобы сайт работал без сбоев
Техподдержка
от 15 000 ₽/мес
Подробнее →Частые вопросы
Как часто проверять сайт на битые ссылки?
Для сайта с активным контентом или каталогом - раз в месяц. Для статичного сайта-визитки хватает раз в квартал. После любой миграции, смены CMS или структуры категорий проверку делаю в первую неделю после изменений, не откладывая.
Влияют ли битые ссылки напрямую на позиции в поиске?
Прямого фактора ранжирования «много 404 - минус в позициях» нет, но большое количество битых ссылок тратит краулинговый бюджет впустую и портит поведенческие метрики - пользователь уходит с сайта после ошибки. Плюс теряется вес внешних ссылок, которые вели на несуществующую страницу.
Нужно ли делать 301-редирект с каждой удалённой страницы?
Нет. Редирект имеет смысл только если на странице был трафик или внешние ссылки. Иначе честный 404 или 410 - нормальный и даже более правильный вариант, чем искусственный редирект на слабо связанную страницу или на главную.
Что делать с битыми ссылками, которые с моего сайта ведут на чужие несуществующие страницы?
Их находит тот же краулер - в Screaming Frog смотрю отчёт External Links и фильтрую по статусу. Дальше либо убираю ссылку из текста, либо заменяю на актуальный адрес того же ресурса, либо ставлю ссылку на архивную копию через Web Archive, если материал больше нигде не публикуется.