Когда в феврале 2011 года Google выпустил Panda, за одну волну из выдачи осело столько контентных ферм, что индустрия поняла: качество страниц можно мерить машиной, и она будет мерить весь сайт целиком. Фильтр давно встроен в основной алгоритм, но проблема, с которой он пришёл, жива до сих пор: тонкие страницы без ценности съедают бюджет сканирования, размывают оценку качества и тянут вниз соседей по каталогу. Статья разбирает, как найти такие страницы в своих отчётах, как отличить кандидата на улучшение от кандидата на удаление и что делать технически, когда решение принято.
Путь алгоритма Panda от отдельного фильтра до встроенной оценки качества
Panda вышла 24 февраля 2011 года и, по оценкам Google, перестроила видимость почти 12 процентов англоязычных результатов. Имя алгоритму дал инженер Навнит Панда, разработавший технологию машинной оценки качества. Позже суть механизма описал патент 8,682,892: заявка от 28 сентября 2012 года, выдача 25 марта 2014 года. Система считает соотношение ссылок на сайт и брендовых запросов к нему, переводит результат в общесайтовый модификатор и применяет его к страницам, не прошедшим порог качества. Именно поэтому фильтр воспринимался как санкция против сайта, а не против отдельной страницы.
Первые два года обновления приходили почти ежемесячно, и каждый раз кто-то терял, а кто-то возвращался. В марте 2013 года Google перевёл обновления в режим непрерывной интеграции, волна Panda 4.0 вышла 20 мая 2014 года, а Panda 4.2 раскатывалась медленно с 18 июля 2015 года. В январе 2016 года Гари Ильеш подтвердил: Panda встроена в основной алгоритм, отдельных анонсов больше не будет. С тех пор "под Панду" формально не попадают - оценка качества просто работает постоянно.
Наследники тоже живы. Вопросы из старого списка Google "что считать качественным сайтом" (там их двадцать три) перекочевали в современные руководства по полезному контенту, а политика против массового производства страниц, обновлённая в марте 2024 года, - прямая правнучка той первой чистки. Слабые страницы без ценности не выпали из повестки ни разу за пятнадцать лет, менялись только инструменты их поиска.
Что Google считает тонким контентом и где искать слабые страницы сайта
Тонкий контент - это страницы с малой добавленной ценностью, а не просто короткие. Страница из трёх абзацев с реальной пользой - нормальный контент; страница из трёх экранов текста, пересказывающая чужие материалы словами из тезауруса, - тонкая. Типичные носители проблемы: пустые разделы тегов, страницы внутренних результатов поиска, попавшие в индекс, карточки товаров из одного предложения на базе фида, копии описаний производителя, дорвеи под регионы, заглушки "раздел готовится", автоматические склейки ключевых фраз.
Искать их удобнее всего по следам в отчётах. Отчёт об индексации показывает пять летательных признаков: "Просканировано, но не проиндексировано" - робот заглянул и не нашёл, зачем тратить на страницу место в индексе; "Обнаружено, но не проиндексировано" - даже заглядывать не стал; "Дубликат без выбранного пользователем канонического URL"; "Мягкая ошибка 404" - сервер отвечает кодом 200 на страницу, по сути пустую; "Исключено по noindex" - уже кем-то закрытая зона.
Отдельный пласт - страницы, которые формально в индексе и даже получают показы, но по запросам третьего эшелона: пятая страница выдачи по коммерческому ядру, хвосты из четырёх слов, мусорная семантика, не связанная с темой сайта. Такой раздел не считается проблемой, пока не начнёшь считать его долю в индексе: когда сорок процентов каталога - пустышки, система качества читает это как преобладание пустышек, и работает общесайтовая логика из того самого патента.
Отдельная зона риска - служебные страницы, которые плодит сам движок: результаты внутреннего поиска, варианты сортировки, фильтры фасетной навигации, бесконечные цепочки пагинации, страницы тегов из одноимённых материалов. Вдумчивая навигация изобретает пустышки без участия редакторов, и владелец узнаёт о разделе в десять тысяч адресов только из отчёта об индексации. Отсюда практический приём: сначала считайте, сколько URL производит каждый шаблон, потом решайте, кто из них имеет право на индекс.
Выгрузка страниц из Search Console и сбор таблицы аудита контента
Аудит собирают из трёх источников. Search Console даёт список URL по каждому статусу индексации с экспортом в таблицу. Краулер вроде Screaming Frog добавляет структуру: число слов на странице через собственное извлечение, даты из мета-тегов, заголовки, глубину вложенности. Система аналитики привносит трафик и конверсии, внешние сервисы - входящие ссылки. В итоговой таблице каждой строке соответствует одно решение, и это делает её главным документом всего аудита.
Разметка идёт по колонкам: адрес, статус индексации, слова, трафик за год, входящие ссылки, принадлежность к ядру тематики, вердикт. Формулы тут не нужны, нужны фильтры: например, все страницы со статусом "Просканировано, но не проиндексировано" и нулевым трафиком за год - готовая стопка кандидатов на уборку. Их проверяют глазами выборочно, по одному взгляду на каждую десятую, чтобы понять природу раздела, а не отдельного адреса.
Важно удержаться от двух крайностей. Первая - считать аудит разовым: индекс живёт, новые пустышки появляются с каждым обновлением движка и каждой рассылкой подрядчика. Вторая - верить автоматике на слово: сервисы "оценки качества" меряют длину и структуру, но не отличают переработанный материал от красивой пустышки. Таблица нужна затем, чтобы решения принимал человек с критериями, а машина только готовила материал.
Строить таблицу удобнее от шаблонов, а не от адресов: сначала сводка "шаблон - число URL - число страниц с трафиком", и только потом детализация внутри проблемного шаблона. Такой порядок экономит месяцы: если у шаблона карточек из фида десять тысяч адресов и сто с показами, вопрос решается на уровне шаблона, а не постранично. Постраничный разбор оставьте страницам, у которых есть трафик, ссылки или претензия на роль в ядре тематики.
Признаки страницы с низкой ценностью от дублей до пустых шаблонов
Четыре вопроса к каждой слабой странице закрывают почти все споры в аудите:
- приносила ли она показы и клики за последние двенадцать месяцев;
- есть ли на неё входящие ссылки и живые внутренние переходы;
- содержится ли на ней фактура, которой нет на соседних адресах;
- существует ли на сайте смысловой близнец для слияния и редиректа.
Негативные признаки складываются в портрет: текст пары десятков слов без собственной фактуры; совпадение содержания с другой страницей сайта или внешним источником; шаблонный заголовок уровня "Каталог, страница пять"; публикация старше пары лет без единого обновления; средняя позиция за пятьдесят и показы по запросам, которых стыдно показывать заказчику.
Проверка на дубли - отдельная дисциплина. Совпадения ищут не только внутри сайта, но и по внешним индексам: страница, скопированная с чужого ресурса или разосланная по десяти партнёрским площадкам, всегда проигрывает канонической версии, и не в вашу пользу. Мягкая ошибка 404 вычисляется проще: код ответа 200, а по содержанию страница не отвечает ни одному запросу - сервер врёт о статусе, и поисковик это помечает.
Путь улучшения когда страницу можно спасти новой фактурой и структурой
Улучшение выбирают, когда страница нужна: у неё есть трафик, ссылки или тема, в которой сайт обязан быть представлен. Механика одна и та же - заменить пересказ фактурой. Собственные замеры, цены с датами, таблицы сравнения, опыт с конкретными моделями, обновлённые цифры, ответы на реальные вопросы из поддержки, структура с подзаголовками и списками. Переработка не равна раздуванию: добавление абзацев воды ради объёма оставляет страницу такой же пустой, только длиннее.
Ключевой вопрос любой переработки - чем эта версия отличается от пяти соседних по смыслу и от всего, что выдаётся по теме. Если ответа нет, страница не кандидат на улучшение, а кандидат на слияние. Слияние выглядит так: выбирается сильнейший адрес (по трафику и ссылкам), остальным ставится редирект 301 на него или на раздел, содержание переносится в сильную страницу без потери фактуры.
Улучшение работает по расписанию, а не по вдохновению. Сначала страницы с входящими ссылками и историей трафика, затем разделы из ядра тематики, затем всё остальное. Каждый пакет правок закрывается контрольной точкой через месяц: сравнение показов и кликов с прошлым годом, не с прошлым кварталом, чтобы сезонность не подсказала ложный вывод.
Мелочь, которая отличает переработку от косметики: соответствие обещания заголовка содержанию. Заголовок "выбор из двадцати моделей с опытом года" требует двадцати моделей и опыта года, иначе страница делает то же самое, что и раньше, - отвечает не на запрос, а на слово из запроса. Проверка одного этого соответствия после переработки закрывает львиную долю претензий к качеству.
Уборка из индекса через noindex коды ответа и канонические теги
Когда решение об уборке принято, техническая часть занимает вечер. Для страниц, которые остаются на сайте для людей, но не должны быть в выдаче, ставят метку:
<meta name="robots" content="noindex, follow">Для целых разделов удобнее заголовок ответа сервера, чтобы не править каждый шаблон:
# Apache: раздел закрыт от индексации целиком
<IfModule mod_headers.c>
Header set X-Robots-Tag "noindex, follow"
</IfModule>Удалённые навсегда страницы отдают кодом 410, который короче 404 в терминах выбывания из индекса:
# Apache
Redirect gone /old-thin-page
# nginx
location = /old-thin-page { return 410; }Дубли с параметрами закрывают канонической ссылкой:
<link rel="canonical" href="https://example.com/page">Две частые ошибки портят даже правильные решения. Первая: закрывают раздел в robots.txt и ждут выпадения из индекса - метка noindex должна быть прочитана роботом, а запрет сканирования не даёт её увидеть, страница так и висит в выдаче без описания. Вторая: массово отдают 301 вместо 410 на несуществующие адреса и создают цепочки редиректов, по которым вес утекает в никуда. Правило простое: живой адрес - каноническая ссылка или noindex, мёртвый - 410. После уборки не забудьте внутренние ссылки: каталог, из которого убрали разделы, продолжает ссылаться на удалённые адреса, и робот снова тратит обходы на 404. Карта сайта обновляется тем же вечером, что и выгрузка решений, иначе она будет месяцами рекламировать убитые страницы.
Для больших сайтов в игру вступает бюджет сканирования: миллионы пустышек заставляют робота тратить обходы на мусор, и свежие страницы ждут очередь неделями. Чистка индекса освобождает обходы для того, что действительно важно, и эффект измеряется по логам: больше запросов в час на приоритетные разделы после уборки.
Контроль переиндексации и ожидаемый эффект после чистки хвоста
После уборки смотрят два счётчика. Первый - число URL в отчёте об индексации: оно должно осесть до размеров осмысленного каталога. Второй - скорость переобхода приоритетных разделов: логи показывают, что робот вернулся к живым страницам чаще. Инструмент проверки URL ускоряет контроль по отдельным адресам: после правки метки можно запросить индексирование и не ждать естественного обхода.
Экономика эффекта складывается из трёх частей. Освобождённый бюджет сканирования достаётся страницам, которые приносят трафик. Оценка качества каталога перестаёт разбавляться пустышками, и сильные страницы получают честный сигнал соседства. Наконец, команды управления сайтом перестают тратить время на поддержку разделов, у которых нет ни читателя, ни цели.
Ожидание дисциплинирует: переиндексация занимает недели, а заметный эффект по трафику - от месяца до квартала. Контрольные точки просты: число URL в индексе, доля страниц с трафиком, средняя позиция по ядру, частота обхода приоритетных разделов по логам. Рост по всем четырём после уборки хвоста - лучший аргумент в спорах с сомневающимися, а сомневающиеся в удалении находятся в любой команде. Panda в её нынешнем виде не приходит с анонсом и не уходит волной, она просто считает. Индекс работает как витрина: на ней должно стоять только то, чем магазин действительно гордится, и это правило за пятнадцать лет не устарело ни на день.