После переноса сайта на новый домен, смены структуры постоянных ссылок или восстановления из бэкапа часто ломаются не главные страницы, а именно записи, рубрики и произвольные типы контента. В админке они есть, а по адресу открывается 404. Обычно проблема не в одной причине: это может быть сбитый .htaccess, не обновлённые правила пермалинков, конфликт плагина, неверный home/siteurl или кэш на уровне сервера.
Ниже — рабочая последовательность, которая помогает не гадать, а быстро сузить источник ошибки и исправить его без лишних правок в базе.
Когда 404 появляется только на части страниц
Если главная открывается, а записи, страницы или архивы отдают 404, это хороший признак: WordPress жив, но маршрут до нужного объекта не совпадает с правилами обработки URL. После миграции это особенно заметно на сайтах с ЧПУ, где менялись:
- структура постоянных ссылок;
- префикс рубрик или ярлыки записей;
- домен и протокол;
- плагины, которые добавляют свои rewrite rules;
- тип записи или таксономии в теме/плагине.
Если 404 возникает только у старых URL, а новые работают, значит, проблема может быть в редиректах или в том, что поисковики и внутренние ссылки ведут на устаревшие адреса. Если 404 появляется даже на свежесозданных страницах, сначала проверяют правила пермалинков и серверную конфигурацию.
Диагностика: что проверить до правок
Начинать лучше не с редактирования кода, а с проверки базовых точек. Это экономит время и помогает не сломать рабочие URL.
1. Сравните адрес в админке и фактический URL
Откройте проблемную запись в редакторе и посмотрите её постоянную ссылку. Затем сравните её с адресом в браузере. Если в ссылке виден старый домен, лишний подкаталог или другой протокол, проблема может быть в настройках home и siteurl.
2. Обновите правила пермалинков
Самый простой тест — зайти в Настройки → Постоянные ссылки и нажать «Сохранить изменения» без правок. WordPress пересоберёт rewrite rules. После переноса это часто решает проблему сразу, особенно если файл .htaccess был перезаписан не полностью.
3. Проверьте, не мешает ли кэш
Если на сайте стоит плагин кэша, CDN или серверный кэш, очистите всё по цепочке: плагин, сервер, CDN, браузер. Иначе можно исправить URL, но продолжать видеть старую 404-страницу из кэша.
4. Посмотрите логи и ответ сервера
Если есть доступ к логам, полезно понять, кто именно отдаёт 404: WordPress, nginx, Apache или промежуточный слой. Для этого достаточно посмотреть заголовки ответа и серверный лог. Если запрос даже не доходит до WordPress, править нужно не тему и не плагины, а конфигурацию веб-сервера.
curl -I https://example.com/slug-problemnoy-stranicyВ ответе обратите внимание на server, x-cache и код ответа. Если там не WordPress-404, а серверный 404, проблема может быть в правилах nginx или Apache.
Пошаговое решение без лишнего риска
Ниже порядок, который обычно даёт результат в реальных переносах сайтов.
Шаг 1. Сохраните постоянные ссылки
Это безопасная операция. Она не меняет контент, а только пересобирает правила маршрутизации. После сохранения проверьте несколько URL: главную запись, страницу, рубрику и архив произвольного типа записи, если он есть.
Шаг 2. Проверьте .htaccess на Apache
Если сайт работает на 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>Если у вас сайт в подкаталоге, RewriteBase и путь в последнем правиле должны соответствовать реальной структуре. После правки снова сохраните постоянные ссылки в админке.
Шаг 3. Для nginx проверьте location для WordPress
На nginx WordPress не использует .htaccess, поэтому проблема часто в конфиге сервера. Минимально нужен маршрут, который отдаёт существующие файлы напрямую, а остальное передаёт в index.php. Пример типового блока:
location / {
try_files $uri $uri/ /index.php?$args;
}Если у вас отдельный конфиг для кэша, мультиязычности или подкаталогов, проверьте, не перехватывает ли он запросы раньше WordPress.
Шаг 4. Сверьте адреса сайта в базе
После переноса нередко забывают обновить home и siteurl. Проверить можно через SQL или WP-CLI. Если есть доступ к WP-CLI, это быстрее и безопаснее, чем ручная правка в phpMyAdmin.
wp option get home
wp option get siteurlЕсли значения старые, обновите их:
wp option update home 'https://example.com'
wp option update siteurl 'https://example.com'После этого ещё раз сохраните постоянные ссылки и очистите кэш.
Шаг 5. Исключите конфликт плагинов
Особенно часто rewrite rules ломают плагины мультиязычности, фильтры ЧПУ, редиректы и плагины, которые создают свои типы записей. Для проверки временно отключите всё, что влияет на URL, и оставьте только базовый набор. Если 404 исчезла, включайте плагины по одному и тестируйте конкретный адрес.
| Подход | Когда подходит | Минус |
|---|---|---|
| Сохранить постоянные ссылки | После переноса, смены домена, обновления структуры | Не помогает, если сломан серверный роутинг |
| Правка .htaccess / nginx | Если WordPress не получает запрос | Нужен доступ к конфигу сервера |
| Отключение конфликтующих плагинов | Если 404 появляется только на части типов URL | Нужно тестировать по одному модулю |
Проверка результата после внедрения
Исправление считается успешным не тогда, когда открылась одна страница, а когда стабильно работают все типы URL, которые использует сайт.
- Откройте 3–5 старых и новых записей.
- Проверьте рубрики, теги и архивы дат, если они используются.
- Проверьте произвольные типы записей и таксономии.
- Сделайте
curl -Iдля нескольких адресов и убедитесь, что код ответа 200, а не 404. - Очистите кэш плагина, сервера и CDN после финальной проверки.
Если сайт индексируется поисковиками, отдельно проверьте, не остались ли старые URL в sitemap и внутренних ссылках. Иначе 404 вернётся уже не технически, а через обход роботом.
Частые ошибки и как их исправить
Редактируют только тему, хотя проблема в маршрутизации
Если в шаблоне выводится правильная ссылка, но страница всё равно 404, дело не в single.php или page.php. Сначала проверяют пермалинки, сервер и базовые опции сайта.
Меняют .htaccess, но не сохраняют постоянные ссылки
WordPress может перезаписать правила при следующем сохранении, а иногда наоборот — продолжает использовать старый набор rewrite rules, пока их не пересоберут из админки.
Не учитывают подкаталог или нестандартный путь установки
Если сайт живёт не в корне домена, а в /blog/ или другом каталоге, шаблонные правила из интернета не подойдут без правки RewriteBase и путей.
Оставляют старый кэш после миграции
Это частая причина ложных 404. Страница уже доступна, но браузер, CDN или сервер отдают старый ответ. Проверяйте проблему в приватном окне и через curl, а не только в обычном браузере.
Не проверяют редиректы после смены домена
Если старый домен ещё отвечает, но ведёт не туда, можно получить цепочку редиректов или петлю. В таком случае сначала настраивают канонический домен, потом обновляют внутренние ссылки и sitemap.
Безопасность и производительность: что не стоит делать
Не нужно массово править URL в базе без бэкапа. Если ошибка в одном параметре, можно повредить сериализованные данные или сломать настройки плагинов. Для массовых замен лучше использовать инструменты, которые умеют работать с сериализацией, либо WP-CLI с пониманием структуры данных.
Если сайт большой, не запускайте тяжёлые проверки на живом проде в часы пик. Пересборка пермалинков, очистка кэша и проверка логов безопасны, а вот массовые поиски и замены по базе — уже нет. Для технической чистки дублей, лишних архивов и SEO-шума иногда удобнее использовать специализированный инструмент вроде Clearfy Pro, но только если задача действительно в удалении дублей и системной оптимизации, а не в ремонте маршрутизации.
Если после всех проверок 404 остаётся только на отдельных типах записей, имеет смысл посмотреть регистрацию register_post_type() и register_taxonomy() в теме или плагине. Ошибка в rewrite-параметрах часто проявляется именно после обновления кода или смены 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'],
]);
});Если меняете rewrite у существующего типа записи, после обновления кода обязательно пересохраните постоянные ссылки, иначе старые правила останутся в памяти WordPress.
Когда проблема уже не в WordPress
Бывает, что WordPress настроен правильно, но 404 остаётся из-за внешнего слоя: reverse proxy, CDN, WAF или неправильного SSL-редиректа. В этом случае полезно сравнить ответ напрямую с сервером и через домен, а также временно отключить промежуточный кэш. Если прямой запрос к origin работает, а публичный URL — нет, искать нужно в инфраструктуре, а не в CMS.
Практический ориентир простой: если после обновления пермалинков, проверки home/siteurl, правки серверных правил и очистки кэша страницы всё ещё отдают 404, значит, нужно смотреть логи и конфигурацию слоя, который стоит перед WordPress. Это быстрее, чем бесконечно переустанавливать плагины и менять тему.