Как с помощью ИИ найти страницы WordPress, которые случайно закрыты от индексации

Ситуация знакомая: контент опубликован, внутренние ссылки есть, а в поиске страницы не появляются. Вручную это обычно превращается в долгую проверку robots.txt, meta robots, canonical, настроек SEO-плагина и шаблонов темы. Если страниц много, часть проблем легко пропустить.

В таких задачах AI полезен не как «генератор текста», а как помощник для аудита: он быстро сопоставляет выгрузку URL, мета-теги, ответы сервера и шаблонные настройки, а потом подсказывает, где именно искать блокировку индексации. Ниже — рабочий сценарий для WordPress без выдуманных инструментов и магии.

Когда стоит подозревать проблему с индексацией

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

• страница открывается по прямой ссылке, но не находится по точному URL в поиске;
• в Google Search Console URL помечен как Excluded by 'noindex' или похожим статусом;
• после миграции сайта часть материалов исчезла из индекса;
• SEO-плагин обновили, а новые записи перестали попадать в поиск;
• в шаблоне темы появились кастомные условия для noindex или canonical.

Самая неприятная часть в том, что причина часто не одна. Например, страница может одновременно иметь noindex в HTML, закрытый путь в robots.txt и каноникал на другую запись. AI здесь помогает не «угадать», а быстро разложить симптомы по слоям.

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

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

1. список проблемных URL;
2. HTML этих страниц с мета-тегами;
3. содержимое robots.txt и, если есть, настройки SEO-плагина.

Если у вас есть доступ к серверу или WP-CLI, удобно выгрузить список опубликованных записей и проверить их массово. Например, можно получить URL через SQL или экспорт из админки, а затем прогнать их через скрипт. Для небольшой выборки достаточно и ручной проверки через браузер и исходный код страницы.

Что именно искать в HTML

Проблема индексации обычно сидит в одном из этих мест:

• <meta name="robots" content="noindex, nofollow">;
• <link rel="canonical" href="..."> на другой URL;
• HTTP-заголовок X-Robots-Tag;
• условный вывод мета-тегов в теме или плагине;
• правила в robots.txt, которые блокируют важные разделы.

Если страница закрыта только в HTML, поисковик может увидеть её, но не индексировать. Если путь закрыт в robots.txt, бот может даже не дойти до страницы. Это разные проблемы, и лечатся они по-разному.

Как использовать AI для поиска причины

Лучше всего работает не абстрактный запрос, а структурированный. Скопируйте в ИИ конкретные данные: URL, фрагмент исходника, заголовки ответа, правила robots. Чем точнее вход, тем полезнее вывод.

Проверь следующий набор данных и скажи, что именно мешает индексации каждой страницы:

URL: https://example.com/article-a/
HTML:
<meta name="robots" content="noindex, follow">
<link rel="canonical" href="https://example.com/article-a/">

URL: https://example.com/article-b/
HTML:
<link rel="canonical" href="https://example.com/category/news/">

robots.txt:
User-agent: *
Disallow: /wp-admin/
Disallow: /tag/

Такой запрос полезен тем, что AI не просто «читает» текст, а группирует проблемы по типу: noindex, canonical, robots.txt, дубли, шаблонная ошибка. После этого уже можно идти в конкретный файл темы, настройки плагина или в базу данных.

Что попросить у AI дополнительно

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

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

Это экономит время на ручной сортировке. Особенно если сайт большой и часть страниц закрыта намеренно, а часть — случайно.

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

Ниже — практический порядок действий, который обычно даёт быстрый результат.

1. Проверьте SEO-плагин и шаблонные настройки

Если используется SEO-плагин, сначала смотрите глобальные настройки для типов записей, архивов, таксономий и медиа-страниц. Частая ошибка — включённый noindex для целого типа записей или архивов после импорта демо-данных или миграции.

Если проблема появилась после правок темы, ищите фильтры, которые меняют robots meta. В кастомных темах это часто делают через wp_head или через фильтры SEO-плагина.

2. Проверьте robots.txt

В WordPress файл robots.txt может быть виртуальным, а может отдаваться сервером. Если там случайно закрыт важный раздел, поисковик не будет его обходить. Для проверки достаточно открыть /robots.txt в браузере и посмотреть, нет ли там запрета на нужные пути.

