Как отловить и убрать бессмысленные 404 в WordPress через Redirection и .htaccess

Если в отчётах постоянно всплывают 404 на странные URL, это обычно не «проблема поисковика», а следствие старых ссылок, мусорных ботов, смены структуры постоянных ссылок или неаккуратных правок в теме и плагинах. Игнорировать такие запросы не стоит: они засоряют логи, мешают анализу, иногда создают лишнюю нагрузку и могут маскировать реальные ошибки после миграции.

Ниже — рабочий сценарий: как сначала понять источник 404, затем убрать их через плагин или серверные правила, а после проверить, что ничего полезного не сломалось.

Когда 404 — это не просто «битая ссылка»

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

Если у вас много 404 на адреса вроде /wp-content/uploads/..., /tag/..., /page/9999/ или на давно удалённые записи, это уже сигнал проверить структуру сайта. Если же в логах идут запросы к /phpmyadmin, /wp-login.php с подозрительными параметрами или к случайным файлам, это чаще мусорный трафик, и перенаправлять его не нужно.

Диагностика: откуда берутся ошибки

Начните с источника, а не с редиректов. Иначе легко создать цепочки перенаправлений и замаскировать проблему.

• Проверьте Google Search Console или аналогичный отчёт по сканированию.
• Посмотрите логи веб-сервера: какие URL запрашиваются чаще всего.
• Проверьте внутренние ссылки на сайте, особенно в меню, хлебных крошках, блоках похожих материалов и в шаблонах.
• Сравните старую и новую структуру постоянных ссылок, если недавно меняли /category/, /postname/ или префиксы таксономий.

Если 404 появляются после обновления темы или плагина, ищите не только ссылки в контенте, но и динамические URL, которые формируются через PHP-функции или настройки виджетов.

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

Не все 404 нужно перенаправлять. Для SEO и для поддержки сайта полезнее выбрать правильный вариант по ситуации.

Пошаговое решение через плагин Redirection

Для большинства сайтов удобнее всего начать с плагина Redirection. Он позволяет быстро завести 301/302-правила, видеть статистику срабатываний и не лезть сразу в конфиг сервера.

Шаг 1. Найдите конкретный старый URL

Не создавайте редирект «на всякий случай» для всех 404 подряд. Возьмите только тот адрес, который реально должен вести на новую страницу. Если таких адресов много, сначала соберите список из логов или Search Console.

Шаг 2. Создайте правило 301

В интерфейсе Redirection укажите источник и целевой URL. Для постоянного переноса используйте именно 301, а не 302. Временный редирект нужен редко, например при тестировании новой структуры.

/staryy-url/  →  /novyy-url/

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

Шаг 3. Проверьте, нет ли цепочки

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

Когда лучше править сервер: пример для .htaccess

Если 404 много, а правила простые, часть перенаправлений удобнее вынести в .htaccess. Это особенно полезно на Apache, когда нужно быстро обработать старые адреса без нагрузки на WordPress.

Перед правкой сделайте резервную копию файла. Ошибка в синтаксисе .htaccess может положить сайт целиком.

Redirect 301 /old-page/ https://example.com/new-page/

Для более аккуратных правил можно использовать mod_rewrite:

RewriteEngine On
RewriteRule ^old-section/old-page/?$ /new-section/new-page/ [R=301,L]

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

Когда .htaccess лучше, чем плагин

• Нужно обработать много старых URL до загрузки WordPress.
• Сайт на Apache и правила простые.
• Вы хотите снизить зависимость от плагинов в админке.

Как убрать источник 404, а не только симптом

Редирект — это не лечение, если проблема внутри сайта. Проверьте, откуда именно идёт неверная ссылка.

• В меню и подменю.
• В шаблонах темы, где URL прописан вручную.
• В блоках Gutenberg с кнопками и ссылками.
• В виджетах, если они ещё используются.
• В плагинах, которые генерируют собственные страницы и архивы.

Если ссылка сидит в контенте, исправьте её в записи или через массовую замену в базе, но только после бэкапа. Если URL формируется кодом, ищите home_url(), site_url(), get_permalink(), get_term_link() и аналогичные функции — часто ошибка кроется в неправильном аргументе или ручной конкатенации строк.

<?php
// Плохой вариант: хардкод пути
$link = 'https://example.com/old-page/';

// Лучше: строить ссылку через WordPress
$link = home_url('/new-page/');

Проверка результата после внедрения

После настройки не ограничивайтесь открытием URL в браузере. Проверьте редирект технически и убедитесь, что он отдаёт правильный код ответа.

1. Откройте старый URL в браузере и убедитесь, что адрес меняется на целевой.
2. Проверьте заголовки ответа через curl или DevTools.
3. Убедитесь, что на целевой странице код ответа 200, а не ещё один редирект.
4. Посмотрите, не появились ли новые 404 на похожих адресах.

curl -I https://example.com/old-page/

В ответе должен быть 301 Moved Permanently и заголовок Location с новым URL. Если видите 302, а нужен постоянный перенос, правило настроено неправильно. Если вместо редиректа возвращается 200, значит запрос обрабатывается не тем правилом или его перехватывает другая логика.

Частые ошибки и как их исправить

Редирект ведёт на нерелевантную страницу

Так часто делают, когда «лишь бы не 404». Но поисковику и пользователю нужен логичный переход. Если старый материал был про конкретную тему, отправляйте на ближайший по смыслу аналог, а не на главную.

Создана цепочка из нескольких перенаправлений

Это происходит, когда старый URL сначала ведёт на промежуточный адрес, а потом ещё раз меняется структура. Сведите всё к одному конечному URL и удалите лишние правила.

Слишком широкое правило захватывает лишние страницы

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

Исправили редирект, но 404 остались

Значит, источник ошибки не в старом URL, а в новой ссылке, которая всё ещё указывает на несуществующий адрес. Проверьте контент, меню, шаблоны и кеш.

Безопасность и производительность: что не стоит делать

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

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

Мини-чек-лист перед публикацией правок

• Старый URL действительно больше не нужен как самостоятельная страница.
• Целевой адрес отвечает 200.
• Редирект один, без цепочки.
• Внутренние ссылки уже исправлены.
• Кеш очищен на стороне сайта и, если есть, на стороне CDN.
• Проверка в Search Console или логах показывает, что старый URL больше не всплывает как активная ошибка.

Если после всех правок 404 не исчезают, не расширяйте правило вслепую. Сначала найдите источник запроса. В WordPress это почти всегда быстрее и надёжнее, чем пытаться «поймать всё» одним универсальным редиректом.