Как с помощью ИИ найти и исправить soft 404 страницы в WordPress

Soft 404 в WordPress — это страницы, которые отдают HTTP 200, но по сути выглядят как пустые, бесполезные или почти пустые. Поисковик видит такой URL как «живой», тратит на него обход, а пользователь получает страницу без нормального контента, с сообщением «ничего не найдено» или с шаблоном архива, где нет записей. На практике это часто всплывает после миграции, массового удаления записей, ошибок в шаблоне или неудачной настройки фильтров.

Если у вас уже были задачи с дублями meta description, noindex и canonical, soft 404 — следующий логичный шаг. Здесь проблема не в метатегах, а в том, что страница формально существует, но не несет ценности. ИИ удобно использовать не для «магии», а как помощника для аудита: он быстро группирует подозрительные URL, объясняет, почему они выглядят как soft 404, и помогает выбрать корректное действие — удалить, переадресовать, закрыть от индексации или наполнить контентом.

Как выглядит soft 404 и почему его сложно заметить вручную

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

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

ИИ здесь полезен тем, что умеет сопоставлять несколько сигналов сразу: заголовок страницы, текст шаблона, количество видимого контента, статус ответа, наличие canonical, robots-меток и поведение шаблона. Это экономит время по сравнению с ручным просмотром сотен URL.

Диагностика проблемы: какие данные собрать до запуска ИИ

Сначала нужно собрать список подозрительных URL. Не пытайтесь сразу чинить всё подряд. Лучше взять небольшой, но репрезентативный набор: страницы из Search Console, URL из логов, результаты краулинга и страницы, которые чаще всего возвращают пустую или почти пустую выдачу.

Что стоит выгрузить

• URL с высоким числом показов и низким CTR;
• страницы с ответом 200, но без основного контента;
• архивы и поиск с пустой выдачей;
• URL, которые раньше были полезными, но после удаления записей остались доступными;
• страницы, где шаблон выводит фразу вроде «Записей не найдено».

Если у вас есть доступ к серверным логам или к краулеру, добавьте туда URL, которые бот посещает чаще обычного. Это часто помогает найти soft 404 раньше, чем они начнут мешать индексации.

Как сформулировать задачу для ИИ

Не просите ИИ «найти все ошибки на сайте». Давайте ему структурированный набор данных и конкретный критерий. Например: «Определи, какие URL похожи на soft 404, объясни признак и предложи действие: редирект, noindex, удаление или доработка контента».

Промпт для аудита soft 404 в WordPress:

У меня есть список URL из WordPress-сайта и краткие описания их содержимого. Для каждого URL определи, похож ли он на soft 404. Критерии: страница отдает 200 OK, но контент пустой, почти пустой или бесполезный для пользователя. Верни таблицу с колонками: URL, вероятность soft 404, причина, рекомендуемое действие, что проверить вручную.

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

Пошаговое решение: как использовать ИИ для поиска и исправления soft 404

Шаг 1. Сгруппируйте URL по типу шаблона

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

Шаг 2. Попросите ИИ оценить не только URL, но и причину

Вместо простого списка «плохих страниц» попросите объяснение. Например, одна и та же страница может быть soft 404 из-за пустого архива, а другая — из-за того, что на ней остался только заголовок и блок «ничего не найдено». Это разные сценарии исправления.

Шаг 3. Выберите действие для каждой группы

Здесь полезно сравнить варианты. Не все soft 404 нужно редиректить. Иногда правильнее закрыть страницу от индексации, а иногда — вернуть 404 или 410, если контент удалён окончательно.

Шаг 4. Исправьте шаблон или поведение запроса

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

<?php

// Пример для шаблона архива в теме: если записей нет, отдаём 404 вместо пустой страницы 200 OK.</nif ( ! have_posts() ) {

    global $wp_query;

    $wp_query->set_404();

    status_header(404);

    nocache_headers();

    include get_query_template('404');

    exit;

}

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

