Битые ссылки в WordPress обычно всплывают не в одном месте, а сразу в нескольких: в старых записях, в меню, в виджетах, в блоках редактора и в ссылках на изображения после переезда сайта. Если просто поставить плагин-проверялку и забыть о проблеме, можно получить лишнюю нагрузку на хостинг и кучу ложных срабатываний. Поэтому лучше сначала понять, где именно ломается ссылка, а потом уже выбирать способ исправления.
Как понять, что проблема именно в битых ссылках
Типичный сценарий выглядит так: пользователь кликает по ссылке и попадает на 404 Not Found, а в Search Console растёт число страниц с ошибкой. Иногда проблема заметна только в админке — редактор показывает старый URL в тексте или в кнопке, хотя файл уже переехал. Ещё один частый случай — медиафайлы остались в контенте по старому пути после миграции домена или переноса на CDN.
Где искать в первую очередь
- контент записей и страниц, особенно старые статьи;
- меню и подменю в разделе «Внешний вид → Меню»;
- ссылки в блоках Gutenberg, кнопках и обложках;
- ссылки на файлы в медиатеке;
- ссылки в шаблонах темы и в кастомных полях;
- редиректы, которые уже не нужны или ведут в цепочку.
Если сайт небольшой, часть проблем можно найти вручную. Но на живом проекте с десятками или сотнями страниц лучше использовать комбинацию: проверка в админке, сканирование сайта и точечный поиск по базе.
Диагностика: как быстро найти проблемные URL
Начните с внешней проверки. Самый простой вариант — открыть несколько важных разделов сайта и посмотреть, не ведут ли ссылки на 404. Для системной проверки удобнее использовать инструменты, которые собирают список URL и показывают статус ответа. Если у вас есть доступ к серверу, можно дополнительно прогнать выборку через консоль.
Проверка через WP-CLI и базу данных
Если на сайте установлен WP-CLI, сначала найдите старые домены, протоколы или явные хвосты URL в контенте. Это не заменяет полноценный аудит, но помогает быстро сузить круг поиска.
wp search-replace 'old-site.ru' 'new-site.ru' --dry-run --all-tablesКоманда выше не вносит изменения, а только показывает, где строка встречается в базе. Если нужно проверить конкретный путь, ищите не только домен, но и часть URL, например /wp-content/uploads/2022/ или старый slug записи.
Для точечной проверки ссылок в контенте можно выгрузить записи и пройтись по ним вручную, но без автоматизации это быстро становится неудобно. На практике лучше сначала собрать список подозрительных URL, а потом уже править их в редакторе или через поиск и замену.
Когда нужен плагин проверки ссылок
Плагин уместен, если нужно один раз разобрать накопившийся мусор. Но держать постоянный фоновый сканер на слабом хостинге — плохая идея: такие плагины могут регулярно обходить весь сайт и создавать лишнюю нагрузку. Если используете подобный инструмент, включайте его только на время аудита и отключайте после чистки.
| Подход | Когда подходит | Минус |
|---|---|---|
| Ручная проверка | Небольшой сайт, 10–20 важных страниц | Не видит скрытые ссылки в базе |
| WP-CLI / поиск по базе | Миграция, массовая замена URL | Нужен доступ к серверу |
| Плагин-сканер | Разовая чистка большого архива | Может грузить сайт при постоянной работе |
Пошаговое решение: как убрать битые ссылки без поломки контента
Логика простая: сначала исправляем ссылки, которые должны вести на существующий адрес, затем решаем, что делать со старыми URL, которые уже нельзя восстановить. Не стоит сразу удалять всё подряд — иногда правильнее поставить редирект, чем менять ссылку в тексте.
Шаг 1. Исправьте ссылки, которые можно заменить напрямую
Если страница или файл просто переехали, обновите URL в редакторе. Для блоков Gutenberg это обычно делается прямо в интерфейсе. Для классического редактора и произвольных полей иногда проще использовать поиск и замену по базе, но только после резервной копии.
Для массовой замены старого пути на новый можно использовать WP-CLI:
wp search-replace 'https://example.com/old-path/' 'https://example.com/new-path/' --all-tables --preciseПараметр --precise полезен, когда в базе много сериализованных данных и нельзя полагаться на грубую замену.
Шаг 2. Настройте редирект для удалённых страниц
Если контент удалён осознанно, а на него уже есть внешние ссылки или трафик из поиска, лучше настроить 301-редирект на ближайшую релевантную страницу. Для этого не обязательно писать свой код, если у вас уже есть надёжный плагин редиректов. Но если задача точечная и нужна одна-две переадресации, можно добавить правило в .htaccess или конфиг nginx.
Redirect 301 /old-page/ https://example.com/new-page/Этот вариант подходит для Apache. На nginx правило будет другим, и его лучше добавлять в конфигурацию сервера, а не в WordPress.
Шаг 3. Уберите ссылки из меню и шаблонов
Если битая ссылка сидит в меню, виджете или шаблоне темы, исправление в записи не поможет. Проверьте:
- меню в админке;
- настройки блоков в редакторе сайта;
- файлы темы, если ссылка вставлена вручную;
- кастомные поля, которые выводятся через шаблон.
Для темы или плагина лучше править код в дочерней теме или в собственном плагине, а не в исходниках обновляемого продукта.
Шаг 4. Закройте цепочки редиректов
Иногда ссылка не битая формально, но ведёт через два-три перехода. Это лишняя задержка и риск ошибки. Проверяйте, чтобы старый URL сразу отдавал конечный адрес, без промежуточных шагов. Если редиректов накопилось много, их стоит пересмотреть и удалить устаревшие правила.
Проверка результата после внедрения
После правок не ограничивайтесь визуальной проверкой в браузере. Нужно убедиться, что старые URL действительно отдают нужный код ответа, а в контенте не осталось старых адресов.
Что проверить вручную
- открывается ли страница по новому адресу;
- старый URL отдаёт
301, если нужен редирект; - не осталось ли ссылок на 404 в меню и кнопках;
- не сломались ли изображения и вложения;
- нет ли цепочки из нескольких редиректов.
Если есть доступ к терминалу, можно проверить ответ сервера через curl:
curl -I https://example.com/old-page/В ответе смотрите на статус и заголовок Location. Для старого URL с редиректом ожидается 301 и конечный адрес в Location. Если видите 404, правило не сработало или URL указан неверно.
Что проверить в Search Console
После исправления не ждите мгновенного обновления отчётов. Поисковик переобходит страницы не сразу. Но если проблема решена, со временем число ошибок по старым URL должно снижаться, а новые 404 не должны появляться в тех же местах. Если ошибка остаётся, значит где-то ещё висит ссылка на старый адрес.
Частые ошибки и как их исправить
Самая частая ошибка — удалять страницу и не ставить редирект. В результате старый URL получает 404, а внешние ссылки и закладки пользователей ломаются. Если страница была полезной и имела трафик, редирект почти всегда лучше, чем пустая ошибка.
Вторая ошибка — массовая замена URL без резервной копии. Это особенно опасно при работе с сериализованными данными, настройками плагинов и блоками. Перед search-replace обязательно делайте бэкап базы.
Третья ошибка — использовать постоянный плагин для проверки ссылок на слабом хостинге. Если сайт начал тормозить после установки такого инструмента, отключите фоновое сканирование и делайте аудит вручную или по расписанию.
Четвёртая ошибка — править ссылки прямо в файлах ядра или обновляемой темы. После обновления изменения пропадут. Для таких правок используйте дочернюю тему, собственный плагин или настройки сервера.
Чек-лист перед публикацией изменений
- сделан бэкап базы и файлов;
- старые URL найдены в контенте, меню и шаблонах;
- для удалённых страниц настроен 301-редирект;
- ссылки на медиафайлы проверены после миграции;
- цепочки редиректов сокращены до одного шага;
- новые и старые адреса проверены через браузер или
curl; - в Search Console добавлены страницы на переобход, если это уместно.
Что делать, если битые ссылки появляются снова
Если проблема возвращается после каждого обновления или импорта контента, ищите источник, а не только симптомы. Часто виноваты:
- импорт из старого сайта с сохранением устаревших URL;
- шаблон темы, который выводит жёстко прописанные ссылки;
- плагин, который подставляет неправильный путь к медиа;
- редактор, где часть контента хранится в кастомных полях и не попадает в обычный поиск.
В таких случаях полезно один раз пройтись по базе и шаблонам, а затем зафиксировать правило: новые ссылки добавляются только через текущий домен и актуальные пути. Если на сайте много технического мусора, иногда проще сначала провести общую чистку и убрать лишние дубли, чем бесконечно латать отдельные 404. Для этого можно использовать инструменты вроде Clearfy Pro, если нужен именно набор для технической чистки и SEO-обслуживания, а не разовая ручная правка.
Главный критерий успеха здесь простой: старые адреса либо корректно редиректятся, либо исчезают из внутренних ссылок, а новые 404 не появляются в тех местах, где вы уже всё исправили.