Настройка устаревших ссылок и поиск битых URL в 2026 году

Устаревшие ссылки и битые URL — это та самая тихая проблема, которая годами сидит в проекте и портит SEO, аналитику и пользовательский опыт. На моей практике я находил сайты, где после нескольких редизайнов и миграций на WordPress или Битрикс накапливалось по 3–7 тысяч старых адресов, а часть из них даже не отдавала 404 корректно, а просто вела в никуда или на главную. И вот это уже плохая идея, честно говоря.

Почему битые URL в 2026 году всё ещё больно бьют по сайту

Сейчас многие думают: ну подумаешь, несколько несуществующих страниц, поисковик сам разберётся. Не разберётся. Если у вас сайт на PHP 8.1, 8.2 или 8.3, база на MySQL 5.7 или 8.0, а сверху ещё кеш, CDN и разные редиректы, то любая ошибка в маршрутизации начинает множиться. Один битый URL в меню, другой в футере, третий в старой XML sitemap — и у поисковых роботов уже каша в индексации.

Я обычно смотрю на эту проблему шире, чем просто на SEO. Битые ссылки ломают путь пользователя. Человек пришёл из поиска, кликнул на старую статью, получил 404, психанул и ушёл. Или хуже: URL с ошибкой отдаёт 200 OK и показывает пустую страницу. Для Яндекса и Google это уже не «ничего страшного», а мусор в индексе. Если параллельно у вас ещё не до конца настроены robots.txt и XML sitemap, то проблема начинает разрастаться очень быстро.

На деле в 2026 году тема стала даже острее, потому что сайты чаще живут в связке CMS + API + headless-фронт + CDN. И URL могут ломаться не только после смены структуры, но и после релиза фронтенда, обновления плагина, изменения slug в CMS, миграции медиа, настройки multilang и даже из-за кривого кэша. Если хотите, это часть технического долга сайта, который потом вылезает в самом неудобном месте.

Какие бывают устаревшие ссылки и битые сценарии

Я делю такие проблемы на несколько типов. И это удобно, потому что лечатся они по-разному. Первый тип — классический 404, когда страница удалена и сервер честно это сообщает. Второй — 301/302-цепочки, когда старый URL ведёт на промежуточный адрес, потом ещё на один, а потом уже на финал. Третий — soft 404, когда страница вроде открывается, но на ней нет содержимого, и поисковик понимает, что это мусор.

Четвёртый сценарий встречается у интернет-магазинов и сайтов с фильтрами: устаревшие URL категорий, фильтрации и пагинации. Например, после смены структуры у вас остались старые ссылки вида /catalog/phones/apple-iphone-13/, а теперь адрес стал /shop/smartfony/apple/iphone-13/. Если это не закрыть 301 редиректом, вы просто теряете накопленный вес. На практике это особенно болезненно после редизайна, о котором я уже писал в статье про редизайн сайта.

Пятый вариант — битые ссылки внутри контента. Их любят оставлять редакторы, когда копируют текст из старых страниц, WordPress-плагины, которые не обновили внутренние ссылки после смены slug, или Bitrix-сайты после переноса разделов. Тут уже нужна не только техническая проверка, но и регулярная гигиена контента. Если у вас есть процесс автоматического обновления контента, его надо сразу связывать с проверкой URL.

Как найти битые URL в 2026 году: ручные и автоматические методы

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

Самый простой путь — краулеры. Я чаще всего использую Screaming Frog SEO Spider, Sitebulb и иногда Netpeak Spider, если надо быстро показать клиенту картину. Для проектов на 10–50 тысяч URL это нормальный рабочий набор. Screaming Frog, например, хорошо ловит 4xx/5xx, цепочки редиректов, каноникалы и внутренние ссылки на несуществующие страницы. Но для больших проектов одной программы мало: надо смотреть логи Nginx и Apache, а ещё отчёты из Google Search Console и Яндекс.Вебмастера.

Если проект на WordPress, я часто ставлю временную связку из плагинов типа Broken Link Checker, но честно говоря, в 2026 году я не советую на него полагаться как на основной инструмент. Он может грузить базу, особенно если у вас MySQL 5.7 и слабый shared-хостинг. На Bitrix я обычно иду через встроенные инструменты, логирование и отдельный скрипт проверки. И да, если у вас уже настроен мониторинг сайта, туда обязательно надо добавить уведомления о росте 404 и 5xx.

