Как исправить 404 на архиве и пагинации после удаления записи в WordPress с WP Super Cache

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

Если у вас включен WP Super Cache, важно сначала понять, где именно возникает ошибка: на уровне WordPress, на уровне кэша или на уровне сервера. Иначе можно долго чистить кэш, а причина останется в старом rewrite-правиле, неверном canonical или в том, что архивный шаблон генерирует ссылку на уже удаленный объект.

Как выглядит проблема на практике

Обычно жалобы сводятся к одному из вариантов:

• после удаления записи перестает открываться /category/news/page/2/ или похожая пагинация;
• архив категории открывается, но отдельные страницы пагинации дают 404;
• главная рубрики показывает старый список, а переход на следующую страницу уже ломается;
• в админке запись удалена, но в выдаче поиска или в кеше CDN/браузера еще видны старые ссылки;
• ошибка появляется только после очистки кэша или только у незалогиненных пользователей.

Это не всегда означает, что WP Super Cache виноват напрямую. Но именно кэш часто маскирует первопричину: вы видите не свежий ответ WordPress, а старую страницу, которая уже не соответствует текущей структуре записей.

Диагностика: что проверить до правок

1. Открывается ли архив без кэша

Сначала проверьте URL в режиме, где кэш не участвует. Самый простой способ — открыть страницу в приватном окне после очистки кэша, а затем сравнить с ответом сервера через curl.

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

Смотрите на статус:

• 200 OK — страница существует, проблема может быть в кэше или шаблоне;
• 301/302 — есть редирект, который может вести на неправильный адрес;
• 404 Not Found — WordPress или сервер действительно не находят маршрут.

2. Не сломались ли правила постоянных ссылок

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

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

3. Не генерирует ли тема битые ссылки

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

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

Шаг 1. Очистите кэш и обновите правила перезаписи

Начните с базового: очистите кэш WP Super Cache и сохраните постоянные ссылки. Это убирает две самые частые причины — старый HTML и устаревшие rewrite rules.

Если у вас есть доступ к WP-CLI, можно дополнительно проверить, не остались ли старые объекты в кеше страницы на уровне сервера или CDN. Но сам WP Super Cache через WP-CLI обычно не управляется, поэтому здесь важнее именно очистка в админке и повторное сохранение permalink-настроек.

Шаг 2. Убедитесь, что архивный шаблон использует корректную пагинацию

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

$paged = max( 1, get_query_var( 'paged' ) );

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

Если paged не передавать, архив может выглядеть рабочим на первой странице, но ломаться на второй и дальше.

Шаг 3. Пересоберите ссылки пагинации через стандартные функции

Не собирайте URL вручную строкой. Для архивов используйте paginate_links() или стандартную навигацию темы. Это снижает риск получить неправильный URL после удаления записи или изменения количества страниц.

$big = 999999999;

echo paginate_links( array(
    'base'      => str_replace( $big, '%#%', esc_url( get_pagenum_link( $big ) ) ),
    'format'    => '?paged=%#%',
    'current'   => max( 1, get_query_var( 'paged' ) ),
    'total'     => $query->max_num_pages,
    'prev_text' => '←',
    'next_text' => '→',
) );

Так WordPress сам подставит корректный адрес для текущего архива, а не сохранит старый путь в шаблоне.

Шаг 4. Проверьте, не кэшируется ли 404 слишком агрессивно

WP Super Cache может хранить не только успешные ответы, но и ошибки, если сервер или дополнительный слой кэширования настроены неаккуратно. Если 404 возникает только после удаления записи и потом «залипает», проверьте:

• нет ли CDN, который кеширует ошибку дольше, чем HTML;
• не отдает ли сервер старый 404 из собственного кэша;
• не включен ли слишком долгий TTL для страниц архива;
• не используются ли правила, которые кэшируют URL с пагинацией без учета изменения контента.

Если есть CDN, после удаления записи желательно сбрасывать кэш не только в WordPress, но и на внешнем уровне.

Когда нужен код: принудительная очистка кэша после удаления записи

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

<?php
add_action( 'before_delete_post', function( $post_id ) {
    $post = get_post( $post_id );
    if ( ! $post ) {
        return;
    }

    // Очищаем кэш для архивов, которые могли зависеть от этой записи.
    if ( function_exists( 'wp_cache_clear_cache' ) ) {
        wp_cache_clear_cache();
    }

    // На случай, если тема строит ссылки на архивы вручную.
    clean_term_cache( array(), 'category' );
    clean_term_cache( array(), 'post_tag' );
}, 10, 1 );

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

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

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

• в приватном окне браузера;
• после очистки кэша WP Super Cache;
• через curl -I или curl -s для проверки статуса ответа.

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

Дополнительно проверьте:

• нет ли в исходном коде ссылок на удаленную запись;
• открывается ли последняя страница архива без редиректа на 404;
• не меняется ли статус ответа после повторной загрузки страницы;
• не появляется ли ошибка только у незалогиненного пользователя.

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

Сохранили постоянные ссылки, но не обновили шаблон

Если архив строится через кастомный запрос, сброс permalink-ов не поможет. Нужно проверить paged, max_num_pages и генерацию ссылок пагинации.

Чистят только кэш плагина, забывая про CDN

Если перед сайтом стоит CDN или прокси, он может продолжать отдавать старый 404 даже после очистки WP Super Cache. В таком случае сбрасывайте кэш на всех уровнях.

Удалили запись, но не пересчитали архивы

Иногда тема или плагин хранит собственный список записей в transient или опции. После удаления контента этот список устаревает. Проверьте, не используется ли в проекте собственное кэширование списков через set_transient().

Путают 404 на записи и 404 на архиве

Удаленная запись должна вести на 404 или редирект по вашей логике. Но архив категории или пагинация не обязаны ломаться. Если ломается именно архив, ищите проблему в шаблоне, правилах перезаписи или кэше, а не в самом факте удаления записи.

Сравнение подходов: что делать в первую очередь

Практические советы по безопасности и производительности

Не отключайте кэш целиком ради одной ошибки. Лучше локализовать проблему и исправить источник. Полное выключение WP Super Cache на рабочем сайте часто только маскирует баг и увеличивает нагрузку.

Если вы вносите правки в тему, делайте это в дочерней теме или через небольшой mu-plugin. Так проще откатить изменения и не потерять их после обновления.

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

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