После переноса сайта или смены структуры постоянных ссылок чаще всего ломаются не главная и не рубрики, а отдельные страницы, записи, вложения и старые адреса из поиска. Типичный сценарий: в админке всё открывается, а посетитель получает 404. Если не разобраться сразу, такие ошибки быстро превращаются в потерю трафика, лишние обходы поисковыми роботами и мусор в отчётах аналитики.
Ниже — рабочая схема: как найти источник 404, чем закрыть проблему без лишних плагинов и как проверить, что исправление действительно сработало.
Когда 404 в WordPress — это не случайность, а следствие конкретного изменения
Чаще всего проблема появляется после одного из действий:
- сменили структуру постоянных ссылок в
Настройки → Постоянные ссылки; - перенесли сайт с тестового домена на основной;
- изменили slug у записи или страницы;
- удалили материал, но старые ссылки остались в меню, внутренних ссылках или поиске;
- подключили плагин, который меняет типы записей, таксономии или правила rewrite;
- перенесли сайт и не обновили старые абсолютные ссылки в контенте.
Важно не путать обычную 404-страницу WordPress с ошибкой на уровне сервера. Если в логах Apache/Nginx есть 404, но WordPress даже не загружается, это уже вопрос конфигурации веб-сервера или кеша. Если же открывается стандартная тема с сообщением «Страница не найдена», значит запрос дошёл до WordPress, и искать нужно в правилах пермалинков, контенте или редиректах.
Диагностика: где именно ломается адрес
Перед исправлением полезно понять, какой тип URL даёт 404. Это экономит время: одно дело — битая ссылка в тексте, другое — сломанные правила перезаписи после миграции.
Проверьте сам URL и источник ссылки
Откройте проблемный адрес в браузере и сравните его с тем, что хранится в редакторе записи. Если адрес отличается даже на один символ, WordPress не обязан угадывать старый путь. Отдельно проверьте:
- меню;
- внутренние ссылки в контенте;
- виджеты;
- хлебные крошки;
- ссылки из sitemap.xml;
- ссылки из внешних сервисов и старых писем.
Посмотрите, не сломаны ли правила пермалинков
Если 404 появились массово сразу после переноса, сначала откройте Настройки → Постоянные ссылки и просто нажмите «Сохранить изменения» без правок. Это пересобирает rewrite rules и часто решает проблему, если WordPress не успел обновить правила после миграции или смены типа записей.
Если после этого ничего не изменилось, проверьте, не отключён ли модуль mod_rewrite на Apache и не переписаны ли правила в .htaccess. На Nginx аналогичная проблема обычно сидит в конфигурации try_files.
Проверьте, не остались ли старые URL в базе
После переезда с домена на домен часто остаются абсолютные ссылки вида https://old-domain.ru/.... Они могут быть в контенте, в настройках темы, в опциях плагинов и в серийно сохранённых данных. Если такие ссылки ведут на старый адрес, посетитель упрётся в 404 уже на уровне перехода.
Для быстрой проверки можно найти старый домен в базе через WP-CLI:
wp search-replace 'https://old-domain.ru' 'https://new-domain.ru' --all-tables --dry-runКоманда в режиме --dry-run покажет, где именно есть совпадения, но не будет ничего менять. Это безопасный способ понять масштаб проблемы до реальной замены.
Пошаговое решение без лишних плагинов
Ниже порядок, который обычно даёт результат быстрее всего. Не пропускайте шаги: если начать с редиректов, не устранив сломанные ссылки в базе, проблема вернётся.
1. Пересохраните структуру постоянных ссылок
Зайдите в Настройки → Постоянные ссылки и нажмите «Сохранить изменения». Это обновляет правила маршрутизации WordPress. После миграции или изменения post_type это обязательный первый шаг.
2. Обновите старые ссылки в контенте и настройках
Если сайт переехал на новый домен или изменился путь к разделам, выполните замену старого адреса на новый. Для этого лучше использовать WP-CLI или инструмент, который корректно работает с сериализованными данными. Пример:
wp search-replace 'https://old-domain.ru' 'https://new-domain.ru' --all-tablesЕсли WP-CLI недоступен, можно использовать плагин для поиска и замены, но только временно и только с проверкой результата. После замены плагин лучше удалить, чтобы не держать лишний код в админке.
3. Настройте 301-редиректы для старых адресов
Если URL был изменён осознанно — например, у записи поменяли slug, — старый адрес нужно не просто оставить 404, а перенаправить на новый. Для единичных случаев достаточно правил в .htaccess или конфигурации Nginx.
Пример для Apache:
Redirect 301 /staryj-url/ https://example.com/novyj-url/Если редиректов много, удобнее держать их в отдельном блоке правил или использовать плагин только для управления перенаправлениями. Но не смешивайте редиректы с логикой темы: это усложняет поддержку и мешает отладке.
4. Если 404 связаны с кастомными типами записей — пересоберите rewrite rules
После регистрации custom post type или таксономии WordPress должен знать, как строить их адреса. Если разработчик темы или плагина изменил аргументы rewrite, а правила не обновились, страницы типа /portfolio/... или /catalog/... начнут отдавать 404.
Пример регистрации CPT с понятным slug:
add_action('init', function () {
register_post_type('portfolio', [
'label' => 'Портфолио',
'public' => true,
'has_archive' => true,
'rewrite' => [
'slug' => 'portfolio',
'with_front' => false,
],
'supports' => ['title', 'editor', 'thumbnail'],
'show_in_rest' => true,
]);
});После изменения таких настроек снова сохраните постоянные ссылки в админке, чтобы WordPress обновил маршруты.
Что выбрать: плагин, код или правка базы
| Подход | Когда уместен | Плюсы | Минусы |
|---|---|---|---|
| WP-CLI / код | Миграция, массовая замена URL, работа с базой | Быстро, прозрачно, можно повторить | Нужен доступ к серверу и аккуратность |
| Плагин редиректов | Много старых адресов, которые нужно перенаправить | Удобно управлять правилами из админки | Дополнительная нагрузка и зависимость от плагина |
| Правка .htaccess / Nginx | Точечные редиректы и серверный уровень | Быстро и без лишних запросов в WordPress | Нужен доступ к конфигу и осторожность |
Как проверить, что исправление сработало
Не ограничивайтесь открытием одной страницы в браузере. Проверьте несколько уровней:
- старый URL отдаёт 301, а не 200 и не 404;
- новый URL открывается без редиректной цепочки;
- внутренние ссылки в контенте ведут на актуальные адреса;
- sitemap.xml не содержит удалённых страниц;
- в Search Console уменьшается число ошибок «Не найдено»;
- в логах сервера больше не появляются повторяющиеся запросы к одному и тому же битому адресу.
Для быстрой проверки редиректа удобно использовать curl:
curl -I https://example.com/staryj-url/В ответе должен быть статус 301 и заголовок Location с новым адресом. Если приходит 200, значит редирект не сработал. Если 404 — правило не совпало с путём или не применилось на нужном уровне.
Частые ошибки и как их исправить
Редирект ведёт на главную вместо новой страницы
Так бывает, когда старый URL перенаправляют слишком общим правилом. Пользователь теряет контекст, а поисковик видит слабый сигнал. Исправление простое: на каждый важный старый адрес нужен свой точный редирект на релевантную страницу, а не на главную.
После замены URL сломались изображения
Это признак того, что в базе остались старые абсолютные ссылки на медиафайлы. Проверьте не только записи, но и поля темы, настройки виджетов и блоки в редакторе. Если сайт использует сериализованные данные, обычный SQL REPLACE() может повредить структуру. Лучше использовать WP-CLI или специализированный инструмент замены.
404 исчезли в браузере, но остались в поиске
Поисковые системы обновляют индекс не мгновенно. Если старый адрес уже отдаёт 301, это нормально: робот ещё какое-то время может показывать старую ошибку в отчётах. Важно, чтобы редирект был стабильным и без цепочек.
Плагин кеша мешает увидеть изменения
После настройки редиректов или правки .htaccess очистите кеш страницы, объектный кеш и, если есть, CDN. Иначе вы можете проверять уже не живой ответ сервера, а старую закешированную копию.
Безопасность и производительность: что не стоит делать
Не держите несколько плагинов редиректов одновременно. Они могут конфликтовать, создавать дубли правил и усложнять диагностику. Если редиректы нужны постоянно, выберите один инструмент и ведите их централизованно.
Не делайте массовую замену URL напрямую в базе без понимания сериализованных данных. Это один из самых частых способов сломать настройки темы и плагинов. Если нет WP-CLI, сначала сделайте резервную копию и проверьте замену на копии сайта.
Если проблема связана с техническим мусором на сайте — дубли, лишние архивы, служебные страницы и слабая индексация — иногда удобнее сначала почистить структуру. Для этого можно использовать инструменты вроде Clearfy Pro, если нужен набор функций для удаления дублей и технической оптимизации, но саму причину 404 он не заменяет: редиректы и корректные URL всё равно нужно настраивать вручную.
Короткий чек-лист перед публикацией исправлений
- Старый URL определён точно, без догадок.
- Постоянные ссылки пересохранены.
- Внутренние ссылки обновлены.
- Для изменённых адресов есть 301-редирект.
- Кеш очищен на сайте, сервере и CDN.
- Проверка через
curl -Iпоказывает нужный статус. - В sitemap нет удалённых страниц.
Если после всех шагов 404 остаются только на отдельных типах страниц, проблема почти всегда в rewrite rules, шаблоне темы или плагине, который регистрирует контент. В таком случае уже имеет смысл смотреть код регистрации post_type, таксономий и фильтры, которые меняют структуру ссылок.