Для быстрой проверки я люблю такие инструменты и источники:

• Google Search Console — разделы «Страницы» и отчёты по сканированию;
• Яндекс.Вебмастер — страницы с ошибками и исключённые URL;
• логи Nginx/Apache — самый честный источник;
• Screaming Frog / Sitebulb — для краулинга всего сайта;
• проверка XML sitemap и HTML sitemap;
• внутренний поиск по базе данных, если нужна миграция старых адресов.

У меня был случай на интернет-магазине на Bitrix с примерно 18 тысячами карточек. После переезда на новую структуру остались старые URL с кириллицей в транслите и вложенными разделами. Визуально сайт выглядел нормально, но в логах я увидел около 4200 запросов к старым адресам за месяц. Почти половина из них была из индекса. Проблему нашли через сканирование и парсинг логов, а потом закрыли серией 301 редиректов и обновлением ссылок в базе.

Что искать в отчётах в первую очередь

Я начинаю с 404, 410, 500 и 301-цепочек. 404 — это удалённые или сломанные страницы. 410 — хороший статус, если страница окончательно удалена и не должна возвращаться. 500 — уже не про ссылки, но часто битые URL всплывают на фоне ошибок PHP или неправильной конфигурации. Цепочки редиректов я смотрю отдельно, потому что каждая лишняя переадресация — это потеря времени, особенно если у вас ещё и HTTP/2 или HTTP/3 настроены неидеально.

Ещё важно смотреть на внешние ссылки. Иногда сайт не ломается сам, но на него ссылаются со старых каталогов, форумов, пресс-релизов или партнёрских страниц. Если там популярный URL, его надо сохранить, даже если контент уже другой. В таких случаях я иногда делаю «мягкую» посадочную страницу или редирект на ближайший релевантный раздел, а не просто удаляю адрес.

Настройка 301 редиректов для устаревших URL

Если URL устарел, но у него был трафик, ссылки и история, 301 редирект — это почти всегда правильное решение. Но только если он сделан нормально. Я категорически против массового редиректа всего старого раздела на главную. Это выглядит как «мы что-то сделали», но на деле SEO-ценность утекает, а пользователь получает нерелевантную страницу.

Для nginx я обычно настраиваю редиректы максимально явно. Вот рабочий пример для пары старых URL и для переноса раздела:

server {
    listen 443 ssl http2;
    server_name example.ru www.example.ru;

    # Старые статьи
    rewrite ^/blog/old-article/?$ https://example.ru/blog/new-article/ permanent;
    rewrite ^/catalog/phones/apple-iphone-13/?$ https://example.ru/shop/smartfony/apple/iphone-13/ permanent;

    # Старый раздел
    location = /services/ {
        return 301 https://example.ru/uslugi/;
    }

    # Важно: не делайте редирект на главную без причины
    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }
}

Если у вас Apache, иногда быстрее закрыть вопрос через .htaccess. Но я сразу скажу: на крупном проекте с высокой нагрузкой лучше держать редиректы в конфиге nginx, а не тащить всё в .htaccess. Особенно если сайт на WordPress с кучей плагинов или на Битрикс с нестандартной маршрутизацией. Вот базовый пример:

RewriteEngine On

RewriteRule ^blog/old-article/?$ /blog/new-article/ [R=301,L]
RewriteRule ^catalog/phones/apple-iphone-13/?$ /shop/smartfony/apple/iphone-13/ [R=301,L]
RewriteRule ^services/?$ /uslugi/ [R=301,L]

На практике я всегда проверяю редирект через curl -I и через браузерный devtools. Потому что часто бывает так: в конфиге всё красиво, а плагин SEO или CMS сверху ещё раз переписывает URL и получается 302 вместо 301, или вообще цикл. И вот это уже не мелочь, а прямой путь к потере индексации.

Если проект большой, я советую вести таблицу соответствий старых и новых URL. Это удобно и для разработчика, и для SEO-специалиста, и для контент-менеджера. На одном проекте я делал редиректы по 12 тысячам URL после переезда с WordPress на Битрикс — и без такой таблицы мы бы просто утонули.

