Как отладить 404 ошибки после миграции сайта WordPress

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

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

С чего начать диагностику 404 после переноса

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

Быстрая проверка перед правками

• Откройте проблемный URL в режиме инкогнито, чтобы исключить локальный кэш браузера.
• Проверьте ответ сервера через curl -I https://example.com/problem-url/ или любой HTTP-инспектор.
• Сравните, открывается ли URL с www и без него, по http и https.
• Посмотрите, не менялась ли структура постоянных ссылок после переноса.
• Если используется кэш-плагин или серверный кэш, временно очистите его и проверьте страницу снова.

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

Пошаговое решение: что проверить и в каком порядке

1. Сбросьте правила постоянных ссылок

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

Зайдите в админку: Настройки → Постоянные ссылки и просто нажмите Сохранить изменения без правок. Это заставит WordPress обновить rewrite rules.

Если нужен программный вариант, можно выполнить сброс один раз при активации плагина или темы, но не на каждом запросе:

<?php
register_activation_hook(__FILE__, function () {
    flush_rewrite_rules();
});

Важно: не вызывайте flush_rewrite_rules() на фронтенде. Это тяжёлая операция, и при каждом запросе она только замедлит сайт.

2. Проверьте файл .htaccess или конфигурацию nginx

Если сайт работает на Apache, после переноса часто теряются стандартные правила WordPress. Для обычной установки в корне сайта блок должен быть похож на этот:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

На nginx логика другая: там нужен корректный try_files. Если его нет, WordPress не сможет обрабатывать «красивые» URL, и часть страниц будет отдавать 404 даже при правильных настройках в админке.

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

3. Убедитесь, что старые URL не конфликтуют с новыми

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

Для точечной проверки удобно посмотреть, куда реально ведёт редирект:

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

Если конечный адрес отличается от ожидаемого, исправьте правило редиректа. Для ручного редиректа в WordPress можно использовать template_redirect, но только для единичных случаев:

<?php
add_action('template_redirect', function () {
    if (is_page('old-page')) {
        wp_redirect(home_url('/new-page/'), 301);
        exit;
    }
});

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

4. Очистите кэш на всех уровнях

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

Проверяйте кэш по слоям:

• очистка кэша плагина;
• сброс серверного кэша у хостинга;
• purge в CDN, если он используется;
• проверка в приватном окне и с другого устройства.

Если кэшируется 404-ответ, он может жить дольше, чем кажется. После исправления маршрута обязательно сделайте принудительную очистку.

Когда проблема не в WordPress, а в данных сайта

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

Проверьте, существует ли объект в админке

Если URL записи отдаёт 404, но самой записи нет в списке постов, значит проблема не в маршрутизации. Нужно восстановить контент или вернуть корректный slug. То же касается медиафайлов: если картинка есть в HTML, но файла физически нет в uploads, WordPress тоже покажет 404.

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

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

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

1. Откройте проблемный адрес в браузере и убедитесь, что страница отдается с кодом 200.
2. Проверьте заголовки через curl -I: не должно быть лишних редиректов и финального 404.
3. Пройдитесь по нескольким старым URL из логов, Search Console или аналитики.
4. Очистите кэш и повторите тест из инкогнито.
5. Если есть sitemap, проверьте, что в нём остались только рабочие адреса.

Хороший признак — когда старый URL либо корректно редиректится на новый, либо честно отдаёт 404, если страницы больше не существует. Плохой признак — цепочка из нескольких редиректов, которая в конце упирается в несуществующую страницу.

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

Редирект ведёт на страницу, которой уже нет

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

Сбросили постоянные ссылки, но 404 остались

Значит, проблема не только в WordPress. Проверьте серверные правила и кэш. На nginx особенно часто забывают обновить конфиг после переноса сайта в другой каталог.

404 видны только у вложений

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

После исправления всё снова ломается

Так бывает, если кэш-плагин или CDN продолжает отдавать старую версию страницы. В этом случае нужно не только очистить кэш, но и проверить, не генерирует ли плагин отдельные правила для 404-страниц.

Что делать для безопасности и стабильности

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

Практичный минимум перед правками:

• сделать резервную копию файлов и базы;
• сохранить текущий .htaccess или конфиг nginx;
• проверять изменения сначала на staging-копии;
• не смешивать редиректы из нескольких плагинов;
• не использовать массовые автозамены URL без выборочной проверки.

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

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

• Постоянные ссылки пересохранены.
• .htaccess или nginx-конфиг содержит корректные правила WordPress.
• Старые URL либо редиректятся, либо удалены из sitemap.
• Кэш очищен на всех уровнях.
• Проблемные страницы открываются с кодом 200.
• В логах нет новых 404 по тем же адресам.

Если после этого часть ошибок остаётся, смотрите access/error-логи сервера: там обычно видно, кто именно отдаёт 404 — WordPress, веб-сервер или промежуточный кэш.