После переноса сайта на новый домен, хостинг или в другую папку чаще всего ломаются не главные страницы, а архивы: рубрики, метки, даты, авторы, пагинация. В админке всё выглядит нормально, но при переходе по старым или новым URL сервер отдаёт 404. Это типичная проблема с правилами перезаписи, настройками постоянных ссылок и кэшем, а не с самим контентом.
Ниже — рабочий порядок действий: как диагностировать причину, что именно сбрасывать, чем отличается проблема в nginx и Apache, и как проверить, что архивы снова индексируются и открываются без ошибок.
Как понять, что проблема именно в архивах, а не в записи
Сначала важно отделить поломку архивов от общей проблемы с ЧПУ. Если одиночные записи открываются, а страницы рубрик или пагинация архива дают 404, значит WordPress получает запрос, но не может сопоставить его с правилом перезаписи. Если же не открывается вообще ничего, чаще всего сбиты постоянные ссылки, конфигурация веб-сервера или .htaccess.
Признаки, которые можно проверить за 2 минуты
- Главная страница открывается, а
/category/news/или/tag/seo/— нет. - Архив первой страницы работает, а
/page/2/даёт 404. - После переноса сайта URL стали открываться только после ручного сохранения настроек постоянных ссылок.
- В Search Console растёт число ошибок 404 именно на архивных URL.
Если у вас есть доступ к логам, посмотрите, кто отдаёт 404: WordPress или веб-сервер. Для Apache и nginx это обычно видно по строкам в access/error log. Если запрос даже не доходит до WordPress, проблема не в шаблоне и не в плагинах.
Диагностика: где ломается маршрут запроса
Самая частая ошибка — сразу менять тему или отключать плагины. Для архивов это редко помогает. Сначала проверьте три слоя: настройки WordPress, правила сервера и кэш.
1. Постоянные ссылки в админке
Откройте Настройки → Постоянные ссылки и просто нажмите «Сохранить изменения», даже если ничего не меняли. Это заставляет WordPress пересобрать правила перезаписи. После переноса сайта это часто решает проблему без дополнительного кода.
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 не получит запрос на обработку и архивы будут падать в 404 на уровне сервера.
location / {
try_files $uri $uri/ /index.php?$args;
}Важно: не копируйте чужой конфиг целиком. Сравните его с текущей структурой сайта, особенно если WordPress стоит в подкаталоге или за прокси.
3. Кэш и CDN
Если архивы открываются после очистки кэша, а потом снова ломаются, проблема может быть в агрессивном кэшировании HTML или в CDN, который держит старые правила маршрутизации. Очистите:
- кэш плагина;
- серверный кэш;
- кэш CDN, если он есть;
- браузерный кэш для проверки.
Пошаговое решение: восстановить архивы без лишних правок
Если вы уже убедились, что проблема именно в перезаписи, действуйте по порядку. Это быстрее, чем искать «магическую» настройку в теме.
Шаг 1. Сбросьте правила перезаписи
Самый безопасный способ — открыть настройки постоянных ссылок и сохранить их. Если нужен программный вариант, можно временно вызвать flush после активации темы или плагина, но не на каждом запросе.
register_activation_hook(__FILE__, function () {
flush_rewrite_rules();
});
register_deactivation_hook(__FILE__, function () {
flush_rewrite_rules();
});Этот код уместен только в плагине или в коде, который действительно управляет структурой URL. Не вставляйте flush_rewrite_rules() в init — это создаст лишнюю нагрузку.
Шаг 2. Проверьте, не конфликтует ли кастомный тип записей
Если архивы сломались после добавления CPT или таксономии, проверьте параметры rewrite и has_archive. Неправильный slug может перекрыть рубрики или метки.
register_post_type('book', [
'label' => 'Книги',
'public' => true,
'has_archive' => true,
'rewrite' => [
'slug' => 'books',
'with_front' => false,
],
]);Если у вас уже есть страница или рубрика с таким же slug, WordPress начнёт путаться. Для архивов это особенно заметно после миграций, когда старые URL и новые правила совпадают частично.
Шаг 3. Убедитесь, что пагинация архива не конфликтует с шаблоном
Иногда первая страница архива открывается, а /page/2/ — нет. Тогда проверьте, что в шаблоне архива используется стандартная пагинация WordPress, а не самописная логика с жёстко заданными URL.
$paged = max(1, get_query_var('paged'));
$query = new WP_Query([
'post_type' => 'post',
'posts_per_page' => 10,
'paged' => $paged,
]);Если paged не передаётся, ссылки пагинации могут формироваться правильно, но запрос будет всегда возвращать первую страницу. Это не 404, но визуально выглядит как сломанный архив.
Если архивы не индексируются: что проверить после исправления 404
Когда URL снова открываются, не останавливайтесь на этом. После переноса сайта часто остаются проблемы с индексацией: архивы доступны, но закрыты от поиска или отдают дубли.
Проверьте мета robots и canonical
У рубрик и меток canonical должен указывать на сам архив, а не на главную. Если SEO-плагин или тема подменяет canonical, поисковик может игнорировать страницу даже при нормальном HTTP-ответе.
Также проверьте, не закрыты ли архивы тегом noindex. Это бывает после импорта настроек с другого сайта или при шаблонах, где автор по умолчанию отключил индексацию архивов.
Проверьте карту сайта
Если архивы должны индексироваться, убедитесь, что они попадают в XML sitemap. Иногда после переноса sitemap продолжает отдавать старые URL или исключает таксономии из-за старой конфигурации SEO-плагина.
| Подход | Когда подходит | Минус |
|---|---|---|
| Сохранить постоянные ссылки в админке | После переноса, если сломались правила перезаписи | Не помогает, если проблема в сервере |
| Исправить .htaccess / nginx | Если 404 отдаёт веб-сервер | Нужен доступ к конфигу |
| flush_rewrite_rules() в плагине | После изменения структуры URL | Нельзя вызывать на каждом запросе |
Частые ошибки и как их исправить
- Сохранили постоянные ссылки, но не очистили кэш. В результате старые 404 продолжают отдаваться из кэша. Решение: очистить серверный кэш, CDN и кэш плагина.
- Сделали одинаковый slug у рубрики и CPT. WordPress не всегда явно сообщает о конфликте, но архивы начинают вести себя непредсказуемо. Решение: разнести slug и заново сохранить ЧПУ.
- Добавили flush_rewrite_rules() в init. Это создаёт постоянную нагрузку и не решает проблему корректно. Решение: вызывать flush только при активации, деактивации или изменении настроек.
- Поменяли только тему. Если правила перезаписи сломаны на уровне сервера, тема ничего не исправит. Решение: проверять конфиг и .htaccess до правок шаблона.
- Не учли подкаталог или поддомен. После миграции в
/blog/или на отдельный хост архивы могут требовать другойRewriteBase. Решение: сверить путь установки WordPress.
Как проверить, что решение сработало
Проверка должна быть не только визуальной. Откройте несколько URL и убедитесь, что сервер отдаёт 200, а не 404 или редирект на главную.
- Откройте архив рубрики и метки в браузере.
- Проверьте вторую страницу архива:
/page/2/. - Посмотрите HTTP-статус через DevTools или
curl -I. - Убедитесь, что canonical указывает на текущий архив.
- Проверьте, что URL попал в sitemap, если архив должен индексироваться.
curl -I https://example.com/category/news/
curl -I https://example.com/category/news/page/2/Если в ответе стабильно 200 OK, а в логах больше нет повторяющихся 404 на эти адреса, проблема решена на уровне маршрутизации. После этого имеет смысл отправить обновлённые URL на переобход в Search Console.
Практические советы по безопасности и производительности
Не держите лишние правила перезаписи и не плодите кастомные архивы без необходимости. Чем больше конфликтующих slug и таксономий, тем сложнее поддерживать сайт после миграций. Если вы часто меняете структуру контента, выносите логику CPT и таксономий в отдельный плагин, а не в тему.
Если на сайте много дублей архивов, полезно пересмотреть настройки SEO и чистки технического мусора. В некоторых проектах для этого используют Clearfy Pro: он помогает убрать часть дублей и лишних элементов, но его всё равно нужно настраивать под конкретную структуру сайта, а не включать всё подряд. Ссылка на продукт: https://wpshop.ru/plugins/clearfy.
И ещё один практический момент: если архивы завязаны на фильтры, сортировки или AJAX, не подменяйте обычные URL на фронтенде без проверки серверных правил. Часто 404 появляется именно после того, как разработчик меняет красивый URL в шаблоне, но забывает добавить соответствующее правило в rewrite.