Поиск битых URL в базе данных и фиксация в контенте

Ссылки ломаются не только в роутинге, но и прямо в контенте. В WordPress это часто посты, страницы, ACF-поля, виджеты и меню. В Битрикс — элементы инфоблоков, разделы, свойства, SEO-поля и компоненты. И если не проверить базу, можно десять раз настроить редирект, но старый URL всё равно будет торчать в тексте статьи.

Я обычно сначала ищу старые адреса по базе SQL. Ниже пример, который часто помогает найти упоминания домена или конкретного URL в таблицах WordPress. Запрос нужно адаптировать под префикс и под конкретную CMS, но логика такая:

SELECT ID, post_title
FROM wp_posts
WHERE post_content LIKE '%https://old-site.ru/%'
   OR post_content LIKE '%/old-section/%'
LIMIT 100;

Для Битрикс задача сложнее, потому что данные лежат не в одной таблице. Там я обычно иду через поиск по таблицам b_iblock_element, b_iblock_element_property, b_option, а иногда и по пользовательским таблицам. Если проект старый, не удивляйтесь, когда старые ссылки всплывают в шаблонах, в описаниях разделов, в настройках компонентов и даже в кроне. Это не баг, это наследие.

Был случай: у клиента на WordPress после смены домена остались ссылки на старый CDN в контенте и в нескольких ACF-полях. Визуально на сайте всё было нормально, но изображения отдавались с 404, а PageSpeed в мобильной версии проседал до 41 балла. После замены URL в базе и настройки нормального CDN с кэшированием мы подняли оценку до 89–92. И да, это напрямую связано с темой Core Web Vitals, потому что битые медиа — это лишние запросы, ошибки загрузки и плохой пользовательский опыт.

Если нужно массово заменить старые адреса, делайте это аккуратно. Для WordPress я обычно использую WP-CLI или скрипт с бэкапом. Для Битрикс — через административные инструменты или подготовленный PHP-скрипт в тестовой среде. И сначала всегда делаю резервную копию, потому что без неё лезть в массовый search-replace — это, мягко говоря, неумно. Про бэкапы сайта я уже писал отдельно, и здесь принцип тот же.

Как обрабатывать старые URL, которые уже в индексе

Вот здесь начинается самая интересная часть. Если старый URL уже в индексе, просто удалить его — мало. Поисковик не сразу забудет страницу. Иногда он будет держать её в выдаче ещё несколько недель или месяцев. Поэтому задача — не только поставить 301 или 410, но и ускорить переобход.

Я обычно делаю несколько вещей одновременно. Сначала проверяю, есть ли на старый URL внешние и внутренние ссылки. Потом ставлю корректный редирект или статус 410, если страница действительно должна исчезнуть. После этого обновляю sitemap, отправляю её в Search Console и Вебмастер, а также проверяю, не осталось ли URL в хлебных крошках, меню и блоках похожих материалов. Тут уместно вспомнить про хлебные крошки и про страницы 404 и 500: они должны работать вместе с редиректами, а не отдельно.

Если страница удалена навсегда и у неё нет равноценной замены, я нередко использую 410 Gone. Это честнее, чем 404, и поисковик быстрее понимает, что URL можно выкидывать из индекса. Но тут надо быть уверенным. На товары, статьи, услуги и посадочные я 410 ставлю редко. Для коммерческого проекта это обычно не лучший вариант. А вот для устаревших техстраниц, старых архивов, служебных URL и мусорных тестовых адресов — вполне.

Инструменты, которые я использую на практике

Если говорить без маркетинговой шелухи, то мой базовый набор в 2026 году выглядит так: Screaming Frog, логи Nginx, Search Console, Яндекс.Вебмастер, phpMyAdmin или Adminer для быстрых выборок, а для больших проектов ещё и какой-нибудь парсер логов. Иногда подключаю Elasticsearch, если на сайте уже построен нормальный поиск и есть централизованные логи. Кстати, если тема вам близка, посмотрите статью про Elasticsearch для сайта.

Для WordPress я периодически использую плагины, но только как вспомогательный слой. Например, Better Search Replace для массовой замены старых доменов после миграции. Для Bitrix я часто делаю отдельные административные утилиты или пишу разовый PHP-скрипт под проект. На Laravel всё ещё приятнее, потому что там можно быстро собрать Artisan-команду, которая пройдёт по базе и отчётливо покажет битые пути.

