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

Автор: Руслан Петров | Опубликовано: 15.09.2026

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

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

Когда проблема уже видна в логах и Search Console

Симптомы обычно одинаковые: в отчёте об ошибках сканирования растёт число Not Found, в логах сервера появляются запросы к старым путям, а пользователи жалуются на пустые страницы после перехода из закладок. После смены структуры ссылок это нормально только в первые часы или дни, пока вы не собрали карту редиректов.

Проверять стоит не только главную ошибку, но и источник запроса. Один и тот же 404 может приходить из разных мест: старый адрес записи, вложение из медиатеки, архив рубрики, URL с лишним слэшем или с изменённым slug. Для каждого случая решение будет разным.

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

отчёт Pages или Страницы в Google Search Console;
логи веб-сервера за последние дни после миграции или смены permalink;
список внутренних ссылок в меню, виджетах и контенте;
старые sitemap-файлы, если они кэшируются отдельно;
страницы вложений и архивы медиафайлов, если они индексировались.

Как быстро понять, какие URL реально сломались

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

Пример простого поиска по access log на сервере Linux:

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

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

Диагностика по типам ошибок

Сценарий	Что обычно ломается	Что делать
Смена структуры записей	`/2024/05/post-name/` стало `/post-name/`	Ставить 301 с шаблона старой структуры на новую
Изменение slug у конкретной страницы	Один адрес перестал существовать	Точечный редирект на новый URL
Удалённые вложения	Файлы из медиатеки больше не открываются	Либо редирект на файл, либо на родительскую запись
Сломанные внутренние ссылки	Меню, блоки, старые материалы ведут на 404	Исправить ссылку в контенте, а не только редиректить

Пошаговое решение: сначала массовые редиректы, потом точечные правки

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

1. Сохраните старую структуру как карту соответствий

Перед любыми правками выгрузите список старых и новых URL. Если есть доступ к базе, можно взять записи и страницы через стандартный WordPress API, но для разовой задачи проще собрать CSV из старого sitemap, бэкапа или логов. Главное — не работать «по памяти».

2. Добавьте 301-редирект для старого шаблона URL

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

# Apache .htaccess пример для старой структуры /YYYY/MM/post-name/ -> /post-name/
RewriteEngine On
RewriteRule ^[0-9]{4}/[0-9]{2}/([^/]+)/?$ /$1/ [R=301,L]

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

3. Закройте точечные 404 через редиректы в WordPress

Для отдельных URL удобнее использовать плагин редиректов или небольшой код в теме/му-плагине. Если задача разовая и редиректов немного, код в functions.php допустим, но лучше вынести его в мини-плагин или mu-plugin, чтобы не потерять при смене темы.

<?php
add_action('template_redirect', function () {
    $request_uri = $_SERVER['REQUEST_URI'] ?? '';

    if ($request_uri === '/staryy-razdel/') {
        wp_redirect(home_url('/novyy-razdel/'), 301);
        exit;
    }

    if (preg_match('#^/old-category/([^/]+)/?$#', $request_uri, $matches)) {
        wp_redirect(home_url('/category/' . $matches[1] . '/'), 301);
        exit;
    }
});

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

4. Исправьте внутренние ссылки в контенте

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

Проверьте:

ссылки в старых записях и страницах;
меню и подменю;
виджеты и блоки в редакторе;
ссылки в шаблонах темы;
автоматические блоки «похожие материалы» и хлебные крошки.

Как проверить, что решение сработало

Проверка должна быть не визуальной, а технической. Откройте старый URL и убедитесь, что сервер отдаёт именно 301, а не 302 или цепочку из нескольких переходов. Затем проверьте конечный адрес: он должен открываться без редиректа и без ошибки.

Быстрый способ через curl:

curl -I https://example.com/2024/05/post-name/

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

После этого проверьте ещё три вещи:

старый URL не возвращает цепочку из двух и более редиректов;
новый URL не закрыт случайным noindex или canonical на старый адрес;
в Search Console новые страницы попадают в индекс, а старые постепенно уходят в Page with redirect или исчезают из ошибок.

Частые ошибки и почему они появляются

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

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

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

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

Не учитывают вложенные и служебные URL

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

Делают редирект в теме, а потом меняют тему

Если логика редиректов лежит в functions.php, смена темы может вернуть старые 404. Для постоянных правил лучше использовать mu-plugin или серверную конфигурацию, а не оформление сайта.

Что делать, если 404 идут из старого контента, а не из структуры ссылок

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

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

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

не ставьте редиректы через цепочку из нескольких плагинов — это создаёт лишнюю задержку;
не храните десятки правил в functions.php, если можно вынести их в отдельный mu-plugin;
после массовых правок очистите серверный и объектный кэш, иначе вы будете проверять старые ответы;
если используете плагин редиректов, ограничьте доступ к его настройкам только администраторам;
не закрывайте проблему через 404.php с автопереадресацией на главную — это ухудшает диагностику и мешает поиску реальных ошибок.

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

Если после внедрения правил 404 всё ещё остаются, не ищите одну «волшебную» настройку. Обычно проблема в сочетании факторов: старые ссылки в контенте, неверный шаблон редиректа и кэш, который не обновился после изменений. В таком случае быстрее всего работает связка: лог ошибок, точечные редиректы, правка внутренних ссылок и повторная проверка через curl и Search Console.