Если после смены URL у страниц в WordPress в отчётах появляются 404, проблема обычно не в одной «битой» ссылке, а в цепочке: старый адрес остался в меню, в контенте, в sitemap, в кэше или в индексе поисковика. Лечить нужно не только редиректом, но и источником старого URL.
Что именно ломается после смены адреса
Типичный сценарий выглядит так: вы переименовали страницу, изменили слаг, перенесли раздел или поменяли структуру постоянных ссылок. Старый адрес продолжает жить в нескольких местах одновременно. Пользователь видит 404, а поисковый робот — сигнал, что страница исчезла без замены.
Проверять нужно не только саму страницу, но и все места, где WordPress мог сохранить старый URL:
- внутренние ссылки в записях и страницах;
- меню и виджеты;
- хлебные крошки и блоки темы;
- sitemap и RSS;
- кэш страницы и объектный кэш;
- внешние ссылки с других сайтов.
Как быстро диагностировать источник 404
Сначала откройте проблемный URL в браузере и посмотрите, это действительно 404 WordPress или редирект, который ведёт не туда. Затем проверьте логи сервера или отчёт в Google Search Console, если он уже накопился. Если 404 возникает только у старого адреса, а новый открывается нормально, задача сводится к корректному редиректу и очистке внутренних ссылок.
Полезно отдельно проверить, не остался ли старый URL в базе данных. Для этого ищут точное вхождение слага в контенте и настройках темы. Если у вас есть доступ к WP-CLI, можно быстро найти старые адреса через поиск по базе, но даже без него достаточно пройтись по меню и связанным блокам.
Пошаговое решение: от редиректа до чистки ссылок
Если адрес страницы изменился намеренно, правильный путь — отдать 301 редирект со старого URL на новый. Это сохраняет переходы пользователей и помогает поисковым системам понять, куда переехал контент.
1. Добавьте 301-редирект на уровне WordPress
Для единичного случая можно использовать код в functions.php дочерней темы или в небольшом служебном плагине. Ниже пример для конкретного старого и нового адреса:
add_action('template_redirect', function () {
if (is_admin()) {
return;
}
$request_uri = isset($_SERVER['REQUEST_URI']) ? wp_unslash($_SERVER['REQUEST_URI']) : '';
if ($request_uri === '/staryj-url/' || $request_uri === '/staryj-url') {
wp_redirect(home_url('/novyj-url/'), 301);
exit;
}
});Если нужно перенаправить несколько старых адресов, лучше хранить их в массиве и не плодить отдельные блоки кода. Для сложных миграций удобнее делать редиректы на уровне сервера или через специализированный плагин, чтобы не зависеть от темы.
2. Обновите внутренние ссылки
Редирект решает проблему для внешнего трафика, но внутри сайта старый URL всё равно будет создавать лишние переходы и цепочки редиректов. Проверьте:
- ссылки в тексте записей;
- меню в разделе «Внешний вид»;
- блоки «Похожие записи», «Читайте также» и кастомные блоки темы;
- URL в кнопках и баннерах;
- ссылки в шаблонах, если адрес прописан вручную.
Если старый адрес встречается массово, можно заменить его через поиск и замену в базе данных. Делать это нужно аккуратно: сначала бэкап, потом тест на staging-копии. Не заменяйте домен или путь «вслепую», если на сайте есть сериализованные данные.
3. Проверьте sitemap и канонические URL
После смены адреса страница должна попадать в sitemap уже с новым URL. Если sitemap генерируется плагином SEO, очистите его кэш и убедитесь, что старый адрес не остался в списке. Также проверьте тег rel="canonical" на самой странице: он должен указывать на новый адрес, а не на старый.
Если canonical указывает на несуществующий URL, поисковик может продолжать считать старый адрес основным, даже если редирект уже настроен.
Сравнение подходов: плагин, код или сервер
| Подход | Когда подходит | Плюс | Минус |
|---|---|---|---|
| Плагин редиректов | Нужно быстро закрыть несколько старых URL | Удобно управлять без правки кода | Дополнительная нагрузка и зависимость от плагина |
| Код в теме/плагине | Один-два стабильных редиректа | Прозрачно и без лишних интерфейсов | Нужно следить за обновлениями и тестировать |
| Редирект на сервере | Миграция большого числа URL | Быстрее и надёжнее для массовых правил | Нужен доступ к конфигурации сервера |
Проверка результата после внедрения
После настройки не ограничивайтесь открытием страницы в браузере. Проверьте цепочку полностью:
- Откройте старый URL в приватном окне.
- Убедитесь, что ответ —
301 Moved Permanently, а не302и не редирект через несколько промежуточных шагов. - Проверьте, что конечный адрес открывается с кодом
200. - Посмотрите исходный код страницы и убедитесь, что canonical указывает на новый URL.
- Проверьте sitemap: старый адрес должен исчезнуть после обновления кэша.
Если есть доступ к консоли, можно быстро проверить заголовки ответа:
curl -I https://example.com/staryj-url/В ответе должен быть один редирект на новый адрес. Если видите цепочку из нескольких Location или повторный переход на тот же URL, редирект настроен неправильно.
Частые ошибки и как их исправить
Редирект ведёт на главную
Такое часто происходит, если правило написано слишком общо или старый URL не совпадает с реальным путём запроса. Проверьте слэш в конце, регистр букв и наличие подкаталогов. Для WordPress важно сравнивать именно путь, а не только слаг.
Страница всё ещё отдаёт 404 после редиректа
Иногда редирект срабатывает, но кэш отдаёт старую версию ответа. Очистите кэш плагина, серверный кэш и CDN, если он используется. После этого повторите проверку в приватном окне и через curl -I.
Старый URL продолжает индексироваться
Это нормально в течение некоторого времени, если поисковик ещё не переобходил сайт. Но если в sitemap по-прежнему есть старый адрес или canonical указывает на него, индексация затянется. Уберите источник старого URL и отправьте обновлённую карту сайта в Search Console.
Редирект сделан через 302
Временный редирект не передаёт сигнал о постоянном переезде страницы так, как нужен в этом сценарии. Для смены URL используйте 301, если адрес действительно заменён навсегда.
Чек-лист перед публикацией изменений
- Старый URL отвечает 301, новый — 200.
- Внутренние ссылки обновлены в контенте и меню.
- Canonical указывает на новый адрес.
- Sitemap не содержит старый URL.
- Кэш сайта и CDN очищены.
- Проверка в приватном окне показывает корректный переход.
Что делать, если URL меняется регулярно
Если на сайте часто переименовывают страницы, лучше не полагаться на ручные правки в контенте. В таком случае полезно вести таблицу старых и новых адресов и сразу добавлять редиректы после изменения слага. Это снижает риск накопления 404 и упрощает поддержку.
Для сайтов с большим количеством технических правок имеет смысл держать отдельный список редиректов в служебном плагине или на сервере, а не в теме. Тогда смена дизайна не сломает логику перенаправлений.