Как отловить и исправить 404 после смены структуры URL в WordPress

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

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

Когда проблема уже есть: как понять, что 404 связаны именно со сменой URL

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

• Google Search Console — раздел с ошибками сканирования и страницами, не найденными роботом;
• логи веб-сервера — запросы к старым адресам с кодом ответа 404;
• аналитика и отчёты по внутренним переходам — если на сайте остались старые ссылки в меню, блоках или статьях.

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

Что проверить в первую очередь

• какую структуру имели URL до изменения;
• какие типы контента затронуты: записи, страницы, рубрики, архивы;
• есть ли на сайте внутренние ссылки на старые адреса;
• не менялся ли одновременно и плагин для ЧПУ, и правила в .htaccess или nginx-конфиге;
• не закрыты ли старые адреса ошибочным правилом, которое отдаёт 404 вместо 301.

Пошаговое решение: от диагностики к редиректам

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

Шаг 1. Соберите список старых URL

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

Если у вас есть доступ к серверу и включены логи, можно быстро посмотреть частые 404 через grep и awk. Пример для Apache/Nginx-логов, где в строке есть код ответа и запрошенный путь:

grep ' 404 ' access.log | awk '{print $7}' | sort | uniq -c | sort -nr | head -50

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

Шаг 2. Сопоставьте старую и новую структуру

Если раньше записи были вида /2023/05/post-name/, а стали /post-name/, правило редиректа можно строить по шаблону. Если же URL менялись точечно, например у части материалов были вручную отредактированы слаги, придётся делать таблицу соответствий старый URL → новый URL.

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

Шаг 3. Настройте редиректы

Есть три практических варианта: плагин, серверный редирект и код в теме/плагине. Для большинства редакционных сайтов оптимален плагин для первичной настройки, а затем перенос критичных правил на сервер, если редиректов много.

Если нужен быстрый и понятный контроль, можно использовать плагин Redirection. Он не решает всё сам, но для старта удобен: видно, какие URL срабатывают, куда они ведут и есть ли цепочки редиректов.

Шаг 4. Добавьте точечные правила в код, если шаблон простой

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

add_action( 'template_redirect', function () {
	if ( is_admin() ) {
		return;
	}

	$request_uri = isset( $_SERVER['REQUEST_URI'] ) ? wp_unslash( $_SERVER['REQUEST_URI'] ) : '';

	if ( preg_match( '#^/\d{4}/\d{2}/([^/]+)/?$#', $request_uri, $matches ) ) {
		$new_slug = $matches[1];
		$new_url  = home_url( '/' . $new_slug . '/' );

		wp_redirect( $new_url, 301 );
		exit;
	}
} );

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

Шаг 5. Обновите внутренние ссылки и sitemap

Редиректы закрывают внешний трафик, но внутренние ссылки тоже нужно привести в порядок. Иначе поисковик будет каждый раз ходить по старому адресу, а пользователь — получать лишний переход. Проверьте:

• меню;
• ссылки в контенте;
• хлебные крошки;
• ссылки в блоках «похожие материалы»;
• XML-карту сайта;
• канонические URL, если они формируются вручную или плагином.

Если на сайте много старых ссылок в контенте, удобно сделать поиск по базе. Для WordPress это безопаснее через WP-CLI или через инструмент массовой замены, который умеет корректно работать с сериализованными данными. Простая замена в SQL без понимания структуры данных часто ломает настройки виджетов и блоков.

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

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

Что именно проверить

• старый URL отдаёт 301, а не 200 и не 404;
• новый URL открывается без дополнительной цепочки редиректов;
• внутренние ссылки уже ведут на новый адрес;
• в Search Console постепенно уменьшается число ошибок по старым страницам;
• в логах больше не растёт количество 404 по тем же шаблонам.

Проверить код ответа можно через curl:

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

В ответе должен быть статус 301 Moved Permanently и заголовок Location с новым адресом. Если вы видите цепочку из нескольких переходов, её стоит сократить. Один редирект лучше, чем три подряд.

Если нужно проверить массово, удобно прогнать список URL через простой скрипт. Например, в bash:

while read url; do
  echo "== $url =="
  curl -I -s "$url" | grep -E 'HTTP/|Location:'
  echo
 done < urls.txt

Так вы быстро увидите, где редирект не сработал или ведёт не туда.

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

Ставят 302 вместо 301

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

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

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

Создают цепочки редиректов

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

Забывают про внутренние ссылки

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

Ломают правила в .htaccess

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

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

Чем больше редиректов, тем важнее не превращать их в хаотичный набор правил внутри WordPress. Для небольшого проекта это может быть терпимо, но на сайте с большим архивом лучше держать логику ближе к серверу или хотя бы в отдельном мини-плагине, а не в functions.php активной темы.

Полезный минимум:

• не хранить редиректы в теме, если тема может меняться;
• не использовать слишком общие регулярные выражения, которые ловят лишние URL;
• не ставить несколько плагинов редиректов одновременно;
• после миграции периодически смотреть логи 404, а не считать задачу закрытой навсегда;
• если редиректов очень много, выносить массовые правила на уровень nginx или Apache.

Если вам нужно не только закрыть 404, но и почистить сайт от лишних дублей, технических хвостов и мусорных URL, имеет смысл смотреть в сторону инструментов, которые помогают с SEO-обслуживанием WordPress. Например, Clearfy Pro уместен как вспомогательный набор для чистки и технической оптимизации: https://wpshop.ru/plugins/clearfy.

Короткий чек-лист перед публикацией изменений

• собран список старых URL из Search Console и логов;
• для массовых шаблонов есть правило 301;
• точечные страницы сопоставлены вручную;
• внутренние ссылки обновлены;
• sitemap пересобран;
• проверка curl -I показывает нужный код ответа;
• в логах не растёт число 404 по старым адресам.

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