Как исправить 404 на страницах с пагинацией в WordPress после настройки кеша и ЧПУ

Сценарий знакомый: главная, рубрики и архивы открываются нормально, а страницы вида /page/2/, /page/3/ или пагинация внутри таксономий начинают отдавать 404. Чаще всего это всплывает после включения кеша, изменения структуры постоянных ссылок, переноса сайта или правок в шаблоне архива. Проблема неприятная не только для пользователей: поисковик тоже видит битые URL и может хуже обходить большие архивы.

Как понять, что сломалась именно пагинация

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

Что проверить в первую очередь

• Открывается ли /page/2/ в стандартной рубрике и в архиве записей.
• Не менялась ли недавно структура постоянных ссылок в Настройки → Постоянные ссылки.
• Не включён ли плагин кеша с отдельной настройкой для 404, редиректов или очистки пагинированных страниц.
• Не переопределяет ли тема запрос через pre_get_posts или кастомный шаблон архива.

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

Почему это ломается после кеша и ЧПУ

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

Ещё один частый источник проблем — ручная правка шаблона архива. Например, разработчик выводит записи через отдельный WP_Query, но забывает передать текущую страницу в параметр paged. Визуально это выглядит как сломанная пагинация, хотя на самом деле WordPress честно отдаёт первую страницу снова и снова.

Пошаговое решение

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

Это самый безопасный первый шаг. Откройте Настройки → Постоянные ссылки и просто нажмите «Сохранить изменения» без правок. WordPress пересоберёт rewrite rules. После этого проверьте проблемный URL ещё раз. Если 404 исчезла, значит дело было в устаревших правилах.

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

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

add_action('init', function () {
    add_rewrite_rule('^news/page/([0-9]+)/?$', 'index.php?post_type=post&category_name=news&paged=$matches[1]', 'top');
});

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

2. Проверьте, не ломает ли кеш пагинированные страницы

Если стоит плагин кеширования, очистите весь кеш и отдельно проверьте настройки исключений. Некоторые решения умеют кэшировать HTML для /page/2/ как обычную страницу, а потом отдают его после изменения контента или структуры архивов. Для архивов и рубрик это особенно заметно: первая страница обновляется, а вторая и третья остаются старыми или начинают отдавать 404 из кеша.

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

3. Исправьте кастомный запрос в шаблоне

Если пагинация сделана не через основной цикл, а через отдельный запрос, обязательно передавайте текущую страницу. Иначе WordPress не поймёт, какую часть архива показывать.

<?php
$paged = max(1, get_query_var('paged'));

$query = new WP_Query([
    'post_type'      => 'post',
    'posts_per_page' => 10,
    'paged'          => $paged,
]);

if ($query->have_posts()) {
    while ($query->have_posts()) {
        $query->the_post();
        the_title('<h2>', '</h2>');
    }

    echo paginate_links([
        'total'   => $query->max_num_pages,
        'current' => $paged,
    ]);

    wp_reset_postdata();
}

Если paged не передать, вторая и последующие страницы могут вести себя как первая. Иногда это маскируется тем, что шаблон не падает в ошибку, а просто показывает повторяющийся контент.

4. Проверьте серверные правила и конфликт с редиректами

На Apache и Nginx проблема может быть не в WordPress, а в конфигурации. Неправильный .htaccess или блок try_files в Nginx иногда перехватывает запросы к /page/2/ раньше, чем они доходят до WordPress. Это особенно заметно после миграции с одного хостинга на другой.

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

Что проверить после исправления

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

• Откройте первую, вторую и третью страницу архива вручную.
• Проверьте, что в HTML есть ссылки на следующую и предыдущую страницу.
• Посмотрите код ответа в браузере или через curl: для рабочей страницы должен быть 200, а не 404.
• Убедитесь, что в пагинированном архиве не повторяется один и тот же набор записей.

Для быстрой проверки можно использовать команду:

curl -I https://example.com/category/news/page/2/

Если сервер отвечает 200 OK, но в браузере вы всё равно видите ошибку, значит проблема может быть в кеширующем прокси, CDN или в JS-логике темы, которая подменяет контент после загрузки страницы.

Сравнение подходов: плагин, код, ручная правка

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

Не обновили rewrite rules после изменения структуры ссылок

Симптом: старые URL ещё открываются, а новые страницы пагинации уже нет. Решение: пересохранить постоянные ссылки и проверить, не остались ли старые правила в плагине или теме.

Забыли передать paged в кастомный запрос

Симптом: вторая страница показывает те же записи, что и первая, или ссылка ведёт на 404 после перехода. Решение: брать текущую страницу через get_query_var('paged') и передавать её в WP_Query.

Кеш отдаёт устаревший 404

Симптом: после очистки кеша страница открывается, а через некоторое время снова ломается. Решение: проверить правила исключений, TTL и очистку кеша при публикации/обновлении записей.

Редирект перехватывает URL с /page/

Симптом: вместо нужной страницы пользователь попадает на главную или в другой архив. Решение: упростить регулярное выражение редиректа и отдельно протестировать URL с пагинацией.

Как не сломать производительность и индексацию

Если архивы большие, не стоит лечить проблему отключением пагинации или массовым noindex без понимания последствий. Для поисковика пагинированные страницы — нормальный способ добраться до старых материалов. Гораздо полезнее сделать их доступными, но не плодить мусорные дубли.

Если у вас уже используются инструменты для чистки дублей и SEO-настроек, например Clearfy Pro, проверьте, не включены ли там правила, которые случайно закрывают нужные архивы или меняют canonical для пагинированных страниц. В таких настройках легко переборщить: цель — убрать мусор, а не отрезать рабочие разделы сайта.

Для производительности лучше кешировать HTML аккуратно, а не по принципу «всё подряд». Пагинация должна оставаться предсказуемой: первая страница может обновляться чаще, а остальные — получать корректную версию после очистки кеша.

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

• Постоянные ссылки пересохранены.
• Пагинация работает в рубриках, архивах и на кастомных типах записей.
• paged передаётся в кастомных запросах.
• Кеш очищен, а пагинированные URL не попадают под ошибочные исключения.
• Редиректы не перехватывают /page/2/ и похожие адреса.
• Код ответа для страниц пагинации — 200, а не 404 или бесконечный редирект.

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