Когда сайт в WordPress внезапно теряет страницы из индекса или, наоборот, начинает тащить в поиск служебные URL, проблема часто не в одном теге, а в связке: robots.txt, noindex, canonical, архивы, параметры URL и шаблоны темы. Ручная проверка по одной странице быстро превращается в рутину. Здесь AI полезен не как «генератор советов», а как помощник для разбора паттернов: он помогает сопоставить правила, найти конфликтующие директивы и подсветить места, где шаблонно выставлен неправильный индексирующий сигнал.
Ниже — рабочий сценарий: что собрать, как дать это AI, какие ошибки искать и как проверить, что правка действительно сработала.
Какие симптомы обычно указывают на проблему
Сначала имеет смысл понять, что именно сломано. Для WordPress типовые признаки выглядят так:
- в поиске остаются только часть записей, хотя страницы доступны без ошибок;
- в индекс попадают архивы тегов, авторов, страниц поиска и пагинация;
- в Google Search Console появляются исключённые URL с причиной, которая не совпадает с вашей логикой;
- в коде страниц встречаются разные сигналы:
noindexв мета-теге, но разрешение вrobots.txt, или наоборот; - каноникал указывает на URL, который сам закрыт от индексации.
Важно не путать блокировку обхода и запрет индексации. robots.txt управляет сканированием, а noindex — попаданием в индекс. Если закрыть URL в robots.txt, поисковик может не увидеть noindex на странице вообще. Это частая причина, почему «мы же поставили noindex, а URL всё равно висит в индексе».
Что собрать перед анализом
AI не должен гадать по ощущениям. Дайте ему конкретные данные: так он быстрее найдёт конфликт. Для начала соберите:
- текущий
robots.txt; - шаблонные настройки SEO-плагина или темы, если они управляют мета-роботами;
- несколько примеров проблемных URL;
- HTML исходник страницы с
<meta name="robots">и<link rel="canonical">; - скрин или текст из Search Console по причине исключения;
- если есть, список правил редиректов и фильтров параметров.
Если у вас много URL, не скармливайте AI весь сайт. Возьмите 5–10 типовых страниц: запись, рубрику, тег, поиск, архив автора, пагинацию. Этого обычно хватает, чтобы увидеть системную ошибку.
Пример запроса к AI
Запрос должен быть не «проверь robots.txt», а с контекстом и задачей. Например:
Проанализируй настройки индексации WordPress ниже как технический редактор SEO.
Найди конфликты между robots.txt, meta robots и canonical.
Скажи, какие URL будут сканироваться, но не индексироваться, а какие могут быть заблокированы слишком жёстко.
Отдельно проверь архивы, пагинацию и страницы поиска.
В конце дай список правок по приоритету.
robots.txt:
User-agent: *
Disallow: /wp-admin/
Disallow: /?s=
Disallow: /tag/
Allow: /wp-admin/admin-ajax.php
URL 1: https://example.com/category/news/
meta robots: index, follow
canonical: https://example.com/category/news/
URL 2: https://example.com/tag/seo/
meta robots: noindex, follow
canonical: https://example.com/tag/seo/
URL 3: https://example.com/?s=wordpress
meta robots: noindex, follow
canonical: https://example.com/?s=wordpressТакой формат помогает AI не расплываться, а сравнивать правила и сигналы по каждому типу URL.
Пошаговое решение: как найти слабые места
1. Сверьте правила сканирования и индексации
Первый шаг — проверить, не закрыли ли вы важные страницы в robots.txt. Если архив тегов должен быть noindex, но при этом доступен для обхода, его не стоит жёстко запрещать в robots.txt. Иначе поисковик может не увидеть мета-тег и продолжит держать старую версию в индексе дольше, чем нужно.
Для служебных страниц логика обычно такая:
- страницы поиска —
noindex, followи, как правило, не блокировать вrobots.txt; - архивы тегов и авторов — либо осознанно индексируются, либо закрываются через
noindex; - пагинация — не закрывать без причины, если она нужна для обхода контента;
/wp-admin/— блокировать можно, но оставитьadmin-ajax.phpдоступным.
2. Проверьте, кто именно ставит noindex
В WordPress noindex может приходить из SEO-плагина, темы или кастомного кода. AI удобно использовать для сопоставления шаблонов: если на всех тегах стоит noindex, а вы этого не планировали, значит проблема в глобальной настройке или фильтре.
Если нужен точечный контроль в коде, безопаснее менять не HTML вручную, а использовать фильтр, который уже есть в ядре. Например, для служебных страниц можно убрать индексацию через wp_robots:
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_search() || is_tag() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );Этот вариант лучше, чем править шаблон header.php напрямую: логика остаётся в одном месте и не теряется при обновлении темы.
3. Сравните canonical с реальным адресом страницы
AI часто находит именно здесь скрытую ошибку. Например, страница архива открыта по /category/news/page/2/, а canonical указывает на первую страницу архива. Для пагинации это не всегда корректно: поисковик может считать вторую страницу дублем и не учитывать её как отдельный URL для обхода.
Проверьте, не переписывает ли тема canonical для архивов, поиска и фильтров. Если есть кастомный код, ищите фильтр wpseo_canonical в Yoast SEO или аналогичный механизм в вашем SEO-плагине. Если плагина нет, canonical должен соответствовать фактическому URL страницы, а не «главной версии» на глаз.
Как автоматизировать первичную проверку через код
Если у вас много типовых страниц, можно быстро собрать список сигналов и отдать его AI на анализ. Ниже пример простого диагностического скрипта для админской проверки: он не меняет сайт, а только показывает, какие правила видит WordPress на текущем URL.
<?php
add_action( 'admin_notices', function() {
if ( ! current_user_can( 'manage_options' ) ) {
return;
}
if ( ! is_search() && ! is_tag() && ! is_category() ) {
return;
}
$robots = wp_robots();
echo '<div class="notice notice-info"><p>';
echo '<strong>Robots:</strong> ' . esc_html( wp_json_encode( $robots ) );
echo '</p></div>';
} );На практике такой код полезен только как временная диагностика. После проверки его нужно убрать, чтобы не засорять админку и не светить внутреннюю логику.
Сравнение подходов: плагин, код или AI-ревью
| Подход | Когда подходит | Минус |
|---|---|---|
| SEO-плагин | Если нужно быстро управлять мета-роботами без кода | Легко не заметить конфликт между шаблонами и ручными исключениями |
| Кастомный код | Если есть повторяющаяся логика для архивов, поиска, таксономий | Нужна дисциплина: код должен быть документирован и протестирован |
| AI-анализ | Если нужно быстро найти конфликт в нескольких типах URL и правилах | Без исходных данных AI может дать слишком общие рекомендации |
На практике лучше сочетать все три: плагин для базовой настройки, код для точечных исключений, AI для аудита и поиска несостыковок.
Проверка результата после внедрения
После правок не ограничивайтесь просмотром исходника одной страницы. Проверьте несколько уровней:
- откройте проблемный URL в браузере и посмотрите исходный код;
- убедитесь, что
meta robotsсоответствует задаче страницы; - проверьте canonical на совпадение с реальным адресом;
- посмотрите, не блокируется ли URL в
robots.txtраньше, чем поисковик увидит мета-тег; - в Search Console отправьте URL на повторную проверку, если страница уже была в индексе с ошибкой.
Если речь о массовой правке, полезно сравнить несколько страниц одного типа. Например, все теги должны вести себя одинаково: либо все закрыты, либо все открыты по одной логике. Разнобой обычно означает, что часть правил идёт из темы, а часть — из плагина.
Частые ошибки и как их исправить
Закрыли страницу в robots.txt и одновременно поставили noindex
Это одна из самых неприятных комбинаций. Поисковик может не увидеть noindex, потому что не сможет обойти страницу. Исправление простое: оставьте страницу доступной для сканирования, если хотите убрать её из индекса через мета-тег.
Canonical указывает на не ту версию URL
Часто это происходит на страницах с параметрами, пагинацией или фильтрами. Проверьте, не переписывает ли canonical тема или SEO-плагин. Если canonical нужен только для чистых URL, не заставляйте его указывать на главную страницу архива без разбора.
AI анализирует только текст robots.txt без контекста сайта
Тогда он может предложить «закрыть всё лишнее», что для WordPress плохая идея. Давайте AI не только правила, но и типы страниц, которые реально есть на сайте. Иначе он не отличит служебную страницу поиска от полезного архива рубрики.
Правки внесли в тему, а потом обновили её и потеряли изменения
Если логика индексации живёт в шаблоне темы, она должна быть вынесена в дочернюю тему или мини-плагин. Иначе любая обновляющаяся тема сотрёт ваши настройки.
Практические советы по безопасности и производительности
Не делайте массовые правки индексации через прямое редактирование файлов на продакшене. Для таких задач лучше использовать staging-копию, а затем переносить только проверенные изменения. Это особенно важно, если у вас уже есть SEO-плагин, который может перезаписать мета-теги при следующем обновлении или сохранении настроек.
Если нужен более системный аудит дублей, тонких страниц и технических сигналов, удобно подключать инструменты, которые умеют работать с SEO-логикой WordPress на уровне правил. Например, Clearfy Pro полезен как база для чистки технических дублей и управления частью SEO-настроек, но даже в этом случае AI-аудит остаётся полезным: он помогает увидеть не только отдельную настройку, а конфликт между несколькими слоями правил.
Если коротко, рабочая схема такая: собрать реальные URL и сигналы, отдать их AI на сравнение, исправить конфликт в одном месте, затем проверить исходник, canonical и Search Console. Это быстрее и надёжнее, чем вручную перебирать все архивы и гадать, почему индекс ведёт себя не так, как ожидалось.