Если вы правите правила вручную, не закрывайте каталоги с контентом по ошибке. Для WordPress обычно блокируют только служебные пути вроде /wp-admin/, но не публичные разделы сайта.

3. Уберите ошибочный noindex точечно

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

add_filter('wp_robots', function (array $robots) {
    if (is_singular('article')) {
        unset($robots['noindex']);
        $robots['follow'] = true;
    }

    return $robots;
});

Этот пример уместен только если noindex действительно добавляется через API WordPress wp_robots. Если мета-тег выводит SEO-плагин, нужно искать его собственный фильтр или настройку. Важно не смешивать разные механизмы.

4. Исправьте canonical, если он указывает не туда

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

Для проверки откройте исходный код и сравните canonical с фактическим URL страницы. Если canonical генерируется плагином, исправляйте источник, а не только HTML на выходе.

Мини-таблица: что менять в зависимости от причины

Пример проверки через PHP

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

<?php
$urls = [
    'https://example.com/article-a/',
    'https://example.com/article-b/',
];

foreach ($urls as $url) {
    $response = wp_remote_get($url, [
        'timeout' => 15,
        'redirection' => 5,
    ]);

    if (is_wp_error($response)) {
        echo $url . "\tERROR\t" . $response->get_error_message() . PHP_EOL;
        continue;
    }

    $body = wp_remote_retrieve_body($response);
    $headers = wp_remote_retrieve_headers($response);

    preg_match('/<meta[^>]+name=["\']robots["\'][^>]+content=["\']([^"\']+)["\']/i', $body, $robots_match);
    preg_match('/<link[^>]+rel=["\']canonical["\'][^>]+href=["\']([^"\']+)["\']/i', $body, $canonical_match);

    $robots = $robots_match[1] ?? 'not found';
    $canonical = $canonical_match[1] ?? 'not found';
    $x_robots = $headers['x-robots-tag'] ?? 'not found';

    echo $url . "\t" . $robots . "\t" . $canonical . "\t" . $x_robots . PHP_EOL;
}

Если запускаете это вне WordPress, замените wp_remote_get() на curl или Guzzle. Внутри WordPress такой подход удобен тем, что использует штатный HTTP API и не требует лишних зависимостей.

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

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

• откройте страницу и проверьте исходный код на наличие noindex;
• проверьте robots.txt на отсутствие запрета для нужного пути;
• посмотрите HTTP-заголовки, особенно X-Robots-Tag;
• в Search Console отправьте URL на повторную проверку;
• сравните canonical до и после изменения;
• если есть кэш, очистите его на уровне плагина, сервера и CDN.

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

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

Отключили noindex глобально вместо точечной правки

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

Смотрят только HTML и забывают про заголовки

Если noindex убрали из мета-тега, это ещё не значит, что страница открыта для индексации. Плагин безопасности, сервер или CDN могут добавлять X-Robots-Tag на уровне ответа.

Путают canonical и noindex

Canonical не запрещает индексацию сам по себе, но может увести вес на другой URL. Если страница индексируется не та, которую вы ожидали, проверяйте обе вещи: и robots, и canonical.

Не очищают кэш после правки

Если сайт использует page cache или CDN, старый noindex может продолжать отдаваться ещё какое-то время. После изменения настроек обязательно сбросьте кэш и проверьте ответ повторно.

Безопасность и производительность: что не стоит делать

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

Если для аудита вы используете AI-сервис, не отправляйте туда приватные данные без необходимости: токены, доступы, внутренние URL, staging-поддомены с закрытым контентом. Для диагностики обычно достаточно фрагментов HTML, заголовков и списка URL без персональных данных.

Для сайтов с большим количеством страниц полезно автоматизировать проверку. Даже простой скрипт, который раз в день собирает robots meta и canonical для выборки URL, помогает ловить регрессии после обновлений темы или SEO-плагина. AI в этом сценарии нужен как аналитик: он быстро объясняет, что изменилось и где искать источник проблемы.

Если нужен более системный подход к технической чистке сайта, имеет смысл посмотреть на инструменты, которые помогают находить дубли, лишние мета-теги и мусорные настройки. Например, в экосистеме WPShop есть Clearfy Pro, который закрывает часть задач по SEO- и технической оптимизации, но применять его стоит только там, где он действительно вписывается в стек проекта.