404-страница сама по себе не должна попадать в индекс, но на практике это часто ломается из-за темы, SEO-плагина или ручной настройки шаблона. Типичный сценарий: поисковик видит не только код ответа 404, но и полноценную HTML-страницу с заголовком, текстом и ссылками. Если на ней еще и стоит мета-тег index, проблема становится заметной в отчете об индексировании.
Ниже разберем, как проверить текущую ситуацию, что именно править в WordPress и как убедиться, что 404 действительно не индексируется. Без лишних действий: только то, что можно проверить руками и через исходный код.
Когда 404-страница вообще попадает в индекс
Сам по себе статус 404 Not Found обычно достаточен, чтобы поисковик не держал страницу в индексе. Но есть несколько рабочих сценариев, когда это не срабатывает:
- тема выводит на 404 полноценный контент с внутренними ссылками и без
noindex; - SEO-плагин не добавляет мета-тег
robotsна шаблон ошибки; - сервер или кэш отдают не настоящий 404, а
200 OKс текстом «страница не найдена»; - на сайте есть старые внешние ссылки на несуществующие URL, и поисковик успел их просканировать;
- в шаблоне 404 случайно подключены канонические URL на главную или похожие страницы.
Что проверить в первую очередь
Откройте несуществующий адрес, например /this-page-should-not-exist-12345/, и посмотрите три вещи: код ответа, содержимое <head> и заголовок страницы. Если в ответе не 404, а 200, сначала исправляйте шаблон темы или правила перенаправления, а уже потом думайте об индексации.
Проверка через консоль браузера или curl дает самый быстрый ответ:
curl -I https://example.com/this-page-should-not-exist-12345/В норме вы должны увидеть что-то вроде HTTP/2 404. Если там 200, поисковик воспринимает страницу как обычную.
Диагностика: где именно ломается 404
Сначала определите, на каком уровне проблема: сервер, WordPress, тема или SEO-плагин. Это экономит время, потому что одинаковый симптом может иметь разные причины.
| Что проверяем | Как выглядит ошибка | Что делать |
|---|---|---|
| HTTP-статус | 200 OK вместо 404 | Проверить шаблон 404.php, редиректы и кэш |
| Мета robots | index,follow или отсутствие тега | Добавить noindex через SEO-плагин или код |
| Canonical | Ссылка на главную или другой URL | Убрать каноникал с 404-шаблона |
| Кэш | Старый HTML отдается как обычная страница | Очистить серверный и плагинный кэш |
Если у вас включен кэш на уровне плагина или сервера, обязательно проверьте страницу в режиме инкогнито и после очистки кэша. Иначе можно исправить шаблон, но видеть старую версию еще несколько часов.
Пошаговое решение через шаблон темы
Если вы контролируете тему, самый надежный вариант — явно задать noindex для 404-страницы в head. Это не заменяет корректный HTTP-статус, но убирает лишние риски, если тема или SEO-плагин ведут себя нестабильно.
Добавляем meta robots только для 404
Вставьте код в functions.php дочерней темы или в свой мини-плагин:
add_action( 'wp_head', function () {
if ( is_404() ) {
echo '<meta name="robots" content="noindex,follow">' . "\n";
}
}, 1 );Здесь важно именно noindex,follow: страница не должна индексироваться, но поисковый робот может переходить по ссылкам, если они есть на шаблоне ошибки. Это нормальная практика для 404.
Убираем canonical с 404-страницы
Некоторые темы и SEO-плагины автоматически добавляют canonical даже там, где он не нужен. Для 404 это лишнее. Если ваш плагин не умеет отключать canonical точечно, можно убрать его фильтром:
add_filter( 'get_canonical_url', function( $canonical ) {
if ( is_404() ) {
return false;
}
return $canonical;
} );Если фильтр не сработал в вашей связке, проверьте, не выводит ли canonical сам SEO-плагин отдельным хуком. В этом случае лучше отключать его штатной настройкой плагина, а не дублировать логику в коде.
Если используете SEO-плагин: что настроить без кода
Во многих проектах проще и безопаснее закрыть 404 через настройки SEO-плагина, чем править тему. Это особенно удобно, если сайт поддерживается не одним разработчиком.
Проверьте, есть ли в плагине такие опции:
- мета-robots для страниц ошибки;
- отключение canonical на служебных шаблонах;
- автоматическое добавление
noindexна 404; - контроль заголовка
X-Robots-Tag, если плагин его поддерживает.
Если у вас уже стоит плагин для чистки сайта и SEO-настроек, например Clearfy Pro, имеет смысл сначала проверить его штатные функции для служебных страниц, а не городить отдельный код. Это уменьшает число конфликтов в <head>. Ссылка на продукт: https://wpshop.ru/plugins/clearfy.
Когда нужен заголовок X-Robots-Tag
Если 404-страница отдается не как обычный HTML-шаблон, а через нестандартную сборку, можно добавить заголовок X-Robots-Tag. Это полезно, когда вы хотите явно продублировать запрет на индексацию на уровне ответа сервера.
add_action( 'template_redirect', function () {
if ( is_404() ) {
header( 'X-Robots-Tag: noindex, follow', true );
}
} );Этот вариант не отменяет необходимость корректного 404 статуса. Он просто добавляет еще один сигнал для поисковика. Используйте его аккуратно: если заголовки уже отправляются где-то еще, не дублируйте их без проверки.
Проверка результата после внедрения
После правок нужно убедиться, что страница действительно ведет себя как служебная, а не как обычный индексируемый URL.
- Откройте несуществующий URL в браузере и проверьте код ответа в DevTools или через
curl -I. - Посмотрите исходный код страницы и убедитесь, что есть
<meta name="robots" content="noindex,follow">. - Проверьте, что canonical отсутствует или не указывает на другой URL.
- Очистите кэш плагина, сервера и CDN, если он есть.
- В Search Console отправьте URL на повторную проверку, если он уже был в индексе.
Если в Search Console страница еще отображается, это не всегда значит, что настройка не сработала. Иногда поисковику нужно время, чтобы переобойти URL и обновить статус. Но если при ручной проверке вы видите 200 или отсутствие noindex, проблема точно на вашей стороне.
Частые ошибки и как их исправить
Страница ошибки отдает 200 вместо 404
Это самая неприятная ошибка. Обычно она появляется после кастомизации темы или из-за неправильного редиректа. Проверьте, что шаблон 404.php не вызывает status_header( '200' ) и не перенаправляет пользователя на главную без причины.
На 404 стоит редирект на главную
Так делать не стоит, если у вас нет очень узкой причины. Массовый редирект 404 на главную часто создает мусор в аналитике и мешает поисковику понимать структуру сайта. Для несуществующих URL правильнее оставить 404 или, в отдельных случаях, 410.
Кэш продолжает отдавать старую версию
После изменений очистите не только плагин кэширования, но и серверный кэш, если он есть. На некоторых хостингах именно он держит старый HTML даже после обновления темы.
Canonical ведет на главную
Это частая ошибка в самописных темах. На 404 canonical не нужен. Если он есть, поисковик может получить противоречивые сигналы: статус говорит одно, canonical — другое.
Безопасность и производительность: что не делать
Не вставляйте в 404-страницу тяжелые блоки, которые тянут десятки запросов к базе или внешним сервисам. Служебная страница должна открываться быстро и без лишней нагрузки. Это особенно важно, если бот активно сканирует битые URL.
Также не стоит использовать сторонние скрипты аналитики или виджеты, которые не нужны на странице ошибки. Чем меньше кода на 404, тем меньше шанс получить лишние задержки и конфликты.
Если вы правите тему вручную, лучше вынести логику в дочернюю тему или небольшой mu-plugin. Так обновление основной темы не затрет изменения.
Короткий чек-лист перед публикацией правок
- 404-страница возвращает именно
404, а не200. - В
<head>естьnoindex,follow. - Canonical на 404 не выводится.
- Кэш очищен на всех уровнях.
- В Search Console URL отправлен на повторную проверку, если он уже был в индексе.
- На странице ошибки нет тяжелых виджетов и лишних скриптов.
Если нужен более «системный» подход к чистке служебных страниц и SEO-мелочей, можно посмотреть инструменты, которые закрывают часть таких задач без ручного кода. Но в любом случае сначала проверьте статус ответа и исходный HTML — именно там обычно и лежит причина проблемы.