Если после удаления страницы в WordPress пользователи продолжают видеть 404, а в кеше остаются старые URL, проблема обычно не в самом удалении записи, а в том, что кеш и правила переадресации живут своей жизнью. В WP Super Cache это особенно заметно на архивных страницах, пагинации и в случаях, когда старый URL уже успел попасть в индекс или в закладки.
Разбирать нужно не только кеш-плагин, но и цепочку целиком: удаление контента, очистку кеша, редирект со старого адреса и проверку, что сервер не отдает устаревшую HTML-версию из wp-content/cache.
Как выглядит проблема на практике
Типичный сценарий такой: страницу удалили, на ее место не поставили редирект, а WP Super Cache еще некоторое время отдает старую копию или, наоборот, уже отдает 404, но поисковик и внешние ссылки продолжают вести на несуществующий адрес. В итоге пользователь получает ошибку, а сайт теряет трафик и внутренние переходы.
Отдельно стоит проверить, не остались ли ссылки на удаленный URL в меню, блоках, хлебных крошках, XML-карте сайта и в старых публикациях. Если адрес продолжает встречаться внутри сайта, 404 будет повторяться даже после очистки кеша.
Диагностика: что проверить до правок
Сначала нужно понять, где именно ломается цепочка. Это можно сделать без сторонних инструментов, прямо из браузера и админки.
- Откройте удаленный URL в режиме инкогнито и посмотрите код ответа.
- Проверьте заголовки ответа: есть ли
cache-control,x-cacheили признаки отдачи из кеша. - Посмотрите исходный HTML: нет ли там старого шаблона страницы вместо честной 404.
- Очистите кеш WP Super Cache вручную и повторите проверку.
- Проверьте, создан ли редирект со старого URL на новый или на ближайший релевантный раздел.
Если после очистки кеша 404 исчезает или меняется поведение, значит проблема была именно в устаревшей копии. Если 404 остается стабильным, ищите ошибку в правилах сервера, плагине редиректов или в том, как удаляется контент.
Пошаговое решение
1. Сначала удаляйте не страницу, а ее публичный адрес из цепочки переходов
Если у страницы есть замена, редирект нужно поставить до удаления или сразу после него. Для WordPress безопаснее использовать постоянный редирект 301. Если замены нет, можно вести URL на ближайший архив или родительскую страницу, но не на главную без смысла.
Пример через template_redirect для конкретного старого адреса:
<?php
add_action('template_redirect', function () {
if (is_page('staryy-urll')) {
wp_redirect(home_url('/nuzhnyy-razdel/'), 301);
exit;
}
});
Такой вариант годится для точечного случая. Если удаленных URL много, лучше использовать плагин редиректов или правила на уровне сервера, чтобы не раздувать тему и не плодить условную логику в functions.php.
2. После удаления очищайте кеш не точечно, а для затронутых страниц
WP Super Cache умеет сбрасывать кеш, но при ручном удалении контента не всегда очевидно, какие URL уже успели попасть в статическую копию. Если удаляете страницу, проверьте:
- главную страницу, если на ней был блок со ссылкой;
- архивы рубрик и тегов;
- пагинацию;
- страницы поиска, если URL был в результатах;
- карту сайта, если она генерируется отдельно.
Если у вас есть собственная логика удаления, можно дополнительно очищать кеш после перехода записи в статус trash или при полном удалении. Для этого подходит хук before_delete_post:
<?php
add_action('before_delete_post', function ($post_id) {
if (function_exists('wp_cache_clear_cache')) {
wp_cache_clear_cache();
}
});
Это грубый, но рабочий вариант. Он очищает общий кеш, поэтому использовать его стоит только если удаление контента происходит нечасто. Для больших сайтов лучше точечная стратегия: чистить только связанные страницы или полагаться на штатные механизмы плагина.
3. Убедитесь, что сервер не отдает старую копию из другого слоя кеша
Иногда WP Super Cache уже очистили, а 404 или старая страница все равно видны. Тогда мешает не плагин, а еще один слой: Nginx fastcgi_cache, CDN или кеш браузера. В такой ситуации сначала отключите CDN на время проверки или сделайте принудительный запрос с Cache-Control: no-cache.
Если используется Nginx, проверьте, не кэшируется ли 404 как обычный ответ. Это отдельная настройка на стороне сервера, и WP Super Cache ее не перекрывает.
Как проверить, что исправление сработало
Проверка должна быть не визуальной, а технической. Иначе легко принять старый кеш за рабочий редирект.
- Откройте старый URL в приватном окне.
- Проверьте код ответа: для редиректа должен быть 301 или 302, для удаленной страницы — 404, если редирект не нужен.
- Убедитесь, что конечный URL открывается без цепочки лишних переходов.
- Обновите кеш WP Super Cache и повторите запрос еще раз.
- Проверьте тот же адрес через
curl -I https://example.com/staryy-url/и сравните заголовки до и после очистки.
Если редирект настроен правильно, старый адрес должен стабильно вести на новый, а не один раз открываться, а потом снова падать в 404 после сброса кеша.
Сравнение подходов: плагин, код, сервер
| Подход | Когда уместен | Плюсы | Минусы |
|---|---|---|---|
| Плагин редиректов | Много старых URL, нужна поддержка без кода | Удобно управлять, видно историю правил | Дополнительный плагин и еще один слой логики |
| Код в теме или mu-plugin | Несколько фиксированных адресов | Быстро, без лишнего интерфейса | Нужно следить за обновлениями и не ломать шаблон |
| Редирект на сервере | Высокая нагрузка, много переходов | Быстро и надежно | Нужен доступ к конфигу Apache/Nginx |
Частые ошибки и как их исправить
Удалили страницу, но не поставили редирект
Это самая частая причина. Если URL уже был в индексе или на него есть внешние ссылки, 404 будет нормальным с точки зрения HTTP, но плохим с точки зрения трафика. Исправление простое: либо 301 на замену, либо осознанный 404, если контент действительно больше не нужен.
Очистили только один кеш, а остались CDN или серверные копии
Если после сброса WP Super Cache поведение не меняется, ищите второй кеш. Особенно часто это CDN и Nginx. Проверка через заголовки ответа обычно быстро показывает, кто отдает страницу.
Редирект ведет на нерелевантную страницу
Перенаправление на главную выглядит как быстрый выход, но для пользователя это плохой сценарий. Лучше вести на ближайший тематический раздел или на обновленную версию материала.
Редирект сделан через цепочку из нескольких переходов
Старый URL → промежуточная страница → новая страница. Для SEO и скорости это лишнее. Сведите цепочку к одному шагу.
Практические советы по безопасности и производительности
Если вы добавляете редиректы кодом, не размазывайте их по шаблонам. Для точечных правил лучше использовать mu-plugins или отдельный мини-плагин: так логика не пропадет после смены темы. Для массовых правил храните список URL в одном месте и проверяйте его перед деплоем.
Не делайте автоматический 301 на главную для всех удаленных страниц. Это создает мусорные переадресации и мешает поисковикам понять, что именно изменилось. Если удаление массовое, сначала составьте таблицу соответствий старых и новых адресов.
Если вам регулярно приходится чистить сайт от дублей, устаревших URL и мусорных архивов, имеет смысл отдельно пересмотреть SEO-настройки и генерацию служебных страниц. В таких задачах иногда помогает связка с Clearfy Pro, но только если реально нужен контроль дублей и системной чистки, а не еще один плагин ради галочки.
Мини-чек-лист перед публикацией изменений
- Старый URL больше не открывается как обычная страница.
- Редирект ведет на релевантный адрес, а не на главную без причины.
- WP Super Cache очищен после изменения.
- CDN и серверный кеш проверены отдельно.
- Внутренние ссылки на удаленный адрес удалены или обновлены.
- Код ответа проверен через браузер и
curl.
Если после всех проверок 404 остается только там, где он и должен быть, значит цепочка работает корректно: старый адрес не живет своей жизнью, кеш не мешает, а пользователь не упирается в тупик.
}