Шаг 5. Автоматизируйте проверку через WP-CLI или скрипт

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

<?php

$urls = [

    'https://example.com/?s=',

    'https://example.com/category/news/',

    'https://example.com/author/admin/'

];

foreach ( $urls as $url ) {

    $response = wp_remote_get( $url, [ 'timeout' => 10 ] );

    $code = wp_remote_retrieve_response_code( $response );

    $body = wp_remote_retrieve_body( $response );

    $is_soft_404 = ( 200 === $code ) && ( stripos( $body, 'ничего не найдено' ) !== false || stripos( $body, 'no results' ) !== false );

    echo $url . ' | ' . ( $is_soft_404 ? 'possible soft 404' : 'ok' ) . PHP_EOL;

}

После этого можно отдать результаты ИИ для классификации: где нужен 301, где 404/410, где noindex, а где достаточно доработать шаблон.

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

Проверка должна быть не только визуальной. Откройте страницу в браузере и отдельно проверьте HTTP-ответ. Для этого подойдут DevTools, curl или любой серверный лог. Важно убедиться, что выбранное действие действительно применяется: редирект отрабатывает, 404 возвращается с нужным кодом, а noindex не конфликтует с canonical.

• для удалённых страниц — ответ 301 или 410, а не 200;
• для пустых технических страниц — отсутствие индексации и отсутствие лишнего обхода;
• для доработанных архивов — нормальный контент и отсутствие сообщения о пустой выдаче;
• в Search Console — снижение числа URL, которые поисковик считает soft 404;
• в логах — уменьшение повторных обходов бесполезных страниц.

Если страница всё ещё определяется как soft 404, проверьте не только сам URL, но и связанные шаблоны: пагинацию, canonical, robots-метки, блоки темы и плагины, которые могут подменять контент.

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

Оставили 200 OK на пустой странице

Это самая частая причина. Разработчик видит «страница открывается», но поисковик видит бесполезный URL. Если контента нет и он не планируется, лучше вернуть 404 или 410, либо сделать редирект на релевантный раздел.

Сделали редирект на главную

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

Закрыли страницу noindex, но оставили пустой шаблон

Noindex не лечит soft 404 сам по себе. Страница всё равно может обходиться ботом и расходовать краулинговый бюджет. Если URL не нужен, решайте вопрос на уровне статуса ответа или редиректа.

ИИ получил слишком мало данных

Если вы отправили только список URL без контекста, модель может ошибиться в классификации. Добавляйте заголовок страницы, тип шаблона, статус ответа, краткое описание контента и, если возможно, фрагмент HTML. Тогда вывод будет гораздо полезнее.

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

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

Если вы используете ИИ-сервис для анализа, не отправляйте туда приватные данные пользователей, служебные токены и внутренние URL с параметрами авторизации. Для аудита soft 404 обычно достаточно обезличенного набора данных. На стороне WordPress полезно также проверить, не создают ли проблему плагины фильтров, поиска и архивов: иногда именно они генерируют пустые страницы с кодом 200.

Когда нужно быстро навести порядок в технических SEO-ошибках, удобно сочетать ручной аудит с инструментами вроде Clearfy Pro, если он уже используется в проекте: часть типовых проблем с дублями и служебными страницами проще закрывать на уровне настроек, чем править каждый шаблон отдельно. Но сам soft 404 всё равно нужно проверять по фактическому HTTP-ответу и содержимому страницы.

Мини-чек-лист перед публикацией правок

• у удалённых URL есть 301 или 410, а не 200;
• пустые архивы не индексируются или отдают корректный статус;
• страницы поиска не попадают в индекс;
• canonical указывает на реальный канонический URL;
• шаблон не выводит заглушку вместо полезного контента;
• после правок проверен ответ сервера и видимый HTML;
• в Search Console нет роста soft 404 по тем же шаблонам.

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