Если проект большой, я добавляю автоматизацию. Например, cron-задачу, которая раз в сутки сканирует список критических URL и отправляет отчёт в Telegram или почту. Это уже ближе к нормальной эксплуатации сайта, а не к разовому «проверили и забыли». Если интересно, у меня есть отдельная статья про cron jobs и ещё про логи сайта и анализ ошибок — там как раз хорошо видно, как это связывается в одну систему.

И ещё момент. В 2026 году у многих сайтов уже есть CDN, кеши, reverse proxy и разные уровни оптимизации. Это хорошо, но иногда они маскируют проблему. Например, старый URL уже перенаправлен, но CDN держит устаревший ответ. Или наоборот, в кеше лежит 200 OK для страницы, которой давно нет. Поэтому при проверке я всегда делаю три вещи: очищаю кеш, проверяю ответ сервера напрямую и смотрю, что видит краулер без браузерного мусора.

Чёткий процесс работы с битымі URL на проекте

Я обычно выстраиваю процесс так: сначала сбор всех URL, потом группировка по типам, затем решение по каждому кейсу. И только после этого — редиректы, правки в базе, обновление sitemap и повторная проверка. Если всё делать хаотично, можно случайно создать новые ошибки. Например, поставить редирект, который вызывает цепочку из трёх переходов, или обновить ссылки в статье, но забыть про навигацию в шапке.

На практике нормальный порядок выглядит так:

1. Собрать 404/410/5xx из логов за 30–90 дней.
2. Прогнать сайт краулером и выгрузить все битые внутренние ссылки.
3. Проверить Search Console и Яндекс.Вебмастер.
4. Сгруппировать URL по типам: контент, товары, служебные страницы, медиа, фильтры.
5. Назначить для каждого URL редирект, 410 или обновление ссылки.
6. Проверить результат вручную и повторно краулером.

И вот здесь часто всплывает соседняя тема — качество серверной части. Если сайт работает на слабом хостинге или с кривой конфигурацией PHP-FPM, то любые проверки занимают вечность и мешают бизнесу. Я не раз видел, как решение проблемы 404 упиралось в банальное обновление PHP до 8.2, настройку OPcache и нормальный хостинг. Об этом, кстати, есть полезные статьи про обновление PHP и выбор хостинга.

Что делать после настройки, чтобы проблема не вернулась

Самая большая ошибка — один раз починить битые ссылки и считать, что вопрос закрыт навсегда. Не закрыт. Как только редактор меняет slug, разработчик переносит шаблон, SEO-специалист обновляет структуру категорий, а CMS получает обновление, старые URL могут появиться снова. Поэтому нужен регулярный контроль.

Я советую раз в неделю автоматически проверять топовые URL, а раз в месяц делать полный краул. Для интернет-магазинов и контентных сайтов с активной редактурой лучше вообще держать мониторинг 404 и рост ошибок в дашборде. И если вы уже настраивали uptime-мониторинг, туда логично добавить ещё и контроль ошибок URL. Это намного полезнее, чем просто смотреть, «сайт жив или нет».

Хорошая профилактика включает в себя несколько вещей:

• регламент на изменение URL и slug;
• обязательную проверку редиректов после релиза;
• автоматический контроль 404 в логах;
• обновление sitemap после массовых изменений;
• контроль внутренних ссылок в контенте;
• бэкапы перед массовыми правками.

Если сайт на WordPress, я бы ещё добавил проверку плагинов, которые меняют URL, хлебные крошки или структуру категорий. Если сайт на Битрикс, однозначно стоит смотреть обновления модулей и шаблонов. И вообще, если вам нужен системный подход, а не разовая пожарная работа, это уже задача для нормальной поддержки WordPress, поддержки Битрикс или полноценной доработки сайта. Потому что вручную ловить битые URL вечно никто не будет.

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

Если у вас сейчас уже есть старые адреса, не откладывайте их в долгий ящик. Сначала соберите данные, потом разберите по типам, после этого настройте редиректы и обязательно проверьте результат. Иначе через пару месяцев вы снова увидите те же 404, только уже в большем объёме.