Как убрать 404 на страницах пагинации в WordPress

404 на страницах пагинации — типичная техническая проблема после смены темы, правки шаблонов архива, установки SEO-плагина или изменения структуры постоянных ссылок. Снаружи это выглядит как «сломались страницы 2, 3, 4», но на практике причин несколько: неверный запрос в шаблоне, конфликт с плагином, отключённая пагинация в настройках темы или неправильная обработка paged в кастомном WP_Query.

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

Когда это действительно проблема пагинации, а не другой 404

Сначала проверьте, что ломается именно вторая и последующие страницы архива. Для стандартного архива WordPress это обычно URL вида /category/news/page/2/, /blog/page/3/ или /page/2/ на главной ленте. Если первая страница открывается, а вторая отдаёт 404, почти всегда дело в шаблоне или запросе, а не в сервере.

Быстрая диагностика

• Откройте проблемный URL в браузере и проверьте, это именно архив, а не одиночная запись.
• Сравните поведение на стандартной теме и на текущей: если на дефолтной теме всё работает, ищите ошибку в шаблоне.
• Посмотрите, не меняли ли вы pre_get_posts, query_posts() или кастомный WP_Query в архивных шаблонах.
• Проверьте, не стоит ли плагин, который вмешивается в канонические URL, редиректы или структуру архивов.

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

Почему WordPress отдаёт 404 на второй странице архива

У WordPress пагинация работает через параметр paged. Когда шаблон архива использует неправильный запрос, WordPress не понимает, что нужно показать не первую, а следующую страницу. Частая ошибка — создание собственного запроса без учёта текущей страницы или с неправильным набором параметров.

Ещё одна причина — использование query_posts(). Эта функция переписывает глобальный запрос и часто ломает пагинацию, особенно если в шаблоне потом строят ссылки через paginate_links() или the_posts_pagination().

Пошаговое решение для стандартных архивов

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

1. Откройте Настройки → Постоянные ссылки.
2. Нажмите Сохранить изменения без правок.
3. Проверьте проблемный URL ещё раз.

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

Что проверить в шаблоне архива

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

add_action('pre_get_posts', function (WP_Query $query) {
    if (is_admin() || ! $query->is_main_query()) {
        return;
    }

    if ($query->is_category('news')) {
        $query->set('posts_per_page', 12);
    }
});

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

Если 404 возникает в кастомном WP_Query

Это самый частый сценарий в темах и плагинах. Разработчик выводит список записей через WP_Query, но забывает передать номер текущей страницы. В итоге первая страница работает, а вторая уже не знает, какие записи показывать.

Правильный вариант выглядит так:

$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 не передать, WordPress будет считать, что всегда открыта первая страница. Визуально это часто проявляется как 404 на /page/2/ или как повтор одного и того же контента на разных URL.

Когда нужен get_query_var('page')

Для обычных архивов используйте paged. Значение page чаще встречается на статических страницах с разбивкой контента по страницам. Если вы подставите не тот параметр, пагинация может вести себя непредсказуемо.

Практическое правило простое: архивы и ленты — paged, постраничная разбивка внутри страницы — page.

Проверка результата после правки

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

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

Если у вас есть доступ к WP-CLI, можно быстро проверить, что сам URL существует и не редиректится странно:

wp rewrite flush --hard

Команда полезна после изменений в правилах пермалинков, но использовать её постоянно не нужно: это не лечение, а инструмент для обновления rewrite rules.

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

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

Используют query_posts() вместо нормального запроса

Это ломает основной цикл и часто сбивает пагинацию. Заменяйте на pre_get_posts или отдельный WP_Query с корректным paged.

Не сбрасывают глобальные данные после кастомного цикла

После WP_Query обязательно вызывайте wp_reset_postdata(). Иначе следующий блок шаблона может работать с неправильным постом и ссылками.

Путают paged и page

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

Ставят жёсткий posts_per_page в шаблоне без учёта основного запроса

Если архив уже ограничен настройками WordPress или фильтром pre_get_posts, второй слой ограничений может дать неожиданный результат. Лучше менять один уровень, а не несколько сразу.

Безопасность и производительность

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

Для крупных сайтов следите за тем, чтобы пагинация не тянула лишние данные. Не добавляйте тяжёлые JOIN-запросы и не грузите в архивы лишние метаполя, если они не нужны для списка. Чем проще запрос, тем меньше шанс получить нестабильное поведение на больших объёмах контента.

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

Если нужен быстрый аудит похожих технических ошибок

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

Главное здесь одно: 404 на пагинации почти всегда можно локализовать. Сначала проверьте, где именно ломается запрос, потом исправьте источник в теме или плагине, и только после этого трогайте редиректы и кэш. Такой порядок экономит время и не создаёт новых ошибок поверх старой.