Тонкие страницы в WordPress обычно не выглядят как явная ошибка. Это могут быть архивы без смысла, пустые карточки, страницы с коротким шаблонным текстом, дублирующиеся посадочные, теги с одним материалом или старые записи, которые уже не дают трафик. Ручной просмотр на небольшом сайте ещё возможен, но на живом проекте быстрее собрать кандидатов автоматически и уже потом принять решение: оставить, доработать, объединить или закрыть от индексации.
Ниже — рабочий сценарий, где AI помогает не «придумать SEO», а ускорить разбор большого массива URL и выделить страницы, которые стоит проверить вручную.
Когда AI реально полезен в поиске тонких страниц
AI не заменяет аналитику, но хорошо справляется с классификацией. Например, он может по списку URL и коротким метрикам пометить страницы как likely_thin, needs_review или keep. Это удобно, если у вас:
- много архивов, таксономий и служебных страниц;
- контент создавался разными авторами и в разном стиле;
- есть страницы с низкой глубиной текста и слабой внутренней связностью;
- нужно быстро понять, какие URL не стоит тащить в индекс.
Если задача — именно убрать дубли, а не тонкие страницы, это другой сценарий. Здесь мы работаем с качеством и полезностью, а не с совпадением URL или title.
Диагностика: как понять, что страница тонкая
Сначала соберите список кандидатов. Самый практичный набор признаков:
- малый объём основного текста;
- низкий органический трафик за длительный период;
- отсутствие входящих ссылок внутри сайта;
- шаблонные заголовки и мета-описания;
- страница не отвечает на отдельный пользовательский запрос.
Для WordPress удобно выгрузить записи через WP-CLI или напрямую из базы, а затем прогнать их через AI-классификатор. Если WP-CLI у вас уже используется, можно взять список опубликованных постов и сохранить его в CSV для дальнейшей обработки.
wp post list --post_type=post --post_status=publish --fields=ID,post_title,post_name,post_date --format=csv > posts.csvДальше к этому списку обычно добавляют метрики из аналитики или хотя бы ручные признаки: количество слов, наличие H2, дата публикации, число внутренних ссылок. Даже без сложной интеграции этого достаточно, чтобы AI выделил сомнительные страницы.
Пошаговое решение: как использовать AI для первичной сортировки
1. Соберите данные по страницам
Минимальный набор полей: URL, заголовок, количество слов, тип записи, дата обновления, число внутренних ссылок, краткий фрагмент текста. Чем меньше мусора в исходных данных, тем полезнее будет результат. Не отправляйте в модель весь HTML страницы, если вам нужен только первичный скоринг.
2. Передайте их в AI с жёсткой схемой ответа
Лучше просить не «оценить качество», а вернуть структурированный JSON. Тогда результат можно сразу использовать в админке или в отдельном отчёте.
<?php
function wpai_classify_page_thinness( $title, $excerpt, $word_count, $internal_links ) {
$prompt = sprintf(
"Оцени страницу WordPress как thin content или нет. Верни только JSON с полями status, reason, action.\n\nЗаголовок: %s\nФрагмент: %s\nСлов: %d\nВнутренних ссылок: %d",
$title,
$excerpt,
(int) $word_count,
(int) $internal_links
);
// Здесь должен быть ваш реальный вызов AI API.
// Возвращаемая строка должна быть JSON без лишнего текста.
return $prompt;
}В реальном проекте этот текст отправляют в API выбранной модели через wp_remote_post() или через код плагина, который уже умеет работать с AI. Важно не полагаться на свободный текст ответа: он плохо масштабируется и неудобен для проверки.
3. Сопоставьте ответ AI с действиями
Практичная схема простая:
keep— страница полезна, оставляем как есть;improve— контент слабый, но страницу можно доработать;merge— материал логичнее объединить с другой страницей;noindex— страница нужна пользователю, но не должна индексироваться;remove— страница устарела и не несёт ценности.
Такой подход удобен тем, что AI не принимает финальное решение за вас. Он только сокращает объём ручной проверки.
Пример: как хранить результат в админке WordPress
Если вы делаете это как внутренний инструмент, результат можно сохранить в post meta и потом фильтровать записи в админке. Ниже упрощённый пример записи статуса проверки.
<?php
function wpai_save_thin_content_status( $post_id, $status, $reason ) {
update_post_meta( $post_id, '_wpai_thin_status', sanitize_text_field( $status ) );
update_post_meta( $post_id, '_wpai_thin_reason', sanitize_textarea_field( $reason ) );
}После этого можно добавить колонку в список записей и быстро видеть, какие страницы требуют доработки. Это особенно удобно для редакции, где контент обновляется часто и ручной аудит быстро устаревает.
Сравнение подходов: плагин, код или ручная проверка
| Подход | Плюсы | Минусы |
|---|---|---|
| Ручная проверка | Точный контекст, меньше ложных срабатываний | Медленно, плохо масштабируется |
| AI через код | Гибкая логика, можно встроить в отчёт или админку | Нужно настраивать интеграцию и формат ответа |
| Готовый плагин с AI | Быстрый старт, меньше разработки | Меньше контроля над критериями и данными |
Если у вас уже есть плагин для AI-контента, например WPGPT, его можно использовать как часть внутреннего процесса: не для генерации текста, а для классификации и первичного анализа страниц. Но даже в этом случае критерии лучше задавать своими правилами, а не полагаться на «оценку по ощущениям».
Проверка результата после внедрения
После сортировки не спешите массово закрывать страницы. Сначала проверьте несколько вещей:
- страница действительно не получает органический трафик;
- у неё нет важных внутренних ссылок;
- она не участвует в навигации, фильтрах или хлебных крошках;
- для неё нет внешних ссылок, которые вы потеряете при удалении;
- если ставите
noindex, страница всё ещё доступна пользователю и не ломает сценарий.
Хорошая проверка — сравнить список URL до и после с данными из Search Console и логов. Если после изменений важные страницы выпали из индекса или исчезли переходы из поиска, значит решение было слишком агрессивным.
Частые ошибки и как их исправить
AI помечает полезные страницы как тонкие
Обычно это происходит, если в промпте нет контекста: тип сайта, цель страницы, роль в воронке. Добавьте в запрос правило, что страница может быть короткой, но полезной, если она решает узкую задачу.
Слишком много автоматических удалений
Не переводите результат AI сразу в действие delete. Сначала используйте промежуточный статус и ручное подтверждение. Для контентных сайтов это критично: короткая страница может быть частью важной структуры.
Проверяются только тексты, а не поведение страницы
Если игнорировать внутренние ссылки, каноникал, статус ответа и участие в навигации, AI будет оценивать только «объём текста». Это слабый сигнал. Добавляйте технические признаки в исходные данные.
Смешивают thin content и дубли
Это разные проблемы. Дубли решают через каноникал, редиректы и консолидацию URL. Thin content — через доработку, noindex или удаление. Если смешать эти сценарии, можно потерять нормальную страницу вместо мусорной.
Чек-лист перед массовыми изменениями
- Есть резервная копия базы и файлов.
- Список кандидатов выгружен отдельно, а не берётся «на глаз».
- Для каждой страницы есть причина, почему она попала в список.
- Проверены внутренние ссылки и навигация.
- Подготовлен план: доработка, noindex, объединение или удаление.
- Есть способ откатить изменения для отдельных URL.
Безопасность и производительность
Не отправляйте в AI лишние персональные данные, черновики и приватные заметки редакторов. Для первичной классификации достаточно заголовка, фрагмента и технических метрик. Если сайт большой, запускайте обработку пакетами, а не одним запросом на тысячи URL: так проще контролировать ошибки и не упереться в лимиты API.
Если вы строите это как постоянный процесс, храните результаты отдельно от основного контента и пересчитывайте их только для новых или изменённых страниц. Иначе вы будете тратить ресурсы на повторную оценку уже проверенных материалов.
В итоге AI здесь нужен не для «магической SEO-оптимизации», а для нормальной технической рутины: быстро собрать кандидатов, сократить ручной просмотр и не трогать страницы, которые реально работают.