Как убрать 404 после удаления записи в WordPress при включенном WP Super Cache

Сценарий знакомый: запись удалили, а на старом URL вместо нормальной страницы архива или корректной переадресации получаете 404, причем поведение плавает в зависимости от того, очищен ли кэш. В связке с WP Super Cache это обычно не «поломка кэша как такового», а конфликт между кэшированным HTML, правилами пермалинков и тем, как тема или плагины обрабатывают удалённый контент.

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

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

Чаще всего жалобы выглядят так:

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

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

Диагностика: что именно ломается

Перед правкой кода проверьте три вещи: отдаёт ли сервер реально 404, не подменяет ли ответ кэш, и есть ли у сайта правило редиректа для удалённых записей.

1. Проверка HTTP-статуса

Откройте старый URL в режиме инкогнито и посмотрите заголовки ответа. Удобно сделать это через curl:

curl -I https://example.com/staryy-url/

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

2. Проверка, не отдает ли WP Super Cache старую копию

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

Также проверьте, не включено ли агрессивное кеширование 404-ответов на уровне сервера, CDN или плагина. WP Super Cache сам по себе не должен превращать удалённую запись в «вечную» страницу, но он может сохранить старую HTML-копию до очистки.

3. Проверка редиректов и пермалинков

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

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

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

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

Шаг 1. Очистите кэш после удаления записи

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

Минимальный вариант — сбрасывать кэш при удалении записи и при смене статуса на trash:

<?php
add_action('before_delete_post', function ($post_id) {
    if (function_exists('wp_cache_post_change')) {
        wp_cache_post_change($post_id);
    }
});

add_action('trashed_post', function ($post_id) {
    if (function_exists('wp_cache_post_change')) {
        wp_cache_post_change($post_id);
    }
});

Это не создаёт редирект, но убирает старую кэшированную копию, чтобы следующий запрос уже увидел актуальное состояние.

Шаг 2. Добавьте редирект для удалённых записей

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

<?php
add_action('template_redirect', function () {
    if (!is_404()) {
        return;
    }

    $path = trim(parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH), '/');
    if ($path === '') {
        return;
    }

    $post_id = url_to_postid(home_url('/' . $path . '/'));
    if (!$post_id) {
        return;
    }

    $post = get_post($post_id);
    if (!$post || $post->post_status !== 'trash') {
        return;
    }

    $terms = get_the_terms($post_id, 'category');
    if (!empty($terms) && !is_wp_error($terms)) {
        wp_safe_redirect(get_term_link($terms[0]), 301);
        exit;
    }

    wp_safe_redirect(home_url('/'), 301);
    exit;
});

Код выше — базовый пример. В реальном проекте лучше хранить карту редиректов отдельно, потому что попытка угадывать старый URL через url_to_postid() не всегда надёжна, особенно если запись уже удалена давно.

Шаг 3. Если редирект нужен для конкретных URL, используйте явную карту

Самый предсказуемый вариант — хранить старый URL и новый адрес в метаполе или отдельной таблице редиректов. Тогда после удаления вы не зависите от эвристик WordPress.

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

    update_option('deleted_post_redirect_' . $post_id, esc_url_raw($old_url), false);
});

add_action('template_redirect', function () {
    if (!is_404()) {
        return;
    }

    $request = home_url(add_query_arg([], $_SERVER['REQUEST_URI']));
    $redirects = wp_load_alloptions();

    foreach ($redirects as $key => $value) {
        if (strpos($key, 'deleted_post_redirect_') !== 0) {
            continue;
        }

        if (trailingslashit($value) === trailingslashit($request)) {
            wp_safe_redirect(home_url('/'), 301);
            exit;
        }
    }
});

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

Сравнение подходов

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

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

• Откройте старый URL в инкогнито и убедитесь, что статус ответа соответствует ожидаемому: 301 или 404.
• Проверьте заголовки через curl -I и убедитесь, что нет старого 200 OK из кэша.
• Очистите кэш WP Super Cache и повторите запрос ещё раз, чтобы исключить случайную подмену старого HTML.
• Если есть CDN, проверьте ответ и на его стороне: иногда 404 или 301 кэшируются отдельно.
• Посмотрите логи сервера, если редирект не срабатывает: там часто видно, что запрос вообще не дошёл до WordPress.

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

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

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

Пытаются редиректить удалённый пост через template_redirect без проверки 404

Если не проверять is_404(), можно случайно сломать нормальные страницы. Редирект должен срабатывать только на реально несуществующем URL.

Путают 404 и soft 404

Иногда страница визуально выглядит как ошибка, но HTTP-статус остаётся 200. Для поисковиков это не 404, а мягкая ошибка. Проверяйте статус ответа, а не только текст на экране.

Ставят слишком общий редирект на главную

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

Что учесть для безопасности и производительности

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

Не делайте редирект через произвольные значения из $_GET или $_SERVER['REQUEST_URI'] без нормализации. Для редиректов используйте wp_safe_redirect(), а не header('Location: ...') вручную: это снижает риск ошибок и небезопасных переходов.

Если сайт большой и удалений много, проверьте, не раздувается ли таблица wp_options из-за временных данных или самописных карт редиректов. Для технической чистки и удаления дублей в WordPress иногда помогает аккуратная оптимизация структуры сайта; если нужен инструмент для SEO-чистки и удаления лишнего мусора, можно посмотреть Clearfy Pro: https://wpshop.ru/plugins/clearfy.

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