Если после правки slug у записей, страниц или рубрик часть URL начала отдавать 404, проблема обычно не в «битом WordPress», а в несоответствии между старым адресом, кешем, правилами перезаписи и внутренними ссылками. На живом сайте это быстро превращается в цепочку ошибок: старые ссылки из меню, карты сайта, RSS, внешние упоминания и закешированные страницы продолжают вести на уже несуществующий адрес.
Ниже — рабочий сценарий: как диагностировать источник 404, что исправить в первую очередь и как проверить, что редиректы и индексация действительно в порядке.
Когда 404 появляется именно после смены slug
Типичный сценарий выглядит так: вы меняете post_name у записи, сохраняете материал, а старый URL перестает открываться. Иногда это ожидаемо. Но если 404 ловят и новый адрес, и архивы, и соседние страницы, значит затронуты правила перезаписи, кеш или конфликт плагина.
Что проверить сразу
- открывается ли новый URL в режиме инкогнито;
- есть ли 301-редирект со старого адреса на новый;
- не закеширован ли старый HTML на стороне плагина, CDN или сервера;
- не изменился ли slug у таксономии, если проблема касается рубрик или меток;
- не переписывает ли адрес плагин для SEO, мультиязычности или редиректов.
Диагностика проблемы без догадок
Начните с самого простого: сравните фактический ответ сервера для старого и нового URL. Это быстрее, чем перебирать настройки наугад.
curl -I https://example.com/staryy-slug/
curl -I https://example.com/novyy-slug/В ответе важно увидеть не только код 200 или 404, но и цепочку Location, если редирект есть. Если старый адрес сразу отдает 404, а новый — 200, значит редирект не настроен. Если оба адреса отдают 404, проблема глубже: правила ЧПУ, кеш или конфликт с плагином.
В админке откройте Настройки → Постоянные ссылки и просто нажмите «Сохранить изменения» без правок. Это безопасный способ пересобрать правила перезаписи. Если после этого новый URL начал открываться, а старый все еще 404 — значит, WordPress сам по себе работает, но старые адреса нужно отдельно перенаправить.
Пошаговое решение: от редиректа до очистки кеша
1. Сохраните старый slug до публикации
Если вы меняете адрес уже опубликованной записи, сначала зафиксируйте старый URL. Для небольшого сайта это можно сделать вручную в таблице или в заметке редактора. Для проекта с регулярными правками лучше сразу ставить редирект на уровне кода или плагина.
2. Настройте 301 со старого адреса на новый
Самый надежный вариант — редирект 301. Он сообщает поисковым системам и браузерам, что адрес изменился постоянно. Для единичного случая можно использовать плагин редиректов, но если правки slug происходят часто, удобнее добавить правило в тему или mu-plugin.
<?php
add_action('template_redirect', function () {
if (is_admin()) {
return;
}
$request_uri = $_SERVER['REQUEST_URI'] ?? '';
if ($request_uri === '/staryy-slug/' || $request_uri === '/staryy-slug') {
wp_redirect(home_url('/novyy-slug/'), 301);
exit;
}
});Это рабочий пример для одного конкретного адреса. Если таких страниц много, лучше хранить карту соответствий отдельно и не раздувать functions.php.
3. Обновите внутренние ссылки
После смены slug старые ссылки могут остаться в контенте, меню, блоках и виджетах. Если их не заменить, пользователь будет попадать на редирект, а иногда — на цепочку редиректов. Для массовой замены используйте поиск и замену по базе, но только после бэкапа.
Если нужен точечный вариант через SQL, сначала проверьте, где именно хранится старый адрес:
SELECT ID, post_title, post_content
FROM wp_posts
WHERE post_content LIKE '%/staryy-slug/%';После этого замену делайте аккуратно, с учетом сериализованных данных. Для контента в wp_posts это обычно безопаснее, чем для опций и мета.
4. Сбросьте кеш
Если на сайте есть кеширующий плагин, серверный кеш или CDN, старый HTML может продолжать отдавать 404 даже после исправления. Очистите:
- кеш страницы в плагине;
- object cache, если он используется;
- кеш на стороне Nginx/Apache;
- CDN-кеш, если сайт за ним стоит;
- кеш браузера для проверки вручную.
5. Проверьте sitemap и canonical
Если slug изменился, карта сайта и canonical должны указывать на новый URL. Иначе поисковик увидит старый адрес в sitemap, а на странице — новый canonical, и начнется лишняя переобходка. Это особенно заметно после массовых правок рубрик или записей.
Если 404 появляется не только на старом адресе
Когда новый slug тоже не открывается, обычно виноваты правила перезаписи или конфликт с плагином. Проверьте, не меняет ли адрес плагин для SEO, мультиязычности или кастомных типов записей. Часто проблема возникает после изменения структуры постоянных ссылок, а не самого slug.
Полезный тест — временно переключиться на стандартную тему и отключить плагины, которые вмешиваются в URL. Если проблема исчезла, включайте их по одному и смотрите, на каком шаге ломается маршрут.
| Подход | Когда подходит | Минус |
|---|---|---|
| Плагин редиректов | Нужно быстро закрыть несколько старых URL | Дополнительная зависимость и лишняя точка отказа |
| Код в теме или mu-plugin | Редиректы нужны постоянно и под контролем разработчика | Нужно следить за обновлениями и структурой проекта |
| Ручная правка ссылок без редиректа | Только для черновиков или непубличных материалов | Ломает старые внешние ссылки и историю индексации |
Проверка результата после внедрения
После исправлений не ограничивайтесь открытием страницы в браузере. Проверьте три вещи: код ответа, редирект и фактический URL в контенте.
- старый адрес должен отдавать
301на новый; - новый адрес должен отдавать
200; - в исходном коде страницы canonical должен указывать на новый URL;
- в sitemap должен быть только актуальный адрес;
- внутренние ссылки в контенте не должны вести на старый slug.
Быстрая проверка через curl:
curl -I https://example.com/staryy-slug/
curl -I https://example.com/novyy-slug/Если у вас есть доступ к Search Console, отправьте новый URL на переобход и проверьте, не остался ли старый адрес в отчете по страницам с ошибкой 404. Для массовых изменений это особенно полезно: поисковик не всегда обновляет данные сразу.
Частые ошибки и как их исправить
Редирект ведет на главную, а не на новую страницу
Так бывает, если в правиле указан неправильный путь или slug уже занят другой записью. Проверьте, что новый адрес реально существует и не конфликтует с архивом, рубрикой или страницей.
Новый URL тоже отдает 404
Сначала пересохраните постоянные ссылки. Если не помогло, проверьте конфликт плагинов и наличие правил в .htaccess или конфигурации сервера. На Nginx проблема часто не в WordPress, а в том, как настроен обработчик ЧПУ.
Старый адрес открывается без редиректа
Значит, WordPress уже не знает о старом slug, а правило перенаправления не добавлено. Для публичных материалов это плохой вариант: внешние ссылки и закладки пользователей будут ломаться.
После замены слугов сломались вложения и медиа-ссылки
Обычно это не связано напрямую со slug записи, но всплывает после массовой правки контента. Проверьте, не затронули ли вы URL изображений, вложений и ссылок в блоках.
Что делать, чтобы проблема не повторялась
Если slug приходится менять регулярно, не делайте это вручную «по месту» без учета старых адресов. Практичнее заранее вести таблицу соответствий или использовать плагин редиректов, а для крупных сайтов — отдельный процесс после публикации: обновление ссылок, очистка кеша, проверка sitemap и контроль 404 в логах.
Для безопасности и производительности не ставьте несколько плагинов, которые одновременно управляют редиректами и ЧПУ. Конфликты между ними часто проявляются не сразу, а после очередного обновления. Если на сайте уже используется набор для технической чистки и SEO, например Clearfy Pro, проверьте, не дублирует ли он часть функций другого плагина — особенно в зоне редиректов, дублей и служебных URL.
И главное: если меняете slug у уже проиндексированной страницы, думайте не только о WordPress, но и о старых ссылках, кеше и поисковом индексе. Именно эта связка обычно и дает 404, а не одна «сломанная запись».